从错误地保存为 UTF-8 的数据中重建 Windows-1252 字符答案

【问题标题】：Reconstructing Windows-1252 characters from data incorrectly saved as UTF-8从错误地保存为 UTF-8 的数据中重建 Windows-1252 字符
【发布时间】：2011-12-23 08:38:13
【问题描述】：

我正在处理使用 Java HtmlUnit 采样的数据。网页使用 Windows-1252 编码，但检索到的响应好像页面被编码为 UTF-8（即，当调用 HtmlUnit WebResponse 对象上的 getContentAsString 时，指定了 UTF-8 编码，而不是推迟到服务器中指定的编码回复）。有没有办法扭转这个过程，从错误标记的 UTF-8 字符数据中重建原始 Windows-1252 数据？

关于这个主题的大多数其他问题都与识别文件类型或从一种流类型转换为另一种流类型以首先正确编码字符有关。这里情况不同。我不相信 iconv 之类的实用程序会起作用，因为它们希望流已经正确地保存在它们的源编码中。

【问题讨论】：

标签： unicode utf-8 character-encoding windows-1252

【解决方案1】：

可能不会。如果 Windows-1252 编码的文本被误认为是 UTF-8，则所有非 ASCII 代码点都会被损坏，因为 UTF-8 处理这些代码点的方式。仅当您非常幸运，并且所有非 ASCII 码点都成对或三元组出现时，完全有机会转换为真正的 Unicode 码点，您才能逆转这个过程。

但是你很不走运。

【讨论】：

这取决于损坏的代码点的存储方式。我没有使用 HtmlUnit 的经验，但我想先看看结果的一些十六进制转储，然后才能断定这是不可能的。
这未必是不可能的。如果负责解码 (assumed) utf-8 的实体很古怪，它可能会以二进制方式“按原样”保留错误的 utf-8 代码点，但这将是一个非常糟糕的解码器。我的猜测是结果充满了方框或问号......
HtmlUnit 使用 Java 的编码并且它自己没有做任何特别的事情（不像 icu4j）。因此，字符集的修改将取决于 Java rt 库的恶意，我希望这些库非常可靠。如果有人对这些信息有进一步的建议，将不胜感激。