5月16日午前、マイクロソフト新宿オフィスにてWindows VistaでのJIS X 0213:2004の対応と、システムフォントとして搭載される『メイリオ』に関するプレスセミナーが開催された。これにより年末にも出荷が予定されているWindows Vista（ビジネス版のみ年末。コンシューマ版は来年1月予定）における日本語環境の実装がだいぶ明らかになってきた。

　今回は予定を変更し、これについて2回に分けて報告したい。まとめるにあたっては、同日午後に行なわれたフォント開発者向けセミナー、および今年2月3日に開催された『PAGE2006』（日本印刷技術協会主催）でのセッション「日本語文字セットとフォントの新しい環境」[*1]で話された内容も適宜参照して、Windows Vistaにおける文字コードと文字セットに関し、今の時点で最も詳細な内容を目指したい。

　ただし、私自身は一貫してJIS X 0213の2004年改正での例示字体変更に反対してきたのも事実。しかしこの原稿ではマイクロソフトのメッセンジャーに徹し、なるべく正確に彼等の言ったことを、そのまま読者に渡すよう努めたいと思う。どうしても我慢ができなくなったら、注釈で反論させていただくことにしよう。

　ところでこの日のセミナーは、新しく搭載されるフォントレンダリング技術ClearTypeや、新フォントのメイリオについても説明された。しかし、ここでは文字コードと文字セットに絞ってお伝えすることをお断りしたい。これについて興味のある向きは、僚誌『PC Watch』の記事をご覧いただきたい[*2]。なお、2月に掲載したままになっている特別編31の続きは鋭意書き進めているところだ。こちらの方もなるべく早く公開したいと考えている。中断ばかりで申し訳ないけれど、もう少しお待ちいただければと思う。

● 最初の一歩は「マイクロソフト標準キャラクタセット」

　プレスセミナーの冒頭、まずマイクロソフト・ディベロップメント次席代表の加治佐俊一氏が登場し、今回のWindows VistaにおけるJIS X 0213:2004（以下、マイクロソフトの用語に従い「JIS2004」と略）対応の位置付けと、今までのWindowsにおける日本語実装の歴史について語った。

　そこで最初に掲げられたのは、マイクロソフトの日本における経営戦略『Plan-J』だ。このうち、「産学官のパートナーシップ」という項目が、今回のJIS2004への取り組みに関わる。すなわちJIS2004という規格は、経済産業省主導の元、学識経験者と各メーカーや各団体、すなわち産学官が協力して開発された成果であり、マイクロソフト自身もこれに参画している。

　そして加治佐氏は、日本語をコンピュータ上で表現したり処理することは、技術としてまだまだ進化途上だと分析した上で、これからも技術革新を進めるためには、文字コードを安定したものとして実装していくことが必要であると位置付けた。

　次にこれまでのWindowsにおける日本語実装の歴史を振り返った。今回のJIS2004対応は3番目のものにあたるが、その最初が1993年リリースのWindows 3.1だ。これ以前、つまりMS-DOSの時代は、さまざまなメーカーが独自の文字セットをサポートしており、各社が拡張していた部分は情報交換ができないという状況にあった。Windows 3.1にあたり、同社は「日本のWindows」になるよう、バラバラだった文字セットを1つに統合する必要があった。こうして策定されたのが「マイクロソフト標準キャラクタセット」だ。

　ここで加治佐氏が強調したのは、同社の実装が標準に基づいてきたことだ。このマイクロソフト標準キャラクタセットは国内標準であるJIS X 0208:1990（以下、JIS90）を収録している[*3]。また、内部コードの符号化方法はシフトJIS[*4]だが、一部では国際標準であるISO/IEC 10646（≒Unicode）[*5]の採用を始めている。例えばグラフィックモジュール（API）として内蔵されているGDIだが、この時すでに内部ではISO/IEC 10646で動作している。

　これ以降、Windows 3.1からはビジネス版であるWindows NT3.1が出て、ここからWindows NT 3.5、Windows NT 3.51、Windows 4.0が続く。コンシューマ版としてはWindows 95が出ている。

● 続いてJIS X 0212に準拠、漢字約6,000字を追加する

　以上の環境をアップデートしたのが、1998年のWindows 98とWindows NT 4.0 SP4になる。ここでは日本語文字セットをJIS X 0212（補助漢字）に基づいて拡張、約6,000字を追加した[*6]。また、単に文字を追加しただけでなく、ここではIMEによりこれらの文字を入力できるようにしていると言う。

　ところでシフトJISが符号化できる最大文字数は約11,000字だ。とすれば、到底これでは約6,000文字もの追加はできない。ではどうやって？　ここでも登場するキーワードは「標準」だ。

