unicode - 非常好，不好 UTF-8 示例测试数据

Question

已结束。此问题正在寻求书籍、工具、软件库等的推荐。它不满足 Stack Overflow guidelines 。目前不接受答案。

---

我们不允许提出寻求书籍、工具、软件库等推荐的问题。您可以编辑问题，以便用事实和引文来回答。

已关闭 6 年前。

Improve this question

所以我们有 XSS cheat sheet测试我们的 XSS 过滤 - 但除了 example benign page我找不到任何邪恶或格式错误的测试数据来确保我的 UTF-8 代码可以处理行为异常的数据。

我在哪里可以找到一些好的呃..坏的数据来测试？或者什么是棘手的字符序列？

Answer 1

另请参阅How does a file with Chinese characters know how many bytes to use per character? - 毫无疑问，还有其他一些问题也会有帮助。

在 UTF-8 中，您可以获得以下类型的字节:

Binary    Hex          Comments
0xxxxxxx  0x00..0x7F   Only byte of a 1-byte character encoding
10xxxxxx  0x80..0xBF   Continuation bytes (1-3 continuation bytes)
110xxxxx  0xC0..0xDF   First byte of a 2-byte character encoding
1110xxxx  0xE0..0xEF   First byte of a 3-byte character encoding
11110xxx  0xF0..0xF4   First byte of a 4-byte character encoding

(最后一行看起来应该是 0xF0..0xF7；但是，Unicode 的 21 位范围 (U+0000 - U+10FFFF) 意味着最大有效值为 0xF4；值为 0xF5..0xF7不能出现在有效的 UTF-8 中。)

查看特定字节序列是否有效 UTF-8 意味着您需要考虑:

• 连续字节出现在预期之外的位置
• 在需要连续字节的地方出现非连续字节
• 字符串末尾有不完整的字符(“预期连续字节”的变体)
• 非最小序列
• UTF-16 代理

在有效的 UTF-8 中，字节 0xF5..0xFF 不能出现。

非最小序列

某些字符有多种可能的表示形式。例如，Unicode 字符 U+0000 (ASCII NUL) 可以表示为:

0x00
0xC0 0x80
0xE0 0x80 0x80
0xF0 0x80 0x80 0x80

但是，Unicode 标准明确指出最后三个替代方案是 Not Acceptable ，因为它们不是最小的。碰巧的是，字节 0xC0 和 0xC1 永远不会出现在有效的 UTF-8 中，因为它们只能编码为 0x00..0x7F 范围内的单字节字符。

UTF-16 代理

在基本多语言平面 (BMP) 中，Unicode 值 U+D800 - U+DFFF 保留用于 UTF-16 代理项，并且不能以有效的 UTF-8 编码。如果它们在 UTF-8 中有效(我强调，它们不是)，那么代理项将被编码:

• U+D800 — 0xED 0xA0 0x80(最小高代理)
• U+DBFF — 0xED 0xAF 0xBF(最大高代理)
• U+DC00 — 0xED 0xB0 0x80(最小低代理)
• U+DFFF — 0xED 0xBF 0xBF(最大低代理)

错误数据

因此，您的 BAD 数据应包含违反这些不同规定的样本。

• 连续字节前面没有初始字节值之一
• 多字符初始字节后面没有足够的连续字节
• 非最小多字节字符
• UTF-16 代理
• 无效字节(0xC0、0xC1、0xF5..0xFF)。

请注意，字节顺序标记 (BOM) U+FEFF，又名零宽度不间断空格 (ZWNBSP)，不能以未编码的方式出现在 UTF-8 中 — 有效的 UTF-8 中不允许出现字节 0xFF 和 0xFE 。编码后的 ZWNBSP 在 UTF-8 文件中可以显示为 0xEF 0xBB 0xBF，但 BOM 在 UTF-8 中是完全多余的。

<小时/>

还有一些noncharacters在统一码中。 U+FFFE 和 U+FFFF 是两个这样的非字符(每个平面中的最后两个代码点，U+1FFFE、U+1FFFF、U+2FFFE、U+2FFFF、... U+10FFFE、U+10FFFF 是其他代码点)。这些通常不应出现在用于数据交换的 Unicode 数据中，但可以出现在私有(private)用途中。请参阅 Unicode FAQ 链接了解许多肮脏的细节，包括 Unicode 中非字符的相当复杂的历史。 ( Corrigendum #9: Clarification About Noncharacters 于 2013 年 1 月发布，正如其标题所示 - 澄清了非字符的含义。)