このページは福井県立大学の田中求之が2006年1月まで運用していた Mac のサーバ運用に関する会議室 「Web Scripter's Meeting」の記録です。情報が古くなっている可能性がありますのでご注意ください。

FOR Decode MIMEJ osax USER

発言者:前薗 健一
( Date Monday, March 17, 1997 02:36:49 )


Decode MIMEJ USER の方へ

あるユーザの方から次のような BUG REPORT をいただきました。

set MyText to Encode MIMEJ (Convert Jcode "およそ12回" code type "JIS" from
"SJIS")
set MyText to Decode MIMEJ MyText

とやると、結果ウィンドウに
"およそ1212回"
と表示されてしまうのです。しかし、"12回" を試すと "12回"
と返ってきますし、"およそ12" も "およそ12" と返ってきます。

現在、調査中です。 BUG FIX したらお知らせします。

どうも、済みません。 m(..)m

佐藤@京都市 さんからのコメント
( Monday, March 17, 1997 06:50:52 )

charset が case insensitive でないのも bug なような気がします。
( ISO-2022-JP ならデコードできるけど iso-2022-jp ではダメ。)

元永二朗 さんからのコメント
( Monday, March 17, 1997 10:33:47 )

あるユーザーです(^_^)。

>charset が case insensitive でない

1.0b2 で既に fix されていますよ。

前薗 健一 さんからのコメント
( Monday, March 17, 1997 23:43:01 )

to:元永さん

フォローありがとうございます。 m(..)m

佐藤@京都市 さんからのコメント
( Thursday, March 20, 1997 02:33:54 )

>1.0b2 で既に fix されていますよ。
失礼しました。
私が試したのは 1.0b でした。

前薗 健一 さんからのコメント
( Tuesday, March 25, 1997 04:08:05 )

原因が判明しました。
Encode MIMEJ のバグでした。
ポインターの操作を誤っていたため JIS と ASCII が混在したデータで
不具合が起こっていたようです。

http://www.st.rim.or.jp/~ken-mae/EncodeMIMEJ_osax.1.0b1.sit.hqx

に修正版があります。

申し訳ありませんでした。

→  Encode MIMEJ osax

前薗 健一 さんからのコメント
( Sunday, March 22, 1998 01:00:23 )

最近 RFC1341 を読み返してみたのですが、encode 後のバイト数が1行、
例えば 74 bytes/line を超える場合の改行コードに CR+LF ( 0x0D + 0x0A )
を使えというような記述があります。

 Encode MIMEJ osax では CR ( 0x0D ) しか改行コードに使っていないのですが、
問題無く動いているでしょうか?

何故、改行コードが CR ( 0x0D ) というのは、参考にした freeware 版の
Eudora のコードがそうなっているからです。

先日、Eudora Pro + EIMS 1.2 + OTSessionWatcher で stream を確認して
みたら CR+LF ( 0x0D + 0x0A ) になっていましたので、今のままではまずいかな
と思っているのですが。

田中求之 さんからのコメント
( Sunday, March 22, 1998 02:50:34 )

改行コードは CRLF にするべきでしょうね。

MIME ヘッダーの場合、長いものは改行処理が入りますが、この際、改行した次の
行の冒頭はスペースが入りますよね。また、2バイト文字の途中で改行する場合は
文字区切りで改行することと、ちゃんとエスケースシーケンスを入れる必要があり
ますが、この辺はOKでしたっけ?

