アカウント名:
パスワード:
コードが汚くなるって言われてるけど、それよりあれがゾンビ化の主因だよなあ。いまはどうなってるのかしら?
やっぱラクダのゾンビなのかな。回し蹴りとツバ吐きが得意なのん。
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使っているようだし。つーか面倒だと思わないならそも
本来、コマインドライン@ARGVのdecodeとか、ファイル入出力時のファイル名のencodeは、Windowsに限った話ではなく、MacでもUNIXでもやらなきゃいけないものでしょう。
最近はファイル名の文字エンコーディングにUTF-8を使うことが多いので、それならしたコードでencode/decodeしなくても問題起きないし、昔ながらのEUCべースでも「ues utf8」しなければまず問題はない(「日本語文字を文字として認識する正規表現」が使えないだけ)ってだけの話。
Windows上でPerlを動かす時の面倒くささは、日本語版 Windows はデフォルトでロケールが CP932(SJIS)になってること。SJISが最大の
> Windowsに限った話ではなく、MacでもUNIXでもやらなきゃいけないものでしょう。
知ってるよ。もしMacやLinuxで本来やるべきことを誰もがちゃんとやっているなら、そもそも移植で苦労することなどありえない。しかしそれは現実と異なるから
>> MacやLinuxでこんなことわざわざしてる奴いないと思うけど。つーか忘れてもたいてい問題なく動くからWindows以外の環境で正しく書くのが超困難。だから結局Windowsに移植する奴が貧乏クジを引かされる。
と書いたんだがお読みになられましたか。
> ・PerlをUTF-8ベース(CP65001)でPerlを動かす> ことだと思います。
Console CPはファイル名で使われるコードページにはまったく影響を与えない。Encode::Localeでもlocale_fsとconsole_inとconsole_outが別々に定義されている(そう、APIレベルではコンソール入力と出力さえ異なる可能性がある)。Perlの仕様をまともにするためにあなたのような知ったかぶりバカをマサカリで殴って回るよりコストがかからないに違いないからPythonの勉強を始めたの。
> 普通のコマンドプロンプト(SJIS)ベースでは不可能。
Windowsにはコンソール入出力にもワイド文字APIがあり、それを使えば可能(リダイレクトやパイプが絡むとこっちの都合だけでエンコーディングを決められないけどそれはCygwinでも同じだし)。もちろん今あるPerlでは不可能だがそれは実装の手抜きにすぎない。そもそもCygwinはどうやってUTF-8文字を受け付けるコンソールを実現してると思ってるの?
> ・UTF-8 な cygwin の環境を構築し、その上で Perl を使う
Cygwinはパスの扱いが特殊すぎて、結局普通のアプリとパス名をやりとりする際にパスの変換/逆変換が必要なので、面倒だとか移植性ゼロだとかいう問題は何も解決しない。Perlがmsvcrt使うのやめて、UTF-8←→UTF-16LE変換を行ってワイド文字API呼び出して、Encode::LocaleはあたかもロケールがUTF-8であるかのようにふるまってくれるのが一番いいのだが、それを実現するために投入するコストを考えるとすでにまともな処理している言語の乗り換えにコストを振り向けたほうがどう考えても省エネ。
> ・@ARGVやファイル名を、スクリプト本体内のデータ処理と混ぜない
それを面倒と思わないなら以下略
> ・データ処理とファイル名が混ざる場合は、ファイル名に日本語は使わない> ってことで。運用でカバー
「本気で」どころか(Cygwinのような特殊な環境を除き)Windows上のPerlで日本語をまともに使ったことがないのはよくわかった。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
日本語を喋らせようとしたら複雑な呪文が必要なゾンビ それが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: (スコア: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使っているようだし。つーか面倒だと思わないならそも
Re: (スコア:1)
本来、
コマインドライン@ARGVのdecodeとか、
ファイル入出力時のファイル名のencodeは、
Windowsに限った話ではなく、MacでもUNIXでもやらなきゃいけないものでしょう。
最近はファイル名の文字エンコーディングにUTF-8を使うことが多いので、それならしたコードでencode/decodeしなくても問題起きないし、昔ながらのEUCべースでも「ues utf8」しなければまず問題はない(「日本語文字を文字として認識する正規表現」が使えないだけ)ってだけの話。
Windows上でPerlを動かす時の面倒くささは、日本語版 Windows はデフォルトでロケールが CP932(SJIS)になってること。
SJISが最大の
Re:美しいPerl(Re:日本語を喋らせようとしたら複雑な呪文が必要なゾンビ それがperl) (スコア:0)
> Windowsに限った話ではなく、MacでもUNIXでもやらなきゃいけないものでしょう。
知ってるよ。もしMacやLinuxで本来やるべきことを誰もがちゃんとやっているなら、そもそも移植で苦労することなどありえない。しかしそれは現実と異なるから
>> MacやLinuxでこんなことわざわざしてる奴いないと思うけど。つーか忘れてもたいてい問題なく動くからWindows以外の環境で正しく書くのが超困難。だから結局Windowsに移植する奴が貧乏クジを引かされる。
と書いたんだがお読みになられましたか。
> ・PerlをUTF-8ベース(CP65001)でPerlを動かす
> ことだと思います。
Console CPはファイル名で使われるコードページにはまったく影響を与えない。Encode::Localeでもlocale_fsとconsole_inとconsole_outが別々に定義されている(そう、APIレベルではコンソール入力と出力さえ異なる可能性がある)。Perlの仕様をまともにするためにあなたのような知ったかぶりバカをマサカリで殴って回るよりコストがかからないに違いないからPythonの勉強を始めたの。
> 普通のコマンドプロンプト(SJIS)ベースでは不可能。
Windowsにはコンソール入出力にもワイド文字APIがあり、それを使えば可能(リダイレクトやパイプが絡むとこっちの都合だけでエンコーディングを決められないけどそれはCygwinでも同じだし)。もちろん今あるPerlでは不可能だがそれは実装の手抜きにすぎない。そもそもCygwinはどうやってUTF-8文字を受け付けるコンソールを実現してると思ってるの?
> ・UTF-8 な cygwin の環境を構築し、その上で Perl を使う
Cygwinはパスの扱いが特殊すぎて、結局普通のアプリとパス名をやりとりする際にパスの変換/逆変換が必要なので、面倒だとか移植性ゼロだとかいう問題は何も解決しない。Perlがmsvcrt使うのやめて、UTF-8←→UTF-16LE変換を行ってワイド文字API呼び出して、Encode::LocaleはあたかもロケールがUTF-8であるかのようにふるまってくれるのが一番いいのだが、それを実現するために投入するコストを考えるとすでにまともな処理している言語の乗り換えにコストを振り向けたほうがどう考えても省エネ。
> ・@ARGVやファイル名を、スクリプト本体内のデータ処理と混ぜない
それを面倒と思わないなら以下略
> ・データ処理とファイル名が混ざる場合は、ファイル名に日本語は使わない
> ってことで。運用でカバー
「本気で」どころか(Cygwinのような特殊な環境を除き)Windows上のPerlで日本語をまともに使ったことがないのはよくわかった。