2 特集 1 徹 底 研 究 の文字コード MS 漢字コードと Unicode の使いこなしがカギ パート 2 では Microsoft SQL Server の文字コードについて解説する SQL Server で扱える文字コ ードは ため 扱うデータの文字コードによってデータ型の使い分けなどに注意す る必要がある そこで本パートでは SQL Server で使用できる文字コードである MS 漢字コード ( マイク ロソフトが策定 ) と Unicode の解説を中心に SQL Server のデータ型との関係 JIS2004 対応 SQL Server Integration Services(SSIS) における文字コード変換などについて紹介する 日本ユニシス株式会社岡田朋之 OKADA, Tomoyuki / 森嶋荘一郎 MORISHIMA, Shoichiro 文字コードの基礎 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でそれぞれ別の文字コードに符号化できる 表 3 : 文字集合と文字コードとの関連 文字集合 文字符号化方式 文字コード JIS X 0201 SHIFT_JIS シフトJIS JIS X 0208 EUC-JP 日本語 EUC 文字 表 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 世界中の文字と記号 文字 図 1 : 文字から文字コードへの対応付け 文字 文字コード 表 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 ISO-2022-JP 半角カナを除く JIS X 0201 JIS X 0208 1~2 1~2 UNIX で使用される 電子メールなどで使用される
MS 漢字コードと Unicode の使いこなしがカギ 2 表 4 : Unicode のバージョンと日本語の符号化文字集合との対応関係 BMP( 第 0 面 ) 上位サロゲート D800h~DBFFh ( 1 0 2 4 ) D842h ( 上位サロゲート ) BMP( 第 0 面 ) 下位サロゲート DC00h~DFFFh ( 1 0 2 4 ) DF9Fh ( 下位サロゲート ) 文字コードを 第 1 面 ~ 第 16 面 第 1 面 1 面 65536 文字 16 面 1,048,576 文字 20B9Fh 第 1 面 ~ 第 16 面に収録されている文字コードは以下の数式で 文字コード ( 上位サロゲート D800h)400h( 下位サロゲート DC00h)10000h 第 2 面 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 サロゲートペアに文字を割り当て 図 2 : サロゲート文字の仕組み 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の場合 Windows 9x 系はMS 漢字コードを Windows NT 系の OSはUnicodeをそれぞれ内部コードとして使用している 図 3のように Windows NT 系と Win dows 9x 系はWindows XPで統合され 以降 Windowsの内部コードは Unicodeを使用している Windows NT 系で使用できる文字集合は 表 5のとおり各 OSの内部コードで使用した Uni codeバージョンに従っており 文字符号化方式はUTF-16を使用している ただし 文字集合に関しては Windowsで標準搭載されているフォントが Unicodeの各バージョンの文字集合すべてに対応しているわけではないため Unicode で定義された文字をすべて使用できるわけではない Windows Server 2003までのOSでは JIS
特集 1 徹 底 研 究 の文字コード X 0213で新たに追加された文字に対応していないため注 1 OS 間でUnicodeのバージョンによる文字の違いは明らかにならなかった しかし Windows VistaでJIS X 0213に対応したフォントが用意されたことで Windows XPから Wind ows Vista へ移行する場合や Windows XPと Windows Vistaが共存する環境において文字の違いによる影響がある ( 一般には JIS2004 対応 と呼ばれている SQL Serverにおける JIS 2004 対応については後述する ) 型がある それぞれのデータ型の特徴は表 6に示すとおりである 非 Unicodeデータ型の文字コードは 列の照合順序注 2 によって決まる 日本語を扱う場合は Japanese Japanese_90 や Japanese_XJI S_100 など Japanese からはじまる Windows 照合順序を選択する ( 画面 1) その際の文字コードは M S 漢字コードとなる SQL Serverでは Unicodeのデータ型と非 Unicodeのデータ型では長さの単位が異なる charなどの非 Unicode 型は数を表わし ncharなどの Unicode 型のデータは文字数を表わす 例えば char(5) の列とnchar(5) の列に文字列 あいうえお を挿入する場合について考える あいうえお は全角 5 文字 データサイ 注 1:Windows XP や Windows Server 2003 は技術仕様として Unicode 3.1 に準拠している Unicode 3.1 では JIS X 0213:2004 の一部文字が収録されている ただし 追加された文字に対応するフォントが用意されていない 注 2: 文字データの並べ替えや比較で使用するルール SQL Server における文字コードの扱い SQL Server のデータ型と文字コードの関係 SQL Serverでは 文字コードの扱いは非 UnicodeとUnicodeで異なる 非 Unicodeのデータ型には char 型 varchar 型 varchar(max) 型 text 型があり Unicodeのデータ型には nch ar 型 nvarchar 型 nvarchar(max) 型 ntext 表 6 : SQL Server の文字列データ型 文字コードデータ型特徴 非 Unicode char 固定長 varchar varchar(max) text 最大 8,000 分の文字を格納できる 最大 8,000 分の文字を格納できる 最大 2,147,483,647 文字 ( 上限 2GB) を格納できる SQL Server 2005 以降で使用可能 text 型の代替機能 Unicode nchar 固定長 最大 2,147,483,647 文字 ( 上限 2GB) を格納できる SQL Server 2005 以降のバージョンでは非推奨 (varchar (max) 型を使用する ) Windows Windows NT 3.1 Windows NT 4.0 Windows 2000 Windows Server 2003 Windows XP Windows Server 2008 Windows Vista 図 3 : Windows OS の系譜 Windows Windows 95 Windows 98 Windows ME nvarchar nvarchar(max) ntext 最大で 4,000 文字 (8,000 ) 分のデータを格納できる 最大で 4,000 文字 (8,000 ) 分のデータを格納できる 最大 1,073,741,823 文字 (2GB) を格納できる SQL Server 2005 以降で使用可能 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 文字の全フォントを実装していないため表示できない文字もある 画面 1 : 列の照合順序の設定画面
MS 漢字コードと Unicode の使いこなしがカギ 2 ズが 10 のため nchar(5) への挿入は正 常に処理できるが char(5) への挿入はエラー となる ( 画面 2) SQL Server での Unicode 文字の扱い方 画面 2 : データ型による格納可能なデータサイズの違い SQL Serverでは SQLステートメント内の文字列にUnicodeの文字を含む場合と含まない場合とで記述方法が異なる Unicode 文字として扱う場合は 文字列の前に Nプレフィックス を付ける必要がある 例えば 鷗 という文字は Unicodeでは扱えるが MS 漢字コードでは扱うことができない文字である この文字が SQL Serverでどのように扱われるか動作を確認した 確認テーブルに以下の 2 パターンの SQLステートメントを実行し 結果を確認する 1 col1[varchar(10)] col2[nvarchar(10)] に Unicode 型のデータを挿入 INSERT INTO TestTable VALUES (N 森鷗外,N 森鷗外 ) 2 col1[varchar(10)] col2[nvarchar(10)] に非 Unicode 型のデータを挿入 INSERT INTO TestTable VALUES ( 森鷗外, 森鷗外 ) 結果 各 SQL ステートメントの実行結果は 画面 3 の ようになる この結果から 以下のことが分かる MS 漢字コードに存在しない文字を非 Unico de 型の列に挿入すると? に変換される N プレフィックスを付けた文字列は Unicode 型の列に正常に挿入できる MS 漢字コードに存在しない文字を N プレフィ ックスを付けずに Unicode 型の列に挿入すると? に変換される 画面 3 : N プレフィックス有無による実行結果 ( 左 : 1 の実行結果 右 : 2 の実行結果 ) SQL ステートメント内で文字列を Unicode とし て扱う場合 N プレフィックスを付け忘れることの ないように十分注意してほしい SQL Server における JIS2004 対応 SQL Serverにおける JIS2004 対応として 以下の 3 点が挙げられる 1 Unicode に対応したデータ型に変更する JIS2004 で追加された文字は MS 漢字コード では扱うことができないため 既存の char 型や varchar 型などの非 Unicode 型を nchar 型や n varchar 型に変更する SQL Serverのデータ型と文字コードの関係 の項でも述べたように char 型と nchar 型ではデータ型の長さが異なるため テーブル定義の見直しや それに伴うディスクサイズの見直しが必要となる また 文字コードが JIS2004を含む Unicodeに変わることにより データの受け渡しを行なうアプリケーションでもJIS2004の文字を含む Unicode 対応が必要となる 2 サロゲート文字や結合文字が含まれる文字列の扱い方を見直す 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)
特集 1 徹 底 研 究 の文字コード に相当するためである なお ワイルドカードによる文字列比較の際に も以前のバージョンの Windows 照合順序 Japa nese ではサロゲート文字を正しく比較できない ため 注意が必要である (3) 既存の文字列操作関数でサロゲート文字や結合文字を正しく扱えない Transact-SQLで提供されている文字列操作関数は Unicodeデータ型を 1 文字 2で扱う そのため 1 文字 4以上のサロゲート文字や結合文字でこれらを使用すると 意図した文字列操作ができない 画面 4は 例として文字列操作関数 LEN() 注 3:http://msdn2.microsoft.com/ja-jp/library/ ms160903.aspx 注 4: 文字の並べ替えなどをする際 順序を決めるときに使われる値 注 5:Windows Vista 向け JIS90 互換 MS ゴシック &MS 明朝フォントパッケージ をインストールすることにより Windows Vista 以前のOSと同一表示にすることもできる 画面 4 : 文字列操作関数の実行例 表 7 : サロゲート文字や結合文字により影響を受ける文字列関数 関数名 関数の機能 でサロゲート文字 叱 を含む文字列の文字数を表示した結果である 本来は2 文字として扱われる文字が 3 文字として扱われていることが分かる ( サロゲート文字や結合文字により影響を受ける文字列操作関数とその影響は表 7を参照 ) この影響への対応策としては CLR ユーザー定義関数を使用してサロゲート文字や結合文字に対応した関数を新しく作成するという方法がある CLRユーザー定義関数のサンプルをマイクロソフトが SQL Serverオンラインブック で公開している注 3 3 最新の照合順序に変更する SQL Server 2000のWindows 照合順序 Ja panese では JIS2004で追加された文字に重み値注 4 が付与されていない文字があり これらの文字の並べ替えおよび比較を正しくできない 一方 SQL Server 2008で新しく提供された Wi ndows 照合順序 Japanese_XJIS100 では これらの文字に重み値が付与されているため 文字の並べ替えおよび比較が正しくできる 画面 5は JIS2004で追加された文字 ( ) が Japanese の列 (col1) と照合順序が Japanese_XJIS100 の列 (col2) で検索 サロゲート文字や結合文字を使用することによる影響 L E N( ) 文字数を表示する正しい文字数を得ることができない L E F T( ) 文字列の左から指定した文字数を取り出す 指定した文字数よりも返される文字が少ない ま RIGHT() 文字列の右から指定した文字数を取り出す た 上位 ( 下位 ) サロゲートのみが指定されると 文字を正しく表示できない SUBSTRING() 文字列を指定の位置から指定した文字数取り出す S T U F F( ) 文字列の指定した位置から指定の文字数に置き換える置き換える文字の開始位置を正しく指定できない REVERSE() 文字列を逆に並べ替える サロゲート文字は上位サロゲートと下位サロゲートの組み合わせが逆になるため正しく表示できない また結合文字は1 文字目と2 文字目が逆になり それぞれ別の文字として扱われる した結果である Japanese_XJIS100 では条件に一致する のみが返されるが Japanese の場合は条件に合致する のほかに も結果として返される 同様に Transact-SQLで提供されている RE PLACE 関数でも 重み値が設定されていない文字を同一と判断して すべて置き換えるという影響がある このように 旧バージョンの Windows 照合順序を使用すると正しく扱うことができない文字があるため JIS2004 対応時には照合順序を最新のWindows 照合順序にする 以上が SQL Serverにおける JIS2004 対応のポイントである SQL Serverとは直接関係ないが JIS2004 対応でもう 1つポイントとなる文字の表示についても解説しよう 既存システムに Windows Vistaが加わることで 表 8にあるように O S 間のフォントが異なり 同じ文字が異なる字体で表示されることや 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 文字として表現する ( 例 : ト と半濁点を結合したなど ) 照合順序 Japanese_ CI_AS で比較した結果 照合順序 Japanese_ XJIS100_CI_AS で比較した結果 画面 5 : 照合順序の違いによる動作比較
MS 漢字コードと Unicode の使いこなしがカギ 2 表 9 : SSIS のデータ型と DBMS のデータ型の対応関係 ( 一部 ) Oracle (Windows) SSIS SQL Server (Windows) SSIS の内部データ型 DT_STR 1 SQL Server Native Client char varchar Oracle Provider for OLE DB DT_WSTR 2 nchar nvarchar char varchar2 nchar nvarchar2 図 4 : SQL Server と Oracle との SSIS 連携時の構成例 1 CP932 の文字を格納するデータ型 2 Unicode の文字を格納するデータ型 JIS X 0213:2004 / Unicode 実装ガイド Oracle Oracle Provider for OLE DB SSIS SQL Server Native Client SQL Server http://download.microsoft.com/download /e/3/c/e3c1a451-1882-49fe-86a8-e25 varchar2 型 (MS 漢字コード ) DT_WSTR (Unicode) データ型変換タスク DT_STR (MS 漢字コード ) varchar 型 (MS 漢字コード ) 680f6c46c/JIS_Unicode_guide.pdf 図 5 : Oracle と SQL Server との SSIS 連携時の文字コード遷移 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 まで一気通貫したチューニングを得意とする