Imported from previous forum
The field instruction supports only ASCII and
Unicode. While FIX itself is not very specific on character sets,
FAST expects explicitly 7-bit ASCII for strings which are then stop-bit
encoded.
As a matter of fact, popular FIX engines such as TransactTools support
8-bit char sets such as ISO Latin-1 out of the box wherever FIX expects a String or char. When it comes to FAST, a Latin-1 string can obviously not be encoded using the instruction.
As a work-around, the byteVector instruction can be used, but this looks
a bit odd.
Any other suggestions?
Thanks,
Stefan
FAST 1.1 explicitly supports international characters through Unicode strings:
The wire representation of this field is a byte vector with the additional constraint that the content is encoded in UTF-8.
This is the recommended and most interoperable way of handling international strings in FAST.
/David
The field instruction supports only ASCII and Unicode. While
FIX itself is not very specific on character sets, FAST expects
explicitly 7-bit ASCII for strings which are then stop-bit encoded. As a
matter of fact, popular FIX engines such as TransactTools support 8-bit
char sets such as ISO Latin-1 out of the box wherever FIX expects a
String or char. When it comes to FAST, a Latin-1 string can obviously
not be encoded using the instruction. As a work-around, the
byteVector instruction can be used, but this looks a bit odd. Any other
suggestions?Thanks,
Stefan
I agree that Unicode is a good thing. However, it partially collides
with FIX in that normal FIX strings should not contain UTF-8. Using the
FIX ‘Encoded’ tags is not a solution either since it would mean a
change to existing FIX interfaces for no added value.
I believe something like
should be possible, similar to XML.
Are there opinions from FIX vendors on how to deal with 8-bit
char sets in FIX and in FAST?
Best regards,
Stefan
FAST 1.1 explicitly supports international characters through
Unicode strings:The wire representation of this field is a byte vector with the
additional constraint that the content is encoded in UTF-8.This is the recommended and most interoperable way of handling
international strings in FAST./David
It collides no more than ISO-8859-1 does. Both requires your software to have special knowledge about the deviation from the standard: FIX does only allow ASCII as specified. If you add FAST to a FIX implementation that supports the ISO-8859-1, there’s nothing that stops you from accepting fields in general and have the FAST mapping translate this down to ISO-8859-1.
Obviously an encoder would have the option of encoding strings that won’t fit in ISO-8859-1, but software always have the option to misbehave, and would in this case breake the bilaterally agreed rules of engagement.
/David
I agree that Unicode is a good thing. However, it partially collides
with FIX in that normal FIX strings should not contain UTF-8. Using the
FIX ‘Encoded’ tags is not a solution either since it would mean a change
to existing FIX interfaces for no added value.I believe something like
should be possible, similar to XML.Are there opinions from FIX vendors on how to deal with 8-bit char sets
in FIX and in FAST?Best regards,
Stefan
FAST 1.1 explicitly supports international characters through Unicode
strings:The wire representation of this field is a byte vector with the
additional constraint that the content is encoded in UTF-8.This is the recommended and most interoperable way of handling
international strings in FAST./David