使用sql server的時候，免不了與xml的參數打交道，xml大多時候都會為我們的程式帶來方便，但是也有些時候會有變數賦值不通過的時候。 （當然羅，如果你本身xml都通不過xml spy 之類軟體的檢查的話那就不是這方面的範圍啦~）
今天分享的例子非常簡單，就測試幾個例子
DECLARE @x XML SELECT @x = '<a>1</a>' SELECT @x = '<?xml version="1.0" encoding="utf-8"?> <a>1</a> ' SELECT @x = N'<?xml version="1.0" encoding="utf-8"?> <a>1</a> ' SELECT @x = '<?xml version="1.0" encoding="utf-8"?> <a>一个人</a> ' 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" 是等價的，在這裡並沒有區分大小寫。注意是在這裡…
以上是詳細介紹測試幾個xml的問題的案例的詳細內容。更多資訊請關注PHP中文網其他相關文章！
