アカウント名:
パスワード:
> そのような中継者が絶滅したと言い切れないのであれば、
これはいわゆる悪魔の証明ではなくて？
某所のリストを見ると年明けの段階でも結構ありますな少数とはいえ無視できないところもあるようだ
>> これはいわゆる悪魔の証明ではなくて？
その通りでしょう。だからこそ普通は
>> iso-2022-jp を使うべきです。
という話になるわけで。「どうせ証明できないんだから、もう証明できたことにしちゃえばいいじゃん」というのは暴論だ、という指摘はもっともだと思いますが？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
受け取れない奴が悪い (スコア:2, すばらしい洞察)
どうしても読みたいなら適切なクライアントを用意するはず。
大体、すべてiso-2022-jpで来ることを期待するなんて設計や思想そのものが間違っている。
「送る場合は厳密に、受け取る場合は寛容に」なんて送受信を行う上での基本でしょ。
というのは暴論でしょうか。
Re: (スコア:5, 興味深い)
e-mail の場合、送信者と受信者だけでなく中継者も考えに入れる必要があります。
昔は8ビット目をクリアしてしまう中継者がたくさん居ました。
運悪くそのような中継者に当たってしまうと、文字化けします。
そのような中継者が絶滅したと言い切れないのであれば、
iso-2022-jp を使うべきです。
# もう絶滅したよね、と思ってたら2006年に遭遇しました…。
# いい加減滅ぼしてくれよ。
Re:受け取れない奴が悪い (スコア:1, すばらしい洞察)
> そのような中継者が絶滅したと言い切れないのであれば、
これはいわゆる悪魔の証明ではなくて？
Re:受け取れない奴が悪い (スコア:1, 興味深い)
某所のリストを見ると
年明けの段階でも結構ありますな
少数とはいえ無視できないところもあるようだ
Re:受け取れない奴が悪い (スコア:1, すばらしい洞察)
>> これはいわゆる悪魔の証明ではなくて？
その通りでしょう。だからこそ普通は
>> iso-2022-jp を使うべきです。
という話になるわけで。「どうせ証明できないんだから、もう証明できたことにしちゃえばいいじゃん」というのは暴論だ、という指摘はもっともだと思いますが？