varcharデータ型がUnicode値を許可するのはなぜですか？

varchar列を持つテーブルがあります。以下に示すように、商標（™）、著作権（©）およびその他のUnicode文字を許可しています。

Create table VarcharUnicodeCheck
(
col1 varchar(100)
)

insert into VarcharUnicodeCheck (col1) values ('MyCompany')
insert into VarcharUnicodeCheck (col1) values ('MyCompany™')
insert into VarcharUnicodeCheck (col1) values ('MyCompany░')
insert into VarcharUnicodeCheck (col1) values ('MyCompanyï')
insert into VarcharUnicodeCheck (col1) values ('MyCompany')

select * from VarcharUnicodeCheck

しかし、varcharの定義では、Unicode以外の文字列データが許可されています。ただし、Trademark（™）およびRegistered（®）シンボルはUnicode文字です。定義はvarcharデータ型のプロパティと矛盾しますか？最初のリンクと2つ目のリンクを読んだ。しかし、定義がユニコード文字列以外の値のみを許可すると言っているときに、ユニコード文字列を許可する理由を理解できませんでした。

ただし、Trademark（™）およびRegistered（®）シンボルはUnicode文字です。

ここは間違っています。文字列には文字のみが含まれますascii。

以下は、あなたのキャラクターがすべてアスキーであることを示す簡単なテストです（+ extended ascii128から255の間のアスキーコードを持つものもあります）：

declare @VarcharUnicodeCheck table
(
col1 varchar(100)
)

insert into @VarcharUnicodeCheck (col1) values ('MyCompany')
insert into @VarcharUnicodeCheck (col1) values ('MyCompany™')
insert into @VarcharUnicodeCheck (col1) values ('MyCompany░')
insert into @VarcharUnicodeCheck (col1) values ('MyCompanyï')
insert into @VarcharUnicodeCheck (col1) values ('MyCompany')

select *,
        right(col1, 1)as last_char, 
        ascii(right(col1, 1)) as_last_char_ascii
from @VarcharUnicodeCheck;

ここでは、すべての文字が1バイトでエンコードされていることがはっきりとわかります。

はい、それらは純粋なASCII文字ではありませんが、拡張ASCIIです。

ここでは、実際のUnicode文字Trademark(™)とそのコードおよびバイナリ表現を示します。

declare @t table (uni_ch nchar(1), ascii_ch char(1));
insert into @t values (N'™', '™');

select unicode(uni_ch) as [unicode of ™], 
       ascii(ascii_ch) [ascii of ™], 
       cast(uni_ch as varbinary(10)) as [uni_ch as varbinary], 
       cast(ascii_ch as varbinary(10)) as [ascii_ch as varbinary]
from @t;

最後に、Trademark(™)Unicode文字には153ではなく8482コードがあることがわかります。

select nchar(8482), nchar(153)

コメントから、「拡張ASCII」は本当に悪い用語で、実際にはASCIIで定義された標準の0-127コードポイント範囲を超える128-255の範囲の文字/コードポイントをマップするコードページを意味することに同意します。

SQL Serverは、照合を介して多くのコードページをサポートします。基になる照合が文字をサポートしている限り、非ASCII文字をvarcharに格納できます。

SQL Server照合コードページが1250以上の場合、「™」文字をvarchar / char列に格納できます。以下のクエリにこれらがリストされます。

SELECT COLLATIONPROPERTY(name, 'CodePage') AS code_page, name, description
FROM sys.fn_helpcollations()
WHERE COLLATIONPROPERTY(name, 'CodePage') >= 1250
ORDER BY name;

ただし、これらのサブセットのみが「©」文字もサポートしているため、列の照合は両方をサポートするために次のいずれかである必要があります。

SELECT COLLATIONPROPERTY(name, 'CodePage') AS code_page, name, description
FROM sys.fn_helpcollations()
WHERE COLLATIONPROPERTY(name, 'CodePage') IN(
    1250
    ,1251
    ,1252
    ,1253
    ,1254
    ,1255
    ,1256
    ,1257
    ,1258
)
ORDER BY name;

しかし、varcharの定義では、非Unicode文字列データが許可されています。ただし、Trademark（™）およびRegistered（®）シンボルはUnicode 文字です。定義はvarcharデータ型のプロパティと矛盾しますか？

他の答えは間違っていませんが、基本用語の混乱を指摘するのに役立つと思います。この混乱の例として、上記の引用から引用された2つの単語を強調しました。SQL Serverのマニュアルは、Unicodeと非Unicodeのことを話すときにデータ、彼らはされていないの話文字。彼らは、特定の文字を表すバイトシーケンスについて話しています。Unicodeの種類（主な違いNCHAR、NVARCHAR、XML、および非推奨/悪NTEXT）と非Unicodeの種類は（CHAR、VARCHAR、および非推奨/悪はTEXT）何種類のバイトシーケンスのは、彼らが保存することができます。

非Unicode型は、いくつかの8ビットエンコードの1つを格納しますが、Unicode型は、単一の16ビットUnicodeエンコードUTF-16 Little Endianを格納します。他の回答で述べたように、8ビット/非Unicodeエンコードで保存できる文字は、照合によって決定されるコードページによって異なります。他の人は、「文字」のバイト値はそれが見つかったコードページ間で変化する可能性があると指摘していますが、いくつかのEBCDICコードページの1つを扱うとき、同じコードページ内でバイト値も変化する可能性があります（Windowsのバリエーション1252）、これは古いバージョンでのみ使用され、実際に使用されるべきではないSQL Server照合順序（つまり、名前がで始まるものSQL_）。

