SQLServer tabeDiff用于同步数据库。在目标表中找到了Â字符。我在这里找不到任何东西，有没有人经历过这个？这是我的情景。它是一个运行它的.bat文件。以下是源table.field值的示例：
SM-33®
在tableDiff之后，它出现在源表中.field：
SM-33®
怎么会发生这种情况？源是SQLServer 2008R2，目标是SQLServer 2005。
答案 0 :(得分：1)
字符®的十进制代码值为174，因此不是ASCII字符，所有字符的代码值都在0到127之间。
®是存储在使用Unicode编码UTF-8编码的文本文件中的字符®，但使用代码页ANSI或{{3}显示为Windows 1252字符}。
所以差异的导出很好，创建的文件（文本文件？）没问题。如果编辑器/查看器不自动检测UTF-8编码，则只需使用UTF-8在文本编辑器/查看器中打开此UTF-8编码文件。
您可以在文本文件的顶部插入，该文件是十六进制EF BB BF，即UTF-8的ISO 8859-1（byte order mark）。这将有助于文本编辑/查看者更快地检测到文本文件是以UTF-8编码的。但是有些应用程序不会将文本文件开头的那3个字节解释为BOM。
现在知道您的问题是由非ASCII字符的不同编码引起的，您可以搜索相关页面。请参阅示例BOM。我建议搜索 Unicode UTF-8 SQL Server 。
答案 1 :(得分：0)
这两个数据库是否使用相同的排序规则？我想这就是造成这个问题的原因。您应该确保它们使用相同的排序规则，然后再次运行tablediff实用程序。
更多信息：
在改变正在使用的生产数据库的整理方面存在一定的风险。您需要确保它不会破坏当前存在的数据。如果所有当前数据都是ASCII，那么你可能没问题，但如果你遇到这样的问题就不会发生这种情况。
这篇文章：Collation Hell (Part 2)讨论了更改数据库整理所涉及的风险。这个technet post描述了您正在使用的两个排序规则之间的差异。
如果不首先在生产数据库的副本上进行测试，我就不会这样做。我从来没有真正需要修改正在使用的数据库的整理，而且我并不是100％在所有整理类型之间的差异，所以我无法给你具体的建议。做一些测试，以确保您不会进一步破坏您的数据。