The choice of encoding defines how a FIX message is transformed into a byte stream for transmission. TagValue encoding encodes messages in a simple, human-readable format. It was the original FIX encoding and is still the most widely used.
While TagValue is efficient for many use cases, it has limitations that have led to the development of alternative encodings, such as Simple Binary Encoding (SBE) , which aim to reduce message size and improve parsing performance.
Regardless of encoding, a FIX message consist of a series of fields.
Each field in a message is identified by a unique integer known as a tag. For instance, the checksum field uses tag 10. Both communicating parties typically agree on a shared dictionary of field-tag mappings in advance, especially when custom fields are involved.
A field is encoded as its tag, followed by an equals (=) character, followed by the field value.
Fields are delimited by the Start of Heading ("SOH") control character. Since SOH is non-printable, it may sometimes appear as a white square □ in logs, or be replaced with a pipe character (|) for readability.
Each part of the message (tags, values and delimiters) is encoded with the ISO-8859-1 single-byte character encoding. For example, tag 35 is transmitted as the characters 3 and 5 0x33 0x35, not as the single byte value 0x23.
Both the tag and value must consist of at least one character.
Some messages include an array of records, such as a list of trades or securities. These are encoded by first inserting a NumInGroup field, which specifies the number of group elements to follow.
Each group element starts with a mandatory field that acts as a logical delimiter between elements. There is no explicit terminator for the final group element. Instead, FIX engines detect the end of the group by identifying when the next field does not belong to the group's defined schema.
Certain fields are designed to carry arbitrary binary data, which may inadvertently include the SOH character. Without special handling, such characters would be misinterpreted as field delimiters, leading to parsing errors.
To address this, binary fields are preceded by a companion length field that specifies the number of bytes to read. This ensures that any SOH characters within the binary content are interpreted correctly as part of the field value, not as delimiters.