東京から帰宅した当日。
メールを受信してみると、メールが文字化けするとの内容が。
普段、滅多に仕事のメールなんて来ないのに…
何故か「東京へ行く」と宣言した日に限ってメールが来る罠。
まさかとは思うけど「ワザと？」と思うようなタイミングです（苦笑
メールの文字化けとは穏やかじゃない。
業務に影響が出るからねぇ。
ただ…
東京から帰宅＝帰りの電車でビール なのでプログラムの変更は勘弁。
酔ってるという実感が無くても、
アルコールが入った状態でプログラムに手を出すと、大変な目に合うのは過去に経験済（苦笑
とりあえず、メーラが「Thunderbird」という事だけは判明。
本当なら、こういう仕事をしている以上、
色々なブラウザ、メーラで動作確認するべきなんだろうけど…
自分用のメイン機でもあるので、どうしてもインストールには慎重になります。
が、問題が出た以上は無視できない。
早速「Thunderbird」をインストール。
過去の注文メールを受信してみると… ガッツリ文字化けしてました。
まぁ、一言で言うと… 全角文字は全て判読不能。
≧∇≦ブハハハハハ もう、笑うしか無いね。
入れたばかりのソフトなので、いまいち機能を理解していないんだけど…
たまたま「表示＞メッセージのソース」「ファイル＞印刷」と進むと
文字化けしていない状態での印刷に成功。
お？ あっさり解決か？
その日は、その旨を報告して作業終了しました。
で、本日。
そのメールの返事が来て…
「受信者が全てパソコンに詳しい訳じゃないので、文字化けの方を直してくれ」との事。
(;´Д`) エー
とは思ったものの… そもそも根本的な解決方法じゃ無かったからね。
ようやく東京での疲れもとれたし、目の前の現実から逃げてちゃダメだ。
そんな訳で久し振りにCGIとニラメッコ。
ついでに、文字化けしたメールもプリントアウトしてニラメッコ。
このCGIなんだけど
かなり、オリジナルを加工しまくってるんだよねぇ。
例えば、今回問題になったショッピグカートも
オリジナル：
http://www.kent-web.com/cart/cart/cart.cgi
加工後：
https://sv93.xserver.jp/~xsvx3025898/izunet.jp/shop/_test/cgi/cart.cgi
データベース関連も
オリジナル：
http://www.kent-web.com/pubc/db/db.cgi
加工後：
http://www.izunet.jp/_cgi/estate/estate.cgi
まぁ、本音を言うと
内部的な処理は触らずに、デザインだけを変更したいんだけど
「あ～したい」「こ～したい」という要望を聞いてくと…
最終的には広範囲の変更が余儀無くされちゃいます。 orz
今回の件も、そうした流れが原因でした。
元々（オリジナル）は、メール本文の内容を変数に格納。
出力前にjcode convertで変数の中身をsjisからjisに変換していたんだけど…
銀行の口座番号だの、色々とメール内容に追加する文が増え
その後の行にある printで文字を追加する事に。
結果、文字化けが発生し、jcode convertをコメントアウトした経緯が。
今思えば…
追加した分も変数内に 変数名 .= "追加文章";
の方法で追加すれば良かったんだけどねぇ。
安易に直接printで吐き出させたものだから
変数内の本文がJIS（iso-2022-jp）
追加文章がS-JISになってしまい、
同じメール内で複数の文字コードが混在した結果、文字化けしたのでしょう。
それをよりによって、jcode convertの方を殺してしまったので、メール全体がS-JISに。
OEは、ヘッダで
Content-type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
となっていても、
メール本文の文字コードを自動認識して、強引に変換してくれるみたいなんだけど
Thunderbirdは、ヘッダの内容に忠実みたい。
まぁ、動作としてはコチラが正しい訳なんだけどね。
IEもOEも、悪気は無いんだろうけど…
つか、使い勝手を良くする意味で強引に（勝手に？）解釈してくれるんだけど
それが仇になるって事も多いねぇ…
とりあえずメールに出力する内容を
foreach ( split(/\n/, 変数名) ) {
&jcode'convert(*_, "jis", "sjis");
print XXXX $_, "\n";
}
で、JISに変換する事で文字化けが直りました。
あぁ、文字コード… (;´Д`) めんどくせ
