プログラム中で自由に日本語リテラルが使え、Converterも、ユーザの目から直接は 見えなくなったということは、ある意味では、日本語のことをあれこれ意識する必要が ほとんどなくなったということです。Javaのプログラム中の、Stringないしはcharは、 英語でも日本語でも、あるいはそれらを混在させても、コンパイラがきちんと Javaの内部コードに解釈してくれます。
多少、注意しなければいけないのは、入出力を通じて日本語を利用しようとする時に は、従来のInputStream/OutputStreamの系列ではなく、新設されたReader/Writerの 系列を使うようにしなければいけないということです。Reader/Writerクラスは、通常は システムに応じたデフォールトのConverterとセットなので、「Reader/Writerを使う」 だけで、日本語とJavaの内部コードへの変換は、自動的に保証されます。
たとえば、僕がNTでJavaのプログラムを開発していて、あるボタンに"ファイル” という日本語のラベルをつけたとしましょう。コンパイルされたクラス・ファイルを 今度は、UNIXマシンに持ってきて、そこで実行しても、ちゃんと、ボタンには "ファイル"という日本語ラベルが現れます。もちろん、逆に、UNIXでコンパイルした ものをPCに持っていっても、ボタンのラベルはきちんと同じ日本語が現れます。 Javaのクラス・ファイルのレベルでは、プラットフォームに依存しない日本語の利用が ある意味では可能です。 これは、いかにもJavaならではの芸当です。
PCでもUNIXでも同じ日本語利用が可能なクラスが存在することは先に述べたとうりです。 ところが、その単一のクラスを生成するソース・ファイルは、エンコードの種類だけ 存在する可能性があります。SJISで"ファイル"と書かれたPC上のソース・ファイルと、 EUCで"ファイル"と書かれたUNIX上のファイルは、明らかに異なるファイルです。 プラットフォームに依存しない日本語プログラムは可能なのですが、そのソース ファイルは、プラットホームに依存するというややこしい事になります。
プログラムの外部のデータ・ファイルの場合は、ますます面倒です。 一つのプラットフォームの上でだけ仕事をする閉じた世界なら、データ・ファイルも defaultのencodingを使っていると仮定すれば、JDK1.1のモデルは、かなり うまく機能することが期待できます。しかし、インターネットの発達は、 多数のコードが飛び交う、一見混乱した、全くオープンな世界を、我々の眼前に 出現させました。
JDK1.1の国際化/日本語対応のポイントは、いうまでもなく、Unicodeを採用した事に あるのですが、今回は、「内部コードとしてのUnicodeの採用」という面を中心に、 出来るだけ中立的な立場で、基本的な部分の説明をしてきました。 最後に、この問題での僕の考えを、いいたいことが沢山あるのですが、簡単に 述べてみたいと思います。
JDK1.1では、Unicodeは、「内部コード」と、「charを表す唯一のコード」 という二重の意味を持っています。Java が「内部コード」を持つことに、 効率の問題を除けば、特に異論があるわけではありません。Sunが、process codeと いう内部コードを使っていることを知っている人も多いでしょうし、Xでプログラム 経験のある人は、multi-byte 文字と wide-character文字の区別を知っている でしょう。問題は、JDK1.1が、Unicodeを単なるJava の「内部コード」と考えて いるのか、Java の外でも、「charを表す唯一のコード」として推賞されるべきべきと 考えているのかが、明確でないことです。そもそも、Unicodeは、その名が示すように、 様々のコード体系を「統一」した、「唯一のコード」体系として構想されたものです。 僕が、危倶しているのは、どうも JDK1.1 の製作者達が、Java の「内部コード」に とどまらず、OSのレベルでも、Unicodeを採用すれば、国際化/各国語化の問題が一挙に 解決すると安易に考えている節があることです。 あるいは、先にみたgetConverter("SJIS")の例が示しているのは、日本の外では、 JIS系の日本語コードとASCIIコードの共通部分が、ASCIIコードであることさえ 知らない人が多いということかもしれません。
Unicodeの採用が、Java の言語仕様の中に、事実上、自然言語のエンコードの仕様を 含めることにつながるのなら、それには、僕は賛成できません。もっと、いろいろな やり方が、Java なら可能だと思います。
少し前には、世界はもう少し単純でした。インターネット上には英語の情報しか ありませんでした。日本語の情報を発信するのは簡単でしたが、日本語が使える browserはありませんでした。今、我々は、WWWサーバがSJISを話すのかEUCを 話すのかを自動的に判別するbrowserを当たり前のように使っていますが、 これは、なかなか日本的なテクノロジーだと僕は考えています。こうしたやりかたを 少し進めて行けば、Unicodeを使わなくても、プラットフォームに依存しない ソースのエディタが出来る訳です。
JDKの日本語対応とは離れますが、世界の諸言語の多様さは、情報化の妨げになるので しょうか？ コードの多様さは、言語の多様さの反映に他なりません。 コードの多様さが情報の流通を妨げているのではなく、基本的には、言語の 多様さが情報の流通を妨げているのです。
これに対する一つの答えは、いうまでもなく、「同じ言葉を使えば良い」 というものです。これにも、「自分と同じ言葉を相手が使えばいい」といった 身勝手なものから、「相手の言葉を自分も理解しよう」というもの、あるいは、 エスペラントのように、第三の言語を作ろうと言うものまで、様々のバリエーション があります。
もう一つの考えは、「言語の多様さが情報化の妨げになる」と考えるのではなく、 「情報化が、多様な言語のままでも、情報の流通を促進する」と考えることです。 「タケコプター」や「どこでもドア」は、実現しそうもありませんが、 「翻訳コンニャク」なら、僕が生きているうちに実現しそうな気がします。