徹・底・研・究 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）既存の文字列操作関数でサロゲート文 字や結合文字を正しく扱えない 定義関数を使用してサロゲート文字や結合文字 文 字を同 一と判 断して、すべて置き換えるという に対応した関数を新しく作成するという方法があ 影 響がある。 Transact-SQLで提供されている文字列操作 る。CLRユーザー定義関数のサンプルをマイク このように、旧バージョンのWindows 照合順 関数は、Unicodeデータ型を1 文字 2バイトで扱 ロソフトが「SQL Serverオンラインブック」で公開 序を使用すると正しく扱うことができない文字が う。そのため、1文字 4バイト以上のサロゲート している注3。 あるため、JIS2004対応時には照合順序を最新 文字や結合文字でこれらを使用すると、意図し のWindows 照合順序にする。 た文字列操作ができない。 ③最新の照合順序に変更する 画面4は、例として文字列操作関数LEN（） 以上がSQL ServerにおけるJIS2004 対応の SQL Server 2000のWindows 照合順序「Ja ポイントである。SQL Serverとは直接関係ない 注3：http://msdn2.microsoft.com/ja-jp/library/ ms160903.aspx panese」では、JIS2004で追加された文字に重 が、JIS2004 対応でもう1つポイントとなる文字の 注4：文字の並べ替えなどをする際、順序を決めるときに使わ み値注4が付与されていない文字があり、これら 表示についても解説しよう。 れる値 。 注5：Windows Vista 向け「JIS90 互換 MS ゴシック＆MS の文字の並べ替えおよび比較を正しくできない。 既存システムにWindows Vistaが加わること 明 朝フォントパッケージ 」をインストールすることにより、 Windows Vista 以前のOSと同一表示にすることもで 一方、SQL Server 2008で新しく提供されたWi で、表8に あ る よう に O S 間 の フォント が 異 なり 、同 きる。 ndows 照合順序「Japanese_XJIS100」では、こ じ文字が異なる字体で表示されることやJIS2004 れらの文 字に重み値 が 付 与されているため、文 で追加された文字を旧バージョンのOSでは表示 字の並べ替えおよび比較が正しくできる。 できないといった影響がある。この影響への対 画面5は、JIS2004で追加された文字（、 応策は、マイクロソフトがWindows XPおよび
画面4 ： 、、）が「Japanese」の列（col1）と照合順 Windows Server 2003 向 けに提 供している 文字列操作関数の 実行例 序が「Japanese_XJIS100」の列（col2）で検索 「MS ゴシック＆MS 明朝JIS2004対応フォント」 を適 用 することである。このフォントを適 用 するこ 表7 ： サロゲート文字や結合文字により影響を受ける文字列関数 とで、字形や追加された文字を表示できる注5。 サロゲート文字や結合文字を使用することによる 関数名 関数の機能 影響 ここまで、SQL ServerにおけるJIS2004 対応 L E N（ ） 文字数を表示する 正しい文字数を得ることができない のポイントを解説したが、マイクロソフトがJIS20 L E F T（ ） 文字列の左から指定した文字数を取り出す 指定した文字数よりも返される文字が少ない。ま た、上位(下位)サロゲートのみが指定されると、 RIGHT（） 文字列の右から指定した文字数を取り出す 04対応に関するホワイトペーパーを公開してい 文字を正しく表示できない SUBSTRING（） 文字列を指定の位置から指定した文字数取り出す る。併せて一読すれば、より理解が深まるだろう。 S T U F F（ ） 文字列の指定した位置から指定の文字数に置き換える 置き換える文字の開始位置を正しく指定できない REVERSE（） 文字列を逆に並べ替える サロゲート文字は上位サロゲートと下位サロゲー トの組み合わせが逆になるため正しく表示できな い。また結合文字は1文字目と2文字目が逆にな り、それぞれ別の文字として扱われる
表 8 ： Windows XP/Server 2003 搭載フォントからの変更点
特徴 説明
一部の文字の字形が変更されている MSゴシック382文字（非漢字100文字、漢字282文字） 照合順序 Japanese_ MS明朝303文字（非漢字90文字、漢字213文字） CI_ASで比較した結果 文字が追加／削除されている （例 ： 味噌 → ） 1082文字追加（非漢字173文字、漢字909文字） 非漢字2文字削除 照合順序 Japanese_ サロゲート文字が使用可能 16ビットの2つのコードを組み合わせて1つの文字として表現する XJIS100_CI_ASで （例 ： 0xD840と 0xDC0Bを組み合わせた など） 比較した結果 結合文字の使用が可能 16ビットの基底文字と16ビットの結合文字を組み合わせて1文字として表現する （例 ：「ト」と半濁点を結合した など）
画面5 ： 照合順序の違いによる動作比較
DB Magazine 2010 January MS 漢字コードとUnicode の使いこなしがカギ Windows OSに依存する SQL Server 文字コードの仕組み 2
表9 ： SSISのデータ型とDBMSのデータ型の対応関係（一部）
SQL Server Native Oracle Provider SSIS の内部データ型 Oracle SSIS SQL Server Client for OLE DB （Windows） （Windows） DT_STR ※1 char varchar
DT_WSTR ※2 nchar char nvarchar varchar2 nchar nvarchar2
※1 CP932 の文字を格納するデータ型 ※2 Unicode の文字を格納するデータ型 図 4 ： SQL ServerとOracleとの SSIS 連携時の構成例
Oracle SSIS SQL Server Oracle Provider SQL Server for OLE DB Native Client ◦JIS X 0213:2004 / Unicode 実装ガイド
http://download.microsoft.com/download varchar2型 DT_WSTR データ型 DT_STR varchar型 （MS 漢字コード） （Unicode） 変換タスク （MS 漢字コード） （MS 漢字コード） /e/3/c/e3c1a451-1882-49fe-86a8-e25 680f6c46c/JIS_Unicode_guide.pdf
図 5 ： OracleとSQL Serverとの SSIS 連携時の文字コード遷移 ◦SQL ServerのJIS2004 対応に関するガイド ＊ ＊ ＊ ライン T_STR 型に、オラクルが提供しているOracle P http://www.microsoft.com/downloads/det rovider for OLE DBを使用してOracleのvarc 以上、パート2ではSQL Serverと文字コード ails.aspx?FamilyId=E942342A-719F-484 har2 型に接続する場合はDT_WSTR 型になる。 の関係について説明した。SQL Serverで扱う 1-A9D2-F6D9FD58299F&displaylang=ja SSISでOracle Provider for OLE DBを使用 文字コードは、Windows OSに依存して決まる。 してOracle のvarchar2 型（MS 漢字コードの文 扱うデータの文字コードによって、データ型の使 字を格納）よりデータを取り込み、SQL Server い分けや SQLステートメントの記述に注意しなけ SSIS使用時に発生する Native Clientを使用してSQL Serverのvarch れ ばならない 。 文字コード変換 ar 型にデータをコピーしようとする。Oracleより また、SQL ServerにおけるJIS2004 対 応と シ ス テ ム 間 で デ ー タ の やりとりを 行 なう 際 に 、シ SSISにデータを取り込む際にSSIS 内のDT_ SSISにおける文字コード変換についても説明し ステム間の文字コードが違うため明示的に文字 WSTR 型に取り込む必要があるため、MS漢字 たが、Windows VistaでJIS2004に対応がなさ コード変換をする場合がある。一方、開発者が コードからUnicodeに変換される。一方、SQL れ、新たに追加された文字が既存システムに影 意識しないところで文字コードが自動的に変換さ Serverにデータをコピーする場合には、DT_ 響を及ぼす可能性がある。JIS2004 については れ、思わぬ問題が発生する場合もある。ここで STR 型にSSIS 内で変換する（図5。内部デー 今後、Windows XPのサポート停止などに伴っ は、Windows上のOracleのデータをSQL Serv タ型を変換するために、SSISで標準提供されて て対応するケースが増えていくだろう。 er Integration Services（以下、SSIS）を用い いる「データ型 変 換タスク」を使用する）。 SQL Serverにおける文字コードの扱いにつ てSQL Serverにコピーする場合を紹介する。 この構成において、MS 漢字コードで扱うこと いて、本パートが読者の理解の一助になれば幸 SSISとは、SQL Server 2005 以降のSQL Se ができる文字の多くはSQL Server へコピーでき いである。 DBM rverで標準提供されているETLツールで、SQL るが、特定の文字によってはUnicodeからMS Server 2000までのデータ変換サービス（DTS） 漢字コードに変換できない場合がある（波ダッシ 岡田朋之（おかだともゆき） の後継機能であり、Oracleなどの他データソー ュ文字［U＋301C、WAVE DASH］など）。 日本ユニシス株式会社へ入社後、サードパーテ スと連携できる機能を持つ（図4）。 このように、SSISは内部で独自のデータ型を ィ製ETL/BIツールの社内向けサポートを担 当。現在は SQL Server を使用したシステム SSISは内部に独自でデータ型を持っており、 保持しており、入出力で使用するデータ型やプ 構築支援や技術評価を担当している。 接続するDBMSの種類やデータ型、接続に使 ロバイダの組み合わせ次第では開発者が気づ 森嶋荘一郎（もりしましょういちろう） 用するプロバイダによって使用するデータ型を決 かないところで文字コードが変換されていること 日本ユニシス株式会社へ入社後、主にアプリケ める。例えば、表9の ように マ イクロ ソ フト が 提 供 がある。そのためにも、SSISで使用するデータ ーション開発畑を歩む。近年、SQL Server の 構築支援、技術支援を担当。アプリケーション しているSQL Server Native Clientを使用して 型とプロバイダの組み合わせを事前に検討して からSQL Serverまで一気通貫したチューニ SQL Serverのvarchar 型に接続する場合はD おくこと が 重 要 で あ る 。 ングを得意とする。
DB Magazine 2010 January