はじめに
職種柄、色んな講演を聞く機会があるのですが、今年の感動したものの1つにベルデータ安井様の「基礎的な文字コードの話」があります。
IBM i のCCSID問題ってよく聞くけど、よくわからない。。。というモヤモヤが晴れた講演でしたので、その際に取ったメモとその後先輩に教えてもらったこと含めの自己調べ&まとめを綴ります。
さっくり読める記事にしたつもり！
そもそも文字コード(コードページ)とは
コンピューターは、人間が読むような「文字」をそのまま扱うことができません。
理解できるのは0と1の数値だけです。
そのため「A」「あ」「😊」といった文字は、内部ではすべて数値に変換されています。
この 「どの文字をどの数値に対応させるのか？」を決めたルールが文字コードです。
代表的な文字コードの種類
文字コードには複数の規格があり、それぞれで文字と数値の対応関係が異なります。
- ASCII：英語圏での基本的な文字コード
- Shift-JIS：日本語で長年使われてきた文字コード
- UTF-8（Unicode）：Web で最も普及した国際規格
- EBCDIC：この記事の主役！IBMが作った文字コード体系、IBM i やメインフレームでよく出てくる
数値は16進数が使われること一般的、例えば「A」は以下のように異なります。
| 文字コード | 数値 |
|---|---|
| ASCII / UTF-8 | 0x41 |
| EBCDIC | 0xC1 |
同じ文字でも数値が変わるため、適切な文字コードを使うことが重要です。
EBCDICの文字コード表
ホスト・コード・ページ解説書にあります。
IBM i の日本語環境では、1バイト文字（SBCS）と、2バイト文字（DBCS）の2種類があります。
シフトイン・シフトアウトで切り替えるやつです。
日本人の私たちがよく耳にする代表的な文字コード(コードページ)を下に羅列します。
1バイトの文字コードページ
1バイトとは半角カタカタとかアルファベットとか数字とかとか、''で囲まなくても入るやつ。1バイト＝8ビットなので、2⁸＝256通りの組合せで文字を表せる。
1バイトの日本語が絡んでくる文字コードページは主に2つです。
-
コードページ 290 ：カタカナ優先で英小文字が独自配置
- 数字・英大文字＋カタカナが中心で、英小文字はもともと存在しなかった
- その後、拡張されて英小文字が追加
- そのため割り当て位置は 290 独自 → 英語圏との互換性が弱い（ ; ; ）
-
コードページ 1027：アルファベット優先、空いたところに半角カタカナ
- 英大小文字が ASCII と連続した領域に配置
- 英語圏環境や英語ベース製品と相性が良い
- カタカナは空き領域に配置
2バイトの文字コードページ
2バイト文字は漢字とかハングルとかタイ語とかアジア圏の言葉に加えて、①、②、㈲、㈹、㎏、㎞、㎡、㍍、㍻ などこの辺りを表すためのものです。2バイト＝16ビットで、2¹⁶＝65,536通りの組合せで文字を表せる。多い！
日本語が絡んでくる2バイト文字コードページは300です。
コードページ300には2種類あります。
(ホスト・コード・ページ解説書には載っていないです。)
新旧 300 があり、扱える文字数が異なります。
- コードページ旧300：第一・第二水準漢字＋非漢字 → 計 6,879 文字
- コードページ新300：扱える文字が多い。第三・第四水準漢字まで含む → 約 16,000 文字
CCSID（文字セット識別子)とは
ここから本題！
代表的な日本語でよく出てくるCCSIDは以下1バイトコードページと2バイトコードページの組み合わせになっています。
IBM i の日本語 CCSID は1バイト文字（SBCS）と2バイト文字（DBCS）の2種類を組み合わせて1つの日本語環境として扱います。
| CCSID | 1バイト文字 | 2バイト文字 | 特徴 |
|---|---|---|---|
| 5026 | コードページ290 | 旧300 | AS400の時代に普及した |
| 5035 | コードページ1027 | 旧300 | 英語環境と互換性が高い |
| 1399 | コードページ1027 | 新300 | ③④㍻などもOK、扱える文字が多い |
文字コードとしては、5035もしくは1399が外部連携をする場合はおすすめということです。
CCSID 65535ってなに、、、？
出荷時のシステム上の文字コード(QCCSID)は65535です。
65535は文字コードを持たないという意味です。
文字コードを持たないって言われても、、、ってなるので、接続時点で使用される文字コード(CCSID)は、ジョブの文字コード(CCSID)を参照します。
ジョブの文字コード(CCSID )はどう決まる？
IBM i 上の「ジョブ CCSID」は、以下の優先順位で決まります。
- ユーザープロファイルの CCSID
- システム上の文字コード(QCCSID)
- LANGID（OSの基本言語）
まず、投入されたジョブは「1.ユーザープロファイルのCCSID」を見に行きます。そこで1399とか指定がされていれば、そのCCSIDに落ち着きます。
一方、*SYSVALになっていた場合、「2.システム上の文字コード(QCCSID)」を見にいくのです。
そして、QCCSIDが65535だった場合は、「文字コードなし」になるので、「3.LANGID」を見にいきます。
日本語環境（LANGID＝JPN）では、DFTCCSID＝5026 が採用されるのが一般的です。
なので、65535だと5026で実行されていることが多いわけです。
CCSID 65535はなぜ困る？
ずばり、外部接続をする際に文字が定義されていないので困ります！
ジョブもしくは物理/論理ファイルのCCSID が65535の場合、IBM i は文字コードが定義されていないと、接続先は読み取るので、、、
- VS codeやRDiなど開発ツール → データを文字として扱えない
- SQL → データの並び替え・比較ができない（文字列として認識できない）
- API 呼び出し → 不正な文字データと判断される
など、トラブルの原因になります。
5250エミュレーターのホストコードページ
ACSとかIBM CloudからIBM i のコンソール開く時、エミュレーターのコードページ指定しますよね。
現代の端末(PC)は Unicode ベースで動作するため、IBM i（EBCDIC）とは文字コードが異なります。
そこで5250 エミュレーターは、Unicode（PC側） ⇔ EBCDIC（IBM i側）の翻訳を行います。
そのときに参照するのが ホストコードページ です。
930：日本語（拡張カタカナ）、939：日本語（拡張ローマ字）、1399：（Latin Unicode拡張）とか指定しますよね。
設定を間違えると、英小文字が入力できない、表示が「□□□□」になる、保存時に文字化けする、、、といった問題が発生します。
例えば、ホストコードページ930を指定すると、5250エミュレーターは、「IBM i の文字コード5026を変換するぞ！」と待機します。
しかし、IBM i 側の文字コードが5035だとすると、ホストコードページが知らない文字が送られてきます、そしてどう翻訳していいかわからなくなり文字化けするわけです。
対応しているCCSIDとホストコードページをさっき上げた表に追記するとこうなります。
| CCSID | 1バイト文字 | 2バイト文字 | 特徴 | ホストコードページ（ACS） |
|---|---|---|---|---|
| 5026 | コードページ290 | 旧300 | AS400の時代に普及した | 930日本語（カタカナ / 拡張カタカナ) |
| 5035 | コードページ1027 | 旧300 | 英語環境との互換性が高い | 939 日本語（拡張ローマ字） |
| 1399 | コードページ1027 | 新300 | ③④㍻などもOK、扱える文字が多い | 1399 日本語（Latin Unicode拡張 / JIS 2004） |
(コードページとホストコードページって若干別ニュアンスの言葉だったんですね、、、知らなかった。。。)
参考
感動した講演の資料、i worldの会員登録(無料)必要ですが、ぜひ本家見てほしい。
録画出るといいんだけどな〜
安井様の記事たち