What If Serial Data Contains the End Marker? Byte Escaping Explained

A serial line delivers a stream of bytes. How does the receiving program know where a message ends? One approach reserves a marker. But a measurement or file can contain the same byte value, and sending it unchanged may be mistaken for an ending. Byte escaping resolves that ambiguity. To understand it, separate character reception, packet boundaries and application meaning rather than looking only at baud rate.

Correct characters do not automatically form a packet

A common asynchronous serial interface uses a start bit, data bits and stop bits to identify a character. Once characters reach a program, they form a sequence of bytes. The receiver does not automatically know where a temperature reading begins and ends. Character boundaries and complete message boundaries are separate problems.

An application protocol can use a fixed length, a length field, timing or special markers to delimit messages. Each has conditions and tradeoffs. This article uses SLIP, a simple serial framing example, to explain markers and escaping. It does not suggest that every serial protocol uses SLIP or that an existing protocol should be changed casually.

Feichang’s FCT-1100-F1S1 single-port three-in-one serial device server provides a real serial-to-network context. Bytes forwarded through an interface or network do not automatically gain new business meaning. This article does not infer the product’s internal framing protocol; check the documentation and configuration for its actual capabilities.

Why one marker can have two roles

Suppose both endpoints agree that a particular byte marks the end. On receiving it, a parser delivers the preceding buffered data. The idea resembles punctuation that marks the end of a sentence. Binary content, however, can contain any byte value; no chosen value is automatically absent from the payload.

A measurement record might contain the same value as the end marker. Should the parser treat that occurrence as data or as a boundary? The value alone cannot answer both questions. The sender and receiver need a shared rule that changes how special values are represented on the wire.

Simply forbidding a value restricts what original data can express and may silently change measurements. Replacing copper with fiber does not remove the ambiguity either: optical conversion changes the transmission medium, not the application protocol’s interpretation. Link quality and encoding rules must be checked separately.

Escaping changes the representation, not the data

Escaping can be thought of as a signal to interpret the following byte using an agreed rule. The sender examines the payload and replaces protected byte values with special sequences. The receiver reverses the mapping and should obtain the same original content.

In the SLIP example described by RFC 1055, the hexadecimal value C0 is END and DB is ESC. A C0 inside payload becomes DB DC; a DB inside payload becomes DB DD. An unescaped C0 supplies the actual end boundary. These particular values belong to this example, not to every serial protocol.

Why escape DB as well? It introduces a special interpretation of the next byte. If an original DB were sent without distinction, the next ordinary value might be mistaken for an escape suffix. Protecting both the delimiter and the escape introducer avoids creating a new ambiguity.

Follow a short example from sender to receiver

Take original payload 11 C0 22 DB 33. The two special values cannot be placed directly in the framed stream as ordinary content. Encoding yields 11 DB DC 22 DB DD 33; actual END markers delimit the result so the receiver can distinguish control roles from restored data.

This illustration places C0 both before and after the packet. RFC 1055 discusses sending an END at the start as a way to flush accumulated noise; a zero-length result from consecutive markers should not be delivered as a normal IP packet. Other protocols do not necessarily use identical markers at both ends.

After decoding, the payload’s C0 and DB again become ordinary data. The delimiters themselves are not part of the delivered content. Encoding may increase the number of bytes on the wire. Serial-server counters, captures and application lengths can differ when measured at different layers without proving data loss.

A receiver must remember its current state

The parser cannot always decide each byte in isolation. It must at least distinguish normal reading from waiting for a suffix after an escape introducer. In normal state an END marks the packet boundary; a DB changes the state to waiting for the suffix rather than immediately emitting DB as original data.

In the waiting state, the receiver applies the agreed mapping and returns to normal. The relation between two bytes is maintained by parser state; the bytes do not need to arrive in the same software read. If one read ends with DB and the next begins with DC, the receiver must retain state and complete the conversion.

A real implementation also needs rules for invalid suffixes, buffer limits, empty packets and interruptions. This article does not impose one universal error strategy. If software clears parsing state on every network read, or assumes every read is a message, framing can fail even though the transport delivered all bytes.

A boundary is not an error check or security guarantee

Escaping resolves representation ambiguity. It does not automatically add error detection, retransmission, authentication or encryption. Splitting a stream into packets does not prove that each packet is correct or that its sender is trusted. SLIP itself offers limited services and should not be treated as a general industrial-control security protocol.

Different protocols can also apply checks and escaping at different stages. PPP’s HDLC-like framing has its own flag, transparency and frame-check rules; those details are not identical to SLIP. Mixing marker values, escape suffixes or checking stages can make both sides receive bytes while neither accepts a packet.

Map the locations of original application data, encoding, physical or network transport, decoding and application validation. When investigating errors, identify the observation layer before comparing expected content. A direct byte-for-byte comparison of encoded traffic with decoded application fields can create an apparent fault that does not exist.

Check the agreement with repeatable small samples

Start with the device and protocol documentation. Record versions, interface settings, packetization and capture points. Test ordinary data, data containing the end value, data containing the escape value and consecutive special values. Check both encoded and decoded forms. These are illustrative methods, not a claim that a particular product was measured.

Then test split reads, coalesced reads and interrupted connections where the implementation needs to handle them. Use harmless data in an authorized environment, not example bytes as live production commands. If endpoints use different protocols, establish who performs conversion before repeatedly changing baud rates.

Remember the layers: UART identifies characters, a framing rule identifies messages, and escaping prevents special payload values from being mistaken for control markers. Separating them explains why a port can receive bytes while an application still cannot reconstruct a complete message.

Translated from the Chinese technical article: Read the original Chinese article.