真的很好,坏的UTF-8示例测试数据

所以我们有XSS备忘单来测试我们的XSS过滤 - 但除了示例良性页面之外,我找不到任何恶意或格式错误的测试数据,以确保我的UTF-8代码可以处理行为不端的数据.

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

1> zildjohn01..：

---

查看Markus Kuhn的UTF-8解码器压力测试

---

不要忘记,知道在哪里找到答案通常与了解答案一样重要.

---

我警告你,他的测试基于UTF-8的过时定义,当允许5和6字节序列时,在删除17号及以上的平面之前.这意味着UTF-8中的代码点U + FFFE和U + FFFF无效,而[根据它们不是Unicode联盟](http://www.unicode.org/faq/private_use.html#nonchar8)

2> Jonathan Lef..：

---

另请参阅具有中文字符的文件如何知道每个字符使用多少字节？ - 毫无疑问,还有其他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;但是,21位的Unicode范围(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中不能出现未编码 - 在有效的UTF-8中不允许使用字节0xFF和0xFE.编码的ZWNBSP可以作为0xEF 0xBB 0xBF出现在UTF-8文件中,但是在UTF-8中BOM完全是多余的.

---

Unicode 中也有一些非字符.U + FFFE和U + FFFF是两个这样的非字符(每个平面中的最后两个代码点,U + 1FFFE,U + 1FFFF,U + 2FFFE,U + 2FFFF,... U + 10FFFE,U + 10FFFF等等).这些通常不应出现在用于数据交换的Unicode数据中,但可以出现在私人使用中.有关许多sordid详细信息,请参阅Unicode FAQ链接,包括Unicode中非字符的相当复杂的历史记录.(更正#9:关于非人物的澄清,于2013年1月发布,按其标题所示 - 澄清非人物的含义.)

---

非字符"不应出现在UTF-8编码数据中"的注释具有误导性.非字符不应出现在用于开放交换的UTF-8编码数据中,但是[应该被UTF-8编码器/解码器接受](http://www.unicode.org/faq/private_use.html#nonchar8)

3> Shebuka..：

---

您可以使用Jeffrey Bergamini的这个方便的在线工具将任何文本转换为非常奇怪的UTF8字符串的Homoglyphs.

一个典型的

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

变成这样:

Ḽơᶉëᶆᶆšᶙṁᶙṁḍỡḽǭᵳǐťť,ĉṓɲṩḙċťᶒţûɾɾčįɳġįɳġłįʈ,şếᶑᶑᶁⱺẽḭŭŝḿꝋďṫĕᶆᶈṓɍỉḉḉḑȋᵭṵḑȋᵭṵťťťṷŧḹẩḇꝛꝛȶȶȶ.

---

我想这是因为这对测试UTF8没有什么帮助:你没有得到任何接近整套案例的东西,没有"坏"的情况,格式对测试没有用.这只是获取奇怪角色的一种方式.

---

IMO,这个奇妙的工具可能是一个非常好的"附加价值"的解释,但不适合作为答案自己在SO(也因为页面可能会停止).无论如何,我同意没有解释的-1不是很有建设性.

4> Gumbo..：

---

维基百科的UTF-8文章很好地总结了哪些字节序列有效/无效.另一篇值得一读的文章是W3C I18N FAQ:多语言表格.