アカウント名:
パスワード:
「8 ビットエンコーデ
少なくとも、
「8 ビットエンコーディング (結合文字や RTL はサポートする意思なし) または UTF-8、従来のマルチバイトエンコーディングは無視」みたいな「国際化」が多くてげんなりしてるので。
スクリプト言語界(?)はそうでもないですよ。Rubyはもちろん、 Pythonだって(Unicode中心とは言え)スクリプトの自身の エンコーディングを明記することで、ISO-8859-xや EUC-JPのスクリプトを認識し、(おそらく一旦Unicodeに 変換してから)動かすような仕組みも考えられています。
#Perl6ではどうなるんでしたっけ?
スクリプト言語は「ちゃちゃっと書いてさくっと実行」というのが 身上なので、「従来のマルチバイトエンコーディング」でも がんがん書けないと意味ない、という気持ちはあるかも。
とはいえ、「文字列の長さ」と「文字列のバイト数」を 区別させることからして、何かと悩ましいわけではありますが……。
その上で、例外を作ればよいかと。 たとえば、スクリプト自身のエンコーディングは、 ワンライナーとかだと、ロケールのエンコーディングに決まってるけど、 システムにインストールしてしまうようなスクリプトだと、 ユーザのロケールに合わせて解釈が変わってしまうのはまずい。 というわけで、自分自身がどんなエンコーディングで書かれているかを 指定する識別子を先頭行 (付近) につけるとか。
ファイル名も、ロケールから独立したものだから、どうするかが問題です。 (これはけっこう難問で、あちこちで繰り返し議論されているようです)。
もちろん、ロケールモードで一時的にバイト列を扱いたいとか、 互換モードで一時的にロケール文字列を扱いたいとか、 ということも、できる必要があります。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
5.8 のときに話題にするべきだったのかも (スコア:2, 興味深い)
「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, 余計なもの)
その上で、例外を作ればよいかと。 たとえば、スクリプト自身のエンコーディングは、 ワンライナーとかだと、ロケールのエンコーディングに決まってるけど、 システムにインストールしてしまうようなスクリプトだと、 ユーザのロケールに合わせて解釈が変わってしまうのはまずい。 というわけで、自分自身がどんなエンコーディングで書かれているかを 指定する識別子を先頭行 (付近) につけるとか。
ファイル名も、ロケールから独立したものだから、どうするかが問題です。 (これはけっこう難問で、あちこちで繰り返し議論されているようです)。
もちろん、ロケールモードで一時的にバイト列を扱いたいとか、 互換モードで一時的にロケール文字列を扱いたいとか、 ということも、できる必要があります。