IBM iの文字コードを考える ~EBCDICとUnicode|既存資産を活かしつつ、新しいニーズに応える(短期連載 1)

IBM iの文字コードは、長らくEBCDIC が使われてきた。IBM iのデフォルトとも言えるこの文字コードは今も、多くの基幹システムを支えている。その一方、IBM iとオープン系システムの連携や、IBM iをデータベースサーバーとして活用するニーズが高まるなか、IBM iでUnicodeを使用することに注目が集まっている。文字コードの歴史をあらためて振り返りつつ、IBM i環境でのEBCDICの基本とUnicodeの扱い方法を解説する。著者は、日本IBMの三神雅弘氏。3回に分けて掲載します。

第1回 文字コードについて ~その歴史と役割
第2回 IBM iの日本語環境 ~EBCDIC編
第3回 IBM iの日本語環境 ~Unicode編

 

 

 

 

 

文字コードについて
その歴史と役割

 私たちが情報システムを通してデータを扱う場合、人が認識できるデータ(文字、画像、音声など)を、コンピュータで扱えるデジタルデータ(2進数)へ変換する必要がある。これらのデータのなかでも、文字はデータとしての扱いに加えて、コンピュータへの指示(コマンドやプログラム)としても使用する基本である。

 コンピュータで文字を扱うための文字コードは、機種やOSなどによるさまざまなコード体系、各国語の固有の文字を表現するためのコード拡張などに対応してきた結果、多くの文字コードが生まれることになった。

 多くの文字コードが存在する、すなわち1つの文字を表現するコードが複数存在することにより、「文字化け」「文字が表示されない」「プログラムが実行されない」といった問題が発生する。このような問題を回避するために、本稿では文字コードについて考えてみたい。

 文字コードとは、コンピュータが扱う2進数で文字を処理するために、文字に対して割り当てられた番号(コード)である。文字の集合とその番号の対応関係を示すものとして、文字コードと呼ばれている。

 文字コードは、ANSIやISOといった標準化団体によって定義されているが、各国でのコンピュータ利用に向け言語に応じて拡張されてきたため、数多くの文字コードが存在することになった。

 文字コードは、「符号化文字集合」と「文字符号化方式」の2つに区別される。

 符号化文字集合 (Coded Caracter Set:CCS)は、識別するための番号(コード・ポイント)を割り振られた文字の集合である。前述の文字コードと同様に使用される。代表的な符号化文字集合としては、ASCII、ISO/IEC 646、JIS X 0201などの半角文字の集合、日本語の漢字の集合であるJIX X 0208、各国で使用される文字を共通の文字集合として使用するためのUnicodeなどがある。

 一方の文字符号化方式 (Character Encoding Sche
me:CES)は、符号化文字集合の文字に割り当てられたコード・ポイントを、コンピュータ上で実際に使用するバイト列に変換するための定義である。JIX X 0208に対するISO-2022-JP、EUC-JP、Shift_JISや、Unicodeに対するUTF-8、UTF-16、UFT-32が該当する。

 以下に、代表的な文字コードについて説明しよう。

 

ASCII

 ASCII(American Standard Code for Information Interchange)は、1963年にAmerican Standards Association (ANS、後のANSI)によって定められた7ビットの文字コードである。7ビット(x‘00’からx‘7F’)のコードに、アルファベット、数字、記号と制御コードを割り当てている(図表1)。

 

 

 たとえば、“A”の16進表記はx‘41’で、“a”の16進表記はx‘61’となる。同じく2進数で表記すると、以下になる。

A:1000001
a:1100001

 ASCIIコード表でアルファベットの大文字と小文字を比べると、それぞれの大文字と小文字の下位ビットは同じで、上位ビットは差が2であることがわかる。2進数で表記すると、大文字の6ビット目を1にしたものが小文字となる。これは、大文字と小文字との間の変換は、6ビット目の値を操作するだけで可能ということである。

 米国で制定されたASCIIコードでは、定められている文字は英語のアルファベットで、通貨記号は$である。ヨーロッパ各国でコンピュータを利用する場合、ASCIIコードでは必要な文字が含まれていなかったり、通貨記号が異なっていたりするので、各国に対応するための文字コードを用意する必要がある。

 そのため、ASCIIコードをベースとする各国語対応の文字コードとして、国際標準化機構(ISO)により7ビットの文字コードISO/IEC 646が定められた。

 ただしISO/IEC 646では、ヨーロッパ各国語への対応で設定できる文字の範囲が少なかったため、あまり使用されなかった。そこでヨーロッパ各国は、8ビットに拡張された文字コードISO/IEC 8859を使用することになる。

