アカウント名:
パスワード:
「404 Not Found [livedoor.jp] 」にはモダン Perl の書き方やモダン Perl の良書紹介エントリがたくさんあるので、まずはここを見るのが筋だと思う。
# dankogai の Perl 至上主義は老害と言ってもいいと思うので AC
404 Blog Not Found : perl - use encoding; #は黒歴史 [livedoor.jp]
10年ぐらい前にPerlに触ったとき、Shift_JISの第2バイトが"\x5C"だとバックスラッシュに解釈されてしまうというのを知ったんだけど、未だにそうなんですね。RubyやPythonみたいにスクリプトのエンコーディングを指定可能にするのじゃなく、「UTF-8以外使うな」とするのがPerl流のモダンなのか……。それ、モダンじゃなくて単なる「手抜き」じゃないのかな？
ちゃんと読みなさいなエンコーディング指定も出来るけれど、UTF-8で書いた方が問題は少ないって話ですよRubyだってShift_JISで書けば、UTF-8では発生しない問題が起きるでしょう？
そもそもShift_JISがモダンなエンコーディングとは言えないんだから仕方ないUTF-8は、少なくともShift_JISよりはモダンなはずだ
なんて乱暴な……。RubyもPythonも、スクリプトの頭で
# coding: Shift_JIS
と宣言しておけば、ソースがShift_JISで書かれているとインタプリタが解釈するんですよ。指定しておけば、"表"の第2バイトがバックスラッシュとみなされることなんてありえません。デフォルトエンコーディング（RubyとPython2.xはUS-ASCII、Python3.0はUTF-8だったかな）以外のエンコーディングでスクリプトが記述可能という仕組みが、インタプリタに実装されているんです。
ライブラリの対応状況とか文字列の処理上の問題はこの際関係ないです。エンコーディングの優劣も的外れ。何を言っているのやら。
Rubyはシェバングに-Kオプション
#! /usr/local/bin/ruby -Ks
Pythonはシェバングの次の行辺りで
# -*- coding: shift-jis -*-
Windowsなら
# -*- coding: cp932 -*-
Perlはライブラリの読み込みの所辺りで
use encoding qw(Shift_JIS);use open qw(:encoding(Shift_JIS) :std);
use encoding qw(cp932);use open qw(:encoding(cp932) :std);
PHPは……6からICUが搭載されますので、それまでお待ちください。
だいたい、こんな感じかな。
ruby の引数での指定方法では、ライブラリのキャラクタセットをどうするんだろう。
python の場合はソースごとに個別の指定が出来るので、モジュールA を UTF-8、モジュールB を EUC-JP、自分のソースを Shift-JIS でコーディング出来るんだよね。
ruby に戻ると、複数のモジュールのキャラクタセットを合わせないと駄目だと思うんだけど、それって UTF-8 縛りを求めてる perl とどこが違うの?と思う。
親コメントにある、引数やshebangでのエンコーディング指定（-Ks, -Kuなど）は古い方法です。
1.9系のRubyではPython同様にマジックコメントによる指定方式がサポートされています。
参考 http://doc.loveruby.net/refm/api/view/spec/m17n#script_encoding [loveruby.net]
use stirct;use warnings;use utf8;binmode STDOUT => ':utf8';
use utf8;binmode STDOUT => ':encoding(cp932)';
例えば、UTF-16で書いたときも同じようにすれば解釈してくれるの？
Perlだってencoding指定すれば、"表"がバックスラッシュになるなんて事ありませんよ。インタプリンタがそう解釈してくれるんだから
小飼さんのBlogで言及してるのはまさに> ライブラリの対応状況とか文字列の処理上の問題だと思いますが……
なるほど、勘違いの理由が分かりました。件のエントリでは、あえて encoding を指定しない場合の話なわけですが(SJIS指定が出来るのは既知なので分かりやすく言及はしてませんね)それを見て、未だに "表" がバックスラッシュに解釈されてしまうと思ったんですね？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
dankogai のブログを読む (スコア:1, 興味深い)
「404 Not Found [livedoor.jp] 」にはモダン Perl の書き方やモダン Perl の良書紹介エントリがたくさんあるので、まずはここを見るのが筋だと思う。
# dankogai の Perl 至上主義は老害と言ってもいいと思うので AC
Re: (スコア:0)
404 Blog Not Found : perl - use encoding; #は黒歴史 [livedoor.jp]
10年ぐらい前にPerlに触ったとき、Shift_JISの第2バイトが"\x5C"だとバックスラッシュに解釈されてしまうというのを知ったんだけど、未だにそうなんですね。
RubyやPythonみたいにスクリプトのエンコーディングを指定可能にするのじゃなく、「UTF-8以外使うな」とするのがPerl流のモダンなのか……。
それ、モダンじゃなくて単なる「手抜き」じゃないのかな？
Re: (スコア:0)
ちゃんと読みなさいな
エンコーディング指定も出来るけれど、UTF-8で書いた方が問題は少ないって話ですよ
RubyだってShift_JISで書けば、UTF-8では発生しない問題が起きるでしょう？
そもそもShift_JISがモダンなエンコーディングとは言えないんだから仕方ない
UTF-8は、少なくともShift_JISよりはモダンなはずだ
Re:dankogai のブログを読む (スコア:0)
なんて乱暴な……。
RubyもPythonも、スクリプトの頭で
と宣言しておけば、ソースがShift_JISで書かれているとインタプリタが解釈するんですよ。
指定しておけば、"表"の第2バイトがバックスラッシュとみなされることなんてありえません。
デフォルトエンコーディング（RubyとPython2.xはUS-ASCII、Python3.0はUTF-8だったかな）以外のエンコーディングでスクリプトが記述可能という仕組みが、インタプリタに実装されているんです。
ライブラリの対応状況とか文字列の処理上の問題はこの際関係ないです。
エンコーディングの優劣も的外れ。何を言っているのやら。
各LLの日本語対応 (スコア:2, 参考になる)
Rubyはシェバングに-Kオプション
Pythonはシェバングの次の行辺りで
Windowsなら
Perlはライブラリの読み込みの所辺りで
Windowsなら
PHPは……6からICUが搭載されますので、それまでお待ちください。
だいたい、こんな感じかな。
Re:各LLの日本語対応 (スコア:1, すばらしい洞察)
ruby の引数での指定方法では、ライブラリのキャラクタセットをどうするんだろう。
python の場合はソースごとに個別の指定が出来るので、モジュールA を UTF-8、モジュールB を EUC-JP、自分のソースを Shift-JIS でコーディング出来るんだよね。
ruby に戻ると、複数のモジュールのキャラクタセットを合わせないと駄目だと思うんだけど、それって UTF-8 縛りを求めてる perl とどこが違うの?と思う。
Re:各LLの日本語対応 (スコア:2, 参考になる)
親コメントにある、引数やshebangでのエンコーディング指定（-Ks, -Kuなど）は古い方法です。
1.9系のRubyではPython同様にマジックコメントによる指定方式がサポートされています。
参考 http://doc.loveruby.net/refm/api/view/spec/m17n#script_encoding [loveruby.net]
Re: (スコア:0)
Windowsなら
Re:dankogai のブログを読む (スコア:1)
例えば、UTF-16で書いたときも同じようにすれば解釈してくれるの？
1を聞いて0を知れ!
Re: (スコア:0)
Perlだってencoding指定すれば、"表"がバックスラッシュになるなんて事ありませんよ。
インタプリンタがそう解釈してくれるんだから
小飼さんのBlogで言及してるのはまさに
> ライブラリの対応状況とか文字列の処理上の問題
だと思いますが……
なるほど、勘違いの理由が分かりました。
件のエントリでは、あえて encoding を指定しない場合の話なわけですが
(SJIS指定が出来るのは既知なので分かりやすく言及はしてませんね)
それを見て、未だに "表" がバックスラッシュに解釈されてしまうと思ったんですね？