解码不正确的UTF-8字符串

时间:2014-12-09 07:42:22

标签: character-encoding

我有一些问题,错误编码的数据已经进入数据库。从我的研究事实发现,我已经认识到字符串数据直接从包含非utf8字符的页面复制,我在想ISO-5589-1。

我已经找到了阻止这种情况发生的方法,并且将采取措施在将来阻止这种情况,但现在为了减轻损害,我需要知道这种错误的编码情况是否可以逆转我能掌握预期的数据吗?

在我的搜索中,我发现了预防,但没有解决已经错误编码的数据。

以下是数据摘录:

ÃÆÃÆÃâÃ

看起来似乎并不明显,但将其复制并粘贴到明文编辑器中也会显示未显示的字符。

我对整个字符集都很陌生并且通常不知道你是否需要更多信息?我可以说这是在LAMP堆栈上捕获的,如果这有帮助的话。

提前致谢。

1 个答案:

答案 0 :(得分:0)

这取决于究竟发生了什么。作为mojibake的一个非常快速的入门,只有在使用不适当的编码解释代表特定编码中的文本的 bytes 时才会发生这种情况。例如,这些是表示以UTF-8编码的文本“Fø”的字节:

46 C3 B8 C3 B6

46代表“F”,C3 B8C3 B6分别代表“ø”和“ö”。 不是根据UTF-8规则解释这些字节,而是根据Latin-1规则来代替这些字符:

  

Føö

五个字符,每个字节对应一个Latin-1表。

在这种情况下,误解是“无损”,即UTF-8文本的每个字节在Latin-1中都有意义。反过来并不能保证。以Latin-1编码的“Fø”编码:

46 F8 F6

只有三个字节,一个来自Latin-1表中的每个字母。但是,无法以UTF-8解释此问题,因此字节序列F8 F6在UTF-8中无效。解释器如何处理这种情况;它可以做任何事情,从抛出异常(它可以说应该)到用问号或其他占位符替换字符。在这种情况下,转型是“有损的”;因为它是无效的操作,结果无法保留确切的输入。

要解决这种不幸事故,首先需要弄清楚问题是否“有损”。如果是的话,运气不好。如果它是“无损”的,您可以通过以正确的顺序解释和/或以其他编码保存数据来反转转换。

如果UTF-8数据被解释为Latin-1数据,然后(错误地)从“Latin-1”转换为UTF-8,则可以通过将结果从UTF-8转换为Latin-1来反转并将结果解释为UTF-8。

弄清楚你的情况发生了什么并玩弄。

阅读What Every Programmer Absolutely, Positively Needs To Know About Encodings And Character Sets To Work With Text