1 rdbms 2 徹・底・研・究...db magazine 2010 january の文字コード 1...
TRANSCRIPT
DB Magazine 2010 January
の文字コード徹・底・研・究
特集1
RDBMS
文字コードの基礎
SQL Serverで使用できる文字コードを説明
する前に、その前提となる知識（文字コードと
Windowsでの文字コードの扱い）を説明する。
「文字コード」とは、コンピュータ上で文字を表
現するために、符号化文字集合を特定の文字
符号化方式によって符号化したデータ列のこと
である。図1は、文字が文字コードに対応付け
されるまでの過程を表わしたものである。図1の
文字コードとは
ように世界中には多くの文字があるが、特定の
国や言語で必要となる文字は限られる。そのた
め、まず規格に含める文字の集まりと順番を定め
る。この文字の集まりと順番を定義したものを
「符号化文字集合（以下、文字集合）」と呼ぶ。
日本で利用される代表的な規格は表1に示すと
おりである。
一方、コンピュータで文字を扱うには、これら
の文字集合をデータ列（ビット列）に割り当てる必
要がある。これらの文字集合の文字をデータ列
に割り当てる方式を「文字符号化方式（エンコー
ディング方式）」と呼ぶ。日本で利用されることの
多い文字符号化方式を表2に示す。
文字集合と文字符号化方式の関係は必ずし
も1対1ではない。複数の文字集合を対象とす
る文字符号化方式や、同一文字集合を対象と
する複数の文字符号化方式がある。
例えば、表3のようにSHIFT_JIS文字符号化
方式は「JIS X 0201」と「JIS X 0208」という2
つの文字集合を対象とする。JIS X 0201、JIS
X 0208の文字集合はSHIFT_JISとEUC-JPで
それぞれ別の文字コードに符号化できる。
MS漢字コードとUnicodeの使いこなしがカギ
パート2では、Microsoft SQL Serverの文字コードについて解説する。SQL Serverで扱える文字コードはWindows OSに依存するため、扱うデータの文字コードによってデータ型の使い分けなどに注意する必要がある。そこで本パートでは、SQL Serverで使用できる文字コードである「MS漢字コード（マイクロソフトが策定）」と「Unicode」の解説を中心に、SQL Serverのデータ型との関係、JIS2004対応、SQL Server Integration Services（SSIS）における文字コード変換などについて紹介する。
日本ユニシス株式会社 岡田朋之 OKADA, Tomoyuki ／森嶋荘一郎 MORISHIMA, Shoichiro
Windows OSに依存するSQL Server文字コードの仕組み
RDBMS
2
文字
英数字ひらがな、カタカナ漢字ギリシア文字ハングル文字 など
符号化文字集合あ亜①
● 国で使用する文字● 言語で使う文字 など目的に応じて選択する
● ASCII● JIS X 0201● JIS X 0208● JIS X 0213 など
文字符号化方式
● SHIFT_JIS● UTF-8● UTF-16● EUC-JP など
文字コード
82A0889F8740
● ANSI● シフトJIS ※● Unicode● 日本語EUC など
※符号化文字方式のShift_JISと文字コードのShift_JISを区別するため、文字コードのShift_JISを「シフトJIS」と表現している
図1：文字から文字コードへの対応付け
表1：主な符号化文字集合の規格
規格名 規定する主な文字
ASCII 半角英数字、英語で使用する記号
JIS X 0201 ASCIIで規定された文字と半角カタカナ
JIS X 0208 ひらがな、カタカナ、漢字（JIS第1水準、JIS第2水準）、英数字、記号
JIS X 0212 JIS X 0208に収録されていない漢字（補助漢字）
JIS X 0213 JIS X 0208 に漢字（JIS第3水準、JIS第4水準）や記号などを追加
Unicode 世界中の文字と記号
表2：主な文字符号化方式
文字符号化方式 対象とする文字集合 バイト数 備考
Shift_JIS JIS X 0201、JIS X 0208 1 ～ 2バイト
UTF-8 Unicode 1 ～ 4バイト
WebサイトやXMLドキュメントなどで使用される
UTF-16 Unicode 2バイト Windows NT系の内部処理で使用している
UTF-32 Unicode 4バイト
EUC-JP JIS X 0201、JIS X 0208、JIS X 0212
1 ～ 2バイト
UNIXで使用される
ISO-2022-JP 半角カナを除くJIS X 0201、JIS X 0208
1 ～ 2バイト
電子メールなどで使用される
表3：文字集合と文字コードとの関連
文字集合 文字符号化方式 文字コード
JIS X 0201 SHIFT_JIS シフトJIS
JIS X 0208 EUC-JP 日本語EUC
DB Magazine 2010 January
MS漢字コードとUnicodeの使いこなしがカギ
2Windows OSに依存するSQL Server文字コードの仕組み
MS漢字コードとUnicode
文字コードには多くの規格が存在するが、そ
の中から以降のトピックに関連するマイクロソフト
が策定した「MS漢字コード」と「Unicode」につ
いて説明する。
MS漢字コードはJIS X 0201とJIS X 0208、
および特殊文字（NEC特殊文字、NEC選定
IBM拡張文字、IBM拡張文字）を文字集合と
して使用し、コードページ932（CP932）と呼ばれ
るSHIFT_JISを拡張した文字符号化方式で符
号化している。JIS X 0201（いわゆる半角文字）
を1バイトで扱い、それ以外の文字を2バイトで
扱っている。日本語版MS-DOSで採用されて以
来、現在Windowsで使用可能な文字コードで
ある。
一方のUnicodeは、国、地域、処理系などで
別々に定義されていた文字コードを統一し、世
界中の文字を1つの文字コードで表現することを
目的とした規格で、ユニコードコンソーシアム
（The Unicode Consortium）によって仕様が制
定されている文字コードである。元々は16ビット
ですべての文字を表現しようとしたが、符号化す
る文字が多すぎたため、現在では拡張されて
いる。
Unicodeの特徴として、「サロゲート文字」と
「結合文字」という2点の特徴がある。Unicode
は、「面」と呼ばれる65536個の文字を定義でき
る領域を単位として、全17面で構成される。面
の先頭である第0面は「基本多言語面（BMP：
Basic Multilingual Plane）」と呼ばれ、欧米、ア
ジア圏などの主要言語で用いる文字（日本語の
平仮名、片仮名、漢字なども含む）が定義され
ている。当初、UnicodeはBMPだけが定義さ
れ、16ビットの文字コードで表現できた。しかし、
アジア圏などの各国から文字の追加要求があり、
さらなる文字を符号化するに伴って文字が増え
てしまい、BMPの領域で表現することは難しくな
った。そこで、BMP以外の領域に文字を定義し
て符号化する必要がでてきたのである。そのた
めの仕組みがサロゲートである。サロゲートは
BMP中に上位サロゲート（D800h 〜 DBFFh）
と下位サロゲート（DC00h 〜 DFFFh）の2箇所
のコード領域を用意し、それぞれ2バイトの値を
所定の数式で計算することによってBMPに続く
面に収録されている文字を符号化する仕組みで
ある（図2）。上位サロゲートと下位サロゲートの
組を「サロゲートペア」と呼ぶ。
また、Unicodeには複数の文字を組み合わせ
て1つの文字を表現する仕組みがある。これが
結合文字である。ヨーロッパ言語、アラビア文字
などで用いられているアクセントなどの発音を表
現するために使われてきた。この複数の文字を
合成して作成した文字が日本語の濁点、または
半濁点付きのカタカナやひらがなの表現に使用
できる。例えば、「ぱ」という文字は「ぱ」という2
バイトの文字と、「は」と文字合成用半濁点「 」゚
を組み合わせた4バイトの文字の2種類が存在
することになる。
Unicodeは、1991年10月に策定されたバージ
ョン1.0.0から、収録文字を増やしながら現在まで
拡張されてきた。それに伴い、順次日本語で用
いる文字も収録されてきた。表4に、Unicodeの
バージョンとJIS規格文字の対応関係を示す。
Windowsの内部コードは、バージョンによって
異なる。日本語版Windowsの場合、Windows
9x系はMS漢字コードを、Windows NT系の
OSはUnicodeをそれぞれ内部コードとして使用
している。図3のように、Windows NT系とWin
dows 9ｘ系はWindows XPで統合され、以降
Windowsの内部コードはUnicodeを使用して
いる。
Windows NT系で使用できる文字集合は、
表5のとおり各OSの内部コードで使用したUni
codeバージョンに従っており、文字符号化方式
はUTF-16を使用している。ただし、文字集合
に関してはWindowsで標準搭載されているフォ
ントがUnicodeの各バージョンの文字集合すべ
てに対応しているわけではないため、Unicode
で定義された文字をすべて使用できるわけでは
ない。
Windows Server 2003までのOSでは、JIS
Windowsで扱うことができる 文字コード
D842h
（上位サロゲート）
＋ DF9Fh 20B9Fh叱
第2面
（下位サロゲート）
上位サロゲートD800h～DBFFh （1024個）
＋
BMP（第0面）
下位サロゲートDC00h～DFFFh （1024個）
BMP（第0面）第1面
第1面～第16面
1面65536文字×16面=1,048,576文字
文字コードを計算※
※第1面～第16面に収録されている文字コードは以下の数式で計算 文字コード値＝（上位サロゲート－D800h）×400h＋（下位サロゲート－DC00h）＋10000h
図2：サロゲート文字の仕組み
表4：Unicodeのバージョンと日本語の符号化文字集合との対応関係
Unicode バージョン 収録文字数 日本語の符号化文字集合との対応
Unicode 1.0.0 7,161 JIS X 0201 に対応
Unicode 1.0.1 28,359 JIS X 0208、JIS X 0212 に対応
Unicode 2.0 34,233 サロゲートペアの仕様が導入され、収録可能な文字数が増加。また、結合文字も仕様として定義
実際にはサロゲート文字は割り当てられていなかった
Unicode 2.1 38,950
Unicode 3.0 49,259
Unicode 3.1 94,205 JIS X 0213:2004に一部対応
Unicode 3.2 95,211 JIS X 0213:2004に正式対応
サロゲートペアに文字を割り当て
Unicode 4.0 96,447
Unicode 5.0 99,089
DB Magazine 2010 January
の文字コード徹・底・研・究
特集1
RDBMS
X 0213で新たに追加された文字に対応してい
ないため注1、OS間でUnicodeのバージョンによ
る文字の違いは明らかにならなかった。しかし、
Windows VistaでJIS X 0213に対応したフォン
トが用意されたことで、Windows XPからWind
ows Vistaへ移行する場合やWindows XPと
Windows Vistaが共存する環境において文字
の違いによる影響がある（一般には「JIS2004対
応」と呼ばれている。SQL ServerにおけるJIS
2004対応については後述する）。
SQL Serverにおける文字コードの扱い
SQL Serverでは、文字コードの扱いは非
UnicodeとUnicodeで異なる。非Unicodeのデ
ータ型にはchar型、varchar型、varchar（max）
型、text型があり、Unicodeのデータ型にはnch
ar型、nvarchar型、nvarchar（max）型、ntext
SQL Serverのデータ型と 文字コードの関係
型がある。それぞれのデータ型の特徴は表6に
示すとおりである。
非Unicodeデータ型の文字コードは、列の照
合順序注2によって決まる。日本語を扱う場合は
「Japanese」「Japanese_90」や「Japanese_XJI
S_100」など、「Japanese」からはじまるWindows
照合順序を選択する（画面1）。その際の文字
コードはMS漢字コードとなる。
SQL Serverでは、Unicodeのデータ型と非
Unicodeのデータ型では長さの単位が異なる。
charなどの非Unicode型はバイト数を表わし、
ncharなどのUnicode型のデータは文字数を表
わす。例えば、char（5）の列とnchar（5）の列
に文字列“あいうえお”を挿入する場合について
考える。“あいうえお”は全角5文字、データサイ
画面1：列の照合順序の設定画面
注1：�Windows XPやWindows Server 2003は技術仕様としてUnicode 3.1に準拠している。Unicode 3.1ではJIS X 0213:2004の一部文字が収録されている。ただし、追加された文字に対応するフォントが用意されてい ない。
注2：�文字データの並べ替えや比較で使用するルール。
表6：SQL Server の文字列データ型
文字コード データ型 特徴
非Unicode char 固定長
最大8,000バイト分の文字を格納できる
varchar 可変長
最大8,000バイト分の文字を格納できる
varchar（max） 可変長
最大2,147,483,647文字（上限2GB）を格納できる
SQL Server 2005以降で使用可能
text型の代替機能
text 可変長
最大2,147,483,647文字（上限2GB）を格納できる
SQL Server 2005以降のバージョンでは非推奨（varchar（max）型を使用する）
Unicode nchar 固定長
最大で4,000文字（8,000バイト）分のデータを格納できる※
nvarchar 可変長
最大で4,000文字（8,000バイト）分のデータを格納できる※
nvarchar(max) 可変長
最大1,073,741,823文字（2GB）を格納できる
SQL Server 2005以降で使用可能
ntext型の代替機能
ntext 可変長
最大1,073,741,823文字（2GB）を格納できる
SQL Server 2005以降のバージョンでは非推奨（nvarchar（max）型を使用する）
※ サロゲート文字や結合文字は1文字で4バイト以上の領域が必要であるため、これらの文字を使用する場合、最大文字数は少なくなる
表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文字の全フォントを実装していないため表示できない文字もある
Windows NT 3.1
Windows NT 4.0
Windows 2000
Windows Server 2003
Windows Server 2008
Windows XP
Windows Vista
Windows 95
Windows 9x 系Windows NT 系
Windows 98
Windows ME
図3：Windows OSの系譜
DB Magazine 2010 January
MS漢字コードとUnicodeの使いこなしがカギ
2Windows OSに依存するSQL Server文字コードの仕組み
ズが10バイトのため、nchar（5）への挿入は正
常に処理できるが、char（5）への挿入はエラー
となる（画面2）。
SQL Serverでは、SQLステートメント内の文
字列にUnicodeの文字を含む場合と含まない場
合とで記述方法が異なる。Unicode文字として
扱う場合は、文字列の前に「Nプレフィックス」を
付ける必要がある。
例えば「鷗」という文字は、Unicodeでは扱え
るがMS漢字コードでは扱うことができない文字
である。この文字がSQL Serverでどのように扱
われるか動作を確認した。
確認
テーブルに以下の2パターンのSQLステートメ
ントを実行し、結果を確認する。
① col1［varchar（10）］、col2［nvarchar（10）］
にUnicode型のデータを挿入
INSERT INTO TestTableVALUES (N‘森鷗外’,N‘森鷗外’)
② col1［varchar（10）］、col2［nvarchar（10）］
に非Unicode型のデータを挿入
INSERT INTO TestTableVALUES (‘森鷗外’, ‘森鷗外’)
結果
各SQLステートメントの実行結果は、画面3の
ようになる。この結果から、以下のことが分かる。
◦ MS漢字コードに存在しない文字を非Unico
de型の列に挿入すると、「？」に変換される
◦ Nプレフィックスを付けた文字列はUnicode
型の列に正常に挿入できる
◦ MS漢字コードに存在しない文字をNプレフィ
ックスを付けずにUnicode型の列に挿入すると
「？」に変換される
SQL Serverでの Unicode文字の扱い方
SQLステートメント内で文字列をUnicodeとし
て扱う場合、Nプレフィックスを付け忘れることの
ないように十分注意してほしい。
SQL ServerにおけるJIS2004対応
SQL ServerにおけるJIS2004対応として、以
下の3点が挙げられる。
JIS2004で追加された文字はMS漢字コード
では扱うことができないため、既存のchar型や
varchar型などの非Unicode型をnchar型やn
varchar型に変更する。「SQL Serverのデータ
型と文字コードの関係」の項でも述べたように、
char型とnchar型ではデータ型の長さが異なる
ため、テーブル定義の見直しや、それに伴うディ
スクサイズの見直しが必要となる。また、文字コ
ードがJIS2004を含むUnicodeに変わることによ
り、データの受け渡しを行なうアプリケーションで
もJIS2004の文字を含むUnicode対応が必要と
なる。
① Unicodeに対応した データ型に変更する
SQL Serverでは、Unicode型データを1文
字2バイトとして扱う。1文字4バイト以上のサロ
ゲート文字や結合文字を使用する場合には、以
下のような点に注意する必要がある。
（1） サロゲート文字や結合文字1文字はnchar（1）に格納できない
nchar（1）には2バイト分の文字しか格納でき
ないため、切り捨てエラーが発生する。これらの
文字を1文字格納する場合は、［文字のバイト
数］/2バイト分の長さが必要となる（例えば、4バ
イトのサロゲート文字では長さが2必要となる）。
（2） ワイルドカードではサロゲート文字や 結合文字を正しく扱えない
Transact-SQLで提供されているワイルドカー
ドのうち、任意の1文字を示すワイルドカード
（“_”）や指定した範囲の1文字に一致するワイル
ドカード（“［ ］”)、指定した範囲の1文字に一致
しないワイルドカード（［^］）ではサロゲート文字を
指定できない。例えば、サロゲート文字を含む
「叱る」はワイルドカード“_る”で検索できない（“__
る”や“%る”では検索できる）。この動作は、ワイ
ルドカードで想定されている1文字がnchar（1）
② サロゲート文字や結合文字が 含まれる文字列の扱い方を見直す
画面2：データ型による格納可能なデータサイズの違い
画面3： Nプレフィックス有無による実行結果（左： ①の実行結果、右：②の実行結果）
DB Magazine 2010 January
の文字コード徹・底・研・究
特集1
RDBMS
に相当するためである。
なお、ワイルドカードによる文字列比較の際に
も以前のバージョンのWindows照合順序「Japa
nese」ではサロゲート文字を正しく比較できない
ため、注意が必要である。
（3） 既存の文字列操作関数でサロゲート文字や結合文字を正しく扱えない
Transact-SQLで提供されている文字列操作
関数は、Unicodeデータ型を1文字2バイトで扱
う。そのため、1文字4バイト以上のサロゲート
文字や結合文字でこれらを使用すると、意図し
た文字列操作ができない。
画面4は、例として文字列操作関数LEN（）
でサロゲート文字「叱」を含む文字列の文字数
を表示した結果である。本来は2文字として扱
われる文字が3文字として扱われていることが分
かる（サロゲート文字や結合文字により影響を受
ける文字列操作関数とその影響は表7を参照）。
この影響への対応策としては、CLRユーザー
定義関数を使用してサロゲート文字や結合文字
に対応した関数を新しく作成するという方法があ
る。CLRユーザー定義関数のサンプルをマイク
ロソフトが「SQL Serverオンラインブック」で公開
している注3。
SQL Server 2000のWindows照合順序「Ja
panese」では、JIS2004で追加された文字に重
み値注4が付与されていない文字があり、これら
の文字の並べ替えおよび比較を正しくできない。
一方、SQL Server 2008で新しく提供されたWi
ndows照合順序「Japanese_XJIS100」では、こ
れらの文字に重み値が付与されているため、文
字の並べ替えおよび比較が正しくできる。
画面5は、JIS2004で追加された文字（�、
�、�、�）が「Japanese」の列（col1）と照合順
序が「Japanese_XJIS100」の列（col2）で検索
③最新の照合順序に変更する
した結果である。「Japanese_XJIS100」では条
件に一致する�のみが返されるが、「Japanese」
の場合は条件に合致する�のほかに�、�、�
も結果として返される。
同様に、Transact-SQLで提供されているRE
PLACE関数でも、重み値が設定されていない
文字を同一と判断して、すべて置き換えるという
影響がある。
このように、旧バージョンのWindows照合順
序を使用すると正しく扱うことができない文字が
あるため、JIS2004対応時には照合順序を最新
のWindows照合順序にする。
以上がSQL ServerにおけるJIS2004対応の
ポイントである。SQL Serverとは直接関係ない
が、JIS2004対応でもう1つポイントとなる文字の
表示についても解説しよう。
既存システムにWindows Vistaが加わること
で、表8にあるようにOS間のフォントが異なり、同
じ文字が異なる字体で表示されることやJIS2004
で追加された文字を旧バージョンのOSでは表示
できないといった影響がある。この影響への対
応策は、マイクロソフトがWindows XPおよび
Windows Server 2003向けに提 供している
「MS ゴシック＆MS 明朝JIS2004対応フォント」
を適用することである。このフォントを適用するこ
とで、字形や追加された文字を表示できる注5。
ここまで、SQL ServerにおけるJIS2004対応
のポイントを解説したが、マイクロソフトがJIS20
04対応に関するホワイトペーパーを公開してい
る。併せて一読すれば、より理解が深まるだろう。
表8：Windows XP/Server 2003搭載フォントからの変更点
特徴 説明
一部の文字の字形が変更されている MSゴシック382文字（非漢字100文字、漢字282文字）MS明朝303文字（非漢字90文字、漢字213文字）
（例 ： 味噌 → ）1082文字追加（非漢字173文字、漢字909文字）非漢字2文字削除
文字が追加／削除されている
サロゲート文字が使用可能 16ビットの2つのコードを組み合わせて1つの文字として表現する（例 ： 0xD840と 0xDC0Bを組み合わせた など）
結合文字の使用が可能 16ビットの基底文字と16ビットの結合文字を組み合わせて1文字として表現する（例 ：「ト」と半濁点を結合した など）
注3：�http://msdn2.microsoft.com/ja-jp/library/ms160903.aspx
注4：�文字の並べ替えなどをする際、順序を決めるときに使われる値。
注5：�Windows Vista 向け「JIS90互換MS ゴシック＆MS明朝フォントパッケージ」をインストールすることにより、Windows Vista以前のOSと同一表示にすることもで きる。
表7：サロゲート文字や結合文字により影響を受ける文字列関数
関数名 関数の機能 サロゲート文字や結合文字を使用することによる影響
LEN（） 文字数を表示する 正しい文字数を得ることができない
LEFT（） 文字列の左から指定した文字数を取り出す 指定した文字数よりも返される文字が少ない。また、上位(下位)サロゲートのみが指定されると、文字を正しく表示できない
RIGHT（） 文字列の右から指定した文字数を取り出す
SUBSTRING（） 文字列を指定の位置から指定した文字数取り出す
STUFF（） 文字列の指定した位置から指定の文字数に置き換える 置き換える文字の開始位置を正しく指定できない
REVERSE（） 文字列を逆に並べ替える サロゲート文字は上位サロゲートと下位サロゲートの組み合わせが逆になるため正しく表示できない。また結合文字は1文字目と2文字目が逆になり、それぞれ別の文字として扱われる
画面5：照合順序の違いによる動作比較
照合順序 Japanese_CI_ASで比較した結果
照合順序 Japanese_XJIS100_CI_ASで比較した結果
画面4：文字列操作関数の実行例
DB Magazine 2010 January
MS漢字コードとUnicodeの使いこなしがカギ
2Windows OSに依存するSQL Server文字コードの仕組み
◦ JIS X 0213:2004 / Unicode 実装ガイド
http://download.microsoft.com/download
/e/3/c/e3c1a451-1882-49fe-86a8-e25
680f6c46c/JIS_Unicode_guide.pdf
◦ SQL ServerのJIS2004対応に関するガイドライン
http://www.microsoft.com/downloads/det
ails.aspx?FamilyId=E942342A-719F-484
1-A9D2-F6D9FD58299F&displaylang=ja
SSIS使用時に発生する文字コード変換
システム間でデータのやりとりを行なう際に、シ
ステム間の文字コードが違うため明示的に文字
コード変換をする場合がある。一方、開発者が
意識しないところで文字コードが自動的に変換さ
れ、思わぬ問題が発生する場合もある。ここで
は、Windows上のOracleのデータをSQL Serv
er Integration Services（以下、SSIS）を用い
てSQL Serverにコピーする場合を紹介する。
SSISとは、SQL Server 2005以降のSQL Se
rverで標準提供されているETLツールで、SQL
Server 2000までのデータ変換サービス（DTS）
の後継機能であり、Oracleなどの他データソー
スと連携できる機能を持つ（図4）。
SSISは内部に独自でデータ型を持っており、
接続するDBMSの種類やデータ型、接続に使
用するプロバイダによって使用するデータ型を決
める。例えば、表9のようにマイクロソフトが提供
しているSQL Server Native Clientを使用して
SQL Serverのvarchar型に接続する場合はD
T_STR型に、オラクルが提供しているOracle P
rovider for OLE DBを使用してOracleのvarc
har2型に接続する場合はDT_WSTR型になる。
SSISでOracle Provider for OLE DBを使用
してOracle のvarchar2型（MS漢字コードの文
字を格納）よりデータを取り込み、SQL Server
Native Clientを使用してSQL Serverのvarch
ar型にデータをコピーしようとする。Oracleより
SSISにデータを取り込む際にSSIS内のDT_
WSTR型に取り込む必要があるため、MS漢字
コードからUnicodeに変換される。一方、SQL
Serverにデータをコピーする場合には、DT_
STR型にSSIS内で変換する（図5。内部デー
タ型を変換するために、SSISで標準提供されて
いる「データ型変換タスク」を使用する）。
この構成において、MS漢字コードで扱うこと
ができる文字の多くはSQL Serverへコピーでき
るが、特定の文字によってはUnicodeからMS
漢字コードに変換できない場合がある（波ダッシ
ュ文字［U＋301C、WAVE DASH］など）。
このように、SSISは内部で独自のデータ型を
保持しており、入出力で使用するデータ型やプ
ロバイダの組み合わせ次第では開発者が気づ
かないところで文字コードが変換されていること
がある。そのためにも、SSISで使用するデータ
型とプロバイダの組み合わせを事前に検討して
おくことが重要である。
＊ ＊ ＊
以上、パート2ではSQL Serverと文字コード
の関係について説明した。SQL Serverで扱う
文字コードは、Windows OSに依存して決まる。
扱うデータの文字コードによって、データ型の使
い分けやSQLステートメントの記述に注意しなけ
ればならない。
また、SQL ServerにおけるJIS2004対応と
SSISにおける文字コード変換についても説明し
たが、Windows VistaでJIS2004に対応がなさ
れ、新たに追加された文字が既存システムに影
響を及ぼす可能性がある。JIS2004については
今後、Windows XPのサポート停止などに伴っ
て対応するケースが増えていくだろう。
SQL Serverにおける文字コードの扱いにつ
いて、本パートが読者の理解の一助になれば幸
いである。 DBM
岡田朋之�（おかだともゆき）日本ユニシス株式会社へ入社後、サードパーティ製ETL/BIツールの社内向けサポートを担当。現在はSQL Serverを使用したシステム構築支援や技術評価を担当している。
森嶋荘一郎�（もりしましょういちろう）日本ユニシス株式会社へ入社後、主にアプリケーション開発畑を歩む。近年、SQL Serverの構築支援、技術支援を担当。アプリケーションからSQL Serverまで一気通貫したチューニングを得意とする。
表9：SSISのデータ型とDBMSのデータ型の対応関係（一部）
SSIS の内部データ型 SQL Server Native Client
Oracle Provider for OLE DB
DT_STR ※1 charvarchar
DT_WSTR ※2 ncharnvarchar
charvarchar2ncharnvarchar2
※1 CP932 の文字を格納するデータ型※2 Unicode の文字を格納するデータ型
Oracle（Windows）
SQL Server（Windows）
SSIS
図4：SQL ServerとOracleとのSSIS連携時の構成例
Oracle Provider for OLE DB
SQL ServerNative Client
Oracle SQL Server
データ型変換タスク
DT_STR（MS漢字コード）
varchar型（MS漢字コード）
varchar2型（MS漢字コード）
DT_WSTR（Unicode）
SSIS
図5：OracleとSQL ServerとのSSIS連携時の文字コード遷移