encoding - 检测错误的 UTF-8 编码 : list of bad characters to sniff?

Question

我有一个在两个应用程序之间共享的 sql-server 2010 数据库。我们可以控制一个应用程序，另一个应用程序是首先创建数据库的第三方应用程序。我们的应用程序是建立在第三方网络邮件应用程序之上的 CRM。

数据库包含 varchar 列并采用 latin-1 编码。第三方应用程序是用 php 编写的，并不关心正确编码数据，因此它将 utf-8 编码字节填充到 varchar 列中，在那里它们被解释为 latin-1 并且看起来像垃圾。

我们的 CRM 应用程序是用 .Net 编写的，它会自动检测数据库排序规则与内存中字符串的编码不同，因此当 .Net 写入数据库时​​，它会转换字节以匹配数据库编码。

所以......从我们的应用程序写入数据库的数据在数据库中看起来是正确的，但来自第三方应用程序的数据却不是。

当我们的应用程序写入 FirstName = Céline 时，它​​作为 Céline 存储在数据库中

当网络邮件应用程序写入 FirstName = Céline 时，它​​作为 Céline 存储在数据库中

我们的 CRM 应用程序需要显示在任一系统中创建的联系人。因此，我正在编写一个 EncodingSniffer 类，该类查找标记的字符，这些字符表明它是一个编码不良的字符串并对其进行转换。

目前我有:

private static string[] _flaggedChars = new string[] {             "é"         };

which works great for displaying Céline as Céline, but I need to add to the list.

Does anyone know of a resource to get all the possible ways that utf-8 special chars could be interpreted as iso-8859-1?

Thanks

Clarification:Since i am working in .Net. The string, when loaded into memory from the database, is converted to Unicode UTF-16. So, regardless of if it was encoded correctly in the database. It is now represented as UTF16 bytes. I need to be able to analyze thes UTF-16 bytes, and determine if they are screwed up due to utf-8 bytes being stuffed into an iso-8859-1 database.... clear as mud right?

Here is what i have so far. It has cleaned up the display of most misencoded characters, but I am still having trouble with Éfor instance: Éric is stored in the db by webmail as Éric, but after detecting bad encoding and changing it back, it displays as �?ricLooking at a user who has 2500 contacts, hundreds of which had encoding issues, the É is the only thing that isn't displaying correctly...

public static Regex CreateRegex()
    {
        string specials = "ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö";

        List<string> flags = new List<string>();
        foreach (char c in specials)
        {
            string interpretedAsLatin1 = Encoding.GetEncoding("iso-8859-1").GetString(Encoding.UTF8.GetBytes(c.ToString())).Trim();//take the specials, treat them as utf-8, interpret them as latin-1
            if (interpretedAsLatin1.Length > 0)//utf-8 chars made up of 2 bytes, interpreted as two single byte latin-1 chars.
                flags.Add(interpretedAsLatin1);
        }

        string regex = string.Empty;
        foreach (string s in flags)
        {
            if (regex.Length > 0)
                regex += '|';
            regex += s;
        }
        return new Regex("(" + regex + ")");
    }

    public static string CheckUTF(string data)
    {
        Match match = CreateRegex().Match(data);
        if (match.Success)
            return Encoding.UTF8.GetString(Encoding.GetEncoding("iso-8859-1").GetBytes(data));//from iso-8859-1 (latin-1) to utf-8
        else
            return data;
    }

所以:É 被转换为 195'Ã',8240'‰'

Answer 1

您可能应该尝试将字节字符串解码为 UTF-8，如果出现错误，请假设它是 ISO-8859-1。

编码为 ISO-8859-1 的文本很少“碰巧”也是有效的 UTF-8...全部，当然。所以这个方法是相当稳健的。

忽略在实际语言中哪些字符比其他字符出现的频率更高，这里是一个天真的分析，假设每个字符都以相同的频率出现。让我们试着找出有效的 ISO-8859-1 被误认为 UTF-8 导致 mojibake 的频率。我还假设 C1 控制字符(U+0080 到 U+009F)不会出现。

对于字节字符串中的任何给定字节。如果字节接近字符串的末尾，那么您更有可能检测到格式错误的 UTF-8，因为已知某些字节序列的长度不足以成为有效的 UTF-8。但假设字节不在字符串末尾附近:

p(字节解码为 ASCII)= 0.57。这没有提供有关字符串是 ASCII、ISO-8859-1 还是 UTF-8 的信息。

如果此字节是 0x80 到 0xc1 或 0xf8 到 0xff，则它不能是 UTF-8，因此您会检测到它。 p=0.33

如果第一个字节是 0xc2 到 0xdf (p=0.11)，那么它可能是有效的 UTF-8，但前提是它后面跟着一个值介于 0x80 和 0xbf 之间的字节。下一个字节不在该范围内的概率为 192/224 = 0.86。所以这里 UTF-8 失败的概率是 0.09

如果第一个字节是 0xe0 到 0xef，那么它可能是有效的 UTF-8，但前提是它后跟 2 个连续字节。因此，您检测到错误的 UTF-8 的概率为 (16/224)*(1-(0.14*0.14)) = 0.07

与 0xf0 到 0xf7 类似，概率为 (8/224)*(1-(0.14*0.14*0.14)) = 0.04。

在长字符串中的每个字节上，检测到错误 UTF-8 的概率为 0.33+0.09+0.07+0.04 = 0.53。

因此，对于长字符串，ISO-8859-1 静默通过 UTF-8 解码器的概率非常小:每增加一个字符，它大约减半!

这种分析当然假设随机 ISO-8859-1 字符。在实践中，误检测率不会那么好(主要是因为现实世界文本中的大多数字节实际上是 ASCII)，但它仍然会非常好。