I’m fighting the weight of the world but ...

mcsがソースを読み込むデフォルトのエンコーディングはLatin1だったのだけど、これはおかしいだろ、ということでシステムロケールから取得するようにした。そしたら、ビルドが出来なくなったという人が続出…。何とutf-8でいくつかのソースがビルドできなかった。みんなLatin1の文字を当たり前のように使っていて、それが拒否られているのである。日本じゃLatin1なんて使わなねーっつの。恐るべし欧米標準。Migたんも「えー、その変更は気に入らねえ」と言うのだけど、codepage 28591に戻すっていうのは筋が通らないので、僕も「戻すのは簡単だけどそれっておかしくね?」と、いつになく突っぱね気味だ。しかしこの調子だと次のリリースを出したらmcsでビルドできなくなったっていうソースが続出だろうな。

そんなわけで仕方なくビルド出来なくなったクラスライブラリのオプションに/codepage:28591を付けて回っていたのだけど、非常に不毛な作業をしている気分で愉快ではない。

ともあれ、これでデフォルトのエンコーディングがロケール依存になったので、VS.NETで作ったShift_JISなASP.NETのアプリケーションが、Mono+Linux環境でそのまま動く…かというと、実はそんなことはない。

多くのディストリビューションでは、GNOMEのデフォルトのエンコーディングがUTF-8になっている¹。だから、Linux上でmcsを動かすと、類似の環境ではどの地域でもutf-8になる。システムロケールからエンコーディングを取得するようにしたからといって、Windowsで開発していたASP.NETアプリケーションが、web.configを変更することなく動作する、ということはないのだ。

むしろ、今日このパッチを適用した後は、これまでデフォルトが28591で、何の障害もなく移植できていた欧米諸国のLatin1ばりばり依存のASP.NETアプリケーションは、上手く動作しなくなるはずで、この辺で混乱が起こることは容易に想定される。これでWebアプリケーションが動かなくなったら僕の修正が原因だとか言われるようになるんだろうなあ。やれやれ。

…ていうか、結局戻してまず議論することになった。やれやれ。

コメント

ladybug — 08/26/2005 10:57:48

「何とutf-8で〜それが拒否られているのである」は、デフォルトエンコーディングが utf-8 でソースコードが Latin1 だから、例えば U+B1 が 0xC2 0xB1 ではなくて 0xF1 で保存されていてコンパイルできねーってことかな？
汚くやるなら utf8/16 は BOM で別認識されることを前提にデフォルトエンコーディングが utf8/16 環境だったら Latin1 とするとか？

atsushieno — 08/26/2005 14:51:13

うーんそれはNG…その回避策ではLANGがja_JP.UTF8な環境でもLatin1になってしまうのです。

ladybug — 08/26/2005 23:31:39

ja_JP.UTF8 のときに Windows との互換性を考慮して ShiftJIS を採用するか、Linux 等の上での使用頻度を考慮して EUCJP を採用するかって問題もありませんか？
そういうこともあって、ja のユーザは欧米のユーザと比べて、utf8 環境において読み込みが Latin1 になっても納得しそうですけどね（苦笑
codeproject からダウンロードしたデモソース等をみてると、ドイツ語(?)と韓国語(?)の人は、結構 utf8 でソースコードを保存していますね。私も手元のコードは、Visual Studio と秀丸と半々ぐらいで書いてて全部 utf8 で保存しています。

atsushieno — 08/27/2005 01:12:20

ええと、euc-jpな環境でソースを書いている人の環境はja_JP.eucJPになるので、Encoding.Defaultもeuc-jpになり、問題は生じないと思います。まあ誰もEncoding.Defaultで行こうという案に反対はしていないので、多分そうなると思いますけどね。TextInfo.ANSICodePageから取るとLinuxでもSJISになってしまったりするので…
ちなみにLatin1がデフォルトだろうとeuc-jpがデフォルトだろうとsjisがデフォルトだろうと、想定外の振る舞いだと思う人は絶対に出てくるので、それなら合理的な振る舞いをした方が良いと思っています。後で設計にケチをつけられるのもしゃくなので(w