Base64デコード変換が期待動作と異なるNo.22289
dimension さん　06/12/07 13:37
　
秀丸エディタ変換モジュールライブラリ
BASE64デコード V1.00
http://hide.maruo.co.jp/lib/hmconv/hmfbase64_100.html
と秀丸エディタ5.18を使用しています。

JISコードの”あい”は、0x1B 0x24 0x42 0x24 0x22 0x24 0x24 です。
これを自作のMIME Base64エンコードすると、
=?iso-2022-jp?B?GyRCJCIkJA?=
となりましした。

このエンコードデータ　"=?iso-2022-jp?B?GyRCJCIkJA?="
を秀丸エディタで変換->Base64デコードとすると、
期待値の”あい”に対して”あ$”になってしまいます。

間違いがどこにあるかご教示をよろしくお願いします。
[ △ ]
RE:22289 Base64デコード変換が期待動作とNo.22290
秀丸担当 さん　06/12/07 14:20
　

>JISコードの”あい”は、0x1B 0x24 0x42 0x24 0x22 0x24 0x24 です。
>これを自作のMIME Base64エンコードすると、
>=?iso-2022-jp?B?GyRCJCIkJA?=
>となりましした。
>
>このエンコードデータ　"=?iso-2022-jp?B?GyRCJCIkJA?="
>を秀丸エディタで変換->Base64デコードとすると、
>期待値の”あい”に対して”あ$”になってしまいます。
>
>間違いがどこにあるかご教示をよろしくお願いします。

