Joachim Merkel [EMAIL PROTECTED] wrote on 22.07.04:
Michael Heydekamp ([EMAIL PROTECTED]) schreibt:
Schon gar nicht vor dem Hintergrund, daß mir vorschwebt, mit FreeXP
mal ein echtes N/W/* machen zu können, ohne die ursprüngliche
Struktur (Content-Type, Boundary usw.) zu verletzen und durch eine
eigene zu ersetzen. Darauf wäre dann wenigstens der UUZ schon mal
vorbereitet.
Liest sich plausibel, auch der Wunsch nach einem eindeutigen
Boundary-Delimiter wird bisher übergangen.
Der UUZ erzeugt den schon immer bei Binärnachrichten, aus denen er sich
selbst eine MIME-Nachricht backt. Ich habe dessen Form jetzt etwas
angepaßt und die soll später auch in XP Verwendung finden:
--8--
MY:
- (-zu): MIME-Boundary (wird bei der Konvertierung von mit i auf
Userbrett in XP erzeugten Binärnachrichten in eine Multipart-Nachricht
erzeugt) an die in den MIME-Multipart-Routinen von FreeXP verwendete
Fassung angeglichen und als eigene Funktion nach mimedec.pas verlagert
(zwecks späterer Verwendung auch in FreeXP). Das Boundary hat jetzt
die Form -==_FreeXP_Next_MIME_Part_[Zufallsstring]_==-.
UUZ.PAS, UUZ0.PAS, MIMEDEC.PAS
--8--
Änderung gegenüber dem bisherigen Boundary in XP ist der angehängte
Zufallsstring (den der UUZ bei seinem Boundary schon immer benutzt
hat).
Ich bin mir einfach auch noch nicht darüber im klaren, mit welcher
Datenstruktur ich arbeiten soll. Entweder liest man alle Parameter
(Bezeichner und Wert jeweils in einem Record) in eine verkettete
Liste oder sowas ein und baut daraus später wieder den Header
zusammen, oder man behandelt das als einen gesamten String.
Ich verstehe jetzt nicht genau, was Du ansprichst.
Um die Parameter zu parsen hast Du doch den Header komplett
erstmal als String einzulesen.
Klar, aber wie ich die ermittelten Parmeter und deren Werte dann
(weiter)verarbeite, ist die Frage.
Bisher gab es einen MIME-Record, dort war für jeden bekannten Parameter
eine Variable mit fester Länge hinterlegt (siehe 'hd.mime.charset'
z.B.). Dieses Verfahren hat aber den Nachteil, daß man alle
existierenden Parameter auch kennen muß, ansonsten gehen die unbekannten
verloren.
Und alle zu kennen, kann man nie gewährleisten. Also stelle ich mir im
Moment paarige Records mit Bezeichner und Wert vor. In einer
verketteten, dynamischen Liste kann man das speicherschonend - wenn auch
nicht sehr bequem - verarbeiten.
Da ich aber natürlich hier nicht auf einen Pascal-String beschränkt
sein will, läuft's wieder auf ein array of char mit 65500 Zeichen
hinaus. Aber da sehe ich das Problem, wenn sich die Stringlänge
(z.B. beim Austausch von charset=UTF-8 durch
charset=ISO-8859-15) ändern sollte, daß das dann nicht geht, wenn
ich mir vorher nur den Speicher für die aktuelle Länge des Headers
reserviert habe.
Änderungen können vielleicht in verkettete Strings abgespeichert
werden. Zunächst also wird Speicher mit der Länge des vorhandenen
Strings zusätzlich reserviert. Wenn also eine Änderung vorgenommen
wird, wird der String bis an die Stelle kopiert wo die Änderung
vorgenommen wird. Dann wird die Änderung reinkopiert. Wenn diese
länger ist als Speicher angefordert wurde, wird nur der Teil
umkopiert, der reinpaßt, dann wieder dasselbe und nachher wird
alles der Reihe nach auf die Platte geschrieben.
Ich denke eher, daß ich für die paar Parameter, die ggf. angepaßt oder
ausgetauscht werden müssen, zusätzlich eigene Variablen definiere (die
brauche ich ja sowieso, um irgendwo den neuen Wert herzuholen).
Und beim Schreiben des Headers, den man sich aus der verketteten Liste
(s.o.) baut, schaut man dann, wenn man dort z.B. gerade beim Parameter
charset angekommen ist, ob die Variable hd.charset einen Wert hat und
wenn ja, schreibt man diesen Wert, ansonsten den Wert, den man im Record
der verketteten Liste selber findet.
Ich fange einfach mal an, konkret ein paar Dinge zusammenzustellen.
Falls jemand was ergänzen/korrigieren möchte, bitte ich darum. :)
-uz: Content-Type und Content-Disposition parsen und ...
[...]
6) Content-Type und Content-Disposition mit originalem Inhalt
^ soll wahrscheinlich 7) heißen
Ja. Bei 1. habe ich z.B. etwas vergessen:
1) name= oder x-filename= in Content-Type = FILE: (Pfad
entfernen)
wenn Content-Type external-body.
Den Dateinamen im Parameter name= nach FILE: zu schreiben, wäre bei
external-body recht sinnfrei wenn nicht falsch. Die Nachricht enthält
keine Datei.
-zu: U-Content-Type und U-Content-Disposition parsen und ...
[...]
3) Alle Parameter entfernen, die a) bekannt sind und b) im
jeweiligen Kontext nicht standardisiert sind (x-
hingegen erhalten)
(Wollen/können wir das?!?!?)
x--Parameter sollen dem Empfänger bekannt sein, sonst kann man sie
sich sparen.
Das weiß der UUZ in zu-Richtung ja nicht, ob sie dem Empfänger bekannt
sind, also kann er sie nicht einfach entfernen.
Die Frage
