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になっている*1。だから、Linux上でmcsを動かすと、類似の環境ではどの地域でもutf-8になる。システムロケールからエンコーディングを取得するようにしたからといって、Windowsで開発していたASP.NETアプリケーションが、web.configを変更することなく動作する、ということはないのだ。
むしろ、今日このパッチを適用した後は、これまでデフォルトが28591で、何の障害もなく移植できていた欧米諸国のLatin1ばりばり依存のASP.NETアプリケーションは、上手く動作しなくなるはずで、この辺で混乱が起こることは容易に想定される。これでWebアプリケーションが動かなくなったら僕の修正が原因だとか言われるようになるんだろうなあ。やれやれ。
…ていうか、結局戻してまず議論することになった。やれやれ。
