Last updated 96/2/3

国際化WWWブラウザの設計と実装
--- i18n Arena

オムロン株式会社 システム総合研究所, 向川信一, 出水法俊

Design and Implementation of I18N WWW Browser --- i18n Arena

OMRON Corp., Advanced Systems Research Center, Shin'ichi Mukaigawa, Demizu Noritoshi

Email: shin@ari.ncl.omron.co.jp, demizu@ari.ncl.omron.co.jp

概要

W3Cが配布している HTML3.0検証用ブラウザである Arenaを 国際化し、中国語(C)、日本語(J)、韓国語(K)などの同時表示を実現する。

Abstract

We propose to change default encoding for HTML on HTTP. And we design and implement new internal structure for W3C Arena to display CJK simultaneously.

はじめに

現在、インターネットは 95ヵ国を結び、様々な言語による情報を世界規模で 流通させている。インターネットにおける主要な情報提供・探索手段である WWW においても、様々な言語による情報が提供されている。

これら様々な言語で記述された情報を表示するために、 Mosaic-l10n を はじめとして、WWW ブラウザの地域化 (localization) がこれまでなされてき た。その結果、西ヨーロッパの諸言語、日本語、中国語、韓国語などのうちの 個々の言語のみで記述された情報は読めるようになった。

ところが、日本語、中国語、韓国語と言った文字を多く含む言語を同時に 表示することができる WWW ブラウザは、現在のところまだほとんどない。そ のため、情報提供側もこれらの言語をひとつの文書内に混在させることが実際 的にはできず、次のような問題が発生している。

例えば 外国語教育の現場では、 教材内で母国語と外国語の2つの言語の同時表示が必要であるが、現在のブラ ウザでは日中韓のうちの2か国語以上を同時に表示するのは難しい。

WWW上でよく見かけるアプリケーションに 観光案内などのガイド ブック類がある。日本人向の日本語で書かれた日本国内の案内は 存在するが、 日本人向の 外国の案内は、ほとんど作成されていない。これは、韓国のガイ ドブックを書きたいと思っても、日本語とハングルを同時に表示できないため、 書けないからである。

また、ルーブル美術館の ようにフランス語などの西欧圏の文字を含むドキュメントを、日本語化された ブラウザで読むと その言語特有の文字が漢字に化けてしまう。

これらの問題を解決するためには、次の問題点を解決しなければならない。

  1. 文字コードに良い標準がない。
  2. 多言語(多コード)を混在処理できない。
以下では、これらの問題点について説明し、それに対する我々の提案と実証を 述べる。

文字コード

多国語を同じドキュメント内で混在させるためには、 ある言語に特化していない文字コードを使用しなければならない。

現在、日本語のエンコーディングとして EUC, Shift-JIS,JISが 使われているが、 このうち 日本語EUC, Shift-JISは 日本語用に特化しているため、 日本語のみしか扱わないアプリケーションにとっては都合が良い。 しかし、これらのコードには どの文字セットを使用するかを示す情報が存在しないため、 文字コードそのものからは なんらかのヒントがなければ、 どの文字コードであるか判断できない (通常は日本語のドキュメントであると仮定し 判別している)。
同じように 韓国語のEUC,中国語のEUC,Big5も その言語に特化しているため、 どの文字セットかを示す情報をもっていない。 そのため、同じドキュメント中に 日本語EUC,中国語EUCなどの 情報が欠落した文字コード(またはエンコーディング方式)を同時にいれてしまうと、 正しく その文字セットの文字として認識することができなくなってしまう。

混在処理

現在の表示用のライブラリ(Xウィンドウ用のMotifやAthenaウィジェット)は、 主に単一の言語を表示する構造になっているため、 それを使って 複数の言語を同時に表示するのは難しい。

例えば Mosaic-l10nでは Font、 Netscapeでは Language encodingを 指定することで、 表示する言語を切り替える仕組みになっている。 そのため、フランス語で書かれているページを見るときはLatin-1にといった、 手でモードを切り替える操作が必要になっている。

