アカウント名:
パスワード:
コードが汚くなるって言われてるけど、それよりあれがゾンビ化の主因だよなあ。いまはどうなってるのかしら?
やっぱラクダのゾンビなのかな。回し蹴りとツバ吐きが得意なのん。
Perl::Criticってのがあって、これを使うとどんな言語よりも美しく書ける(無理矢理書かされる)ようになります。仕事に使うなら必須ですね。http://search.cpan.org/~thaljef/Perl-Critic-1.121/lib/Perl/Critic/Poli... [cpan.org]#severity=1で絶望するのが誰もが通る道。
日本語の扱いは、現在は Encode::JP がありますから、ほぼ呪文は要らないんじゃないですかね。日本語を正規表現で処理するには perl が一番楽だと思う。
今時のperlならばuseutf8;use Encode;で日本語はおろか多言語で幸せですからねぇ。
呪文って何なんだろう?まさかこれ?でも、これ以前ならば何やってもまともに日本語使えなかったけど。EUC依存なコードにしたところで、Windowsだとcp932なファイルを扱わないといけないわで、なんだかんだでorz
> 呪文って何なんだろう?
コマンドラインからの引数取得とかファイル操作とかのたびに@ARGV = map { decode('cp932', $_) } @ARGV; とかopen my $fh, '', encode('cp932', $filename) or die $!; とか@files = map { decode('cp932', $_) } readdir($d); とかif (-f encode('cp932', $filename)) とかmkdir encode('cp932', $filename); とかソース全体にわたって書かなければならないこと。
これが面倒だと思わない奴はWindows上でPerlを本気で使ったことがないとしか思えない。少なくとも小飼弾はMac使っているようだし。つーか面倒だと思わないならそもそもどうして開祖が「怠惰はプログラマの美徳」とか言ってる言語なんか使ってるの?
56億7千万歩ほど譲ってこれは面倒ではないということにしても、Windows以外の環境への移植性がまったくない。Windows上でシステムロケールを変えただけで動作がおかしくなる。当然どんな環境で動くかわからないモジュール内では使えない。まあいちおうこれには対処の方法があって、use Encode::Locale;@ARGV = map { decode(locale, $_) } @ARGV; とかopen my $fh, '', encode(locale_fs, $filename) or die $!; とか@files = map { decode(locale_fs, $_) } readdir($d); とかif (-f encode(locale_fs, $filename)) とかmkdir encode(locale_fs, $filename); とかさらに呪文を積み増しすればいいらしい。MacやLinuxでこんなことわざわざしてる奴いないと思うけど。つーか忘れてもたいてい問題なく動くからWindows以外の環境で正しく書くのが超困難。だから結局Windowsに移植する奴が貧乏クジを引かされる。Windows上ですら、localeとlocal_fsが違う環境があるというバグを知らずに踏んでも気づかない。
しかし実はEncode::Locale;使ってもまだ不十分で、システムロケール(日本語版ならシフトJIS)で表せない文字を含んだファイル名が扱えない。いちおうWin32::Unicode::Fileというモジュールがあるようだが、ファイル読み書きをモジュール内で独自に行なっているので信じられないほど遅くて捨てた。Win32::Longnameというモジュールがちょっとはマシなようだが、どちらにしてもまたも移植性がなくなる。
自分で書くコードは上記の面倒じゃないことにした書き換えを「するだけで」済むとしても、File::compareのような超基本的モジュールすらいまだに非対応。
Perlでこのへんが改善される見込みはまったくなさそうなので、自分はPythonの勉強を始めた。
まだ調べ始めたばかりだけどPythonはかなりよさそう。Python 2はsys.argvがまだunicode化されていないとかopen関数などに間違ってバイト列を渡さないよう注意する必要があるとか微妙な点もあるけど、Python 3はすごくいい。裏を返すとWindows上で日本語をまともに扱えるようにするには互換性を犠牲にする必要があったわけで、Perlでは改善が期待できそうにないと思った理由の1つ。
非ASCII文字を含むバイト列とUnicode文字列を連結したとき、Perlみたいに勝手にバイト列をlatin-1とみなしてupgradeして意味不明なバグの原因になったりしないで、ちゃんと例外投げて死んでくれるのもポイント高い。
RubyはPerlのEncode::Localeレベルのサポートまではいいけど、Unicode固有文字を含むファイル名の扱いがダメダメっぽい。
本来、コマインドライン@ARGVのdecodeとか、ファイル入出力時のファイル名のencodeは、Windowsに限った話ではなく、MacでもUNIXでもやらなきゃいけないものでしょう。
最近はファイル名の文字エンコーディングにUTF-8を使うことが多いので、それならしたコードでencode/decodeしなくても問題起きないし、昔ながらのEUCべースでも「ues utf8」しなければまず問題はない(「日本語文字を文字として認識する正規表現」が使えないだけ)ってだけの話。
Windows上でPerlを動かす時の面倒くささは、日本語版 Windows はデフォルトでロケールが CP932(SJIS)になってること。SJISが最大の元凶で、SJISで記述したスクリプトを動作させようとすると、EUCの場合と違って、「表の2バイト目の\」問題などではまる。
だから、スクリプトをUNIXなどと共用する一番完璧で単純な解決策は、・PerlをUTF-8ベース(CP65001)でPerlを動かすことだと思います。それなら元コメで挙げられてるような問題は起きません。もっとも、そのためには・UTF-8ベースで動くコンソールが必要なので、普通のコマンドプロンプト(SJIS)ベースでは不可能。chcp 65001 しても、かなり動作が怪しい。実質、・UTF-8 な cygwin の環境を構築し、その上で Perl を使うのが一番楽なんじゃないかと思います。
結構面倒なので、私の場合、結局いろいろ試した結果、・@ARGVやファイル名を、スクリプト本体内のデータ処理と混ぜない(@ARGVとファイル名だけSJISベース、データ処理はUTF-8)というのに落ち着きました。もしくは、・データ処理とファイル名が混ざる場合は、ファイル名に日本語は使わないってことで。運用でカバーですね。
#「日本語ファイル名はなんとなく使いたくない」という古い人間なので出来る技ですが…
> Windowsに限った話ではなく、MacでもUNIXでもやらなきゃいけないものでしょう。
知ってるよ。もしMacやLinuxで本来やるべきことを誰もがちゃんとやっているなら、そもそも移植で苦労することなどありえない。しかしそれは現実と異なるから
>> MacやLinuxでこんなことわざわざしてる奴いないと思うけど。つーか忘れてもたいてい問題なく動くからWindows以外の環境で正しく書くのが超困難。だから結局Windowsに移植する奴が貧乏クジを引かされる。
と書いたんだがお読みになられましたか。
> ・PerlをUTF-8ベース(CP65001)でPerlを動かす> ことだ
解説thx。前半のWindows内で閉じた部分は モジュールでカプセル化して 問題ないレベルにするのは簡単なんだけど、後半の localeのは確かに問題だね。
フォローありがとー!┌(_Д_┌ )┐ 元コメ#2628113より。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
日本語を喋らせようとしたら複雑な呪文が必要なゾンビ それがperl (スコア:0)
コードが汚くなるって言われてるけど、それよりあれがゾンビ化の主因だよなあ。
いまはどうなってるのかしら?
やっぱラクダのゾンビなのかな。回し蹴りとツバ吐きが得意なのん。
美しいPerl(Re:日本語を喋らせようとしたら複雑な呪文が必要なゾンビ それがperl) (スコア:0)
Perl::Criticってのがあって、これを使うとどんな言語よりも美しく書ける(無理矢理書かされる)ようになります。
仕事に使うなら必須ですね。
http://search.cpan.org/~thaljef/Perl-Critic-1.121/lib/Perl/Critic/Poli... [cpan.org]
#severity=1で絶望するのが誰もが通る道。
日本語の扱いは、現在は Encode::JP がありますから、ほぼ呪文は要らないんじゃないですかね。
日本語を正規表現で処理するには perl が一番楽だと思う。
Re: (スコア:0)
今時のperlならば
useutf8;
use Encode;
で日本語はおろか多言語で幸せですからねぇ。
呪文って何なんだろう?まさかこれ?
でも、これ以前ならば何やってもまともに日本語使えなかったけど。
EUC依存なコードにしたところで、Windowsだとcp932なファイルを扱わないといけないわで、なんだかんだでorz
Re:美しいPerl(Re:日本語を喋らせようとしたら複雑な呪文が必要なゾンビ それがperl) (スコア:0)
> 呪文って何なんだろう?
コマンドラインからの引数取得とかファイル操作とかのたびに
@ARGV = map { decode('cp932', $_) } @ARGV; とか
open my $fh, '', encode('cp932', $filename) or die $!; とか
@files = map { decode('cp932', $_) } readdir($d); とか
if (-f encode('cp932', $filename)) とか
mkdir encode('cp932', $filename); とかソース全体にわたって書かなければならないこと。
これが面倒だと思わない奴はWindows上でPerlを本気で使ったことがないとしか思えない。少なくとも小飼弾はMac使っているようだし。つーか面倒だと思わないならそもそもどうして開祖が「怠惰はプログラマの美徳」とか言ってる言語なんか使ってるの?
56億7千万歩ほど譲ってこれは面倒ではないということにしても、Windows以外の環境への移植性がまったくない。Windows上でシステムロケールを変えただけで動作がおかしくなる。当然どんな環境で動くかわからないモジュール内では使えない。
まあいちおうこれには対処の方法があって、
use Encode::Locale;
@ARGV = map { decode(locale, $_) } @ARGV; とか
open my $fh, '', encode(locale_fs, $filename) or die $!; とか
@files = map { decode(locale_fs, $_) } readdir($d); とか
if (-f encode(locale_fs, $filename)) とか
mkdir encode(locale_fs, $filename); とかさらに呪文を積み増しすればいいらしい。
MacやLinuxでこんなことわざわざしてる奴いないと思うけど。つーか忘れてもたいてい問題なく動くからWindows以外の環境で正しく書くのが超困難。だから結局Windowsに移植する奴が貧乏クジを引かされる。Windows上ですら、localeとlocal_fsが違う環境があるというバグを知らずに踏んでも気づかない。
しかし実はEncode::Locale;使ってもまだ不十分で、システムロケール(日本語版ならシフトJIS)で表せない文字を含んだファイル名が扱えない。いちおうWin32::Unicode::Fileというモジュールがあるようだが、ファイル読み書きをモジュール内で独自に行なっているので信じられないほど遅くて捨てた。Win32::Longnameというモジュールがちょっとはマシなようだが、どちらにしてもまたも移植性がなくなる。
自分で書くコードは上記の面倒じゃないことにした書き換えを「するだけで」済むとしても、File::compareのような超基本的モジュールすらいまだに非対応。
Perlでこのへんが改善される見込みはまったくなさそうなので、自分はPythonの勉強を始めた。
Re:美しいPerl(Re:日本語を喋らせようとしたら複雑な呪文が必要なゾンビ それがperl) (スコア:1)
自分の使い方では一回ファイルをLinuxへ持ってきて処理しちゃうからWindows上にPerlを用意していない。
っていうか、Windows上で実用的なスクリプト言語ってあまり選択肢ないよね。
RubyとかPythonとかは実際便利なレベルに達しているのかしら?
Re: (スコア:0)
まだ調べ始めたばかりだけどPythonはかなりよさそう。Python 2はsys.argvがまだunicode化されていないとかopen関数などに間違ってバイト列を渡さないよう注意する必要があるとか微妙な点もあるけど、Python 3はすごくいい。裏を返すとWindows上で日本語をまともに扱えるようにするには互換性を犠牲にする必要があったわけで、Perlでは改善が期待できそうにないと思った理由の1つ。
非ASCII文字を含むバイト列とUnicode文字列を連結したとき、Perlみたいに勝手にバイト列をlatin-1とみなしてupgradeして意味不明なバグの原因になったりしないで、ちゃんと例外投げて死んでくれるのもポイント高い。
RubyはPerlのEncode::Localeレベルのサポートまではいいけど、Unicode固有文字を含むファイル名の扱いがダメダメっぽい。
Re:美しいPerl(Re:日本語を喋らせようとしたら複雑な呪文が必要なゾンビ それがperl) (スコア:1)
本来、
コマインドライン@ARGVのdecodeとか、
ファイル入出力時のファイル名のencodeは、
Windowsに限った話ではなく、MacでもUNIXでもやらなきゃいけないものでしょう。
最近はファイル名の文字エンコーディングにUTF-8を使うことが多いので、それならしたコードでencode/decodeしなくても問題起きないし、昔ながらのEUCべースでも「ues utf8」しなければまず問題はない(「日本語文字を文字として認識する正規表現」が使えないだけ)ってだけの話。
Windows上でPerlを動かす時の面倒くささは、日本語版 Windows はデフォルトでロケールが CP932(SJIS)になってること。
SJISが最大の元凶で、SJISで記述したスクリプトを動作させようとすると、EUCの場合と違って、「表の2バイト目の\」問題などではまる。
だから、スクリプトをUNIXなどと共用する一番完璧で単純な解決策は、
・PerlをUTF-8ベース(CP65001)でPerlを動かす
ことだと思います。それなら元コメで挙げられてるような問題は起きません。もっとも、そのためには
・UTF-8ベースで動くコンソール
が必要なので、普通のコマンドプロンプト(SJIS)ベースでは不可能。chcp 65001 しても、かなり動作が怪しい。実質、
・UTF-8 な cygwin の環境を構築し、その上で Perl を使う
のが一番楽なんじゃないかと思います。
結構面倒なので、私の場合、結局いろいろ試した結果、
・@ARGVやファイル名を、スクリプト本体内のデータ処理と混ぜない(@ARGVとファイル名だけSJISベース、データ処理はUTF-8)
というのに落ち着きました。もしくは、
・データ処理とファイル名が混ざる場合は、ファイル名に日本語は使わない
ってことで。運用でカバーですね。
#「日本語ファイル名はなんとなく使いたくない」という古い人間なので出来る技ですが…
Re: (スコア:0)
> Windowsに限った話ではなく、MacでもUNIXでもやらなきゃいけないものでしょう。
知ってるよ。もしMacやLinuxで本来やるべきことを誰もがちゃんとやっているなら、そもそも移植で苦労することなどありえない。しかしそれは現実と異なるから
>> MacやLinuxでこんなことわざわざしてる奴いないと思うけど。つーか忘れてもたいてい問題なく動くからWindows以外の環境で正しく書くのが超困難。だから結局Windowsに移植する奴が貧乏クジを引かされる。
と書いたんだがお読みになられましたか。
> ・PerlをUTF-8ベース(CP65001)でPerlを動かす
> ことだ
Re: (スコア:0)
解説thx。
前半のWindows内で閉じた部分は モジュールでカプセル化して 問題ないレベルにするのは簡単なんだけど、
後半の localeのは確かに問題だね。
Re: (スコア:0)
フォローありがとー!┌(_Д_┌ )┐ 元コメ#2628113より。