ids/8/475.txt

#?SuikaWiki/0.9 page-icon="メイル"
[1] [[頭]] (頭部) とは [[header]] の訳語で、「かしら」と呼びます。
手紙の最初の部分のことを[RUBY[頭] [かしら]]と呼んだことにちなんで、この訳語が当てられました。 (なお頭部に対して本文部分を[[本体]] ([[body]])
と呼びます。)

[2] [[電子メイル]]や[[電子ニュース]]では、記事の題や著者, 日時,
その他の[[メタ情報]]を記述する部分として、頭部は重要な役割を果たしています。

[3] [[RFC822]] では、頭部は[[頭欄]]の集合として定義されています。
頭欄は更に頭欄名と頭欄本体で構成されます。この電子メイルの構造は [[USENET]]
のニュース記事, [[HTTP]] メッセージ, [[SIP]] メッセージなどにも流用されています。
この WikiPage では RFC 822 的メッセージ形式の頭部全体についての話題を扱います。

[[#comment]]
*ありがちな構造
-[[comment]]
-[[quoted-string]]
-[[encoded-word]]
-[[atomとtokenの類]]
- [29] [[atom]], [[token]]
[[#comment]]
*頭部の charset
-[4] '''注''': [[Subject:]] 欄の末尾から引越しますた。
- [23] [[spam]] なんですけど、本文が [[Content-Type:]] & [[charsetパラメーター]]つきの[[シフトJIS]] (名前が [CODE[shift-jis]] だったが。) で、 [[Subject:]] 欄が生シフト JIS のメッセージがありました。今ではこんなのはあんまり見かけませんが、過去には (特に私信や local newsgroup で) よくあったんじゃないかと思います。
- [24] >>23 で、 [CODE[Subject:]] が8ビットで、本文も8ビットだけど本文の [[charset]] が分かっている場合には、その charset を [CODE[Subject:]] にも適用したらどうかなあとか思ったです。
- [25] >>23-24 本文はシフト JIS で [CODE[Subject:]] は [[ISO-2022-JP]] ってこともありますから、何も考えずに一律にやってしまうとまずいとは思うんですけど、状況を >>24 くらいに限定すればどうかなと。 (だけど、この類は hard coding しないと実装は困難かなあ。)
- [26] >>25 こういう処理を入れてくと条件分岐や option がどんどん増えてってぐちゃぐちゃになって嫌ですよねえ。
- [27] >>23-26 spam じゃない普通のメッセージでも、 [[ISO-8859-1]] の生 [[From:]] とかがよくあるね、英語の [[ML]] とか読んでると。やっぱりそういう実装は、 header 全体レベルで、人間可読文字列部分に対して付ける必要がありそう。
- [28] >>27 header charset が [[US-ASCII]], [[ISO/IEC2022]], [[ISO-8859-1]], [[UTF-8]] とあって、更に [[encoded-word]] がある状況で、こういうのを全部うまくきれいにまとめて実装するのはとてつもなくしんどそうだ。
- [30] [[RFC822]] を見ましたが、 [CODE(ABNF)[field-name]] は [[ASCII]] の一部[[図形文字]]しか使えませんね。ちょっと安心。
- [31] >>30 でも [[encoded-word]] (っぽいもの) は書けるね。 [CODE(ABNF)[encoded-word]] として認識してはもらえないけど。
[[#comment]]
*メモ
1	wakaba	1.1	#?SuikaWiki/0.9 page-icon="メイル"
2			[1] [[頭]] (頭部) とは [[header]] の訳語で、「かしら」と呼びます。
3			手紙の最初の部分のことを[RUBY[頭] [かしら]]と呼んだことにちなんで、この訳語が当てられました。 (なお頭部に対して本文部分を[[本体]] ([[body]])
4			と呼びます。)
5
6			[2] [[電子メイル]]や[[電子ニュース]]では、記事の題や著者, 日時,
7			その他の[[メタ情報]]を記述する部分として、頭部は重要な役割を果たしています。
8
9			[3] [[RFC822]] では、頭部は[[頭欄]]の集合として定義されています。
10			頭欄は更に頭欄名と頭欄本体で構成されます。この電子メイルの構造は [[USENET]]
11			のニュース記事, [[HTTP]] メッセージ, [[SIP]] メッセージなどにも流用されています。
12			この WikiPage では RFC 822 的メッセージ形式の頭部全体についての話題を扱います。
13
14			[[#comment]]
15			*ありがちな構造
16			-[[comment]]
17			-[[quoted-string]]
18			-[[encoded-word]]
19			-[[atomとtokenの類]]
20			- [29] [[atom]], [[token]]
21			[[#comment]]
22			*頭部の charset
23			-[4] '''注''': [[Subject:]] 欄の末尾から引越しますた。
24			- [23] [[spam]] なんですけど、本文が [[Content-Type:]] & [[charsetパラメーター]]つきの[[シフトJIS]] (名前が [CODE[shift-jis]] だったが。) で、 [[Subject:]] 欄が生シフト JIS のメッセージがありました。今ではこんなのはあんまり見かけませんが、過去には (特に私信や local newsgroup で) よくあったんじゃないかと思います。
25			- [24] >>23 で、 [CODE[Subject:]] が8ビットで、本文も8ビットだけど本文の [[charset]] が分かっている場合には、その charset を [CODE[Subject:]] にも適用したらどうかなあとか思ったです。
26			- [25] >>23-24 本文はシフト JIS で [CODE[Subject:]] は [[ISO-2022-JP]] ってこともありますから、何も考えずに一律にやってしまうとまずいとは思うんですけど、状況を >>24 くらいに限定すればどうかなと。 (だけど、この類は hard coding しないと実装は困難かなあ。)
27			- [26] >>25 こういう処理を入れてくと条件分岐や option がどんどん増えてってぐちゃぐちゃになって嫌ですよねえ。
28			- [27] >>23-26 spam じゃない普通のメッセージでも、 [[ISO-8859-1]] の生 [[From:]] とかがよくあるね、英語の [[ML]] とか読んでると。やっぱりそういう実装は、 header 全体レベルで、人間可読文字列部分に対して付ける必要がありそう。
29			- [28] >>27 header charset が [[US-ASCII]], [[ISO/IEC2022]], [[ISO-8859-1]], [[UTF-8]] とあって、更に [[encoded-word]] がある状況で、こういうのを全部うまくきれいにまとめて実装するのはとてつもなくしんどそうだ。
30			- [30] [[RFC822]] を見ましたが、 [CODE(ABNF)[field-name]] は [[ASCII]] の一部[[図形文字]]しか使えませんね。ちょっと安心。
31			- [31] >>30 でも [[encoded-word]] (っぽいもの) は書けるね。 [CODE(ABNF)[encoded-word]] として認識してはもらえないけど。
32			[[#comment]]
33			*メモ