2008-02 / 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
mew-dist 355 (古い...) から一部抜粋。
仕様では通常、シンタックスとセマンティクスを定義します。
RFC822 では、ヘッダのセマンティクスもボディのセマンティクスも ASCII と
定めています。ASCII とは、0-127 の範囲を ASCII 表にある文字として解釈
するというセマンティクスです。ただ、RFC822 の執筆当時 Dave が気が付い
ていた犯しやすいシンタックス上の問題点(単一の CR など)は明確に排除しま
した。
日本で本文に ISO-2022-JP を入れたのは、シンタックス上は問題ありません
が、セマンティクスを破っています。ASCII 文字列中に ESC シーケンスが現
れても、それは単なる ESC シーケンスですから、日本語として取り扱われま
せん。また、ヨーロッパでは、本文に 0-255 までを許し、これを Latin-1 と
解釈することにしました。これはシンタックスもセマンティックスも破ってい
ます。しかし、所詮、日本で ISO-2022-JP を利用しようとした背景は、ヨー
ロッパが 8bit 領域を使っていたからにほかなりません。日本でも EUC Japan
を標準に選ぶ可能性はあったということです。
シンタックスは「構文」、セマンティクスは「データの意味」のことらしい。へぇ〜。
Gartner Column:第11回 そもそも「セマンティクス」とは何だろう?が参考になるかも。
追記(2009-04-05):
関連する話題があったので、貼り付けておきますね。
(URL: 日本語のe-mail、ISO-2022-JP以外のcharsetを使うのは是か非か - スラッシュドット・ジャパン)
個人的には ISO-2022-JP で表現できない内容なら、Unicode で送るのはまっ
たく問題ないと思います。ただ上の記事にあるように、本文に 8bit 目を
使うのはシンタックスを破ることになるので、base64 符号化は必須です。
Shift-JIS や EUC-JP を base64 符号化せずに送るのは 8bit 目を使って
いるので論外ですが、じゃあ Shift-JIS+base64 や EUC-JP+base64 なら良
いの?と言われるとこれも NO です。ISO-2022-JP で送れば素直なプレー
ンテキストになるのに、無駄な符号化をしているので。
2008-02 / 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29