3. Syntax (Syntax)
3.1. Introduction (Einführung)
Die in diesem Abschnitt angegebene Syntax definiert die legale Syntax von Internet-Nachrichten. Nachrichten, die dieser Spezifikation entsprechen, MÜSSEN der Syntax in diesem Abschnitt entsprechen. Wenn es in diesem Abschnitt Optionen gibt, bei denen eine Option generiert werden SOLLTE, wird dies entweder im Text oder in einem Kommentar neben der Syntax angegeben.
Für die definierten Ausdrücke wird zunächst eine kurze Beschreibung der Syntax und Verwendung gegeben, gefolgt von der ABNF, gefolgt von einer semantischen Analyse. Primitive Tokens, die verwendet, aber nicht anderweitig in diesem Dokument spezifiziert werden, stammen aus den "Kernregeln" von Anhang B.1 der RFC 5234: CR, LF, CRLF, HTAB, SP, WSP, DQUOTE, DIGIT, ALPHA und VCHAR.
In einigen Definitionen gibt es Nicht-Terminale, deren Namen mit "obs-" beginnen. Diese "obs-"-Elemente beziehen sich auf Tokens, die in der veralteten Syntax in Abschnitt 4 definiert sind. In allen Fällen sollten diese Produktionen für die Zwecke der Generierung legaler Internet-Nachrichten ignoriert werden und DÜRFEN NICHT als Teil solcher Nachrichten verwendet werden. Bei der Interpretation von Nachrichten MÜSSEN diese Tokens jedoch als Teil der legalen Syntax berücksichtigt werden. In diesem Sinne definiert Abschnitt 3 eine Grammatik für die Generierung von Nachrichten, wobei "obs-"-Elemente ignoriert werden sollen, während Abschnitt 4 dieser Grammatik hinzufügt, um eine Grammatik für die Interpretation von Nachrichten zu spezifizieren.
Kernkonzepte:
| Konzept | Beschreibung |
|---|---|
| Nachrichtengenerierung | Abschnitt 3 Syntax, obs--Elemente ignorieren |
| Nachrichtenanalyse | Abschnitt 3 + Abschnitt 4, obs--Elemente einschließen |
| obs-Elemente | Veraltete Syntax, DARF NICHT generieren, MUSS aber analysieren |
3.2. Lexical Tokens (Lexikalische Tokens)
Die folgenden Regeln werden verwendet, um einen zugrunde liegenden lexikalischen Analysator zu definieren, der Tokens an Parser höherer Ebene liefert. Dieser Abschnitt definiert die Tokens, die in strukturierten Header-Feld-Bodies verwendet werden.
Hinweis: Leser dieser Spezifikation müssen besonders darauf achten, wie diese lexikalischen Tokens sowohl in der Syntax niedrigerer als auch höherer Ebene später im Dokument verwendet werden. Insbesondere werden die in Abschnitt 3.2.2 definierten Leerzeichen- und Kommentar-Tokens in den Definitionen der hier definierten Tokens niedrigerer Ebene verwendet, und diese Tokens niedrigerer Ebene werden wiederum als Teile der später definierten Tokens höherer Ebene verwendet. Daher können Leerzeichen und Kommentare zwischen Tokens in einer Konstruktion höherer Ebene erlaubt sein, auch wenn sie nicht explizit in einer bestimmten Definition erscheinen.
3.2.1. Quoted characters (Zitierte Zeichen)
Einige Zeichen sind für spezielle Interpretationen reserviert, wie z.B. zur Abgrenzung lexikalischer Tokens. Um die Verwendung dieser Zeichen als nicht interpretierte Daten zu ermöglichen, wird ein Zitierungsmechanismus bereitgestellt.
quoted-pair = ("\" (VCHAR / WSP)) / obs-qp
Wo auch immer ein quoted-pair erscheint, soll es als das einzelne Zeichen interpretiert werden, das durch Entfernen des Backslash erhalten wird. Das heißt, das ""-Zeichen, das als Teil eines quoted-pair erscheint, ist semantisch "unsichtbar".
Hinweis: Das ""-Zeichen kann in einer Nachricht erscheinen, wo es nicht Teil eines quoted-pair ist. Ein ""-Zeichen, das nicht in einem quoted-pair erscheint, ist nicht semantisch unsichtbar. Die einzigen Stellen in dieser Spezifikation, an denen quoted-pair derzeit erscheint, sind in ccontent, qcontent und in obs-dtext in Abschnitt 4.
Beispiele:
Zitierter Backslash: "\\" → Interpretiert als: \
Zitiertes Anführungszeichen: "\"" → Interpretiert als: "
Zitiertes Leerzeichen: "\ " → Interpretiert als: (Leerzeichen)
3.2.2. Folding White Space and Comments (Faltende Leerzeichen und Kommentare)
Leerzeichen, einschließlich derjenigen, die beim Falten verwendet werden (beschrieben in Abschnitt 2.2.3), können zwischen vielen Elementen in Header-Feld-Bodies erscheinen. Außerdem können Zeichenketten, die als Kommentare behandelt werden, als in Klammern eingeschlossene Zeichen in strukturierten Feld-Bodies enthalten sein. Die folgenden Definitionen definieren das faltende Leerzeichen (FWS, Folding White Space) und Kommentar-Konstrukte.
Zeichenketten in Klammern werden als Kommentare betrachtet, solange sie nicht innerhalb eines "quoted-string" erscheinen, wie in Abschnitt 3.2.4 definiert. Kommentare können geschachtelt werden.
Es gibt mehrere Stellen in dieser Spezifikation, an denen Kommentare und FWS frei eingefügt werden können. Um diese Syntax zu unterstützen, wird ein zusätzliches "CFWS"-Token für Stellen definiert, an denen Kommentare und/oder FWS erscheinen können. Wo jedoch CFWS in dieser Spezifikation erscheint, DARF es NICHT so eingefügt werden, dass eine Zeile eines gefalteten Header-Felds vollständig aus WSP-Zeichen und nichts anderem besteht.
FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
; Faltendes Leerzeichen
ctext = %d33-39 / ; Druckbare US-ASCII
%d42-91 / ; Zeichen, nicht einschließlich
%d93-126 / ; "(", ")", oder "\"
obs-ctext
ccontent = ctext / quoted-pair / comment
comment = "(" *([FWS] ccontent) [FWS] ")"
CFWS = (1*([FWS] comment) [FWS]) / FWS
In dieser gesamten Spezifikation, wo FWS (das faltende Leerzeichen-Token) erscheint, zeigt es eine Stelle an, an der Faltung, wie in Abschnitt 2.2.3 diskutiert, stattfinden kann. Wo auch immer Faltung in einer Nachricht erscheint (d.h. ein Header-Feld-Body, der ein CRLF enthält, gefolgt von beliebigem WSP), wird Entfaltung (Entfernung des CRLF) durchgeführt, bevor weitere semantische Analyse auf diesem Header-Feld durchgeführt wird. Das heißt, jedes CRLF, das in FWS erscheint, ist semantisch "unsichtbar".
Kommentar-Beispiel:
From: Pete (A nice \) chap) <[email protected]>
↑ ↑
└── Kommentarbeginn └── Maskierte Klammer
Geparster Anzeigename: Pete
Tatsächliche Mailbox: [email protected]
3.2.3. Atom (Atom)
Mehrere Produktionen in strukturierten Header-Feld-Bodies sind einfach Zeichenketten bestimmter Grundzeichen. Solche Produktionen werden Atome (Atoms) genannt.
Einige strukturierte Header-Feld-Bodies erlauben auch das Punkt-Zeichen (".", ASCII-Wert 46) innerhalb von atext-Läufen. Zu diesem Zweck wird ein zusätzliches "dot-atom"-Token definiert.
atext = ALPHA / DIGIT / ; Druckbare US-ASCII
"!" / "#" / ; Zeichen, nicht einschließlich
"$" / "%" / ; specials. Für Atome verwendet.
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
atom = [CFWS] 1*atext [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
dot-atom = [CFWS] dot-atom-text [CFWS]
specials = "(" / ")" / ; Sonderzeichen, die nicht
"<" / ">" / ; in atext erscheinen
"[" / "]" /
":" / ";" /
"@" / "\" /
"," / "." /
DQUOTE
Sowohl atom als auch dot-atom werden als eine einzelne Einheit interpretiert, die aus der Zeichenkette besteht, die sie bildet. Semantisch sind die optionalen Kommentare und FWS, die die restlichen Zeichen umgeben, nicht Teil des Atoms; das Atom ist nur der Lauf von atext-Zeichen in einem Atom oder die atext- und "."-Zeichen in einem dot-atom.
Beispiele:
Atom-Beispiele:
- john
- example
- user_name
- info+tag
Dot-atom-Beispiele:
- john.doe
- first.middle.last
- [email protected] (für Mailbox-Lokalteil)
3.2.4. Quoted Strings (Zitierte Zeichenketten)
Zeichenketten, die andere Zeichen als die in Atomen erlaubten enthalten, können in einem zitierten Zeichenketten-Format dargestellt werden, bei dem die Zeichen von Anführungszeichen (DQUOTE, ASCII-Wert 34) umgeben sind.
qtext = %d33 / ; Druckbare US-ASCII
%d35-91 / ; Zeichen, nicht einschließlich
%d93-126 / ; "\" oder des Anführungszeichens
obs-qtext
qcontent = qtext / quoted-pair
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]
Ein quoted-string wird als Einheit behandelt. Das heißt, quoted-string ist semantisch identisch mit atom. Da ein quoted-string FWS enthalten kann, ist Faltung erlaubt. Beachten Sie auch, dass, da quoted-pair in einem quoted-string erlaubt ist, die Anführungszeichen- und Backslash-Zeichen in einem quoted-string erscheinen können, solange sie als quoted-pair erscheinen.
Beispiele:
"Joe Q. Public" → Joe Q. Public
"First Last" → First Last
"Giant; \"Big\" Box" → Giant; "Big" Box
3.2.5. Miscellaneous Tokens (Verschiedene Tokens)
Drei zusätzliche Tokens sind definiert: word und phrase für Kombinationen von Atomen und/oder quoted-strings, und unstructured für unstrukturierte Header-Felder und an einigen Stellen innerhalb strukturierter Header-Felder.
word = atom / quoted-string
phrase = 1*word / obs-phrase
unstructured = (*([FWS] VCHAR) *WSP) / obs-unstruct
3.3. Date and Time Specification (Datums- und Zeitspezifikation)
Datums- und Zeitwerte erscheinen in mehreren Header-Feldern. Dieser Abschnitt spezifiziert die Syntax für eine vollständige Datums- und Zeitspezifikation. Obwohl faltendes Leerzeichen in der gesamten date-time-Spezifikation erlaubt ist, wird EMPFOHLEN, dass ein einzelnes Leerzeichen an jeder Stelle verwendet wird, an der FWS erscheint (ob erforderlich oder optional); einige ältere Implementierungen interpretieren längere Sequenzen von faltendem Leerzeichen nicht korrekt.
date-time = [ day-of-week "," ] date time [CFWS]
day-of-week = ([FWS] day-name) / obs-day-of-week
day-name = "Mon" / "Tue" / "Wed" / "Thu" /
"Fri" / "Sat" / "Sun"
date = day month year
day = ([FWS] 1*2DIGIT FWS) / obs-day
month = "Jan" / "Feb" / "Mar" / "Apr" /
"May" / "Jun" / "Jul" / "Aug" /
"Sep" / "Oct" / "Nov" / "Dec"
year = (FWS 4*DIGIT FWS) / obs-year
time = time-of-day zone
time-of-day = hour ":" minute [ ":" second ]
hour = 2DIGIT / obs-hour
minute = 2DIGIT / obs-minute
second = 2DIGIT / obs-second
zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone
Datum-Zeit-Beispiele:
Vollständiges Format:
Date: Fri, 21 Nov 1997 09:55:06 -0600
Date: Mon, 20 Dec 2025 10:00:00 +0800
Ohne Wochentag:
Date: 21 Nov 1997 09:55:06 -0600
UTC-Zeit:
Date: 21 Nov 1997 15:55:06 +0000
3.4. Address Specification (Adressspezifikation)
Adressen erscheinen in mehreren Nachrichten-Header-Feldern, um Absender und Empfänger von Nachrichten anzugeben. Eine Adresse kann entweder eine einzelne Mailbox oder eine Gruppe von Mailboxen sein.
address = mailbox / group
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] /
obs-angle-addr
group = display-name ":" [group-list] ";" [CFWS]
display-name = phrase
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
address-list = (address *("," address)) / obs-addr-list
group-list = mailbox-list / CFWS / obs-group-list
Adress-Beispiele:
Einfache Form (nur Adresse):
[email protected]
Vollständige Form (mit Anzeigenamen):
Alice Smith <[email protected]>
"Joe Q. Public" <[email protected]>
Mehrere Empfänger:
To: [email protected], [email protected]
Gruppenadresse:
To: Development Team: [email protected], [email protected];
3.4.1. Addr-Spec Specification (Addr-Spec-Spezifikation)
Ein addr-spec ist ein spezifischer Internet-Identifikator, der eine lokal interpretierte Zeichenkette enthält, gefolgt vom At-Zeichen ("@", ASCII-Wert 64), gefolgt von einer Internet-Domain.
addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part
domain = dot-atom / domain-literal / obs-domain
domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
dtext = %d33-90 / ; Druckbare US-ASCII
%d94-126 / ; Zeichen, nicht einschließlich
obs-dtext ; "[", "]", oder "\"
Adress-Beispiele:
Standardformat:
[email protected]
[email protected]
Mit zitiertem Lokalteil:
"joe smith"@example.com
Domain-Literal (IP-Adresse):
user@[192.0.2.1]
Zusammenfassung Kapitel 3
Wichtige Syntaxelemente
Nachrichtenstruktur-Hierarchie:
Nachricht (Message)
├── Lexikalische Tokens (Lexical Tokens)
│ ├── atom, quoted-string
│ ├── word, phrase
│ └── comment, FWS
├── Datum-Zeit (Date-Time)
│ └── Day, DD Mon YYYY HH:MM:SS +ZZZZ
└── Adresse (Address)
├── mailbox: name <user@domain>
└── group: name: addr1, addr2;
Implementierungs-Checkliste
- Faltendes Leerzeichen (FWS) korrekt handhaben
- Kommentare (verschachtelte Klammern) unterstützen
- Zitierte Zeichenketten und quoted-pairs analysieren
- Datum-Zeit-Format und Gültigkeit validieren
- Mailbox- und Gruppenadressen analysieren
- Lokalteil und Domain handhaben
- Veraltete Syntax unterstützen (nur analysieren, nicht generieren)
Weiter: 4. Obsolete Syntax (Veraltete Syntax)
Zurück: 2. Lexical Analysis of Messages (Lexikalische Analyse von Nachrichten)