字符编码：①答案

【问题标题】：Character Encoding: â?字符编码：①
【发布时间】：2011-05-31 15:14:28
【问题描述】：

我正在尝试拼凑神秘的字符串 â??我在我们的数据库中看到了很多 - 我很确定这是字符编码之间转换的结果，但我并不完全肯定。

用户可以在 Ext-Js 富文本编辑器中输入文本（或剪切和粘贴）。数据被发布到一个将其持久化到数据库的 severlet 中，当我在数据库中查看它时，我看到了那些奇怪的字符......

如果我能够发现正确的编码，是否有任何方法可以将它们解码回其原始含义 - 或者在转换过程中是否丢失了位或字节？
用户正在从多个版本的 MS Word 和 PDF 中剪切和粘贴。编码是否跟随用户从哪里复制？

谢谢

网站是 UTF-8 我们使用的是 ms sql server 2005；

SELECT serverproperty('Collation') -- 服务器默认排序规则。 Latin1_General_CI_AS

SELECT databasepropertyex('xxxx', 'Collation') -- 数据库默认 SQL_Latin1_General_CP1_CI_AS

和专栏：

Column_name Type    Computed    Length  Prec    Scale   Nullable    TrimTrailingBlanks  FixedLenNullInSource    Collation
text    varchar no  -1                  yes no  yes SQL_Latin1_General_CP1_CI_AS

的非 Unicode 等价物 nchar、nvarchar 和 ntext 数据类型下面列出了 SQL Server 2000 中的。当 Unicode 数据插入到一个这些非 Unicode 数据类型的列通过命令字符串（否则称为“语言事件”），SQL 服务器将数据转换为数据使用相关的代码页键入与列的排序规则。什么时候字符不能在 a 上表示代码页，它被替换为问号 (?)，表示数据已经丢失。外观意外的字符或问题您数据中的标记表示您的数据已从 Unicode 转换为在某些层非 Unicode，而这转换导致丢失字符。

所以这可能是问题的根本原因……而且我们这方面解决起来并不容易。

【问题讨论】：

缺少可能非常相关的信息：DBMS、DB 字符集、网站字符集、信息语言（英语、法语、日语...）。
您还可以做一个测试：在 Microsoft Word 中输入 –—‘’‚“”„†‡•…‰‹›€™ 并尝试找出进程的哪个点损坏。

标签： javascript sql-server encoding extjs character-encoding

【解决方案1】：

â 在 ISO-8859-1 和 windows-1252 中编码为 0xE2。 0xE2 也是 UTF-8 中三字节序列的前导字节。（具体来说，对于 U+2000 到 U+2FFF 的范围，包括 windows-1252 字符 –—‘’‚“”„†‡•…‰‹›€™）。

因此，您的 UTF-8 编码文本似乎被误解为在 windows-1252 中，并显示为 â 后跟两个不可打印的字符。

【讨论】：

这可以解释两个问号...我希望是 sql server 执行转换...
@dan04 +1！我做了同样的研究，但无法得出结论！你能推荐一种资源来按字节序列而不是 Unicode 代码点查找字符吗？
@akaphenom，恐怕 SQL Server 会采用有效字符并在进行转换之前删除三分之二的信息。它没有将源标识为 UTF-8。
Alvaro 是否建议即使使用 nvrchar，SQL Server 也无法保留 utf-8？
support.microsoft.com/kb/232580 使用 BINARY/VARBINARY/IMAGE 列在服务器上存储实际的 UTF-8 数据。 - 真是一团糟……

【解决方案2】：

这是一个有根据的猜测，您只是在经历将 Word/PDF 文档天真地转换为 HTML 的过程。（windows-1252 到 utf8 最有可能）如果是这种情况，Word 文档中可能有 2/3 的神秘字符是“智能引号”，其余大部分是它们的其他“智能”编辑功能、省略号、破折号的结果等。PDF 可能具有类似的功能。

我还猜测，如果粘贴到 ExtJS 编辑器后的格式看起来没问题，那么编码正在传递。根据文本的最终用途，您可能不需要转换。

如果我还在基地，而且我们不是在谈论国际化问题，那么我可以补充一点，那里有 Word 到 HTML 转换器，但我不知道它们如何操作的细节，而且我在评估它们时取得了喜忧参半的成功。几乎可以肯定，此类转换器涉及一些小的信息丢失/错误，因为它们需要猜测“智能”字符的原始来源。在我的孤立案例中，返回用户并让他们关闭“智能”功能更容易。

【讨论】：

【解决方案3】：

问题很明确：如果浏览器足够好，网页中的表单可以接受您可以键入或粘贴的任何 Unicode 字符。如果字符属于 HTML 字符集，它将按原样发送。如果没有，它将被转换为 HTML 实体。 SQL Server 将执行适当的转换并在字符没有对应字符时静默损坏您的数据。

您无法完全修复它，但您可以采取一种解决方法：让您的 servlet 执行转换。这样您就可以完全控制它。例如，您可以编译一个用户粘贴的最常见的非拉丁字符的列表（智能引号、unicode 空格......），这应该很容易从上下文中识别出来，然后用比@987654323 更好的东西替换它们@。或者您使用为您制作的库。

或者你可以将你的数据库切换到 Unicode :)

【讨论】：

根据您在 dan04 回复中的评论 - 我发现 wiki 相当有趣：en.wikipedia.org/wiki/UTF-8 它非常简单地列出了代码页。不确定这是您要查找的内容
@akaphenom Wikipedia 的文章是一个很好的资源，但它不包含完整的字符表（原因很明显）。我经常使用utf8-chartable.de，但你只能通过Unicode码位搜索。

【解决方案4】：

您正在将每个字符使用 2 个字节的 unicode 数据存储到每个字符使用 1 个字节的 varchar 类型列中。每个字符使用 2 个字节的任何文本在存储在数据库中时都会丢失 1 个字节。

您需要做的就是将 varchar 列更改为 nvarchar。
然后当然改变你在代码中使用的sql参数。

【讨论】：

我还需要更改列的排序规则吗？