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

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

まず、
■調べる対象は以下の3つのファイル

1. オリジナルのNP_ItemMail.php(UTF8/LF)

1. 1をエディタJedit4で開いて、EUC/LFに変換したもの(改行されない)

1. 2をエディタJedit4で、バックスラッシュ==>円マークで全置換したもの(works!)

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

1. 5C

1. 80

1. 5C

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

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

• オリジナルのrawファイルは、当該部分は、5Cであった。

• Jedit4で開こうとすると、
  「漢字コードは、「UTF」、改行コードは「LF(Unix)」のようです。変換しますか？

  と聞かれた。

• 私の環境は、Mac OS Xであるから、そのままでは、改行コードが違うので、「はい」を押した。

• ここで、JeditはSJIS(Mac Font Table)/CRに変換して、表示した。

• 上記表の赤文字部分を見てもらえばわかるように、UTFの5Cは、SJISの80である。

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

• これをそのままEUC/LFで保存したら、当該部分は、Mac上のバックスラッシュ(つまり0x80)のままである。

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

• 注1Mac Font Tableではということらしい。だって、0x80って通常文字として使っては行けない制御文字の部分だったりするもんね。
• 注2今回のは最初から改行コードがLFだったから、今回については、Rawモードでも同じだと思われる
• 注3もちろん、NP_ItemMail.php自体に書かれた日本語の部分だけが化けているのであって、nucleusにパースされた変数部分の日本語は化けていない