=?iso-2022-jp?B?...=?=$B$NI=8=$N7o(B (Re: $B%X%C%@!<$NJ8;z2=$1(B)
Kawaguti Ginga
<9q9t79$q7u$1...@news01.iij4u.or.jp>の記事において
sug...@pp.iij4u.or.jpさんは書きました。
> # fj.net.mime とも思ったのですが、ユーザーエージェント側の
> # 話と思うので Followup-To: fj.mail.reader です。
fj.net.mime の存在を知らなかったのでクロスポスト...
> > *汎用* の text 表現を行うための規約で "表現できないもの" が
> > あるのは良くないでしょう．
>
> てっきり面倒とか無駄という話が出るのかなと思ってました。
> 下で Subject の話が出てるので(encoded-textは入れてませんが)
> Subject を変えてみたのですが、勘違いされてませんか？
どうも想定しているものが異なっていたようですね．
以下に私の書いていた立場を書きます．
> > > そうですか？
> > > 規格があっても存在は消せないので、私はやっぱり欲しいです。
> >
> > もしかして，MIME の方が Outlook* よりずっと昔から
> > 明確に決まっている，ということをご存じないのでしょうか?
> > あとから勝手に乱入してきて暴れている人に合わせて
> > 規格を変えていたら規格の意味がないでしょう?
>
> この部分は実装の話なのですが…？？
すみません，確認ですが "規格があっても存在は消せない" は
(MIME)規格があっても(規格策定より前に)存在していたもの
(実装であったり，それによって生成されたメールなどの出力)
は消せない，という意味かと解釈していたのですが違うのですね?
でこの話については最終的には実装の話かもしれませんが，
要するに規格に逆らった実装をしていたら規格の意味がないのでは，
というのが私の文章の意図でした．
> > > # 昔は文字化けしたメールとか届くことがよくありましたが、
> > > # 受け取った側で対処するというのはよくありましたし、
> > > # 今でも携帯からのとかはよくやりますし。
> >
> > それをなくすために規格で統一しているのではないのですか?
> > そして，それは規格を守ることによって避けられるべき
> > ことではないのですか?
>
> すべて考慮した上であればそうでしょうね。
> ただ、とどいてしまったメールになにか問題があったとして、それ
> を読みたいと思ったとき、どのような効力があるのでしょうか？
とりあえず
暴虐なOutlook* が存在して暴れていることは
(積極的ではなくても)認める(認めざるをえない)
という立場で，そういう連中を相手にする際の機能としての対処が
欲しい，ということでしょうか? それならば分かります．
そしてそれに対しては私の考えでは個別実装で
(decode側の部分のみですが)
* 普段は普通にしておいて異常対応機能として設定すると
"?=iso-2022..." をもデコードする
* もっとあきらめて常に quote を考慮しない
(これはこれでかなり困りますが)
なんていう対処法は現実の実装としてはあり得るかもしれませんが
後者は私としては反対です．やるなら前者．
> > そうだったのかもしれませんが，別に From: や To: や
> > Subject: でも全く同じ話なので関係ないです．
>
> mnews の話かな？
> そのように実装されているということは了解しました。
すみません，私は個別実装の話をしていたつもりではありません．
(MIME による)コミュニケーションの在り方として
双方が規格に基づいてやりとりをしないのなら駄目だ，
という話は body でも from でも subject でも共通の問題である，
という意図です．
# もう世の中は Outlook* が全てであるという前提の元に
# 実装するならまた別ですけど．
--
∧∧
Zzz.. (- - )⌒⌒⊇～ 川口 銀河
############## gi...@athena.club.ne.jp
Koichi Soraku
In article <9qlccq$14j$1...@inb.m.ecl.ntt.co.jp>,
gi...@athena.club.ne.jp wrote:
> Subject: Re: =?iso-2022-jp?B?...=?=の表現の件 (Re: ヘッダーの文字化け)
これ、quoteしておいた方が良いんじゃないですかねぇ。たぶん元記事から
こうなっていたのだとは思いますが…。
＃今使っているやつはMIME未対応だから大丈夫だけど…。
> > ただ、とどいてしまったメールになにか問題があったとして、それ
> > を読みたいと思ったとき、どのような効力があるのでしょうか？
> とりあえず
> 暴虐なOutlook* が存在して暴れていることは
> (積極的ではなくても)認める(認めざるをえない)
> という立場で，そういう連中を相手にする際の機能としての対処が
> 欲しい，ということでしょうか? それならば分かります．
うーん、規格を示してきちんと規格に添った形で送りなおしてくださいと要
求するとか。:-p まぁ、これだけですまないのが辛いところなのでしょうが。
> そしてそれに対しては私の考えでは個別実装で
> (decode側の部分のみですが)
> * 普段は普通にしておいて異常対応機能として設定すると
> "?=iso-2022..." をもデコードする
…(1)
> * もっとあきらめて常に quote を考慮しない
> (これはこれでかなり困りますが)
…(2)
私は(1)といって良いのかもしれませんが、
* 必要ならnkf等の別ツールを使って手動対応
としています。
> なんていう対処法は現実の実装としてはあり得るかもしれませんが
> 後者は私としては反対です．やるなら前者．
そうですね。後者(2)だとこの記事のようなSubjectのような場合に変な事に
なってしまいそうですし。まぁ、(2)と(1)を組み合わせて、(2)で問題が発生
する時のみquoteを考慮した処理を行うというのも手間を省くという点ではあ
りかもしれませんが、問題意識をもってもらうためにもあまりやって欲しくな
いです。
--
Koichi Soraku
Izumi-ku Yokohama-shi KANAGAWA JAPAN
SGU0...@nifty.ne.jp,jg4...@ja6ybr.org
-- Powered by FreeBSD & FreeBSD(98) --
T. Sugita
In message news:9qlccq$14j$1...@inb.m.ecl.ntt.co.jp
"Kawaguti Ginga" <gi...@athena.club.ne.jp> wrote ...
> > > > そうですか？
> > > > 規格があっても存在は消せないので、私はやっぱり欲しいです。
> > >
> > > もしかして，MIME の方が Outlook* よりずっと昔から
> > > 明確に決まっている，ということをご存じないのでしょうか?
> > > あとから勝手に乱入してきて暴れている人に合わせて
> > > 規格を変えていたら規格の意味がないでしょう?
> >
> > この部分は実装の話なのですが…？？
>
> すみません，確認ですが "規格があっても存在は消せない" は
> (MIME)規格があっても(規格策定より前に)存在していたもの
> (実装であったり，それによって生成されたメールなどの出力)
> は消せない，という意味かと解釈していたのですが違うのですね?
すみません。私も曖昧な書き方になっていましたが、ほぼ合って
います。
ただし規格策定の前後は関係なく、誤って拡張されたものも含んで
おり、実装の際に拡張があっても、それに合わせて規格を変える
必要はないという意味です。
> でこの話については最終的には実装の話かもしれませんが，
> 要するに規格に逆らった実装をしていたら規格の意味がないのでは，
> というのが私の文章の意図でした．
了解しました。
ただ、規格は相互コミュニケーションの円滑化(正しく実装していれば、
意図した通りにコミュニケーションが取れるようにするための指針)が
主目的と“私は”考えており、逆らった実装に意味がないことはあっ
ても、規格に意味がないとは思いません。
> とりあえず
> 暴虐なOutlook* が存在して暴れていることは
> (積極的ではなくても)認める(認めざるをえない)
> という立場で，そういう連中を相手にする際の機能としての対処が
> 欲しい，ということでしょうか? それならば分かります．
>
> そしてそれに対しては私の考えでは個別実装で
> (decode側の部分のみですが)
> * 普段は普通にしておいて異常対応機能として設定すると
> "?=iso-2022..." をもデコードする
> * もっとあきらめて常に quote を考慮しない
> (これはこれでかなり困りますが)
> なんていう対処法は現実の実装としてはあり得るかもしれませんが
> 後者は私としては反対です．やるなら前者．
<9oo0g1$dvb$1...@news01.iij4u.or.jp> での記述も、前者のつもりでした。
曖昧な表現で申し訳ないです。
> > > そうだったのかもしれませんが，別に From: や To: や
> > > Subject: でも全く同じ話なので関係ないです．
> >
> > mnews の話かな？
> > そのように実装されているということは了解しました。
>
> すみません，私は個別実装の話をしていたつもりではありません．
> (MIME による)コミュニケーションの在り方として
> 双方が規格に基づいてやりとりをしないのなら駄目だ，
> という話は body でも from でも subject でも共通の問題である，
> という意図です．
前回、具体的にかかなかった点は申し訳なかったのですが、
私は以下のように考えています。
body はどの body か不明なので置いておきます。
# もし本文ということであれば、どの規格のどの部分を適用しようと
# しているか、指摘していただければ幸いです。
Subject は、RFC822 では
3.1.3. UNSTRUCTURED FIELD BODIES
| For some fields, such as "Subject" and "Comments", no struc-
| turing is assumed, and they are treated simply as <text>s, as
| in the message body. Rules of folding apply to these fields,
| so that such field bodies which occupy several lines must
| therefore have the second and successive lines indented by at
| least one LWSP-char.
3.3. LEXICAL TOKENS
| text = <any CHAR, including bare ; => atoms, specials,
| CR & bare LF, but NOT ; comments and
| including CRLF> ; quoted-strings are
| ; NOT recognized.
4.1. SYNTAX
| optional-field =
| / "Subject" ":" *text
と定義され、RFC2822 も同様に
3.6.5. Informational fields
| subject = "Subject:" unstructured CRLF
となっています。
一方、Message Header Extensions の RFC2047 では
5. Use of encoded-words in message headers
| (1) An 'encoded-word' may replace a 'text' token (as defined by RFC 822)
| in any Subject or Comments header field, any extension message
| header field, or any MIME body part field for which the field body
| is defined as '*text'. An 'encoded-word' may also appear in any
| user-defined ("X-") message or body part header field.
|
| Ordinary ASCII text and 'encoded-word's may appear together in the
| same header field. However, an 'encoded-word' that appears in a
| header field defined as '*text' MUST be separated from any adjacent
| 'encoded-word' or 'text' by 'linear-white-space'.
とあり、encoded-word として処理することが求められているだけで、
word として扱うことが求められているわけではありません。
RFC2047 中で、たとえば
5. Use of encoded-words in message headers
| + An 'encoded-word' MUST NOT appear within a 'quoted-string'.
等で求められる quoted-string は、structured header field
として定義された From や To では phrase と定義されている
ことからそのように扱う必要がありますが、Subject も同様に
扱うべきとは、具体的にどの部分に抵触していると考えて
おられるのでしょうか？
ただし、encoded-word の両端が "" で囲われた場合、
LWSP-char に隣接していないことからどのように扱うかは微妙ですが、
これは "" だからではなく他の文字でも同様ですし、スペース
を含んで quote されている(ように見える)ケースも考えられる
わけですので、理由としては弱いと考えます。
8. Examples
| In each of the following examples, if the same sequence were to occur
| in a '*text' field, the "displayed as" form would NOT be treated as
| encoded words, but be identical to the "encoded form". This is
| because each of the encoded-words in the following examples is
| adjacent to a "(" or ")" character.
もし Subject に encoded-word を使用したいとして、
1. Introduction
| A mail reader that implements this specification will recognize
| encoded-words when they appear in certain portions of the message
| header. Instead of displaying the encoded-word "as is", it will
| reverse the encoding and display the original text in the designated
| character set.
5. Use of encoded-words in message headers
| Use of these methods to encode non-textual data (e.g., pictures or
| sounds) is not defined by this memo. Use of 'encoded-word's to
| represent strings of purely ASCII characters is allowed, but
| discouraged. In rare cases it may be necessary to encode ordinary
| text that looks like an 'encoded-word'.
とあるように、再エンコードした方が良いと私は考えます。
ASADA Kazuhisa
<9qrule$h5d$1...@news01.iij4u.or.jp> に書きました:
～～ばっさり～～
> 等で求められる quoted-string は、structured header field
> として定義された From や To では phrase と定義されている
> ことからそのように扱う必要がありますが、Subject も同様に
> 扱うべきとは、具体的にどの部分に抵触していると考えて
> おられるのでしょうか？
～～ばっさり～～
ええと、何か話が脱線していってるみたいですが、いつのまに Subject
の話になっているんでしょう？
Subject なら unstructured header なので、殆んどの 7bit文字を問題
なく記述できますよね。元は structured header field body の話だった
のではありませんか？
まあ、Subject に encoded-word と解釈される文字列を書きたいなら、
杉田さんが書かれた通り、符号化してやるしかないでしょうね。
(多くの MUAは対応していないんだろうけど)
一連の記事では Subject が生JISで入っていたり、Outlook Express が
得意の丸ごと符号化をしたり、といったことから読めておりますが、さて
ワタシの投稿ではどうなることやら。
--
浅田和久／大阪市在住
T. Sugita
In message news:9qs8cu$9jr$1...@news511.nifty.com
"ASADA Kazuhisa" <HHD0...@nifty.ne.jp> wrote ...
> ええと、何か話が脱線していってるみたいですが、いつのまに Subject
> の話になっているんでしょう？
相手に encoded-word を説明できるかどうかというあたりから派生
(とはちょっと違うかな)しています。
> Subject なら unstructured header なので、殆んどの 7bit文字を問題
> なく記述できますよね。元は structured header field body の話だった
> のではありませんか？
はい。
> 一連の記事では Subject が生JISで入っていたり、Outlook Express が
> 得意の丸ごと符号化をしたり、といったことから読めておりますが、さて
> ワタシの投稿ではどうなることやら。
綺麗に符号化されてますね。
丸ごと符号化も選択肢の一つ(メモリを消費する以外は割りと良いかな
と思ってる)のですが、Re: だけは除きたいところです。
# 頭４文字は同じなので、送信前にスプールを検索して "Re: " に
# 置き換えようかと思ったことがあったのですが、スペースが増えて
# しまうことに気付き、スプールもバイナリなので、そこであきらめ
# てしまいました。