32 个控制字符 U+0000 至 U+001F 在 JSON 字符串中绝对不允许以原始形式出现。
详见（链接：https://www.ecma-international.org/publications/standards/Ecma-404.htm 文本：ECMA-404）
bq. 所有的字符都可以放在引号内，除非这些字符必须转义：引号（U+0022）、反斜杠（U+005C）和控制字符 U+0000 至 U+001F。
详见（链接：https://tools.ietf.org/html/rfc7159#section-7 文本：RFC 7159）
bq. 一个字符串以引号开头和结尾。所有 Unicode 字符都可以放在引号内，除非这些字符必须转义：引号、反斜杠和控制字符（U+0000 至 U+001F）。
当
`}（默认），所有 32-127 范围之外的字符都使用 {{\uCAFE}} 语法进行转义（或者对于特殊的空白情况，使用命名的转义）。
但是，当
`}
提供给 {{write}} 或 {{write-str}} 函数时，一些控制字符将以原始形式编写，从而导致无效的 JSON。这是不正确的行为；无论用户提供什么选项，库都不应生成违反规范（specification）的 JSON。
This patch escapes the control characters even when
`} is supplied.
对解析功能，我没有添加任何控制字符验证，遵循 Postel 的法律
bq. [TCP] implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.
为什么我担心合规性还要使用 } 呢？好吧，Unicode 是一个好主意，并且与 UTF-8 字符编码搭配得非常好，UTF-8 同样是一个非常好的主意。UTF-8 比 spell out literal escapesiframekachefrom encoding text 更高效。默认（}）不利用 UTF-8 的压缩优势——这是一个权衡，因为与 UTF-8 相比，如果没有预期 UTF-8，ASCII 几乎不可能出错（但你应该预期 UTF-8）。
所以，简而言之，我想利用 UTF-8 并确信我会得到有效的 JSON 输出，而不必清理（不常见）的所有控制字符。
