Visual RFC.
ALL RFCs / RFC 5424
Read the RFC ↗
RFC 5424 / SYSLOG MESSAGE FORMAT

Distinguish UTF-8 message text from raw octets

04

MSG is the optional free-form event body. It can contain arbitrary octets, or UTF-8 text identified by the required byte order mark. The body’s encoding differs from the ASCII header and structured parameter rules.

RFC 5424 · § 6.4EXAMPLE
4 / 4
Distinguish UTF-8 message text from raw octetsOptional MSG example has required structured-data NILVALUE then optional SP/body. UTF8 chosen body shows3BOMoctets plus5cafeoctets, making31with23preMSG octets including header, structured-data hyphen and spaces. Separate MSG-ANY63 61 66 E9 has no proven UTF8 encoding. Separate BOM plus nonshortestC0AF stops before UTF8 interpretation. No guessed transcoding or transport error behavior.Optional MSG · byte meanings matterEF BB BF C0 AFSTOP: invalid/non-shortest UTF-8Do not interpret C0 AF as UTF-8 slash
04
Stop invalid UTF-8 interpretation.

Separate BOM-prefixed C0 AF uses a non-shortest representation of slash. It MUST NOT be interpreted as UTF-8. The stop concerns decoding, not a newly invented transport error response.

Source for this drawing: RFC 5424 · Read RFC section 6.4 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Readable-looking bytes are not enough to claim valid UTF-8.

  • The message grammar is HEADER SP STRUCTURED-DATA [SP MSG]. MSG is optional. Without structured-data elements, - still occupies that required field. MSG can be empty (§6).
  • MSG SHOULD be Unicode encoded in UTF-8. If the application cannot do that, it MAY use another encoding. When MSG uses UTF-8, it MUST begin EF BB BF, the UTF-8 byte order mark (BOM), and MUST use shortest-form encoding (§6.4).
  • A body not starting with BOM is MSG-ANY. Do not assume that such bytes are UTF-8 solely because they look like text. Invalid/non-shortest UTF-8 MUST NOT be interpreted as UTF-8, including in a BOM-prefixed MSG (§6.4).
  • Applications SHOULD avoid body octets below32, but these are legal and MAY be modified on reception; other octets SHOULD NOT be modified. This body advice is distinct from required escaping of structured parameter values (§6.4).
DETAILS

The complete fictional example <34>1 - host app - - - followed by SP and BOM+café is31octets. BOM is3octets and café is5, not4. This is an encoding lesson, not a font-dependent character count or full Unicode validator.

Read the RFC section ↗

All chapters in RFC 5424

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