以前に、XFCN で作ろうとしていたころ(かなり昔の話)、改行処理が面倒そう
だったのであきらめたのでした (^_^;;

前薗 健一 さんからのコメント
( Sunday, March 22, 1998 03:45:47 )

> 改行コードは CRLF にするべきでしょうね。

了解です。

>MIME ヘッダーの場合、長いものは改行処理が入りますが、この際、改行した次の
>行の冒頭はスペースが入りますよね。また、2バイト文字の途中で改行する場合は
>文字区切りで改行することと、ちゃんとエスケースシーケンスを入れる必要があり
>ますが、この辺はOKでしたっけ?

これは大丈夫です。(^^)v

それでは update したものができたら、ここでお知らせします。

前薗 健一 さんからのコメント
( Monday, March 23, 1998 00:19:46 )

http://www.st.rim.or.jp/~ken-mae/EncodeMIMEJ_osax.1.0b2.sit.hqx

に改行コードを修正したバージョンがあります。

→  EncodeMIMEJ_osax.1.0b2.sit.hqx

重松修 さんからのコメント
( Wednesday, June 24, 1998 22:04:55 )

ちょっとややこしいので教えていただきたいのですが、

Subject: [RE] =?ISO-2022-JP?B?GyRC..(MIME-Bエンコードされた文字)..?=
 =?ISO-2022-JP?B?GyRC.....?=

となるということですよね。

このときに、ライン、というのは、
Subject: [RE] =?ISO-2022-JP?B?GyRC..(MIME-Bエンコードされた文字)..?=
の長さが80バイト以下である必要があるということでしょうか。

それとも、Shift_JISに戻したとき80バイト以下ということでしょうか。

同様の問題で、メールのボディを80バイト以下で改行するようにSJISで
作業したものを、JISにすると、<ESC>$Bとかがくっつく分80バイトを
オーバーします。

重松修 さんからのコメント
( Wednesday, June 24, 1998 22:10:39 )

その2の問題点として、

例えば、「oうさぎxくま」というタイトルだったとして、私はこれを
o=?ISO-2022-JP?B?GyRCJCYkNSQuGyhC?=x=?ISO-2022-JP?B?GyRCJC8kXhsoQg==?=
という風にエンコードしています。

MicrosoftのOutlookなどは、1バイトのoやxも含めて全体をエンコードしま
すし、クラリスメールは最初の1バイト文字列はエンコードしませんが、
一端エスケープに当たると以降をまとめてエンコードしているようです。

Outlook方式だと例えば、Macjorodomoなので、メールリストの名前を振ると、
RE: [foo-ml] [foo-ml]なんて、無様なことになってしまいます。

逆にクラリスメール方式だと、
foo@bar.net (山田太郎)
の最後の)がエンコードされたままになってしまいます。
無論
山田太郎 <foo@bar.net>
でも同じくダメです。

この当たり明確な決まりってのはあるんでしょうか。

前薗 健一 さんからのコメント
( Thursday, June 25, 1998 00:48:33 )

