アカウント名:
パスワード:
> # もう絶滅したよね、と思ってたら2006年に遭遇しました…。> # いい加減滅ぼしてくれよ。そうですね、今どきオープンリレーなんていい加減滅ぼしてほしいです。オープンじゃないリレーなら広い意味で受信者に含まれるでしょう。そもそもBase64でエンコードすれば8bit目を落とされても問題ありません。
>しかしまあ、なんという番号付けだろう。最初の821はともかく、>次は2000を足して2821、そのは8を5と3に分解して5321だもんなあ
ここ笑うとこ？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
受け取れない奴が悪い (スコア:2, すばらしい洞察)
どうしても読みたいなら適切なクライアントを用意するはず。
大体、すべてiso-2022-jpで来ることを期待するなんて設計や思想そのものが間違っている。
「送る場合は厳密に、受け取る場合は寛容に」なんて送受信を行う上での基本でしょ。
というのは暴論でしょうか。
Re: (スコア:5, 興味深い)
e-mail の場合、送信者と受信者だけでなく中継者も考えに入れる必要があります。
昔は8ビット目をクリアしてしまう中継者がたくさん居ました。
運悪くそのような中継者に当たってしまうと、文字化けします。
そのような中継者が絶滅したと言い切れないのであれば、
iso-2022-jp を使うべきです。
# もう絶滅したよね、と思ってたら2006年に遭遇しました…。
# いい加減滅ぼしてくれよ。
Re: (スコア:0)
> # もう絶滅したよね、と思ってたら2006年に遭遇しました…。
> # いい加減滅ぼしてくれよ。
そうですね、今どきオープンリレーなんていい加減滅ぼしてほしいです。
オープンじゃないリレーなら広い意味で受信者に含まれるでしょう。
そもそもBase64でエンコードすれば8bit目を落とされても問題ありません。
Re: (スコア:1)
送信元MUA→自社部署内MTA→自社MTA→どこか→他社MTA→他社部署内MTA→宛先MUA
という感じだとオープンリレーなしで中継者たくさん、という状況になり得ます。
この場合、自社MTAを受信者に含めると話がしにくいと思います。
で、こういう経路のどこかで8ビット目が捨てられてしまったとしましょう。
すると、どこで捨てられたかわからないし、
誰に文句言ったらいいのかもわからないという状況になります。
# 文句言うと逆に怒られそう。
このような状況が考えられる中で
「受け取れない奴が悪い」と言うのはまずいと思います。
> そもそもBase64でエンコードすれば8bit目を落とされても問題ありません。
はい。常時7ビットの符号にしておくのが無難です。
Re:受け取れない奴が悪い (スコア:1)
Re: (スコア:0)
>しかしまあ、なんという番号付けだろう。最初の821はともかく、
>次は2000を足して2821、そのは8を5と3に分解して5321だもんなあ
ここ笑うとこ？