ちくちく日記

文書フォーマットの国際化とオープン化

セミナー, その他, 文字

先日受けた文字情報技術促進協議会のセミナー「文字と情報処理の変遷とこれから」の中で、村田 真氏の話された「文書フォーマットの国際化とオープン化」についての解説が面白かったので、メモがわりに書き起こし。

（セミナー内で、内容についてのSNSやブログでの発信について特に注意はありませんでしたが、何か問題あれば削除します）

「文書フォーマットの国際化とオープン化」

まず、ゼロックスの話から。最近、富士フィルムに買収されたことで話題です。

Starについて

ゼロックスのワークステーション Star。

1980年代のもの。35年前。今のWindowsやMacはゼロックスの技術に影響を受けている

ネットワークにつながり、文書や図形の編集もできた。電子メールもレーザープリンターもあった。

日本語にも対応、80年代にヘブライ語、アラビア語などにも対応していた。つまり文字を右から左に並べることができていた。

商業的には失敗したが、技術的にはきわめて優れていた。

Starはどのように文字を扱っていたのか。

StarではXerox Character Code Standardを採用

これはゼロックス独自の文字コードで、欧米の文字だけでなくて、アラビア語もヘブライ語もキリル文字も中国語、日本語、韓国語、様々な文字が扱えた。

そしてそれを混在させることができた。

これが、Unicodeの原型。Joe Beckerがこれをまとめ、ユニコードコンソーシアムを設立した。Unicodeという名前をつけたのも彼。

Starの文書エディターについて

Starは残念ながら、市場から消えたが、実は市場から消えるずっと前から社内では「メンテナンス不能」と言われていた。つまり誰も中身がわからない。当然拡張もできない。

Starの文書エディターは巨大なソフトウエアで、ちゃんと理解するのもメンテナンスも大変。

それだけではなく、本質的な問題もあった。体系上の空白ともいうべき問題点。

Starを支えた技術はおおまかに3つあり

ジーンズというネットワークプロトコル。

パイロットというOS

メサというプログラミング言語

ジーンズは洗練されかたでは初期のインターネットを上回る、パイロットやメサもどれも当時としては極めて優れた技術だった。

ところがジーンズには文書フォーマットの規定がなかった。

つまりStarが作る文書がどんな構造をもちどういうデータであるか、それを書いたドキュメントがどこにもなかった。

それじゃまずいというのはゼロックスもわかっていて、ちゃんとした文書フォーマットを作ろうという話はあった。研究所でインタースクリプトという文書フォーマットの研究も行われた。今見ても面白いアイデアはそこに見られる。しかし完成せず、途中で放棄された。そのため、体系上の空白がうまれた。

Starはどんな形式で文書を保存していたのか。

聞くところによると、メモリーダンプみたいなものをそのまま保存していたらしい。

Starの文書エディター内部構造をそのまま書き出していた。それはStarの文書エディタにとっては扱いやすいけれども、他のプログラムにとってはまったく扱えない代物。

Starで作成した書類はStarでしか扱えなかった。

どうしてそんなことになったのか。本当のところはわからないが、想像するに、一つは性能、メモリーダンプのようなデータはまた読み込むのが早い。文書フォーマットを定義してしまうと、読み込む時、書き出す時、そのための処理をしなければならない。Starはたださえ遅かったので、少しでも処理速度をあげるため（文書フォーマットを避け）メモリーダンプをそのまま読み込んだ。

もう一つはコスト、ドキュメントフォーマットをちゃんときめて開発すると10億円とかそういうお金がかかる

そういうことができなかったので、Starの文書構造を知るにはStarの文書エディタプログラムのソースコードを読むしかない。

ゼロックスの場合は人がどんどんやめちゃうので、そうなるとどうなるか。プログラムを読める人がどんどん減った。だれもわからない。そういうことになった。

実際のところ、Starによって作られた電子化文書は大量に残されたが、そこからテキストを取り出すこと、埋め込むことは決して簡単ではなかった。

ワープロの話

Starがゼロックスで作られた頃、日本ではワープロ専用機が盛んに作られていた。東芝のJW-10など。

ワープロ専用機は日本で非常に使われましたし、なくなった後もパソコン用にワープロソフトが作られた。松や一太郎など。

当時のワープロでどんな文字コードを使い、どのような文書フォーマットを使っていたか。

当時の資料が今ではあまり見つからない。当時もあまり公開されていなかった。

ワープロではJISX0208をもとに作られたが、各社が独自に拡張していた。文書フォーマットは各社各部門独自にやっていて資料や情報も公開されていなかった。

結局のところ、ワープロ文書が大量にあってもそこからテキストを取り出したり、埋め込んだりということは簡単にはできなかった。

ワープロ文書の標準化について

80-90年代、ワープロのための文書フォーマットを標準化しようという話があった。標準化するといろんなワープロ間で文書交換ができるようになる。

ところが標準化の試みはすべて惨めなばかりの失敗に終わった。ISOではODAというフォーマットが一時盛んにやられたがそれも見事に失敗した。ほとんど使われなかったと思う。私もそれに深く関わっていました。

日本国内でも幾つかの標準化の動きがあったが全部失敗した。

なぜ失敗したか

先ほどのStarの時と違ってパソコンの性能は上がってきていた。性能が理由ではない。

いろいろ難しい話があり、何が原因だったのかわかっていない。とにかく大失敗だったというだけに止めておく。

