DDBM 特集2 4-1001（SQL Server）
Total Page：16
File Type：pdf, Size：1020Kb
徹・底・研・究 2 特集 1 RDBMS の文字コード MS 漢字コードとUnicode の使いこなしがカギ RDBMS Windows OSに依存する SQL Server 文字コードの仕組み パート2では、Microsoft SQL Server の文字コードについて解説する。SQL Serverで扱える文字コ ードはWindows OSに依存するため、扱うデータの文字コードによってデータ型の使い分けなどに注意す る必要がある。そこで本パートでは、SQL Serverで使用できる文字コードである「MS 漢字コード（マイク ロソフトが策定）」と「Unicode」の解説を中心に、SQL Serverのデータ型との関係、JIS2004対応、 SQL Server Integration Services（SSIS）における文字コード変換などについて紹介する。 日本ユニシス株式会社 岡田朋之 OKADA, Tomoyuki ／森嶋荘一郎 MORISHIMA, Shoichiro ように世界中には多くの文字があるが、特定の 文字集合と文字符号化方式の関係は必ずし 文字コードの基礎 国や言語で必要となる文字は限られる。そのた も1対1ではない。複数の文字集合を対象とす め、まず規格に含める文字の集まりと順番を定め る文字符号化方式や、同一文字集合を対象と SQL Serverで使用できる文字コードを説明 る。この文字の集まりと順番を定義したものを する複数の文字符号化方式がある。 する前に、その前提となる知識（文字コードと 「符号化文字集合（以下、文字集合）」と呼ぶ。 例えば、表3のようにSHIFT_JIS 文字符号化 Windowsでの文字コードの扱い）を説明する。 日本で利用される代表的な規格は表1に示 すと 方式は「JIS X 0201」と「JIS X 0208」という2 おりで ある 。 つの文字集合を対象とする。JIS X 0201、JIS 一方、コンピュータで文字を扱うには、これら X 0208の文字集合はSHIFT_JISとEUC-JPで 文 字 コ ードと は の文字集合をデータ列（ビット列）に割り当てる必 それぞれ別の文字コードに符号化できる。 「文字コード」とは、コンピュータ上で文字を表 要がある。これらの文字集合の文字をデータ列 現するために、符号化文字集合を特定の文字 に割り当てる方式を「文字符号化方式（エンコー 表3 ： 文字集合と文字コードとの関連 符号化方式によって符号化したデータ列のこと ディング方式）」と呼ぶ。日本で利用されることの 文字集合 文字符号化方式 文字コード である。図1は、文字が文字コードに対応付け 多い文字符号化方式を表2に示す。 JIS X 0201 SHIFT_JIS シフト JIS JIS X 0208 EUC-JP 日本語 EUC されるまでの 過 程を表 わしたものである。 図 1 の 表1 ： 主な符号化文字集合の規格 規格名 規定する主な文字 ASCII 半角英数字、英語で使用する記号 JIS X 0201 ASCIIで規定された文字と半角カタカナ 文字 英数字 JIS X 0208 ひ ら が な 、カ タ カ ナ 、漢 字（ J I S 第 1 水 準 、J I S 第 2 水 準 ）、英 数 字 、記 号 ひらがな、カタカナ ※符号化文字方式のShift_JISと文字コード JIS X 0212 JIS X 0208に収録されていない漢字（補助漢字） 漢字 のShift_JISを区別するため、文字コードの ギリシア文字 Shift_JISを「シフトJIS」と表現している JIS X 0213 JIS X 0208 に漢字（JIS第3水準、JIS第4水準）や記号などを追加 ハングル文字 など Unicode 世界中の文字と記号 ● 国で使用する文字 ● 言語で使う文字 表2 ： 主な文字符号化方式 など目的に応じて選択する 文字符号化方式 対象とする文字集合 バイト数 備考 Shift_JIS JIS X 0201、JIS X 0208 1～2 符号化 文字符号化方式 文字コード バイト 文字集合 あ 82A0 UTF-8 Unicode 1～4 Web サイトや XMLドキュ 亜 889F バイト メントなどで使用される ① 8740 UTF-16 Unicode 2 バイト Windows NT 系の内部処 理で使用している ● ASCII ● SHIFT_JIS ● ANSI UTF-32 Unicode 4 バイト ● JIS X 0201 ● UTF-8 ● シフトJIS ※ EUC-JP JIS X 0201、JIS X 0208、 1～2 UNIX で使用される ● JIS X 0208 ● UTF-16 ● Unicode ● JIS X 0213 ● EUC-JP ● 日本語EUC JIS X 0212 バイト など など など ISO-2022-JP 半角カナを除くJIS X 0201、 1～2 電子メールなどで JIS X 0208 バイト 使用される 図1 ： 文字から文字コードへの対応付け DB Magazine 2010 January MS 漢字コードとUnicode の使いこなしがカギ Windows OSに依存する SQL Server 文字コードの仕組み 2 表4 ： Unicodeのバージョンと日本語の符号化文字集合との対応関係 Unicode バージョン 収録文字数 日本語の符号化文字集合との対応 第1面～第16面 Unicode 1.0.0 7,161 JIS X 0201 に対応 第1面 BMP（第0面） BMP（第0面） Unicode 1.0.1 28,359 JIS X 0208、JIS X 0212 に対応 Unicode 2.0 34,233 サロゲートペアの仕様が導入され、収録可能 上位サロゲート な文字数が増加。また、結合文字も仕様とし ＋ D800h～DBFFh て定義 （ 1 0 2 4 個 ） 下位サロゲート DC00h～DFFFh 文字コードを計算※ （ 1 0 2 4 個 ） 実際にはサロゲート文字は割り当てられてい なかった Unicode 2.1 38,950 1面65536文字×16面=1,048,576文字 Unicode 3.0 49,259 第2面 Unicode 3.1 94,205 JIS X 0213:2004に一部対応 20B9Fh Unicode 3.2 95,211 JIS X 0213:2004 に正式対応 D842h ＋ DF9Fh 叱 サロゲートペアに文字を割り当て （上位サロゲート） （下位サロゲート） Unicode 4.0 96,447 Unicode 5.0 99,089 ※第1面～第16面に収録されている文字コードは以下の数式で計算 文字コード値＝（上位サロゲート－D800h）×400h＋（下位サロゲート－DC00h）＋10000h 図2 ： サロゲート文字の仕組み バイトの文字と、「は」と文字合成用半濁点「゜」 を組み合わせた4バイトの文字の2種類が存在 る領域を単位として、全17面で構成される。面 す ることになる 。 MS 漢字コードとUnicode の先頭である第0面は「基本多言語面（BMP： Unicodeは、1991 年 10月に策定されたバージ 文字コードには多くの規格が存在するが、そ Basic Multilingual Plane）」と呼ばれ、欧米、ア ョン1.0.0から、収録文字を増やしながら現在まで の中から以降のトピックに関連するマイクロソフト ジア圏などの主要言語で用いる文字（日本語の 拡張されてきた。それに伴い、順次日本語で用 が策定した「MS 漢字コード」と「Unicode」につ 平仮名、片仮名、漢字なども含む）が定義され いる文 字も収 録されてきた。表4に、Unicodeの いて説明する。 ている。当初、UnicodeはBMPだけが定義さ バージョンとJIS規格文字の対応関係を示す。 MS漢字コードはJIS X 0201とJIS X 0208、 れ、16ビットの文字コードで表現できた。しかし、 および特殊文字（NEC特殊文字、NEC選定 アジア圏などの各国から文字の追加要求があり、 Windows で扱うことができる IBM拡張文字、IBM拡張文字）を文字集合と さらなる文字を符号化するに伴って文字が増え 文 字 コ ード して使用し、コードページ932（CP932）と呼ばれ てしまい、BMP の領域で表現することは難しくな るSHIFT_JISを拡張した文字符号化方式で符 った。そこで、BMP以外の領域に文字を定義し Windowsの内部コードは、バージョンによって 号化している。JIS X 0201（いわゆる半角文字） て符号化する必要がでてきたのである。そのた 異なる。日本語版 Windowsの場合、Windows を1バイトで扱い、それ以外の文字を2バイトで め の 仕 組 み が サ ロ ゲ ートで あ る 。 サ ロ ゲ ートは 9x 系はMS 漢字コードを、Windows NT 系の 扱っている。日本語版 MS-DOSで採用されて以 BMP中に上位サロゲート（D800h 〜 DBFFh） OSはUnicodeをそれぞれ内部コードとして使用 来、現在 Windowsで使用可能な文字コードで と下位サロゲート（DC00h 〜 DFFFh）の2 箇所 している。図3のように、Windows NT 系とWin ある。 のコード領域を用意し、それぞれ 2 バイトの値を dows 9ｘ系はWindows XPで統合され、以降 一方のUnicodeは、国、地域、処理系などで 所定の数式で計算することによってBMPに続く Windowsの内部コードはUnicodeを使用して 別々に定義されていた文字コードを統一し、世 面に収録されている文字を符号化する仕組みで いる。 界中の文字を1つの文字コードで表現することを あ る（ 図2）。 上 位 サ ロ ゲ ートと 下 位 サ ロ ゲ ートの Windows NT 系で使用できる文字集合は、 目的とした規 格で、ユニコードコンソーシアム 組を「サロゲートペア」と呼ぶ。 表5のとおり各OSの内部コードで使用したUni （The Unicode Consortium）によって仕様が制 また、Unicodeには複数の文字を組み合わせ codeバージョンに従っており、文字符号化方式 定されている文 字コードである。元々は 16ビット て1つの文字を表現する仕組みがある。これが はUTF-16を使用している。ただし、文字集合 ですべての文字を表現しようとしたが、符号化す 結合文字である。ヨーロッパ言語、アラビア文字 に関してはWindowsで標準搭載されているフォ る文字が多すぎたため、現在では拡張されて など で 用 いられ ているアクセントなど の 発 音を表 ントがUnicodeの各バージョンの文字集合すべ いる。 現するために使われてきた。この複数の文字を てに対応しているわけではないため、Unicode Unicodeの特徴として、「サロゲート文字」と 合成して作成した文字が日本語の濁点、または で定義された文字をすべて使用できるわけでは 「結合文字」という2 点の特徴がある。Unicode 半濁点付きのカタカナやひらがなの表現に使用 ない。 は、「面」と呼ばれる65536個の文字を定義でき で き る 。 例 え ば 、「 ぱ 」と い う 文 字 は「 ぱ 」と い う 2 Windows Server 2003までのOSでは、JIS DB Magazine 2010 January 徹・底・研・究 特集 1 RDBMS の文字コード X 0213で新たに追加された文字に対応してい 型がある。それぞれのデータ型の特徴は表6に charなどの非 Unicode 型はバイト数を表わし、 ないため注1、OS間でUnicodeのバージョンによ 示 すとおりで ある 。 ncharなどのUnicode 型のデータは文字数を表 る文字の違いは明らかにならなかった。しかし、 非 Unicodeデータ型の文字コードは、列の照 わす。例えば、char（5）の列とnchar（5）の列 Windows VistaでJIS X 0213に対応したフォン 合順序注2によって決まる。日本語を扱う場合は に文字列“あいうえお”を挿入する場合について トが用意されたことで、Windows XPからWind 「Japanese」「Japanese_90」や「Japanese_XJI 考える。“あいうえお”は全角 5 文字、データサイ ows Vista へ移行する場合やWindows XPと S_100」など、「Japanese」からはじまるWindows Windows Vistaが共存する環境において文字 照合順序を選択する（画面1）。その際の文字 注1：Windows XPやWindows Server 2003は技術仕様と してUnicode 3.1に準拠している。Unicode 3.1では の違いによる影響がある（一般には「JIS2004対 コ ード は M S 漢 字 コ ードとな る 。 JIS X 0213:2004の一部文字が収録されている。ただ し、追加された文字に対応するフォントが用意されてい 応」と呼ばれている。SQL ServerにおけるJIS SQL Serverでは、Unicodeのデータ型と非 ない。 2004対応については後述する）。 Unicodeのデータ型では長さの単位が異なる。 注2：文字データの並べ替えや比較で使用するルール。 表 6 ： SQL Server の文字列データ型 SQL Serverにおける 文字コード データ型 特徴 文字コードの扱い 非 Unicode char 固定長 最大8,000バイト分の文字を格納できる varchar 可変長 SQL Server のデータ型と 最大8,000バイト分の文字を格納できる 文字コードの関係 varchar（max） 可変長 最大2,147,483,647文字（上限2GB）を格納できる SQL Serverでは、文字コードの扱いは非 SQL Server 2005 以降で使用可能 text 型の代替機能 UnicodeとUnicodeで異なる。非 Unicodeのデ text 可変長 ータ型にはchar 型、varchar型、varchar（max） 最大2,147,483,647文字（上限2GB）を格納できる 型、text型があり、Unicodeのデータ型にはnch SQL Server 2005 以降のバージョンでは非推奨（varchar （max）型を使用する） ar 型、nvarchar 型、nvarchar（max）型、ntext Unicode nchar 固定長 最大で4,000文字（8,000バイト）分のデータを格納できる※ nvarchar 可変長 Windows NT 系 Windows 9x 系 最大で4,000文字（8,000バイト）分のデータを格納できる※ nvarchar(max) 可変長 Windows NT 3.1 Windows 95 最大1,073,741,823 文字（2GB）を格納できる Windows NT 4.0 Windows 98 SQL Server 2005 以降で使用可能 ntext 型の代替機能 Windows 2000 Windows ME ntext 可変長 最大1,073,741,823 文字（2GB）を格納できる Windows Server 2003 Windows XP SQL Server 2005 以降のバージョンでは非推奨（nvarchar （max）型を使用する） Windows Server 2008 Windows Vista ※サロゲート文字や結合文字は1文字で4バイト以上の領域が必要であるため、これらの文字を使用 する場合、最大文字数は少なくなる 図 3 ： Windows OS の系譜 表 5 ： Windows OSとUnicode のバージョン対応状況 Windows OS バージョン Unicode バージョン※ Windows NT 3.1 Unicode 1.1 Windows NT 4.0（SP4） Unicode 2.0 Windows 2000 Unicode 2.1 Windows XP Unicode 3.1 Windows Server 2003 Unicode 3.1 Windows Vista Unicode 3.2 Windows Server 2008 Unicode 5.0 ※ここでは、技術仕様として準拠しているUnicodeのバージョン を表わしている。実際には該当バージョンにおけるUnicode 文 字の全フォントを実装していないため表示できない文字もある 画面1 ： 列の照合順序の設定画面 DB Magazine 2010 January MS 漢字コードとUnicode の使いこなしがカギ Windows OSに依存する SQL Server 文字コードの仕組み 2 ズが10バイトのため、nchar（5）への挿入は正 常に処理できるが、char（5）への挿入はエラー と な る（ 画面 2）。 SQL Server での Unicode 文字の扱い方 画面2 ：データ型による格納可能なデータサイズの違い SQL Serverでは、SQLステートメント内の文 字列にUnicodeの文字を含む場合と含まない場 合とで記述方法が異なる。Unicode 文字として 扱う場合は、文字列の前に「Nプレフィックス」を 付ける必 要がある。 画 面 3 ： 例えば「鷗」という文字は、Unicodeでは扱え N プレフィックス有無による実 るがMS漢字コードでは扱うことができない文字 行結果（左： ①の実行結果、 右 ： ②の実行結果） である。この文字がSQL Serverでどのように扱 われるか動作を確認した。 ② サロゲート文字や結合文字が SQLステートメント内で文字列をUnicodeとし 含まれる文字列の扱い方を見直す 確認 て扱う場合、Nプレフィックスを付け忘れることの テーブルに以下の 2 パターンの SQL ステートメ ないように十分注意してほしい。 SQL Serverでは、Unicode型データを1 文 ントを実行し、結果を確認する。 字2バイトとして扱う。1文字4バイト以上のサロ ゲート文字や結合文字を使用する場合には、以 SQL Serverにおける ① col1［varchar（10）］、col2［nvarchar（10）］ 下のような点に注意する必要がある。 JIS2004対応 にUnicode 型のデータを挿入 （1） サロゲート文字や結合文字1文字は INSERT INTO TestTable SQL ServerにおけるJIS2004 対応として、以 VALUES (N‘森鷗外’,N‘森鷗外’) nchar（1）に格納できない 下の 3 点が挙げられる。 ② col1［varchar（10）］、col2［nvarchar（10）］ nchar（1）には2バイト分の文字しか格納でき に非 Unicode 型のデータを挿入 ないため 、切り捨 てエラーが 発 生 する。これらの ① Unicodeに対応した INSERT INTO TestTable 文字を1文字格納する場合は、［文字のバイト VALUES (‘森鷗外’, ‘森鷗外’) データ型に変更する 数］/2バイト分の長さが必要となる（例えば、4バ JIS2004で追加された文字はMS 漢字コード イトのサロゲート文字では長さが2 必要となる）。 結果 では扱うことができないため、既存のchar 型や （2） ワイルドカードではサロゲート文字や 画面 3 各SQLステートメントの実行結果は、 の varchar 型などの非 Unicode 型をnchar 型やn 結合文字を正しく扱えない ようになる。この結果から、以下のことが分かる。 varchar 型に変更する。「SQL Serverのデータ 型と文字コードの関係」の項でも述べたように、 Transact-SQLで提供されているワイルドカー ◦ MS 漢字コードに存在しない文字を非 Unico char 型とnchar 型ではデータ型の長さが異なる ドのうち、任意の1文字を示すワイルドカード d e 型 の 列 に 挿 入 すると、「？」に変 換される ため、テーブル定義の見直しや、それに伴うディ （“_”）や指定した範囲の1文字に一致するワイル ◦ Nプレフィックスを付けた文字列はUnicode スクサイズの見直しが必要となる。また、文字コ ドカード（“［ ］”)、指定した範囲の1文字に一致 型の列に正常に挿入できる ードがJIS2004を含むUnicodeに変わることによ し な い ワ イ ル ド カ ー ド（［ ^ ］）で は サ ロ ゲ ー ト 文 字 を ◦ MS漢字コードに存在しない文字をNプレフィ り、データの受け渡しを行なうアプリケーションで 指定できない。例えば、サロゲート文字を含む ックスを付けずにUnicode 型の列に挿入すると もJIS2004の文字を含むUnicode 対応が必要と 「叱る」はワイルドカード“_る”で検索できない（“__ 「？」に変 換される なる。 る”や“%る”では検索できる）。この動作は、ワイ ルドカードで想定されている1 文字がnchar（1） DB Magazine 2010 January 徹・底・研・究 特集 1 RDBMS の文字コード に相当するためである。 でサロゲート文字「叱」を含む文字列の文字数 した結果である。「Japanese_XJIS100」では条 なお、ワイルドカードによる文字列比較の際に を表示した結果である。本来は2文字として扱 件に一致するのみが返されるが、「Japanese」 も以前のバージョンのWindows 照合順序「Japa われる文字が 3 文字として扱われていることが分 の場合は条件に合致するのほかに、、 nese」ではサロゲート文字を正しく比較できない かる（サロゲート文字や結合文字により影響を受 も結 果として返される。 ため、注意が必要である。 ける文 字 列 操 作 関 数とその 影 響 は 表7を 参 照 ）。 同様に、Transact-SQLで提供されているRE この影響への対応策としては、CLRユーザー PLACE 関数でも、重み値が設定されていない （3） 既存の文字列操作関数でサロゲート文