JIS X 0201

 JIS X 0201は、1969年に日本産業規格(JIS)により定められた符号化文字集合である。ISO/IEC 646を拡張した、ラテン文字用図形文字集合と片仮名用図形文字集合の2つの文字集合である。

 7ビットおよび8ビットのコードであり、7ビットコードの場合は上位ビットのx‘21’からx‘7E’の領域をラテン文字とカタカナ文字で切り替えて割り当てる。切り替えにはシフトインとシフトアウトを用いる。

 8ビットコードの場合は、上位ビットのx‘21’からx‘7E’の領域をラテン文字、x‘A1’からx‘FE’の領域をカタカナ文字で割り当てる。

 

EBCDIC

 EBCDIC (Extended Binary Coded Decimal Interchange Code、拡張二進化十進コード)は、IBMが1964年に発表したメインフレームのSystem/360で使用するために、1963年に定められた8ビットの文字コードである。10進数を4ビットの2進数で表すBCD (Binary-Coded Decimal)を拡張する形で定義された。EBCDICコードは、IBMメインフレームおよびIBM iのようなミッドレンジシステムで使用されている。

  IBMは、文字データの表記や処理の一貫性の実現を目的とした文字コードの設計指針となる文字データ表示体系(Character Data Representation Architecture:CDRA)を定義した。

 システム内の文字表現は、CDRAによって制御される。CDRAはコード化スキームID、文字セットID、コード・ページID、および追加のエンコード関連情報によって文字を識別する。このCDRAによって文字を識別するために定義されているIDが、CCSID(Coded Character Set IDentifiers:コード化文字セットID)である。

 EBCDICは、CCSIDにより識別される符号化方法である。CCSID 37は、コード・ページ37(USA英語)である。

 日本語のCCSIDとしては5026、5035、1399などがある。CCSID 5026と5035、1399は、SBCSのコード・ページが異なる。

 またコード・ページ290とコード・ページ1027では、カタカナのコード・ポイントが異なる。

 コード・ページ290のカタカナは、英語のコード・ページ37の英小文字の部分をカタカナに割り当て、英小文字は異なるコードで割り当てられている。そのため、コード・ページ37のx‘81’の英小文字“a”は、コード・ページ290ではカタカナ“ア”で表されることになる。

 またコード・ページ1027では、英小文字のコードはコード・ページ37と同じコードに割り当てられているので、英小文字の扱いは問題ない。しかしコード・ページ290とは英小文字とカタカナの割り当てが異なるため、同じ日本語のコード・ページでもカタカナと英小文字の表記が異なる(図表2)。

 

 

 このような英小文字とカタカナの「文字化け」の問題のほかに、コード・ページ290では英小文字、大文字を区別しているプログラムが動作しない問題も発生する。IBM i でJavaやC、C++などを使用する場合には、英小文字のコードが、英語コード・ページ37と同じコード・ページ1027を使用するCCSID 5035やCCSID 1399を指定する必要がある。

 

Unicode

 文字コードは各国あるいは各メーカーがそれぞれ独自に使用するコード体系を定義してきたため、互換性のない数多くの文字コードが存在している。そこで、各国のすべての文字を1つのコード体系で示すために定められたのがUnicodeである。コンピュータ関連企業が参加するユニコードコンソーシアムにより、Unicodeが定められた。

 一方、同時期にISOによる国際規格としてISO/IEC 10646の策定が進められていた。そこで同じ目的の規格が複数存在することを避けるため、UnicodeとISO/IEC 10646を統一する作業が行われた。当初4バイトとして定義されていたISO/IEC 10646に、2バイトのUnicodeを基本多言語面(Basic Multilingual Plane :BMP)として取り込む形で、1993年に制定された。

 ISO/IEC 10646の規格名称は「Universal Multiple-Octet Coded Character Set (UCS)」で、この規格の文字コードがUCSと呼ばれる。

 ISO/IEC 10646は、JISではJIS X0221として制定され、国際符号化文字集合(UCS)と呼ばれる。

 Unicodeには100万文字以上のコード・ポイントが用意されており、各国の文字や記号だけではなく、歴史的な古代文字や絵文字なども加えて、現在は約14万文字が割り当てられている(*1)。

