gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-04 04:41:58 25 4
gpt4 key购买 nike

我有一个在两个应用程序之间共享的 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'‰'

最佳答案

您可能应该尝试将字节字符串解码为 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),但它仍然会非常好。

    关于encoding - 检测错误的 UTF-8 编码 : list of bad characters to sniff?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10484833/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com