Send UTF-8 and valid Unicode characters

JSON syntax alone does not guarantee an interoperable message.

• I-JSON is short for Internet JSON. RFC7493 defines restricted JSON messages for interoperable Internet protocols, not a new transport, schema language, media type or canonical signature format (§§1–2). Published March2015, it remains Proposed Standard; official metadata lists no Updates, Updated by, Obsoletes or Obsoleted by.
• I-JSON messages MUST use UTF-8 (§2.1). The example {"text":"é"} uses bytes c3 a9 for é, rather than a native Latin-1 byte e9. This is an encoding requirement, not a requirement to escape every non-ASCII character. UTF-8 does not normalize Unicode text.
• Object member names and string values in arrays and object members MUST NOT contain Unicode surrogate code points or noncharacters (§2.1). Escapes are included: an unpaired \uDEAD is invalid there, while the paired \uD800\uDEAD represents the permitted scalar U+102AD. UTF-16 code units in an escape pair are not two prohibited scalar characters.
• Noncharacters include U+FDD0–U+FDEF and the final two code points of each Unicode plane, for example U+FFFE and U+10FFFF. A syntactically valid JSON string can still violate this profile. Escaping a forbidden character does not make it acceptable (§2.1).
• Reported technical erratum6861 proposes removing the published qualification about string values in arrays/object members, to cover an entire top-level string explicitly. It is unverified. This guide states the published scope; its bounded helper additionally rejects forbidden characters in top-level strings as an explicitly stricter local policy. No normalization or character substitution is used.