IBM i のウンチクを語ろう：その107
－ わかっているようでわかっていない文字コードの話 ～ 5250エミュレータ事情 －
皆さん、こんにちは。前回はIBM i が採用するEBCDICと呼ばれる文字コード事情を説明いたしました。書き始めるまではエミュレータとの関わり合いまで一気に仕上げるつもりだったのですが、きちんと説明しようとEBCDICの特徴だけでなくその起源にまで言及していたら、想定以上の分量になってしまいました。そこでやむなく一旦中途で切り上げ、元々書こうと思っていたエミュレータ事情については、今回の後編に委ねることにした次第です。テーマを設定すれば凡その分量は見極められると思っていたのですが、前回は見事に外してしまいました。
IBM i の文字コードを初めて意識する機会があったとしたら、多くの方にとっては5250エミュレータというソフトウェアの利用を通じてだったのではないでしょうか。エミュレータ（emulator）とはエミュレート（emulate）の派生語で、「（他の何かの動作を）模倣するもの」といった意味を持ちます。すなわち5250エミュレータとは、5250という型番を持つIBM i （AS/400）専用端末のように、PCを動作させるためのソフトウェア、という意味です。今でこそ端末はモバイル機器だったりPCだったりとサーバーからは独立した汎用的な存在ですが、かつてのIBM i （AS/400）では専用端末までが広義のシステムでした。この端末はIBM i からネットワーク上に送出されるEBCDIC文字情報や制御情報を、システムの一部として直接理解する機能を備えておりました。ところがPCなどの汎用端末は、Shift-JISをベースに動作しますし、IBM i から受け取るEBCDICを直接理解することはできませんので、何かを利用してShift-JISへの「同時通訳」を行わなければなりません。逆にPCのShift-JIS環境で入力された情報を、EBCDICに「同時通訳」してIBM i に送信する必要もあります。エミュレータ・ソフトの役割はちょうどこの双方向に働く同時通訳者に該当します。
ちなみにIBM製品にはもう一つ、IBM i と同様にEBCDICを前提として動作するIBM Zがあります。いわゆるメインフレームです。旧来の専用端末型番は3270であり、取り扱う文字コードは5250と同じEBCDICと共通ではあるものの、その制御手順は独自のものでした。そのためIBM i 用には5250エミュレータがあるように、IBM Z用には3270エミュレータがある、ということになります。
さて、通訳が通訳として機能するためには、相手が何語を話すのかを知らなければなりません。前回コラムで参照した「ホスト・コード・ページ解説書」にあるように、EBCDICとは文字の表現方法という言わば「器の形状」であって、その内容物であるところの日本語、英語、アラビア語などといった国語言語は決定されません。この国語言語に付された識別情報がコード・ページというわけです。人間ならば相手の話し言葉を聞いて、何語なのかを判別し理解することが可能ですが、この「同時通訳者」は人間ほどの柔軟性はありません。どの国語言語を対象に通訳して欲しいのかを、通訳者にあらかじめ教えておかなければなりません。具体的にはエミュレータの構成情報の中で、適切な「ホスト・コード・ページ」、すなわちホスト（サーバー）が送受信する文字コード「コード・ページ」を設定することになります。
5250エミュレータ利用において多くの方が違和感を覚える点は、英小文字が使えない、というものではないでしょうか。この現象の原因はエミュレータのディフォルト設定に原因があるのですが、だからといって意義が正しく理解されないままに「正しい」設定が展開されると、トラブルが生じてしまうリスクをはらんでいます。継続的・安定的にビジネスをサポートしなければならない基幹業務システムにおいては、許されることではありません。やむを得ず、安全のために英小文字が使えない設定をディフォルト値にしている、といったところなのだと推測しています。どういうことなのか、少し詳しく見てみたいと思います。
前回のコラムで、IBM i の日本語環境における主なCCSIDには5026、5035、1399の3種類があると説明しました。そして日本語環境におけるディフォルト値は5026なのですが、過去に取り扱える文字の種類を増やした経緯があります。もう少し詳しく見てゆくと、CCSID 5026を構成する1バイトのコード・ページ290には新旧二つのバージョンがあり、旧290は英小文字を扱えなかったのに対して、新290ではこれを扱えるように強化されており現在に至っています。本来であればきちんと両者を識別できるようにするべきなのでしょうけれども、文字コード体系が整備される以前のことだったためなのか、5026とか２９０という値に変化は無く、表面的には両者は区別されていません。そして現在旧5026ないし旧２９０は実質的には存在していません。
文字コード関連の事情を知る上で最大の障壁の一つは、多くの概念や用語が登場するばかりでなく、時にその使い方に統一性・整合性があるとは思えないケースがあることではないかと思います。例えばサーバーと端末との間でやり取りされる文字を識別するのは、エミュレータから見れば上記のとおり「ホスト・コード・ページ」ですが、IBM i では「CCSID」という用語で表現されます。前回コラムで見たとおり、CCSIDは1バイトと2バイトのコード・ページのセットを指す言葉でした。
さらに、これに相対するエミュレータの設定情報である「ホスト・コード・ページ」の値は、以下のとおり5026とか5035ではない、というややこしさがあります。その「反省」ゆえか、最も新しいCCSID 1399に関しては整合性があります。ここで前回コラムで提示した表をもう少し詳しく表現しながら、互換の設定値をまとめると以下のようになります。
| IBM i （EBCDIC） | PC（Shift-JIS） | ||
| CCSID | 1バイト コード・ページ |
2バイト コード・ページ |
エミュレータ（ACS）における 互換の「ホスト・コード・ページ」 |
旧5026 現存せず |
旧290 英小文字含まず |
旧300 第一・二水準漢字 |
930日本語（カタカナ） |
| 新5026 現在有効 |
新290 英小文字を含む |
旧300 第一・二水準漢字 |
930日本（拡張カタカナ） |
| 5035 | 1027 英小文字を含む |
旧300 第一・二水準漢字 |
939日本（拡張ローマ字） |
| 1399 | 1027 英小文字を含む |
新300 第三・四水準漢字を含む |
1399日本語（Latin Unicode拡張） 1399日本語（Latin Unicode拡張, JIS 2004） |
上記「新5026」の行をご覧いただければわかるとおり、エミュレータのホスト・コード・ページを「930日本（拡張カタカナ）」に設定すれば英小文字が扱えるはずであることがわかります。ここで注意しておきたいのは、コード・ページ930には「カタカナ」版と「拡張カタカナ」版とがあるということです。前者が古く、後者が新しい、という関係にあります。まとめると、IBM i のCCSID旧５０２６は旧２９０によって構成され、エミュレータの「930日本語（カタカナ）」と互換性があり、英小文字が使えません。新5026は新290によって構成され、「930日本（拡張カタカナ）」と互換性があり、英小文字を使えます。
英小文字を扱えるはずの新5026に対して、「930日本語（カタカナ）」が設定されていたら、エミュレータが扱えるアルファベットは大文字に限定されますので、英小文字が入力ないし出力されることはありません。出力しようとすると、EBCDICからShift-JISに変換できない文字として「・」（中黒）が表示されます。これがエミュレータでは英小文字が扱えないとされる現象です。
この状況を改善するために、「ホスト・コード・ページ」を「930日本（拡張カタカナ）」に設定し直すことが一見簡単な解決策になりそうですが、テスト環境ではない限り迂闊に取り組むのは避けた方が安全です。英小文字が「930日本（拡張カタカナ）」設定のPCから入力され、IBM i に蓄えられるかもしれません。何らかの理由でこのデータを「930日本語（カタカナ）」設定のPCから参照しようとすると、ちょうど上記の「・」が表示される状況が再現されることになります。エミュレータのホスト・コード・ページのディフォルト値が「930日本語（カタカナ）」設定のまま変更されないなのは、この混乱を避けようという狙いがあったのではないかと想像しています。
文字コードにまつわる問題というのは、見た目はシンプルでありながら、その裏側の仕組みに目を向けると意外に根深いようです。そして文字化けが生じた場合に、どの文字が化けているのかによって、解決のために目を向ける領域が異なってきます。英小文字ならば今回コラムで述べたように、新旧ホスト・コード・ページの設定に関わる可能性、第三・四水準漢字ならばCCSID 1399 に関わる領域を疑うところから始めよう、といった具合です。原因を探り解決策を考えるのは、パズルを解くようなものなのかもしれません。
ではまた