したがって、定義は正確です。非Unicodeタイプに保存できる文字は常に8ビットです（2つの8ビット値を組み合わせて単一の「文字」として使用する場合でも、バイト文字セット/ DBCSコードページで許可されます）。また、Unicodeデータ型は、2つの16ビット値を組み合わせて単一の「文字」（つまり、補助文字を表すサロゲートペア）として使用する場合でも、常に16ビットです。

また、SQL Serverは、SQL Server 2019の時点でUTF-8エンコードVARCHARおよびCHARデータ型をネイティブにサポートしているため、

VARCHAR「非ユニコード」と呼ぶことはできなくなりました。したがって、2018年9月のSQL Server 2019の最初のパブリックベータ版から、SQL Server 2019 VARCHARより前のバージョンに関して言えば、「8ビットデータ型」と呼ぶ必要があります。この用語は4つのタイプすべてに当てはまりますで使用できるエンコーディングの例VARCHAR：

1. 拡張ASCII
2. 2バイト文字セット（DBCS）
3. EBCDIC
4. UTF-8（ユニコード）

のみTEXT（SQL Server 2005のの非推奨なので、それを使用していない）データ型は、「非Unicode」であり、それはただ専門的だし、「8ビットのデータ型」としてそれに言及正確です。

NVARCHAR、NCHAR、およびNTEXT「UTF-16」または「16ビットデータ型」と呼ぶことができます。Oracleは、「Unicodeのみ」の用語を使用していますNVARCHARが、UTF-8（Unicodeエンコーディング）を使用する可能性を明確に除外していないため、動作しないため、最初の2つのオプション。

新しいUTF-8エンコーディングの詳細については、私の投稿を参照してください。

SQL Server 2019でのネイティブUTF-8サポート：救い主と偽りの預言者？

PSこれらの変更を反映するために、SQL Serverのドキュメントを更新する作業を徐々に進めています。

PPS Microsoftは、質問で参照されているcharおよびvarcharのドキュメントを含む、UTF-8情報でいくつかのページを既に更新しています。フレーズ「non-Unicode」は含まれなくなりました。しかし、それは単なる参考です。これは、誤ってUnicode専用と考えられていた文字を含む非Unicodeエンコーディングに関するものであるため、質問を変更しません。

この質問には、ユニコードとは何かに関する中心的な誤解が含まれています。Unicode文字セットは、UTF-8やUTF-16などのエンコーディングとともに、コンピューターでテキストを表現する多くの方法の1つであり、その目的は他のすべての文字セットとエンコーディングを置き換えることです。「非Unicodeデータ」が「Unicodeに存在しない文字」を意味する場合、この回答で使用したテキストはどれもそのタイプに保存できません。これは、日常英語で使用されるラテンアルファベットと一般的な句読点のすべての文字がUnicodeに含まれています。

テキスト表現は、2つの部分で広く考えることができます。異なる文字（文字、数字、記号など）を参照チャートの数字にマッピングする文字セット。そして、それらの数をビットのパターンとして表現するエンコード（ディスク上、ネットワーク接続など）。ここでは、特定の文字セットのチャートにどの文字がリストされているかという最初の部分に主に関係します。

Unicodeは世界中のすべての文字に数字（「コードポイント」と呼ばれる）を持たせることを目的としているため、Wikipediaのような参照では、文字のUnicode位置を参照情報の標準として参照することがよくあります。ただし、それは他の文字セットにも同じ文字のマッピングがないことを意味しません。

まだ使用されている最も古く、最も単純な文字セット（およびエンコーディング）の1つはASCIIです。ASCIIは7ビットを使用して各文字をエンコードするため、128の異なる文字（0〜127）のマッピングがあります。この除外多くのアクセント文字と共通の記号ので、後符号化は標準的であるこれらの中で注目255に位置128を充填することにより、キャラクタ・セットに追加して、8ビットを使用し、同一の最初の128個の文字をマップISO 8859-1およびISO 8859- 15、およびMicrosoft固有のWindowsコードページ1252。

保存されているように、「Unicode文字列」：だから、MS SQL Serverに戻ってきてnchar、nvarchar、またはntext表すことができ、列をすべて、それがデータを保存するためにエンコードするUnicodeを使用しているため、Unicode文字セットにマッピングされた文字が。「非Unicode文字列」は、のように格納されているchar、varcharまたはtextカラムにマッピングされた文字のみ表すことができ、いくつかの他の符号化を。非Unicode列に格納できるものはすべてUnicode列にも格納できますが、その逆はできません。

格納できる文字を正確に知るには、このMicrosoftリファレンスページで説明されているように、Microsoftが「コードページ」と呼ぶものを指示する使用中の「照合」を知る必要があります。あなたの場合は、前述の非常に一般的なコードページ1252を使用している可能性があります。

あなたが言及した文字はユニコードとコードページ1252の両方に存在します：

• Trademark（™）はUnicodeで8482の位置に、CP1252で153に表示されます。
• Registered（®）は、UnicodeとCP1252の両方の位置174に表示されます