Microsoft SQL Serverで文字列の前にNを置く必要があるのはなぜですか？

T-SQLを学んでいます。私が見た例から、varchar()セルにテキストを挿入するために、挿入する文字列だけを書くことができますが、nvarchar()セルの場合、すべての例は文字列の前に文字Nを付けます。

nvarchar()行があるテーブルで次のクエリを試しましたが、正常に機能するため、プレフィックスNは必要ありません。

insert into [TableName] values ('Hello', 'World')

私が見たすべての例で、文字列の先頭にNが付いているのはなぜですか？

このプレフィックスを使用することの長所と短所は何ですか？

NVarcharはUnicodeに使用されます。データベースに多言語データが保存されていない場合は、Varcharを引き続き使用できます。例として、N'abc'単に文字列をユニコードに変換します。

デフォルトでは、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内で使用される「狭い」文字列（charC ++ CHARまたはVARCHARSQL）が従来の「コードページ」でエンコードされるという規則に従います。コードページの問題は、文字数に制限があり（ほとんどがシングルバイトエンコーディングで、レポート文字が256文字に制限されている）、単一の言語（または類似したアルファベットを持つ言語のグループ）を中心に設計されていることです。これにより、多言語データの保存が難しくなります。たとえば、ロシア語はコードページ1251を使用し、ヘブライ語はコードページ1255を使用するため、ロシア語とヘブライ語の両方のデータを保存することはできません。

Unicodeは、世界のすべての言語を表現するのに十分な100万文字以上のスペースを持つ単一の巨大なコード化文字セットを使用することにより、この問題を解決します。いくつかのUnicodeエンコードスキームがあります。Microsoftは、歴史的な理由からUTF-16を使用することを好みます。UTF-16は、従来の8ビットではなく16ビットコードユニットのシーケンスとして文字列を表すため、別の文字タイプが必要です。MSVC ++では、これはです。そして、MS SQLでは、またはです。「国家」の略で Unicodeが約あるので、私には後方思われる、相互 -nationalization、それはISOの用語です。wchar_tNCHARNVARCHARN

他のSQL実装では、UTF-8テキストをVARCHAR列に格納できます。UTF-8は可変長（1文字あたり1〜4バイト）のエンコードで、データの大部分がBasic Latin範囲（ASCIIと同じ文字あたり1バイトとして表される）の場合に最適化されますが、任意のUnicode文字。したがって、bwalk2895で言及されている「2倍のスペース」の問題を回避できます。

残念ながら、MS SQL Server はUTF-8をサポートしていないVARCHARため、代わりにUTF-16を使用する（およびASCIIテキストのスペースを浪費する）か、非Unicodeコードページを使用する（および外部文字を表現する機能を失う）または、UTF-8をBINARY列に格納します（また、SQL 文字列関数が適切に動作しない、またはGUI DBマネージャーでデータを16進ダンプとして表示する必要があるなどの不便に対処します）。