Keep a text FEFF separate from a signature
07A byte-order mark is an initial signature in a chosen context. RFC2781 assigns a different meaning to FEFF inside text, and warns about concatenating independently signed strings.
With explicit metadata that each initial FEFF is a signature, consume those two prefixes before joining. The resulting units0041 0042 represent AB. Genuine text FEFF values remain intact.
Source for this drawing: RFC 2781 · Read RFC source: § 3.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
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
FEFF away from the beginning MUST have the RFC’s zero-width non-breaking-space semantics and MUST NOT be treated as a new byte-order mark.
- FEFF away from the beginning MUST have the RFC’s zero-width non-breaking-space semantics and MUST NOT be treated as a new byte-order mark.
- An initial FEFF MAY instead be a genuine text character, such as at the beginning of a substring. It is not always a signature.
- When joining independently signed strings, remove the known signatures at their respective starts; do not indiscriminately delete genuine FEFF text. Stripping can affect counts and digital signatures at another layer.
This teaches RFC2781’s historical FEFF text semantics, not a recommendation to insert FEFF for word joining today. No automatic signature detection/removal is inferred for arbitrary chunks; the examples carry explicit signature metadata.
Read the RFC section ↗