文字コード特集

本ページは、過去に取り上げた文字コード関連の記事をまとめたものです。
内容は当時のものですので、ご注意下さい。

[98/04/10]

文字コードのこと

本ページでは、HFS+の問題に関連して、Shift-JISとかUnicode等の文字コードの話がよく出ていたのですが、文字コードについての説明は行っていませんでした。

質問が多く来るようだったら説明しようと考えていたのですが、以前にも書きましたしたように反響も少なかったので（笑）、そのままになっていました。

今回、WAOさんが記事にされていましたので、その補足というか、要は「人の褌で相撲を取る」ですけど、少し説明しておきたいと思います。WAOさんの「Mac日記の日々」と合わせてご覧ください（他力本願モード）

なお、分かりやすくするために、説明を簡略化しているため厳密には正しくない部分も出てくるかと思いますが、予めご了承下さい。誤解を招くような表現がありましたらご指摘下さい。

全角／半角文字という表現は、等幅フォントの表示の場合であり、プロポーショナルフォントの場合は文字ごとに幅が異なるので正しい表現とは言えませんが、他に適当な用語もないのでとりあえずこのように表現します。

16進数の表記は、値の前に「0x」を付けて、「0x00」のように表記します。
(これはC言語系の表記です。)

では、とりあえず始めましょう。

「文字コード」って？

文字や記号をコンピュータで扱うため、それぞれの文字や記号に割り当てた符号のことを「文字コード」と呼びます。

この割り当て方の違いによって、「ASCIIコード」とか「JISコード」等の種類があります。

コンピュータは、ビットのon/offしか理解できません。onを1、offを0で表すと、例えばASCIIコードで「A」には「0100 0001」という値が割り当てられています。

これを2進表記といいますが、長くて分かりにくいため、通常は4ビットごとに0～Fの文字で表した16進表記がよく使用されます。

つまり、2進表記と16進表記は表現方法が異なるだけで、内容は同じものです。

表． 8ビットの値の2進表記と16進表記の比較

2進表記	16進表記
0000 0000	0x00
0000 0001	0x01
0000 0010	0x02
：	：
0000 1110	0x0E
0000 1111	0x0F

前述の「A」は16進表記では「0x41」となります。

ASCIIコード

その名（American Standard Code for Information Interchange）が示すように、元々米国の標準コードです。ISO（国際標準化機構）により標準化され、JIS（日本工業規格）の1バイトコード（JIS X 0201）も、このASCIIコードをベースとしているため、英数字のコードについてはASCII/JIS間で互換性があります。

本来のASCIIコードでは、1バイト（8ビット）のうち、最上位の1ビットは使用されておらず、7ビット（0x00～0x7F）、128文字が割り当てられています。

このうち、0x00～0x1Fと0x7Fが制御文字、0x20が空白、0x21～0x7Eが普通の文字や記号です。制御文字というのは、例えばMacの改行コード（CR）は0x0Dです。
1バイトコードの問題

前述のように、ASCIIコードでは7ビット、128文字しか使用できません。米国（英語）では英大文字、英小文字、数字、記号を合わせてもなんとか足りていたのですが、他の言語ではもっと多くの文字を使用したい場合があります。

そこで、ASCIIコードで使用されていない0x80～0xFFの範囲に独自の文字を入れることが考えられました。

日本では、0xA1～0xDFにカタカナ（いわゆる半角カタカナ）を入れました。

また、ヨーロッパではアクセント記号やウムラウト記号付きの文字をこの範囲に入れました。HFS+関連で出てきた「アクセント記号付きのE」は0x83に割り当てられていました。

さらに、PCメーカーによっては独自に拡張を行ったものも出てきたため、割り当てられた値が重なってしまい、機種や環境によっては文字化けが起きるという問題が発生することになってしまいました。

同じMacでも、英字の「TM」マークと同じ値（0xAA）が日本語では「ェ」に割り当てられているため、文字化けすることは皆さんもご存知でしょう。

以上、1バイトコードについて、簡単に説明を行いました。要望があるか気が向いたら2バイトコードについても説明を行いたいと思います。

ご意見やご質問、誤りの指摘などありましたらこちらまでお願いします。
（全体的に反響少ないので．．．）

[98/04/13]

文字コードのこと（ＪＩＳ漢字コード編）

2バイトコードについても簡単に説明しておくことにします。

あらかじめお断りしておきますが、文字コードについてすべてを説明することはとてもできませんので、ここではHFS+関連の問題を理解するための補足程度にとどめます。文字コードについてさらに詳しく知りたいという方は、WAOさんが紹介しているサイトやJIS規格書などをご参照下さい（手抜きですみません）。

