避免使用 Microsoft SQLServer 和 Unicode 进行代码更改
如何让 MSSQL 服务器默认接受 Unicode 数据到 VARCHAR 或 NVARCHAR 列中？
我知道您可以通过在要放置在字段中的字符串前面放置一个 N 来完成此操作，但老实说，这在 2008 年似乎有点过时，尤其是使用 SQL Server 2005。
How can you get MSSQL server to accept Unicode data by default into a VARCHAR or NVARCHAR column?
I know that you can do it by placing a N in front of the string to be placed in the field but to by quite honest this seems a bit archaic in 2008 and particuarily with using SQL Server 2005.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
N语法是在 SQL Server 中指定 unicode 字符串文字的方式。如果可能，SQL Server 将使用列的排序规则或数据库的排序规则在两者之间自动转换。
因此，如果您的字符串文字实际上不包含 unicode 字符，则无需指定
N前缀。但是，如果您的字符串文字do包含unicode字符，则需要使用
N前缀。The
Nsyntax is how you specify a unicode string literal in SQL Server.SQL Server will auto convert between the two when possible, using either a column's collation or the database's collation.
So if your string literals don't actually contain unicode characters, you do not need to specify the
Nprefix.But if your string literals do contain unicode characters then using the
Nprefix is necessary.如果这是一个 Web 应用程序，您可能可以让您的 Web 服务器使用 UTF8 作为默认编码。 这样，来回浏览器的所有数据都将是 UTF8，可以插入到 VARCHAR 字段中。 UTF8 是一种让不支持 Unicode 的应用程序处理它的好方法。
If this is a web application, you could probably get your webserver to use UTF8 as it's default encoding. That way all data back and forth to the browser would be UTF8 which can be inserted into VARCHAR fields. UTF8 is a nice way to make applications that are not aware of Unicode deal with it.
他们确实需要一种方法来消除对 N'' 前缀的需要。 “向后兼容需要它”这个论点对我来说毫无意义——当然，让这种行为成为旧应用程序的默认行为，但为我提供一个默认打开 Unicode 字符串的选项（即不需要 N'' 前缀。）我发现我需要对应用程序的大部分区域进行修改以适应 SQL Server 上的 Unicode，而这在 Oracle 和 Postgresql 中不是问题。 加油，微软！
They really need a way to turn off the need for the N'' prefix. The "it's needed for backwards compatibility" argument makes zero sense to me - sure, make that behavior the default for old apps, but provide an option for me to turn on Unicode strings by default (i.e, no N'' prefix required.) I'm discovering that I need to go and mess with large areas of my app to adapt to Unicode on SQL Server when this is NOT an issue in Oracle and Postgresql. C'mon, Microsoft!
虽然只要未完成字符集转换，您就可以将 UTF8 内容简单地存储在 MSSQL Server 的 VARCHAR 字段中，但您应该注意：
应用程序之外的任何管理/报告/数据工具都无法理解您的非英文字符。
特定于语言的处理（例如对名称列表进行排序）可能无法按照每种语言可接受的顺序进行。
特定于语言的处理（例如对
必须小心数据截断。 截断多字节 UTF8 字符通常会导致所涉及字符的数据损坏。 如果输入超过字段长度，则应始终拒绝输入。
禁用字符集转换可能并不像您想象的那么容易。即使您在客户端驱动程序中将其关闭，在某些情况下，如果客户端和使用的 RDBMS 代码页之间存在显着的区域设置差异，它仍然可以被覆盖立即导致数据损坏。
如果您认为这就是全部，您将不得不担心自己欺骗自己。
总而言之，虽然您可能会想走这条路，但这不是一个好主意。 当使用多字节时需要更改代码。
While you can simply store UTF8 content in a VARCHAR field in MSSQL Server as long as charset translation is not done you should be aware that:
No management/reporting/data tools outside of your application will be able to understand your non-english characters.
Language specific handling such as sorting a list of names may not be done in the order acceptable for every language.
Must be careful about data truncation. Truncating a multi-byte UTF8 character ususally causes data corruption for the character involved. You should always reject input if it exceeds the field length.
It may not be as easy as you think to disable charset translation..Even if you turn it off in your client driver it can still be overriden in some cases if there is a significant locale difference between client and RDBMS codepage used which instantly leads to data corruption.
If you think this is all you will have to worry about your fooling yourself.
In summary while you might be tempted to go down this path its not a good idea. Code change is required when going multi-byte.