nicht angemeldet
Hallo,
Es gibt kein CRLF--, wenn du den Part am Boundary aufgeteilt hast. Es gibt allenfalls noch ein letztes CRLF.
Nicht, wenn man am boundary-String, der vom Browser mitgesendet wird aufgeteilt hat, wie ich. Aber natürlich kann man auch am --$BOUNDARYSTRING aufteilen. Danke für den Hinweis. Ich wusste, dass ich da mal wieder eine Gedanken-Edlos-Schleife im Hirn hatte.
3.2 Übernehmen des Inhalts ab CRLFCRLF bis CRLF-- als Dateiinhalt.
Das ist auch nicht korrekt. Je nach Mimetyp wird der Dateiinhalt codiert. text/plain natürlich nicht.
Bevor ich da jetzt wieder den Wald vor Bäumen nicht sehe, frage ich hier nochmal nach.
Du meinst die 7-Bit-Kodierung für das mailto:-Protokoll?
Ich habe nämlich bei allen meinen bisherigen Versuchen (image/gif, image/jpeg, application/octet-stream) nie einen Content-Transfer-Encoding: header in den Parts gesehen (ja ich habe bisher nur mit IE unter Windows getestet ;-)), will allerdings auch _nur_ HTTP nutzen.
Die Boundary _insgesamt_ ist so zu wählen, dass dieser String nicht im Inhalt vorkommt. Das ist Aufgabe des Browsers. Außerdem steht die gewählte Boundary ja im Header der Multipart-Nachricht. Damit kannst du die einzelnen Teile ja aufsplitten.
Mach/te ich ja ;-)), allerings nicht an "--".concat(boundary), mach ich aber jetzt.
Die Startmarke eines Parts ist "--$BOUNDARYSTRING", das Ende einer Reihe von Parts wird mit "--$BOUNDARYSTRING--" gekennzeichnet. Wozu brauchst du da jetzt noch irgendeine Markierung?
Ja, danke, jetzt brauch ich die nicht mehr.
viele Grüße
Axel