アカウント名:
パスワード:
「8 ビットエンコーディング (結合文字や RTL はサポートする意思なし) または UTF-8、従来のマルチバイトエンコーディングは無視」みたいな 「国際化」が多くてげんなりしてるので。
(というか、現実はもっとひどくて、「国際化」とは翻訳のことだと 思っている人が多いみたい)
少なくとも、
「8 ビットエンコーディング (結合文字や RTL はサポートする意思なし) または UTF-8、従来のマルチバイトエンコーディングは無視」みたいな「国際化」が多くてげんなりしてるので。
スクリプト言語界(?)はそうでもないですよ。Rubyはもちろん、 Pythonだって(Unicode中心とは言え)スクリプトの自身の エンコーディングを明記することで、ISO-8859-xや EUC-JPのスクリプトを認識し、(おそらく一旦Unicodeに 変換してから)動かすような仕組みも考えられています。
#Perl6ではどうなるんでしたっけ?
スクリプト言語は「ちゃちゃっと書いてさくっと実行」というのが 身上なので、「従来のマルチバイトエンコーディング」でも がんがん書けないと意味ない、という気持ちはあるかも。
とはいえ、「文字列の長さ」と「文字列のバイト数」を 区別させることからして、何かと悩ましいわけではありますが……。
その上で、例外を作ればよいかと。 たとえば、スクリプト自身のエンコーディングは、 ワンライナーとかだと、ロケールのエンコーディングに決まってるけど、 システムにインストールしてしまうようなスクリプトだと、 ユーザのロケールに合わせて解釈が変わってしまうのはまずい。 というわけで、自分自身がどんなエンコーディングで書かれているかを 指定する識別子を先頭行 (付近) につけるとか。
ファイル名も、ロケールから独立したものだから、どうするかが問題です。 (これはけっこう難問で、あちこちで繰り返し議論されているようです)。
もちろん、ロケールモードで一時的にバイト列を扱いたいとか、 互換モードで一時的にロケール文字列を扱いたいとか、 ということも、できる必要があります。
昔はJEという名前でMuleなどがまとめられていましたね。
jperlというのもあったけれど、今はもういらないものなのだろうか...
そもそも perl って翻訳用カタログすら作れなかったな…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
5.8 のときに話題にするべきだったのかも (スコア:2, 興味深い)
「8 ビットエンコーディング (結合文字や RTL はサポートする意思なし) または UTF-8、従来のマルチバイトエンコーディングは無視」みたいな 「国際化」が多くてげんなりしてるので。
(というか、現実はもっとひどくて、「国際化」とは翻訳のことだと 思っている人が多いみたい)
Re:5.8 のときに話題にするべきだったのかも (スコア:2, 参考になる)
少なくとも、
スクリプト言語界(?)はそうでもないですよ。Rubyはもちろん、 Pythonだって(Unicode中心とは言え)スクリプトの自身の エンコーディングを明記することで、ISO-8859-xや EUC-JPのスクリプトを認識し、(おそらく一旦Unicodeに 変換してから)動かすような仕組みも考えられています。
#Perl6ではどうなるんでしたっけ?
スクリプト言語は「ちゃちゃっと書いてさくっと実行」というのが 身上なので、「従来のマルチバイトエンコーディング」でも がんがん書けないと意味ない、という気持ちはあるかも。
とはいえ、「文字列の長さ」と「文字列のバイト数」を 区別させることからして、何かと悩ましいわけではありますが……。
Re:5.8 のときに話題にするべきだったのかも (スコア:1)
Perlのメインのひとつ、CGIだと入力エンコーディングがね。
NN4.いくつかで、Content-TypeのcharsetもMETAもくっつけて、こっち(CGI)から丁寧にエンコードした送信ページを作ってやっても、そこから送られてくるエンコードが(再判定しないと)確定できないの。(ユーザー設定が優先するんだっけな?詳細忘れた)
そーゆーブラウザがあるだけでもLOCALE一発てのは難しいでしょうね。
#しかもなぜか固執するファンが多いんだよね、NN4。
Re:5.8 のときに話題にするべきだったのかも (スコア:1, 余計なもの)
その上で、例外を作ればよいかと。 たとえば、スクリプト自身のエンコーディングは、 ワンライナーとかだと、ロケールのエンコーディングに決まってるけど、 システムにインストールしてしまうようなスクリプトだと、 ユーザのロケールに合わせて解釈が変わってしまうのはまずい。 というわけで、自分自身がどんなエンコーディングで書かれているかを 指定する識別子を先頭行 (付近) につけるとか。
ファイル名も、ロケールから独立したものだから、どうするかが問題です。 (これはけっこう難問で、あちこちで繰り返し議論されているようです)。
もちろん、ロケールモードで一時的にバイト列を扱いたいとか、 互換モードで一時的にロケール文字列を扱いたいとか、 ということも、できる必要があります。
Re:5.8 のときに話題にするべきだったのかも (スコア:2, 参考になる)
まだ libc5 が幅をきかせていたころ、「Linux 環境を日本語化する」
というタイトルの Web ページがあったので、
「どんなすごいことをしてるのかなわくわく」
と思って見てみたら、jless と jgroff と kterm その他を
インストールする方法が書いてあっただけの罠。
今わりと困るのは、むしろ「国際化すれば地域化が不要だと思ってる手合い」かも。
Re:5.8 のときに話題にするべきだったのかも (スコア:1)
昔はJEという名前でMuleなどがまとめられていましたね。
jperlというのもあったけれど、今はもういらないものなのだろうか...
Re:5.8 のときに話題にするべきだったのかも (スコア:1)
1. LC_CTYPE ロケールだとネットワークでは役に立たない
2. 文字列リソース一つ一つのエンコーディングをプログラマが管理したくない
3. 特定のエンコーディングに依存しない汎用文字列ライブラリの作成は困難
この3点じゃないか?
1. 2. に関しては、ファイルハンドルなんかの、
外部に直接繋がってるリソースに対してのみエンコーディングを管理すれば解決できそうだ。
たしか以前の Apocalypse でファイルハンドルにいろいろ設定できるようなことが書いてあったし。
内部に入ってくるデータはすべてロケールで指定されたエンコーディングになるから、
あとはワイド文字列にしちゃう(mbstowcsはロケール依存なので問題なし)、
でライブラリレベルでは全部 wcs を使えば 3. も解決?
これだと問題は文字数 != 文字列の長さ、ってあたりでえらく問題が出そうだが…
そこはプログラマの問題なんだろうな。
> 「国際化」とは翻訳のことだと思っている人が多いみたい
そもそも perl って翻訳用カタログすら作れなかったな…
# mishimaは本田透先生を熱烈に応援しています
Re:5.8 のときに話題にするべきだったのかも (スコア:1)
国際化 == 英語以外禁止 (スコア:1)
某県立大学の人が、「うちは国際化を目指しているので、入学式も卒業式も全部英語でやっています」と自慢していました。ソフトウェア業界の外で「国際化」って言うと、日本語(現地語)を使わずにすべて英語だけで済ませることを意味するようですね。