標準化の失敗と同時期に、ワープロソフトの市場も変わってきた。Wordが世界中で使われるようになった。皆、中立フォーマットではなくこれでよいのではと思うようになった。

私はこれはだめだと、文書交換の理想はこれで消え失せたと感じた。ワープロ文書の標準化はもう2度とできることはないと思った。

マークアップ言語

SGML

HTML3.2

HTML国際化（IETF RFC 2070）

XML1.0

HTML4.0

HTML5.0

マークアップ言語は文書フォーマットが公開されており、様々なプログラムで使うことができる

一番有名なものはHTML。これはワープロのためのものではなく、Webのためのもの。

こういったマークアップ言語では最初から文書フォーマットが公開されている。ある会社の特定のワープロしか使えないということはない。

ブラウザも検索エンジンもhtmlエディタも使える。様々なプログラムがhtmlをつかい、今なおWebを支えている。そういう意味でワープロの文書より大きく進歩している。

マークアップ言語での文字の扱いはどうなっていたか

最初のSGMLでは実態としてはワープロ程度。多言語の混在などできなかった。

ある時Gavin Nicolという人が提案をした。

1.内部コード（プログラム内部で扱うコード）とファイルに書き出すときの外部コードは分けて考えよう

2.内部コードとしてはUnicodeを採用しよう。

3.外部コードはなんでも構わない。ShiftJISやEUCでもよい。そういったコードはUnicodeの一部しか表現できない特殊なエンコーディングだとみなして、取り込んだ瞬間にUnicodeに変換して使用してしまおう

4.どの外部コードが使われているか、判断するための仕掛けを作ろう。

この提案によってマークアップ言語における文字の扱いが大きく変わった。今世界中の言語でWebが使われているがこれは彼の提案による貢献が大きかったと思う。この4つの考え方が今でもWebの国際化の中心をなしている。

この提案に基づいてHTML国際化仕様が作られた（IETF RFC 2070）

この提案が取り入れられたのはHTML4から。同時期にXMLにも。

内部コードとして、Unicodeを採用し、外部コードとしてシフトJISやEUCなど他のコードを認めた。

今ではUnicodeの文書の方が多いが、当時はShiftJISやEUCの方が多かった。Gavin Nicolの提案はSJISやEUCを見つめつつ、段々にUnicodeへ移行することを可能にした。

マークアップ言語についてのまとめ

HTML4以降で内部コードにUnicodeを使い、外部コードにそれ以外のコードを認めた。

マークアップ言語はただのテキストなので、いろいろなプログラムから触ることができる。

HTMLはWebに使われているが、ワープロ文書やDTPフォーマットに取って代わるにはまだ力不足というのが世の中の認識。

再びワープロ文書のフォーマットについて

ワープロ文書の標準化はできないものと一度諦めていたが、ある時から風向きが変わり、オフィス文書フォーマットOOXMLとODFという新しいフォーマットがでてきた。

なぜこのフォーマットがでてきたのか、ひとつにはアンチマイクロソフトの流れ。

ユーザーの意識の変化。オフィス文書はユーザーの知的財産が入っている。それを一企業の独自フォーマットにロックインされていていいのか。それはまずいのではないかと欧米の政府や地方自治体が考えた。ユーザーの知的財産をユーザーが自由に活用するためにはフォーマットのオープン化が必要。そのため国際標準化を要求した。

OOXMLとODFの実態はZIPで固めたXMLや画像ファイル。

内部コードとしても外部コードとしてもUnicodeを採用している。SJISやEUCはもう認められていない。

それまでもマイクロソフトのバイナリデータを解析して、いろいろな処理をしていた人はいるが、OOXMLになってから格段に精度が上がった。

OOXMLとODFは広い範囲のオフィス文書を表現できる。特にOOXMLはパワーポイントやExcelなどの文書フォーマットも表現できる。

Starの文書エディタは中身がわからなくなりメンテナンスできなくなったが、OOXMLによってマイクロソフトオフィスにはどんな影響があったか。

マイクロソフトの開発リーダーから聞いた話。以前は新人が入ってきたらソースコードをばさっと渡して「これを読め」今はちがってOOXMLの仕様書をばさっと渡して「これを読め」になった。7000ページの規格書だが、プログラムのソースコードを読んで仕様を知るよりはるかに楽でしょう。

OOXMLはISOなどの委員会で今でも保守されている。

電子書籍の話

今国内外の電子書籍のほとんどはEPUBというフォーマットで作られている。

EPUBファイルの実態はZIPファイルの中にHTMLやXML文書をまとめたもの。

マークアップ言語のよいところを受け継いでいる。EPUBも内部コードも外部コードもUnicode。

ZIPファイルを解凍してしまえば中身はただのテキストなので、どんなプログラムからも触ることができる。

まとめ

英語と日本語だけの文書のように幾つかの言語しか扱えないような文書からUnicodeによって多言語を扱える国際化された文書となり世界中で使えるものになった。

特定の文書エディタにしか扱えないメモリダンプから、多くのプログラムに読める文書フォーマットになった。

自然言語テキストを電子化文書から抜き出すことも、書き戻すことも今なら簡単になった。

Webもオフィス文書も電子書籍もすべてカバーすることができるようになった。

感想

優れた技術でありながら、内部がブラックボックス化した結果、扱える人がいなくなりだれも読むことができなくなったStarの話、なかなかに示唆に富む現代寓話である…。

Permalink | コメント(0) | 18:19