日本語の表示１

日本語の表示１
質問を頂いていて、放置している件を先に触れておきます。日本語の文字化け問題。結論を先に云えば、「文字化けを完全に回避出来る方法は、現状では技術的にない。」ということです。これはコンピューターの仕様に関するかなり深い問題であり、ハード面とソフト面の両方にまたがる問題なので、どこまで記すべきか悩んでしまうのです。日本語は、現在ソフトウェアを利用して表示されるようになっていますが、ここに至るまでには、長い歴史があります。その歴史的背景を理解していかないと、文字化け問題に対処することは出来ません。日本語のFontに関する問題は、現在尚、修正途上なのです。予測を先に云えば、いずれ新しいユニコード体系に統一されて行くでしょう。しかし、だからといって、現時点で現行のユニコードを先行的に使う、積極的理由はないのです。それは、現在のユニコード自体がまだまだ多くの問題を抱えたままであるからです。ある人は、JISコード（ISO-2022-JP）を使うべきだと云うそうです。これも？？？です。理由は上記と同様です。無難というレベルに過ぎません。現在日本語フォントの表記体系は、次の４種類があります。ＪＩＳ体系 Shift-JIS体系日本語EUC体系ユニコード体系これらの表記のベースになっているのは、印刷業界で用いられてきた日本語活字で、それは、康煕辞典の字体が元になっています。古書店ならお解りでしょうが、ここには異体字が相当含まれています。また、漢字表記に関しては、常用漢字、人名用漢字などの分別もあります。こういった事項が絡んだ状態で、日本語の漢字割り当てが、現状では整合的に出来ていないというのが実状なのです。既に記したように、コンピューターにとって、漢字は漢字として認識されているわけではありません。あくまでも２進法の数字の並びとして理解され、処理されています。文字コードというのは、16bit時代に、２バイト文字列を、数値化して表したものがベースになっています。例えば、アルファベットのAは８行１６列の表の中で、０と１の並びで表され、それを一行ずつ読み込んだものを、一つのデーターの固まりとして処理しています。（ランダムアクセスデーターの一種）いわゆる半角で、１バイト文字コード（ASCII文字）です。漢字の場合、８行１６列では表せないので、１６行１６列、即ち半角２つ分をデーターの固まりとして処理しています。これが全角で、２バイト文字コードです。 JISコード体系といわれるものはこの様にして始まりました。（最初はJIS C6226-1978　で1978年） JIS第一水準漢字、JIS第二水準漢字、等と呼ばれるものです。16進文字コードとも云います。当初、これらは、漢字フォントとしてROMボードで提供されました。 Macの文字化け問題は、漢字ROMボード時代に遡ります。 MacのOSとDOSでは、漢字に割り当てを行うROM領域が違っていたのです。そもそもAppleは、ハード面をユーザーがいじることを非常に嫌っていた会社です。漢字ROMボードを取り付けることさえ、当初認めようとしなかった。当然、それを取り付けるためのアドレス領域など用意していない。それを無理矢理空きアドレスを利用して取り付け、Macの日本語化が始まった訳です。それが互換性の面で、後々まで尾を引くことになってしまったのです。一方MicroSoftはただのソフトハウスで、日本ではNECの98で独占状態であった事も幸いして、空きアドレスへのROM割り当てに対してハード面で関知しないし、NECなどが積極的に主導していった訳です。 Shift-JISというのはMicroSoftが定義した体系です。これは、２バイト文字と１バイト文字が混在する日本語環境でフォント割り当て文字列が 2バイトであるか１バイトであるかを判断する際に、ＪＩＳ体系では２バイトの場合には漢字In、outを示すコマンドをその都度プログラムに書き入れて処理しなければ区別できず、非常に不便でした。この問題に対処するために、１バイト文字のコードと２バイト文字のコードを一体にして振り分けし直し、その上でJIS体系に対してコード変換（encoding）を行う様にしたものが Shift-JISです。プログラム環境上では、非常に便利になるので、一気に普及しました。他のOS、例えばCP/MやOS-9等が席巻されていった背景として、この漢字処理の件が一因になったのです。 Sift-ＪＩＳというのはこの処理により、コード番号がずれていくことから呼ばれるようになった名前です。正式には「MS漢字コード」、JIS用語では「シフト符号化表現」といいます。そんなこんなで、漢字ROMボードを用いた日本語表示が進んで行ったわけですが、当初は使える漢字の種類が余りにも少なかったのです。それ故、各個人で外字を作ったりしていましたが、これは他の人との互換性が全くない私的なものでした。その為、拡張漢字コードとして、漢字の種類を増やしたものが Sift-JIS上で割り当てられたりしました。（閑話休題）この時期のプログラミングは、今と異なり、ホントに手間暇の掛かるものでした。漢字が使えるというのは感動ものでしたが、画面表示、印刷設定等、何かにつけてコード指定していくと云うのは、コード表とにらめっこしながらの作業で大変でした。(^^ゞ画面のテキストエリアでなく、画像エリアに漢字を表示させるなどと云う場合は、ワールド座標系から位置計算してプロットする等と云う作業で一文字表示も大変だったのです。まあ今では何の意味か解らない人が大半でしょうけど、大変だった事だけは知っていて下さい。思い出すと懐かしいけれど、二度と戻りたくない環境ですね。あの頃に比べると今の環境はホントに気楽で、簡単なのです・・・・。又、漢字の表示や印刷に、より大きなフォントを使いたいという要求がユーザーから強まります。こういう要求に対してはソフト的に処理します。最初は、ドットフォントを各種用意するということから始まり、ベクトルフォント、更にはプロポーショナルフォントに進んでいきます。 ○ドットフォントというのは、文字通り、フォントを点（ドット）で表していくもの ○ベクトルフォントは、フォントの拡大縮小表示の際に、ベクトル演算して表示するもの。凸凹が減り多少滑らかになる。 ○プロポーショナルフォントは文字種に応じて、そのサイズを微妙に修正し見栄えが良くなるようにしたもの。この事が、次には、ROMボード無しで、全てソフト的にファイル化されたフォントで処理するという発想を生み、さらには、ハングルやアラビア語などの各国語に対してもソフト的に処理するという発想で生まれたのが、 Windowsであったわけです。この時期に、MSとAppleが協力して作り上げたのが、TrueTypeフォントと呼ばれるものでした。これは旧来のBitMapフォントに対してスケーラブルフォントと呼ばれるもので、ベジュエ曲線などを利用して、フォントをかなり滑らかに表示するものです。（あの音のうるさいドットプリンターもこれでお払い箱）パソコン世界でこの様な進歩発展が次々行われていく中で、JIS体系は、どの漢字をどのコードに割り当てるかみたいなことばかり議論していて、全然時代に付いてこれなくなっていたのです。更にはＪＩＳの改訂が数度行われてきていますが、コード割り当てを変えたりしたこともあり、 Sift-JISとの１：１対応が狂ったりもしたのです。一方UNIX世界では、日本語EUC体系が使われています。（EUC=Extended Unix Code） UNIX体系とWindowsのベースであるDOS、その標準仕様であるShift-ＪＩＳでは、特殊記号のコード割り当てが異なるという問題があります。例えば、\記号や~記号などです。更には、これらの統合と、世界標準化を目指して、ユニコードが考えられましたが、今尚２バイト文字圏のフォントを網羅的に処理できているわけではありません。中国語の漢字フォントと日本語の漢字フォントなどです。 JIS体系の、ISOと云うのは官主導の国際規格であることを表していますが、これは、コンピューター上での仕様フォントだけに特化して規格化しているわけではありません。組み版用活字などの規格も配慮していかなくてはなりません。その分、コンピューターの進化速度に立ち後れてしまいます。一方ユニコードは民間コンピューター業界主導の規格です。両者は今は一応手を繋ごうとしていますが、いつまで続くか解らないのが現実です。漢字のencoding問題は、以前は各メーカー別に仕様が異なっていましたが、NECが98仕様からPC/AT互換機路線に路線変更したことで、Windows環境では仕様統一が出来ています。Appleだけ尚独立（孤立）状態。こんな状態ですから、最初に記したように、文字化け問題は、尚解消のための途上にあるとしか云えないのが、現状であるわけです。
ブラウザーは、あるサイト情報を読み込む際、HTML文の最初の数行を読み込んで、コード体系がどれであるかの判断をし、その上で、表示しています。最初の数行の読み込み段階で、この判定を間違えると、全く訳の分からない表示を行ってしまうわけです。こういう場面に遭遇したら、あわてずに、ブラウザーで再読込をかけてやります。何度か再読込すれば、書かれたコード体系に当てはまる形で表示するはずです。この場合ブラウザー側の設定を、コード体系の自動判定にしておく必要があることは云うまでもありません。古いブラウザーでは、ユニコード体系が読み込めないものもありますから、適当にブラウザーのＶｅｒＵＰにつきあう必要があります。サイト作りで強制的にコード体系を指定する場合には、メタタグで記述しておきます。メタタグで指定しない場合には、文字化けの起きる可能性が高くなります。そういう場合には、最初の数行のうちに、ダミー的に、特定コード体系でしか表示されない文字列を入れておくという裏技があります。この辺りは、ホームページ作成ソフトを使っている人が大半でしょうから、気にすることはありません。１つのサイトの中に複数のコード体系を用いたページを作らないと云うのが、まあ約束のようなものです。通常のHTMLページであればTopページで使うコード体系で統一しておくと云うことです。 CGIの記述文章の場合には、日本語EUCに強制指定しておく必要がある場合があります。この場合は、コード体系の異なるページの混在は仕方がありません。
どこから、何をどう記せばよいのか、解らないので、整理が付かない文章になっていますが、それほどこの漢字表記問題は根深いのだと理解して下さい。で、結局どう対処するのが良いかと云えば、対処法はないので、時を待ちましょう。体系が世界的に統一されるまでは、自分が一番使いやすい方法で行きましょう。それまで、文句はガンガン言って統一を促進させましょうということになる訳です。うーん。パソコン教室になりませんが、現実が上記の状態なので、仕方がありません。五月蝿い声に惑わされる必要はないということ位でしょうか、役に立つのは・・・・・。sigh! 希望を云えば、数式表現を考慮して、TEXのインターフェイスを改善し、使いやすくし、その上で、各ブラウザーが hyperTEXの表示に標準で対応すればよいと思うのですが・・・。なかなか難しいかも知れません。

日本語の表示１
質問を頂いていて、放置している件を先に触れておきます。日本語の文字化け問題。結論を先に云えば、「文字化けを完全に回避出来る方法は、現状では技術的にない。」ということです。これはコンピューターの仕様に関するかなり深い問題であり、ハード面とソフト面の両方にまたがる問題なので、どこまで記すべきか悩んでしまうのです。日本語は、現在ソフトウェアを利用して表示されるようになっていますが、ここに至るまでには、長い歴史があります。その歴史的背景を理解していかないと、文字化け問題に対処することは出来ません。日本語のFontに関する問題は、現在尚、修正途上なのです。予測を先に云えば、いずれ新しいユニコード体系に統一されて行くでしょう。しかし、だからといって、現時点で現行のユニコードを先行的に使う、積極的理由はないのです。それは、現在のユニコード自体がまだまだ多くの問題を抱えたままであるからです。ある人は、JISコード（ISO-2022-JP）を使うべきだと云うそうです。これも？？？です。理由は上記と同様です。無難というレベルに過ぎません。現在日本語フォントの表記体系は、次の４種類があります。ＪＩＳ体系 Shift-JIS体系日本語EUC体系ユニコード体系これらの表記のベースになっているのは、印刷業界で用いられてきた日本語活字で、それは、康煕辞典の字体が元になっています。古書店ならお解りでしょうが、ここには異体字が相当含まれています。また、漢字表記に関しては、常用漢字、人名用漢字などの分別もあります。こういった事項が絡んだ状態で、日本語の漢字割り当てが、現状では整合的に出来ていないというのが実状なのです。既に記したように、コンピューターにとって、漢字は漢字として認識されているわけではありません。あくまでも２進法の数字の並びとして理解され、処理されています。文字コードというのは、16bit時代に、２バイト文字列を、数値化して表したものがベースになっています。例えば、アルファベットのAは８行１６列の表の中で、０と１の並びで表され、それを一行ずつ読み込んだものを、一つのデーターの固まりとして処理しています。（ランダムアクセスデーターの一種）いわゆる半角で、１バイト文字コード（ASCII文字）です。漢字の場合、８行１６列では表せないので、１６行１６列、即ち半角２つ分をデーターの固まりとして処理しています。これが全角で、２バイト文字コードです。 JISコード体系といわれるものはこの様にして始まりました。（最初はJIS C6226-1978　で1978年） JIS第一水準漢字、JIS第二水準漢字、等と呼ばれるものです。16進文字コードとも云います。当初、これらは、漢字フォントとしてROMボードで提供されました。 Macの文字化け問題は、漢字ROMボード時代に遡ります。 MacのOSとDOSでは、漢字に割り当てを行うROM領域が違っていたのです。そもそもAppleは、ハード面をユーザーがいじることを非常に嫌っていた会社です。漢字ROMボードを取り付けることさえ、当初認めようとしなかった。当然、それを取り付けるためのアドレス領域など用意していない。それを無理矢理空きアドレスを利用して取り付け、Macの日本語化が始まった訳です。それが互換性の面で、後々まで尾を引くことになってしまったのです。一方MicroSoftはただのソフトハウスで、日本ではNECの98で独占状態であった事も幸いして、空きアドレスへのROM割り当てに対してハード面で関知しないし、NECなどが積極的に主導していった訳です。 Shift-JISというのはMicroSoftが定義した体系です。これは、２バイト文字と１バイト文字が混在する日本語環境でフォント割り当て文字列が 2バイトであるか１バイトであるかを判断する際に、ＪＩＳ体系では２バイトの場合には漢字In、outを示すコマンドをその都度プログラムに書き入れて処理しなければ区別できず、非常に不便でした。この問題に対処するために、１バイト文字のコードと２バイト文字のコードを一体にして振り分けし直し、その上でJIS体系に対してコード変換（encoding）を行う様にしたものが Shift-JISです。プログラム環境上では、非常に便利になるので、一気に普及しました。他のOS、例えばCP/MやOS-9等が席巻されていった背景として、この漢字処理の件が一因になったのです。 Sift-ＪＩＳというのはこの処理により、コード番号がずれていくことから呼ばれるようになった名前です。正式には「MS漢字コード」、JIS用語では「シフト符号化表現」といいます。そんなこんなで、漢字ROMボードを用いた日本語表示が進んで行ったわけですが、当初は使える漢字の種類が余りにも少なかったのです。それ故、各個人で外字を作ったりしていましたが、これは他の人との互換性が全くない私的なものでした。その為、拡張漢字コードとして、漢字の種類を増やしたものが Sift-JIS上で割り当てられたりしました。（閑話休題）この時期のプログラミングは、今と異なり、ホントに手間暇の掛かるものでした。漢字が使えるというのは感動ものでしたが、画面表示、印刷設定等、何かにつけてコード指定していくと云うのは、コード表とにらめっこしながらの作業で大変でした。(^^ゞ画面のテキストエリアでなく、画像エリアに漢字を表示させるなどと云う場合は、ワールド座標系から位置計算してプロットする等と云う作業で一文字表示も大変だったのです。まあ今では何の意味か解らない人が大半でしょうけど、大変だった事だけは知っていて下さい。思い出すと懐かしいけれど、二度と戻りたくない環境ですね。あの頃に比べると今の環境はホントに気楽で、簡単なのです・・・・。又、漢字の表示や印刷に、より大きなフォントを使いたいという要求がユーザーから強まります。こういう要求に対してはソフト的に処理します。最初は、ドットフォントを各種用意するということから始まり、ベクトルフォント、更にはプロポーショナルフォントに進んでいきます。 ○ドットフォントというのは、文字通り、フォントを点（ドット）で表していくもの ○ベクトルフォントは、フォントの拡大縮小表示の際に、ベクトル演算して表示するもの。凸凹が減り多少滑らかになる。 ○プロポーショナルフォントは文字種に応じて、そのサイズを微妙に修正し見栄えが良くなるようにしたもの。この事が、次には、ROMボード無しで、全てソフト的にファイル化されたフォントで処理するという発想を生み、さらには、ハングルやアラビア語などの各国語に対してもソフト的に処理するという発想で生まれたのが、 Windowsであったわけです。この時期に、MSとAppleが協力して作り上げたのが、TrueTypeフォントと呼ばれるものでした。これは旧来のBitMapフォントに対してスケーラブルフォントと呼ばれるもので、ベジュエ曲線などを利用して、フォントをかなり滑らかに表示するものです。（あの音のうるさいドットプリンターもこれでお払い箱）パソコン世界でこの様な進歩発展が次々行われていく中で、JIS体系は、どの漢字をどのコードに割り当てるかみたいなことばかり議論していて、全然時代に付いてこれなくなっていたのです。更にはＪＩＳの改訂が数度行われてきていますが、コード割り当てを変えたりしたこともあり、 Sift-JISとの１：１対応が狂ったりもしたのです。一方UNIX世界では、日本語EUC体系が使われています。（EUC=Extended Unix Code） UNIX体系とWindowsのベースであるDOS、その標準仕様であるShift-ＪＩＳでは、特殊記号のコード割り当てが異なるという問題があります。例えば、\記号や~記号などです。更には、これらの統合と、世界標準化を目指して、ユニコードが考えられましたが、今尚２バイト文字圏のフォントを網羅的に処理できているわけではありません。中国語の漢字フォントと日本語の漢字フォントなどです。 JIS体系の、ISOと云うのは官主導の国際規格であることを表していますが、これは、コンピューター上での仕様フォントだけに特化して規格化しているわけではありません。組み版用活字などの規格も配慮していかなくてはなりません。その分、コンピューターの進化速度に立ち後れてしまいます。一方ユニコードは民間コンピューター業界主導の規格です。両者は今は一応手を繋ごうとしていますが、いつまで続くか解らないのが現実です。漢字のencoding問題は、以前は各メーカー別に仕様が異なっていましたが、NECが98仕様からPC/AT互換機路線に路線変更したことで、Windows環境では仕様統一が出来ています。Appleだけ尚独立（孤立）状態。こんな状態ですから、最初に記したように、文字化け問題は、尚解消のための途上にあるとしか云えないのが、現状であるわけです。
ブラウザーは、あるサイト情報を読み込む際、HTML文の最初の数行を読み込んで、コード体系がどれであるかの判断をし、その上で、表示しています。最初の数行の読み込み段階で、この判定を間違えると、全く訳の分からない表示を行ってしまうわけです。こういう場面に遭遇したら、あわてずに、ブラウザーで再読込をかけてやります。何度か再読込すれば、書かれたコード体系に当てはまる形で表示するはずです。この場合ブラウザー側の設定を、コード体系の自動判定にしておく必要があることは云うまでもありません。古いブラウザーでは、ユニコード体系が読み込めないものもありますから、適当にブラウザーのＶｅｒＵＰにつきあう必要があります。サイト作りで強制的にコード体系を指定する場合には、メタタグで記述しておきます。メタタグで指定しない場合には、文字化けの起きる可能性が高くなります。そういう場合には、最初の数行のうちに、ダミー的に、特定コード体系でしか表示されない文字列を入れておくという裏技があります。この辺りは、ホームページ作成ソフトを使っている人が大半でしょうから、気にすることはありません。１つのサイトの中に複数のコード体系を用いたページを作らないと云うのが、まあ約束のようなものです。通常のHTMLページであればTopページで使うコード体系で統一しておくと云うことです。 CGIの記述文章の場合には、日本語EUCに強制指定しておく必要がある場合があります。この場合は、コード体系の異なるページの混在は仕方がありません。
どこから、何をどう記せばよいのか、解らないので、整理が付かない文章になっていますが、それほどこの漢字表記問題は根深いのだと理解して下さい。で、結局どう対処するのが良いかと云えば、対処法はないので、時を待ちましょう。体系が世界的に統一されるまでは、自分が一番使いやすい方法で行きましょう。それまで、文句はガンガン言って統一を促進させましょうということになる訳です。うーん。パソコン教室になりませんが、現実が上記の状態なので、仕方がありません。五月蝿い声に惑わされる必要はないということ位でしょうか、役に立つのは・・・・・。sigh! 希望を云えば、数式表現を考慮して、TEXのインターフェイスを改善し、使いやすくし、その上で、各ブラウザーが hyperTEXの表示に標準で対応すればよいと思うのですが・・・。なかなか難しいかも知れません。