Unicode 型を使用しなければならない場合のルールはありますか?
ほとんどのヨーロッパ言語 (ドイツ語、イタリア語、英語など) は、VARCHAR 列の同じデータベースで問題ないことがわかりました。
私は次のようなものを探しています:
サーバー/データベースの照合はどうですか?
ここで提案されているように、常に NVARCHAR を使用したくない varchar と nvarchar SQL Server データ型の主なパフォーマンスの違いは何ですか?
NVARCHAR を使用する本当の理由は、同じ列に異なる言語がある場合、デコードせずに T-SQL で列に対処する必要がある場合、SSMS でデータを「ネイティブに」表示できるようにする場合、または必要な場合です。 Unicode で標準化します。
データベースをダム ストレージとして扱う場合、VARCHAR (たとえば UTF-8 など) でワイド文字列とさまざまな (可変長であっても) エンコーディングを格納することは完全に可能です。問題は、特に行ごとにコード ページが異なる場合に、エンコードとデコードを試みるときに発生します。これはまた、SQL Server が (潜在的に可変的に) エンコードされた列に対して T-SQL 内でクエリを実行する目的で、データを簡単に処理できないことを意味します。
NVARCHAR を使用すると、これらすべてを回避できます。
比較的制約のない、ユーザーが入力したデータが含まれる列には NVARCHAR をお勧めします。
通常、標準または法律または慣習によって定義および制約される自然キー (車両のナンバー プレート、SSN、シリアル番号、サービス タグ、注文番号、空港のコールサインなど) である列には VARCHAR をお勧めします。また、ユーザーが入力した非常に制約のある (電話番号など) またはコード (ACTIVE/CLOSED、Y/N、M/F、M/S/D/W など) の VARCHAR もあります。それらに NVARCHAR を使用する理由はまったくありません。
したがって、単純なルールの場合:
制約が保証されている場合は VARCHAR、それ以外の場合は NVARCHAR
複数の言語を保存する必要がある場合はいつでも NVARCHAR を使用する必要があります。アジア言語に使用する必要があると思いますが、引用しないでください。
たとえば、ロシア語を varchar に格納する場合の問題は次のとおりです。正しいコード ページを定義している限り問題ありません。しかし、デフォルトの英語の SQL インストールを使用すると、ロシア語の文字が正しく処理されないとしましょう。NVARCHAR() を使用していた場合、それらは適切に処理されます。
わかりました、 MSDNを引用させてください。おそらく私は具体的に説明しましたが、varcar 列に複数のコード ページを格納したくないのですが、できません。
char、varchar、varchar(max)、またはテキスト データ型で格納されているテキスト データを処理する場合、考慮する必要がある最も重要な制限は、単一のコード ページからの情報のみがシステムによって検証されるということです。(複数のコード ページからのデータを保存できますが、これはお勧めしません。) データの検証と保存に使用される正確なコード ページは、列の照合順序によって異なります。列レベルの照合が定義されていない場合は、データベースの照合が使用されます。特定の列に使用されるコード ページを確認するには、次のコード例に示すように、COLLATIONPROPERTY 関数を使用できます。
さらにいくつかあります：
この例は、グルジア語やヒンディー語などの多くのロケールが Unicode のみの照合であるため、コード ページを持たないという事実を示しています。これらの照合は、char、varchar、または text データ型を使用する列には適していません
したがって、グルジア語またはヒンディー語は実際には nvarchar として保存する必要があります。アラビア語も問題です。
遭遇する可能性のあるもう 1 つの問題は、サポートしたいすべての文字がコード ページに含まれているとは限らない場合、データを格納できないことです。多くの場合、Windows は特定のコード ページを "最適な" コード ページと見なします。つまり、そのコード ページを使用してすべてのテキストを処理できるという保証はありません。それは単に利用可能な最高のものです。その一例がアラビア文字です。バルーチ語、ベルベル語、ペルシア語、カシミール語、カザフ語、キルギス語、パシュトー語、シンド語、ウイグル語、ウルドゥー語など、さまざまな言語をサポートしています。これらのすべての言語には、Windows コード ページ 1256 で定義されているアラビア語以外の文字が追加されています。
Unicode を使用している場合は、1 つの列にさまざまな言語を格納できますが、1 つの照合を使用してのみ並べ替えることができることに注意してください。ラテン文字を使用しているが、他のラテン言語のように並べ替えられない言語がいくつかあります。アクセントはこの良い例です。例を思い出せませんが、Y が英語の Y のようにソートされない東ヨーロッパ言語がありました。次に、スペイン語のユーザーが h の後にソートされることを期待するスペイン語の ch があります。
全体として、内部化に対処するときに対処しなければならないすべての問題があります。私の意見では、最初から Unicode 文字を使用し、余分な変換を避け、スペース ヒットを取る方が簡単です。したがって、以前の私の声明。
ギリシャ語では、N 列の型で UTF-8 が必要になります: αβγ ;)
Josh氏は次のように述べています。「....Unicodeを使用する場合は、1つの列にさまざまな言語を格納できますが、1つの照合を使用してのみ並べ替えることができます。ラテン文字を使用しているが、他のラテン言語アクセントはこの良い例です。例を思い出せませんが、Yが英語のYのようにソートされなかった東ヨーロッパの言語がありました。次に、スペイン語のユーザーがソートを求めているスペイン語のchがあります。 hの後。」
私はスペイン語を母国語としています。「ch」は文字ではなく、2つの「c」と「h」です。スペイン語のアルファベットは次のようになります。abcdefghijklmnñopqrstuvwxyz「h」の後に「ch」はありませんが「i」アルファベットは、ñまたはHTML "＆ntilde;"を除いて、英語と同じです。
アレックス
TL;DR;
Unicode - (nchar、nvarchar、および ntext)
非 Unicode - (char、varchar、および text)。
SQL Server の照合順序は、データの並べ替え規則、大文字と小文字、およびアクセントの区別のプロパティを提供します。char や varchar などの文字データ型で使用される照合は、そのデータ型で表現できるコード ページと対応する文字を決定します。
デフォルトの SQL 照合を使用していると仮定すると、次のスクリプトは、印刷されたリストに表示されない場合、1 文字 (合計 256) を格納するために 1 バイトを使用するため、SQL_Latin1_General_CP1_CI_AS収まるすべての記号を出力する必要があります。VARCHARNVARCHAR
declare @i int = 0;
while (@i < 256)
begin
print cast(@i as varchar(3)) + ' '+ char(@i) collate SQL_Latin1_General_CP1_CI_AS
print cast(@i as varchar(3)) + ' '+ char(@i) collate Japanese_90_CI_AS
set @i = @i+1;
end
照合を日本語に変更すると、すべての奇妙なヨーロッパ文字が通常の文字に変わり、いくつかの記号がマークに変わったことに気付くでしょう?。
Unicode は、コード ポイントを文字にマッピングするための標準です。世界のすべての言語のすべての文字をカバーするように設計されているため、異なる文字セットを処理するために異なるコード ページを用意する必要はありません。複数の言語を反映する文字データを格納する場合は、非 Unicode データ型 (char、varchar、および text) ではなく、常に Unicode データ型 (nchar、nvarchar、および ntext) を使用します。
そうしないと、並べ替えが奇妙になります。
誰かが Mysql でこの問題に直面している場合、varchar を nvarchar に変更する必要はありません。列の照合を utf8 に変更するだけです。