小形克宏の「文字の海、ビットの舟」 ――文字コードが私たちに問いかけるもの　　 第1部　2000JISがやってきた 第2回　2000JISの原案はなぜ修整されたか？

Illustation:青木光恵

●単一の規格としては実装されない2000JIS

　4年の歳月をかけて開発されてきた、拡張された新JIS文字コード、JIS X 0213:2000[*1]（以下2000JISと略）が、今年1月20日に制定された。しかし、残念なことに、これをすぐに一般ユーザーが使えるという状況ではなさそうだ。主要なパソコン用OSメーカーに対応状況を聞いてみると、以下のような答えが返ってきた。

◎マイクロソフトのコメント

「マイクロソフトの製品、とくにシステム製品の主要なコンポーネントは、すでにUnicodeベースです。Unicode化がさらに進むということがあっても、これが昔にもどるということはありません。ですので正確に符号化方法の部分に関していうと、2000JISに対応するということは基本的にありません。ただ、2000JISの文字集合は、OS側で標準的に提供すべき必須レパートリー（収録文字）であると弊社は認識しております。ではどうするのかというと、弊社は2000JISのレパートリーを、将来アップデートされたバージョンのUnicodeで対応する、ということになります。ただしまだ提案中の文字もありますので、いつ頃対応できるのか、今の段階ではお答えできません。ISO/IEC 10646のスケジュールからすると、2001年というのがひとつの目標になっています[*2]。ですからそれ以降、弊社でいえばNTベースのOSで実装すると、いうことになるでしょう。つまりWindows2000の後継にあたりますね」

（ビジネス＆エンタープライズ開発統括部　グループマネジャー　増井伸昭）

◎アップルコンピュータのコメント

「JIS X 0213のキャラクターセット（文字集合）に関しては、弊社としても非常に高く評価していると同時に、策定に関わった方々のご労苦を考えると大変頭の下がる思いです。エンコーディング・スキーム（符号化方法）に関しては、ご存知の通り弊社はUnicodeを推進している企業の一社ですので、この価値あるキャラクターセットをUnicodeの枠組みの中でサポートしていきたいと考えています」

（マーケティング本部プロダクトマーケティング課長　MacOSプロダクトマネージャー　櫻場浩）

　コメント中に難しい用語があるが、おいおい説明するのでまずは気にせず読み進んでもらいたい。

　これらのコメントから判明するのは、つまり“現在主流をしめるOSであるWindowsもMacOSも、規格単体として2000JISを実装しない”という事実だ。そして、Unicodeのなかに2000JISの文字が収録された時点で、そのバージョンのUnicodeに対応するという形で、結果的に2000JISを使用可能にする。これは他にUnicodeを内部コード（OS内部のデータ処理に使う文字コード）として採用しているLinuxもBeOSも、そしてUnicodeをデフォルトの文字コードとして指定しているXMLやJAVAも同様と思われる。

　さて、ではこのUnicodeとはなんだろうか。

　uniとは“統一された”という意味を持つ。codeは文字コード、つまりUnicodeとは“統一された文字コード”ということになる。実は文字化けに悩んでいるのは日本語だけではない。アメリカで使われる英語（イギリス英語の文字コードとは別）を例外として、ほぼすべての言語をコンピューターで使う人々は、ことあるごとに文字化けに悩み、苦しんでいる[*3]。これがアメリカ英語をのぞく、世界のコンピューター環境の現状だ。なぜ文字化けはおこるのか。違う文字コードとのあいだで変換に失敗するからだ。

[*3]……アメリカ英語の文字コード、US-ASCII=ISO/IEC 646は、ほとんどの7、8ビット系の符号化方法で、ほぼそのままのコード位置で含まれており、よってアメリカ英語は文字化けの心配から一番遠い言語である。もちろん、アメリカ英語の環境であっても、いったん他の文字コードを表示させようとすれば化ける可能性はある。しかし、アメリカ英語じたいはたいていの環境において化けない。そういうことである。うらやましい。ところで素朴な疑問なのだが、アメリカ英語が母語である人々にとって、我々がもつような文字化けの悩みというのは、本質的に理解が可能なんだろうか？

　

●世界中の文字を収録しようとするUnicodeとは？

　このような状況、つまり文字コードを多言語に対応させる技術的な方法はふたつある。ひとつは複数の文字コードを切り替えて使う方法、もうひとつが複数のスクリプト[補注1]を単一の文字コードの中に入れてしまう方法だ。Unicodeは後者の手法であり、より徹底して、複数のスクリプトというより世界中のスクリプトを収容する文字コードをつくり[訂正3-1]、これを世界共通の文字コードとして使って、違う文字コードとのあいだの変換で生じていた文字化けを原理的に存在しなくさせる――という、ユーザーにとっては夢のような世界の実現を目指したプロジェクトなのだ。[訂正2]

[*補注1]…… スクリプト（用字）とは、JIS X 0221:1995規格票の『4.1定義』によれば「一つ以上の言語の表記の方法で、使用する図形文字の集合」となる。図形文字とは制御文字以外の目で読める文字だから、つまりある言語の書き言葉のことなのかと思われるかもしれないが、これが間違い。たとえば英語、ドイツ語、フランス語など、ヨーロッパやアメリカ英語のアルファベット（ラテン文字という）をつかう言語は、すべて“ラテン・スクリプト”に属する。これらは表記する文字の集合が共通のラテン文字をつかうからだ。もちろん各言語でちがった発音区別符号（ダイヤクリティカル・マーク）をつかうが、基本になる文字は同じだ。 　反対に日本語では漢字、ひらがな、カタカナ、ローマ字という4つの異なるスクリプトをつかって表記する。そして、日本、中国、韓国などで使われる漢字は共通のスクリプトだ。 　つまり、言語とスクリプトは違う概念に属する。“言語”は話し言葉を中心にしたひとつの体系、まとまりだ。しかし“スクリプト”は記述する文字だけに注目した体系だ。ひとつの言語が複数のスクリプトをもつ場合もあるし、多数の言語がひとつのスクリプトを共有する場合もある（こちらの方が多い）。 　そして多くの場合、文字コードはある言語の書き言葉に符号位置を与えるのではなく、スクリプトに符号位置を与えていることにも注意したい。たとえばJIS X 0208では、“A”に３つもの区点位置を与えているが、これはそれぞれラテン、キリル、ギリシャの各スクリプトのものだ。広義のUnicodeも同じ考え方により世界中の文字、というよりスクリプトを収録しようとしている。 　言語とスクリプトの混用はとても重大なボタンのかけ間違いにつながるので注意。とくに広義のUnicodeを考える場合、この使い分けは前提になる。実際スクリプトという概念がなければ、Unicodeの文字集合は途方もなく膨れ上がるだろう。この原稿の初出時は“スクリプト”の部分をそのまま“言語”と書いていたが、これじたいが典型的かつ初歩的な間違いであった。(2000.2.14)

　

