数据通过带有utf-8编码数据的XML进入我的应用程序。用户输入的文本保存在XML中，然后我的应用程序将其读取。
最近，当用户在最后编写一个特殊字符时，它失败了。结果是在XML中，每个字符前面都有一个额外的0x40字符。所以不要接收：
67 6f 20 61 68 65 61 64 (go ahead)
40 67 40 6f 40 20 40 61 40 68 40 65 40 61 40 64 (@g@o@ @a@h@e@a@d)
出了什么问题？
二进制中的0x40是01000000，这使我认为1是某种控制位，它有不同的编码......
答案 0 :(得分：0)
如果我理解正确，你说有效载荷是一串所谓的UTF-8字节。即。
40 62 20 C6 40 62
但这不是有效的UTF-8。 C6破坏了它。在UTF-8中，只有一个字节＆gt;永远不会有效。 0x80的。如果将上面的内容（空间扩展字节）粘贴到我的小转换实用程序中，您可以看到这一点。使用UFT-8字节字段。
http://sodved.awardspace.info/unicode.pl
因此，我怀疑您使用的任何工具/库是遇到无效的UTF-8数据，然后尝试其他方式处理它。 在任何标准编码中，syngle字节都不是C6的卷曲引号。 C6在GSM7bit无效（http://www.developershome.com/sms/gsmAlbetbet.asp）。
所以你真正的问题是它在做什么？你确定有效载荷的编码吗？即使在没有C6的GSM7默认字母表中，它看起来也很奇怪
¡b ¡b
答案 1 :(得分：0)
字节40 62 20 C6 40 62无效utf-8！问题是孤立的初始字节C6。 C6处于双11000110中，因此它是2字节序列的初始字节（因为它以110开头，其余5位是代码点的有效负载位，即110）。但是缺少startbyte的后续字节，所以这是一个非法的2字节序列！可能字节不是utf编码的，C6是ANSI字符e。 G。单个字符。但是C6高于127，因此不是ASCII字符。当编码为utf-8时，每个高于127的字符必须用适当的utf-8序列进行解码。