そのような表示用ライブラリを使用しているため、 現在のブラウザでは同時に複数の言語用のフォントを表示できる構造になっておらず、 言語を切り替える = フォントも切り替えるという実装になっており、 この実装による同時表示は 不可能である。 つまり、同時に複数の言語を認識し、正しいフォントを選択して表示する機能が 必要である。


HTTPにおけるHTMLのエンコーディングに関する提案

HTMLのデフォルトのエンコーディングを、 現在の ISO-8859-1(Latin-1)から、 ISO-2022とUNICODEに変更することを提案する。
  1. ISO-2022は以下の点でASCIIの代替のエンコーディングとして適している。
  2. UNICODEは 文字コード自体には 言語を示す情報が欠ているが、 多国語の文字を扱いやすく設計されている。

以上より 多言語を扱うには この2つのエンコーディングが適している。
さらに HTMLならば、ISO-2022とUNICODEを以下の方法に従えば、自動判別できるため、 2つのエンコーディングを両立することができる。

UNICODEとISO-2022の自動判別

HTMLドキュメントの先頭は ``<HTML>''のように 必ずHTMLのタグではじまる。 そのため、HTMLドキュメントの先頭には、必ずASCIIの文字が来ることになる。 UNICODEでASCIIコードの文字を表すと、"0x00XX"になるため、 UNICODEのHTMLドキュメントの先頭バイトは常に"0"になる。 これを利用して、先頭バイトが"0"の場合は UNICODE、 それ以外の場合は ISO-2022と判別が可能である。

charsetパラメータ

HTTPは、どのような内容でも転送できるフレキシブルなプロトコルであり、 テキストに関しても、どのようなエンコーディングであろうと 関係なく転送が可能である。 しかし、日本語のようにエンコーディング方式が ひとつに決まっていない言語の場合などを想定して、 "Content-type:"ヘッダに含まれる charsetパラメータによって エンコーディングを知るという方法が、 決められている。 しかし 以下のような理由で charsetパラメータを サーバ側で 付加するという処理は難しい。 以上の理由によって charsetパラメータの付加を正しく実装している HTTPサーバは、ほとんどなく、charsetパラメータなしでの httpによるドキュメントの転送が ほとんどである。 そのため、charsetパラメータなしで 多言語を表示するための、 デフォルトが必要であると考えられる。

i18n Arenaの実装の方針

多言語の同時表示(混在処理)を実現するために、以下の方針で実装を行った。
Arenaは Xのアプリケーションであるが、 X11R6の国際化機能である localeモデルを 使用しない。

locale

``locale'' は、ユーザインタフェースにおけるメッセージの言語や長さ等の 単位の指定、入出力における外部文字コードの指定、内部処理における処理対 象言語指定、画面表示関数における引数文字列の文字コード指定など様々な場 面で用いられている。複数の言語を同時に扱うアプリケーションにおいては、 これらの場面ごとに異なる ``locale'' を指定できなければならないと考える。 その理由を考えるために、``locale'' 情報を参照するとされている場面の例 を次に挙げる。

UNIX においては ``locale'' は大域情報として設定され、基本的にすべての 場面で同一の ``locale'' 値が使われることが想定されているようだ。しかし、 上記の例を考えると、各ライブラリ関数の引数として処理対象言語や内部文字 コード情報を渡す API にすべきだと考える。


i18n Arenaの内部

Arenaの内部構造は大きく、 W3CのReference Libraryと Arena本体に分けられる。 このうち Reference Libraryは HTTPの処理を行い、 HTMLの解析(パーザ)などの内部処理部分と表示部分が Arena本体側で行われる。

内部処理部分

オリジナルのArenaからの変更点を小さくし、 混在表示を行いやすくするために、 HTMLドキュメント用の内部コードを定義した。

Reference Libraryに含まれる SGMLパーザでは、 ISO-2022の処理を、そのまま パーザのステートに組み込んで行っているが、 Arenaのパーザは Reference Libraryのように 一つのステートマシンでは構成されていないため、 同じアプローチを取ることは難しい。 また、同じISO-2022の解析を表示の際に もう一度行う必要があり 2度手間になってしまう。

