最近、SQL Serverでvarchar(120)として格納されているフィールドに関連するエンコーディングに問題がありました。 SSMSでは、varcharは次のように表示されます。
「ジョンベンを殺したのは誰?」
ただし、Pythonに取り込むと、次のように表示されます。
私はこれをPython側から調査しましたが、奇妙なことは何も起こっていません。私の理論では、SQL ServerのvarcharはpythonでSSMSとは異なる方法で表示されるUTF-8文字を受け入れます。 SQL Serverでのエンコードについてはあまり詳しくありません。誰かが私に次のことを知らせてくれますか?
前もって感謝します!
sp_help N'table_name';
を使用して、このVARCHAR
列の照合順序はSQL_Latin1_General_CP1_CI_AS
であることがわかりました。
SQL Serverは、いかなる状況でもUTF-8を格納しません。 NVARCHAR
(NCHAR
およびNTEXT
を含むが、NTEXT
を使用しない)およびXML
、またはコードページに基づくVARCHAR
(CHAR
およびTEXT
を含む)に基づく8ビットエンコーディングを使用して、UTF-16リトルエンディアン(LE)を取得します。 、ただしTEXT
は使用しないでください)。
ここでの問題は、コードがその0x82文字を誤って変換し、UTF-8であると考えていることですが、そうではありません。 0x82の値を持つUTF-8「文字」はありません。これが、「不明」/「�」の置換記号を取得する理由です。シングルバイト0x82の文字がないことを示す次のUTF-8テーブルを参照してください。
O.P.によって述べられているように、問題の列の照合順序はSQL_Latin1_General_CP1_CI_AS
です。これは、8ビットエンコーディングがコードページ1252を使用していること、つまり Windows Latin 1(ANSI) であることを意味します。そして、そのチャート(文字名があるため、一番下のチャートまでスクロールします)の値0x82(「コードポイント」列で「82」を探します)を確認すると、実際には 単一の低い9の引用符 = SSMSに表示されます。その文字は、UTF-8では、3バイトのシーケンスです:E2 80 9A
。
Pythonコードは、SQL Server接続のクライアントエンコーディングをコードページ1252に設定する必要があるか、返された文字列のエンコーディングを変更/変換する必要があります。 fromコードページ1252toUTF-8。
もちろん、これがWebページに表示されている場合は、ページの宣言された文字セットをWindows-1252
に変更できますが、 UTF-8文字が既に存在する場合、ページ上の他の文字と干渉する可能性があります。