确实好，坏UTF-8示例性测试数据（闭合）(Really Good, Bad UTF-8 examp

因此，我们有XSS小抄来测试我们的XSS过滤-但除此之外的例子良性页面我无法找到任何邪恶或畸形的测试数据，以确保我的UTF-8编码可以处理missbehaving数据。

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

Answer 1:

退房马库斯·库恩的UTF-8解码器压力测试

Answer 2:

另请参阅如何与中国字符的文件知道有多少字节的每个字符使用？ - 毫无疑问，还有其他的做题，这也将帮助。

在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的（U + 0000的21位范围 - 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 - 字节0xFF和0xFE的在有效UTF-8是不允许的。的编码ZWNBSP可以出现在UTF-8文件作为0xEF为0xBB为0xBF，但BOM完全是多余的在UTF-8。

也有一些noncharacters以Unicode。 U + FFFE和U + FFFF两个这样的noncharacters（和各平面中最后两个代码点，U + 1FFFE，U + 1FFFF，U + 2FFFE，U + 2FFFF，... U + 10FFFE，U + 10FFFF是别人）。这些通常不应出现在用于数据交换的Unicode数据，但可以在私人使用出现。见Unicode的FAQ链接大量的肮脏细节，包括以Unicode noncharacters的相当复杂的历史。（更正＃9：澄清Noncharacters ，这是在2013年1月发布的，做什么标题暗示-明确了非字符的含义。）

Answer 3:

您可以使用由杰弗里·贝尔加米尼这个方便的在线工具，以任何文本转换成同形字的一个非常奇怪的UTF8字符串。

典型