　加治佐氏は「マイクロソフト標準キャラクタセットを作った際、1つ決めていたことがある。それはこれ以上シフトJISをベースとした中では、文字の拡張はしないということだ」と振り返る[*7]。そこで準拠することにした標準が、ISO/IEC 10646だ。もともとJIS X 0212はISO/IEC 10646の部分集合だが、このJIS X 0212の文字を、ISO/IEC 10646の符号位置として追加する形で実装している。この2番目の日本語環境は、OSとしてはWindows 2000、Windows Me、そして現在出荷されているWindows XPに受け継がれている[*8]。

　そして3世代目が、今回のセミナーで詳しく説明される、Windows Vistaにおける日本語環境だ。ここでも加治佐氏が強調したのは標準化だ。氏は「JIS2004が産学官の連繋の成果であることは最初に触れた通りだが、JIS2004自体が2000年に国語審議会が答申した『表外漢字字体表』に沿って標準化を進めたもの」と指摘する。

　最後に加治佐氏は、再度「大事なことは標準に対応していること、JISなりISO/IECなりの規格に対応していること」と強調して話を締めくくった。このように何度も言われた「標準の尊重」だが、この意味については次回改めてに考えてみることにして、今は報告を続けることにしよう。

● Windows Vistaで、約900字の漢字と約200字の非漢字を追加

　次に我々の前に立ったのは、マイクロソフト・ディベロップメントでプログラムマネージャーとして日本語実装を担当する阿南康宏氏だ。まず前置きとして、Windows Vistaでの新しい日本語環境全体に共通するテーマとして、「コラボレーション」「文化と技術の融合」の2つを挙げる。

　文字コードにおいてもこのテーマは同様だ。阿南氏は、「コンピュータで使われる文字と、従来からの印刷文化の中で使われる文字が整合性を保つことが大事」と指摘した上で、「コンピュータが日本の文化に準拠することにより、より広くより深く国民の皆さんにITのパワーが使われるようになるのではないか」と、Windows Vistaに対する期待感を表明した。

　その上で、阿南氏はJIS2004に対応する新たなWindows Vistaの文字セットの特徴として、端的に以下の2つを挙げる。

　漢字については後述するとして、非漢字の内訳は、ヨーロッパ諸語などで使われる発音記号付きのラテン文字、各種カッコ・記号類、アイヌ語や鼻濁音の表記に使われる濁音・半濁音つき平仮名・片仮名などだ[*9]。例えば発音記号付きのラテン文字の追加により、従来は表記できなかった英語の教科書の発音記号が表現できるようになったと言う。

　この発音記号付きのラテン文字や濁音・半濁音付き平仮名・片仮名は、ISO/IEC 10646で言うところの結合文字（combining character）として表現される。つまり単一の符号位置は持たず、複数の符号位置を組み合わせて1文字をレンダリングする。これはOpenTypeの処理エンジン（Uniscribe）によりサポートされる。

● Windows XPでは「現代の日本語表記」は網羅できない

　では、新しく追加された漢字の特徴はなんだろう。阿南氏は最大のトピックとして「現代の日本語表記に必要な漢字が、ほぼ網羅されたこと」を挙げる。例えば政令文字がすべて書けることだ。ここで言う政令文字とは以下の通り。

　以上はJIS X 0208の第1水準の範囲であり、これはすでに一番最初の文字セットから表現可能だった。ところが問題は以下のもの。

　このうちの一部はJIS X 0208の範囲を越え、JIS X 0213の第3水準が必要になっている。今回のWindows Vistaの新しい文字セットでは、これが表現可能になった。これは従来のWindows XPまでの文字セットではできないことだ。

● 辞書や教科書、書籍で使われるのと同じ字体が使える

　次にいよいよ文字の形を変更したものについてだ。ここで阿南氏は「紙に刷られた国語辞典、漢和辞典、教科書では、どんな印刷文字が使われているか」と提起する。そこでは「常用漢字表・1997年までの人名用漢字」は通用字体（略字体）、「常用漢字表以外の表外漢字」は正体（いわゆる康煕字典体）で書かれていると言う（図1）。

　このように、表外漢字なのか常用漢字なのかによって、辞書や教科書の世界ではきちんと字体が使い分けられているというのが現実だと言う。阿南氏はこれを包括するのが印刷標準字体だと説明する。「国語審議会の用語では、常用漢字表、それに1997年までの人名用漢字を含めた通用字体、加えてそれ以外の表外漢字字体表に示されたいわゆる康煕字典体の1,022字を合わせたものが印刷標準字体」とした[*10]。

