アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
メール作成機能の強化って (スコア:1)
これかなぁ
Re:メール作成機能の強化って (スコア:1)
http://mac.ascii24.com/mac/news/misc/2005/02/07/654114-000.html [ascii24.com] の中ほどに
| 無料のウェブメールサービス“Gmail(ジーメール)”
| デジタル写真管理ソフト“Picasa(ピカサ)”
| 国内ではmixiなどの日本語で提供されているサービスに押され気味だが
| ソーシャルネットワークサービスの先駆けとなった“orkut(オーカット)”
|
| などを年内に日本語化する予定であることを明かした。
まさかGmailの日本語化提供
Re:メール作成機能の強化って (スコア:0)
Re:メール作成機能の強化って (スコア:2, 参考になる)
こんな感じでした。
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: quoted-printable
おしい。Content-Transfer-Encoding: 7bit となればメーリングリストでも使える?
Re:メール作成機能の強化って (スコア:2, すばらしい洞察)
デフォルトは自動判別おまかせで良いので、ユーザーが指定できる項目がほしいなぁ。
Re:メール作成機能の強化って (スコア:1, 参考になる)
これでも、すごい進歩かも。
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
この前まではBase64のわけのわからない文字列で
メール本文が何倍にも・・・
日本語で検索可能になってました (スコア:1)
Re:メール作成機能の強化って (スコア:2, 参考になる)
アカウントに送ってみましたが、gmail は私が送ったメールの Subject を
微妙に間違って認識してまうようです。
使った Subject: 観自在菩薩行深般若波羅蜜多時照見五蘊皆空
Becky! ver. 2.12.01 が作り出す Subject ヘッダ:
Subject: =?ISO-2022-JP?B?GyRCNFE8KzpfSm47JzlUPzxITDxjR0hNZRsoQg==?=
=?ISO-2022-JP?B?GyRCTCpCPzt+Pkg4KzheaT4zJzZ1GyhC?=
gmail はこの Subject を次のように認識します。
(「羅」のうしろにあるスペースに注目。)
観自在菩薩行深般若波羅 蜜多時照見五蘊皆空
Sylpheed version 1.0.4 が作り出す Subject ヘッダ:
Subject: =?ISO-2022-JP?B?GyRCNFE8KzpfSm47JzlUPzxITDxjR0hNZUwqQj87fj5IGyhC?=
=?ISO-2022-JP?B?GyRCOCs4Xmk+Myc2dRsoQg==?=
gmail はこの Subject を次のように認識します。
観自在菩薩行深般若波羅蜜多時照 見五蘊皆空
(「照」のうしろにあるスペースに注目。)
gmail が正しく MIME-decode を行えない為、同じ Subject を持つメールを送っても、
異なる Subject を持つメールとして扱われてしまうようです。
gmail は、同じ Subject を持つメールを、同じ Conversation としてまとめるので、
議論の流れをもれなく追うことが必要な Mailing-List 等での使用は、まだ厳しいな
と思います。
こういうところもはやく直してくれるといいな。
Re:メール作成機能の強化って (スコア:2, 興味深い)
MIME Subject は空白(タブも含む)の扱いの仕様が曖昧で、結果的にデコードする側に判断を委ねる形になっています。
んで、メールヘッダは 76 文字以内に収めなければならないという規格がありますが、
76 文字以内であればどこで改行しても規格には一応反しない訳ですね。
Becky は恐らく安全率(?)を考慮して 74 文字程度で改行を入れているのではないでしょうか。
なので今回は Becky Sylpheed Gmail 全て規格に沿った動作です。
しかーし! メールヘッダの継続行の為の行頭空白は消してもいんじゃねーのかなー、というのはオレの個人的意見ですかね。
無くて困る人はいなさそうだし、あって困る人は現にいるし。
まぁ MIME の仕様が腐っているという事実は変わらないので、Google に文句を言うのは間違いですけどね。
もう一つ個人的な MIME に対しての意見を言わせて貰うなら、ASCII も込みでエンコードさせろよ!と思ってます。
Subject がちょっと長くなったからって、誰も困らないでしょ。んで行頭空白は削除。
ついでに改行前後のエスケープシーケンスも無くしたい所ですが、事故が起きた時の為の保険は欲しいかな、やっぱり…。
Re:メール作成機能の強化って (スコア:2, 参考になる)
しかし、pjamさんの件に関してはGoogleのバグですよ。
RFC2047ではencoded-word間のlinear white spaceは無視するように定義されていますから。
Re:メール作成機能の強化って (スコア:0)
曖昧というのは仕様がエンコード後の形式しか定義していないので、
エンコードの方法が一意に定まらないということを指していますか?
そちらは同意ですが、何人かの人が指摘している空白の扱いが曖昧
というのは間違っています。
RFC(2)822の上に複数の
Re:メール作成機能の強化って (スコア:1)
もとのpjamさんが言いかったのは、gmailはSubjectの文字列一致でメールをまとめるのだから、糞な仕様でもなんとかしてよ、って事だと思います。
gmailはConversationが別になると、激しく話題が追い辛い(「スレッド」でなく同じ話題に対するメールを時系列に表示するだけの時点で、ただでさえ話を追い辛いのだが)ので、Subjectで表記のゆれが生じるのが既知の(MIME仕様上の)問題なら、それを考慮した作りになっていないとだめでしょう。
Re:メール作成機能の強化って (スコア:0)
Re:メール作成機能の強化って (スコア:0)
国内ですら統一できてませんからね……
Re:メール作成機能の強化って (スコア:1, すばらしい洞察)
元凶は空白と改行に関する仕様を曖昧にしたまま放置したMIMEの仕様策定者のほうにあると思うけど。
だいたいMIMEなんてゴミ仕様がここまで蔓延しなければ……
(以下100行ほど罵詈雑言が続くので略)
Re:メール作成機能の強化って (スコア:0)