Revolution1.x は多バイト言語に対応していません。日本語を使うと思わぬトラブルに合うことがあります。ここでは 1.x の代表的な症例と対処法、そして Unicode 対応を謳う Revolution 2.x の情報を書いてみました。

　−−−−

なぜラップ（自動改行）しないのか

　フィールドの Don't Wrap プロパティを false にしても、フィールド内の日本語が自動改行してくれません。内部でどういう処理がされているのか分かりませんが、要は文字の区切りを適切に判断出来ないのと、ASCII 128 以上の文字コードが含まれていることが原因でしょう。

　苦し紛れの対処法として、フィールドの幅で強制改行するスクリプトを作ってみました。マックとＷｉｎ９５で動作確認してあります。 http://homepage.mac.com/udi/temp/jWrap10.rev.hqx（ 27KB non-compressed ）


なぜ Windows に（または Mac に）持っていくと化けるのか

　Windows と Mac の文字コードは微妙に異なっています。日本語でもいわゆる機種依存文字が問題になることがありますが、実は半角英数にも細かな差異があります。 RunRev はこの違いを吸収するために、Mac で作ったスタックを Windows で開く時に、或いは Windows で作ったスタックを Mac で開く時に、そのスタック内の文字コードを自動的に変換します。（そのため、別の OS 上で作られたスタックを開くときは、少し時間がかかります）

　問題は、この自動変換エンジンが、半角英数しか考慮されていないことです。元々 S-JIS の文字コードは Mac と Windows でほぼ共通であり、ほとんど無変換で共有することが出来ます。しかし RunRev には半角英数の変換ルールしか実装されておらず、本来変換する必要のない日本語文字列を書き換えて、別の OS 上で作られたスタックの日本語を壊してしまうのです。

　自動変換の対象になるのは、フィールド内の文字列と、各プロパティ（スクリプトも含む！）内の文字列です。カスタムプロパティはバイナリデータを入れることがあるため、自動変換の対象にはなっていません。ここが狙い目です。スタック内に日本語の文字列を入れたい時は、文字列をカスタムプロパティに保存するようにします。そしてスタックを（或いはカードを）開くときに、カスタムプロパティの文字列をフィールドに書き出すようスクリプトを書きます。これで複数の OS で「全く同一の」文字列データを共有することが出来ます。更に上記のラップ処理をすれば、1.x でも日本語の「表示」だけは出来るようになります。


なぜ 1.x は日本語がうまく使えないのか

　殆どの開発環境やアプリケーションは、OS の文字入力／編集サービスを利用しています。そのため英語版のアプリケーションであっても、多くはそのまま日本語が使えてしまいます。しかし RunRev はマルチプラットホームに対応するために、テキスト入力や編集に OS の機能を使わず、自前のエンジンを用意しています。つまり OS が日本語に対応していても、RunRev の編集エンジンが日本語に対応しない限り、日本語が使えるようにはならないのです。

　2.x は Unicode 対応を謳っています。これによって、日本語の問題は解決されるはずです。


Revolution2.x の Unicode 対応とは

　2.0 の目玉は Unicode 対応です。つまり半角英数以外の文字コードを正式サポートするわけです。現在ベータ版が公開されていますが、2.0 のリリースも近いようです。（当初の予定の半年遅れ！）

　ベータ版では、フィールドへの日本語入力と、フィールド上での日本語編集が可能になっています。（やっとまともに文字選択が出来るようになりました）　ラップ処理もうまく行っているようです。フィールド上の文字列に文字コードプロパティ（のようなもの）が追加されました。フィールドやスクリプトに入力された文字列は（デフォルトでは）全て Unicode になります。

　いくつか問題点も見えてきています。まず、一部の IM で日本語変換に問題が残っているようです。これは 2.1 以降でフィックスされるということですが、時間がかかるかも知れません。また最終的な仕様はまだ分かりませんが、日本語環境で Unicode を指定すると、フォントが OSAKA に固定されてしまいます。テキストメニューからフォントを変えると Unicode 属性が外れてバケ文字になってしまうのも困りもの。スクリプトから日本語を扱う方法もまだ確立されていないようで、line 指定子が正しく働きません。ポップアップメニューなども未実装っぽいところが見られます。ダブルクリックで単語を選択することも出来ません。日本語を安心して使えるようになるのは、恐らく 2.1 か 2.2 からでしょうね。


S-JIS はどうなるのか

　ウェブ上の文書を始めとして、S-JIS の資産は膨大です。 Unicode をサポートすることによって日本語の入力／表示の問題はクリア出来るとしても、やはり S-JIS は避けて通れません。

　RunRev には uniEncode という関数があり、1.x では半角英数を対象とした簡単な変換操作をすることが出来ました。この関数に日本語を渡しても無意味な変換がなされるだけでしたが、2.x ではこれが拡張されました。 uniEncode 関数に文字コードを指定することによって、S-JIS の文字列を Unicode に変換することが出来ます。この文字列をフィールドに入れれば、（間接的にではあるが） S-JIS を扱えるようになるわけです。

　しかし事はそう簡単ではありません。問題は、例えばローカルディスクにある文書を読もうとした時に、それが Unicode によって書かれているのか、それとも S-JIS によって書かれたものか、調べる方法が無いことです。これは RunRev の問題と言うより文字コードシステムの問題ですが、少々やっかいです。各コードの傾向を整理して半自動の判別ルーチンを書くことも可能ですが、最終的には「スタックを使うユーザーに」判断させる（文字コードを指定するボタンやメニューを付けて、ユーザーに選択させる）しか無いかも知れません。幸い HTML 文書は文字コードが指定されているものが多いので対応が可能でしょうが、文字コード指定の無い HTML 文書は（ブラウザの多くがそうであるように）やはりユーザーに文字コードを指定してもらうしかありません。


2.x に期待する

　ベータ版にはいくつもの不具合がありますが、正式な最終仕様が発表されていないために、それが単なるバグなのか、仕様なのか、それとも未実装なだけなのか、なかなか判断が付きません。何にせよ前途は多難であります。マルチプラットホームのマルチ言語はあまりに複雑で、どういう仕様が理想的なのかさえ私には分かりません。全ての元凶は Unicode の仕様だったりするかも知れない。がんばれ負けるな Revolution。


2003.05.14
ＵＤＩ