非常好，坏的 UTF-8 示例测试数据 [关闭]

Posted 2023-02-24

【中文标题】非常好，坏的 UTF-8 示例测试数据 [关闭]

【英文标题】：Really Good, Bad UTF-8 example test data [closed]

【发布时间】：2010-11-22 02:03:40

【问题描述】：

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

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

【问题讨论】：

columbia.edu/kermit/utf8.html 是另一个不错的

cl.cam.ac.uk/~mgk25/ucs/examples/quickbrown.txt

ăѣ????ծềſģȟᎥ??????ǩľḿꞑȯ???????????????????????????ψ????? ???????1234567890!@#$%^&*()-_=+[];:'",<.>/?~????Ḇ????????٤ḞԍНǏ????ƘԸⲘ????০Ρ????Ɍ????ȚЦ????Ѡ????ƳȤѧᖯć????ễ????????Ⴙ????????????ļṃʼnо????????ᵲꜱ????ừ????ŵ????????ź1234567890!@#$%^&*()-_=+[];:'",<.>/?~АḂⲤ????????? ???ꞠꓧȊ?????????ꓡ?????????Ǭ??????????Ŗ????????????????????? ?ꓫŸ??????ả??????ƀ????ḋếᵮℊ????Ꭵ????кιṃդⱺ??????????????????ŧ???ṽẉ? ???ყž1234567890!@#$%^&*()-_=+[];:'",<.>/?~Ѧ????ƇᗞΣℱԍҤ١????К????????ƝȎ????????Ṛ????ṮṺƲᏔꓫ????????????Ꮟçძ????????????ḧ????????ҝɭḿ????????????????ṛ????тú????ẃ⤬????????1234567890!@#$%^&*()-_=+[];:'",<.>/?~??????Β????????? ???????ĢȞỈ??????ꓗʟ????ℕ০????????????ՀꓢṰǓⅤ????Ⲭ???????????????跨度>

【参考方案1】：

Wikipedia’s UTF-8 article 很好地总结了哪些字节序列是有效/无效的。另一篇值得一读的文章是W3C I18N FAQ: Multilingual Forms。

【参考方案2】：

在我的头顶：

0xff 和 0xfe

单个高位字节

低字节字符的多字节表示 - 通过早期检查走私空值的好方法

字节顺序标记 - 你会忽略它们吗？

NFC vs. NFD

【参考方案3】：

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

在 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 标准明确指出最后三个替代方案是不可接受的，因为它们不是最小的。碰巧字节 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 中出现未编码 - 字节 0xFF 和 0xFE 在有效的 UTF-8 中是不允许的.编码的 ZWNBSP 在 UTF-8 文件中可以显示为 0xEF 0xBB 0xBF，但 BOM 在 UTF-8 中完全是多余的。

---

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

【讨论】：

感谢这份出色的清单。我计划现在更详细地检查每一个。

非字符“不应出现在 UTF-8 编码数据中”的评论具有误导性。非字符不应出现在 UTF-8 编码数据中用于开放式交换，但仍应为should be accepted by UTF-8 encoders/decoders

@SimonKissane：显然，我是对Corrigendum #9 的现状感到困惑的人之一，它似乎于 2013 年 1 月发布。 noncharacters 上的 Unicode FAQ 的整个部分都值得一读。谢谢（你的）信息。 （我还要注意，我的 cmets 说“应该”，这与 Unicode 标准所说的一致（但不是“说”）；目的是它们不应该出现在“开放交换”中，但可以用于“内部使用” '.)

@AdrianMaire：参见 Unicode (9.0.0) 标准的Chapter 3 中的表 3.6（第 125 页；PDF 文件的 p54）。我不确定您正在咨询哪些其他来源，但我认为我所说的内容已包含在该表中。

@JonathanLeffler 你是 100% 正确的，谢谢你的参考。

【参考方案4】：

查看Markus Kuhn’s UTF-8 decoder stress test

【讨论】：

虽然您没有为此付出任何努力 - 该页面正是我想要的。 ;)

不要忘记，知道在哪里可以找到答案通常与知道答案一样重要。

我警告你他的测试是基于一个过时的 UTF-8 定义，当 5 和 6 字节序列被允许，在平面 17 及以上被删除之前。这意味着代码点 U+FFFE 和 U+FFFF 在 UTF-8 中无效，当 per the Unicode consortium they are not

【参考方案5】：

您可以使用this handy online tool from Jeffrey Bergamini 将任何文本转换为非常奇怪的 UTF8 同形文字字符串。

典型的

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua。

变成这样：

Ḽơᶉëᶆ ȋṕšᶙṁ ḍỡḽǭᵳ ʂǐť ӓṁệẗ, ĉṓɲṩḙċťᶒțûɾ ấɖḯƥĭṩčįᶳġ ḝłįʈ, ♣ ẽḭŭŝḿꝋď ṫĕᶆᶈṓɍ ỉñḉīḑȋᵭṵńť ṷŧ ḹẩḇőꝛế éȶ đꝍꞎôꝛȇ ᵯáꞡᶇā ą.

【讨论】：

我想这是因为这对测试 UTF8 没有真正的帮助：你没有得到任何接近完整案例的东西，没有“坏”案例，格式对测试。这只是获取奇怪字符的一种方法。

你试过了吗？那台发电机不是为了好玩。它为您提供完整 UTF-8 范围内的字符，并且因为它们与实际字符奇怪地相似，您可以“看到”哪些字符给您带来问题。在我发布的示例中，我的 iPhone 将 6 个字符呈现为盒装问号。

IMO，这个很棒的工具可能是一个非常好的解释“附加值”，但它本身不适合作为 SO 中的答案（也因为该页面可能已停止使用）。无论如何，我同意没有解释的 -1 不是很有建设性。

所以这是“好，好 utf-8 示例测试数据”......值得一票，因为它相关，IMO