|
>>2670 a-jmj > その他に良い分別方法があったら教えていただけたら、幸いです。 データ構造を変えていいなら、各行に一意の番号を付けて $data{123}{DATE} = '20020101'; $data{123}{NAME} = 'hoge'; $data{123}{MAIL} = 'foo@bar'; などとするのが好みです。 データ構造を現行のままにするなら案の通り $data{20020101}[0] = '1<>aaaa<>' とするのも悪くないでしょう。 あるいは最初に <> を解析しておいて $data{20020101}[1]->{NAME} といった形でアクセスできるようにするという手もあります。以下サンプル。 my %data; open(IN,"file"); while (<IN>){ chomp; my ($date,$name,$mail,$content) = split /<>/; my %hash; $hash{NAME}=$name; $hash{MAIL}=$mail; $hash{CONTENT}=$content; push(@{$data{$date}}, \%hash); } close(IN); foreach $date (sort keys %data ){ print "$date: "; foreach my $ref_hash (@{$data{$date}}){ print "$ref_hash->{NAME} $ref_hash->{MAIL} $ref_hash->{CONTENT} "; } print "\n"; } print "おまけ: $data{20020101}[1]->{NAME}\n"; データファイルの内容: 20020101<>名前1<>メールアドレス1<>発言内容1 20020101<>名前2<>メールアドレス2<>発言内容2 20030203<>名前3<>メールアドレス3<>発言内容3 実行結果: 20020101: 名前1 メールアドレス1 発言内容1 名前2 メールアドレス2 発言内容2 20030203: 名前3 メールアドレス3 発言内容3 おまけ: 発言内容2 ただし、perl でちょっと凝ったリファレンスを使い出すと、とてつもなく ソースが汚くなるので、クラスを使いたくなるかもしれません。そして クラスを使い出すと、perl の OO に嫌気がさして ruby を使い出すかも しれません。 なので、ほどほどのところでやめておく方がいいのかも。 |
|
始めまして。C-CGI システム構築をＨＴＭＬのタグレベルで実現するツール の紹介ページが shino.server-club,net/index.htm にあります。皆様の 御参考になればとＣＭまがいの書き込みを致しました。 |
|
>>2672 Shino こんなもので金が取れると思ってるの?? なんか最初からあやしげな臭いがプンプンしてたけど、やっぱり。。 http://shino.server-club.net/cgi-bin/DS.cgi?COMMAND=Html&HTML=../../../../../../../etc/passwd 注：Referer。 汚染チェックしてね。 |
|
名無しさん様、大変失礼を致しました。 |
|
おひさしぶりですみません。質問です。 よく、インターネット（Web、メール）で （いわゆる）半角カナを使ってはいけないといわれますが、 この理由が、 ・インターネットは ASCII 以来、７ビットしか通さない伝送路が 使われてきたので、７ビットコードを使うのが望ましい ・日本の場合 ISO-2022-JP が標準 ・ISO-2022-JP は、４つの面に（いわゆる）半角カナ以外の コードが割り当てられている。 ・つまり、ISO-2022-JP には半角カナが「ない」 ・ないものは使ってはいけない という風に覚えていましたが、 UNIX の mule や Windows の xyzzy で ISO-2022-JP を指定して （いわゆる）半角カナを入れるときの、 「ESC)I がエスケープシーケンスで（いわゆる）半角カナ」 というコード系は、何に規定されているものなのでしょうか。 こんなの、ちょっと調べろよって話だと思うんですが、 調べ方が悪いのかこれだ、という情報に当りません、、。 |
|
>>2675 ふくし > 「ESC)I がエスケープシーケンスで（いわゆる）半角カナ」 > というコード系は、何に規定されているものなのでしょうか。 何にっていうのは、どの規格で定められているかってことですよね。 http://www2d.biglobe.ne.jp/~msyk/charcode/jisx0201kana/ には JUNET方式のエンコーディング方式を素直に拡張すれば、この エンコーディング方式になる。 とありますが、何をどう素直に拡張すればこうなるのか (僕の知識 不足のため) 理解できません。 http://www.kanzaki.com/docs/jis-mail.html には RFC1468には記載されていませんが、定義からESC ( I が7ビットの カタカナを指示（designate）するエスケープシーケンスとなるので、 とありますが、どこをどう読めば ESC ( I が 7bit カタカナを指示する ことになるのか これまた (僕の知識不足のため) 理解できません。 わかったら僕にも教えて下さい。 |
|
>>2675 ふくし > よく、インターネット（Web、メール）で（いわゆる）半角カナを > 使ってはいけないといわれますが、 おっと、見逃してた。ここで「web」を挙げているのは誤りです。 インターネット (≒ TCP/IP) は 8bit を通します。FTP も HTTP も 8bit through です。過去 7bit しか通さない実装が多かったのは SMTP で、7bit しか通らないところに日本語を通そうという苦肉の 策が、後の ISO-2022-JP につながる JUNET コードです。 よって、web で半角カナ使用禁止という話はありません。もちろん web で Content-type: text/html; charset=ISO-2022-JP としているならば半角カナは使えませんけれども。 ちなみに、個人的には半角カナは嫌いでしたが、2ch で AA を見てると、まぁ 半角カナもいいかなと思い始めていました。が、半角カナは EUC-JP と Shift_JIS でバイト長が違うため、項目長を事前に決めておかなければ ならない DB では何かとトラブルの元です。よって、やっぱり半角カナ 嫌いに戻ってしまいました。 |
|
そっかー。68user さんもわからないと聞いて 少なくともつまんない質問ではなかったとわかって なんかホッとしました(^o^) マルチポストになりますが、別所で聞き、なにかわかったら また書きます。ありがとうございます。 他の方も、なにかありましたらご教示ください。 |
|
>>2675 ふくし >>2676 68user お久しぶりです。 http://euc.jp/i18n/charcode.ja.html によると、 ＞終端文字と文字集合の対応は登録制になっており、 ECMAという組織が登録簿を管理して います。 (略) ＞・94文字集合 (略) ＞I ＞ JIS X 0201カタカナ ＞J ＞ JIS X 0201ローマ文字 とあります。 先にECMAが決めたのか、誰かが既に決めたのをECMAが登録したのかは、 わかりませんが。 |