[解決?]円マークとバックスラッシュ(その4)

この話題の元々の話は、「NP_ItemMailメール出力結果において、各項目毎の改行がされずに、本来改行のある位置に、「?n」の文字が入ってしまうという問題が、NP_ItemMail本体中の改行を表わす「バックスラッシュn」を「円マークn」に置換することで解決されたことの理屈がわからない」という話だった。なんとか、これが見えてきた。まず、■調べる対象は以下の3つのファイル

■上記の3つのファイルをバイナリエディタで開いて、当該部分を確認した結果は以下の通り。

1と3は当該部分の記述は同じである。だから、動作(送信メールにおける項目毎の改行)したわけである。問題は、2のファイルである。なぜ、オリジナルをエディタJedit4で開いてEUC/LFに変換しただけで、当該部分が書き換わってしまったのか？このことを考えるために、文字コードに関する円マークとバックスラッシュの詳細をもう一度、確認しておく。私が調べた結果が間違いなければ、以下は事実である。

さて、以下のように考えるのと全てが符合する。

誤）Mac font tableで80ということである。では、SJISでは5Cなのかというと、SJISではASCIIでなくJISラテン文字(JIS X0201-1976 Roman Set)が使われているので、0x5Cはバックスラッシュでなく円マーク。ということは、厳密にはSJISでのバックスラッシュは存在しないことになるんじゃないの？結果、私は、Jeditで見た当該部分は、バックスラッシュになったわけだ。

以上の理屈から、EUC/LFで保存し直しただけのものが、書き換わったのではなかろうか。もちろん円マークバックスラッシュでなければ項目毎の改行はしないので、2のファイルは動作しなかった。では、エディタでいじらずに、単に、FTPでASCIIモード転送*2してやれば良かったのだろうか？今回のは、Plugin自体に日本語を書かなければならないので、実用にはならないが、2バイト文字(日本語)が関係ないものであったならば、それで動作するはずだし、今回のものも、化けるだけで動作(改行)自体はするのではないか。やってみた。見事、項目毎に改行された化け化けメールが届いた。*3こんな理屈が当たりなのではないでしょうか。