すべての SQL Server 2008 R2 照合順序がコード ページに関連付けられている理由。すべての照合順序は unicode ですか?
私たちのデータベースが異なるコードページを使用する複数の言語で使用されている場合、どのように照合を選択するのですか?
ありがとうございました。
すべての SQL Server 2008 R2 照合順序がコード ページに関連付けられている理由。すべての照合順序は unicode ですか?
私たちのデータベースが異なるコードページを使用する複数の言語で使用されている場合、どのように照合を選択するのですか?
ありがとうございました。
CHAR と NCHAR (つまり、非 Unicode と Unicode) は、文字ストレージ エンコーディングを定義します。照合は...照合を定義します(つまり、ソート順と比較規則)。これらは異なる概念ですが、しばしば混同されます。
この混乱は、クライアント ツールがデータのコード ページを選択するためのヒントとして非 Unicode データの照合を使用するという事実から生じます。コード ページ アーキテクチャを参照してください。これは、ADO.Net SqlClient のようなクライアントが、サーバーから受信したシングルバイトのCHAR データをマルチバイトの string
.Net オブジェクトとして適切にエンコードできることを意味します。列のメタデータには使用される照合が含まれるため、クライアントは特定のコード ページに従ってシングルバイト データを解釈する方法を知ることができます。
Unicode (NCHAR) カラムの場合、クライアントはコード ページに従ってデータを解釈する必要はありません。データ自体はすでにマルチバイトであり、クライアントは UCS-2 エンコーディングに従って解釈します ( SQLサーバー)。
ただし、これを実際の照合と混同しないでください:文字を比較するための規則です。照合の操作で説明されているように:
英語を話す人は、文字列 'Chiapas' が昇順で 'Colima' の前に来ることを期待します。ただし、メキシコのスペイン語話者は、「C」で始まる単語のリストの最後に「Ch」で始まる単語が表示されることを期待する場合があります。照合は、これらの種類の並べ替えと比較の規則を指示します。Latin_1 General 照合では、ORDER BY ASC 句で 'Chiapas' が 'Colima' の前にソートされますが、Traditional_Spanish 照合では 'Chiapas' が 'Colima' の後にソートされます。
このソート規則は、すべてのデータ型 (CHAR 非 Unicode または NCHAR Unicode) に適用されます。