2004/12/11配信号／新居雅行

　筆者を中心に開発しているオープンソースのメールソフト「Open Mail Envrionment（OME）」でのローカライズについて、以前にも紹介したが、文字コードの扱いそのものでもイレギュラーなことがあれこれ出てくることなどをご紹介した。今回はまだ手つかずな部分も含めてローカライズについてのはまりポイントをさらに説明をしたい。

　　いろいろな文字コードに対応するというのがメールソフトの宿命であるのは、国際化の上ではすぐに分かることだ。もちろん、Unicodeということへの視野はあったが、少なくとも、やってくるメールについてはUnicodeになることは遠い将来にはあるとしても、近々はないのではないかと予測できる。21世紀を記念して、すべての文字コードがUnicodeになるとかならさておき、各国の固有のコードはなくならない。もっとも、「そろそろ送信するのはUnicodeでいいんじゃないか」説もあるわけで、時代はじわじわと動いているのも事実だ。

　　Mac OS X自体は内部的にはUnicode化は進んでいるとしても、たとえばテキストエディットがUnicodeのテキストファイルを開くときにエラーを出すことがあるなど、まだまだという状況も見られる。少なくとも、日本語システムの使用状況を見る限りは、まだまだアプリケーションがUnicodeを素直に受け入れる状況とは言えないような気がする。アプリケーションのUnicode対応が進んでいるとは言え、いまだに、Shift-JISでテキストファイルを作る方がスムーズなのである。

　　ストレージをテキストであると規定したOMEにおいては、メールの文字コード／文字セットと、保存するメールファイルの文字コード／文字セットも設定が必要になる。もちろん、カスタマイズできるようにはしたが、よく考えると、ある日突然、Shift-JISからUCS-2にしました…といったとき、それはそれで「互換性の問題」が発生しそうでもある。１メール１ファイルは便利なのだが、そういったところでの新たな問題も発生するのだ。

　　そこで結果的に考えたのは、現在のメールファイルがどんな文字セットで保存されてるかをファイルに残すことだ。絶対に100%確実ではないが、メールのヘッダ（本文とは別に送信される一連のメール属性で、件名や送信日などが含まれる）に追加すればいいと考えた。ヘッダ部分に独自の記述を加えて文字セットと処理した言語環境を記録している。とはいえ、これはとても場当たり的な方法であることはまぎれもない。

　　そうなると、XMLでなんでも保存すればいいではないかと言う極端な考え方ももたげるわけだが、XMLになったファイルはプログラムが扱うのはいいとしても、人間が見るものではない。少なくとも、メールはファイルはプレーンでシンプルなテキストファイルである必要があると考えた。

　　組み込むべき機能はたくさんある。どうしても必要な機能はなんとか組み込み、がんばって国際化してきたが、はたと手が止まった部分がある。送信メールの行末処理だ。メールの文面は適当な長さで改行を挿入し、なが～い行はさけるべきだとされている。理屈の上では、1000文字程度までなら1行の長さは可能であり、メールサーバも1000文字程度をめどに処理は正しく動くようになっている。

　　ところが1パラグラフって、以外に1000文字は超えるものだ。1000文字ではなく、100000文字なら、行末処理という仕組みは現状ではもうなくなったかもしれないが、1000だと結局はやらないといけない範囲にぶちあたる上限なのである。RFC的には70バイト程度などとされていてあまり細かい規定はない。もっとも、70バイトでぶつぶつ切っていると、日本語の場合はえらいことになる。ISO-2022-JPだと多くは2バイト文字だから、2バイトが前後の行に分かれて文字にならない。また、エスケープシーケンスの問題もあって「バイト数で行を区切る」というのはプログラム上ではあり得ない話なのである。

　　バイト数で切れない事情はそうした技術的なことだけではない。言語に深く根ざした仕組みをプログラミングしない。日本語だと、当然ながら「禁則処理」という厳然とした仕組みがある。行末に開きカッコがあってはいけないし、行頭に句読点があるのはおかしい。きっと、今みなさんが目にしているデジクリのテキストでも、編集の方がそうしたことを眉にしわを寄せてやっているんじゃないかと思う。メールソフトではそうしたことを自動的にしたいのである。