*1 Unicode 13.0 Character Code Charts    http://www.unicode.org/charts/

 

 Unicodeの最初の128のコード・ポイント(U+00 から U+7E)は、ASCIIと同じ文字コードが割り当てられている。

 Unicodeは、各文字とそのコード・ポイントを定めた符号化文字集合である。このコード・ポイントを、コンピュータで扱うバイト・コードに変換する文字符号化方式が、UTF(Unicode Transformation Format、あるいはUCS Transformation Format)である。

 Unicodeコード・ポイントから UTF のバイト・コードへ変換することを、エンコードと呼ぶ。UTFには、UTF-8、UTF-16、UTF-32のエンコード方式が存在する。

 

UTF-8

 UTF-8は8ビット・コードを基本としており、各文字は1から4バイトでエンコードされる。Unicodeコード・ポイントの最初の128文字は、1バイト・コードでエンコードされ、ASCIIと同じコード・ポイントとなる。

 たとえば、文字列「ABC」は、UTF-8ではx‘414243’となり、ASCIIと同じコードで扱われる。ASCIIとの互換性があることから、ネットワークにUnicodeデータであることを知らせなくても、ネットワーク上に8 ビット・データを流せる。

 UNIX プラットフォームでは UTF-8 を使用してUni
codeを保管している場合が多く、ほとんどの新しいインターネット標準にデフォルトのエンコード方式として使用されている。

 英数字を主に扱う場合はASCIIと同じ1バイトであるが、日本語を扱う場合には3バイトが必要になる。

 

UTF-16

 UTF-16は16ビット・コードを基本としており、各文字は2バイト単位でエンコードされる。Unicodeコード・ポイントの最初の128文字も、2バイト・コードでエンコードされる。

 もともとのUnicodeであるUCS-2では、基本多言語面(BMP)と呼ばれる6万5535文字までしか扱えないため、UCS-2を拡張する形で定められたのがUTF-16である。

 BMP以外の文字は、サロゲート・ペアと呼ばれる仕組みを用いて示す。通常使用する文字はBMPに含まれているので、サロゲート・ペアを用いるのは稀である。

 

UTF-32

 UTF-32は32ビット・コードを基本としており、各文字は4バイトでエンコードされる。UTF-32は、UCS-4と同じである。すべての文字で常に4バイトを使用するため、多くのストレージが必要となる。そのため、あまり使用されていない。図表3に、UTFエンコードの例を示す。

 

 

バイト・オーダー

 UTF-16やUTF-32は、1文字のコードを複数バイトで示している。このようなマルチ・バイトのデータでは、バイト配列の順序を定めておく必要がある。この規則をバイト・オーダーと呼び、ビッグ・エンディアンとリトル・エンディアンの2つがある(図表4)。

 

 

ビッグ・エンディアン

 ビッグ・エンディアンは、最上位のバイトから並べるバイト・オーダーである。たとえば、ひらがなの「あ」のコード・ポイントU+3204は、UTF-16のビッグ・エンディアンでは30 42、UTF-32では 00 00 30 42の順になる。

リトル・エンディアン

 リトル・エンディアンは、最下位のバイトから並べるバイト・オーダーである。たとえば、ひらがなの「あ」のコード・ポイントU+3204は、UTF-16のリトル・エンディアンでは 42 30 、UTF-32では 42 30 00 00の順になる。

 エンディアンが関係するのはマルチ・バイトのバイト順であり、1バイト内のビットの順番は常に 7 6 5 4 3 2 1 0 である。

 

短期連載
第1回 文字コードについて ~その歴史と役割
第2回 IBM iの日本語環境 ~EBCDIC編
第3回 IBM iの日本語環境 ~Unicode編

 


著者
三神 雅弘氏

日本アイ・ビー・エム株式会社
システム事業本部 サーバー・システム事業部
コグニティブ・システムズ事業統括
シニアITスペシャリスト

1989年、日本IBM入社。AS/ 400のテクニカル・サポートを担当。日本IBM システムズ・エンジニアリングへの出向を経て、2004年よりテックライン、2016年よりビジネス・パートナー向けテクニカル・サポート、2018年よりIBM iブランド業務を兼任している。

 

[i Magazine 2020 Autumn(2020年10月)掲載]

More Posts