内部コードへの変換

元のパーザ内では HTMLは すべて ASCIIであると 仮定されており、 そのままでは ISO-2022, UNICODEを 処理することは難しい。
そこで i18n Arenaでは いったん すべてのHTMLドキュメントを 4byteの内部コードへ変換し、 コード系の違いを吸収することにした。 内部での扱いを楽にするため以下のように変換する。 内部コードの子細は このドキュメントを参照。 この内部コードによるメリット/デメリットは、以下のようになる。

メリット

デメリット 最近のページデザインの傾向では、 文字そのものよりイメージの占める割合が大きくなっているため、 テキスト部分が4倍になったとしても、 1ページのレンダリングに必要な全データに占める割合は それほど大きくならないと考えられる。

JPEGやGIFイメージは圧縮されているため、 メモリ中で実際にテキストが占める割合は、 例えば http://www.ntt.jp/では、2.4%であり、 i18n Arenaの内部コードに変換した場合でも 9.0%にしかならない。 この結果から、この程度の増加分は 全体からみて 無視できる大きさであると考えられる。 (1ピクセル 8bitとして計算した。 もし 1ピクセルが 32bitならば さらに割合は小さくなる)

内部コードを選択する際に いくつかの候補が考えられた。 もし、それらが使用できるなら コードの流用が可能であり 内部コードを直接 外部コードとして使用できる可能性がある。

  1. UCS-2(UNICODE)
  2. X11R6の Wchar
  3. Muleの内部コード
UCS-2は CJKを包含するエンコーディングのため、 そのまま表示が可能なら 非常に扱いやすい エンコーディングである。 しかし、ISO-2022からの 変換用のテーブルが巨大になること、 表示の際に もう一度変換が必要なため 2度手間になってしまうことから、 採用しない。 現在では UNICODEエンコーディングのX用フォントが 入手できないため、 漢字(CJKすべて)の ISO-2022から UNICODEへの変換は 意味がない。

Muleの内部コードは可変長でメモリ使用量を考慮しているが、 前述のように WWWブラウザでは テキストのメモリ使用量が ネックではないことから、 処理のしやすさを考えて 4byte固定長のコードを選択した。

X11R6のWcharは 必要な情報を取り出しにくく扱いづらいことと、 Xでしかメリットがないことから採用しない。

パーザの内部コード対応

Arenaが使用するHTMLパーザ部分を 内部コードの変更に従って変更した。 HTMLパーザが見る必要のある文字は ASCII部分のみであり、 UNICODEとISO-2022のASCII部分が同じ内部コードに マップしてあることから、パーザは 2つのエンコーディングの違いを 考えずに処理が行える。

その結果、内部コードへのコンバータを 拡張して新たな言語のサポートを 加えたとしても パーザ本体を修正する必要がなく、 追加作業が容易になる。

また、現在のArenaは Reference Libraryに 含まれている SGMLパーザは 使用していないため、 Reference Libraryそのものに手を入れる必要はない。 (Reference Libraryは Arenaとは別に開発されているため)

表示

前述の通り、Arena の国際化においては localeを使用しないため、 X11R6 の国際化表示関数を用いず、 locale とは独立した文字列表示ライブラリを作成した。

今後の課題

以上の提案によっても解決されていない問題が残っている。

フォールディング(禁則処理)

現在のフォールディングの処理は 既存のArenaのままなので、 スペースや タブで区切られた単位でしか行われない。 そのため、日本語のように 詰めて書かれ、任意の場所で改行できる言語では、 フォールディングが行えず、 思ったようなレンダリングができていない。

多言語のフォールディング方式が実現でき、 容易に追加が行える方式を 設計/実装する必要があり、 この問題に対しては、それぞれの言語のネイティブによるサポートが 必要であると考えられる。

タイ語などのサポート

