直到最近,我的博客对 PHP 和 MySQL 使用了不匹配的字符编码设置。我已经解决了根本问题,但我仍然有大量充满垃圾的文本。例如,ï
已成为ï
.
有没有软件可以使用模式识别和统计来自动发现损坏的文本并修复它?
例如,看起来U+00EF
(UTF-8 0xC3 0xAF
) 已变为U+00C3 U+00AF
(UTF-8 0xC3 0x83 0xC2 0xAF
)。换句话说,十六进制编码已用于代码点。这种模式发生在我网站上的(看似随机的)非 ASCII 字符上。
直到最近,我的博客对 PHP 和 MySQL 使用了不匹配的字符编码设置。我已经解决了根本问题,但我仍然有大量充满垃圾的文本。例如,ï
已成为ï
.
有没有软件可以使用模式识别和统计来自动发现损坏的文本并修复它?
例如,看起来U+00EF
(UTF-8 0xC3 0xAF
) 已变为U+00C3 U+00AF
(UTF-8 0xC3 0x83 0xC2 0xAF
)。换句话说,十六进制编码已用于代码点。这种模式发生在我网站上的(看似随机的)非 ASCII 字符上。
您引用的示例看起来像老式的 utf8-over-latin1。您可以快速尝试如下查询:
select convert(convert(the_problem_column using binary) using utf8)
看看它是否能解决问题。
只要您的所有数据都经过相同的编码转换序列,并且只要这些转换都不是有损的,那么沿着这些线进行的编码转换就应该起作用 - 您只是在反转其中一些转换的效果。
如果您不能依赖经过同一组编码转换的数据,那么只需扫描数据中的垃圾字符并用预期的字符替换它们,这是有风险的,因为它取决于某人对什么的定义是垃圾,是什么意思。
这个答案中的一些讨论是关于如何使用手工脚本进行这种修复。我不知道有一种工具可以了解所有自然语言和编码,它采用更高级的统计方法来发现可能的问题,并建议使用精确的转换来解决问题——这样的东西会很有用。
您可能想查看正则表达式http://en.wikipedia.org/wiki/Regular_expression。使用它,您可以搜索并替换有问题的字符。
这是 MySQL 正则表达式文档,http://dev.mysql.com/doc/refman/5.1/en/regexp.html。