なお、前回と同様に説明の簡略化のため、厳密には正しくない表現が一部ありますが、ご了承ください。明らかな誤りがありましたらご指摘ください。
1. JIS漢字コード
  
  まずはJIS漢字コードについて説明します。
  （JIS漢字コードは、通常Macintoshでは使用されません）
  
  前回お話ししましたように、1バイトでは128個（7ビット）または256個（8ビット）の文字しか表現することができません。
  
  これでは漢字のような膨大な数の文字を表現することはできません。
  
  そこで、2バイトを使用して文字を割り当てたものが漢字コードです。なお、全角文字の英字や数字は、もちろん「漢字」ではありませんが、一般に「漢字」と総称されています。
  
  2バイト＝ 16ビットですが、ASCIIコードと同様に各バイトの最上位ビットは使用されません。また、ASCIIの制御文字（0x00～0x1F、0x7F）や空白（0x20）と重なる値も使われませんので、漢字として割り当てることができる文字は第1バイト、第2バイトともに0x21～0x7Eです。
2. エスケープシーケンス
  
  このように、2バイトで漢字を表すことにしたわけですが、漢字として割り当てられた値とASCIIコードの値が重なっています。
  
  たとえば「漢」はJISコードで「0x3441」ですが、これはASCIIコードの「4A」と同じ値なので、そのままではどちらか区別がつきません。
  
  そこで、コードの切り替えに「エスケープシーケンス」というものを使用します。
  
  「エスケープシーケンス」とは、「ここから先の文字は漢字（ASCII）ですよ」ということを示すものです。
  
  漢字の開始には「ESC $ B」（0x1B2442）が、ASCIIの開始には「ESC ( J」（0x1B284A）が使用されます。
  
  たとえば「ab漢cd」という文字列をJISコードで表すと「0x61 62 1B2442 3441 1B284A 63 64」となります。
  
  先頭から順に見ていきますと、「a」（0x61）、「b」（0x62）ときて、漢字開始のエスケープシーケンス（0x1B2442）があるので、次の「0x3441」は「漢」と判断されます。次にASCII開始のエスケープシーケンス（0x1B284A）があるので、その先はまたASCIIコードと見なされて「c」（0x63）、「d」（0x64）となります。
  
  通常、エスケープシーケンス自体は画面や印刷に表示されることはありません。
3. JIS漢字コードの問題
  
  このように、エスケープシーケンスを用いて、2バイトの漢字と1バイトの英字（ASCIIコード）が共存できるようになったわけですが、このエスケープシーケンスというのがプログラマにとっては厄介な代物です（笑）。
  
  前述のように、エスケープシーケンス自体は画面には表示されませんので、画面上の文字数と内部的なバイト数が異なります。さらに画面上は同じ文字数であっても内部的なバイト数が異なることがあります。
  
  たとえば「abcd漢字」という文字列は、画面では1バイト文字が4個、2バイト文字が2個ですが、「d」と「漢」の間に漢字開始のエスケープシーケンス（3バイト）が入るので、内部的なバイト数は 1×4＋2×2＋3＝11 バイトになります。
  
  ところが「ab漢字cd」では、画面上は同じく1バイト文字が4個、2バイト文字が2個ですが、「b」と「漢」の間に漢字開始の、「字」と「c」の間にASCII開始のエスケープシーケンス（3バイト）がそれぞれ入るため、内部的なバイト数は14バイトになります。
  
  私は現在はWindowsのプログラマ（爆）ですが、以前はメインフレームのプログラマでした（メインフレームというのは、銀行や証券会社にあるような大型のコンピュータのことです）。
  
  メインフレームでは、メーカー独自のコードを採用していましたが、これもJISコードのエスケープシーケンスと同様に、特殊な文字列（2バイト）を使用して1バイトの英字と2バイトの漢字を切り替えていました。
  
  私はたまたま文字列操作関係の部分を担当していたことがありますが、文字コードやコード切り替えにはかなり悩まされました（笑）。
次回、Shift-JIS編に続く（かもしれない）。

[98/04/17]

文字コードのこと（Shift-JIS編）

前振りが長くてすみませんでした。ようやく本題のShift-JISコードです。

Shift-JISコード

前回お話したJIS漢字コードは、エスケープシーケンスがあるため、文字列の見た目の長さと実際の長さが異なり、コンピュータの内部コードとしては非常に扱いにくいものです。

そこで、エスケープシーケンスを使用せずに漢字を利用しようと考えられたのがShift-JISコードです。

マイクロソフト社が中心となって開発されたため、MS漢字コードと呼ばれることもあります。

MacintoshやWindowsで採用されている文字コードでもあります。

Shift-JISコード詳細

Shift-JISコードもJIS漢字コードと同様に2バイトで漢字1文字を表しますが、その第1バイトの範囲は0x81～0x9Fおよび0xE0～0xFCとなっています。

これは、ASCIIの制御文字（0x00～0x1F、0x7F）、空白（0x20）、英数字（0x21～0x7E）および半角カタカナ（0xA1～0xDF）を避けて配置されています。

つまり、JISのコード表上の漢字を、ASCII文字や半角カタカナ等と重ならない位置へずらして（シフトさせて）配置したことから「Shift-JIS」と呼ばれています。

ASCIIコードでは、1バイト（8ビット）のうち、最上位の1ビットは使用されず、7ビット（0x00～0x7F）のみ使用されています。

このため、あるバイトの最上位ビットがOFFであればASCII（英数字）、ONであれば、漢字（の第1バイト）又は半角カタカナ、と区別することができるので、エスケープシーケンスを使用しなくても漢字と英数字の混在が可能となったのです。

Shift-JISコードの問題

まず、インターネットのニュースやメールの世界では、現在でも7ビットのコードしか通らない場合があり、Shift-JISコードを使用すると文字化けしてしまうことがあります。これは最上位の1ビットが落ちてしまうためです（同じ理由で8ビットの半角カタカナも文字化けします）。

また、漢字1文字を構成する2バイトのうち、前述のように第1バイトはASCIIコードと重ならない位置に配置されていますが、第2バイトの範囲は0x40～0x7E、0x80～0xFCであり、一部がASCIIコードと重なります。

以前、本ページでHFSボリュームでは「色」と「診」という名前のファイルを同一階層に作成することができないということをお伝えしました（2月18日の記事）。

「色」はShift-JISコードで0x9046、「診」は0x9066ですが、0x46がASCIIコードの英大文字の「F」、0x66が英小文字の「f」と重なっています。

Macのファイルシステムは、漢字であっても1バイトごとに処理を行っているので、「色」（0x9046）と「診」（0x9066）を比較すると、最初の1バイトは共に「0x90」で同じ値、2バイト目は「0x46」と「0x66」でF/fの大文字／小文字の違いしかないと判断します。

Macのファイルシステムはファイル名の英大文字／英小文字を同一と見なすため、「色」と「診」を同一のファイル名と判断してしまうのです。

また、本来のASCIIコードは7ビットしか使用していないのですが、ASCIIコードの説明（4月10日の記事）で書きましたように、米国以外の地域やメーカーは、この部分に独自の文字を割り当てました。

日本でも半角カタカナをこの部分に入れたのですが、Shift-JISコードの第1バイトは半角カタカナに割り当てられた値を避けて配置されているので、これは特に問題ありません。

しかし、ヨーロッパで割り当てられたアクセント記号やウムラウト記号付き文字のコードがShift-JISコードの第1バイトと重なる場合があります。

このため、たとえばヨーロッパのWebページを見たとき、漢字に文字化けしてしまう等の問題が発生することになってしまいました。

次回、Unicode編に続く（多分）。

[98/04/18]

最上位ビットとは

昨日の記事で「最上位ビット」という言葉を使用したところ、早速WAOさんからツッコミが入ってしまいました。

プログラマを10年もやっていると、専門用語等を無意識のうちに使ってしまうことがあるのですが、よく考えると（考えなくても）一般の方は何が「上」かなんて分かりませんよね、すみません。

他にも何か分からないことがありましたら、遠慮なくツッコミを入れてくださいね＞ ALL。

さて、最上位ビットですが、文字コードがビットのON/OFFの並びであることは既にご理解頂いていることと思います。

この並んだビットを左から順にビット0、ビット1．．．と呼びます。

余計なことを書くとかえって混乱されるかもしれませんが、「2のn乗（2ⁿ）ビット　」という呼び方をする場合は、右から順に0～nとなります。

ASCIIコードの「A」をビットのON（1）とOFF（0）の2進表記で表すと、次のようになります。

ビット0

ビット1

ビット2

ビット3

ビット4

ビット5

ビット6

ビット7

2⁷ビット

2⁶ビット

2⁴ビット

2³ビット　

2²ビット

2¹ビット　

2⁰ビット　

ここで、左の方が「上」だと考えてください。つまり「最上位ビット」とは一番左側のビット（「ビット0」又は「2⁷ビット」）のことです。

1バイト（8ビット）の場合、最上位ビットがOFFというのは「0*** ****」、ONは「1*** ****」という値です（「*」は0でも1でも良いと考えてください）。

また、2進表記が長くて分かりにくいため、通常は16進表記が使用されることは4月10日の記事でお話ししましたが、これを16進表記で表すと、最上位ビットがOFFというのは「0x0*～0x7*」、ONは「0x8*～0xF*」となります（「*」は0～Fのどれでも良いです）。

ASCIIコード（0x00～0x7F）では最上位ビットがOFF、Shift-JISコードの第1バイト（0x81～0x9F，0xE0～0xFC）および半角カタカナ（0xA1～0xDF）では最上位ビットがONであることがご理解頂けましたでしょうか？

なお、「ビットn」という呼び方では、2の重みに対応した名称（1バイトの最上位ビットだとビット7）を使用する場合もあります。

[98/04/24]

文字コードのこと（Unicode編）

さて、問題（？）のUnicodeです（笑）。例によって説明の簡略化のため、厳密には正しくない表現があると思いますが、ご容赦ください。誤りなどお気付きのことがありましたらご指摘下さい。
1. Unicode
  
  JIS漢字コードやShift-JIS、説明は省略しましたがUnix系で使用されるEUCコード等を使用することで、コンピュータで漢字が扱えるようになりました。
  
  しかし、これらのコードはもともと1バイトで英数字を表すASCIIコードをベースに2バイト（以上）に拡張したものであるため、プログラムでは扱いにくい部分もありました。
  
  また、日本と同様に、漢字やハングル等の1バイトで表現できない数多くの文字を使用している中国、台湾、韓国等でも、それぞれ独自のコードを規格化しているため、世界的にも文字コードの混乱が問題となってきました。
  
  そこで、最初から漢字等の複数バイトで表現される文字のことも考慮し、世界中の（主な）文字を一つの文字セットで表現することを目的として、Apple、Microsoft、IBM等の企業が提唱した文字コードがUnicodeです。
2. Unicodeの利点
  
  Unicodeでは、いわゆる半角文字も全角文字も全て2バイトで表現します。このため内部的な文字列の長さは常に「文字数 × 2バイト」になるので、プログラムでの扱いが楽になると言われています。
  
  また、漢字や英数字といった区別なく、全ての文字を同じように扱うことができるので、例えばBeOSやRhapsody (DR1)のようなUnicodeを内部コードとして採用しているシステムでは、英語版システムでもフォントや日本語入力プログラムを追加するだけで、日本語が利用できます。
3. Unicodeの問題
  
  上記のような利点もあるUnicodeですが、多くの問題点も抱えています。
  
  よく言われているのが「漢字統合」の問題です。前述のように日本だけでなく中国や台湾、韓国でもそれぞれ独自の漢字コードを使用していたのですが、これらの漢字全てを収録しようとすると、2バイトでは足らなくなってしまいます。
  
  そこで、Unicodeでは、日本、中国、台湾、韓国で使用されている漢字のうち、形の似た字は同じ漢字として扱う（同じコード値を割り当てる）ことにしたのですが、これが漢字圏の国からは反発を受けることになってしまいました。
  
  また、Unicodeには既存のASCIIコードとの互換性がほとんど無いという問題もあります。
  
  このためUnicodeを採用したシステムでは、従来のプログラムを大幅に修正しなければならないことがあります。
  
  全てのプログラムを修正するわけにもいきませんので、HFS+で部分的にUnicodeを採用したMac OSでは、システム側でUnicodeとShift-JISのコード変換を行っており、プログラム側では特にUnicodeと意識する必要はありません。
  
  しかし、既にご報告しているように、このコード変換により様々な問題が発生することとなってしまいました。
4. UTF-8のこと
  
  少し本題から外れますが、UTF-8についても説明しておきます。
  
  前述のようにBeOSでは、システムの内部コードにUnicodeを採用しているのですが、表示等にはUTF-8というコードが使用されています。
  
  これはUnicodeの文字を、ある規則で1バイト～6バイトの文字へ変換したものです。
  
  せっかくUnicodeで全ての文字を同じ長さ（2バイト）にしたのに、なぜこのようなことをするのかと疑問に思われるかもしれませんね。
  
  実はUnicodeの先頭の128文字（0x0000 ～ 0x007F）は、ASCIIコード（0x00 ～ 0x7F）と順序が同じです。
  
  そこで、UTF-8ではこの部分を従来のASCIIコードと同じ1バイトの値に変換し、それ以外の文字（漢字等）の部分を2バイト以上の値に変換しています。
  
  前述しましたように、Unicodeは従来のASCIIコードとの互換性が無いのですが、UTF-8を採用することで、少なくとも英数字に関してはASCIIコードと互換性を持たせることができ、（ASCIIコードを前提とした）既存のプログラムをほぼそのまま利用することができるのです。
以上、1バイトコード／2バイトコード／Unicodeと、文字コードについて簡単に説明を行いましたが、それぞれのコードについて大体のところはご理解いただけましたでしょうか？

疑問点やご意見などありましたらお聞かせ下さい。

←TOPページに戻る

「Macintoshは米国アップルコンピュータ社の商標です」
「その他、記載の商品名などは、一般に各社の登録商標または商標です」