WIFE - open source SWIFT

E.g.

:35B:ISIN XS0222550880 4,125? LANXESS FIN.B.V.NT.V.05 21.6 :12

causes:

java.lang.IllegalArgumentException: parameter 'name' cannot be null
    at org.apache.commons.lang.Validate.notNull(Validate.java:201)
    at net.sourceforge.wife.swift.model.Tag.setName(Tag.java:199)
    at net.sourceforge.wife.swift.parser.SwiftParser.consumeTag(SwiftParser.java:873)
    at net.sourceforge.wife.swift.parser.SwiftParser.block4Consume(SwiftParser.java:599)
    at net.sourceforge.wife.swift.parser.SwiftParser.consumeBlock(SwiftParser.java:293)
    at net.sourceforge.wife.swift.parser.SwiftParser.message(SwiftParser.java:144)
    at net.sourceforge.wife.services.ConversionService.getMessageFromFIN(ConversionService.java:108)
    at net.sourceforge.wife.swift.model.UnparsedTextList.getTextAsMessage(UnparsedTextList.java:251)
    at net.sourceforge.wife.swift.model.SwiftMessage.unparsedTextGetAsMessage(SwiftMessage.java:1087)

Is this a bug (as the colon (:) should be a valid character in the SWIFT character set 'x'.

Where are the lines breaks at your example? If you field content is something like this:

":35B:ISIN XS0222550880\n" +
"4,125? LANXESS FIN.B.V.NT.V.05 21.6\n" +
":12\n"

You get the posted exception because the :12 line is interpreted as a new field. This seems to be a parser issue because the colon is valid for x charset and there are no restrictions for field components to start with a colon.

Within the field content, a colon ’:’ must never be used as the first character of a line (the combination ’CrLf:’ always indicates a new field tag). So this is not a parser issue as I've just wrote.

You cannot use ":12" as the third line of your 35B field example.

Okay, through misc ways from the original content and unix/windows charcter set conversions, the ":12" was right after the (windows) CRLF. But as of my knowledge a SWIFT block 4 field can only be ":xyz:" or ":xy:", i.e. a string enclosed in two colons and 2 or 3 characters. So ":12" can't be a field as it misses the closing colon ":". I guess the field parsing of WIFE is too simple by just looking for CRLF+: for a new field to start.