照合とエンコードの関係

Question

SQL Serverは何らかの形でVARCHAR列のエンコードを強制するか、制御しますか？私が閲覧したドキュメントでは、照合（ソートと比較のルール）とエンコーディング（文字のバイト表現）について明確な区別はありません。

私はすべてがModern_Spanish_CI_AS（データベース、テーブル、列を含む）のSQL Serverインスタンスを持っています。これは、Windows-1252という印象を受けました。データベースには、Windows-1252も使用するアプリケーションが作成されます。最近、UTF-8を使用して誤って構成されたアプリケーションがデータを書き込んでいましたが、驚いたことに、SQL ServerはUnicodeカタログ全体をうれしく受け入れています。テーブルがどのアプリケーションに属しているかを問題にします。

私は六角にキャスト：

SELECT foo, CAST(foo AS VARBINARY(MAX)) AS hex 
FROM ...; 

...私はテーブルが属するどのようなアプリケーションに応じて異なるエンコーディングを参照してください。

• アプリの初回起動：

  €Á 0x80C1 
  

• を

  セカンドアプリ：

  €Á 0xAC20C100 
  

...生キャラクタは正しく表示されます。

SQLクライアントはソースコードをどのように知ることができますか？

---

編集：両方のアプリケーションが同じテーブルに書き込む場合私はこれを見つける：

€Á  0x80C1 
ۈ 0xE282ACC381 

Answer 1

これは単なる推測ですが、私のテストや各種ドキュメントの閲覧によってサポートされているようです。

• レガシー（半角）
• ユニコード（マルチバイト）

レガシーデータで符号化されることが予想される。脇特別なバイナリ照合、SQL Serverは、文字列データの2つのタイプを考慮し基になるWindowsシステムが使用するように設定されているコードページ文字のレパートリーはほとんど同じなので、Unicodeは問題にはなりません。いずれの場合でも、クライアントが使用するドライバはコンバージョンを処理するドライバ（存在する場合）で、通常のドライバ設定にはこの事実を反映するオプションがいくつか含まれています（raw、ANSI、UTF-8など）。このため、SQL Serverには、他のDBMSのように文字セットを選択するための設定や指示はなく、通常の意味で照合順序を選択するだけです（ソートと比較のルール）。

2つの可能なエンコーディングを区別する方法についてとおり、それはすべての列の型によって異なります。

• CHAR、VARCHAR、TEXTは...
• NCHAR ANSI
、 NVARCHAR、 NTEXT意味するものではあり...Unicodeを暗示する

指定された列の種類に不適切なエンコーディングを使用すると、€Ãのようなガベージが表示されます。