メールには詳しくないのですが適当答えてしまいますと、JISで最後に ASCIIに
戻す ESC ( B が無いためのようです。
この変換はたぶん秀丸メールと同じ処理をしていて、秀丸メールの題名の受信で
も同様になりました。
JISとしては ESC ( B は無くても大丈夫だと思うのですが、メールでは約束事が
あるのかどうか知らないですが、ESC ( B は付けておいた方がいいようです。
Outlook Express でも正しくデコードできませんでした。
[ △ ]
RE:22290 Base64デコード変換が期待動作とNo.22291
dimension さん　06/12/07 15:33
　
>
>>JISコードの”あい”は、0x1B 0x24 0x42 0x24 0x22 0x24 0x24 です。
>>これを自作のMIME Base64エンコードすると、
>>=?iso-2022-jp?B?GyRCJCIkJA?=
>>となりましした。
>>
>>このエンコードデータ　"=?iso-2022-jp?B?GyRCJCIkJA?="
>>を秀丸エディタで変換->Base64デコードとすると、
>>期待値の”あい”に対して”あ$”になってしまいます。
>>
>>間違いがどこにあるかご教示をよろしくお願いします。
>
>メールには詳しくないのですが適当答えてしまいますと、JISで最後に ASCIIに
>戻す ESC ( B が無いためのようです。
>この変換はたぶん秀丸メールと同じ処理をしていて、秀丸メールの題名の受信で
>も同様になりました。
>JISとしては ESC ( B は無くても大丈夫だと思うのですが、メールでは約束事が
>あるのかどうか知らないですが、ESC ( B は付けておいた方がいいようです。
>Outlook Express でも正しくデコードできませんでした。

ありがとうございます。
JISコードの”あ”=　0x1B 0x24 0x42 0x24 0x22
をMIME　BASE64にエンコードすると
=?iso-2022-jp?B?GyRCJCI?=
になりました。
これは期待通りに秀丸上でBASE64デコードされ
”あ”に変換されました。

お教えのように安全のために、エンコード処理で、JIS漢字コード
の最後は、ESC(B をつけて終わるようにしてみます。

お礼に興味深いサンプルプログラムを見つけたので参考まで
ご覧願います。
TITLE:[9fans] Base64 mime encode/decode program
URL:http://lists.cse.psu.edu/archives/9fans/1998-November/007052.html

このプログラムをクリップボード経由でエディタに移すと、
元のJIS日本語コードが化けてSHIFT-JISコードに変わり、
この状態でコンパイルすると、
プログラムはESCをとりそこねて0x80以上ではじまる漢字コードがきて、*mime_encod
e(char *from, char *encoded) 関数が無限ループに陥りました。
[ △ ]
RE:22291 Base64デコード変換が期待動作とNo.22292
秀丸担当 さん　06/12/07 16:21
　

>お礼に興味深いサンプルプログラムを見つけたので参考まで
>ご覧願います。
>TITLE:[9fans] Base64 mime encode/decode program
>URL:http://lists.cse.psu.edu/archives/9fans/1998-November/007052.html
>
>このプログラムをクリップボード経由でエディタに移すと、
>元のJIS日本語コードが化けてSHIFT-JISコードに変わり、

見てみました。
IEでは"Re: これはmimeB64のテストです."というところは日本語で表示されまし
た。
FireFoxでは文字化けしました。
IEで明示的にエンコードをシフトJISにすることで、ESC付きの生のコードとして
見ることができました。
この生の状態をコピーして、秀丸エディタに貼り付けると、一部だけ日本語にな
って、ESC ( H は無視され、半分文字化け状態になりました。

秀丸エディタの貼り付けは、標準ではJISのエスケープシーケンスを理解します。
[その他]→[動作環境]→[編集]の「貼り付けでJISコードの自動認識をする」を
OFFにすると、生のまま貼り付けることができます。
Outlook Express のいつかのバージョンで、メール本文をコピーするとJISが混
在するデータがコピーされるという問題があり、それに対応せざるを得なくなっ
たためです。

で、そこまではいいののですが、ESC ( H は、古い希なエスケープシーケンスの
ようで、秀丸エディタは対応していませんでした。
V6.50βのほうで入力のみ対応しておこうと思います。

FireFoxも ESC ( H を理解できず文字化けしてしまうようです。
[ △ ]
RE:22292 Base64デコード変換が期待動作とNo.22295
Ａｒｉｍａｃ さん　06/12/08 01:07
　
ESC ( H はJIS規格書の誤植だと書いてあるのを見たような気がするので探してみたら
http://www2d.biglobe.ne.jp/~msyk/charcode/jisx0201kana/swx0201roman.html
にちょっとだけありました。
他にも書いてあるところがあったような気がするんだけど…
RFC1468には間違った原因は書いてないし。
[ △ ]
RE:22295 Base64デコード変換が期待動作とNo.22296
秀丸担当 さん　06/12/08 09:08
　

>ESC ( H はJIS規格書の誤植だと書いてあるのを見たような気がするので探してみたら
>http://www2d.biglobe.ne.jp/~msyk/charcode/jisx0201kana/swx0201roman.html
>にちょっとだけありました。
>他にも書いてあるところがあったような気がするんだけど…
>RFC1468には間違った原因は書いてないし。

そうだったのですか。HとJが隣にあるから間違えたのでしょうか。
情報ありがとうございます。


最初の件ですが、ESC ( B が無いためなんじゃないなかと答えてしまいましたが、
それは関係なくてbase64の最後にパディング'='が無いためかもしれません。
エンコード前のデータが３の倍数でない場合、３の倍数に揃えてパディングを付
けるというルールがあったと思います。秀丸エディタのUTF-7のbase64解析でや
っていたので思い出しました。
[ △ ]
RE:22296 Base64デコード変換が期待動作とNo.22298
dimension さん　06/12/08 15:43
　
>
>>ESC ( H はJIS規格書の誤植だと書いてあるのを見たような気がするので探してみたら
>>http://www2d.biglobe.ne.jp/~msyk/charcode/jisx0201kana/swx0201roman.html
>>にちょっとだけありました。
>>他にも書いてあるところがあったような気がするんだけど…
>>RFC1468には間違った原因は書いてないし。
>
>そうだったのですか。HとJが隣にあるから間違えたのでしょうか。
>情報ありがとうございます。
>
>
>最初の件ですが、ESC ( B が無いためなんじゃないなかと答えてしまいましたが、
>それは関係なくてbase64の最後にパディング'='が無いためかもしれません。
>エンコード前のデータが３の倍数でない場合、３の倍数に揃えてパディングを付
>けるというルールがあったと思います。秀丸エディタのUTF-7のbase64解析でや
>っていたので思い出しました。

秀丸担当さん、ありがとうございます。
その通りでした。
TITLE:BASE64 について
URL:http://www.sea-bird.org/doc/Cygwin/BASE64enc.html
・・・ここを見ると、３の倍数に満たない部分を"="でパッディング
することが書かれていました。

Base64でコード化されると0〜63の64文字と思っていましたが、
パッディング文字の"="はそれら64文字に該当しない例外として用意されてるんですね。
0に対応するBase64コードの"A"でパッディングしたほうが分かりやすい気はするんで
すけど、規則では止む無しですね。
勉強になりました。
[ △ ]
RE:22298 Base64デコード変換が期待動作とNo.22299
dimension さん　06/12/08 16:13
　
動作確認しました。
base64エンコード部分が4の倍数になるように
=?iso-2022-jp?B?GyRCJCIkJA?=
へ"=="をパディングして10バイト->12バイト
にしました。

=?iso-2022-jp?B?GyRCJCIkJA==?=

・・・これを変換すると”あい”になりました。
自作のBase64エンコードプログラムはLGPLの
プログラムがベースになっていますが、
問題が見つかったのでこれから見直します。
お騒がせし申し訳ありません。
ご教示をありがとうございました。

なお、先に示したプログラムでJISコードをエンコードすると、
TITLE:[9fans] Base64 mime encode/decode program
URL:http://lists.cse.psu.edu/archives/9fans/1998-November/007052.html

=?ISO-2022-JP?B?GyRCJCIkJA==?=

・・・となってしまい、このケースでは秀丸Base64変換が
効かないのを発見しました。この生成コードが規則に正しいのか
どうかは未調査です。
[ △ ]
RE:22299 Base64デコード変換が期待動作とNo.22300
dimension さん　06/12/08 16:18
　
>なお、先に示したプログラムでJISコードをエンコードすると、
>TITLE:[9fans] Base64 mime encode/decode program
>URL:http://lists.cse.psu.edu/archives/9fans/1998-November/007052.html
>
>=?ISO-2022-JP?B?GyRCJCIkJA==?=
>
>・・・となってしまい、このケースでは秀丸Base64変換が
>効かないのを発見しました。この生成コードが規則に正しいのか
>どうかは未調査です。

まことにすみません。訂正します。
ファイル属性が関係して変換が効かないようです。
コピペして変換すると変換OKです。
[ △ ]
RE:22298 Base64デコード変換が期待動作とNo.22302
アルビレオ さん　06/12/08 17:49
　
ユーザーのアルビレオです。

>0に対応するBase64コードの"A"でパッディングしたほうが分かりやすい気はするんで
>すけど、規則では止む無しですね。

パディングはデータの終端を示す意味もあります。
単純に0で埋めてしまうと、デコードしたときにパディング分だけデータが増え
てしまって困りますよ。
[ △ ]
RE:22291 Base64デコード変換が期待動作とNo.22506
dimension さん　07/02/07 15:59
　
>お礼に興味深いサンプルプログラムを見つけたので参考まで
>ご覧願います。
>TITLE:[9fans] Base64 mime encode/decode program
>URL:http://lists.cse.psu.edu/archives/9fans/1998-November/007052.html
>
>このプログラムをクリップボード経由でエディタに移すと、
>元のJIS日本語コードが化けてSHIFT-JISコードに変わり、
>この状態でコンパイルすると、
>プログラムはESCをとりそこねて0x80以上ではじまる漢字コードがきて、*mime_enco
>de(char *from, char *encoded) 関数が無限ループに陥りました。

無限ループに陥る問題を解決したソースコードをこちらにおいておきました。
この改良によりBASE64エンコード・デコードの実験レベルに使えます。

http://forums.microsoft.com/MSDN-JA/ShowPost.aspx?PostID=999656&SiteID=7

ただし実用には、入出力配列に関しmalloc(),free()等のメモリ管理関数を使う改良
が必要と思われます。
[ △ ]