编码与字符集

将 Unicode 转义和 HTML 实体还原为文字

使用工具

原本可读文字变成反斜杠或 & 开头的序列，可能并未损坏，只是另一格式的表示。但 Unicode 转义、HTML 字符引用和 URL 百分号编码各有规则，不能混用解码器。

用あ、表情和短 HTML 样式文本检查恢复范围。输出按文字查看，不当 HTML 或 JavaScript 执行，即使看起来像代码也无需运行。始终确认来源格式。

Unicode 转义输入

\u3042

Unicode 解码得到あ，编码则按选项输出 \u3042 或 \u{3042}。两者都指向字符，但接收格式不一定都支持，应区分 JSON 字符串与 JavaScript 码点表示。

日志显示 \u3042 可能只是把あ转义序列化。需确认实际值是六个字面字符，还是日志如此展示一个字符，不能仅凭符号断定存储损坏。

😀 的两种表示

\u{1F600}
\uD83D\uDE00

第一行表示一个码点，第二行表示 UTF-16 代理对。分别解码都得到 😀，两组不代表两个表情。可见字符与 UTF-16 单元的区别也体现在转义表示中。

单独 \uD83D 因代理不成对而失败。不要为缩短或满足长度限制删掉半对，拆断表示单位会制造无效数据。截断策略必须明确单位。

HTML 实体解码输入

Tom &amp; Jerry
&lt;b&gt;hello&lt;/b&gt;

HTML 实体解码得到文字 Tom & Jerry 和 <b>hello</b>，工具并非执行标签使其加粗。查看恢复文字与插入 DOM 的 HTML 不同，解码成功不是安全插入许可。

当前命名引用支持 amp、lt、gt、quot、apos、nbsp，以及数值引用，并非完整 HTML 名称表。不支持的名称原样保留，残留引用可能是范围问题而非数据损坏。

逐层解码结果

&amp;lt; → &lt; → <

首次把 & 还原为 &，留下 <；再解才得到 <。但第二次不一定正确，原文可能就在解释 < 这种写法。应确认序列化层数，不要解到所有转义消失。

HTML 文本嵌在 JSON 时，形式会叠加。应先解析外层 JSON 得到字符串，再另行解 HTML 引用。一次大替换可能改坏引号或分隔符，应为每一步定义小例子与预期。

表示あ的不同规则

Unicode: \u3042
HTML: &#12354; / &#x3042;
URL UTF-8: %E3%81%82

HTML 数值引用以十进制或十六进制表示码点，URL 百分号表示 UTF-8 字节。数字不同未必字符不同。按来源格式选工具；格式不明应查生成方，不只凭外观猜。

当前 Unicode 解码支持 \uXXXX、\u{X}、\xXX，不是包括 \n、\t 的通用字符串解析器。完整 JSON 应用 JSON 整理验证，不要强行替换未支持语法制造成功外观。

解码推进了调查，但把结果放入 HTML 正文、属性、JavaScript 或 URL 时，仍需对应上下文处理。一次转义不是到处安全，目标变化就要重新确认解释规则。

报告应含原序列、解码方式、次数和结果。“解一层 HTML 引用得到预期 &”比“修好乱码”更具体。追踪多余层的来源，比反复转换到外观正确更能防复发。

日志显示 \u3042，可能原值是あ而仅显示转义，也可能用户输入了六个字面字符。是否应解码取决于复制了哪层。读取 JSON 时先确认解析后的值，别为了可读反复替换，而忽略解析器已经处理了转义。

HTML 字符引用也一样。要展示字面示例 <，源文本可能需要 &lt;，解码两次成为 < 就改变了示例。应按已知表示层数解码，而不是一直到看得懂。工具不能推断处理历史，可读不代表回到了正确层。