　Unicodeを策定しているのは『Unicodeコンソーシアム』というアメリカのコンピューター企業を中心にした団体だ。Microsoft、Apple Computer、Sun Microsystems、Hewlett-Packard、IBM、Compaq、Oracle、Xerox等々、そうそうたるメンバーが名を連ねている。日本からはジャストシステムがフル会員として参加している( http://www.unicode.org/unicode/consortium/memblogo.html)。

　先にUnicodeを“ユーザーにとっては夢のような”という書き方をしたが、Unicodeコンソーシアムの会員企業の側にたって見れば、世界中に自社製品を売りたいメーカーにとって、Unicodeでプログラムを書くということは、ローカライズ作業のためにその国で使われる言語にあわせて始めから書き直さないですむ、つまりよけいなコストをかけずにビジネスが展開できることを意味する。きびしい競争でライバルとしのぎを削る巨大コンピューター・メーカーにとって、Unicodeは最小限度のコストで世界を相手にビジネスを展開するための、いくつもある必須の技術の中のひとつという側面をもつのだ[*4]。

　

　ところで、このUnicodeは、ある意味でUnicodeコンソーシアムだけで開発しているのではない。『ISO/IEC 10646』（別名“UCS”――Universal Multiple-Octet Coded Character Set）という国際規格があり、この内容は実質的にUnicodeと一緒なのだ。これを策定しているのはISO/IEC JTC 1/SC2というセクションだ[*5]。そして、その委員長は、なんと2000JISの原案を作成したJCS委員会の委員長、芝野耕司その人。

　このUnicodeとISO/IEC 10646の関係は、私企業の連合体であるUnicodeコンソーシアムと、国際的な公的標準化機構であるISO/IEC JTC 1/SC2が、まるで自転車の前輪と後輪のように連携をとりながら開発していると考えておけば間違いはない。実際の話、これらの団体のメンバーは、重複する人間も多く、関係も錯綜している。ふたつの団体がゴッチャになっているこの状態は、とりもなおさず“世界中の言語を収録する単一の文字コードを作る”という計画の途方もなさを象徴しているのかもしれない。つまり、これはとてもひとつの標準化団体では手に負えない大事業なのだ[*6]。

[*5]…… これは、左から右に行くに従って組織が細分化されていくことをしめし、ISO（国際標準化機構）とIEC（国際電気標準会議）によるJoint Tchnical Committee-1（第1合同委員会）傘下のSub Committee-2（第2専門委員会）ということになる。ちなみに電気通信分野ではISOとIECは合同で標準化作業をしており、JTC 1の“合同”（Joint）とは、このことを指す。また、Sub Committeeは全部で18あり、SC2は文字コードのための委員会。SC2の下にはWG2とWG3のふたつの作業部会があり、それぞれWG2はマルチ・オクテッド（一般にいわれる16ビット以上）、つまりISO/IEC 10646を担当し、WG3は7、8ビット系の文字コードを担当する。この～ビットというのは、文字集合を入れる容器の大きさをさす。詳細は文末の専門書を参照。 [*6]…… 他にも両者が連携する歴史的な経緯があるだが、ここでは省略して話をすすめる。また、UnicodeとISO/IEC 10646の細かな違いについても、同じく省略する。これらは専門書を参照してほしい。

　

　ただし実質的に同じだからといって見逃してはいけないポイントがふたつほどある。まず、両者が連携をとっているといっても、それぞれの開発ロードマップ、つまり改訂のスケジュールは別であり、一方が他方の改訂を反映するとしても、数カ月から数年のタイムラグが生じるということだ。

　それからもうひとつ、実際に製品に実装されるのはISO/IEC 10646ではなく、多くはUnicodeであるということだ。Unicodeコンソーシアムの会員企業ならば、自社製品にUnicodeを実装するのは当然だ。そして会員企業のメンツをみれば、そこから生み出される製品の幅の広さと影響力の強さが容易に推測できるだろう。

　このふたつのポイントは、2000JISとUnicode（ISO/IEC 10646）の関連で大きな問題をもつことになる。

　

●公的標準とデファクト標準――ふたつの標準化のあり方

　ここで話は日本に戻る。前回の原稿冒頭で触れたが、2000JISは原案通りに最終審議を通過せず、というより審議が難航した末に、いくつかの修整が加えられて成立した。これはなにを意味するのだろうか？

　それを説明する前に、まずJISとは何か、どのように制定されるかを、今回の2000JISにそって整理してみよう。

JISはJapan Industrial Standardの略称で、正式には日本工業規格という[訂正1]。工業標準化法に基づいて制定される“国内標準”（本稿ではNational Standardの訳として一般的な“国家規格”ではなくこの言葉をつかう。理由は後述）だ。JISの制定や改正は通産省の工業技術院に設置されるる日本工業標準調査会（JISC）[訂正4]という半官半民の団体がつかさどっている。

　誤解されることが多いが、JIS規格は法律と違い、従わなければ罰せられるようなものではない。JIS規格を国による“規制”と混同すると、すべての理解が間違ってしまうことになるので注意したい。実はJIS文字コードをめぐる議論にも、ここの部分の誤解・混乱が少なからずあるように思える。

　標準には公的標準とデファクト標準のふたつがある。ISOやJISCなどの公的な標準化機関による審議をへて決まる公的標準とちがい、デファクト標準は、例えばWindowsという、いちメーカーが開発したOSがパソコン市場で独占的な地位を占めているように、標準をめぐる競争が市場でおこなわれ、その結果標準が事実上（デファクト）きまるものだ（表1参照）。

◆表1　公的標準とデファクト標準の比較

( http://www.miti.go.jp/press-j/science/x71110a1.html より引用)　

　このふたつはどちらが正しいとか偉いとかではなく相互補完的なものと考えたい。制定の過程がオープンで仕様が明確な一方で、策定のスピードが遅く、どうしても普及まで時間がかかってしまう公的標準に対し、その欠点を補うことがデファクト標準には可能だからだ。例えば本来Sun Microsystemsによるデファクト標準であったJAVAも、じょじょに公的標準へ移行される流れにある。

　ただし、このふたつを比べれば、やはりオープンでユーザーが監視できる公的標準が優位を占める方が幸せな社会だといえよう。制定過程が公開される国内標準は、私企業による独占であるデファクト標準と違い、本来的にはユーザー自身の関与が可能だからだ。もちろんJIS規格も同じ。だから「お上が決めたものだから悪い」とでも言うような、まるで床屋政談のような論調でJIS文字コードを論じるのはおかしい。国内標準への安易な一方的批判は、即自分の元に返ってくると覚悟した方がいい。

　実際、2000JISも公開レビューとして原案をウェブ上で公開し、広く一般に意見と情報の提供を募り、それに答えるかたちで、さまざまな団体、個人が貴重な情報を無償で提供してつくられた。2000JISは、これら多くの人々の好意と努力の結晶であることを、我々は肝に銘ずる必要がある。

　その意味で、一般的にJISを説明するときに使われる“国家標準”“国家規格”という言葉も、本当は諸外国の標準化の実態を考えると変な言葉ではある。なぜならば、嫌な言い方ではあるけども、欧米では日本のように政府機関に標準化の事務局がおかれるということはない。国によって差はあるが、政府から多少の資金援助はうけるものの、主体となって動いているのは規格によって利益をうける企業、それに学会などであり、これらが人と資金を出し合って組織をつくり、出身母体から派遣されたボランティア・メンバー（つまり無報酬）によって策定、運営されているという実態がある。日本のように官庁に標準化事務局がおかれ、主体的にJISに関わっていくというあり方は、そろろ再考すべき段階にきているのではないか。

　だから、その意味で "National Standard" は、国家のご威光を感じさせる“国家標準”という訳語ではなく、単に“国内標準”と呼ばれるべきではないのか。そのような意味をこめて、本稿ではこの言葉を使うことにした。

●2000JISが最終審議で紛糾した理由とは？

　さて、また脇道にそれてしまった。先を急ごう。

　JIS化の必要ありと認めたものについて、JISCは民間の団体に原案作成を依頼する。2000JISは日本規格化協会傘下の符号化文字集合調査研究委員会（JCS委員会）が原案の作成にあたった。こうした委員会は委員長以下、実費程度しか支給されないボランティアで構成される。つまり、委員たちは原案作成をビジネスとしてやっているわけではない。集まる人間は学者やメーカーから派遣される専門知識をもった人間が多い。

　JCS委員会は今までいくつか文字コードの原案作成をしてきた委員会だ。たとえば97JIS（JIS X 0208:1997）の改正はこの委員会の仕事だ。今回の2000JIS原案のため、下に専門の作業部会（ワークグループ）をつくり、ここで開発作業をおこなった。これがJCS委員会ワークグループ2（以下JCS/WG2）だ。 http://jcs.aa.tufs.ac.jp/jcs-memb.htm にある名簿をみると37人が名を連ねている。JCS/WG2と親委員会であるJCS委員会のメンバーは委員長をはじめ一部だぶってはいるが、基本的には別だ。つまり2000JIS原案作成という高度な専門知識が必要とされるプロジェクトのために集められた専門家集団がJCS/WG2で、そのチェック役が親委員会というわけだ。今回JCS/WG2メンバーには委員とは別にオブザーバという名目の人々が9名いるが、これは出席すると数千円の日当、遠隔地の場合は交通費がでる委員に対して、まったく報酬を支給されない、完全に無給のスタッフだ。ただしオブザーバーの権限は委員と変わらない。また、有力なJIS文字コードユーザーでありながら、従来原案作成にはあまり関わらなかった出版業界出身のメンバーが、今回は5人参加しているのもJCS/WG2の大きな特徴だろう。

　作成された原案は、JISCに提出され、それぞれの部門ごとに分かれた部会で最終審議にまわされる。2000JISを所轄するのは情報部会という部会だ。ここのメンバーは日本電気、日本アイ・ビー・エム（以下日本IBM）、日立製作所、富士通など、日本を代表する情報機器メーカーの社長や専務などトップクラスがメンバーになっている。ここで検討ののちに評決がとられ、通過したものが主務大臣、2000JISの場合は通産大臣の名前で制定され、官報などで告知される。

　では、2000JISはどのようにして修正されたか。

　もともと審議にはいる前から、情報部会の委員の間では、2000JISの原案について難色をしめす空気が強かったと言われる。その反対理由については後述するが、9月27日の時点でただちに評決をとると否決のおそれが強かったため、極力2000JISをぶじに規格成立させたい工業技術院は、時間をかせぐために次回10月の部会に審議を持ち越すことにした。しかし10月25日の部会でも、原案をテクニカルレポート(TR)という規格ではなく単なる技術報告書にする案と、附属書1（シフトJISによる符号化方法をきめた部分）のみを規格から外すところまでしか妥協しないJCS委員長芝野との間で溝がうまらず、会は紛糾することになる。最後の最後に両者の中間点として附属書1～3（2はインターネット上で使用するISO-2022-JP、3はUNIXで使用されるEUCによる符号化方法をきめたもの）附属書を規格から外し“参考”にする案が急浮上、ここでようやく両者は妥結し、2000JISは最終審議で可決された。情報部会の部会長をつとめる棟上昭男（東京工科大学）は、以下のように説明する。

「情報部会で一番問題になったのは、私の感覚で言えば、これまでの遺産の扱いなんです。具体的には文字化けの問題ですね。古いシステムは古いシステムでまだ存在する。一方でメーカーとしては顧客のサポートを考えなくてはならない。今までの遺産との関係において、客先へのサービスが大変になったり、クレームをつけられたりすることが多くなるだろう、そういうことを恐れて、とりあえず実装法（符号化方法）に関してそういうきついタガをはめないでほしい、そういうことでした。規格原案の文字集合そのものに関しては高く評価する。しかし実装法に関してはISO/IEC 10646系（Unicode）の行方を見定めてからでもいいのではないかと、そういう意見がかなりあって、私からみると経過措置というか、そういえば言い過ぎかもしれないが、そういうことで附属書を参考にして納めたんです。

　規格にする前のテクニカルレポートにしてはどうかという意見も、メーカー側からかなり出ました。特に昔のシステムは日本電気とか日本IBMが基盤を提供していたところがあるし、逆にいえばそういうところが、データベースにしろ業務用システムにしろ、多様な顧客のいろんな要求にこたえて提供していたところがある。そこの部分をどう考えるのかと。そこの面倒見の問題ですね」

　また、シフトJISをめぐる審議を以下のように説明する。

「情報部会でも芝野委員長は、シフトJISのところ（附属書1）は、まず参考でも良いという意見でした。附属書2と3はまずいけれど、シフトJISの部分はどっちみちテンポラリーなものだからという感じであったと記憶しています。もともと情報処理学会情報規格調査会（ISO/IEC JTC 1の全活動に対応する国内審議組織。会長は棟上部会長）の関係者のあいだでも、シフトJISはもういいんじゃないですか、やめにしましょうよという意見で、趨勢としてはいろいろシフトJISは制限もあるし、これまでの技術ということでいいのではないか、そういう空気が支配的でした」

　つまるところ、情報部会で議論が集中したのは2000JISの中身、つまり収録された文字ではない。反対理由としてあげられたのは、文字にどうやってコードポイントを与え、コンピューターに実装するのかという符号化方法についてなのだった。

●シフトJISとは、いったい何なのか？

　ここで、少し過去にさかのぼって、シフトJISの歴史を振り返ってみる。そうしないと、この情報部会で何が問題になったのか理解するのが難しいからだ。

　正式には“符号化文字集合”と呼ばれる文字コードの規格は、大きくふたつの部分に分かれる。ひとつは収録する“文字集合”の部分、もうひとつがその文字のコード位置を定義し、どのようにしてコンピューターなどに実装化するかを規定する“符号化方法”の部分だ。このふたつを分けることで、文字コードはだいぶ理解しやすくなるはずだ。つまり、以下のように覚えてほしい。

　　　　符号化文字集合（文字コード）＝文字集合＋符号化方法*1

　ごく普通に“JISコード”とか“JIS漢字コード”などという場合は、通常JIS X 0208（以下0208）を指す。もともとこの0208は、単独で運用されるように考えられた文字コードだった。しかし、もしアメリカ英語の文字コード（US-ASCII）の日本版JIS X 0201（以下0201）と同時に使用できれば、プログラム開発が非常に簡単になる。プログラム言語はアメリカ英語により記述されているし、これと漢字をあわせてプログラムを書くことが、日本語ソフトウェア開発では必須だからだ。

　0208と0201を同時に使用する方法は、0208の規格本文によれば、特定の制御符合（エスケープシーケンス）を使って符号化文字集合を切り替えるJIS X 0202で定められた方法だ。しかし、これをパソコンに実装するには難点がおおく、現実にはシフトJISという80年代初頭にマイクロソフトとアスキーが考案した符号化方法がデファクト標準として普及することになった。

　つまり、文字集合として国内標準の0201と0208を使い、符号化方法としてデファクト標準のシフトJISを使うという、ある種片寄った実態のなかで、日本のパソコン市場は成長していったのだ[*7]。

[*7]……ちなみにこの状態を現実的なものにしようとしたのが0208の第4次規格、97JISで、ここにおいて初めて規格本文にシフトJISの詳細が規格で明文化された。

　ところで誤解が多いのだが、シフトJISは文字集合を規定しているわけではなく、基本的には0201と0208を同時に8ビット固定で使うための“ルール”だ。つまりシフトJISは純粋に“符号化方法”であって“文字集合”ではない。これが現実に何を意味するかというと、“外字セットの種類だけシフトJISのバリエーションがある”ということなのだ。当然バリエーションが違うもの同士の間では文字化けが発生する。

　詳しく説明しよう。そもそも0208では縦94×横94＝8,836字分の容器の中に6,879字しか定義していない。つまり1,957字の空き領域がある。Windows 3.1よりも前のMS-DOSの時代は、ここに各社さまざまな外字を入れ[*8]、符号化方法はシフトJISを使い実装していた。

　つまり同じ“シフトJISマシン”と言っても、メーカーごとに外字部分で違う文字集合を実装していた。この柔軟性こそがシフトJISの美点でもあったのだが、反面、例えば日本電気のPC-9801と富士通のFM-Rの間で、この外字領域の文字が化けてしまうという事態が起きていた。

　さらにいえば、シフトJISで使える領域は全部で11,280字あるわけで、前述したように外字を抱え込んだ0208の94×94＝8,836字の領域をそのまま収録しても、まだ2,444字の空き領域ができる。この空き領域に、さらにメーカーは外字（主にユーザー定義用外字エリア）を入れており、これも同様に文字化けの原因になっていた。

　これは、Windows 3.1から始まるWindows標準時代になっても事情は変わらなかった。マイクロソフトはWindows 3.1の開発にあたって、それまでの既存各社の外字を整理して、『Windows標準キャラクタセット』という符号化文字集合を制定したのだが、これは符号化方法はシフトJIS、文字集合は0208と0201、そして空き領域に日本電気と日本IBMの外字を入れ込むというものだった。

　同様のことは、MacOSにも言える。アップルコンピュータはマイクロソフトがやったのと同様に、符号化方法はシフトJISを使い、空き領域に独自の外字を定義した。当然WindowsとMacintoshの間では、文字化けがおこる領域が出てしまう。

　これらの空き領域に定義された各社の外字が“機種依存文字”と呼ばれているものだ。つまり、ひと口に“シフトJIS”といっても、想像される以上に多くのバリエーションが存在し[*9]、それらは同時に、常に文字化けの可能性をはらんでいた。

[*9]……ここではパソコン上のシステムだけを述べたが、当然ながらシフトJISはパソコンだけに実装されているわけではない。現在漢字を表示できる情報・通信機器の符号化方法は、まずシフトJISである可能性が高い。例えば携帯電話、ビデオデッキなどの家電、あるいは街角の電光掲示板、高速道路上の情報表示システムなどなど。

　つまり、符号化方法としてシフトJISはデファクト標準の座を占める一方、97年の改訂以前の0208が空き領域をユーザーに開放していたおかげで、日本語を使うパソコンの間では、多少の差はあれ、文字化けが常態化してしまうという状況下に長い間おかれ続けていた。

　

●シフトJISには未来がない。だから2000JISも……

　話はここで、ようやく10月の情報部会にもどる。情報部会で問題になったのは、2000JISによって、また新たな符号化方法、特に新しいバリエーションのシフトJISを誕生させることの是非だった。他にも細かい理由はあったようだが、要はこれに尽きる。新しいバリエーションのシフトJISは新たな文字化けを生む。これが規格として成立すれば、市場からは実装要求が強まる。もし本当に実装すれば、メーカーは従来のシフトJISとの間で身動きがとれなくなるおそれがある。本当にそういう問題が発生するのかどうかはさておき、少なくともメーカーはそこを強く心配した。

　2000JISは従来あった空き領域をほとんどすべて埋め、そこに新しい文字を入れることによって拡張する方法をとった（他の符号化方法との互換性を配慮して、空き領域を全部は埋めていない）。それは同時に従来ここに外字を入れていた会社にとって、文字化けが発生することを意味する。そんな面倒なものを新たに作るよりは、ISO/IEC 10646（Unicode）があるじゃないか。先に引用した棟上会長の発言はこういうことを意味している。

　ISO/IEC 10646（Unicode）の最大のメリットとはなにか？　前述したように、それは多言語版の開発が非常に容易だということだ。それ自身のなかに世界中の多くの文字を含んでいるISO/IEC 10646（Unicode）は、いったんプログラムをこれで記述すれば、日本語版であろうと、フランス語、ドイツ語であろうと、はたまた中国簡体字版であろうと、中国繁体字版であろうと、台湾版であろうと、韓国語版であろうと、部分的な修整でことがすむ。シフトJISにはこういう拡張性がない。

　もともとUnicode（ISO/IEC 10646）は、その中に0201や0208、そして補助漢字と呼ばれるJIS X 0212でさえも包含する。つまり上位互換の文字コードだ。MicrosoftもApple ComputerもUnicodeを制定・推進するUnicodeコンソーシアムのフル会員であり、OSを含めてUnicode化を着々と進めており、すでにWindowsもMacOSもUnicodeへの対応を終えている。冒頭の「2000JISがUnicodeに収録された段階で2000JISをサポートする」というコメント、そして前回の原稿末尾で「2000JISで新たに収録された文字は、いくつかの段階をへて2～5年後にはすべて使用可能になるだろう」と書いたのは、こういう事情を反映したものなのだ。

　今後MicrosoftやApple ComputerなどのUnicodeコンソーシアム参加企業が、Unicode以外の文字コードを採用することは絶対にあり得ない。日本だけを市場にしていた従来と違い、これから国際的なビジネスをするにはUnicode以外の解はありえない。バスに乗り遅れてはならないのだ。情報部会の委員たちの共通認識は、このようなものだったと思われる。

　さらに付け加えれば、UnicodeもISO/IEC 10646も拡張を進めている最中であり、2000JISで新たに収録された文字だって、ISO/IEC JTC 1/SC2に申請すれば収録できる。情報部会の委員であり、同時にISO/IEC JTC 1/SC2の国内対応委員会（情報規格調査会SC2専門委員会）、つまり日本を代表して国際の場に参加する委員会の委員長、石崎俊（慶應義塾大学）も、以下のように明解に言い切る。

「2000JISの新しい文字は、時期はさておき、ほぼ100％遠からずISO/IEC 10646に収録されます。不確定要素はあるが、今のところ２年後を目途に考えています」

　もともと2000JISの多くの文字は、すでにISO/IEC 10646（Unicode）に収録されている。また、新しい文字がISO/IEC 10646に収録されれば、ほぼ自動的にUnicodeにだって収録されるのだ。そういう、いわばUnicodeへのレールが敷かれた状況下で、いたずらに新たなシフトJISを作ることは、文字化けの要因をまたひとつ増やすだけで、顧客を混乱させることでしかない……。

　このようにして、2000JISはいくつかの修整をへて成立した。しかしおさまらないのがJCS委員長、芝野耕司だ。彼は上記の情報部会の論調を「たんなる建前だけのUnicode推進論」と斬って捨て、「日本のメーカーはデベロッパーとしてもユーザーとしても当事者能力を失ってしまった」と断ずる。それは、修整を呑まざるをえなかった原案作成者の、失礼ながらごまめの歯ぎしりなのか？　しかし、ここで思い出してもらいたい。芝野はISO/IEC 10646を策定する国際機関、ISO/IEC JTC 1/SC2の、他ならぬ委員長なのである。つまり、誰よりもISO/IEC 10646（Unicode）を深く知り、推進する立場にあるはずなのだ。その彼が、なぜシフトJISにこだわったのか？　彼は何を考え、何をやろうとしているのか？

　申し訳ないが、またまたここで紙幅がつきた。次回のお楽しみである。では来週お会いしましょう。

◎参考URL

▼2000JISそのものについて

・開発声明( http://www.tiu.ac.jp/JCS/ )

・原案資料( http://jcs.aa.tufs.ac.jp/ )

・文字表( http://jcs.aa.tufs.ac.jp/fdis/X0213t-p1.pdf 、および http://jcs.aa.tufs.ac.jp/fdis/X0213t-p2.pdf )

・規格化決定( http://jcs.aa.tufs.ac.jp/jcs/X0213-std.htm )

▼JIS規格のしくみについて

・日本工業標準会（JISC）公式サイト( http://www.jisc.org/jis1.htm )

・JIS制度全体のワークフロー図( http://210.154.33.36/j/other/zoom.html )

・情報分野の標準化をめぐる議論( http://www.itscj.ipsj.or.jp/jp/plaza.html )

▼国際規格とその標準化団体について

・UCS(ISO/IEC 10646)とUnicodeの現状( http://www.kobysh.com/tlk/elicon.htm )

・Unicodeコンソーシアムの公式サイト( http://www.unicode.org/ )

・ISOの公式サイト(The International Organization for Standardization)について( http://www.iso.ch/ )

・IECの公式サイト( http://www.iec.org/ )

・ISO/IEC JTC 1の公式サイト( http://www.jtc1.org/jtc1.asp?SubComm=JTC*space*1&Organization=ISO*slash*IEC&TechComm=JTC*space*1 )

・情報処理学会情報規格調査会（ISO/IEC JTC 1 に対応する国内審議組織）公式サイト( http://www.itscj.ipsj.or.jp/ )

・ISO/IEC JTC 1/SC2の公式サイト( http://anubis.dkuug.dk/jtc1/sc2/ )

▼その他

・日本語EUC・シフトJIS間コード変換仕様とコード系実態調査( http://www.opengroup.or.jp/jvc/cde/sjis-euc.html )

・日米欧の標準化の取り組みの歴史と国際標準化について( http://www.miti.go.jp/press-j/science/x71110a1.html )

・文字コード標準体系検討専門委員会報告書(99-08) (99-09-22版) ( http://www.itscj.ipsj.or.jp/domestic/mojicode/houkoku922.pdf )

◎参考文献

上記のURLのドキュメントと、文中にでた規格の規格票本文の他にも、以下の雑誌・書籍より多くの知識を得ました。記して感謝いたします。

・ことばと国家（田中克彦　岩波新書　81.11.20）

・日本語情報処理（Ken Lunde著　ソフトバンク　95.8.25）

・土台揺らぐ日本語処理（日経バイト　96.5）

・課題残す文字コード標準化（日経バイト　97.7）

・JIS漢字字典（芝野耕司編著　日本規格協会　97.11.25）

・漢字文化は危なくない　見えてきたUnicode3.0（月刊ASCII　98.6）

・Unicodeを巡る放談会　Unicodeはどうやって決まっているのか（月刊ASCII　98.12）

・パソコンにおける日本語処理／文字コードハンドブック（川俣晶著　技術評論社　99.6.10）

・文字コードの世界（安岡孝一・安岡素子著　東京電機大学出版局　99.9.30）

・漢字問題と文字コード（小池和夫・府川充男・直井靖・永瀬唯著　太田出版　99.10.1）

◆訂正ならびに補遺

　この原稿の発表後、いくつかご意見をいただき、筆者はこの原稿にいくつかの訂正と補遺を加える必要を感じた。そこで、これらを別記することで、明示的に筆者はどこを間違えたか、どこの部分を補足したのかわかるようなかたちで読者にお伝えしようと思う。筆者が間違えた部分も、じつは読者にお伝えするべき情報であると思うからだ。貴重なご指摘、ご意見に対し、こころから感謝いたします。なお、〈　〉は原文、《　》は訂正後の原稿をあらわす。

[訂正1]……読者の方から、日本工業規格は訳語ではなく正式名称であるとのご指摘をいただき修正した。

〈JISはJapan Industrial Standardの略称で、日本工業規格と訳される〉
《JISはJapan Industrial Standardの略称で、正式には日本工業規格という。》

(2000.1.27　同年2.12加筆)

[訂正2]……マイクロソフト株式会社より、以下のような指摘をいただいた。メールより引用する。

>具体的に気になったところは、
>1)「なぜ文字化けはおこるのか。違う文字コードとのあいだで変換に失敗するか
>らだ。」
>->
>2)「世界中の人々がUnicodeさえ使えば文字化けなしに情報交換できる」という論
>の運びです。
>最初の問題定義、そこからの解決策という運び方は着眼点も含めて非常によいの
>ですが、問題定義1)と解決策2)の間が(物理的に)離れすぎていて、読者に「そう
>か、Unicodeをつかえば文字化けがおきないのか」という早とちりをひきだして
>しまうようでもったいないと思いました。
>
>問題定義 1)のなかの着眼点：「違う文字コードとのあいだで変換に失敗する」を
>生かす形でUnicodeの解決策を述べるならば、もう少し丁寧に2-a) 「Unicodeを世
>界共通の文字コードとして使えば、違う文字コードとのあいだの変換で生じてい
>た文字化けは原理的に存在しなくなる。」と限定的に書いたほうが誤解が少ない
>と思います。

上記のご指摘にもとづき、以下のように修正した。
〈Unicodeは後者の手法であり、より徹底して、複数の言語というより世界中の言語を収容して、世界中の人々がUnicodeさえ使えば文字化けなしに情報交換できる――という、ユーザーにとっては夢のような世界の実現を目指したプロジェクトなのだ。〉
《Unicodeは後者の手法であり、より徹底して、複数の言語というより世界中の言語を収容する文字コードをつくり、これを世界共通の文字コードとして使って、違う文字コードとのあいだの変換で生じていた文字化けは原理的に存在しなくさせる――という、ユーザーにとっては夢のような世界の実現を目指したプロジェクトなのだ。》

(2000.1.27　同年2.12加筆)

[訂正3]……直井靖さんより以下のような指摘をいただいた。

[訂正3-1]
>>Unicodeは後者の手法であり、より徹底して、複数の言語というより世界中の言語
>>を収容して
>「言語」というより「スクリプト」じゃないですか？「スクリプト」が耳慣れない
>言葉だとしたら、「世界中の言語を記述するための文字」とか……。 

　直井さんのご指摘のとおりだ。「言語」という単語は、日本語とかドイツ語とか いった場合のひとつのまとりをあらわす。つまり「話し言葉」や「書き言葉」をふ くんだ、その総称ということになる。言葉について原稿を書こうとする人間にとっ て、初歩的なミスといえるだろう。なお、直井さんのおっしゃる「スクリプト＝ script」については、ただ今勉強中。今の私のような状態をあらわすのに、最適な 言葉がある。「泥縄」である。

(2000.1.31) 

　その後、スクリプトの概念を勉強して原稿に反映させた。しかし、こんな基本的なことを知らずに文字コードの原稿を書くとは……。我ながら呆れてものが言えない。下記の訂正にくわえて、スクリプトを説明する補注1を加筆した。

〈もうひとつが複数の言語を単一の文字コードの中に入れてしまう方法だ。Unicodeは後者の手法であり、より徹底して、複数の言語というより世界中の言語を収容〉
《もうひとつが複数のスクリプトを単一の文字コードの中に入れてしまう方法だ。Unicodeは後者の手法であり、より徹底して、複数のスクリプトというより世界中のスクリプトを収容》

(2000.2.12)

[訂正3-2]
>>それ自身のなかに世界中の多くの文字を含んでいるISO/IEC 10646（Unicode）は、
>>いったんプログラムをこれで記述すれば、日本語版であろうと、フランス語、ド
>>イツ語であろうと、はたまた中国簡体字版であろうと、中国繁体字版であろうと、
>>台湾版であろうと、韓国語版であろうと、部分的な修整でことがすむ。
> 
>「Unicodeで記述すれば」というより「Unicode用のシステム・ルーチンを呼び出し
>て使用するプログラムであれば」というようなことでは？

　これもまことにその通りで、けっして〈Unicode で記述すれば〉いいだけの問題 ではない。なによりもプログラムがUnicodeに対応していなければ問題にならない。 そこで、以下のように訂正させていただこうと思う。

・訂正前 
〈それ自身のなかに世界中の多くの文字を含んでいるISO/IEC 10646（Unicode）は 、いったんプログラムをこれで記述すれば、日本語版であろうと、フランス語、ド イツ語であろうと、はたまた中国簡体字版であろうと、中国繁体字版であろうと、 台湾版であろうと、韓国語版であろうと、部分的な修整でことがすむ。シフトJISに はこういう拡張性がない。〉

・訂正後 
《それ自身のなかに世界中の多くの文字を含んでいるISO/IEC 10646（Unicode）は 、いったんプログラムをこれで記述すれば、日本語版であろうと、フランス語、ドイツ語であろうと、はたまた中国簡体字版であろうと、中国繁体字版であろうと、台湾版であろうと、韓国語版であろうと、ISO/IEC 10646（Unicode）に対応したアプリケーションであるなら、部分的な修整でことがすむ。シフトJISにはこういう拡張性がない。》 
(2000.1.31) 

[訂正4]……山本もぐさんからの指摘により以下の点を修正した。

〈日本工業標準会〉
《日本工業標準調査会》

(2000.2.12)

[補遺1]……マイクロソフト株式会社より、以下のような指摘をいただいた。

>筆者の図式「符号化文字集合（文字コード）＝文字集合＋符号化方法」に従えば、
>「複数の文字コードを切り替えて使う方法」
>は図式右辺の文字集合そのものを丸ごと取り替えながら使う方法で、同一符号で
>もどの文字集合を使っているかで表現している文字が違ってくるのに対して、
>「複数の言語を単一の文字コードの中に入れてしまう方法」
>は図式右辺の文字集合を単一にして異なる符号には異なる文字が対応しているの
>で曖昧さが生じません。

筆者としては、考えもしなかった視点で、まさに目からうろこが落ちるような指摘であった。自分の考えを世に問う意味とは、まさにこのような反応に出会うためなのかもしれない。
この指摘じたいはISO/IEC 2022とUnicode（ISO/IEC 10646）を比較し、後者の利点をのべているが、ここでは、シフトJISとUnicode（ISO/IEC 10646）を比較し、より原稿の趣旨がつたわるように補足的に説明させてもらうことにしよう。

符号化文字集合（文字コード）＝文字集合＋符号化方法

シフトJISを上記の図式にあてはめてみると、以下のようになる。

シフトJIS実装機＝（0201＋0208＋機種依存文字）＋シフトJIS

　なぜシフトJISを実装したコンピュータの間で文字化けを招きやすいか、この図式で分かりやすく理解できる。つまり右辺カッコ内の“機種依存文字”の項が、OSによって違ってしまうからだ。よって右辺の総和は各OSにより異なってしまう。
一方でUnicodeはどうだろう。これはちょっとややこしい。

Unicode＝Unicode文字集合＋さまざまな符号化方法

　Unicode（ISO/IEC 10646）は文字集合として世界中の文字をふくめ単一固定化するものだ。その一方で符号化方法はいくつかある。それぞれの符号化方法によりアクセスすることのできる文字集合が違うので、厳密には等号ではむすばれないかもしれない。これは以下のような式であらわせられる。

UCS-2⊆UTF-16⊆（UCS-4＝UTF-8）[補遺1の訂正1][補遺1の訂正2]

　つまり、UCS-2とUTF-8は同じ範囲の文字集合をアクセスし、UTF-16のアクセスする文字集合はこれを含み、UCS-4は以上をすべて含む。つまりすべての符号化方法がアクセスできる部分があることがお分かりいただけると思うが、この部分こそが現在制定がほぼ終わり、実装がすすみつつあるBMP（Basic Multilingual Plane、基本多言語面）であり、およそ64,000文字を収録する。0208の6,879字と比べると、これがいかに膨大な数かわかるだろう。
　Unicodeの利点は、この現在使用可能なBMPに収録された文字をあつかうかぎり、どのような符号化方法でも文字化けしない、言葉をかえれば符号化方法が変わっても文字化けしないということだ。
　
　しかし、最後の最後でちゃぶ台をひっくり返すようなことを言って申し訳ないが、0208もUnicodeも文字集合の非互換な変更（従来空欄だった区点に文字を追加するのではなく、入れ替えたり、変更したりする変更。文字化けが発生するので、文字の符号化で絶対やってはならないことのひとつ）をおこなっているおり、バージョンによって文字集合が違うということは指摘しておきたい。勘のいい読者なら、すでにお分かりかもしれないが、本文中で説明をさけたUnicodeとISO/IEC 10646の違いも、このUnicodeのバージョンに依存する。
　
　以上、まったく用語を解説しないで文章を書いた。ここででた難解な用語、特にUnicodeの符号化方法については4回以降の原稿で解説していくつもりだ。
(2000.1.27)

[補遺1の訂正1]

高橋征義さんより、以下のような指摘をいただいた。

>さて、先日の連載での補遺、
>/www/column/ogata/part1_2.htm
>を読ませていただいたのですが、2点ほど気になる点があります。
>一つ目は、シフトJIS実装機を
>
> （0201＋0208＋機種依存文字）＋シフトJIS
>
>と規定しているところですが、この「0201」を素朴に導入してしまうのは
>問題があるのではないでしょうか。これではいわゆる「￥問題」が説明
>できません。0201とASCIIを曖昧なまま使い続けてしまったつけが、
>文字化けの一端となっている以上、何らかの形で言及してほしいと思い
>ます。もっとも、ここに触れると分かりにくくなってしまうので、深入りを
>避けたということであれば、それも一つの見識かとは思いますが。
>
>もう一つは、
>
> UCS-2＝UTF-8⊇UTF-16⊇UCS-4
>
>という式です。正直、符号化文字集合であるUCS-2、UCS-4と、
>符号化方式であるUTF-8、UTF-16が並列しているところから気になる
>のですが、それはおくとしましても、このUTF-8の位置付けは問題なの
>ではないでしょうか。UTF-8はUTF-16よりも大きく、UCS-4と
>同じ広さを持ちますよね？
>IETFでUTF-8を規定しているRFC2279では、
>
>(略)
>0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
>0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx
>
>という例すら示して、UTF-8が31ビットの空間を持つことを述べて
>います。あるいは単純なミスかもしれませんが、そうであれば訂正して
>いただけたらと思います。もし私の理解が違っていましたら、申しわけ
>ございません。

　どうやら筆者の一夜漬け、付け焼き刃がここで一気に露呈されてしまったようで、なんともお恥ずかしいかぎりだ。たぶん“馬脚をあらわす”という表現は、こういうときに使うのだろう。

　まず指摘の1、つまり0201における「￥問題」について。これについては高橋さんも薄々お分かりのとおり、じつは承知のうえで一緒、というより埒外にしたので、訂正はご容赦いただく。つまりこの式は、アメリカ英語の文字コードであるUS-ASCIIとの関係を問題にしておらず、シフトJIS実装機間の文字化けを説明しようとしたものだからだ。
　ただしこれはとても根元的な問題をふくむので、この機会にくわしく書きたい。もちろんこれは私の理解なので、もしも誤解があれば読者の皆さんにはどんどんご指摘いただきたいと思う。

　高橋さんはUS-ASCIIとその日本版規格JIS X 0201との間の文字の違いをおっしゃっている。US-ASCIIは'63年に制定され、のちに世界中の文字コードの基本になったもので、各国の文字コードはUS-ASCIIを発展させるかたちで制定した歴史がある。これをつかう限り文字化けがおこらないゆえんである。US-ASCIIは7ビットコードだ。

　ここでちょっと脱線して、この“○ビットコード”という言葉を説明する。たとえば7ビットコードとは、“コードポイントを7桁の2進数（7ビット）であらわす文字コード”という意味だ。7桁の2進数であらわすことのできる数は、2の7乗で128。つまり7ビットコードは128の文字をコード化できることになる。同様の計算で、0201などの8ビットコードは2^8=256文字、現在のUnicode、つまりUCS-2などの16ビットコードは2^16=65,536文字、Unicodeが最終的に目指すUCS-4の32ビットコードにいたっては、2^32=4,294,967,296、つまり42億9496万7,296文字。気が遠くなりそうな数だ。

　ところで、この○ビットコードの文字数をもとめる計算式というのを、私はいつもすぐに忘れてしまい、そのたびに友人に恥をしのんで聞くか、7ビットは7の2乗だっけ、いや2桁2進数は、00、11、01、10、なるほど4か、では2×2で、ということは……などということをグルグル考えなければならないハメにおちいる。なぜなら、このような英語のABC、日本語のあいうえおにあたる初歩の初歩の計算式が、

「どの文字コードの本にも書いていない」[補遺1の訂正1の訂正A]

からである。どうやら現在文字コードを語るには、上記の計算式がごく当然、言わずもがなの了解事項でなければいけないらしい。算数音痴の私としては、同じ轍を自分の原稿でおかしていた心苦しさが、この文章を書くことで解放でき、ほっとしている。


　話をもどす。US-ASCIIは7ビットコードだが、ここで規定された94文字（残りは不可視の制御用符合）ではウムラウトが必要なドイツ語、セディラが必要なフランス語などは表現できない。そこで、94文字のUS-ASCIIのうち、12文字をてきとうな自国の言語の文字に入れ替えて使い、残りのアルファベットの大文字・小文字などはUS-ASCIIそのままという規格が考えられた。つまり、これを使えば大筋では判読が可能な情報交換ができるわけだ。これこそ'67年に制定されたISO/IEC 646であり、この枠組みを使って日本、イギリス、ドイツ、フランス、スウェーデンなど、多くの国の言語で対応バージョンがつくられた。

　日本の文字コードの基本であり、US-ASCIIの日本版規格、JIS X 0201は、'67年に制定された。つまり上記のISO/IEC 646と同年であり、ヨーロッパ各国に先駆けて作られたものだ。これは8ビットコードの枠内に、ローマ字94文字、カタカナ他を63文字、あわせて157文字を規定する（残りは保留域と制御符合）。このうちローマ字部分は上記ISO/IEC 646の枠組みを使って配置されており、つまり大ざっぱにはUS-ASCIIと互換性がある。

　今、「大ざっぱに」という書き方をした。これが高橋さんの言われる「￥問題」である。0201では、US-ASCIIのバックスラッシュ、つまり“/”の逆向きの記号のコードポイントに“\”をおいた。このため例えば「\1,200」という1200円をあらわす0201の数字の文字列を、US-ASCIIに変換したとたんに“\”の文字が化けてしまう。
　もちろんISO/IEC 646の枠組みを使ったのだから、US-ASCIIと違う文字があり、ここで文字化けがおこるのは当たり前なのだが、この“\”とバックスラッシュを、運の悪いことに80年代になって、マイクロソフトがMS-DOSやWindowsで、ファイルの位置を表記する際の区切り文字として使うようになり、混乱は拡大してしまった。区切り文字はファイル名などで使用禁止となるなど、特殊な属性を与えられるのでだ。ここでは詳しく書かないが、たとえばアメリカ英語版のアプリケーションを日本語版にローカライズしたり、逆に日本語のアプリケーションをアメリカ英語版にする場合、プログラマーはややこしい処理を強いられることになる。
　
　以上が「￥問題」のあらましである。より詳しくは『文字コードの世界』（安岡孝一・安岡素子著　東京電機大学出版局）の第2章、それに『パソコンにおける日本語処理／文字コードハンドブック』（川俣晶著　技術評論社）の82ページ以降を参照してほしい。

　さて、次に指摘の2。これはUTF-8はBMPにしかアクセスしないと思っていた私の間違い。正直にいえば、高橋さんがおっしゃるような「単純ミス」ではなく、「理解不足」といった方がよい。また、これについて前寺正彦さんからも同様のご指摘をいただいた。

・訂正前
〈UCS-2＝UTF-8⊇UTF-16⊇UCS-4〉

・訂正後
《UCS-2⊇UTF-16⊇（UCS-4＝UTF-8）》
(2000.1.31)

▼[補遺1の訂正1の訂正A]

　この点について、他ならぬ川俣晶さんから以下のようなご指摘をいただいた。

> 　拙著の「パソコンにおける日本語処理／文字コードハンドブック」の冒頭(11
> ページ)にて、ビットを何個集めると、何種類の数値を表現できるかを記述して
> います。
> 　一応、2のべき乗で増加すると書きましたが、これでも分かりにくいでしょう
> か?　2^(ビット数)のように数式の形で書いた方が良かったでしょうか

　この本を、まるで教科書のように何度も読んで勉強した筆者のとっては恐縮のいたりである。もちろんこのご指摘の部分は読んでいた。しかし、情けないことに筆者は“べき乗”という表現が脳味噌のどこにもヒットせず、わけも分からないまま読み流していたのでございます。トホホ。算数音痴の開き直りととっていただいても結構だ。ただ、“べき乗”という概念をあらわす単語で説明するよりも、思考の道筋をたどれるような数式をしめした方が、一見むずしそうだが、かえってシロートには分かりやすいんですよ～、ということは、ちょっと言わせてください。

〈このような英語のABC、日本語のあいうえおにあたる初歩の初歩が、〉
《このような英語のABC、日本語のあいうえおにあたる初歩の初歩の計算式が、》
(2000.2.12)

[補遺1の訂正2]

羽毛田信拓さん、高橋征義さんより指摘があって、集合記号の向きが逆であることが判明し、修正した。いやはやなんともお恥ずかしい限りだ。慣れないことをするもんじゃない。

〈UCS-2⊇UTF-16⊇(UCS-4＝UTF-8)〉
《UCS-2⊆UTF-16⊆(UCS-4＝UTF-8)》
(2000.2.12)

[補遺1の訂正3]

Nob.Koikeさんから「符号」と「符合」が混ざって使われているという指摘をうけた。単純な筆者の間違いであり、「符号」に統一した。

(2000.2.12)

(2000/1/26)

[Reported by 小形克宏]