Unicode 非常好，非常坏的UTF-8示例测试数据

因此，我们有必要测试XSS过滤，但除了一个测试，我找不到任何有害或错误的测试数据，以确保我的UTF-8代码可以处理错误的数据

---

我在哪里可以找到一些好的嗯。。要测试的坏数据？或者什么是复杂的字符序列

很好地总结了哪些字节序列有效/无效。另一篇值得一读的文章是。

在我的脑海中：

0xff和0xfe

单个高位字节

低字节字符的多字节表示法 -走私的一个好方法是取消早期检查

字节顺序标记 -你会忽视他们吗

另请参见-毫无疑问，还有其他一些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（最大低位代理）

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

• 连续字节前面没有一个初始字节值
• 多字符初始字节后面没有足够的连续字节
• 非最小多字节字符
• 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中是完全多余的

---

还有一些是Unicode格式的。U+FFFE和U+FFFF是两个这样的非字符（每个平面中的最后两个代码点，U+1FFE，U+1FFF，U+2FFE，U+2FFF，…U+10FFFE，U+10FFFF是其他的）。这些通常不应出现在用于数据交换的Unicode数据中，但可以出现在私人使用中。请参阅Unicode常见问题解答链接，了解许多肮脏的细节，包括Unicode中非字符的相当复杂的历史。（，于2013年1月发布，做了它的标题所建议的事情-澄清了非字符的含义。）

请查看您可以使用它将任何文本转换为非常奇怪的UTF8同音字字符串

典型的

Lorem ipsum dolor sit amet，圣职精英，sed do 临时性的劳动和生产许可证

变成这样：

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

---

谢谢你给我这个很棒的清单。我计划现在更详细地检查每一个字符。关于非字符“不应该出现在UTF-8编码数据中”的评论是误导性的。非字符不应该出现在用于开放交换的UTF-8编码数据中，但@SimonKissane：显然，我是被2013年1月发布的现状弄糊涂的众多人之一。Unicode常见问题解答的整个部分都值得一读。谢谢你的信息。（我还要注意，我的评论说“应该”，这与Unicode标准所说的（但不是“说”）是一致的；目的是它们不应该出现在“开放交换”中，而是可以用于“内部使用”。@AdrianMail:Unicode（9.0.0）标准（第125页；PDF文件第54页）中的表3.6。我不确定你在咨询哪些其他来源，但我认为我所说的都包含在那张表中。@JonathanLeffler你是100%正确的，谢谢你的参考。虽然你没有为此付出任何努力，但那页正是我要找的。；）别忘了，知道在哪里找到答案通常和知道答案一样重要。我要警告你，他的测试是基于UTF-8的过时定义，当时允许5字节和6字节的序列，在删除平面17及以上之前。这意味着代码点U+FFFE和U+FFFF在UTF-8中是无效的，而另一个好的情况是什么？我想这是因为这对测试UTF8没有帮助：你没有得到任何接近全套情况的东西，没有“坏”情况，格式对测试也没有帮助。这只是一种获得奇怪角色的方法。你试过了吗？