SQL Server 2005/2008 UTF-8照合/文字セット

16

私はセットに直接オプション（複数可）を見つけることができませんUTF-8rellated Collations/Charsetsと同じで、他のSQLエンジンに設定することも可能ですが、SQL Serverの2005/2008はそこだけでラテン語とSQL照合順序は、SQL Serverの2005/2008に。

これらの照合/文字セットをSQL Serverエンジン（両方のバージョン）2005/2008 Win2008 OSで強制/インストールするオプションはありますか

— mKorbel
ソース

13

いいえ、ありません。SQL ServerはUTF-8をサポートしていません。

Unicodeデータが必要な場合は、列をnvarchar / ncharとして定義する必要があります。SQL Serverは内部的にこれをUCS-2として保存することに注意してください。

これはConnect on MSから要求されており、古いKB記事があることに注意してください。そして、このブログに関する情報も

— GBN
ソース

6

さらに、nvarcharで外部文字とテキストマッチングを行う場合、文字列の前にNでフォーマットされた文字列（N'οἰκονόμον 'など）で一致する必要があります。

— -swasheck

SQL Serverの最近のリリースでは、この動作は変更されていますか？

— セイリア

@Seiyria：いいえ、同じ動作

— gbn

この答えにたどり着いた方は、MS Connectページにアクセスして、MSがSQL ServerでUTF-8をサポートしていることを投票してください。ありがとう：D

— DarcyThomas

@DarcyThomasこれはSQL Server 2019で現実になりつつありますが、明示的に必要がない限り、まだ使用すべきものではありません。詳細については私の答えをご覧ください。

— ソロモンラッツキー

2

UTF-8は文字セットではなく、エンコードであるため、文字セットとしてインストールできません。

Unicodeテキストを保存する場合は、nvarcharデータ型を使用します。

あなたが店のテキストにしたい場合はUTF-8を使用してエンコードされ、あなたは（バイナリデータとして保存しますvarbinary）。

— グッファ
ソース

1

SQL Server 2019（現在はベータ版/「Community Tech Preview」）以降、新しい一連のUTF-8照合によるUTF-8のネイティブサポートがあります。ただし、 UTF-8を使用できるということは、そうする必要があるという意味ではありません。UTF-8の使用には、次のような明確な欠点があります。

最初の128コードポイントのみが1バイトです（つまり、標準の7ビットASCIIセット）
次のほぼ2000コードポイントは2バイトであるため、UTF-16 / NVARCHAR
BMPの残りの63kコードポイント（つまり、U + 0800-U + FFFF範囲）はすべて3バイトであるため、UTF-16 /の同じ文字より1バイト大きくなりNVARCHARます。
ちょうどそれを述べてください：補助文字は両方のエンコーディングで4バイトなので、そこにスペースの違いはありません
UTF-8を使用してスペースを節約できますが、そうすることでパフォーマンスが低下する可能性が非常に高くなります。

実際のところ、UTF-8は、8ビットシステム（通常はASCIIおよびASCII拡張-コードページを中心に設計されている）が何も壊さず、既存の変更を必要とせずにUnicodeを使用できるようにするストレージ形式の設計です実行し続けるためのファイル。UTF-8はファイルシステムとネットワークにとって素晴らしいですが、SQL Server 内に保存されたデータもそうではありません。UTF-16 /として保存された場合、たまたまほとんど（または完全に）標準ASCII範囲内にあるデータは、同じデータよりも少ないスペースで済みNVARCHARます。確かに、それは有用であると証明できる副作用ですが、その決定は、データとこの決定の結果/欠点の両方を理解している誰かによって行われる必要があります。これは一般的な使用のための機能ではありません。

また、（SQL Serverでの）UTF-8の主な使用例は、UTF-8を既に使用しているアプリコード用であり、おそらくUTF-8をサポートする別のRDBMSで既に使用されており、アプリコード/ DBスキーマを更新する必要性または能力はありませんNVARCHARデータ型（テーブル、変数、パラメータなど）を使用するか、文字列リテラルの先頭に大文字の「N」を追加します。目標は、UTF-8が存在する理由と同じです。全体の構造を変更したり、存在するデータを無効にしたりせずにアプリコードでUnicodeを使用できるようにします。これがあなたの状況を説明している場合は、UTF-8を使用しますが、まだいくつかのバグ/問題があることに注意してください。

NVARCHAR大文字の "N"プレフィックス付き文字列リテラルを使用せずにUnicodeを動作させる必要がない場合、UTF-8が利点となる唯一のシナリオは、多くの標準ASCIIデータを許可する必要がある場合Unicode文字、および使用しているNVARCHAR(MAX)（つまり、データ圧縮が機能しないことを意味する）ため、テーブルが頻繁に更新されます（したがって、クラスター化列ストアインデックスはおそらく役に立たないでしょう）。

詳細については、私の投稿を参照してください。

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

— ソロモン・ラツキー
ソース

0

私の場合、アラビア文字を表示する必要があり、私の開発データベースは2014年でした。ここでは、クエリでアラビア文字が表示され、照合はSQL_Latin1_General_CP1256_CI_ASでした

しかし、私の制作はSQL Server 2008で行われ、最終的にはUTF-8文字セットをサポートしませんでした。ここでは、すべてを見ることができました??????????? UTF-8はSQL 2008ではサポートされていないためです。

私がしたことは、すべてのvarcharをnvarcharに変更することであり、アラビア語のcharを適切に見ることができました。また、2008年のデータベース照合をSQL_Latin1_General_CP1256_CI_ASに変更します

— ハリム
ソース