18

multipart/relatedC ++/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を正しく読んでいませんでしたが、私のパーサーが仕様で定義されているように厳密に機能する場合、パラメーターtypestart-infoパラメーターは単一の文字列またはさらに悪いことにパーサーエラーになります。

みんな、これについてどう思いますか?RFCのタイプミスですか?それとも私は何かを逃しましたか?

ありがとう!

4

2 に答える 2

17

例ではタイプミスです。パラメータは、折りたたまれている場合でも、常にセミコロンで正しく区切る必要があります。折りたたみは、ヘッダーのセマンティクスを変更することを意図したものではなく、読みやすさを考慮し、行の長さに制限があるシステムを説明することだけを目的としています。

于 2010-08-25T23:17:04.330 に答える
1

おそらくタイプミスかもしれませんが、一般的に(そして経験から)、この種のことも「野生で」処理できるはずです。特に、メールクライアントは、有効なメッセージを生成し、関連するすべての仕様に従う能力が大きく異なります(どちらかといえば、電子メール/ SMTPの世界では、WWWの世界よりもさらに悪いです!)

于 2010-06-16T06:26:43.813 に答える