トップページ | 利用規定
  FAQ・4

カレッヂ
カレッヂ



メールで受け取る内容が1文字しか書かれていません

古いバージョンのjcode.plを使っていませんか? jcode.plはどこに設置しても構いませんが、初心者の方は多くの場合指示の通り、 呼び出すプログラムと同じ場所に設置していると思います。 次のように設定した場合は、あなたが設置したjcode.plを読みこんでいません。 詳しく言うと、@INCに含まれるパスを順番に検索して、jcode.plを探しているのです。 この場合、バージョンを把握しておかないと、思わぬ障害が発生します。

#■日本語コード変換ライブラリ
require 'jcode.pl';

同じ場所にjcode.plが存在するなら、

#■日本語コード変換ライブラリ
require './jcode.pl';

と設定してください。この設定の仕方の違いを十分覚えてください。

J-Phone系のメールアドレスに届くメールの怪

フォームメールなどで、J-Phone 関西 ******@jp-k.ne.jp のメールアドレスに配信するようにフォームメールなどで設定した場合に、 届いたメールの返信が正常に行われないという事例があるようです。これはどこにそのCGIを設置したかにもよります。 関西以外のメールサーバでも同じシステムが使われていると思われ、 同様の症状が出るかと推測されますが、確認ができないのでわかりません。 該当するシステムの管理者に聞いたところ、原因は、配信されてくるメールのヘッダの中の、Return-Path: を返信先にしてしまうからのようです。 このヘッダはメールシステムが自動的につけるもので、実際の送信者をあらわすものですが、必ずしも返信先を示すものではありません。 返信先を示すのは、From: または Reply-To: だと思うのですが、このヘッダは全く見ずに、Return-Path: のアドレスに返信してしまうのです。 これは、J-Phone 関西による返答は、「Return-Path:で設定されたアドレスへ返送する仕様になっている」ということですので、 現実には返信を受けられない場合が少なくないと思われますし、現実に起きていますが、J-Phone 関西では、クレームを出しても、 システムの欠陥ではなく、単なる要望として受けたということになっているようです。大きい会社だと1人2人で疑問をぶつけても、 なかなか調査検討して対応してくれる可能性は低いですね。こちらの疑問が間違っていれば、その根拠を示してくれればいいのですが。 私もReturn-Path:の使い道?をよく知らないのですが、少なくとも返信先を指定するReply-To:を無視されるのはおかしくないのかな?と思ってます。 ということで、フォームメール等のCGIプログラムのトラブルではありませんので、念のために理由を添えてお知らせしておきます。 この件については、2000年4月21日現在の情報としてください。その後改善されるかどうかまでは情報を追いません。 なお、この件はH.M.Fox.Mulder氏からレポートや協力をいただき、 調査したものです。

追記:ライコスフリーメール宛てに設定しても似たような症状が起きます。例えば、ライコスフリーメール宛てに配信するように設定したフォームメールで、 例えばビッグローブのサーバ上に設置した場合に、そこから送信されるメールのFrom:ヘッダの送信者(すなわち返信先)に、自分のメールアドレスを記入しても、 到着メール一覧には、From:ではなくReturn-Path:のアドレスが表示されてしまうものです。この場合、ビッグローブのWWWサーバからの送信になり、 Return-Path:は記入者のメールアドレスにはなりません。しかしこちらの場合は、 返信はちゃんとFrom:になるようで、一覧時には記入者のメールアドレスが出ないので戸惑いますが、返信先はそのアドレスになるので、 返信のトラブルはないようです。ライコスの方にも質問したところ、症状は確認できたということで、アメリカ側と協力して、 引き続き調査検討するという積極的な回答を比較的早々に頂きましたので、今後に期待したいところです。

NPHって何?

