答案 0 :(得分：3)
â在ISO-8859-1和windows-1252中编码为0xE2。 0xE2也是UTF-8中三字节序列的前导字节。 （具体来说，对于范围U + 2000到U + 2FFF，其中包括windows-1252个字符–—‘’‚“”„†‡•…‰‹›€™）。
所以看起来你有用UTF-8编码的文本被误解为在windows-1252中，并显示为â后跟两个不可打印的字符。
答案 1 :(得分：2)
这是一种有根据的猜测，你只是在经历将Word / PDF文档简单地转换为HTML。 （最有可能是windows-1252到utf8）如果是这种情况，那么Word文档中可能有2/3的神秘字符是“智能引号”，其余大部分都是其他“智能”编辑功能的结果，省略号，em破折号等PDF可能有类似的功能。
我还猜想如果粘贴到ExtJS编辑器后的格式看起来没问题，那么编码就会被传递。根据对文本的最终使用情况，您可能不需要转换。
如果我还在基础，我们不是在讨论国际化问题，那么我可以补充一点，那里有Word到HTML的转换器，但我不知道它们如何运作的细节，我在评估它们时取得了成功。这些转换器几乎肯定会涉及一些小的信息丢失/错误，因为他们需要猜测“智能”字符的原始来源。在我孤立的案例中，更容易回到用户并让他们关闭“智能”功能。
答案 2 :(得分：0)
您将每个字符使用2个字节的unicode数据存储到每个字符使用1个字节的varchar类型列中。任何使用每个字符2个字节的文本在存储在db中时都会丢失1个字节。
您需要做的就是将varchar列更改为nvarchar 然后在代码中更改你正在使用的sql参数。
答案 3 :(得分：0)
问题很明显：如果浏览器足够好，网页中的表单可以接受您可以键入或粘贴的任何Unicode字符。如果角色属于HTML字符集，它将按原样发送。如果没有，它将转换为HTML实体。当角色没有等效角色时，SQL Server将执行适当的转换并以静默方式破坏您的数据。
您无法完全修复它，但您可以解决方法：让您的servlet执行转换。这样你就可以完全控制它。例如，您可以编译用户粘贴的最常见的非Latin1字符列表（智能引号，unicode空间...），这应该很容易从上下文中识别，并用更好的其他内容替换它们{{ 1}}。或者您使用的库可以为您提供此功能。
或者您可以将数据库切换为Unicode：）