トップへ
最新（あんぜん）
さて 1999/5/10 <=
はしもとは一応技術屋なわけですけど。基本的には素人です。
だから、できないことの方が多いし、間違ってることとかもたくさんあります。
でも、まあ、なんかぼちぼちやってます。
このページ、雑記のほとんどはＣＧＩで更新してます。入力フォームを別に持ってる掲示板みたいな感じでしょうか。
でも、出力はＨＴＭＬなので、誰かが見るたびＣＧＩが動くことはありません。
ついでに言うと、ＧＯＯロボットも来るでしょう（笑）
基本的に同様のシステムで、オリジナルの掲示板ＣＧＩを作りたいんですけど、どーなることやらさっぱり不明です。
後でこの場所でそれについて何か書くつもりではあります。
とりあえず、テーマだけ。
掲示板あらし対策（不正書き込みをどうするか）
クッキー（ＨＴＭＬ出力だと、ＣＧＩでクッキー使えないのね）
うーん、いつ書けるんだろう
掲示板の類 1999/5/12 <=
掲示板あらし対策しなくていいなら、すぐにだって作れるのだけど・・・
一言で掲示板あらし対策と言っても、多くの意味がある。
・書き込み内容に対する対策
許したいタグ以外の不許可（ま、当然）
スタイルシートの不許可（９９９９９ピクセルの文字とか書けるし）
書き込み容量制限（これも当然）
特定キーワードの禁止（あんまり意味はないけどね）
連続書き込み禁止（まったく同じ内容の書き込みはだめ）
・書き込みそのものに対する制限
ＣＧＩを呼び出すＵＲＬの制限（特定の入力フォームからのリクエストしか受け付けない）
ユーザのＩＰに対する制限（引けなかったら禁止とか、特定ＩＰ禁止とか）
また、上記の条件などで書き込みを禁止する場合、どのように書き込みを禁止するか。
素直に「○○は使えません」とか表示するのが普通だけど、それが相手の神経を逆なでする結果にもなるだろう。
他に、上記の複合条件（「どこどこからの○○タグ禁止」など）も考慮してもいいかもしれない。
そこまで考えなくても、実は、管理者がまめに掲示板をチェックしていれば、普通はなんとかなるものだが、表示破壊系とか、ブラウザハングアップ系とかは、かなり嫌なものだし、getメソッドとimgタグによる間接連続攻撃などは、攻撃側の手間がほとんどいらないわりに、攻撃能力はすごく高いので、対策しなければならないと思う。
まあ、あと、ページそのものが閉鎖的だったりすれば案外大丈夫だけど、そーゆーのはどこから来るかわかりゃしないし、攻撃に特別な理由は必要ないので、ある日、突然掲示板がぐちゃぐちゃになるかもしれない。
joeさんのページに、掲示板あらし関係の記事があります。「掲示板あらし事件」と「乗っ取られた掲示板事件」、どっちも面白いよ。
クッキーの話 1999/5/14 <=
通常、掲示板のクッキーはＣＧＩで処理している。
ＣＧＩを呼び出す際にクッキー情報を取得して、入力フォームの初期値にvalue="なんたら"とかいって設定しているわけだ。
掲示板の表示そのものが、常にＣＧＩで生成されるタイプ（有名なminibbsとか）の掲示板では、その方法で問題はないのだが、ＨＴＭＬファイルをを出力するタイプだと問題がある。
出力されたＨＴＭＬファイルはサーバに存在しつづけるので、通常にアクセスしてもＣＧＩは起動しないわけだ。つまり、ＣＧＩはどうがんばってもクッキーをとりにいけないのである。
解決策は２つある。
１、書き込む際に入力フォームをＣＧＩで呼び出す。
つまり、書き込みをするときに入力フォームをＣＧＩで生成して、そのＣＧＩでクッキーを処理
するということだ。たいていの場合、入力フォームは別のウィンドウや別のフレームに開かれる。
ただし、１段階余分な操作が加わるぶん、ユーザの手間がかかるし、ページリクエストが１回増えるぶんだけレスポンスも低下する。フレームやら別窓やら、設定するのもちょっと面倒だ。
２、ＨＴＭＬファイルそのものからクッキーを呼び出す。
これは、scriptタグとかで行う。他のスクリプトについてよく知らないのでコメントは避けるが、最も一般的なJavaScriptで、普通の掲示板で使っているようなクッキーを実現することができる。
「送信」ボタンを押したときに指定したフォームの内容をクッキーとしてセーブし、次にそのページを読み込んだときに、自動的にクッキーを呼び出してフォーム内容を書き換えるのだ。
ユーザは、普通のＣＧＩで出力する掲示板と同じ感覚で操作できる。
私としては後者がおすすめだ。なんせ、JavaScriptは軽いし、ユーザは特別な操作も必要としない。（プログラムが１つ必要にはなるが）
JavaScriptでクッキーを処理する実験はすでに終了しているので、近いうちに公開しようと思う。
perlのはなし 1999/5/21 <=
ちょっと毛色が変わって今回は言語の話。
一般的にＣＧＩプログラムはperlで書かれている事が多い。ネットで公開されているのもたいがいperlのプログラムだ。かく言う私もＣＧＩはperlで作っている。
それはなぜかというと、perlの特徴による。
まず、言語として使いやすい。コンパイルもいらないし、unixの類ならほぼperlはインストールされている。言語仕様もゆるくて、細かいことをあまり気にしなくても大丈夫。
あと、みんな使っているから資料も豊富だし。
んで、perlはＣＧＩと相性がいいのだ。
perlの欠点は、速度が出ないこと、グラフィックを扱いにくいこと、などがあるが、ＣＧＩとして使う場合、出力はＨＴＭＬのテキストである場合がほとんどだし、処理速度よりも、回線速度の方が明らかに時間がかかるので、遅いという印象も薄れる。
そして、perlは、文字列と配列の扱いが非常に得意である。詳しい解説をここでしても仕方ないのでパスするが、この特徴は、掲示板などを作る場合にものすごくありがたい。
ただし、ある程度以上重いプログラムは、cなどで作った方が無難なのは間違いない。
でも、perlは素敵な言語なんだよ、というお話
JavaScriptでくっきーなはなし 1999/5/27 <=
以前予告した通り、サンプルを公開しよう。
cookie.htm
「記録」でテキストボックスの内容をクッキー情報として保存して。
「呼び出し」でそれを呼び出してテキストボックスに表示する。
「りせっと」はリセットだ。
ソースを見ればわかるけれど、クッキーの処理以外は何もしていないので、実験しても問題はないと思われる。くっきーの賞味期限（？）も１日しかないわけだし・・・
ソースについて具体的に解説するのもなんか面倒なので省略。
もし何かあったらメールしてくれれば応対できるとは思う。
ま、大して難しいことしてるわけじゃないので、解析するのはそんなに手間がかかるものでもないだろう。そのままコピーして使われるのはあまり気分がいいものじゃないけど、これを参考に誰かがプログラムを作るのは別に問題はないことだと思う。
自分で解析してプログラム作れないけど、どっかで何かに（たとえばＨＴＭＬ出力型掲示板に）これを使いたいと思ったときとかは、メールとかしてくれたら対応できるかもしれない。
あんまり自信はないし、何の保証もしないけど。
ちょいと補足 1999/5/27 <=
文中にたまにあるコメントアウトされたalert文は、
いわゆるデバッグモードのよーなものです。
JavaScriptのエラーが発生したとき、ブラウザによってぜんぜん動作が違ったりする。ＩＥ４は比較的親切だし、ねすけ4.5はエラー内容も表示してくれない。でもねすけ4.04なんかだとエラーメッセージにＯＫしないと何もできなかったり・・・
で、まあ、ともかく、alert文書くとそこで完全に処理が止まるし、どこでミスってるのかも発見しやすくなるというわけですな。
よーするに、別に意味はないよ。ってこと。
＊せぱれいてっどばりゅー 1999/5/31 <=
今回は、データ保存の話。
掲示板なんかのデータは、たとえば、名前、内容、メールアドレス、日付、などのデータを持っている。これらは、可変長データであり、また、そのデータをひととおりそろえたものが、１件分の書き込みデータとなる。それが、数十から数百保存されたものが、掲示板のデータということになる。
たとえば、
名前、メール、ＵＲＬ、タイトル、内容、日付
名前２、メール２、ＵＲＬ２、タイトル２、内容２、日付２
名前３、メール３、ＵＲＬ３、タイトル３、内容３、日付３
などというデータが保存されるわけである。
これから、確実に元のデータを取り出すためには、いくつめの書き込みの何番目のデータか、ということが、狂わずに保存されている必要がある。
上の例ならば、改行コードで書き込み１件分のデータを取り出し、「、」でそれぞれのデータを区切っている。
ちなみに、同様にしてコンマ「,」で区切ったものを、csv（コンマセパレイテッドバリュー）という。excelなど、表計算ソフトのセーブ形式にも存在するので、わりと有名なんじゃないだろうか。
さて、これについての大きな問題は、書き込み内容に、区切り記号と同じものが存在した場合である。
上記の例で、「あ、、、」というタイトルを使ったとすると、
はしもと、hasimoto@ash.or.jp、http://ash.or.jp/~hasimoto/、あ、、、、今日は大変なことがあったなぁ、19990531
などというデータが保存されることになる。これを「、」を区切り記号に読み込むと、「あ、、、」の部分の「、」のせいで、内容や日付のデータがきちんと取り出せなくなってしまうのだ。
もちろん、csvにしたところで同じである。コンマが使われたら狂ってしまうのだ。
長くなってきたので次回に続く
＊せぱれいてっどばりゅー、その２ 1999/6/1 <=
つづきなのだ。
さて、では、解決策はあるのだろうか？
１、区切り記号を使わない。
区切り記号に問題があるなら使わなければいい。この場合の方法には、「データを固定長にしてしまう」「データを全て別ファイルに保存する」などがあるが、ファイルがたくさんできたり、無駄なデータ領域ができたりする。それに、データを処理するにも、なにかと使いにくい。
まあ、用途によってはこちらの方がいい場合もあるけどね。
２、書き込み内の区切り記号を別のものに置き換える。
たとえば、書き込み内のコンマを、全て全角コンマに変換してしまえば、半角コンマで区切っても問題はなくなるわけである。
ただし、元の書き込み内容が変化してしまうという欠点は大きい。
とりあえず、コンマを何か別のものにしておいて、後で元に戻すということも可能ではあるが、その「別のもの」を何にするかという問題があって、根本的な解決にはならない。
３、普通は使わない記号を区切り記号にする。
とりあえず、私のおすすめはこれである。
タブ記号などを使ったりすることもあるが、コピー＆ペーストでタブ記号を書けてしまうので、やはり問題はある。
普通には使わないメタ記号などを使うのも手だが、扱いが何かと面倒になってしまう。
で、私は、出力がＨＴＭＬであることを生かして、タグを使うのがいいと思う。
どうせ、<＊＊＊>などと書いても表示はされないのだ。だったら、誰かがそういう内容の書き込みをするということはありえないし、そういう書き込みを制限しても問題はない。短い方がいいのだから、<>、などというのはどうだろうか？
書き込み内に<>なんてものがあっても、「禁止タグがあるので書き込めません」といって書き込ませなければ問題はない。
なにせ、<>というものを表示させたかったら<>と書くしかないのだ。見えないものをわざわざ書き込みたがるひとはいないはずだろう？
まあ、あくまでも私のおすすめなので、実際にはどういうふうにしようと問題はないのだけど・・・
さて、実は、前回の例のように、書き込みごとの区切りとして、改行コードも使っているのだが。これはどうなっているのだろう？ 書き込みの中にも改行はあるし・・・？
これについては、改行コードというものの話になるので、また今度。
補足 1999/6/1 <=
ちょっと誤解があるかもしれない、
ユーザさんが、つまり、書き込みをするひとが、コンマやタブを使えないというのは、結局望ましいことじゃないのだ。ユーザ側は、思うままに好きなように書き込みができるべきだと思う。
だから、掲示板を作ろうと（設置しようと、ではなく）思うなら、配慮しなければならないだろう。という話なのである。
普通、掲示板に書き込みするときには、そんなことを気にする必要はまるでない。
というか、ちょっとかっこつけた言い方をすれば、
「書き込みするひとにそんな気遣いをさせないようにするために、製作者はがんばらねばならない」
のだ。
素人のくせにえらそうだな。
改行コードのはなし 1999/6/4 <=
をするには、文字コードの話をしとかなきゃいけない。
で、それには、バイトがどーこーって話も必要だったりもする。
基本的に、こーゆー文字ってゆーのは、１バイト文字と２バイト文字があるってゆーのは聞いたことがあるとこだろうけど。
だいたい、半角文字が１バイトで、全角文字が２バイトだと思ってもらっていいだろう。１バイトってゆーのは、８ビットのことで、１６進数で言えば２桁ぶん。０から２５５までだ。
で、まあ、その最初の方は、文字じゃなくて特殊な役割を割り当てられていて、その中に、タブとか改行とかがあるのだ。
で、改行コードには、
0A：Newline（\nと書かれることが多い）
0D：Return（\rと書かれることが多い）
があって、ＯＳによって一般的な改行コードが違うのだ。
Windowsでは\r\nの２バイトぶんで、改行１つ、
Unixでは、\nで改行して、
Macintoshでは、\rで改行する。
Webで何かするときには、これらを気にした方がいい。
ダウンロードしたHTMLファイルをメモ帳で開いたら、改行しないで、ずーっと右に行っちゃった経験があるひともいるかと思う。それは、UNIXでは\nだけで改行していたのだが、メモ帳ではそれを改行だと認識できなかったというわけだ。
一般的に、FTPソフトにはＡモード、Ｂモードってゆーのがある。それはアスキーモードとバイナリモードで、Ａモードだと、改行コードを変換してくれたりするものなのだ。
で、ＣＧＩでどうなるかっていうと・・・
また次回に書きます。
改行コードとＣＧＩのはなし 1999/6/4 <=
で、Webページだと、ユーザがMACでもWINでもUNIXでも、ちゃんと動くように作らなきゃいけない。
フォームから送信されてくるデータは、それぞれのOSに準じた改行コードになっている。これをそのまんまにしておくと、なにかと都合が悪い。
データは改行コードでくぎったりするし、表示だってうまくいかないことがある。
で、大体の場合は、改行コードをまず統一して、しかる後にBRタグとかに置換してやることになる。
具体的には、「\r\n」を「\n」に置換して、それから、「\n」を「\r」に置換する、などである。これによって、改行コードは（この例だと\rに）統一される。
このようにして、いろいろな改行コードを知り、それに対応するべきだよ、というお話。
ちなみに私は書き込みデータの改行コードは\rに統一してデータを保存している。
CGI（perl@Linux）は、データの区切りを改行コードで行うのが簡単なので、１回分のデータは、改行コードで区切っている（以前書いた例のように）。んで、\rはCGIから見ると改行コードではないので、書き込みデータ内に\rがあっても１回分のデータをちゃんと区切る事ができる。
まあ、BRタグなどに変換してしまってもいいのだが、データをフォームに呼び出して修正、とかするときに、BRがあると邪魔だったりする。その点\rは「ブラウザから見れば」改行コードなので（MACユーザーに対応するためだ）、フォームにいれるとかPREタグで囲むとかすれば、きっちり改行されるし、そのデータを再びCGIに送っても当然問題無く動作する。
まあ、DLしてWindows上でどうこう、というときには扱いにくいのは確かだけどね。
javascriptのちょっといい話（？） 1999/6/12 <=
javascriptのプログラムを作っているとき、当然最初からきっちりとしたプログラムが作れるなんてことはまずない。それは、ｃだろーがperlだろーがjavaだろーが同じことで、どんなに優れたひとでも、ミスはするし、勘違いとかもある。
で、ねすけ4.06以上（あまり自信ないけど、最近のねすけ）でjavascriptのエラーを発生させると、どんなエラーが出たのか教えてくれない。
それは、以前にも書いたとおり。
で、最近ようやく、エラーの詳細を表示させる方法がわかった。
エラーのときに、
JavaScript error: Type 'javascript:' into Location for details
というメッセージが出てくる。
これの後半を訳すと、「詳細のためには、Locationの中に「javascript」とタイプしろ」ってな意味になる。さて、Locationとは何か？ それは日本語版だと「場所：」と書いてある、ＵＲＬを書き込んだりする場所のことなのだ。
今ねすけ4.08en（すたんどあろーん英語版）を使ってるんだけど、それだとしっかり「location」って書いてあって、初めてそれだと気付いた。「訳すならこーゆーメッセージもちゃんと訳してくれよう」って気分。
で、そこに、「javascript」と書くのだが、普通に書くと「http://javascript/」を探しに行ってエラーになる。メッセージをよーーーーーーく見るとわかるのだが、javascriptの後に、コロンがついてるのだ。tと'の間に:書かれても見にくいってばよ。
まあ、ともかく、「javascript:」と書いてやれば、エラー内容が表示されて一件落着。
しっかりしろよねっとすけーぷ、そして俺。
JavaScriptでくっきーな話、近況 1999/6/23 <=
某マルチメディア研究会向けコンテンツとして、JavaScriptでcookie処理するスクリプトの解説文を書いたりしました。
まだ某マルチメディア研究会さんのページでは公開されてないけど、なんとここで先行公開（笑）
すたいるしーと対応ぶらうざで見ていただきたいところです。
これが解説文
ちょっと改定されたサンプル
まじめに（？）プログラム解説なんて書いたのひさしぶりだ。
なお、これを読んで、某マルチメディア研究会ではなく、はしもと個人にお礼がしたくなった場合はメールなどでお問い合わせください（笑）
JavaScriptのあるいはいい話 1999/7/1 <=
ちょっとしたテクニックとも言う。
最近、CGIをいじる暇がない。だからといっていじってないわけじゃないのだけれど、このページで使ってるCGIもバージョンアップしたいし、掲示板だってつくりたい気がする。
だからというわけではないがJavaScriptのはなし。
少し前に、alert文でデバッグする話は書いたけど、JavaScriptでプログラムを組むとき、かなり頻繁に使われるのはsetInterval()ではないかと思う。まあ、ねすけ３とかＩＥ３のことを考えてsetTimeout()をループさせて使うとかもありだろうけど・・・
そんなプログラムにalert文を仕込むと、alertのOKボタンを押し続ける毎日が待っている。しかもその間ブラウザは他の処理を受け付けないので、ctrl+alt+delを押すはめになりかねない。
そんなあなたにちょっといいテクニックをお教えしよう（＜えらそう）
まあ、もしかして「そんなの常識じゃん」とか言われるかも知れないけど、まあ、もしかしたら誰かが喜ぶかもしれないので書く。
まず、適当にフォームを作り、テキストボックスを作る。このとき、他のフォームの邪魔にならないように、bodyの最後とかに書くのがいいかな？まあ、どっちにしても画面に入るところにテキストボックスを作る。そしたら、
document.forms[0].texbox.value = '変数='+ val;
とか書いて、フォームにデータを出力しちゃうのだ。（この場合、いっこめのフォームのtextboxって名前のフィールドを指定している）これなら処理が止まらないから、リアルタイムに変数をモニターできる。しかも、いかにもプログラムが計算していますって感じで、なんかかっこいいぞ（笑）一度おためしあれ。
別のウィンドウ開けて書くのもありだけど、スクリプト書くの面倒だしね。
CGIのミスをした 1999/7/17 <=
久しぶりにゲーム系雑記書いて、チェックしないでおいたら、なんかミスってどらくえ３にっきの方に更新されてしまっていた。それを見たひとがいたら、まあ忘れておいていただけると幸いである。
これは、更新用データファイル（どこのファイルをどのように書き換えるかなどを記述したテキストファイル）の指定を間違えてしまっていたためだ。一応どこを更新したかの確認画面は出ているのだが、そんなもの見ちゃいなかった（笑） 普段は更新後にページの確認もしてるのに、たまたま昨日に限ってやってなかったという・・・
どんなシステムも、運用側がミスをするとどうしようもないということを、改めて思い知ることになった。
運用ミスを無くすことは不可能かもしれないが、ミスを少なくする方法はあるし、ミスをした場合の被害を少なくする方法も存在する。確認画面の出力や、エラーメッセージの出力など、CGIを作ったりするときも注意しておくにこしたことはない。
自分が使うためのものだから、その辺で手を抜いた報いがきてしまったということか・・・ 要反省。
Webチャットのはなし 1999/8/2 <=
とりあえず、はなしはかわるけれど。
Webチャットはいいものだ。なんといってもプロトコルがhttpだから普通のhttpプロキシを通るし、クライアント側にもWebブラウザしか必要ない。
でも、遅い。
リクエストしたら１ページまるごと呼び出して再描画が基本だからだ。転送データも大きくなるし、表示処理にも時間がかかる。
そこで、画期的（？）なWebチャットを考えてみた。
サーバ側にメッセージを転送する処理は通常のWebチャットと同様だが、サーバからメッセージを転送する際には、現在確保しているメッセージ番号をリクエストし、その差分を転送してもらうのだ。差分をテキストエリアに書き込んだ形の最低限なhtmlファイルで転送してもらったら、その内容をJavaScriptで処理して、ダイナミックhtmlを利用して差分の追加表示を行うのだ。
これによって、クライアント側で１ページまるごと書き換えを行わなくなり、それだけでもストレスは減るし、転送データも小さくなるので回線負荷も減少するはずだ。また、回線負荷が減り、再描画も行わないのだから、リクエスト頻度を現状のWebチャットより高くしても問題はないはずだ。
試しに作ってみたいとは思ってるのだが。最近CGIで遊ぶ暇がない・・・
掲示板の機能とかについて 1999/9/14 <=
考える機会があったので、少し考えてみた。
どのような機能も、悪用するひとがいれば、その機能は本来の意味通りには受け入れられない。
掲示板あらしを防ぐための機能を使って、自分の気に入らない反対意見を封じ込めたり、
自分の書き込み内容を削除や修正する機能を使って、他者間の対立を誘ったり、
そういうものを目の当たりにしたら、そういう機能そのものを悪だと判断することも有り得る。
原爆の被害にあったひとが、原子力を否定しようとするのと似ているかもしれない。
まあ、原子力と比べるにはあまりにもスケールの小さい話ではあるのだが、話がこじれてしまったあげくに、とある掲示板の不使用運動がおこったり、誰かをネットワークから追放しようという話になったりもする。
よく言われる言葉に「技術はあくまでも技術でそれ事体に善悪はない」というものがある。私はこの言葉は全面的に正しいと思っている。実際のところ善悪というのは主観的なものなので、「それ自体の善悪を論じることに意味はない」と言い換えてもいいだろう。
しかし、「技術」そのものについてだけ論じることは、実はかなり難しい。どのような技術にも、それを開発したり使用したりするに際してひとの意志が加わってくる。
また原子爆弾を例にするが、原子爆弾そのものには善悪はないが、それを作ったひと、それを使うことを決めたひと、実際にそれを使ったひと、と、様々なひとの意志が存在し、それに対しては善悪を論じるべき意味がある。
だから「技術」に関わる者は、その「技術」の持つ意味をきちんと考えていかねばならないと思う。
えらく話がでかくなった気がする・・・
同様に、掲示板などに機能をつける場合でも、その機能が意味するところを考えるべきである。安易につけられた機能は、思わぬリスクを生むことにもなるのだ。
本来は意味が違うが、わかりやすいのでタグの話を例にしてみよう。
タグの使用が可能な掲示板を作ったとしよう。
それに対して、「タグを悪用する掲示板荒らしが現れたのでタグを禁止してくれ」という意見が出てくる。
だからタグを禁止するようにすると、「タグが使用できないのは嫌だ」という意見もでてくる。
じゃあ、タグの使用、不使用を管理者が選択できるようにしようとすると。タグ許可という機能を悪用されてタグ許可を悪だと思っているひとから「タグなどという機能は完全に抹消するべきだ」と言われたりする。
まあ、これがタグの許可不許可という話だから、わりと「なんじゃそりゃ（笑）」って感じだが、これが、書き込み拒否機能だったりすると、コトはかなり深刻になる。
悪意を持った管理者の情報操作なんかに利用できてしまう危険があったりするのだ。
普通、管理者は一般ユーザが不快な気持ちにならないようにするものである。拒否機能だって、本来はそのためにつけられたものだ。しかし、管理者側がそれを悪用しようとすると、際限無く悪用できてしまう。そんな機能を実装していると本来はそんなことをしなかったはずのひとまで、ついついそういう悪事をやってしまうかもしれない。
「だからその機能を外せ」
で、実際問題、かなりひどいユーザというものが存在する。積極的に掲示板をつぶすために行動していることだってある。書き込み内容（特殊なタグなど）で識別できるならそれを禁止してしまえばいいが、そうではない場合も多い。そうなると、特定IPからの書き込みの拒否や、パスワードによる認証といった方法が必要になる。
「だからその機能は必要だ」
まあ、こういう話は、実際のところどちらも正しいことなので、どちらかが勝利して終わるということにはならない。大抵は、より攻撃的な方が攻撃をし、先に根負けした方が逃げ出して終わる。
実に不毛だ。
私的に言えば、作る側が機能をもりこむことは正しいことだ。利用者により広い選択の幅を与えることは、ある意味では製作者の義務でもある。それを求める者がいるのなら、その機能を提供するべきである。もちろん、その機能の意味を考えるのは当然のことだが。
一番悪いのは誰か、そんなのは決まっている。機能を悪用した者だ。
いわゆる掲示板荒らしも、ユーザがメッセージを伝え合うという掲示板の機能の悪用に他ならない。
悪用するようなひとがいるから、製作者は余計な手間をかけてセキュリティなどを考えなければいけなくなる。管理者はセキュリティその他の設定が必要になる。ユーザは掲示板を利用するときに余分な手間がかかる。そして、悪用されたことのある者は、機能の悪用に対して過敏になる。
掲示板荒らしに荒らされたひとが、セキュリティについて過敏になるのも、拒否機能や削除機能を悪用されたひとがそれらの機能に過敏になるのも、結局、悪用する奴がいるからだ。
でも悪用しちゃうひとはいなくならない。だからスクリプトをフリーで公開したりすると問題は必ず発生する。
掲示板荒らしを排除することばかりに目が行っているひとも、その機能の悪用ばかりに目が行っているひともいる。スクリプトを公開したりするなら、その機能に対して、誰よりも冷静で理性的で理論的であるべきだ。
冷静さを失うと、物事の一方向しか見えなくなる。そんな状態では、機能についてのちゃんとした考えも持てなくなる。
・・・
うーん、掲示板公開するのって大変そうだなぁ・・・
やっぱし、みんな自分で作るのがいいよ（笑）
はしもと９９改良計画 1999/11/11 <=
このページをＣＧＩで更新しているのはみなさんご存知の通り。
今回もまた改良して、ＣＧＩもずいぶんと増築された。最初はそれなりに見やすいプログラムだったのだが、そのころは予想していなかった改造の結果として、おそらく私自身にしか理解できないものとなっている。
ＣＧＩに限ったことでなく、プログラムを書くときには、見やすいプログラムを書くことを心がけるべきだろう。
「自分で使うんだからいいや」
などと思って適当に増改築を繰り返すと、そのときはまだしも、少し時間がたってから修正するときなどに苦労するし、思わぬエラーに襲われて、結局最初から作り直す方が早いなんてことにもなりかねない。
タブの使い方や、サブルーチン名や変数名の命名規則など、それなりのルールをもって作るべきだ。
ちなみに、それらをメモしておくことも重要だ。より便利な方法に変えたりするかもしれないし。
現在私の使っている更新用ＣＧＩは、Webで公開したりするつもりはない。変な使い方をすると、サーバに大きな危険を招きかねない部分があるからだ。
ちなみに何が危険かは秘密である。
メモ帳とかのはなし 2000/1/14 <=
CGIなんかで作ったデータをダウンロードしてきて、Win上で修正したりすることがある。だいたいにおいてそんなファイルは全部テキストファイルなんだから、テキストエディタで書き換えたりするわけなのだが、そんなときに、ちょっと気を付けなきゃいけないことがある。
ってゆーか、自分が失敗したって話なんだけど・・・
文字コードや改行コードがいろいろ異なってくるって話はこれまでにもちょっと書いたけど、普通、Winのテキストエディタは変なコードを認識できないものである。でも、テキストエディタによっては、Winとは違う改行コードでもちゃんと認識してくれたり、変なコードを?マークで表したりしてくれるものがある。
で、その状態でコピーしたりセーブしたりいろいろしたりすると、Win上での表示が正しくなる代わりに、CGIのデータとしては壊れてしまったりすることになる。
もちろん、ちゃんと理解したうえで気を付けていれば大丈夫なのだが、私のようないいかげんな人間は、ついつい適当に書き換えて適当にセーブしたりしてえらい目にあう。
ちなみにWin95のメモ帳は、どんなわけのわからないコードを入れてもそれはそれとして表示してくれるので、見にくいのは確かだがその（ちゃんと文字になってない）コードをそのままコピー＆ペーストしたりもできて便利かもしれないなぁ。と思った。
Win的にちゃんとしてないテキストを読み込んだときにエディタがどんな処理をするかってのは、わりと重要なことかもしれない。もし、CGIデータを修正したりするときは、みなさんも気を付けよう。
教訓（役に立たない） 2000/1/14 <=
ここでも以前書いたが、CGIなどを改造するときは、どのような改造をしたかを明確にし、それを自分でわかるようにメモするなどし、最新のデータがどれであるかもきちんとルールを作っておくべきだ。
それを怠ると、今、私が苦労してるみたいに、CGIのソースをおっかけて、以前直したはずのバグをもう１度直すなんていうくだらない事をするはめになる。
また、修正するときにはバックアップをとり、動作確認がきっちりとれるまでは保存するべきだとも言っておこう。
CVSなんかのバージョン管理ツールなどを使えばいいのかもしれないけど、個人でそのようなものを使うのはかえって大変だし、WinとLinuxの両方で作業をする場合にはそういうツールも使いにくいだろう。
きっちりと自分なりのルールを作り、それを守ることが重要なのだ。
理屈じゃわかってるんだけどなぁ・・・
かいせつとか 2000/1/22 <=
ひさしぶりに、CGIの解説なんかをやったりした。
ちなみに、例によってASHさんでアップしてるので、まあ、興味のある方は見てみてもいいかもしれない。
ちなみにその解説自体はここです。
去年の正月用におととし作ったCGIの解説だってんだから笑える。でも、perlのスクリプトのちゃんとした解説したページを作ったのは初めてかもしれない。ま、どこがどういうふうに『ちゃんとしてる』かは不明だし、ほんとうに『ちゃんとした』解説なのかは、見たひとが判断するしかないんだろうとは思うけど。
HDML 2000/2/25 <=
Handheld Device Markup Language とかいうものだ。
携帯端末で使用するために開発されたマークアップランゲージで、cdmaOneなんかで使われてるEZwebで採用されている。よーするに、cdmaOneの端末にはHDMLブラウザが装備されてて、この言語で書かれているWebページを表示するというわけだ。
ちなみに、現在HDMLのバージョンは3.0、バージョン2.0の仕様はW3Cにも提出されてたりする。
なんといっても現在のところ資料が少ない。HTMLにちょっと似てるけどかなり違ってたりもする。
で、一応httpで送れるのだが、ヘッダはtext/x-hdmlでなきゃいけないので、ユーザがHDMLのページを公開するためにはWebサーバ側の設定が必要だったりもする。
仕様的にはいろいろ考えて作られてて面白いのだけど、現状ではなかなか難しいとこかもしれないなぁ。
対抗馬のimodeは、通常のHTMLとほぼ同じものを使ってるから、とってもとっつきやすいからねぇ・・・
ま、私が携帯買うことはないんだろうけどね。
HDMLのこと 2000/2/25 <=
そーいえば、CGIで出力する場合は、サーバ側に特別な設定は必要ないと思う。
CGIの場合、HTMLを出力する場合でもContent-type: text/htmlの出力が必須なわけだから、そこで、Content-type: text/x-hdmlなどと書いてやればいいというわけだ。
ちなみに、HDML対応端末は独自の環境変数を出力してるから、それをチェックして分岐してHTMLとHDMLをそれぞれ出力するようにすれば、同じURLでi-modeとcdmaOneの両方から見れるようにする。なんてことも可能なんじゃないかと思う。最近流行の携帯端末による予約ページなんかを作る場合には有効かもしれない。
ちなみに、このページを携帯から見れるようにしてみようか。などと思わないでもなかったが、そこまでしてチェックするような内容でもないからやめにした。
ま、最大の理由は面倒だからだけど。
この馬鹿弟子がぁ！（意味不明） 2000/11/2 <=
いや、たぶん、弟子の方ができがいいんじゃないかと思わなくもなかったりするが、まあ、とりあえず、弟子のはなし。
なんと、この私には弟子がいるのだ。知り合いがCGIでゲームを作るってんで、2人ばかしにCGIとかを教えたりしたってだけなのだが、まあ、一応弟子という設定になっている。
その弟子が、突然電話をかけてきて、プログラムがうまく動かないから見てくれないか？ ってな話をしてきた。
師匠を呼び出すとはいい度胸だ。などと心の中でつぶやきつつ、救援に向かった。
ずいぶんとでかいプログラムのどこかにミスがあることはわかっているのだが、どこにどんなミスがあるのかわからない状態。たぶんどこかで無限ループになっているだろうことは推測できるが・・・
他人の作ったプログラムのデバッグは至難である。だから、結局自分でやってもらうことにした。
CGIとして動かす以上、プログラムが途中で止まってしまっては何の出力もできない。だから、テキストファイルにメッセージログを出力してデバッグ用情報を得るとか、いろいろそういうことをして、なんとか修正は完了した。
プログラムって、作るよりも直す方が難しいってところがあるような気がする。
CSVとMSEXCELのちょっとアレな関係 2000/11/26 <=
データベースで検索したデータをCGIからCSV出力するっていう作業があって、ちょっとそれについて調べていたのだけれど、なかなかバカっぽいはなしが発見された。
本当は出力時のcontent-typeに、『text/csv』とか書いてやれればいい感じなのだが、どーやらそれやっても基本的には無駄。なんせ、クライアント側がそれを解釈できない。
ちなみに、content-typeに『application/vnd.ms-excel』とか書いてやれば、excelを起動してやることはできる。そうやっておいて、テキストを書き出してやると、IEの場合はそこでEXCELが立ち上がってくる。
が、しかし、どーやらそれをCSVだとは思ってくれないらしい。
『あ,い,う,え,お』
とか出力しても、それがそのまま１つのセルに入っちゃったりするのだ。
で、ふと思い立って、URL欄に『〜/csv.cgi』と書くのではなく『〜/csv.cgi?.csv』などとおざなりに書いたりすると、なんとそれがCSVとして認識されるのだ。どーやら、基本的に拡張子を見ているようで、『〜/csv.cgi?.csv』って書くと、『csv.cgi?.csv』ってファイル名だと判断してくれるらしい。
なんか、バカっぽい。
ちなみに、コンマ区切りじゃなくて、タブ区切りにすると、素直にEXCELがデータを取り込んでくれた。
うーむ、そんなもんなのか？
続・CSVとMSEXCELのちょっとアレな関係 2000/12/1 <=
その後にも、ちょこちょこと調べた。
『〜/csv.cgi?.csv』とか書くだけでなく『〜/csv.cgi/filename.csv』などと書いてやることもできる。IEで開くと、ちゃんとだまくらかしてCSVとして開いてくれる。
で、どうしようかと考えなくもなかったのだが、クライアントがみんなマイクロソフトな環境だってわけでもないだろう。結局CSVファイルをファイルとして保存してもらうことにした。
Content-type: application/octet-stream
Content-Disposition: filename="filename.csv"
なんて感じでヘッダを出力して、こっちの指定する（.csvな）ファイル名で保存してもらう。そーすれば、その後で保存したデータをどうしようと、そのひとの勝手というわけだ。
たぶん、マイクロソフトな環境なら、ダブルクリック（あるいはシングルクリックかもしれないが）してやればMS-EXCELが立ち上がってきてくれることだろう。
でも、データベースアクセスはEUCでやってるのに、CSV出力はS-JISにしてやんないとEXCELじゃ文字化けしちゃうんだよなー・・・
らびりす 2000/12/17 <=
かなり意味不明だが、以前ちょっと話題にした弟子が作ってるゲームのタイトルだ。
これが、最近公開されて、なかなかに盛況なようである。
だがしかし、まだちょっとトラブルかかえてるっぽいから、ここではあえてURLを書かないことにする。安心しておすすめできるようになったら、たぶんあらためて紹介することになるんじゃないかな？
Labyrith 2000/12/19 <=
19世紀初頭、近代ヨーロッパ。魔法と幻想は去り、理性と文明が世界の闇を切り開く、そんな時代・・・。
発掘された地底都市は《冥界》へと続く道だった。次々と蘇生する死人の群れ、押し寄せる神話の怪物。
冥界の門を塞ぎ、再び魔法と幻想を否定するべく、人は戦いの地へと赴く。
てなわけで（どんなわけか？）一応大バグも直ったと思うので、URLを公開しよう。
http://cas.ash.or.jp/labyrith/
である。
なかなか面白いと思うので、気が向いたらぜひ。
ちなみに大バグってのは・・・
うう、師匠の私がロック処理についてきちんと教えなかったばっかりに・・・
たれながし 2000/12/22 <=
CGIをインターフェイスにして、サーバの作業を行ったりする。
そんなことはわりとよくあったりするのだが、その作業に時間がかかるとちょっと困る。なんせ、ブラウザは何も表示してくれないままに、数秒、あるいは数分もの時間を待たされることになる。これはかなり不安だ。
で、そんなときにやるといいかもしれないこと。
CGIのPerlスクリプトの中で、特殊変数$|に0以外を代入しておくのだ。
するってーと、出力がだらだらとたれながされることになる。
参考までに、実験に使ったスクリプトはこんな感じ。
ただし、ネットワーク越しに動作させるとどういう挙動をするのかは試していない。
それでもかまわないなら動作するものもある。
最後まで行ったら、次のページへのリンクを出力してみるのもいいし、JavaScriptのonloadイベントで何かするっていう手もある。
不安な待ち時間を過ごしている方は、試してみてもいいかもしれない。
ぴんぐ 2001/1/12 <=
pingではなく、pngのこと。
gifの後継として今一番有力な画像フォーマットだ。
なにせ、gifは、圧縮方式（LZW圧縮）の特許を持ってる米Unisys社が、突然金を払えと言い出して、一般的なフリーソフトなどでは圧縮展開が行えなくなってしまった。
いや、厳密には、米Unisys社と契約してお金を払えばOKなのだが、そんなものを払ってなおフリーソフトを公開するなんてことは、現実的ではない。ま、マイクロソフトとかアドビとか、そーゆーでっかいとこは当然のように正式に契約してるので、それらの大企業が提供するフリーソフトなんかは、問題ないっていえば問題ないんだけど・・・
なんせ、正式契約されてないソフトで製作されたGIF画像をWebページで使用しているだけで米Unisys社に金を払わねばならない。
気が向いたなら調べてみるといい。なかなか腹の立つ話だから。あと、GIFを扱うフリーソフトなんかを使ってる方は、ぜひ一度調べておくべきだろう。
昨日も言ったが、世の中は権利と利害で（以下略）
その点、PNGはそこらへんの権利や利害から自由でいられる。これだけをとってみてもすばらしい。だから、GIFの騒動でGIFに嫌気がさしたひとたちは、つぎつぎとGIFからPNGへと画像フォーマットを変更している。
私としても、PNGにのりかえちゃったりしようかなぁ・・・ と考えなくもなかったが、現状ではブラウザの対応もまだ完全とは言えないし、アニメーションPNGがない（それに極めて近いものはフォーマットとして存在するが、現状ではブラウザがほとんど対応していない）ってのも個人的にはちょっと・・・
ちなみに、
「おまえがページを運用するのに、画像なんて必要なのか？」
とかいう質問には答えないことにしておきます。
寝or死 2001/1/24 <=
Perlのバカ話。
sleep or die
上記の文は、『眠れさもなければ死ね』ってなことになる。まあ、『死にたくなければ眠れ』ってな訳をされるような文章だろうか？
この文章をPerl（perl5）インタープリタに渡してやる。-cwのオプションをつけて実行すると、ちゃんと『syntax OK』と表示される。これは『正しい』Perlスクリプトなのだ。
ちなみに、これを普通に実行すると、殺されることを恐れたPerlは永遠に眠ってしまうのだが・・・
同様なネタとしては、
chop or die
なんてのもある。ちなみにこれを実行すると、Perlはチョップできなくて死んでしまう。
もちろん、プログラムとして何か意味があるかというと、何の意味もないのだけれど・・・
続・Labyrith 2001/2/9 <=
以前紹介したラビリスだが、順調にバージョンアップも進み、プレイヤー数も順調に増え、それはそれでけっこー大変な状態だ。
で、多少なりともマシな環境を求めて引越しをおこなった。
引越し先はこちらだ。
マシンスペックもけっこー上がったし、回線も悪くないと思う。
うーむ・・・ なんか、すっげーたくさんひといる・・・
私の弟子たちもがんばっているなぁ・・・
いや、既に元弟子と言うべきかもしれない・・・
JavaScriptとcookieのこと 2001/2/25 <=
えらく昔に書いたモノは、今見るとかなり情けないモノであることがある。
2年前に、いろいろ資料見ながらなんとかかんとか書いたプログラムソースがある。それを今見てみたらかなり嫌な気持ちになった。
てなわけで、
改訂版なんてモノを書いたりした。
これってASHさんのページ用に書いたものだから、リンク先なんかはASHさんのページになる。どーでもいいって言えばどーでもいいことだが。
ひとは成長するものだ。それがたとえ私のような者であっても、成長はするのだなぁ。
いや、まあ、自分で成長したと思いこんでいるだけなのかもしれないが。
先読まれ 2001/5/23 <=
CGIプログラムで、GETメソッドを使うことは結構多い。
ごく普通のAタグからCGIにパラメータを渡すことができるので、何かと便利であることには違いない。
が、実はちょっとした落とし穴があることがわかった。
例えば、
<a href="aaaaa.cgi?bbb=ccc">あいうえお</a>
みたいな感じでHTMLに書いてやったとする。すると当然このリンクをクリックしたときにCGIが動作することになる。
が、世の中には、リンクを先読みで辿ってキャッシュしておくことでWebブラウジングの高速化をはかるアプリケーションなんてものが存在する。
リンク先のCGIがサーバ側で特殊な処理を行うものだったりすると、先読みアプリのアクセスによってそれが動作してしまうのだ。
ちなみに、今回私がどーだったかというと、
<a href="logout.cgi?id=xxxxx">ログアウト</a>
って感じのリンクを、メニューの最下段に出力していた。
ちなみにlogout.cgiは、ユーザのログイン情報文字列を受け取って、サーバにあるデータファイルから当該ユーザのログイン情報を削除する。
で、先読みアプリが、勝手にログアウトしてしまい。ユーザがメニューを選んでも既にログアウト後になってしまっている。といわけだ。
結局、ログアウトはリンクではなく、フォームのボタンで行うことにした。先読みアプリはボタンを押したりはしないからだ。
まあ、あんまし影響がないことも多いけど、こーゆートラブルが発生することもある。
覚えておいても損はないんじゃないかな？
CSVと窓様 2001/7/28 <=
以前にも何度か話題にしたCSVファイルなんかをCGIからダウンロードさせたりする話。
なんかいろいろ問題が発生したりとかなんとかで、ちょいと再調査したりした。
Content-type: application/octet-stream
と書いてやればまあ、だいたいの場合はうまく動いてくれるのだが、.CSVが窓様に登録されてなかったりすると、おもむろにブラウザで開いてくれたりする。
どーやら、
Content-type: application/octet-stream
に対して、IE（窓様）は『正体不明のバイナリデータ』をファイルにセーブしないで、拡張子などの情報から勝手にその正体をさぐろうとする？ ように見える。もしかしたらファイル内容とかも調べてるかもしれない。
てなわけで、クライアントの環境によっては、想定される動作をしてくれないのだ。
こいつはちょっと問題だ。
で、結局、IE（窓様）が知らないContent-Typeを与えてやれば、ちゃんとセーブしようとしてくれるらしい。
とりあえずCSVの場合だったら、apprication/x-csvとか、text/x-csvとか書いておくのが無難だろうか。
これで、トラブルは減るかもしれないが、なんとなく、納得できない気持ちは増えていく・・・
せつない話 2001/8/26 <=
センチメンタル某とは無関係です。念のため。
Web上で動作するシステムを開発するとしよう。まあ、基本的にはCGIやJAVAなんかを使うことになる。どのようなものを開発するかにもよるが、不特定の『誰か』の書いたものがそのままWeb上で公開されるってことはそんなに珍しくない。例えば、そこらにあるWeb掲示板なんかはほとんどそうだし、何らかのデータを登録してもらってそれを一覧表示したりとか、そーゆーものだってごく一般的なものだと思う。
ここで、ちょっと気を使うのは、あまり公開しておきたくないような単語。まあ、代表的なものでは猥褻な言葉とか差別用語とか、そーゆーモノについてだ。
個人のページならまだしも、会社だとか何だとかがからんでくると、やっぱしそーゆー言葉を登録できないようにしよう。ってことになる。
で、特定の単語リストにマッチする言葉は登録できないようにしたりするわけなのだが、当然、その単語リストを作らなければいけなくなってくる。
そのリストを作る作業が、どうにもせつない。
そのリストを仕事相手に送るのもせつなければ、そのリストを仕事相手から受け取るのもせつない。
プログラムに組み込むのもせつないし、そのリストについてあれこれ話し合うのもせつない。
これって『ひとを信じてない』ってことだよな。などと気づいちゃったりすると、これまたせつない。
なれ 2001/8/30 <=
最近、また弟子をとっている。
ちょっと嘘。
CGIを勉強したいというひとに、いろいろアドバイスしたりしてるのだが、まあ、実際のところ、弟子の弟子ってことになるように思う。
初心者である孫弟子と、それなりに経験をつんでいる弟子、あとは私自身。実は、プログラムを書くという一点で見れば、それほど大きな差はないように思う。
特に、ごくシンプルなCGIなんかだと、誰が書いても同じようなものになるわけだし。
ただ、ちょっと複雑なことをしようと考えたり、あるいは、バグなどのトラブルに遭遇したときには大きな差がうまれる。
まあ、つまり、経験ってのはそういうものなんだろうと思う。
いろいろ経験しておくと、いろいろと手を抜く方法を知ってることになって、いろいろと楽ができる。
手抜きをバカにしてはいけない。プログラムなんて、ほとんどの場合手を抜くために書かれるものなのだから。
もう戻れない 2001/9/6 <=
太陽の牙ダグラム。
いや、それは関係ないが。
最近、なにかとPerl5の機能を使うことが多い。
オブジェクト指向風インターフェイスだったり、リファレンスを使った配列の配列やハッシュのハッシュだったり、小さいとこではchomp()だったりする。
実際、使っているPerlのバージョン自体はずいぶん前から5以上だったのだが、モノがPerlだけに、特別新しい機能を使わなくてもあまり問題なくプログラムできてしまったりしたのだ。
とりあえず、必要になったのでいろいろと機能を使っていたら、あちこちで使えてしまって、気がつくとプログラムのそこかしこでそーゆー機能を使ってしまっていた。
まあ、それはそれでいいことなのかもしれないが、ソースはさらに理解不能になっていく・・・
2001年9月9日問題 2001/9/9 <=
今日は2001年9月9日。
こんな半端な日にどのような問題が発生するかと言うと、まあ、おそらくほとんど何も問題は発生しないだろう。
ちなみに、9月9日はどんな日なのかというと、1970年1月1日0時0分（日本時間なら9時0分だな）から、ちょうど1000000000秒が経過する日である。
プログラム言語でよく出てくる1970年1月1日からの秒数ってやつが、9桁から10桁に繰り上がるのだ。
これでどーなるかっていうと、まあ、大抵はどーにもなりゃしないのだが、もしかしたら、それが9桁であることを前提に作られちゃったシステムなんかで、思いもよらないバグが発生したりするかもしれないわけだ。
気になって『2001年9月9日問題』で検索してみたら、結構な数がヒットした。マイナーだと思ってたけど、案外メジャーなんだな・・・
ちなみに、実際にそれが発生するのは、日本時間で9月9日10時46分40秒である。
大半のひとにとって、何事もない一瞬でしかないんだろうな。
おお あいいいよ しんでしまうとはなにごとだ 2001/10/27 <=
JavaScriptで変な無限ループ含みのプログラムを書く。
もちろん、きちんと完成してたら問題はないのだが、モノは未完成なまま。
「これ動かしたら大変なことになるだろうなぁ・・・」
などと思いながらもついついIEにドラッグしてみたりする。
当然のようにフリーズしたIEを、とりあえず強制終了。
殺したんだから当然IEは死亡。予想を裏切った点としては、窓様を道連れにしたことだろうか。
そこで出た言葉が、
『あいいいはしんでしまった』
流れるように王様風台詞と共に再起動。
『IE』だと思えばまだマシだが、『あいいい』って名前もかなりいいかげんにつけた主人公の名前っぽくて好感が持てる。
かっきてき 2002/2/4 <=
ずいぶん前に思いついたチャットのネタだが、最近かろのりさんが作ってくれた。
私が面倒になって放置してあるネタを、彼が次々と実現してくれるってのは、個人的に悪くない状態だと思うのだが、どうだろうか？
ちょっと情けないかもしれないが・・・
onSubmit 2002/2/21 <=
JavaScriptのちょっといい話。
といっても大した話じゃない。
CGI等で何か処理をするとき、間違って送信ボタンを押しちゃうと困る。
そんなときformタグの中にonsubmitを追加するとよい。
trueを受け取れば送信するし、falseを受け取れば送信をキャンセルしてくれる。
簡単なとこだと、
<form action="xxxx.cgi" method="POST" onsubmit="return confirm('送信していいですか？');">
みたいな感じ。
データの更新処理や削除処理なんかのちょっと気をつけたい動作をするときには、ちょっとこれだけ追加しておくと、それだけでわりと安全度が増したりする。
クライアントも満足。
ついでに言えば、スクリプトが有効じゃなかったり、ブラウザが対応してなかったりしても、普通にフォームとしては動作してくれる点もよいところだ。
わりとよく使う手で、いまさら書くようなことでもないようにも思えるが、このページにはちょっとした備忘録的な部分もあるし、ま、いいんじゃないかな。
もしかしたら、たまたまこのページを見た誰かの役に立つかもしれないし。
HTMLメール 2002/4/19 <=
何も考えずにデフォルトでHTMLメールを送信するのは、メーラの機能としては最低のものだろうと思う。
また、相手がそれを受け取れるかどうかも気にせずにHTMLメールを出すひとも、まあ、あまり好きになる理由はない。
他には、様々なセキュリティホールの温床であり、最近はやっているウィルスやワームが、『多機能』で『親切』なメーラが勝手にHTML内部をあれこれしてくれる『素晴らしい』機能のおかげで全世界に広まり続けていることは言うまでもない。
てなわけで、HTMLメールは基本的に嫌いである。
が、どんな内容を、誰に、どのように、送るのか。
ということをちゃんと考えて使うなら、それはそれで使いこなして便利なモノではないかとも思う。
例えば、フォーム等をきちんと書いたHTMLメールを送信すれば、メール受信者の手間を減らしつつも、確実なCGIへのアクセスが可能となる。
『メールに書かれたURLのWebページにアクセスし、フォームにデータを書き写して送信ボタンを押す』といった手続きが『メール内の送信ボタンを押す』だけで実現できる。
入力ミス等の可能性も減るので、そういった面でも有用だ。
まあ、もちろん、相手がHTMLメールを受信可能である必要があるし、必ずしも全ての場合で有用ではない。が、状況によってはかなり便利かもしれない。
通常、ロクな使い方をされてない技術でも、それだけで嫌っちゃいけないんだなぁ、などと思ったり思わなかったり。
たんす 2002/6/13 <=
短いスクリプト、略して『短ス』
perlには、いろいろと独特のものがある。
で、正規表現、短絡演算子、特殊変数、など、そこらへんをいろいろうまく使うと、なんだか奇妙に短いプログラムが書けてしまう。
まあ、非常に理解しがたいソースになってしまうのだが、それでも短いスクリプトを書くのはなんとなく楽しくて好きだ。
今の私にできるありったけの技術を費やして、世界で1番スクリプトの短いWeb掲示板を目指してみるのも面白いだろうか？ などと思う。
今、あまり暇がないのだが、ちょっとやってみたい・・・
アプレット 2002/6/21 <=
アプレットはあまり好きではない。
昔からNetscapeを使っていた私としては、一時期アプレットがはやった時代に、Javaの起動でものすごく待たされた悪印象があったりする。
例によって、まあ、使いどころを間違えさえしなければ、いろいろとすばらしい可能性を秘めた技術であることは確かだ。
いや、確かだったというべきなんだろうか・・・？
SunとMicrosoftが仲良くできなかったせいで、いろんな意味であれこれとかげりのあるJava技術。
IEのJavaVMはバージョン古いままだし、IE6.0にはそもそもJavaVMのってないし・・・
プログラム言語としてのJavaは、すでにある程度の地位を獲得しているのだが、最大シェアを誇るブラウザがああである以上『アプレット』の未来はかなり暗い。
くだらない流行としてのアプレットはなくなって、本当に意味のあるアプレットが作られたりもしてるのにねぇ・・・
でも、今仕事で作ってるのはなぜがアプレット。私自身はJavaのコードを書いているわけではないが、動作環境のフォローがものすごく大変だったり。
この中途半端なところがなんだかとても素敵に嫌。
失敗することさえできれば 2002/6/26 <=
失敗することさえできれば、あとはどうにでもなるっ！
意味不明ではある。
だが、まあ、それがある部分では事実であったりするのだから面白い。
さて、プログラムを動かすとき、特に、ネットワーク関係で、どこの誰が使ってるかわからないようなプログラムを動かすとき。
一番困るのは、誤動作してるのにその原因が特定できないことである。
自分の環境では問題なく動作しているのに、自分以外の多くのひとの前では誤動作する。
原因を特定しようにも、その誤動作がおこらないのだから、調査もやっかいだ。
で、失敗した状況を調べ、必要ならそのときに使ったファイルなども送ってもらって、自分の環境でその誤動作を再現させる。
失敗することさえできれば、どこで失敗したか、どのように失敗しているか、などを調べるのはたやすいことで。原因さえわかってしまえば、修正することもそれほど難しくはないものだ。
とにかく、結構長期にわたって気にしていたトラブルがあって、なかなか原因がわからなかったのだが、最近やっと失敗することができた。
よかったよかった。
と、そういうはなし。
脱力 2002/8/3 <=
なんだか脱力する話。
JoeMasumuraと私の2人で、ほんのちょっとしたテストプログラムを作っていた。
これがうまくいかない。
JavaとPerlで同様の動作をするものを作って結果を一致させようとしているだけなのだが、
これがどーにもうまくいかない。
2人で悩む。
かなりの勢いで悩む。
あーでもないこーでもない。
で、結局、1バイト分のシフトが必要なのに、4ビットシフトしてた。というどーにもならないオチ。
1バイトは8ビット、もしかしたら小学生だって知っている。
原因がわかったとき、ものすごい脱力感に襲われた。
1人で1時間以上悩んでたりしたのだ。なんか、ダメすぎである。
あーあ・・・
あんぜん 2002/11/21 <=
何が安全で何が危険か。
よく言われることだが、結局、一番危険なのは人間である。
セキュリティの基本は、ひとを信じないことだ。
どんな他人が襲いかかってくるかわからない。
安全そうな顔をしていても、裏では何をしているかわかりはしない。
そして、自分を信じたりもしないことだ。
どんな強固なシステムを作っても、運用する人間が何かミスをすればそれで安全性は壊れてしまう。だから、運用する人間がちょっとくらいミスしても、それで即座に危険になったりしないようにする必要がある。
なかなか難しいことだ。
トップへ