株式会社エヌフォー V.J.Catkick

●Be OSの現状

 さてBe OSである。そして日本語環境である。ユーザサイドから見れば「日本語処理」や「日本語表示」、「日本語入力」等をまとめて「一口」で言ってしまうが、作る方 はなみなみならぬ努力と忍耐が必要である。これでも最近のプログラムは、以前から比べるとかなり迅速に簡単にポーティング 出来るような組み方がされている。但し、日本語がネイティブな、日本の「国語」教育を経てきた人間が開発に、しかも初期から携わってきた場合のみである。

 幸いにもBe OSのデベロッパチームには日本語を話す日本人 がいるので、某Nという携帯端末 の開発チームよりは話が早い。実際に先日行われたBe Developers Conferenceでも多言語の入力デモを行っていたし、OSが開発途上 ということもあり、「日本語OS」の期待は持てるであろう。たとえ「エラーメッセージが英語」だったり、「ファイル名に日本語が使えなかったり」しても、だ。

 OSやアプリケーションの開発者側から見ると、「日本語を表示出来る」と「日本語を含んだデータの処理が出来る」には大きな差がある。「日本語の入力が出来る」となるともっと話は複雑 だ。

 「日本語を表示出来る」の場合は単純にフォントを用意してやれば良いだけである。何らかの方法、例えば通信手段等を用いて「日本語の含まれている」テキストファイル等をマシンに仕入れ、ワープロ かなにかで読み込んでフォントの指定をしてやれば、大方は読める 。まぁ、2バイトがどうの、フォントのエンコーディングがどうのという話はこの際抜きにしての話ではあるが…。

 「日本語を含んだデータの処理が出来る」となった場合、一番のネックになるのはソーティングということになる。大概文字コード順に並べてしまうので、住所録などは思った順番にならないことがおおい。「力石」という苗字 があったとして、この人が「りきいし」さんなのか、「ちからいし」さんなのかは文字を見ただけではわからない。人間だって「力石」と書かれた名刺を見ただけではどちらかわからない。ましてコンピュータには後数百年 ぐらいしても無理かも知れない。結果、「ふりがな」なるフィールド等を作ってひらがなで「りきいし」と入れるのが一般的な常識となる。

 でもこういった「日本人にしかわからない一般的な常識」といったものは、ちょっとやそっとで身につくものではない。例えば今、韓国向けの住所録ソフトを作ることを考えてみれば簡単に理解出来るであろう。日本人には「韓国人にしかわからない一般的な常識」は理解出来ないのである。玄人が裸足で逃げ出すようなソフトを作っても、それを使うのは「一般ユーザ 」である、ということだ。

 だいぶ話が脱線 したが、要は米国から来るソフトウェアなりハードウェアにいきなりの期待をしてはいけないということである。確かに冒頭で書いたように、Beのチームには日本人がいるし日本語も表示出来ている。しかしながらこれらは未だに「日本語を表示出来る」の域を出ていないのが現状で、まだまだ「日本語を含んだデータの処理が出来る」には課題が沢山残っているのである。これからのフラッシュアップに期待したい。

●UNICODEについて

 Beでは従来のパーソナルコンピュータの日本語文字セットとは違った文字セットを標準で使用している。従来の文字セットとは、一部業界人 には悪名高きShift-JIS のことである。

 なぜShift-JISが悪名高きなのかちょっと触れておこう。コンピュータには「〜バイト 」という単位があって、1バイトで最大256の数字 を表すことが可能である。英語の文字は26文字×2の52文字しかないので、1バイトあれば全部の文字を表すことが出来る。しかし日本語の場合、ひらがな、カタカナ、漢字と文字が多く、1バイトではとても表現出来ない。そこで2バイト使うことによってそれらを表現しようとしたのがShift-JISである。無論他の方法、JISやEUCでも基本的な考え方は一緒である。この「2バイト使う」がネックになるのである。

 貴方が米国人で何かのソフトを作るとする。データのサイズに制限があったり、何らかの理由で大きなフィールドは極力避けたいとする。故にあるフィールドでは5バイトのサイズを取った、としよう。そこへShift-JISを3文字入れたらどうなるであろうか?Shift-JIS3文字、2バイト×3文字なので6バイト。フィールドは5バイトなので最後の1バイトを削って保存 する。当然Shift-JISの3文字目は壊れる、という結果になる。表示が出来なくなったり、フィールドのデータそのものが壊れたりもする。こういった問題 がそこここに点在するのである。

 そこでBeはUNICODEに注目 することになる。UNICODEは大まかに言えば、アルファベットもひらがなもカタカナも漢字も、そして中国語やハングルまでも1つの文字につき2バイトという原則を作り対応させたコード体系である。

 ハナから 2バイト1文字、なのでアルファベット1文字も漢字1文字も同じ長さという事になる。前述の例で3文字入力してもエラーになったり文字が欠けたりすることはない 訳である。

 私のまわり ではApple(既にAppleの扱いでは無くなってしまったけど)のNewtonがUNICODEを採用している。従って日本語化を行うにあたり、「日本語を表示出来る」のハードルは簡単に越えることが出来た。

 ちなみにもっと深くUNICODEの事を知りたければ、下記のURL から参照することが出来る。

http://www.stonehand.com/unicode.html

●日本語システムへの期待

 日本語を話す日本人の開発者に、UNICODE、とりあえず準備は出来た。後は作るだけ…そうは行かないのが現実。Beも営利団体なので「売れるか?」という問いに明確な答えがなくては上層部、つまり経営サイドは納得 しない。更に日本人の開発者がいるといっても1人で全て、フォント、表示ロジック、果てはインプットメソッドに至るまでを短期間に作れるわけがない。ある程度の分担作業も必要だろうし、それらの摺り合わせも必要だろう。なにぶんにもまだ「動き始めた」ばかりなのである。まして生まれたばかりの会社にとって、経験と実績が蓄積されていない 状態から始めるのである。

 特に日本人にとって「日本語の入力」は大事である。「表示」だけならフォントのバリエーションを増やせば良い訳だが、「入力」ソフトウェアはそうは行かない。現実、私の勤めている会社では全員がメインマシンとしてMacintoshを使用しているが、インプットメソッドに関してはことえりあり、Atokあり、VJEあり、といった状況。ユーザが受ける好みや使い勝手 が、人各々違うのだから始末が悪い。最近のほとんどは「パラメータファイル」というのものでユーザを獲得している。「パラメータファイルを変えれば同じ使い勝手ですよ」という事だ。

 話を戻そう。Be OSでのインプットメソッドは、当然の事ながらUNICODEが使われる。ユーザから見た場合、文字セットにどのコードが使われていようが関係はないだろう。さらに英語圏の人達はこの「インプットメソッド」は必要としない。開発というモノは大変である。

●本当は…

 この原稿を依頼された時、「技術的な事をガンガン書いて下さい」と言われた。