使用sql server的時候,免不了與xml的參數打交道,xml大多數時候都給我們的程式帶來方便,但是也有些時候會有變數賦值不通過的時候。(當然羅,如果你本身xml都通不過 xml spy 之類軟體的檢查的話那就不是這方面的範圍啦~) 今天分享的例子非常簡單,就測試幾個例子 例子1 : 我們平常見 ...
使用sql server的時候,免不了與xml的參數打交道,xml大多數時候都給我們的程式帶來方便,但是也有些時候會有變數賦值不通過的時候。(當然羅,如果你本身xml都通不過 xml spy 之類軟體的檢查的話那就不是這方面的範圍啦~)
今天分享的例子非常簡單,就測試幾個例子
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" 是等價的,在這裡並沒有區分大小寫。註意是在這裡……
今天就分享了這個小例子~如果有什麼不對,肯定指正