Eri*_* J. 5 sql-server unicode ucs2 utf-8 utf-16
虽然研究在SQL Server数据库中存储大多数英语但有时不存储数据的选项可能会非常大,但我倾向于将大多数字符串数据存储为UTF-8编码.
但是,微软之所以选择UCS-2是因为我并不完全明白是什么导致我猜测这种倾向.SQL Server 2012的文档确实展示了如何创建UTF-8 UDT,但UCS-2的决定可能会遍及SQL Server.
Wikipedia(有趣地指出UCS-2已经过时,支持UTF-16)注意到UTF-8是一个可变宽度字符集,能够编码任何Unicode数据点及其provides the de facto standard encoding for interchange of Unicode text.因此,感觉任何Unicode字符都可以用UTF-8表示,并且由于大多数文本都是英文,因此表示将几乎是UCS-2的两倍(我知道磁盘"便宜",但磁盘缓存不是并且,内存与我正在处理的数据大小不相比.当工作集大于可用RAM时,许多操作会以指数方式降级.
游泳UCS-2流可能会遇到什么问题？
Sol*_*zky 11
在SQL Server数据库中存储大部分英语但有时不存储的数据可能非常大,我倾向于将大多数字符串数据存储为UTF-8编码.
与允许选择编码的其他一些RDBMS不同,SQL Server 仅以 UTF-16(Little Endian)存储Unicode数据,而对于任何代码页,都以8位编码(扩展ASCII,DBCS或EBCDIC)存储非Unicode数据该字段的整理暗示了这一点.
微软选择UCS-2是出于我不完全理解的原因
他们决定选择 UCS-2是有道理的,因为UTF-16是在1996年中期推出的,并在2000年完全指定.许多其他系统也使用(或使用)它(请参阅:https:// en. wikipedia.org/wiki/UTF-16#Usage).他们继续使用它的决定可能更值得怀疑,尽管可能是因为Windows和.NET是UTF-16.UCS-2和UTF-16之间的字节物理布局是相同的,因此从UCS-2升级系统以支持UTF-16应该是纯功能的,无需更改任何现有数据.
SQL Server 2012的文档确实显示了如何创建UTF-8 UDT,
不.通过SQLCLR创建自定义用户定义类型不会以任何方式让您替换任何本机类型.创建处理专用数据的东西非常方便.但是,即使是不同的编码,字符串也远非专业化.为你的字符串数据走这条路线会破坏你系统的任何可用性,更不用说性能,因为你将无法使用任何内置的字符串函数.如果您能够在磁盘空间中保存任何内容,那么这些收益将会被整体性能损失所抹去.存储UDT是通过将其序列化为a来完成的VARBINARY.所以为了做任何事情 字符串比较或排序,在"二进制"/"序数"比较之外,您必须将所有其他值逐个转换回UTF-8,然后进行可以解释语言差异的字符串比较.
此外,"文档"实际上只是示例代码/概念证明的东西.该代码是在2003年(http://msftengprodsamples.codeplex.com/SourceControl/latest#Kilimanjaro_Trunk/Programmability/CLR/UTF8String/CS/UTF8String/Utf8String.cs)中为SQL Server 2005编写的.我看到了一个用于测试功能的脚本,但没有任何涉及表现.
但UCS-2的决定可能会遍及SQL Server.
是的,非常如此.默认情况下,内置函数的处理仅适用于UCS-2.但是从SQL Server 2012开始,您可以使用其中一个排序规则来处理完整的UTF-16字符集(从Unicode版本5或6开始,具体取决于您的操作系统和.NET Framework版本).名称以_SC(即补充字符)结尾.
维基百科...注意到UCS-2已经过时,支持UTF-16
正确.UTF-16和UCS-2都使用2字节代码点.但是UTF-16成对地使用它们中的一些(即代理对)来映射其他字符.用于这些对的代码点在UCS-2中为此目的保留,因此不用于映射到任何可用的符号.这就是为什么您可以在SQL Server中存储任何Unicode字符的原因,它将被正确存储和检索.
维基百科...注意到UTF-8是一个可变宽度字符集,能够编码任何Unicode数据点
正确,虽然误导.是的,UTF-8是可变宽度的,但UTF-16也是微小变量,因为所有补充字符都由两个双字节代码点组成.因此,UTF-16每个符号使用2或4个字节,但UCS-2总是2个字节.但这不是误导性的部分.误导的是任何其他Unicode编码都无法编码所有其他代码点的含义.虽然UCS-2可以保留它们但不能解释它们,但UTF-16和UTF-32都可以映射所有Unicode代码点,就像UTF-8一样.
并且它[ed:UTF-8]为Unicode文本的交换提供了事实上的标准编码.
这可能是真的,但从操作角度来看,它完全无关紧要.
感觉就像任何Unicode字符都可以用UTF-8表示
同样,真实,但完全不相关,因为UTF-16和UTF-32也映射所有Unicode代码点.
由于大多数文本将是英文,因此表示将几乎是UCS-2的两倍
根据具体情况,这很可能是真的,你关注这种浪费的用法是正确的.但是,正如我在导致这个问题(UTF-8支持,SQL Server 2012和UTF8String UDT)的问题中提到的,如果大多数行可以适应VARCHAR但有些需要,您有几个选项可以减少浪费的空间量.是NVARCHAR.最好的选择是启用ROW COMPRESSION或PAGE COMPRESSION(仅限Enterprise Editon!).从SQL Server 2008 R2开始,它们允许非MAX NVARCHAR字段使用"Unicode的标准压缩方案",这至少与UTF-8一样好,在某些情况下甚至比UTF-8更好.NVARCHAR(MAX)字段不能使用这种花哨的压缩,但他们的IN ROW数据可以从常规的ROW和/或PAGE压缩中受益.请参阅以下内容以获取此压缩的说明以及比较数据大小的图表:原始UCS-2/UTF-16,UTF-8和UCS-2/UTF-16,并启用了数据压缩.
SQL Server 2008 R2 - UCS2压缩是什么 - 对SAP系统的影响
另请参阅数据压缩的MSDN页面以获取更多详细信息,因为存在一些限制(除了仅在Enterprise Edition中可用 - 但是对于从SQL Server 2016,SP1开始的所有版本都可用)以及某些压缩可能的情况让事情变得更糟
我知道磁盘"便宜"
该陈述的真实性取决于人们如何定义"磁盘".如果您正在谈论商品零件,您可以在商店购买,以便在您的台式机/笔记本电脑中使用,那么请确定.但是,如果谈到将用于您的生产系统的企业级存储,那么就可以向任何人控制预算,解释他们不应该拒绝您想要的百万美元以上的SAN,因为它"便宜" ";-).
游泳UCS-2流可能会遇到什么问题？
没有我能想到的.好吧,只要你不遵循任何可怕的建议来做一些事情,比如实现UDT,或者将所有字符串转换为VARBINARY或者NVARCHAR(MAX)用于所有字符串字段;-).但是在你可能担心的所有事情中,使用UCS-2/UTF-16的SQL Server不应该是其中之一.
但是,如果出于某种原因,这个没有UTF-8本机支持的问题非常重要,那么您可能需要找到另一个允许使用UTF-8的RDBMS.
更新2018-10-02
虽然这还不是一个可行的选择,但SQL Server 2019在VARCHAR/ CHARdatatypes中引入了UTF-8的原生支持.目前有太多的bug用于它,但如果它们被修复,那么这是一些场景的选项.请参阅我的帖子," SQL Server 2019中的原生UTF-8支持:救世主还是假先知？ ",详细分析了这一新功能.