ヘッダーが代行受信されないCGIプログラムを呼び出すための特別な手法があります。 これは、Non-Parsed Heder CGI と呼ばれ、大抵のサーバでは、nph-で始まるファイル名であるときに、 これが呼び出されます。これを利用するには、MIMEヘッダ print "Content-type: text/html\n\n"; の他に、 HTTPレスポンスヘッダ print "HTTP/1.0 200 OK\r\n"; を送信しないとエラーになります。 これで動作しないようなら、設置を予定しているサーバの管理者に、NPHに対応しているかどうか、 NPH-CGIを実行する方法などを問い合わせてみてください。なお、ビッグローブのwww2uサーバでは、 NPHには対応していないそうです(2000/5/15現在の情報)。

文字化けするが更新すると直る症状がある

サポート掲示板において情報をいただいた内容です。 これは特定の環境において発生するそうです。 以下、引用を含め書き直して掲載してあります。

Webサーバであるapache1.3.12とNetscape4系列との組み合わせで発生します。 原因はapache1.3.12からセキュリティ対策のため、サーバ側でcontent-typeをISO-8859-1にハードコーディング(固定値として)している部分があります。 つまり、HTTPレスポンス(30*,40*系)によっては、ISO-8859-1がcontent-typeとして付加されます。 そのような時に日本語が入っていると結果として文字化けすることになります。

さらにNetscape4系列はそのような場合、METAタグ等で文字コードを指定していても、直前のcharsetを引きずるというバグがあり、 そのため、apache1.3.12とNetscape1.3.12の組み合わせでこのような文字化けが発生します。

解決方法は、バグのあるブラウザを使わずにバージョンアップするのはもちろんですが、 サーバ側に設定の修正を求めるか(通常、WWWサーバでcharsetを正しくつけるのが本来の方法)、下記のような方法でご自身で対応することになります。

CGI等では、出力前に必ず記述してある

print "Content-type: text/html\n\n";

を次のように修正し、強制的に文字コードを指定してあげます。

print "Content-type: text/html; charset=Shift_JIS\n\n";

これらの問題はHTMLでも発生することがありますので、.htaccessファイルを置くことが出来る方は

AddType "text/html; charset=ISO-2022-JP" html

のような charsetの指定をできるだけするようにします。

*main::valとかいう文字が出る

プログラム実行中に下記のように表示が出る場合があります。 確実な原因というのは把握できていないのですが、jcode.plのバージョンによるものと、 サーバ環境によるものが考えられます。

*main::val
     sjis

前者の場合、かなり古いバージョンのjcode.plやv2.3は利用を避けてみてください。 当サイトのプログラムにはjcode.pl-v2.3を梱包しているものがあります。 これが直ちにこの原因になるわけではないのですが、設置する環境との相性か、現実問題として不具合が生じる場合が報告されました。 たとえば、jcode.pl-v2.13に替えたところ問題が無くなったという報告もあります。 参考までに、v2.0・v2.1・v2.3・v2.8では問題発生、v2.11・v2.13は問題なしというレポートをいただきました。

jcode.plを単純コード変換にしか当サイトのプログラムは使っていませんので、 (一部にv2系のコマンドを利用しているので、v1系は使わないでください) 新し過ぎても何か起きる可能性も否定できません。半角カナを全角に変換する処理があるプログラムについては、 少なくともv2.0以上のバージョンを使う必要があり、これは説明には書いてあると思います。 ダウンロードした中に不用意にも古いものが入っていた場合には、 お手数ですが別途ダウンロードをお願いします。

後者の場合、Perlはマルチスレッド機能が組み込まれている場合にjcode.plが使えなくなるそうです。 threads とはマルチスレッド機能のことで OS が pthreads(POSIXThreads) ライブラリを提供している場合組み込むことができます。 その場合は perl を make するまえに ./Configure -Dusethreads のように指定します。 つまり jperl のパッチとも関係なく、 -Dusethreads で作られた Perl では jcode.pl は使えません。 もし次のようにした場合に'define'と表示されたら、マルチスレッド機能が組み込まれていることになり、 jcode.plは使えませんので、サーバ管理者にthreadsを無効にして再組み込みしてもらう必要があります。

# perl -V:usethreads
usethreads='define';

ショッピングバスケットで商品が1個しか、または入らなくなった

プライバシーポリシーについてご覧ください。


Powered by CGI RESCUE(R)