　　一方、英語は英語で行末処理は独自のルールがある。単語を2行にまたがっては記述しないというルールとも言えるし、2行にまたがるときにはハイフンを入れるが、その入れる場所も音節で決められて適当に切ることは許されない。これはこれで難しい。

　　それで、日本語メールの特徴だが、日本語と英語が混在するのである。日本語の部分は禁則で、英語の部分は、単語を切らないというルールで運用する。この処理は似ているようで微妙に違うのである。しかしながら、条件分岐でなんとかならないこともない。日本語と英語の境目は、半角スペースがあるかように扱えばいいか…などとまだまだその辺りは楽しいプログラミングの領域である。さすがに、音節でのハイフネーションは対応していないが、なんとか動いている。

　　そんなこんなで、ともかく英語まじりの日本語の行末処理はそこそこできたが、国際化というところでどうしてもつまずいた。もし、Unicodeでの文字処理が本格的になったとき、日英混在どころの話ではない。中日韓英混在もありうる。たまたま、日本人は日本語以外では英語がなじみだったこともあって、日英混合テキストが普通になっているだけだ。まあ、この点に関しても、こうした日英の混在がいちおうISO-2022-JPとして規格に乗っているというのがある意味興味深いが、ISO-2022-JPだと、日本語と中国語の混在は仕様にはないのである。（実は、ISO-2022-JP-2がそうした複合言語を切り替えるための仕様ではあるのだが、実際にはほとんど使われている形跡はない。もはやそうした用途ではUnicodeを素直に使うようになっている。）

　　つまり、一連の文字列に対して、行末処理はその一部分の言語に応じて対処しなければならない。そろそろ改行が必要そうだというあたりで、今何語なのかを判別しながら処理をしないといけないのである。そうか、そういう仕組みを入れないといけないのか…。もちろん、そうした仕様の入れ込みはJavaでは比較的やりやすい。

　　しかし、さすがに挫折した。なぜかというと、韓国語や中国語のそうした行末処理について、言語独特の事情を知らないからである。逆に言うと、そういうことでのアドバイスをもらえる人がOMEの中に入ってきてもらえると大変うれしいのであるが、筆者がこれから、中国語や韓国語を勉強して…というのはまず無理だろう。地道にやるぞと思っても、限界がある。ヨーロッパ系言語の微妙な違いや、アラブ系など、言語の多様性は言うまでもないことだ。もちろん、所詮シェアの低いメールソフトだろうと言われればそれまでなのだが、国際化されていないという事実には変わりない。

　　中国語って禁則のような規則はないのでしょうか？　そういう基本的な問いかけからして解決しない。そういえば、ハワイなんかで配られているフリーペーパーって禁則していないと思ってみたらフォントが一部中国語のものだったので、きっと華僑系の印刷会社が作業したんだなと思ったりもするわけだが、そんな生半可な知識ではプログラムはできない。

　　そうした強力な壁があって、国際化はまだまだ道半ばだ。ただ、そこで、チャンスがあれば食い込みたいとも考える。ちなみに、改行の問題は送信だけだったが、今ではフローレイアウトという仕組みで、「勝手に改行したものを元に戻す」みたいな枠組みが浸透し始めている。送信だけではなく、受信というかメールを参照するという場面でも「改行問題」は発生しそうである。

　　コンポーネント化というのは、何かあったときに１から作らないで済むということを実現したいからということもある。ともかく、組み込みは無理でも組み込める仕組みを作るというところがポイントになるだろう。そこをしっかりと作っておきたいところなのである。

　 【にい・まさゆき】msyk@msyk.net

　トレーナー、コンサルタント、デベロッパー、そしてライターと、あれこれこなすフリーランス。アップル公認トレーナーになることができた。一方、FileMaker Server 7 Advancedに絡む仕事もあれこれ発生しているというのが身辺の近況だ。