SQL Serverの文字列型varchar nvarchar
もう一度読み直し
文字列の同値性確認
仕様は決まっているが、実装によりけり
SQL Serverのvarchar
長い方の文字列と短い方の文字列があり、短い方の文字列の末尾を空白で埋める
二つの文字列が完全に一致するか確認する
Oracle・PostgreSQLはこの空白埋めはやっていない
切り出した
やってみる
連結する
参考
公式
SQL Server 2005のデータ型
多言語のTransact-SQL
書籍
他
整理用に公式をコピペ
Microsoft SQL Server の各照合順序にはコード ページがあり、char 型、varchar 型、text 型の値で、どのビット パターンがどの文字を表すかを定義しています。個別の列や文字定数を異なるコード ページに割り当てることができます。
SQL Server では次のデータ型が Unicode データをサポートします。
nchar
nvarchar
ntext
注意
これらのデータ型のプレフィックスnは、National(Unicode)データ型に関するISO標準に由来しています。
次の点を除き、nchar、nvarchar、ntext は、それぞれ char、varchar、textと同じです。
Unicodeの方が広範な文字をサポートします。
Unicode文字の方が格納に多くの記憶域を必要とします。
char型列とvarchar型列の最大サイズは8000文字であるのに対し、nchar型列の最大サイズは4000文字です。
nvarchar型列の最大サイズは、2^31バイトで、max指定子を使用して指定します。nvarchar(max) の詳細については、「大きな値のデータ型の使用」を参照してください。
Unicode定数は先頭にNを付けて指定します。つまり、「N'Unicode文字列'」と指定します。
UnicodeデータはUnicode標準により規定された文字セットを使用します。Unicode列に使われるUnicode照合順序は、大文字と小文字の区別、アクセントの区別、かなの区別、文字幅の区別、バイナリなどの属性を基に指定されます。
国際的なデータベースの文字データを管理する最も簡単な方法は、char、varchar、text などの非 Unicode データ型を使用するのではなく、常に nchar、nvarchar、nvarchar(max) などの Unicode データ型を使用することです。それによって、クライアントには、他のすべてのクライアントと同じ文字でデータが表示されます。国際的なデータベースを使用するすべてのアプリケーションで、非 Unicode データ型の変数の代わりに Unicode データ型の変数を使用すれば、システム内で文字の変換を行う必要がなくなります。
ポイントとそれが表す文字は、視覚表現に使用される"グリフ"とは別のものです。ISO規格 (ISO/IEC 9541-1) では、グリフは "特定のデザインに依存しない認識可能な抽象的グラフィック シンボル" と定義されています。したがって、文字は必ずしも常に同じグリフあるいは一意のグリフで表現されるとは限りません。選択した書体によって、特定の 1 つのコードポイントまたは一連のコード ポイントを表現するのに使用されるグリフが決まります。 Unicodeテキスト型: nchar、nvarchar、nvarchar(max)、ntext
SQL-92仕様では、"N"("国別"データ型の意味)で始まるデータ型が定義されています。ただし、この仕様は、Unicodeにこのデータ型を使用することを明確に求めていません。これらのデータ型の実際の定義は、データベースのプラットフォームまたは開発者に委ねられています。SQL Server 2000およびSQL Server 2005では、これらのデータ型は、UnicodeエンコードのUCS-2と同等であると定義されています。ただし、他のデータベース サーバーを使用する場合、この"N"データ型が特にUnicodeを意味しているわけではないことを知っている必要があります。"N"データ型をUnicodeとして定義するのはMicrosoft SQL Serverの場合のみです。 エンコード
Unicodeは、文字にコードポイントを割り当てますが、メモリ、データベース、Webページでのデータの表現方法を実際に指定するわけではありません。ここで、Unicodeデータのエンコードが効力を発揮します。Unicodeのエンコードにはさまざまなものがあります。ほとんどの場合は Unicodeデータ型を選択するだけでよく、その詳細を気にする必要はありません。ただし、次のような場合にはエンコードを理解することが重要になります。 Unicodeを別の方法でエンコードする可能性があるアプリケーションを扱う場合
他のプラットフォーム(Microsoft Windows以外)またはWebサーバーにデータを送信する場合
他のエンコードに対してデータのインポートやエクスポートを行う場合
Unicode規格では、UTF-7、UTF-8、UTF-16、UTF-32 など、単一の文字セットの複数のエンコードを定義しています。ここでは、次の一般的なエンコードについて説明します。
通常、SQL Serverでは、UCS-2エンコード体系でUnicodeが格納されます。ただし、多くのクライアントでは、UTF-8などの他のエンコード体系でUnicodeが処理されます。Web ベース アプリケーションでは、このシナリオが頻繁に発生します。Microsoft Visual Basicアプリケーションでは、文字列はUCS-2エンコード体系で処理されます。したがって、Visual BasicアプリケーションとSQL Serverのインスタンスとの間では、エンコード体系の変換を明示的に指定する必要はありません。 SQL Server 2005は、Unicode(UTF-16)を使用してXMLデータをエンコードします。xml型の列のデータは、ドキュメントの順序や再帰構造などのXMLモデルの特性をサポートするために、バイナリラージオブジェクト(BLOB)として内部形式で格納されます。したがって、サーバーから取得されるXMLデータはUTF-16で取り出されます。データ取得のために異なるエンコードが必要な場合、アプリケーションは、取得されたUTF-16データに対して変換を行う必要があります。SQL Server Books Onlineの「XMLの推奨事項」には、varchar(max)列から取得された XMLデータのエンコードを明示的に宣言する方法の例が示されています。 UTF-16エンコードが使用される理由は、UTF-16エンコードが2バイトまたは4バイト文字を処理することが可能であり、バイト指向のプロトコルに従って処理されるためです。これらの特性により、UTF-16は、使用しているエンコードおよびバイト記述体系が異なるコンピュータ間での通信に適しています。一般的にXMLデータはネットワーク間で広く共有されるので、XMLデータをクライアントにエクスポートする場合はデータを既定のUTF-16 のままでデータベースに保存するのが適切です。 UCS-2はUTF-16の前身です。UCS-2とUTF-16の相違点は、UCS-2はすべての文字を16ビット値(2バイト)で表現する固定長のエンコードであるため補助文字をサポートしないという点です。UCS-2はUTF-16としばしば混同されます。UTF-16 は、Microsoft Windows オペレーティング システム (Windows NT™、Windows 2000、Windows XP、Windows CE) で内部的にテキストを表現するのに使用されますが、UCS-2 は、UTF-16 よりも多くの制限があります。 ** 注** **: **Windows オペレーティング システムでの Unicode の使用に関する最新情報については、Microsoft Developer Network (MSDN) ライブラリの「Unicode」を参照してください。Windows アプリケーションでは内部的に UTF-16 を使用し、他の形式を使用する必要がある場合にのみインターフェイス上の "シン レイヤ" の一部として変換を行うことをお勧めします。
Microsoft SQL Server 2000 および Microsoft SQL Server 2005 において Unicode で格納される情報には、UCS-2 エンコードが使用されます。UCS-2 エンコードは、使用される文字に関係なく、すべての文字を 2 バイトで格納します。したがって、ラテン文字の "A" は、キリル文字の Sha (Ш)、ヘブライ文字の Lamed (ל)、タミール文字の Rra (ற)、日本語のひらがなの E (え) と同じように扱われます。そして、それぞれが一意のコード ポイントを持ちます (これらの文字の場合、コード ポイントはそれぞれ U+0041、U+0248、U+05DC、U+0BB1、U+3048 です。4 桁の各 16 進数は、UCS-2 で使用される 2 バイトを表します)。
UCS-2 は、65,536 のコード ポイントのエンコードしか行えないため、補助文字はネイティブに処理されません。その代わりに、補助文字は未定義の Unicode サロゲート文字のペアとして処理され、これらのサロゲート文字がペアになったときに補助文字が定義されます。ただし、SQL Server では、損失や破損の危険性なく補助文字を格納できます。カスタム CLR 関数を作成すれば、サロゲート ペアを使用できるように SQL Server の機能を拡張できます。サロゲート ペアおよび補助文字の使用の詳細については、このホワイト ペーパーの「補助文字とサロゲートペア」を参照してください。
注 **: **補助文字は、"補助コード ポイントを持つ Unicode でエンコードされた文字 " と定義されています。補助コード ポイントの範囲は U+10000 ~ U+10FFFF です。
UTF-8
UTF-8 は、コンピュータ上のバイト順に依存しない方法で Unicode データを扱うように設計されたエンコード体系です。UTF-8 は、ASCII や、8 ビット エンコードを必要とする他のバイト指向のシステム (さまざまなエンコード、バイト順、言語が使用される膨大な数のコンピュータを受け持つ必要があるメール サーバーなど) を使用する場合に便利です。SQL Server 2005 は、UTF-8 形式ではデータを格納しませんが、XML (Extensible Markup Language) データを処理するために UTF-8 をサポートしています。詳細については、このホワイト ペーパーの「SQL Server 2005 での XML サポート」を参照してください。
Oracle や Sybase SQL Server などの他のデータベース システムは、UTF-8 形式での Unicode の格納をサポートしています。サーバーの実装にもよりますが、この方がデータベース エンジンを技術的により簡単に実装できます。その理由は、1 バイトずつデータを処理するためにサーバー上の既存のテキスト管理コードを大幅に変更する必要がないためです。ただし、Windows 環境の場合、UTF-8 形式での格納には次のようないくつかの短所があります。
注 **: **古いバージョンの Oracle および Java も UCS-2 を使用しており、サロゲートを認識できません。Oracle Corporation は、Oracle 7 でデータベース文字セットとして Unicode のサポートを開始しました。Oracle は、現在、次の 2 つの Unicode データ格納方法をサポートしています : (1) CHAR および VARCHAR2 文字データ型、そしてすべての SQL 名およびリテラルのエンコードに UTF-8。(2) NCHAR、NVARCHAR、NCLOB Unicode データ型の格納には UTF-16。Oracle では、この 2 つの方法を同時に使用できます。
コンポーネント オブジェクト モデル (COM) の API およびインターフェイスでは、UTF-16/UCS-2 のみサポートされています。したがって、データが UTF-8 形式で格納されている場合は、定数の変換が必要になります。この問題は COM を使用する場合にのみ該当します。通常、SQL Server データベース エンジンが COM インターフェイスを呼び出すことはありません。
Windows XP と Windows Server™ 2003 カーネルはどちらも Unicode です。UTF-16 は、Windows 2000、Windows XP、および Windows Server 2003 の標準エンコードです。ただし、Windows 2000、Windows XP、および Windows Server 2003 は UTF-8 に対応しています。したがって、データベースで UTF-8 格納形式を使用すると、多くの追加の変換が必要になります。通常、変換に必要な追加のリソースは、SQL Server データベース エンジンには影響しませんが、クライアント側の多くの操作に影響する場合があります。
UTF-8 は、文字列操作の多くで時間がかかる場合があります。文字が固定幅ではないため、並べ替え、比較、および事実上すべての文字列操作が低速になる可能性があります。
UTF-8 は、ほとんどの場合に 2 バイトより多くのバイト数が必要となり、サイズの増加によりディスクおよびメモリの使用量が大きくなります。
このような短所はあるものの、インターネット経由での通信において XML が重要な規格となっていることから、UTF-8 を既定で使用することも必要に応じて検討してください。
UTF-16 は Microsoft および Windows オペレーティング システムのエンコード標準です。UTF-16 は、追加の 1,048,576 文字を処理するために考えられた拡張機能です。サロゲート範囲の必要性は、Unicode 2.0 がリリースされる前から認識されていました。なぜなら、すべての言語のすべての文字に単一のコード ポイントを持たせるという Unicode の目標は、たった 65,536 文字では実現できないことがはっきりしていたからです。たとえば、中国語などの一部の言語では、使用がまれであっても出版や学問上は重要な歴史的、文学的な表意文字などの文字のエンコードには、少なくとも同程度の数の文字が必要となります。次のセクションでは、サロゲート範囲について詳しく説明します。
UCS-2 と同様、UTF-16 も "リトルエンディアン" バイト順を使用します (Windows ではすべてがこのバイト順を使用します)。"ビッグ エンディアン" とは対照的に、リトル エンディアンでは、メモリの最下位アドレスに下位バイトが格納されます。バイトの順序は、オペレーティング システムのレベルで重要になります。SQL Server では、Windows プラットフォームで動作する他のアプリケーションと同じく、リトル エンディアンのバイト順が使用されます。したがって、0x1234 のような 16 進法の語は、0x34 0x12 としてメモリに格納されます。場合によっては、文字のエンコードを正しく読み取るため、バイト順を明示的に逆にしなければならないこともあります。SQL Server Integration Services には、Unicode テキストのバイト順を変換する機能が用意されています。詳細については、このホワイト ペーパーの「SQL Server 2005 Integration Services」を参照してください。 少なくともデータを失うことなく格納できることを意味しています。Microsoft Windows では、通常、UTF-16 を使用して文字データが表現されます。16 ビットの使用により、65,536 の一意の文字表現が可能になります。しかし、人間の言語で使用されている記号をすべてカバーするには、これでも十分ではありません。UTF-16 では、一部のコード ポイントは、最初の 2 バイトのすぐ後に別のコード ポイントを追加して、サロゲート範囲の一部として文字を定義します。
Unicode 規格には、1,114,112 もの文字を定義できる文字の "面" が 16 あります。0 面、つまり基本多言語面 (BMP) は、世界で使用されている文字の大部分、出版で使用される文字、数学記号および技術記号、幾何学模様、レベル 100 の Zapf Dingbats すべて、および句読記号を表現できます。
BMP を除き、大部分の面の文字はまだ定義されていませんが、補助文字を表現するために使用されます。補助文字は、主に歴史的文書および古典文学に使用され、中国語、韓国語、および日本語の豊富な文学的遺産のエンコードを支援します。また、補助文字には、ルーン文字やそれ以外の歴史的な文字、音楽記号なども含まれます。
UTF-16 では、サロゲート ペアと呼ばれるコード ポイントのペアは、主要な文字セット (BMP) 以外の文字を表現するのに使用されます。サロゲート領域は、Unicode の U+D800 ~ U+DFFF の領域であり、1,024 の下位サロゲート値と 1,024 の上位サロゲート値が含まれます。上位サロゲート (U+D800 ~ U+DBFF) と下位サロゲート (U+DC00 ~ U+DFFF) は結合され、100 万を超える数の文字の表現が可能になります。
サロゲート ペアの片方だけでは有効と見なされません。有効なものにするには、常に上位サロゲートの後に下位サロゲートがなければなりません。このため、サロゲートの検査は範囲の検査の問題となります。この検査は、DBCS (2 バイト文字システム) 文字の検出に必要となる複雑な規則よりは簡単です。
UCS-2 がサロゲートに対応していなくても、SQL Server 2000 および SQL Server 2005 はどちらもサロゲート ペアを格納できます。SQL Server は、1 つの文字ではなく 2 つの未定義の Unicode 文字としてサロゲート ペアを扱います。通常、このようなアプリケーションは "サロゲート ニュートラル" または "サロゲート セーフ" と呼ばれます。これは、データとやり取りする固有の機能を持ってはいないものの
これに対して、"サロゲート対応" アプリケーションは、サロゲート ペアを考慮できるだけでなく、結合文字や、特殊な処理が必要なそれ以外の文字を扱うこともできます。適切なアプリケーションは、わずかなサブルーチンだけで、分離されたサロゲートを検出して再結合することができます。サロゲート対応アプリケーションには、Microsoft Word や Internet Explorer 5 以降などがあります。
SQL Server で補助文字を使用する場合は、次の点に注意してください。
サロゲート ペアは、2 つの分離された Unicode コード ポイントと見なされるため、補助文字を 1 つ保持するには nvarchar(n) のサイズを 2 にする必要があります (つまり、サロゲート ペア用の領域)。
補助文字は、データベース オブジェクトの名前など、メタデータ内で使用することはできません。一般に、メタデータで使用するテキストは、識別子の規則に従う必要があります。詳細については、SQL Server Books Online の「識別子」を参照してください。
標準的な文字列操作は補助文字に対応していません。SUBSTRING(nvarchar(2),1,1) などの操作は、補助文字のサロゲート ペアの上位サロゲートのみを返します。LEN 関数は、検出された各補助文字を 2 文字として計算した合計を返します (上位サロゲートの 1 文字と下位サロゲートの 1 文字)。ただし、補助文字に対応したカスタム関数を作成することもできます。SQL Server Books Online の「補助文字対応文字列操作」の StringManipulate サンプルでは、このような関数の作成方法について説明しています。
補助文字の並べ替えおよび検索の動作は、照合順序によって変わることがあります。新しい 90_ および BIN2 照合順序では、補助文字は正しく比較されます。これに対して古い照合順序および標準 Windows 照合順序では、すべての補助文字は他のすべての補助文字と等しいと見なされます。たとえば、日本語および韓国語の既定の照合順序では補助文字が処理されませんが、Japanese_90 および Korean_90 では処理されます。
Unicode コード ポイント、サロゲート対応アプリケーション設計のベスト プラクティス、Unicode データの使用に関する詳細については、「グローバリゼーションのステップ バイ ステップ : ユニコードへの対応」を参照してください。Unicode 規格でサポートされている文字範囲の詳細については、「Unicode Technical Standard #18」の「Unicode Regular Expressions」を参照してください。