複数の XML 問題をテストするケースの詳細な紹介

SQL サーバーを使用する場合、XML パラメータを扱うことは避けられません。ほとんどの場合、XML はプログラムに利便性をもたらしますが、変数の代入が失敗する場合もあります。 (もちろん、独自の XML が xml spy などのソフトウェアの検査に合格できない場合、これはこの領域の範囲ではありません~)

今日共有する例は非常に簡単です。いくつかの例をテストするだけです

DECLARE @x XML  
 
 
SELECT @x =
&#39;<a>1</a>&#39;
 
SELECT @x =
&#39;<?xml version="1.0" encoding="utf-8"?>
<a>1</a>
&#39;
 
SELECT @x =
N&#39;<?xml version="1.0" encoding="utf-8"?>
<a>1</a>
&#39;
 
SELECT @x =
&#39;<?xml version="1.0" encoding="utf-8"?>
<a>一个人</a>
&#39;
 
SELECT @x =
&#39;<?xml version="1.0" encoding="GBK"?>
<a>单身狗汪</a>

例 1 :

通常、ほとんどの例が表示され、コンパイルはストレスフリーです。変数の代入が通って、あとはクエリと解析が思い通りに行われます~

例2:

コンパイルも通されます ここが一番誤解を招きやすい箇所のようです SQLの代入はいつもそう思っていました。サーバーは

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

のようなヘッドをサポートしていないので、この種のエラーが発生した場合は、ヘッドを削除してくださいとコーダーに指示します (確かに問題はありませんが、理由は間違っています (⊙﹏⊙)b)。実際、XML 型自体はサポートされていますが、ストアド プロシージャを呼び出したり、ステートメントでパラメータを割り当てたりするときのアプリケーション シナリオの問題にすぎません。 SQL Server は、私がこの責任を負わないと言った

例 3:

この例のコンパイルに問題があり、コンパイラがスローする

メッセージ 9402、レベル 16、ステータス 1、8 行目
XML 分析: 1 行目、文字 38。エンコーディングは切り替えることができません

ただし、例 3 と例 2 の違いは、例 3 の代入では Unicode エンコード方式が使用されているのに対し、例 2 ではこれが行われていないことです。一瞬╮(╯_╰)╭。ということで、よくあるデータベースパラメータ転送エラーはこの方法を使っているからなので、騙されてしまいました_(:з」∠)_。つまり、サポートされていないわけではなく、呼び出しメソッドに問題があるだけです

例 4:

メッセージ 9420、レベル 16、ステータス 1、行 9
XML 分析: 行 2、文字 5、不正な XML 文字

咦~別のエラーが報告されました~ 今回は不正な XML 文字です。エンコードは utf-8 で、中国語をサポートしていないようです。したがって、これらの詳細に注意を払わないと、本当に.../(ㄒoㄒ)/~~

例 5:

今回は、コンパイルが正常に成功しました。内部のエンコーディングを GBK エンコーディングに変更します。中国語もサポートできます。もちろんコンパイルも全く問題ありません。

別の例を追加するには、

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

も OK です。一部の繁体字中国語文字も GBK フォント ライブラリでサポートされており、通常、この問題に苦労する必要はありません。特別な記号がない限り、何とも言えません笑

最後に、encoding="utf-8" と encoding="UTF-8" は同等であり、ここでは大文字と小文字は区別されません。ここに注目です…

以上が複数の XML 問題をテストするケースの詳細な紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。