我有一个在两个应用程序之间共享的 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 �?ric Looking 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。但假设字节不在字符串末尾附近:
在长字符串中的每个字节上,检测到错误 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/