正確には「多言語化」(m17n)というよりは「複数文字コード対応」(語呂が悪い(^^;)というべきか。「国際化」(i18n)と「地域化」(l10n)はここでは扱わない。
通常のプログラミング言語は文字データ型がひとつしかなくそのひとつの文字データ型の中で複数の文字コードをやりくりしている。それはオブジェクト指向言語でも大差がない。でも、せっかくオブジェクト指向言語を使うのならもっとスマートにできるんじゃないだろうか。
ひとつのアプローチとして文字コードごとにサブクラス化してみることを考えてみる。例えば、基本文字列クラスがあり、そのサブクラスとして ShiftJIS 文字列クラス、EUC-JP 文字列クラス、ISO-2022JP 文字列クラス、UTF-16 文字列クラスなどが存在する。それぞれのクラスで定義されているメソッドが文字列操作をよきにはからってくれるので文字コードを意識せずにプログラムを記述できるというわけである。
この方法では内部コードに変換するということはしない。できるかぎりオリジナルの文字コードをそのまま扱う。これには大きな理由は2つある。1つは文字コードの変換に必要な計算コストの削減で、もう1つは文字コード変換にともなうデータの変質(*1)の回避である。
そうは言ってもどうしても文字コードの変換が必要な場合がある。例えば文字列の連結であるがこういうルールはどうだろう。
// 同じ言語の場合、一番最初の文字コードに変換
ShiftJIS ← ShiftJIS + EUC-JP + ISO-2022JP
// 違う言語の場合、全てを表現できる UNICODE に変換
UTF-16 ← ShiftJIS + Big5(中国語、繁体字) + EUC-KR(韓国語)
// 明示的に文字コードを変換
ISO-2022JP ← “ShiftJIS”.to_s(ISO-2022JP)
プログラミング言語の言語デザインとしてはあらかじめ多言語で使われることを考慮して、文字コードごとのサブクラス化と実装をルール付けしておく必要があるだろう。各文字コードごとにサブクラスで文字列処理のメソッドを記述するのは少し面倒かもしれないが、すべてを記述する必要はなくとりあえず必要な文字コードだけでいいだろう。あとは決められたルールに従って拡張ライブラリで追加していけばいいわけである。実際のエンコーディングには nkf や iconv を使用するかもしれないが、それは縁の下の力持ちでどういうライブラリを使っているかは一般プログラマの目からは隠蔽される。
個人的にはかなりスマートだと思うのだがどうだろう(^^)?
本当は NEWT/0 で採用しようと思っているのだけど、NewtonScript ではクラスはないし文字列でメソッドは使えないのでクラスライクな機能とラッパーオブジェクト(*2)の機能を拡張する必要があると考えている。(*3)
*1) 例えば ShiftJIS の半角 ‘¥’ は UTF-16 の ‘\’ と ‘¥’ のどちらに変換すべきか。ShiftJIS の ‘¥’ は円マークとエスケープ文字の2つの意味をもっているが UNICODE ではどちらか1つにしかなれない
*2) JavaScript ではオブジェクトでない基本データ型でメソッドを使うためにラッパーオブジェクトというものを使用している
*3) 構想ばかりでなくちゃんと実装しなきゃだめだな(^^;
Tags: NewtonScript
UTF-8もお仲間に入れて欲しいです。
(同じ言語の場合、一番最初の文字コードに変換)
では組合せが多くなるのでUTF-16へ統一したほうが楽ではないでしょうか。
あるいは結果を文字列の集まりとして取り扱えないでしょうか。
(ShiftJIS , EUC-JP , ISO-2022JP)
コード変換をしない代わりに文字操作でオーバーヘッドが大きくなりそうですが。
もちろん UTF-8 もお仲間です(笑)
文字コードの変換は UTF-16 に統一したほうが楽なのですが、ShiftJIS をメインに使っていてときどき EUC-JP や ISO-2022JP を使うというケースも考えられます。組み合わせが多くなる問題は直接変換可能な文字コードのみ変換し、そうでないものは UTF-16 にしちゃえばいいかなと思ってます。
文字列の集まりは面白いアイデアですね。ちょっと思うところがあるのでこれは別記事で書込みます。
これって、結局のところCSI(Code Set Independence)方式ですよね。
これといった文献は知らないのでURLは出せませんが、「CSI 国際化」でぐぐると色々とでてきます。
「CSI 国際化」ぐぐってみました。なるほど確かに CSI 路線ですね。