字符编码：？

Question

我正在努力拼凑神秘的字符串-？我在我们的数据库中看到了很多--我相当肯定这是字符编码之间转换的结果，但我不是完全肯定的。

用户可以将文本(或剪切和粘贴)输入到Ext富文本编辑器中。数据被发布到一个保存在数据库中的服务器上，当我在数据库中查看它时，我会看到这些奇怪的字符.

如果我能够找到正确的编码，或者在转换过程中出现了比特或字节丢失，那么

1. 是否有办法将它们解码回原来的含义？
2. 用户正在从MS Word和PDF的多个版本中剪切和粘贴数据。编码是否遵循用户复制的位置？

谢谢

网站为UTF-8，我们正在使用2005；

选择serverproperty(“排序规则”) --服务器默认排序规则。Latin1_General_CI_AS

选择databasepropertyex('xxxx'，‘排序规则’) --数据库默认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

Server 2000中nchar、nvarchar和ntext数据类型的非Unicode等价物列示如下。当Unicode数据通过命令字符串(或称为“语言事件”)插入到这些非Unicode数据类型列中之一时，Server将使用与列的排序规则关联的代码页将数据转换为数据类型。当一个字符不能在代码页上表示时，将被问号(?)替换，表示数据丢失了。数据中意外字符或问号的出现表明您的数据在某一层已从Unicode转换为非Unicode，此转换导致字符丢失。

所以这可能是问题的根源..。在我们的头上也不容易解决。

Answer 1

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

因此，看起来您的文本编码在UTF-8中，被误解为在windows-1252中，并以â的形式显示，后面跟着两个不可打印的字符。

Answer 2

这是一种有理有据的猜测，您只是在体验Word/PDF文档到HTML的天真转换。(Windows1252很可能是utf8 )如果是这样的话，Word文档中2/3的神秘字符可能是“智能引号”，其余的大部分都是它们的其他“智能”编辑功能、elipsis、em破折号等的结果。PDF可能具有类似的功能。

我还会猜测，如果粘贴到ExtJS编辑器后的格式看起来没有问题，那么编码就会被传递。根据文本的使用结果，您可能不需要进行转换。

如果我仍然在基础上，而且我们没有谈论国际化问题，那么我可以补充说，有文字到HTML转换器，但我不知道它们是如何运作的细节，我在评估它们时取得了不同程度的成功。几乎可以肯定，这类转换器涉及到一些小的信息丢失/错误，因为它们需要猜测“智能”字符的原始来源。在我孤立的情况下，只需返回用户并让他们关闭“智能”功能就更容易了。

Answer 3

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

您只需将varchar列更改为nvarchar。

然后更改您在代码中使用的sql参数。