Protokollsoezifikation für text/html
Tom
Hello,
habe gerade wieder eine Latte Spam und "Halbspam" bekommen; darunter eine HTML-Mail von netzmarkt.de
Guck ich natürlich im Raw-Mode rein und nicht mit "öffnen"...
Die Zeilenlänge im HTML-Bereich
(Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
ist weit über 120 Zeichen. Ist das eigentlich ok? Welche Zeilenlängen gelten denn für den HTML-Bereich? Der sollte doch tunlichst auch bei 76+newline Zeichen aufhören, oder?
Ist 7bit-Codierung für deutsche HTML-Texte überhaupt sinnvoll? Habe aber geschaut, benannte Zeichen sind auch ersetzt worden.
Wie würdet Ihr das mit dem HTML-Bereich halten *rara* Ja, ich weiß schon: weglassen. Aber wenn er da sein muss "weil der Kunde es wünscht"[tm]
Grüße
Tom
Hallo Tom,
Die Zeilenlänge im HTML-Bereich
(Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bitist weit über 120 Zeichen. Ist das eigentlich ok?
Was halt so OK ist.
Welche Zeilenlängen gelten denn für den
HTML-Bereich? Der sollte doch tunlichst auch bei
76+newline Zeichen aufhören, oder?
Zuerstmal sind es 72 Zeichen ;) Und zweitens ist
das eine Konvention, keine Regel. Eine
Uebereinkunft mit Ruecksichtnahme auf User, die
auf Shell-Terminals oder sonstwie nur per Shell
arbeiten.
Ist 7bit-Codierung für deutsche HTML-Texte
überhaupt sinnvoll? Habe aber geschaut, benannte
Zeichen sind auch ersetzt worden.
Im Normalfall wird eine Mail sowieso per 7bit
uebertragen (meist mit quoted printable enkodiert).
Gruesse,
CK
Hello Ihr beiden,
Die Zeilenlänge im HTML-Bereich
einer multipart _eMail_ hatte ich gemeint.
(Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bitist weit über 120 Zeichen. Ist das eigentlich ok?
Was halt so OK ist.
Welche Zeilenlängen gelten denn für den
HTML-Bereich? Der sollte doch tunlichst auch bei
76+newline Zeichen aufhören, oder?Zuerstmal sind es 72 Zeichen ;) Und zweitens ist
Wieso bricht man dann base64-Codierte Bereich nach 76 Zeichen um?
Habe ich mich da verlesen?
das eine Konvention, keine Regel. Eine
Uebereinkunft mit Ruecksichtnahme auf User, die
auf Shell-Terminals oder sonstwie nur per Shell
arbeiten.
Ich denke, die email-Server reagieren da manchmal allergisch, wenn die Zeilenlänge zu groß wird? Kann ich also ruhig alles in einem Stream schicken? Z.B. Bild in Base64 ohne jeglichen Umbruch?
Ist 7bit-Codierung für deutsche HTML-Texte
überhaupt sinnvoll? Habe aber geschaut, benannte
Zeichen sind auch ersetzt worden.Im Normalfall wird eine Mail sowieso per 7bit
uebertragen (meist mit quoted printable enkodiert).
Quoted Printable halte ich dann auch für sinnvoll oder, wenn der Overhead wegen Traffic nicht so schlimm ist, eben base64. Braucht base64 eigentlich mehr, als quoted printable?
Grüße
Tom
Hallo Tom,
Welche Zeilenlängen gelten denn für den
HTML-Bereich? Der sollte doch tunlichst auch
bei 76+newline Zeichen aufhören, oder?Zuerstmal sind es 72 Zeichen ;) Und zweitens
ist
Wieso bricht man dann base64-Codierte Bereich
nach 76 Zeichen um?
Habe ich mich da verlesen?
Weil das in der Base64-RFC so festgelegt wurde ;)
das eine Konvention, keine Regel. Eine
Uebereinkunft mit Ruecksichtnahme auf User, die
auf Shell-Terminals oder sonstwie nur per Shell
arbeiten.
Ich denke, die email-Server reagieren da manchmal
allergisch, wenn die Zeilenlänge zu groß wird?
Nein. Denen is das schnuppe, die kennen keine
Zeilen im DATA-Segment.
Kann ich also ruhig alles in einem Stream
schicken? Z.B. Bild in Base64 ohne jeglichen
Umbruch?
Nein, Base64 schreibt vor, 76 Zeichen max.
Im Normalfall wird eine Mail sowieso per 7bit
uebertragen (meist mit quoted printable
enkodiert).Quoted Printable halte ich dann auch für
sinnvoll oder, wenn der Overhead wegen Traffic
nicht so schlimm ist, eben base64. Braucht
base64 eigentlich mehr, als quoted printable?
Ja.
Gruesse,
CK
Hallo Christian,
Ich denke, die email-Server reagieren da manchmal
allergisch, wenn die Zeilenlänge zu groß wird?Nein. Denen is das schnuppe, die kennen keine
Zeilen im DATA-Segment.
Aha? Wieso steht dann in RFC 2822 folgendes?
| 2.1.1. Line Length Limits
|
| There are two limits that this standard places on the number of
| characters in a line. Each line of characters MUST be no more than
| 998 characters, and SHOULD be no more than 78 characters, excluding
| the CRLF.
|
| The 998 character limit is due to limitations in many implementations
| which send, receive, or store Internet Message Format messages that
| simply cannot handle more than 998 characters on a line.
Das ist - denke ich - ziemlich eindeutig.
Es wird zwar gesagt:
| Receiving
| implementations would do well to handle an arbitrarily large number
| of characters in a line for robustness sake.
Allerdings wird das ganze auch gleich wieder eingeschränkt.
| However, there are so
| many implementations which (in compliance with the transport
| requirements of [RFC2821]) do not accept messages containing more
| than 1000 character including the CR and LF per line, it is important
| for implementations not to create such messages.
Viele Grüße,
Christian
Hallo Christian,
Nein. Denen is das schnuppe, die kennen keine
Zeilen im DATA-Segment.Aha? Wieso steht dann in RFC 2822 folgendes?
[...]
Das ist - denke ich - ziemlich eindeutig.
Oha ;)
Danke. Du hast recht, ich sollte mein Gedaechtnis
auffrischen.
Gruesse,
CK
Helloooooh,
Ich denke, die email-Server reagieren da manchmal
allergisch, wenn die Zeilenlänge zu groß wird?Nein. Denen is das schnuppe, die kennen keine
Zeilen im DATA-Segment.Aha? Wieso steht dann in RFC 2822 folgendes?
[...]
Danke Christian. Das hatte ich gesucht und wusste nicht mehr, was nun stimmt. Durch den Tom-Tom-Tom-Tom-Thread bin ich erst wieder drauf gestoßen und habe meine Doku rausgepult. Leider hatte mein MA damals wohl die kopierte Stelle der RFC wirder zu den RFCs gepackt, statt an sie an der Doku für den Formmailer zu lassen.
Nun denn, dann haben aber die Luete von Netzmarkt noch nichts "gefährliches" gemacht. von ca. 150 Zeichen bis 1000 ist ja noch ein wenig Platz.
Aber ich denke, dann war meine Entscheidung, HTML-Abschnitte auch mit Base64 bei 76 Zeichen wrapped zu versenden nicht falsch. Angesichts der Bilder einer HTML-Mail sind die paar Byte Overhead für den codierten Textbereich dann 0,01 % oder so.
Nun werde ich es aber gleich wieder dranheften. Papier gibts hier noch tonnenweise.
Grüße
Tom
Hallo Tom,
Aber ich denke, dann war meine Entscheidung,
HTML-Abschnitte auch mit Base64 bei 76 Zeichen
wrapped zu versenden nicht falsch.
Nein ;) Der Base64-RFC schreibt es zwingend
vor (RFC 3548):
| 2.1 Line feeds in encoded data
| [...] As such, MIME enforces a limit on line
| length of base 64 encoded data to 76 characters.
Gruesse,
CK
Moin!
Aber ich denke, dann war meine Entscheidung, HTML-Abschnitte auch mit Base64 bei 76 Zeichen wrapped zu versenden nicht falsch. Angesichts der Bilder einer HTML-Mail sind die paar Byte Overhead für den codierten Textbereich dann 0,01 % oder so.
Erstens: Man muß ja keine Bilder mitschicken.
Zweitens: Ein HTML-unfähiger Mailclient, der nur Text anzeigen kann, wird dem Benutzer das base64 nicht decodieren.
Drittens: Es besteht durchaus die Möglichkeit, dass alles base64 als angehängte Datei betrachtet und nervigerweise dann sofort gespeichert wird.
HTML ist text/html, das man nicht base64-encoden muß. base64 ist schließlich 33% größer, als die Originaldaten. Wenn aus 3 Byte dadurch 4 Byte werden, ist das noch egal. Aber irgendwann läppert sich das.
- Sven Rautenberg
Die Zeilenlänge im HTML-Bereich ist weit über 120 Zeichen. Ist das eigentlich ok? Welche Zeilenlängen gelten denn für den HTML-Bereich?
Es gibt bei HTML keine Zeilenlänge. Ist Dir vielleicht noch nicht aufgefallen, aber standardmäßig ist eine Zeile in HTML-Dokumenten immer gerade so lang, wie sie gerade in den jeweiligen Bereich reinpasst.
Ausnahmen sind ein gewollter Umbruch mittels <br /> und der <pre>-Block. Bei letzterem könnte man aber irgendwie auch gleich auf HTML verzichten.
Der sollte doch tunlichst auch bei 76+newline Zeichen aufhören, oder?
Nein, warum? Kein brauchbarer HTML-Parser kennt das ASCII-Zeilenumbruchzeichen, denn alle leeren Zeichen werden definitionsgemäß als Leerzeichen behandelt.
Ist 7bit-Codierung für deutsche HTML-Texte überhaupt sinnvoll?
Wenn's darum geht, was hinten raus kommt: Sicher. Und wenn man sich anschaut, wieviele HTML-Seiten 8-bittig mit falscher Zeichensatzangabe ausgeliefert werden (Stichwort Eurosymbol und Apostroph), könnte es sogar die sinnvollste überhaupt sein, noch vor utf-8.
Falls Du nach Volumenersparnis fragst: Nein.
Gruß,
soenk.e