Nプレフィックス
Nをつけた場合とつけない場合の文字列挿入の挙動はどう異なる？
Nをつけない場合
1. デフォルトのコードページへ変換しようとしてしまう
3. SQL Serverによって使用される前に現在のデータベースのUnicode以外のコードページに変換される
Nをつけた場合
Unicodeで定義された列にUnicodeのまま文字列を入れる
SQL ServerでUnicode文字列定数を扱う場合には、Unicode文字列の前に大文字のNが必ず必要です。これは、SQL Server Books Onlineの「Unicode データの使用」で説明されています。Nプレフィックスは、SQL-92標準のNational Languageを意味し、必ず大文字にする必要があります。Unicode文字列定数の前にNを付加しない場合、その文字列は、SQL Serverによって、使用される前に現在のデータベースのUnicode以外のコードページに変換されます。SQL ServerでUnicode文字列定数を処理するときは、すべてのUnicode文字列の前にNプレフィックスを付ける必要がある(リンク先消滅) Unicode文字列の形式は文字列に似ていますが、先頭にN識別子が付きます (Nは、SQL-92標準でNational Languageを表します)。たとえば、'Michél'は文字定数であり、N'Michél'はUnicode定数です。Unicode定数はUnicodeデータとして解釈され、コードページを使用して評価されることはありません。 Unicode定数は照合順序を持ちます。この照合順序では主に比較と大文字小文字の区別が制御されます。Unicode定数には、現在のデータベースの既定の照合順序が指定されます。COLLATE句が使用されている場合、COLLATE句によって指定された照合順序への変換の前に、データベースの既定の照合順序への変換が引き続き行われます。 詳細については、「Collation and Unicode Support」を参照してください。Unicode文字列定数は、拡張照合順序をサポートします。 そのSQL Serverのテーブルの列はどのような型で定義されているのでしょうか？SQL Serverは文字を格納する際に、その文字はデフォルトのコードページに変換されます。例えばデフォルトコードページがShift_JISであれば、Shift_JISに変換されてから格納されます。よって、Shift_JISに無い文字を挿入しようとした場合、必ず文字化けします。これはテーブルの列がどのような型で定義されているのかとは無関係です。たとえその列がUnicodeで定義されていたとしても、コードページによる変換後の文字が文字化けしているのですから、その文字化けした文字が入ってしまいます。よって、Unicodeで定義された列にUnicodeのまま文字列を入れるためには、Nプレフィックスを使います。別の言い方をすれば、Nプレフィックスを付けることにより、デフォルトのコードページであるシフトJISへの変換を避けることができ、UnicodeのままUnicode型の列に格納することが可能となります。以上より、SQL Serverのテーブルの列がUnicode型でない場合、Unicodeにしかない文字を格納しようとすると文字化けします。また、SQL Serverのテーブルの列がUnicode型の場合でも、デフォルトのコードページがUnicodeでない場合、Unicodeにしかない文字を格納する場合、Nプレフィックスを付けないと文字化けします。