Inspect the prefix of generic UTF-16
06The generic UTF-16 label permits either order. A conforming processor examines the first two octets, supports both orders and uses the RFC’s qualified fallback when no marker exists.
Separate processor-capability example: the first two octets are unavailable to inspect. It cannot claim to satisfy the generic-label inspection requirement by blindly guessing an order.
Source for this drawing: RFC 2781 · Read RFC source: § 4.3 ↗
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
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
All UTF-16-labelled processors MUST be able to inspect at least the first two octets and MUST support both byte orders; they MUST NOT assume the order without the prefix check.
- All UTF-16-labelled processors MUST be able to inspect at least the first two octets and MUST support both byte orders; they MUST NOT assume the order without the prefix check.
- Initial FE FF identifies big-endian; FF FE identifies little-endian. Without either marker the text SHOULD be interpreted big-endian.
- The chosen signature examples consume only their explicitly designated initial signature. Inferring order does not itself erase every FEFF character.
The last example is a capability/available-input gate, not a declaration that an empty string is illegal UTF-16. Prefix inspection chooses order; signature removal requires context. General charset-name parsing, transport framing and incomplete-byte recovery are outside this bounded model.
Read the RFC section ↗