Hatena::Groupasakura

浅倉卓司@blog風味? このページをアンテナに追加 RSSフィード

Error : RSSが取得できませんでした。

2007-05-17(Thu)

twitterブームに対してLingrが何かアクションするかなと思ってるんだけど、

| 13:13 |  twitterブームに対してLingrが何かアクションするかなと思ってるんだけど、 - 浅倉卓司@blog風味? を含むブックマーク  twitterブームに対してLingrが何かアクションするかなと思ってるんだけど、 - 浅倉卓司@blog風味? のブックマークコメント

 今のところ何もないですよね。見落としてる?

 違うけど似てるというか、似てるけど違うというか、微妙なラインだとは思うけど。


 Lingrは非同期じゃないから微妙という意見を見かけてやっぱりねとか思ったりもしたけれど、これが同案多数なのかどうかは知らないし、twitterの良さが非同期の部分じゃないのならLingrからその辺のフォローがあるかなー、と思っていたのでした。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20070517

2007-05-11(Fri)

PerlではUTF8文字列でマルチバイトなファイル名をちゃんと扱えないという話も書いておいてくださいな

| 11:44 |  PerlではUTF8文字列でマルチバイトなファイル名をちゃんと扱えないという話も書いておいてくださいな - 浅倉卓司@blog風味? を含むブックマーク  PerlではUTF8文字列でマルチバイトなファイル名をちゃんと扱えないという話も書いておいてくださいな - 浅倉卓司@blog風味? のブックマークコメント

 PerlでのUTF8の扱いについて宣伝するのなら、それでファイル名を扱えないことについてちゃんとフォローしておいてくださいね。

(→追記があります。)


フォロー=「使えない可能性がありますよ」と補足すべきでは、という事です

| 13:56 |  フォロー=「使えない可能性がありますよ」と補足すべきでは、という事です - 浅倉卓司@blog風味? を含むブックマーク  フォロー=「使えない可能性がありますよ」と補足すべきでは、という事です - 浅倉卓司@blog風味? のブックマークコメント

 弾さんに言われなくてもPerlでマルチバイトなファイル名を扱うための提案はちゃんとしてるつもりです*1。だからこそ気になったわけで。


 UTF8文字列をファイル名として扱った場合にprint等と違ってwarningが出ないのは仕様としては不思議だな、と思いますけれど。


FUDというほどの内容ではないでしょう

| 17:18 |  FUDというほどの内容ではないでしょう - 浅倉卓司@blog風味? を含むブックマーク  FUDというほどの内容ではないでしょう - 浅倉卓司@blog風味? のブックマークコメント

 UTF8文字列をファイル名として指定したときにwarningを出さないのは不思議でもなんでもないそうですが、それではprintしたときにwarningを出すのは何故なんでしょうか。

 僕は同じ理由でwarningを出すべきなんじゃないかな、と思っただけです*2


ついでに言うと、本当に朝倉さんの要求を額面通りに受け取るなら、filenameプラグマは的はずれだろう(そんなことをするくらいならIO::Allにファイル名をいじくるオプションでもつけてもらった方がいい)。

 なるほど*3。すべてをPerlIOに任せるべき、というのはその通りかもしれません。

 ちなみに、filenameプラグマはencodingプラグマと整合的に使えるとうれしいな、というのが先にあったので、それが唯一の解だと思っているわけではないです。したがって、IO::Allにファイル名をいじくるオプションが付いたさいには、それを利用して既存の関数などをラッピングするプラグマを書くような気はします。


 あと、別に弾さんにつっかかってるつもりはないです。

 たまたまあの記事を読んで「日本語のファイルを開こうとしたらできないじゃん!」って人がいるかもなぁ、フォローといたほうがいいよなぁ、と思っただけです*4

 「あんたがフォロー記事を書けばいいじゃん」って言われればその通りなので、前に自分が書いた記事に触れておくことにしました。


PerlとPerl以外でファイルのやりとりをする可能性はないのでしょうか

| 21:54 |  PerlとPerl以外でファイルのやりとりをする可能性はないのでしょうか - 浅倉卓司@blog風味? を含むブックマーク  PerlとPerl以外でファイルのやりとりをする可能性はないのでしょうか - 浅倉卓司@blog風味? のブックマークコメント

