Fatal编程技术网
  • unicode/
  • Unicode 这种情况是一种奇怪的UTF-8编码转换吗？

Unicode 这种情况是一种奇怪的UTF-8编码转换吗？

unicode encoding character-encoding

Unicode 这种情况是一种奇怪的UTF-8编码转换吗？,unicode,encoding,character-encoding,unicode-normalization,Unicode,Encoding,Character Encoding,Unicode Normalization,我正在使用一个远程应用程序，它似乎在编码方面发挥了一些神奇的作用。应用程序根据用户输入呈现清晰的响应（我将其称为True和False）。我知道两个有效值，它们将呈现“True”，其他所有值都应为“False” 我发现（意外地）有趣的是，提交损坏的值会导致“True” 输入示例： USER10 //gives True USER11 //gives True USER12 //gives False USER.. //gives False OTHERTHING //gives False 因此

我正在使用一个远程应用程序，它似乎在编码方面发挥了一些神奇的作用。应用程序根据用户输入呈现清晰的响应（我将其称为True和False）。我知道两个有效值，它们将呈现“True”，其他所有值都应为“False”

我发现（意外地）有趣的是，提交损坏的值会导致“True”

输入示例：

USER10 //gives True
USER11 //gives True
USER12 //gives False
USER.. //gives False
OTHERTHING //gives False
因此，基本上只有这两个第一个值才能呈现真实的响应

我注意到用户À±0（hex-wise\x55\x53\x45\x52\C0\xB1\x30）被认为是真的，这令人惊讶。 我确实检查了其他十六进制字节，但没有这样的成功。这使我得出一个结论，即\xC0\xB1可以以某种方式转换为0x31（'1'）

我的问题是——这怎么可能发生？该应用程序是否正在执行从UTF-16（或其他）到UTF-8的奇怪转换

非常感谢您的评论/想法/提示。

C0
对于双字节UTF-8序列来说是无效的起始字节，但是如果一个坏的UTF-8解码器接受它，
C0 B1
将被解释为ASCII 31h（字符
1
）

引述：

…（C0和C1）只能用于ASCII字符的无效“超长编码”（即，尝试使用两个字节而不是一个字节对0和127之间的7位ASCII值进行编码…）

谢谢你给我一个很好但很简短的解释：）为什么会有缺点？这难道不是一个有效的问题，一个有效的答案吗？