会社情報

1.　古くて新しい問題

「また読めないメールが来てる。最近多いな。」

「メールの文章をテキスト保存したら、一部の文字だけ化けて読めなくなったよ。」

「ここのホームページ、いつもおかしく表示されて見られない。」

これらの例のように、文字データを表示させようとした時に意味不明な記号に置き換わって表示されてしまうことを、一般に「文字化け」と呼んでいます。主な原因は、「本来の文字コードと違う文字コードで表示してしまった」、「転送経路の途中で情報が欠けてしまった」、「機種依存文字を使ってしまった」、「表示するために必要なフォントがない」などです。皆さんも多かれ少なかれご経験があると思います。今回は、この「文字化け」について、改めて考えてみることにしましょう。

ところでこの「文字化け」、決して今に始まったことではありません。英語圏で発達したコンピュータで、他国語を表現し始めた時からついて回っている問題です。


１-１． なくなったわけではないが、今まであまり意識する必要がなかった
M/F（メインフレーム・コンピュータ）の頃は、「別メーカーのプリンタで印刷したらおかしくなった…」という類いの問題でした。

その頃の原因は、「本来の文字コードと違う文字コードで表示してしまった」と「機種依存文字を使ってしまった」の混合形でどちらとは言い切れませんでした。それは、機種（製造メーカー）と「コード体系」が渾然一体としていて、「文字コード」とはいえ見方を変えれば「機種依存文字」と同じだったからです。つまり標準化された「コード体系」を使っていなかったということです。　

しかし、そのような初期の頃の問題点は、SIerや情報システム部という社内システムを構築する人たちの努力により、通常の利用者が意識することはほとんどありませんでした。また、閉じられた世界であったので、構築された社内システムの中に違う「文字コード体系」が勝手に入り込んでくることはありませんでした。つまり、「文字化け」という問題は消えたわけではなく、長く（15年ぐらい）潜行していたのです。


１-２．インフラの向上と社会状況の変化が問題を呼び戻す

ところが、コンピュータを取り巻く環境の進化が、この隠されていた問題を表面化させました。最初はPC（パーソナル・コンピュータ）の普及です。ホスト・コンピュータが使用する「文字コード体系」^※1だけを表現できていれば良かった環境に、クライアント側単独で漢字までも表現できるPCが出現したのです。この時に採用されたのは、すでに規格として存在していたJIS（1978年初版発表）ではなく、シフトJIS（1982年発表）^※2という「文字コード体系」でした。





この時点で、社内システムはホスト・コンピュータが使用する「文字コード体系」との併存を余儀なくされたのです。この時は、情報を有効活用するために基幹系ホスト・コンピュータの世界と情報系クライアントPCの世界でデータ交換を行おうとすると「文字化け」のリスクがついて回りました。

それは、お互いに対応する「文字コード」に変換したいのに、ホスト・コンピュータの世界の機種依存文字とPCという世界での機種依存文字の相互非互換（片方にあって片方にない文字が存在する）が主な原因でした。これも、情報システム部の努力により対処されていました（リスクのある文字は使わない、あるいは使えないようにするなど）。

この頃も問題の範囲は、ほとんど社内に閉じられていたのです。

2.　グローバル化＝英語化、しかなかった

しばらくの間は、各国独自の形で英字＋母国語を実装して環境を構築していました。もちろんコード体系の整理標準化作業は進められていましたが、基本的には他国のことは自国には関係ありませんでした。

例えば、日本で利用されるシステムは英字＋日本語で構築、中国で使用されるシステムは英字＋中国語で構築、複数の国で利用されるシステムは英字のみとする。こうすることで、英語を核とするグローバルなシステムと各国に特化したシステムが棲み分けられて存在していました。つまりシステムが別々に存在していたのです。


２-１． オープン化の波とインターネット