人間には文字化けして見える「繝輔ぃ繧、繝ォ.txt」というファイル名だって、Windowsにとっては(そしてPerlにとっても)正常なファイル名ですもの。warningを出す理由がありませんでしょ。

Perlの中で閉じているかそうでないかの差でしょう

 人間以外も認識できないと思いますけれど。

 Perlが扱うUTF8文字列なファイル名はWindows(あるいはそこで動くアプリケーション/ツール)にとっての「正常な」ファイル名ではありません*5。少なくともPerl以外のアプリケーション/ツールで作った「ファイル.txt」はお互いに開けます*6Perlでは開けませんし、逆もまたしかりです*7


 あるいは逆に、printした結果が「繝輔ぃ繧、繝ォ」であっても、それは人間には文字化けして見えるだけですから、warningを出す必要はないんじゃないでしょうか*8


 ファイル名は「Perlで閉じている」ものではないのですから、ファイルの中身と同様に扱うのが自然だと思うのです。


僕はファイル名も文字列として扱いたいわけですよ

| 11:20 |  僕はファイル名も文字列として扱いたいわけですよ - 浅倉卓司@blog風味? を含むブックマーク  僕はファイル名も文字列として扱いたいわけですよ - 浅倉卓司@blog風味? のブックマークコメント

 ファイル名は常にバイト列でしかあり得ない、というのであればd:id:charsbarさんの主張も(ある程度は)理解できますが、僕は文字列として扱いたいのですよ*9

 例えば、正規表現でマッチさせるとか、(encodingを問わない)テキストファイルからファイル名を読み込んで(あるいは加工なりなんなりして)処理するとかね。


歴史は繰り返す、のかな

| 00:53 |  歴史は繰り返す、のかな - 浅倉卓司@blog風味? を含むブックマーク  歴史は繰り返す、のかな - 浅倉卓司@blog風味? のブックマークコメント

でもね、お作法というなら、UTF8フラグ付きの文字列として扱う前にはdecodeをするのがお作法。ファイルシステム含め外部とのやりとりをするときはencodeするのもお作法。

ファイル名を文字列として扱いたいってのとは話が別

 うん、それはそうです。

 でもね、UTF8文字列をprint(あるいはreadline)するときはbinmode(やopenの引数等)で自動的に変換するように指定できるじゃないですか*10。あるいはprint時にencodeを指定しないとwarningが出るじゃないですか*11

 ファイル名を扱うときも同様にしたほうが仕様としては統一感があるでしょ、ということです。Practicalだと言うんであれば、そうであったほうが実用的にも便利ですし。


 ファイル名を実行環境に合わせてPerl側が全自動でなんとかしろ、なんて話はしていなくて*12、printなんかと同様にUTF8文字列をファイル名として使った時は指定したencodeで変換すればいいのにね、どうしてそうなっていないんだろう、って話なんですよ。仕様として不思議だなというのはそういうこと。

 printの時と同様に勝手にUTF-8バイト列(オクテット)として出力するんじゃない、するんであればwarningくらい出したほうがいいんじゃね、と。5.8.0あたりの事を思い出しますと、特にね。


 この辺の仕様の疑問については(昔Encodeがらみのメールのやりとりがあったのもあって)Jcodeメーリングリストにも

1. open()などでUTF8文字列をファイル名に使った時はwarningを出すべきではないか
 print等での扱いを考えると、open等でもwarningを出したほうが良いと思うのですが、
いかがでしょうか。

2. UTF8文字列をファイル名に指定した時、できれば自動的にencodeして欲しい
 encodingのようなプラグマで指定するか、あるいは3引数openの2番目の引数
で指定できるのが望ましいように思います。

――みたいな形で提案(あるいは質問)をしてはいたのです。

*1:および補足

*2:もっとも、そもそもマルチバイトなファイル名については何も考慮していないんじゃないか――少なくとも何かを検討したうえで現在の仕様に決めたわけではなくて、たまたま現在こうなっているだけ――という気もしますけれど。

