Recognize an unambiguous boundary
02An actual RS byte begins a record; an escaped RS inside a JSON string remains ordinary string data.
Only the next actual 0x1E begins another candidate record.
Source for this drawing: RFC 7464 · Read RFC section 2.2 ↗
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.
Terms in this drawing
- Escaped character
- A JSON spelling such as \u001e that represents a character without embedding its raw control byte.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Separate the framing byte from escaped string content.
- An unescaped RS cannot occur in a valid JSON text. In a JSON string it must be escaped, for example as \u001e. That six-character escape in the encoded text is not the raw byte 0x1E.
- JSON whitespace, including line feeds within a pretty-printed object, is allowed. A line feed alone is not the next-record boundary; the next RS begins the next candidate.
- A parser reads runs of non-RS bytes after RS and attempts to interpret each run as UTF-8 JSON. The encoder and parser grammars deliberately differ to permit recovery from truncated elements.
The fictional object contains a mark string written as "\u001e" in JSON. A parser decodes that escape as a character inside the string, not a record boundary. The visual uses symbolic LF labels for actual newlines and explicitly labels the escape as text.
Read the RFC section ↗