Microsoft SQLServerとUnicodeによるコード変更の回避

Question

MSSQLサーバーがデフォルトでVARCHARまたはNVARCHAR列にUnicodeデータを受け入れるようにするにはどうすればよいですか？

フィールドに配置する文字列の前にNを配置することで実行できることはわかっていますが、正直なところ、2008年、特にSQL Server 2005の使用に関しては少し古風に思えます。

Answer 1

N 構文は、SQL ServerでUnicode文字列リテラルを指定する方法です。

N'Unicode string'
'ANSI string'

SQL Serverは、可能な場合、列の照合またはデータベースの照合を使用して、2つの間で自動変換します。

したがって、文字列リテラルに実際にUnicode文字が含まれていない場合は、 N プレフィックスを指定する必要はありません。

ただし、文字列リテラルに do にUnicode文字が含まれている場合は、 N プレフィックスを使用する必要があります。

Answer 2

これがWebアプリケーションの場合、WebサーバーがデフォルトのエンコーディングとしてUTF8を使用するようにすることができます。このようにすると、ブラウザーとやり取りするすべてのデータはUTF8になり、VARCHARフィールドに挿入できます。 UTF8は、Unicodeを認識していないアプリケーションにUTF8を処理させる優れた方法です。

Answer 3

N ''プレフィックスの必要性をオフにする方法が本当に必要です。 「後方互換性のために必要です」引数は私には意味がありません-確かに、その動作を古いアプリのデフォルトにしますが、デフォルトでUnicode文字列をオンにするオプションを提供します（つまり、N ''プレフィックスは必要ありません）これがOracleとPostgresqlで問題にならない場合、SQL ServerのUnicodeに適応するために、アプリの大部分をいじってください。さあ、Microsoft！

Answer 4

文字セットの変換が行われない限り、UTF8コンテンツをMSSQL ServerのVARCHARフィールドに単純に格納できますが、次のことに注意する必要があります。

1. アプリケーション外の管理/レポート/データツールは、英語以外の文字を理解できません。

2. 名前のリストのソートなどの言語固有の処理は、すべての言語で許容される順序で実行されるとは限りません。

3. データの切り捨てに注意する必要があります。通常、マルチバイトUTF8文字を切り捨てると、関連する文字のデータが破損します。入力がフィールド長を超える場合は、常に入力を拒否する必要があります。

4. 文字セットの変換を無効にするのは思ったほど簡単ではないかもしれません。クライアントドライバでオフにしても、クライアントとRDBMSのロケールに大きな違いがある場合は、それをオーバーライドできます。すぐにデータ破損につながるコードページが使用されます。

5. これがすべてだと思うなら、あなたがあなた自身をだますことを心配する必要があります。

要約すると、この道をたどりたくなるかもしれませんが、それは良い考えではありません。マルチバイトに移行するにはコードの変更が必要です。