Ich versuche, einen grundlegenden MIME-Parser für die multipart/related in C++/Qt zu implementieren.MIME RFC "Content-Type" Parameter Verwirrung? Unklare RFC-Spezifikation
Bis jetzt habe ich einige grundlegende Parser-Code für Header geschrieben, und ich lese die RFCs, um eine Idee zu bekommen, wie alles so nah wie möglich an die Spezifikation zu tun. Leider gibt es einen Teil in der RFC, die mir ein wenig verwirrt:
Von RFC882 Abschnitt 3.1.1:
kann jedes Header-Feld als eine einzige, logische Zeile von ASCII-Zeichen betrachtet werden, eine umfassend Feldname und ein Feldkörper. Der Einfachheit halber kann der Feldkörperabschnitt dieser konzeptionellen Entität in eine Mehrfachliniendarstellung aufgeteilt werden; Diese heißt "Faltung". Die allgemeine Regel ist, dass dort, wo linear-weisser Raum sein kann (NICHT einfach LWSP-Zeichen), eine CRLF unmittelbar gefolgt von ATLEAST ein LWSP-Zeichen stattdessen eingefügt werden kann. Somit ist die einzige Zeile
Okay, so analysiere ich einfach ein Kopffeld und wenn ein CRLF mit linearen Leerzeichen folgt, habe ich einfach Concat die in nützlicher Weise in einer einzigen Kopfzeile zu führen. Lassen Sie uns gehen ...
Von RFC2045 Abschnitt 5.1:
In der Augmented BNF-Notation von RFC 822 wird ein Content-Type-Header-Feld Wert wie folgt definiert:
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>
Oka y. So ist es, wenn Sie scheint ein Content-Type Header mit Parametern angeben möchten, tun Sie es einfach so:
Content-Type: multipart/related;
foo=bar;
something=else
:
Content-Type: multipart/related; foo=bar; something=else
... und eine gefaltete Version des gleichen Header würde wie folgt aussehen Richtig? Gut. Als ich die RFCs las weiter, ich auf die folgenden kam in RFC2387 Abschnitt 5.1 (Beispiele):
Content-Type: Multipart/Related; boundary=example-1
start="<[email protected]>";
type="Application/X-FixedRecord"
start-info="-o ps"
--example-1
Content-Type: Application/X-FixedRecord
Content-ID: <[email protected]>
[data]
--example-1
Content-Type: Application/octet-stream
Content-Description: The fixed length records
Content-Transfer-Encoding: base64
Content-ID: <[email protected]>
[data]
--example-1--
Hmm, das ist seltsam. Siehst du den Header Content-Type? Es hat eine Reihe von Parametern, aber nicht alle haben ein ";" als Parameterbegrenzer.
Vielleicht habe ich gerade gelesen, nicht die RFCs richtig, aber wenn mein Parser streng wie die Spezifikation definiert arbeitet, die type und start-info Parameter in einem einzelnen String oder noch schlimmer, ein Parser-Fehler führen würden.
Jungs, was denken Sie darüber? Nur ein Tippfehler in den RFCs? Oder habe ich etwas vermisst?
Danke!
Wenn Sie mit solchen Standards arbeiten, sollten Sie immer tolerant sein beim Lesen der Eingabe und streng beim Schreiben der Ausgabe. – Gumbo
Es ist ein Tippfehler in den Beispielen. Parameter müssen immer mit Semikolon korrekt abgegrenzt werden, auch wenn sie gefaltet sind. Die Faltung ist nicht dazu gedacht, die Semantik eines Headers zu ändern, nur um Lesbarkeit zu ermöglichen und um Systeme mit Zeilenlängenbeschränkungen zu berücksichtigen. –
@Remy Lebeau: Warum postest du es nicht als Antwort, also kann ich es akzeptieren? Ich habe versucht, den ursprünglichen Autor des RFC zu kontaktieren, aber sie haben nicht so weit geantwortet. – BastiBen