smtp/mime
-
SMTP arbeitet auf Systemen, die 7Bit breite pro Zeichen brauchen. Deswegen musst du zB. Zeichensätze die größer sind als 7Bit (also zB. alle Erweiterungen zu ASCII), wieder auf 7Bit runter rechnen. Das macht man mit base64 oder quoted-printable.
Wann was genommen wird ist eigentlich egal.
-
-woher weiss ich dass der zeichensatz meines textes oder anhangs größer als 7bit is?
-gibts irgendwo n codebeispiel oder ne deutsche beschreibung wie man das runterrechnet
-wenn mans auf 7bit kürzt, was macht man dann mit dem letzten bit wegwerfen/weiterschieben oder hinten anhängen?
-
nein, base64 rechnet 8bit auf 7bit runter (3 8Bit Zeichen werden zusammengefasst und auf 6Bit aufgeteilt, das 7.bit wird dann aufgefüllt)
-
Sovok schrieb:
-woher weiss ich dass der zeichensatz meines textes oder anhangs größer als 7bit is?
Text:
7 Bit = ASCII (Zeichen 0 - 127)Alles andere (Text: Extended ASCII, ANSI, Unicode / Binär: sowieso (octet-stream)) -> 8 Bit!
-
Sovok schrieb:
ausserdem wär ne aktuelle liste der Content-Types ned schlecht
die ausm mime rfc is ja ned grade aktuellftp://ftp.isi.edu/in-notes/iana/assignments/media-types/media-types
-
Sovok schrieb:
-gibts irgendwo n codebeispiel oder ne deutsche beschreibung wie man das runterrechnet
http://garbo.uwasa.fi/pc/decode.html
uudecode / encode ist was Du suchst denke ich...
-
@nuke thx
kingruedi schrieb:
nein, base64 rechnet 8bit auf 7bit runter (3 8Bit Zeichen werden zusammengefasst und auf 6Bit aufgeteilt, das 7.bit wird dann aufgefüllt)
aufgefüllt mit 1 oder 0?
is ja einfach... ich frag mich warum die amis seitenweise zeug darüber schreiben das keiner versteht *g*hast du ned lust ne liste mit solchen tollen sätzen für die diversen kodierungen zu schreiben? *bidde bidde bidde*
-
Drück' mal CRC32 oder MD5 in einem Satz aus!
-
crc oder md5 benutzt mime doch garned
Conversion values or Content Transfer Encodings.
7BIT //jedes 8te bit is nutzlos/ascii?
8BIT //1:1 senden/empfangen ?
BASE64 //is klar
BINARY //wie??
QUOTED-PRINTABLE //wie??MIME content-types sind nur zur info des clients und ham nix mit den daten zu tun oder?
wie isses mit den verschiedenen iso typen... was muss man anders machen wenn es statt typ1 typ2 is... wofür sind die diversen isos überhaupt gut?
-
quoted-printable ist genau wie base64 eine Methode um 8Bit Zeichen auf 7Bit abzubilden.
7BIT //jedes 8te bit is nutzlos/ascii?
8BIT //1:1 senden/empfangen ?nein 7Bit ist die richtige Zeichengröße. 8Bit kann SMTP Server oder Mail Clients verwirren. Deswegen gibt es ja Base64 und Quoted-Printable um 8Bit auf 7Bit umzurechnen
-
kingruedi schrieb:
quoted-printable ist genau wie base64 eine Methode um 8Bit Zeichen auf 7Bit abzubilden.
7BIT //jedes 8te bit is nutzlos/ascii?
8BIT //1:1 senden/empfangen ?nein 7Bit ist die richtige Zeichengröße. 8Bit kann SMTP Server oder Mail Clients verwirren. Deswegen gibt es ja Base64 und Quoted-Printable um 8Bit auf 7Bit umzurechnen
heisst dass ich bekomm als client sowieso nie 8bit daten rein? warum gibts das dann überhaupt als mime typ?
unterscheidet sich Quoted-Printable irgendwie von base64?
mit jedes 8te bit is nutzlos meinte ich, ob ich beim empfangen immer 7 bit abgreife , in ein byte stecke, die nächsten 7 bit hole usw. stimmt das ned?
-
Sovok schrieb:
@nuke thx
kingruedi schrieb:
nein, base64 rechnet 8bit auf 7bit runter (3 8Bit Zeichen werden zusammengefasst und auf 6Bit aufgeteilt, das 7.bit wird dann aufgefüllt)
aufgefüllt mit 1 oder 0?
is ja einfach... ich frag mich warum die amis seitenweise zeug darüber schreiben das keiner versteht *g*Schön, wenn das so einfach wäre. Ein paar mehr Regeln gehören da schon zu. Das einfach im Forum zu erkläre, wäre ein bisschen zu kompliziert. Wenn du es ganau wissen willst, dann lies dir die entsprechende RFC durch. Ansonsten such mal bei Google...
kingruedi schrieb:
Wann was genommen wird ist eigentlich egal.
Na ja, das stimmt eigentlich nicht ganz. Für Binär-Daten sollte man Base64 nehmen. Für Text, in dem 8-Bit-Zeichen vorkommen, sollte man Quoted-Printable nehmen. Genau nachzulesen in der entsprechenden RFC.
Sovok schrieb:
kingruedi schrieb:
quoted-printable ist genau wie base64 eine Methode um 8Bit Zeichen auf 7Bit abzubilden.
7BIT //jedes 8te bit is nutzlos/ascii?
8BIT //1:1 senden/empfangen ?nein 7Bit ist die richtige Zeichengröße. 8Bit kann SMTP Server oder Mail Clients verwirren. Deswegen gibt es ja Base64 und Quoted-Printable um 8Bit auf 7Bit umzurechnen
heisst dass ich bekomm als client sowieso nie 8bit daten rein? warum gibts das dann überhaupt als mime typ?
unterscheidet sich Quoted-Printable irgendwie von base64?
mit jedes 8te bit is nutzlos meinte ich, ob ich beim empfangen immer 7 bit abgreife , in ein byte stecke, die nächsten 7 bit hole usw. stimmt das ned?
Binary sind 8-Bit-Daten. Ähnlich wie der Typ 8Bit. Beides ist nur aus Vollständigkeit vorhanden. Man sollte es nicht nutzen, da es Server geben könnte, die noch auf 7-Bit basieren. Das würde dann zu einem undefinierten Verhalten kommen.
Bei Base64 werden alle Bits neu verteilt (so, wie es kingruedi beschrieb). Bei QuotedPrintable werden nur die Daten kodiert, die einen 8-Bit-Wert haben. Das sieht dann ungefähr so aus: M=E4nner bedeutet dann z. B. Männer. (e4 = hexcode vom ä).
Du solltest du am besten folgene RFCs angucken, wenn du eMails erstellen willst:
RFC 822 - Standard for the format of arpa internet text messages
RFC 1521 - MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
RFC 1522 - MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII TextDa ist selber grade daran abeite, schreibe ich mir das z. Z. in einem Tut zusammen. Wird aber noch ein bisschen dauern, bis das fertig sein wird.
Konstantin
-
Na ja, das stimmt eigentlich nicht ganz. Für Binär-Daten sollte man Base64 nehmen. Für Text, in dem 8-Bit-Zeichen vorkommen, sollte man Quoted-Printable nehmen. Genau nachzulesen in der entsprechenden RFC.
das merkt man spätestens wenn man ein Binäry mal mit Quoted-Printable kodiert
> du -h a.out 16K a.out > base64 -e a.out a.out.b64 > qprint -e a.out a.out.qp > du -h a.out.b64 20K a.out > du -h a.out.qp 32K a.out
-
super danke jungs... damit kann ich erstmal ne weile experimentiern
-
noch mehr fragen
-outlook verschickt nunmal 8bit und binary und da mein client auch outlook mails lesen können will wüsst ich gern wie ich mit den daten im vergleich zu 7bit umgehn soll
-was mach ich bei base64 wenn sich die gesamtanzahl der bytes nich durch 3 teilen lässt
-woher weiss ich beim decode von quoted-printable, welche zeichen encoded wurden und welche ned
@konstantin auf das tut freu ich mich jetzt schon
wenn du fertig bist schick mirs bitte als pdf an ez@rebels.com
wenns keine pdf is mach ich gern die konvertierung
-
Sovok schrieb:
-outlook verschickt nunmal 8bit und binary und da mein client auch outlook mails lesen können will wüsst ich gern wie ich mit den daten im vergleich zu 7bit umgehn soll
Das müsste eigentlich egal sein. Zeig die Daten einfach so an, wie du sie bekommst.
Sovok schrieb:
-was mach ich bei base64 wenn sich die gesamtanzahl der bytes nich durch 3 teilen lässt
-woher weiss ich beim decode von quoted-printable, welche zeichen encoded wurden und welche ned
Wie schon geschrieben, kann man das der RFC entnehmen. Da gibt es zu beiden ein paar Rules. Wenn du in englisch nicht so fit bist, kann ich dir das ja mal kurz zusammmenfassen. Da komm ich aber erst am Freitag zu. Morgen hab ich keine Zeit und heute Abend habe ich da keine Lust mehr zu.
Sovok schrieb:
@konstantin auf das tut freu ich mich jetzt schon
wenn du fertig bist schick mirs bitte als pdf an ez@rebels.com
wenns keine pdf is mach ich gern die konvertierungDa ist eigentlich in HTML geplant, um das auf meiner Website zu veröffentlichen. Aber wenn ich fertig bin, können wir da mal drüber reden...
-
ok ich zieh mir erstmal die rfcs rein
btw. was is ein octet?
-
Ein Byte (8 Bit)
-
ach octal->acht... argh warum sagen die ned byte dazu ?
-
weil ein byte nicht ein octet groß sein muss.
(siehe wieder 7Bit vs 8Bit Problematik :))