Microsoft SQL Serverで文字列の前にNを付ける必要があるのはなぜですか？
T-SQLを学習しています。私が見た例から、varchar()セルにテキストを挿入するには、挿入する文字列のみを書き込むことができますが、nvarchar()セルの場合、すべての例で文字列の前に文字を付けますN.
nvarchar()行を持つテーブルで次のクエリを試してみましたが、正常に機能するため、プレフィックスNは必要ありません。
insert into [TableName] values ('Hello', 'World')
私が見たすべての例で文字列の前にNが付いているのはなぜですか？
このプレフィックスを使用することの長所と短所は何ですか？
NVarcharはUnicodeに使用されます。データベースに多言語データが格納されていない場合は、Varcharを使い続けることができます。例として：N'abc'は、単に文字列をUnicodeに変換します。
デフォルトでは、SQLサーバーは varchar に Windows-1252 文字コードを使用します。ラテン語ベースの言語（英語、ドイツ語、フランス語など）のほとんどの文字が含まれていますが、非ラテン語ベースの言語（ポーランド語、ロシア語など）の文字は含まれていません。 @Pieter Bで述べられているように、nvarcharは、これらの欠けている文字を含む Unicode 用であるため、この問題を回避するために使用されます。これにはコストがかかります。nvarcharを格納するには、varcharの2倍のスペースが必要です。
文字列の前にNを置くと、文字はnvarchar列に配置される前にUnicodeに変換されます。ほとんどの場合、Nをオフにしても問題ありませんが、お勧めしません。申し訳ありませんが、安全であることの方がずっといいです。
MS SQL Serverは他のRDBMSと比較してUTF-8のサポートが不十分であるためです。
MS SQL Serverは、Windows内で使用される規則に従い、「狭い」文字列（C++ではchar、SQLではCHARまたはVARCHAR）は エンコードされた レガシー「コードページ」。コードページの問題は、文字数に制限があり（ほとんどがシングルバイトエンコーディングであり、レポート文字が256文字に制限されている）、単一の言語（または同様のアルファベットを持つ言語のグループ）を中心に設計されていることです。これにより、多言語データの保存が困難になります。たとえば、ロシア語はコードページ 1251 を使用し、ヘブライ語はコードページ 1255 を使用するため、ロシア語とヘブライ語の両方のデータを格納することはできません。
Unicode は、世界中のすべての言語を表すのに十分な、100万文字以上のスペースを持つ単一の巨大なコード化文字セットを使用してこの問題を解決します。いくつかのUnicodeエンコードスキームがあります。 Microsoftは、 歴史的な理由 のため、 UTF-16 を使用することを好みます。 UTF-16は文字列を従来の8ビットではなく16ビットコード単位のシーケンスとして表すため、別の文字タイプが必要です。 MSVC++では、これはwchar_t。 MS SQLではNCHARまたはNVARCHARです。 Nは "national" を表します。Unicodeはinter-国有化、しかしそれはISOの用語です。
他のSQL実装では、VARCHAR列に UTF-8 テキストを格納できます。 UTF-8は可変長（1文字あたり1〜4バイト）エンコーディングで、データがmostlyでBasic Latin範囲にある場合に最適化されています（ASCIIと同じ文字ごとに1バイトとして表されます）が、任意のUnicode文字を表すことができます。したがって、bwalk2895で言及されている「2倍のスペース」の問題を回避できます。
残念ながら、MS SQL Server はUTF-8 VARCHAR をサポートしていないため、代わりにUTF-16を使用する必要があります（ASCIIテキスト）、非Unicodeコードページを使用する（そして外部文字を表す機能を失う）、またはBINARY列にUTF-8を格納する（そしてSQL string functions が正しく機能していないか、GUI DBマネージャーでデータを16進ダンプとして表示する必要があります）。