Latinization != Internationalization

Latinization != Internationalization

商用は比較的まともですが、一般的にオープンソース系のものは、初期段階の開発者がアメリカあるいはヨーロッパに多いので、マルチバイト対応がうまく行きません。まあ、最初は「English」次に「German / Spanish / Italian / French etc.」と来るのが殆どでしょう。その際、「English-Oriented」から「Latinization」の過程で、必ず「ウムラウト(Umlaut – e.g. ü)」を含めた若干の「例外文字(Anomaly / Exception)」が問題となります。

例外文字は、一般的にus-asciiでは表示出来ません。よって、iso-8859-1 (や -2)などをセットする事で回避/対応するケースが殆どです。若干、「UTF-8」というものの存在を聞いた事のあるエンジニアは、何とか * 頑張って * 「UTF-8」を使おうとすると思いますが、諦めるケースが多分殆どでしょう。何故なら、彼らは「Latin 系 で正しい」記号(というか例外文字)は認知出来ても、私たちが使っている日本語などのような「例外が何百万文字もある」文化には対応出来ない – Struggling against invisible entities – からです(人間、認知できないものはすべて<同じ>と判断する傾向が強い — 君はアラビア語(Arabic)の「エクリチュールと差異(L’Ecriture et la difference)」を味わうことが出来るかっ!? 🙂 )。従って、「iso-8859-1」で部分最適化します。

本来、これは「ナチュラルな」過程とも言えますが、us-ascii文化をそのまま「UTF-8 化」するより、実は「Latinization」の過程が入っていた方が厄介であったりします。何故なら、「iso-8859-1」で最適化された部分を UTF-8 化 すると、必ず「文字化け」が起こるからです。よって(解決策をご存知ではないので)、rewind されます。

まあ、多分なんですが、「& u u m l ;」といったニーモニックとか(例えば)をヨーロッパ人が若干「覚えて」くれてその状態で部分最適化されている事が、一番の解決策であったりします … まあ、UTF表記(\u***)も然り。高々自分にとって必要な4-5個とかの例外を覚えるのってそんなに難しいのかな? — というのはプリミティブで素朴な「疑問」ではあったりしますが — 一般的にこれらの問題に適切に処理できないヨーロッパ系エンジニアが多いのはコンピュータ社会の悲劇の一つかもしれません。更に言えば、「変換テーブル」なんて100レコードも入らないと思いますので、それらをデフォルトで入れておく([F5] を押したら相互変換するとか。:-) … といった裏技もあるとGood)ようなシステムにしておけば良いわけで … Latinizationの共通モジュール(将来的な拡張が容易となる為のモジュールであって、部分最適させるためのものではなく)が無いのは問題。日本語の場合は<完全に>諦めざるを得ないので例えばjcode.plとか … そういうのを開発せざるを得なかったとは思いますが。「若干の差異」なので「力技」に任せてマトモに Latinization を考えてこなかったことが問題の根本にあるのではないでしょうか。また、「Latinization = Internationalization」と「勘違い」しているケースが多いのが、多分問題を(今まで)ややこしくしてきた根本の一つにあるのではないでしょうか。

ともあれ、 http://nagoya.apache.org/eyebrowse/ の文字化け(\uXXX の為の “native2ascii” を施すとかそういうたわいもないレベルだったりはしましたが、それを伝えるのに相当苦労してしもうた … garbled garbled)を修正するのに相当な手間がかかり、その時に「諦め」に似た感覚を有してしまったので….まだまだ真の国際化には程遠いような気はします。

追伸:逆に言えば、ラテン系のみで部分最適化しないように、システムで「禁止」をかければ、意外に国際化は早く進むかもしれません。逆説的ですが….. あと、更に言えば、「ü, é等一部の<例外>を & u u m l ; , & e a c u t e ; 等々に直す」smart なツールを 日本人・韓国人・中国人とかが開発して、それを「英語で紹介」してあげると良いのかもしれません。私はいつも(&#XXXXX 系の日本語変換を含め)「FrontPage」を使いますが(笑)みんな持ってるわけではないですからネ — PHP等に適切な関数あったりして密かにワンライナー(one liner)で処理出来たりしますが。

WindowsでUNIX環境を! — Cygwin on Windows

http://www.terra-intl.com/unix.html

これを書いて本当に久しい … です。 – Lovely Bubbly (^_^) な 2000年かその1年前くらいに書いて、ずっとほっぽっといてたものでありますが…. (こんなのを入れてるから「会社のホームページらしくない」んだろうなあ、と思いつつ。ま、会社も所詮「実験場」だったりするので)
書いた当時、なんとなく「パーティションマジック(Partition Magic)を使うのが面倒だ!!」とかそのレベルでCygwinというものの存在を掘り当てて、一生懸命インストールした時(更に言えば、PostgreSQLをなんとしてでもWindows上で動かしたかった!!)のメモだったりします。
今は、VMWareといった仮想マシンツールがあるので(うう、こういった所で必要以上にお金を使って「実験」しようとする性格なのでお金がたまらず赤っぽくなる…)、Cygwinなどはもう必要なかったりはしますが、自分自身がLinux/Unix系のコマンドに慣れてきってしまってたりするので、MS-DOSのプロンプトでたまに「ls !」とかやっちゃってもエラーを出してくれないので(path が設定されてれば、の話ですが)重宝したりはします。:-)
….逆に言うと、「Windowsで」「Unix系コマンドを」というタイトルだったほうがよかったかもしれない …

数年前(といっても、もう8年近く前になります)は、BSD on Windows (BOW) というソフトも使いましたが、どうも使い勝手がよいようには思えず、また、メモリを多量に使うため、BOWを立ち上げるだけでWindows(当時は95)がフリーズする現象が起き、実際にはあまり使えませんでした。 ・・・当時の事を思うと、本当に隔世の感がありますネ。

尚、Cygwinのフルリリースには以下のパッケージが含まれてます。

・開発ツール: binutils, bison, byacc, dejagnu, diff, expect, flex, gas, gcc, gdb, itcl, ld, libstdc++, make, patch, tcl, tix, tk

・ユーザツール: ash, bash, bzip2, diff, fileutils, findutils, gawk, grep, gzip, m4, sed, shellutils, tar, textutils, time