　では、これに対してコンピュータの文字はどういう字体が使われているのだろう。そこでは常用漢字表や人名用漢字ではともかくとして、表外漢字では通用字体が多いのが現実だろう。一部のユーザーはこれを「JIS字」などと呼び、コンピュータの文字は一般に使われている書籍とは違うというレッテルが、長い間貼られてきた[*11]。阿南氏はこれについて「当社でも進捗の“捗”という字などは、辞書に載っている字と違うではないか、マイクロソフトはウソ字を搭載しているというご批判をいただいたことがある」と苦笑いしつつ振り返る。

　なぜこうした現実が生まれたのか。阿南氏は「一言でいうと現実に使われている字体と、コンピュータに使われている字に齟齬が生じていたということ」と指摘し、こうした齟齬の発生理由として「表外漢字に対する字体標準がなかったから」と分析する。

　こうして字体標準が必要になり、それに応えようとしたのが文部科学省の表外漢字字体表だということになる。しかしこれを現実の社会で使ってもらうようにするのは、1つの省庁の手には余る仕事だ。阿南氏はここで複数の省庁のコラボレーションがあったことを指摘する。「基本的に文字行政には3つのステークホルダーが存在する」として、以下のように説明した。

　以上に加え、こうして確立された各種標準に基づいて製品開発したマイクロソフトも、この「コラボレーション」に加えてよいはずだ。これが阿南氏が冒頭で言った「コラボレーション」「文化と技術の融合」につながるわけだ。JIS2004に対応することで、Windows Vistaは文化的にも法令的にも齟齬がなくなり、その結果、「現代日本語の“標準的”な表記ができる日本語環境が提供できるようになった」と阿南氏はまとめた。（次回完結）

◆修正履歴

[訂正1]……私は注釈8で以下のように書いた。

ところで、なぜ主な符号化方法がシフトJISであるWindows 98やWindows Meにおいて、シフトJISが符号化できる範囲を上回るISO/IEC 10646の文字が扱えるのだろう？　ここでは任意のAPIを用いて、TrueTypeまたはOpenTypeフォントの文字の形（グリフ）だけを取り出して描画することが可能になって いる。ただしこの場合は符号位置は付与されない。つまり過渡的な実装と言えるだろう。

　しかし、上記の〈ただしこの場合は符号位置は付与されない〉という記述は事実に反している。Windows 98やWindows Meにおいて（のみならずWindows 95でも）ISO/IEC 10646の符号位置を読み込み、また符号位置をファイルに出力することは可能だ。これは「OSがある符号化方法に対応するとは、その符号位置を入出力できることだ」という誤った認識からきている。実際には文字コード規格の実装とその符号位置の入出力は、必ずしも依存関係にはない。

　ではどのような場合に「対応した」と言えるのだろう。それは API（Application Programming Interface）が、その符号化方法を正しく解釈できるかどうかだろう。Windows 95以降、Windows NTや現在のWindows XPでも実装されているAPIセット「Win32 API」においては、ISO/IEC 10646の使用を前提とした多くの命令が用意されている。しかし、Windows 95～Windows Meに限っては、これらは用意されているだけで、実際には機能していないものがほとんどで、圧倒的多数の開発者は旧来の符号化方法（例えばシフトJIS）しか解釈できない命令を使ってアプリケーション開発をしていたのが実情だった。それ故にこれらのOSは〈主な符号化方法がシフトJIS〉となるわけだ。

　もっともこれらのOSでも、文字を扱ういくつかのAPIだけは、ISO/IEC 10646の符号位置を正しく解釈できた。これに加えてISO/IEC 10646に対応したフォント、例えばTrueTypeフォントを使うことにより、〈シフトJISが符号化できる範囲を上回るISO/ IEC 10646の文字が扱える〉ことが可能になっていたのである。

　以上を踏まえて、下記のように訂正する。（2006/6/2）

ところで、なぜ主な符号化方法がシフトJISであるWindows 95、Windows 98やWindows Meにおいても、シフトJISが符号化できる範囲を上回るISO/IEC 10646の文字が扱えたのだろう？　ここではごく少数ながらISO/IEC 10646に対応していたAPIを使い、さらにTrueTypeまたはOpenTypeフォントと組み合わせることで、ISO/IEC 10646の符号位置を読み書きすることが可能になっていた。ただしそれ以上の複雑な処理となるとお手上げだったのが実情だった。つまりこれらのOSでのISO/IEC 10646の実装は、過渡的なものと言えるだろう。

INTERNET Watch ホームページ

Copyright (c)2006 Impress Watch Corporation, an Impress Group company. All rights reserved.