*3:ちなみに僕は「浅倉」であって「朝倉」ではありません。念のため。

*4:ちょうどその手の事について考えていたタイミングだったものですから。

*5:「ちゃんと扱えない」と思っているのはそのためです。「いちおう扱える」とは思いますけれど。ま、その辺はPerlに限った話じゃないですが。

*6:ついでにファイル名で検索もできます。

*7:これはWin32以外でも同じで(おそらくd:id:charsbarさんの指摘通り)LOCALE等によって変わったりするんじゃないのかな。そもそもマルチバイトなファイル名について考慮されていないOSのほうが多いかもしれませんが。

*8:ところで、UTF8フラグ付きでprintする方法はないと思いますが(UTF8フラグはperlの内部情報だから)、何かやり方があるんでしょうか。少なくともUTF8で書かれたファイルを読み込んでも勝手にUTF8フラグを付けて読み込んだりはしないはずです。

*9Perlでマルチバイトを含めた文字列を扱う時は、UTF8フラグ付きの文字列として扱うのが標準的な作法です。

*10:「ちゃんと使える」のはこういう機能があるから。

*11:UTF-8で出力するときも明示しなくちゃ駄目ですし。

*12:まあできるんであれば対応したほうが嬉しいとは思うけれど。

:-):-)2007/05/12 11:49いつまで言いがかり続ける気なんですか?

BarBar2007/05/12 19:35↑なんか、自分の意見や技術力のない人ほど、すぐ他人のところに首突っ込んできて誹謗すんのってなに? 人間力が低いってこと? それとも空気読めないってこと?

tateisutateisu2007/05/12 20:19Windowsの場合はANSIコードページかUnicodeで表現された文字列を使ってファイル名を扱いますが、Perlのファイル名は現在のところマルチバイト文字列のみです。元々POSIX文化の製品を別の文化のOSで使っているのがこの問題の核でしょう。openだけならフラグを見てUnicode APIをつかってくれればいいかもしれませんが、opendirやglobまで考慮すると根本的な解決にはならないと思います。

tateisutateisu2007/05/12 20:39なぜ難しいかというと、POSIX環境では同じディレクトリに異なるエンコーディングのファイル名が存在することがあり、便宜的にエンコーディングを仮定してもよいとは限らないからです。あと、globはオーバライドしないとダメでしょうね。

2007-05-10(Thu)

livedoorクリップのタグ入力部分でのTabの動作がちゃんとしているのにいまさら気付いた

| 14:22 |  livedoorクリップのタグ入力部分でのTabの動作がちゃんとしているのにいまさら気付いた - 浅倉卓司@blog風味? を含むブックマーク  livedoorクリップのタグ入力部分でのTabの動作がちゃんとしているのにいまさら気付いた - 浅倉卓司@blog風味? のブックマークコメント

 Tabでスペースが入力され(項目が確定し)、さらにTabを押すと次のフォーム要素に移動するのね。

 しらんかった。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20070510

2007-05-09(Wed)

セカンドライフが流行るくらいなら、その前にコレピクが流行るんじゃないの?

| 01:04 |  セカンドライフが流行るくらいなら、その前にコレピクが流行るんじゃないの? - 浅倉卓司@blog風味? を含むブックマーク  セカンドライフが流行るくらいなら、その前にコレピクが流行るんじゃないの? - 浅倉卓司@blog風味? のブックマークコメント

――と常々思っているのですが、全然取り上げられないのね。

 セカンドライフでどーこーするくらいなら、コレピクでオフィシャルアイテムでも出したほうが面白そうなのに。

 Wiiに対応すればそこそこ流行りそうなんだけど。だらっとTVに流しとけばいいし。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20070509

2007-05-07(Mon)

購入の検討に値する電子書籍

