web-dev-qa-db-ja.com

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

別のSQLエンジンで設定できるのと同じように、SQL Server 2005/2008でUTF-8関連Collations/Charsetsを設定するオプションを直接見つけることができませんが、SQL Server 2005/2008にはありますラテン語とSQLの照合順序のみ。

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

sql-serversql-server-2008sql-server-2005collationencoding
16
mKorbel

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

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

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

13
gbn

UTF-8は文字セットではなくエンコーディングなので、文字セットとしてインストールすることはできません。

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

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

2
Guffa

SQL Server 2019（現在はベータ版/「コミュニティテクノロジープレビュー」）から、新しい一連のUTF-8照合を介したUTF-8のネイティブサポートがあります。 HOWEVER、UTF-8を使用する機能があればできませんする必要があることを意味します。 UTF-8の使用には、次のような明確な欠点があります。

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

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

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

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

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

SQL Server 2019のネイティブUTF-8サポート：救世主か偽預言者か

1
Solomon Rutzky

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

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

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

0
Halim