# 8-bit char sets (e.g. ISO Latin-1) **URL:** \ **Category:** General Q&A\ **Tags:** xid\_169519, imported, fast-protocol\ **Created:** [September 24, 2007, 3:46pm UTC](https://forum.fixtrading.org/t/8-bit-char-sets-e-g-iso-latin-1/730 "2007-09-24T15:46:58Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![stefanschwendiman\_x](https://avatars.discourse-cdn.com/v4/letter/s/ea5d25/32.png) [@stefanschwendiman\_x](https://forum.fixtrading.org/u/stefanschwendiman_x)\ **Post date:** [September 24, 2007, 3:46pm UTC](https://forum.fixtrading.org/t/8-bit-char-sets-e-g-iso-latin-1/730/1 "2007-09-24T15:46:58Z")
Imported from previous forum ---
**Author:** ![stefanschwendiman\_x](https://avatars.discourse-cdn.com/v4/letter/s/ea5d25/32.png) [@stefanschwendiman\_x](https://forum.fixtrading.org/u/stefanschwendiman_x)\ **Post date:** [September 24, 2007, 3:46pm UTC](https://forum.fixtrading.org/t/8-bit-char-sets-e-g-iso-latin-1/730/2 "2007-09-24T15:46:58Z")
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 ---
**Author:** ![davidrosenborg30\_x](https://avatars.discourse-cdn.com/v4/letter/d/7ea924/32.png) [@davidrosenborg30\_x](https://forum.fixtrading.org/u/davidrosenborg30_x)\ **Post date:** [September 24, 2007, 4:00pm UTC](https://forum.fixtrading.org/t/8-bit-char-sets-e-g-iso-latin-1/730/3 "2007-09-24T16:00:49Z")
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 ---
**Author:** ![stefanschwendiman\_x](https://avatars.discourse-cdn.com/v4/letter/s/ea5d25/32.png) [@stefanschwendiman\_x](https://forum.fixtrading.org/u/stefanschwendiman_x)\ **Post date:** [September 24, 2007, 4:36pm UTC](https://forum.fixtrading.org/t/8-bit-char-sets-e-g-iso-latin-1/730/4 "2007-09-24T16:36:26Z")
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 ---
**Author:** ![davidrosenborg30\_x](https://avatars.discourse-cdn.com/v4/letter/d/7ea924/32.png) [@davidrosenborg30\_x](https://forum.fixtrading.org/u/davidrosenborg30_x)\ **Post date:** [September 24, 2007, 5:04pm UTC](https://forum.fixtrading.org/t/8-bit-char-sets-e-g-iso-latin-1/730/5 "2007-09-24T17:04:03Z")
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