詳細は RFC を読んでください。番号は忘れました。(^^;;

元になる文字列長に制限はありません。
MIME BASE 64 に encode した時に、1行の byte 数が 74 bytes 以下に
なるようにしなさい、ということだったと記憶しています。

Outlook や、クラリスメールの仕様についてはわかりません。

田中求之 さんからのコメント
( Thursday, June 25, 1998 01:13:30 )

半角混じりの日本語のエンコードの仕方は、メーラーによってバラバラというのが
実情のようです。

また、ボディの改行についてですが、メーラーの吐き出す JIS のボディを比較した
ことがありませんが、通常は、SJIS ベースで処理されているようです。

ただ、これに関しては、英文であっても、パラグラフの間に全然改行が入らない
メールというのが最近増えてきているように思います。


清 秀紀 さんからのコメント
( Thursday, June 25, 1998 19:32:02 )

MewというEmacs用メーラーを私は主に使用しているのですが、そのMLで
過去に何度か話題になっています。

ご参考まで。


→  mew-dist ML

たまちゃん さんからのコメント
( Thursday, June 25, 1998 21:15:44 )

>>MewというEmacs用メーラー

TeXの(?)内山さんが愛用しておられました。

UNIXと言えば、ついこの間、話題のCobalt Cubeを秋葉のぷらっと
ホーム(10万円台という値札は外されていました)で見てきました。ほんとに
小さかったです。

       Cobalt Qube 2700 Software 

                  Linuxィ 2.0 multitasking operating system
                  Apacheィ 1.2 web server, HTTP 1.1 compliant
                  CGI support
                  Perl 5.0 scripting
                  SMTP, IMAP4, POP3 email protocol support
                  FTP
                  Domain Name Server (2700WG only)
                  SMB and AppleShareィ compatible file services
              (2700WG only) 

というスペックです。本題からずれてすみませんです。


→  Cobalt Cube

たまちゃん さんからのコメント
( Thursday, June 25, 1998 23:13:51 )

つながらないようなので、本家の方を。

→  Cobalt Microserver

重松修 さんからのコメント
( Friday, June 26, 1998 01:50:31 )

RFC読みましたけど、デコード後の長さが75文字を越えたらダメっぽいで
すね。?=を検索する範囲を制限するためにそういう実装になっているようで、
mewのページを見るとかなりマニアックなことが書いてありましたけど、
スペースすらエンコードする必要があるみたいですね。。。

今は手抜きで<ESC>$B〜<ESC>(Bを抜き出してBASE64エンコードしたものを
MUNGERでリプレイスしているのですが、ちょっとこれでは対応できないで
すね。

Cは全然分からないんですが、前薗さんにいただいたOSAXのコードを参考に
させていただこうと思います。>エンコードのアルゴリズム

重松修@脱線 さんからのコメント
( Friday, June 26, 1998 01:57:32 )

内山さんはTeXでお世話になっております。
# 愛用しております。

コバルトブルーですが欲しいですね。場所と電気代が節約できそうな。。。
どれくらい簡単に使えるか不明ですけど、DOS/Vの組立に苦戦し、Linuxの
インストールで挫折した私にはこういうお手軽なソリューションがいいの
かも。

清 秀紀 さんからのコメント
( Friday, June 26, 1998 11:48:31 )

コバQと某所では呼ばれているようですが、本当に小さいですね。先
日、実物を見てきたのですが、いい感じです。ボタンでIPアドレス
を直接入れるだけでOKというのは本当にお手軽。

でも私なら、自分で作っちゃうなと。あれに収まるPCのMBとケース
がほしい……。LinuxよりFreeBSDの方が慣れているし。

閑話休題。

メールのsubjectなど、「Re: ほげほげ」がどんどん「Re:  ほげほ
げ」「Re:   ほげほげ」となって行ってしまうのは、いろんな意味
で辛いですね。でも、Mewで駄目ならあきらめがつきます。それが現
状なのだと。
  

重松修 さんからのコメント
( Saturday, June 27, 1998 20:01:33 )

ちょっとまたまた分からないことがでてきたんですが、多分これは、
クラリスメールのバグだと思いますが、

例えば、

set myText to "Subject: =? と ?= を含む日本語のタイトルの Test"
set myText to SjisToJis myText
set myText to Encode MIMEJ myText

を実行すると

"Subject: =? =?ISO-2022-JP?B?GyRCJEgbKEI=?=
 ?= =?ISO-2022-JP?B?GyRCJHI0XiRgRnxLXDhsJE4lPyUkJUglayROGyhC?= Test"

が戻ります。

しかし、クラリスメールではデコードされません。

これはクラリスメールがタコだから、といってしまえばそれまでなのですが、
元文字列として、例えば、メールタイトルが =?ISO-2022-JP?B?〜?= という
風になっている場合でもきちんと読めるようにするにはどうすればよいの
でしょうか。

そこはエンコードしてしまった方がよいのでしょうか。

重松修 さんからのコメント
( Sunday, June 28, 1998 12:13:24 )

PostPetで試してみました。

そうすると、やはり=?はエンコードしませんが、なんと!受信時にクラッ
シュします。しかも、サーバに残って、メールが取れない。

PostPetでは、他にも改行が入っていないメールでも吹っ飛びますし、
PostPetが悪いといえばそれまでですけど、なんか商品にしてはいい加減
かもとか思いました。

その他のメーラーでも試してみようと思います。

田中求之 さんからのコメント
( Sunday, June 28, 1998 13:19:26 )

Eudora Pro 3.1 がどのようにエンコードするか試してみましたが

「=? と ?= を含む日本語のタイトルの Test」で

Subject: =? =?ISO-2022-JP?B?GyRCJEgbKEo=?= ?= 
 =?ISO-2022-JP?B?GyRCJHI0XiRgRnxLXDhsJE4lPyUkJUglayROGyhK?= Test

となります。改行の位置以外は同じようですね。

重松修 さんからのコメント
( Tuesday, June 30, 1998 12:50:33 )

大学のWinbiffとやら言うメーラーで実験してみました。
そうすると、どうやら、これはかなりアバウトな処理で、不完全な文字列の時はデコードしないだけ見たいです。
意地悪なので、
=?ISO-2022-JP?Q?This=20is=20a=20test?=とかやってみると、さくりと単にThis is a testに戻されておしまい。
と言うことは、メールのタイトルに=?が含まれたりすると扱いはバラバラって事ですね、完全に。
すごいいいかげんだと言う事がわかりました。