utf-8 - 如何解码 UTF-8 文本序列\ud83e\udd14

Question

我正在读取包含“\ud83e\udd14”的 UTF-8 文本。阅读规范，它说未使用 U+D800 至 U+DFFF。然而，如果我通过 Microsoft 的 System.Web.Helpers.Json.Decode 之类的解码器运行它，它会产生伸出舌头的面部表情符号的正确结果。该文本源自 Twitter 的搜索 API。

我的问题:这个序列应该如何解码？我正在寻找最终的十六进制序列是什么以及它是如何获得的。感谢您的任何指导。如果我的问题不清楚，请告诉我，我会尽力改进。

Answer 1

您是从一个有趣的角度来看这个问题的。首先要注意的是，您正在处理两个级别的文本:JSON 文档和其中的字符串。

概要:您不需要编写代码来解码它。使用将 JSON 反序列化为对象的库，例如 Newtonsoft 的 JSON.Net .

但是，首先是 Unicode。 Unicode 是一个有一定历史的字符集。与几乎所有字符集不同，1)它有多种编码，2)它仍在增长。几十年前，它的代码点<65636，这被认为是足够的。因此，计划将每个代码点编码为 2 字节整数。它被称为 UCS-2，或者简称为 Unicode 编码。 (微软在 .NET 中坚持使用 Encoding.Unicode，这会导致一些困惑。)

旁白:使用 U+ABCD(十六进制)格式标识用于讨论的代码点。

然后 Unicode 联盟决定添加更多代码点:一直到 U+10FFFF。为此，编码至少需要 21 位。 UTF-32(32 位整数)是一个显而易见的解决方案，但不是很密集。因此，发明了使用可变数量的代码单元的编码。 UTF-8 使用一到四个 8 位代码单元，具体取决于代码点。

但是很多语言在 20 世纪 90 年代都采用了 UCS-2。当然，文档可以随意转换，但如果没有扩展字符集的兼容编码，处理 UCS-2 的代码就会中断。由于 U+D800 到 U+DFFF 未分配，UCS-2 可以保持不变，并且这些“代理代码点”可用于编码新的代码点。结果是 UTF-16。每个代码点都以一个或两个 16 位代码单元进行编码。因此，处理 UCS-2 的程序可以自动处理 UTF-16，只要它们不需要理解它。在同一系统中编写的程序可以被视为正在处理 UTF-16，尤其是对于能够理解它的库。仍然存在诸如字符串长度给出 UTF-16 代码单元数量而不是代码点数量之类的危险，但它在其他方面表现良好。

对于\ud83e\udd14 表示法，语言在其语法或文字字符串中使用 Unicode，需要一种方法来接受非 Unicode 编码的源文件，并且仍然支持所有 Unicode 代码点。它们是在 20 世纪 90 年代设计的，只是以十六进制编写 UCS-2 代码单元。当然，这也扩展到了 UTF-16。这种 UTF-16 代码单元转义语法允许中间系统处理具有非 Unicode 编码的源代码文件。

现在，JSON 基于 JavaScript，而 JavaScript 的字符串是 UTF-16 代码单元的序列。所以 JSON 采用了来自 JavaScript 的 UTF-16 代码单元转义语法。但是，它不是很有用(除非您必须处理无法使用 UTF-8 的中间系统或将它们不能理解的文件视为二进制文件)。旧的 JSON 标准要求系统之间交换的 JSON 文档使用 UTF-8、UTF-16 或 UTF-32 进行编码。新RFC8259需要 UTF-8。

所以，你没有“UTF-8 文本”，你有 UTF-8 的 Unicode 文本编码。文本本身是一个 JSON 文档。 JSON 文档的名称和值是 Unicode 文本，作为允许转义的 UTF-16 代码单元序列。您的文档的代码点为 U+1F914，不是“🤔”，而是“\ud83e\udd14”。

有很多库可以将 JSON 转换为对象，因此您不需要解码 JSON 文档中的名称或值。要手动执行此操作，您需要识别转义前缀并将接下来的 4 个字符作为代理项 extracting the data bits, then combine 的位。它们与来自配对代理的位应该跟随。