タイ語のように 文字を重ね打ちして表現する 文字セットのレンダリングは考えられていない。 Muleでは ISO-2022にプライベートなエスケープシーケンスを付け加えて実現しているので、 Muleのエンコーディング方式を そのまま使用すれば実現は可能である。 しかし ISO-2022の範囲から逸脱してしまうため、 使用することはできない。

ディレクション

アラビや語やヘブライ語などの 右から左へと書かれる言語を 表示の際に、どのように扱うかの問題がある。 現在ようにデフォルトで 左から右へレンダリングされることに対しても、 なんらかの対応が必要である。 同種の問題に、日本語の縦書きの扱いがある。 つまり 縦横、右左で 4つの組合わせが存在し、 さらに それを混在が考えられる。

Reference Libraryへのフィードバック

現在のReference Libraryには LineModeブラウザ用のSGMLパーザと LineModeブラウザ側へ実装されるべきコードの一部が含まれている。

この部分を切り放し、現在のArenaなどの他のブラウザと 共通化できる部分を抽出し、 ブラウザ用の汎用ライブラリとして 独立させるべきである。


結論

デフォルトの文字コードの変更と、 同時表示可能な内部構造によって、 以下のことが 実現された。
  1. 中国語、日本語、韓国語、ギリシャ語、ロシア語、西欧圏の言語が 同じ文書中に 同時に 表示ができる。
  2. 既存の Latin-1(ISO-8859-1)を使用して書かれている HTMLドキュメントが そのまま扱える。
  3. エンコーディングにISO-2022を使用している文書は フォントさえあれば 表示可能。
  4. UNICODEドキュメントが表示可能(現在はLatin-1のみ確認)。
今後は 残った課題について W3Cと協力して、 解決策を 考えていきたい。

サンプル

i18N Arena用のサンプルを示す。 提案したデフォルトのエンコーディングによって書かれているため、 手で操作することなく、正しいフォントで表示される。 また、Latin-1と日本語などの混在が実現されていることが分かる。
  1. Greetings in CJK (CJK stands for Chinese, Japanese and Korean, dump)
    日中韓とフィンランド語の挨拶。Latin-1と entity表現を含む。
  2. Multilingual sample text (dump)
    Muleに付属の多言語の挨拶から抜粋。ISO-2022エンコーディング。
  3. Localized ISO646 symbols (JIS-Roman, dump)
    JIS X 0201と ISO-646の違いを区別するサンプル。
  4. Chinese sample text (Simplefied, GB, dump)
    GB 2312-80のみサンプル。
  5. Chinese sample text (Complexed, CNS, dump)
    CNS 11643のみのサンプル。元のページはBig5だったのを変換。
  6. Japanese sample text (iso-2022-jp, dump)
    ISO-2022-JPのみのサンプル。
  7. Korean sample text (iso-2022-kr, dump)
    ISO-2022-KRのみのサンプル。元のページは EUC_KRだったのを変換。
  8. Unicode sample text (ASCII & Latin-1, dump)
    UNICODEのサンプル。UNICODEへの変換フィルタにより作成。 ドキュメントの先頭部分を以下に示す。
    $ od -c unicode.html
    0000000  \0   <  \0   h  \0   t  \0   m  \0   l  \0   >  \0  \n  \0   <
    0000020  \0   h  \0   e  \0   a  \0   d  \0   >  \0  \n  \0   <  \0   T
    0000040  \0   I  \0   T  \0   L  \0   E  \0   >  \0   M  \0   u  \0   l
    0000060  \0   t  \0   i  \0   L  \0   i  \0   n  \0   g  \0   u  \0   a
    0000100  \0   l  \0      \0   H  \0   e  \0   l  \0   l  \0   o  \0    
    0000120  \0   <  \0   /  \0   T  \0   I  \0   T  \0   L  \0   E  \0   >
    0000140  \0  \n  \0   <  \0   /  \0   h  \0   e  \0   a  \0   d  \0   >
    (以下略)
    

Mukaigawa Shin'ichi, DEMIZU Noritoshi