DLE (Data Link Escape) is ASCII code point 16 (0x10), Unicode U+0010. It is a C0 control character that switched a serial link from data mode into control mode — any byte following DLE was interpreted as a command, not payload. IBM BSC built its framing around this: DLE STX opened a transparent block, DLE ETX closed it, and a literal 0x10 in the payload was escaped by doubling to DLE DLE — one of the earliest byte-stuffing schemes. Modern protocols like PPP and SLIP replaced DLE with cleaner sentinel bytes, but the escape-character concept it introduced persists everywhere. UTF-8 encodes it as the single byte 0x10; Unicode classifies it as Cc (Control) with the alias DATA LINK ESCAPE.
unsigned char payload[] = {0x41, 0x10, 0x42};unsigned char stuffed[] = {0x41, 0x10, 0x10, 0x42}; // escape DLE as DLE DLEunsigned char frame[] = {0x10, 0x02, 0x41, 0x10, 0x10, 0x42, 0x10, 0x03}; // DLE STX ... DLE ETX
DLE (ASCII 16) switches a communication link into a special mode where the following bytes are treated as control commands rather than data. It's like putting air quotes around a conversation — 'the next thing I say has a different meaning.'
When you're sending raw binary data, any byte could accidentally look like a control character. DLE provides an escape mechanism — prefixing a data byte with DLE tells the receiver 'treat this next byte as data, not as a command.'
Same concept, different character. Terminal escape sequences use ESC (ASCII 27) to introduce special commands, while DLE was designed for data-link-level framing in protocols like IBM's BISYNC. Both 'escape' the normal meaning of bytes.
It appears in some industrial and point-of-sale protocols that still use BISYNC-style framing. Modern protocols have largely replaced it with length-prefixed messages or byte-stuffing schemes that don't need a dedicated escape byte.