[過去ﾛｸﾞ] 文字コード総合スレ part13 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
668: デフォルトの名無しさん [sage] 2022/12/02(金) 11:55:24.27 ID:u/9H+2Gz(1/2) AAS
実は7bit制約もインターネットの場合は存在しない。
昔ながらの個別メール網とメール交換する際の互換性のために7bitが必要だっただけだが、そういうのは滅びたかゲートウェイで7−8変換するようになったので。
そういう意味で生UTF8で十分。
670: デフォルトの名無しさん [sage] 2022/12/02(金) 18:40:42.32 ID:u/9H+2Gz(2/2) AAS
>>669669(1): デフォルトの名無しさん [sage] 2022/12/02(金) 17:25:39.59 ID:q48B2P2f(2/2) AAS
えっと、RFC（現在は何番かな... 5322でおk?）に書いてあるUS-ASCII、というのは
生きてるわけですよね?
その上でMIMEを使えと
そうだよ。US-ASCII 以外の文字コードを使用する場合は原則MIMEヘッダーで本文の文字コードを指定しなければならない。
原則というのは
・送信者と受信者の間で暗黙もしくは明示の合意がある場合は例外。
・多くのメール・クライアントは文字コードを自動推定をする機能があるのでMIMEヘッダーを省略してもたいてい機能する。
・その後に、RFC6531 で SMTPUTF8 が導入され、RFC6532でメールヘッダーもUTF8対応に拡張されている。
要はデフォルトを US-ASCII から UTF8 に置き換える方向で進んでいる。
インターネットは一気に全体が更新されるわけではないので従来的なやり方が安全といえるけど、ユーザーがメールクライアントを更新したら裏で勝手にUTF8になっている可能性がある。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.034s