| 23:54 |  購入の検討に値する電子書籍 - 浅倉卓司@blog風味? を含むブックマーク  購入の検討に値する電子書籍 - 浅倉卓司@blog風味? のブックマークコメント

 ちょっと前に「富士山マガジン、IT技術誌「Software Design」デジタル版を発売」という記事を見かけて「相変わらず出版社はやる気ねー」とうんざりしたわけですよ。

 この手のやつにはだいたい

 雑誌のデジタル版は、紙媒体と同じ感覚でページをめくれる機能や、中身を丸ごとキーワード検索できる機能、視線の流れに沿って読むエリアを自動拡大する「ラク読み機能」などが搭載されており、記事単位での付箋やメモ、ハイライトも可能だ。

みたいなウザい機能が付いてて「紙媒体と同じ感覚」を目指すんだけど、だったら紙媒体のほうがいいに決まってじゃん。はっきり言って無駄だと思うんだけど、出版社の(あるいは編集部の)エライ人的には「紙媒体らしさ」は必須らしい。

 無駄な点には目をつぶって検索性が良ければ「電子化して良かったね」とか思うんだけど、下手すると全く検索できなかったりするし*1、これで「電子書籍を販売してます」とか言われても「おまえら売る気ないだろ」としか思えない。


 そもそも紙媒体で使うデータを使い回してる時点で基本的には紙媒体に劣るものしかできないのだよ。それでも電子媒体である利点を使ってもうちょっと工夫をすれば「買ってもいいかな」と思える可能性はあるのに。

 例えば。

 書籍は版によっては微妙に変更されているのだけれど――主に誤字脱字の修正とかでね――そういったのもを入手するには買い直すしかない。交換とかしてたらコストがかかって現実的じゃないしね。でも、電子媒体ならこれは簡単だ。専門ツールを使わせるくらいなら「自動アップデート」くらい対応すべきでしょ。

 あるいは、「改訂版」を値引き販売するのも電子媒体なら簡単だから是非やるべきだ。っつーか「ヤバい経済学(増補改訂版)」の「増補」部分だけ売れよ! パソコンソフトならバージョンアップ対象だろ! もし「ヤバい経済学」が電子出版されていてバージョンアップ対象なら「電子版にすれば良かった!」と思ったかもしれない。

*1:この点で「WEB+DB Press」がPDFにしてるのはマシだと思う――あれはテキスト付きのPDFだよね? 実は違ったりする?

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20070507

2007-05-02(Wed)

ファイルテスト演算子(-X)を変更する方法が分からない

| 17:11 |  ファイルテスト演算子(-X)を変更する方法が分からない - 浅倉卓司@blog風味? を含むブックマーク  ファイルテスト演算子(-X)を変更する方法が分からない - 浅倉卓司@blog風味? のブックマークコメント

 とりあえずstat()みたいにファイル名かファイルハンドルを受け取るものに関しては

    my $stat = eval {$where->can('stat')};
    *{"$where\::stat"} = sub (*) {
        my $file = shift || $_;
        is_utf8($file) and $file = $convert->($file);
        if (not ref $file and exists ${"$where\::"}{"$file"}) {
            $file = qualify_to_ref($file, caller);
        }
        $stat? $stat->($file): CORE::stat($file);
    };

――とかで動くのだけれど*1、-e(file exists)なんかを上書きする方法が分からなくて困ってます。

 こればっかりは無理なのかな。

 やるとすればソースフィルタでごにょごにょするとか? うーん。

 それで:globallyなことができればいいのだけれど……。

*1:ただし、barewordファイルハンドルかどうかの判定がこれで良いのか分からない。動いてはいたけど。

inabahirotoinabahiroto2007/05/06 01:30use overload が-Xもオーバーロードできるようになっていてもよかったのに、と思いますが…。

asakura-tasakura-t2007/05/07 23:58ファイルテスト演算子は「演算子」というよりは「関数」だと思うので、globみたいにCORE::にマップされてれば良かったのですけれど。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20070502
2004 | 01 | 02 | 03 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 08 | 09 | 10 | 11 | 12 |
2007 | 02 | 03 | 04 | 05 | 06 | 07 | 10 | 11 | 12 |
2008 | 02 | 03 | 04 | 06 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 02 | 03 | 04 | 05 | 07 | 08 | 10 | 11 | 12 |
2013 | 01 | 05 | 07 |
2014 | 01 | 02 |
2016 | 01 |
2017 | 01 | 05 |