multipart/related
C ++/Qtでの基本的なMIMEパーサーを実装しようとしています。
これまで、ヘッダー用の基本的なパーサーコードをいくつか作成してきました。また、RFCを読んで、すべてを仕様にできるだけ近づける方法を理解しています。残念ながら、RFCには、私を少し混乱させる部分があります。
RFC882セクション3.1.1から:
各ヘッダーフィールドは、フィールド名とフィールド本体で構成されるASCII文字の単一の論理行として表示できます。便宜上、この概念エンティティのフィールド本体部分は、複数行の表現に分割できます。これは「折りたたみ」と呼ばれます。一般的な規則として、線形空白(単にLWSP文字ではない)がある場合は、代わりにCRLFの直後に少なくとも1つのLWSP文字を挿入できます。したがって、単一の行
了解しました。ヘッダーフィールドを解析し、CRLFの後に線形空白が続く場合は、それらを便利な方法で連結して、単一のヘッダー行を作成します。先に進みましょう...
RFC2045セクション5.1から:
RFC822のAugmentedBNF表記では、Content-Typeヘッダーフィールド値は次のように定義されています。
content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; Matching of media type and subtype
; is ALWAYS case-insensitive.
[...]
parameter := attribute "=" value
attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.
value := token / quoted-string
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>
わかった。したがってContent-Type
、パラメータを使用してヘッダーを指定する場合は、次のように実行するだけです。
Content-Type: multipart/related; foo=bar; something=else
...そして同じヘッダーの折りたたまれたバージョンは次のようになります:
Content-Type: multipart/related;
foo=bar;
something=else
正しい?良い。RFCを読み続けると、RFC2387セクション5.1(例)で次のことに気づきました。
Content-Type: Multipart/Related; boundary=example-1
start="<950120.aaCC@XIson.com>";
type="Application/X-FixedRecord"
start-info="-o ps"
--example-1
Content-Type: Application/X-FixedRecord
Content-ID: <950120.aaCC@XIson.com>
[data]
--example-1
Content-Type: Application/octet-stream
Content-Description: The fixed length records
Content-Transfer-Encoding: base64
Content-ID: <950120.aaCB@XIson.com>
[data]
--example-1--
うーん、これは奇妙です。Content-Type
ヘッダーが見えますか?いくつかのパラメータがありますが、すべてに「;」があるわけではありません。パラメータ区切り文字として。
たぶん私はRFCを正しく読んでいませんでしたが、私のパーサーが仕様で定義されているように厳密に機能する場合、パラメーターtype
とstart-info
パラメーターは単一の文字列またはさらに悪いことにパーサーエラーになります。
みんな、これについてどう思いますか?RFCのタイプミスですか?それとも私は何かを逃しましたか?
ありがとう!