避免使用Microsoft SQLServer和Unicode更改代码
时间:2020-03-06 15:04:41 来源:igfitidea点击:
默认情况下,如何使MSSQL Server接受Unicode数据到VARCHAR或者NVARCHAR列中?
我知道我们可以通过在要放置在字段中的字符串前面放置N来做到这一点,但是老实说,在2008年,尤其是在使用SQL Server 2005时,这似乎有些陈旧。
解决方案
如果这是一个Web应用程序,则可能会让Web服务器使用UTF8作为其默认编码。这样,来回浏览器的所有数据都是UTF8,可以将其插入VARCHAR字段。 UTF8是使不了解Unicode的应用程序可以使用它的一种好方法。
" N"语法是我们在SQL Server中指定Unicode字符串文字的方式。
N'Unicode string' 'ANSI string'
SQL Server将在可能的情况下使用列的排序规则或者数据库的排序规则自动在两者之间进行转换。
因此,如果字符串文字实际上不包含Unicode字符,则无需指定N
前缀。
但是,如果字符串文字确实包含Unicode字符,则必须使用N
前缀。
只要我们不完成字符集转换就可以将UTF8内容简单地存储在MSSQL Server的VARCHAR字段中,则应注意:
- 应用程序之外的任何管理/报告/数据工具都将无法理解非英语字符。
- 特定于语言的处理(例如,对名称列表进行排序)可能不会以每种语言可接受的顺序进行。
- 必须小心数据截断。截断多字节UTF8字符通常会导致所涉及字符的数据损坏。如果输入超过字段长度,则应始终拒绝输入。
- 禁用字符集转换可能并不那么容易。即使在客户端驱动程序中将其关闭,即使在客户端和RDBMS代码页之间使用的语言环境存在显着差异,在某些情况下仍可以覆盖该字符集转换,从而导致数据损坏。
- 如果我们认为这是全部,那么我们将不得不担心自己在自欺欺人。
总而言之,虽然我们可能很想走这条路,但这不是一个好主意。转为多字节时,需要更改代码。
他们确实需要一种方法来关闭对N''前缀的需要。 "对于向后兼容,这是必需的"参数对我来说毫无意义,使该行为成为旧应用程序的默认值,但为我提供了一个选项,默认情况下打开Unicode字符串(即,不需要N前缀)。发现在Oracle和Postgresql中这不是问题时,我需要去麻烦我的应用程序的大部分区域以适应SQL Server上的Unicode。来吧,微软!