今天分享的例子非常简单，就测试几个例子

DECLARE @x XML  

--1
SELECT @x =
'<a>1</a>'
--2
SELECT @x =
'<?xml version="1.0" encoding="utf-8"?>
<a>1</a>
'
--3
SELECT @x =
N'<?xml version="1.0" encoding="utf-8"?>
<a>1</a>
'
--4
SELECT @x =
'<?xml version="1.0" encoding="utf-8"?>
<a>一个人</a>
'
--5
SELECT @x =
'<?xml version="1.0" encoding="GBK"?>
<a>单身狗汪</a>
'

例子1 :

我们平常见到最多的例子，编译通过无压力。变量赋值通过，随后查询，解析，随你的便~

例子2：

编译也是通过的，貌似这个是最容易引起误会的地方，我之前一直以为sql server 里面的赋值是不支持带

<?xml version="1.0" encoding="utf-8"?>

这种头部的 ，所以平时跟coder说如果出现这种错误，把头部去掉就好了(确实会好，只是原因搞错了(⊙﹏⊙)b)。其实本身xml 类型是支持的，只是我们调用存储过程或者语句里面的参数赋值的时候应用的场景问题而已。sql server表示这锅我不背

例子3：

这个例子编译就有问题了，编译器就抛出

消息 9402，级别 16，状态 1，第 8 行
XML 分析: 行 1，字符 38，无法切换编码

然而例子3和例子2 的差别就是 例子3 的赋值使用了 unicode 的编码方式而例子2并没有这样干，所以例子3 瞬间就跪了╮(╯_╰)╭。所以我们平时发现的数据库传参报错是因为使用了这种方式进行，所以我就一直被忽悠了_(:з」∠)_。所以并不是不支持，只是我们的调用方式有问题

例子4：

消息 9420，级别 16，状态 1，第 9 行
XML 分析: 行 2，字符 5，非法的 xml 字符

咦~又报错啦~这次是非法xml 字符，看起来就是编码是utf-8 的这种不支持中文咯。所以有时候这些细节不注意就真是……/(ㄒoㄒ)/~~

例子5：

编译顺利通过，这次将里面的编码换成GBK编码，就可以支持中文啦。当然编译也是完全没问题罗。

补充另外一个例子

SELECT @x =
'<?xml version="1.0" encoding="GBK"?>
<a>繁体字 龍 _(:з」∠)_</a>
'

也是ok的，一些繁体字在GBK的字库里面也是可以支持，一般也不一定需要纠结这个问题。除非一些特殊符号，就难说了呵呵哒

最后，encoding="utf-8" 和 encoding="UTF-8" 是等价的，在这里并没有区分大小写。注意是在这里……

今天就分享了这个小例子~如果有什么不对，肯定指正