ところが、ここに新たな進化がもたらされました。PCサーバやUNIXサーバを中心とするオープン化とそれに付随するインターネット環境（日本での商用利用は1992年、本格利用は1994年から）の登場です。ちなみに、この時UNIX環境でよく使われている日本語「文字コード」はEUC（1985年発表）でした。

ネットワークは、社内LANが構築され、それがWANで繋がり、さらにインターネット基礎技術を流用して再構築されたイントラネットへと進歩していきました。全く同じ仕組みの閉じた社内のシステムと、オープンにすべての国と繋がったシステムの二重化構造があっという間にできあがってしまったのです。

しかし、どちらのシステムも利用者の接点は、目の前のPCです。こうなってくると利用者にとって社内システムを使用するのも、インターネット上のシステムを使用するのも、相違はありません。こうして守られていた社内システムと社外システムとの違いが表面化してきました。


２-２． 繋ぐと止まる

そうなんです。今まで標準の技術を利用して社内ローカルのルールで独自に使い勝手の向上を図っていたシステムが、いきなり構築思想の違うシステムと繋がってしまったのです。あるいは、繋がらないまでも別ルールのシステムが同じ使い勝手で利用できてしまうのです。

こうなると、人というのは普段行っている行動を無意識のうちに取るものです。社内でしか利用することができない「文字コード」（例えばシフトJIS）を利用して、無意識のうちにインターネットの世界に電子メールを送ったりしてしまいます。もちろん運が良ければ何の問題も起こりません。しかし運が悪ければ「文字化け」を起こしてしまう可能性があります。

また、クライアントPCも格段に進歩しています。日本語OSのマシンから繁体字やらハングルやら他言語の入力ができてしまうのです。その結果として、グループウエアのスケジューラに訪問先名として普通に「深　」のような現地名を入力してしまうといったこともあり得ます。

最近のグループウェア・システムであれば最初から多言語同時利用を考えてUTF-8を採用しており、何の問題も起こらないでしょうが、設計が古いシステムでしたら、入力した途端に何が起こるかわかりません。

未対応コードとしてエラーを出力してくれたら、それは非常に優秀なシステムです。たいていは入力できてしまいます。そしてその後画面が表示されなくなってしまったり、画面が文字化けで覆われてしまったりという結果を招きます。もはや、「グローバル・システム＝英数字のみしか使われない」という共通認識ではないのです。


２-３． 統合すると化ける

業務システムも大変です。最近の業務システムは管理の容易さからブラウザ・ベースのものが多くなってきています。また、インターネット上で提供される各種サービスへのアクセスも、そのほとんどはブラウザを利用します。

このように共通インフラが整っていることにより、SaaSのような外部のサービスも活発に利用されていくでしょう。しかし、これら外部のサービスと社内のシステムが同じ「文字コード」を利用しているとは限りません。別々に利用している分には全く問題ありませんが、統合を図ろうとすると、データの相互運用性において問題が出てくる可能性があります。


２-４． 黙っていても化ける

JISの改訂を見ていただければおわかりのように、常用漢字の範囲は常に見直され、新しいコードが振られたりコードに対応する字体が変化したりします。オープンな環境で新しいインフラを追加していくと常に文字の互換性の問題はついて回ります。これはしばらくの間は避けられない問題として認めていくしかないでしょう。

３．考察（まとめ）

各国の都合が先行した「文字コード」の問題も、統合への道を歩み始めています。

Webベースのアプリケーションは、今後ますます企業内で利用されていくものと思われます。イントラネット対インターネットの対立軸も今後は過去のものとなっていくでしょう。その点を見据えて、新たにシステムを構築したり改修したりする場合には是非「文字コード」の規格も考慮に入れて（利用文字コードはUTF-8、対応ブラウザを限定しない）インターネットとの親和性の高い国際的なシステムを作り上げていって欲しいと思います。

＜参考文献＞

・『文字コード超研究』　深沢千尋著（ラトルズ）

・『図解雑学文字コード』　加藤弘一著（ナツメ社）