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 "Wollen/können wir das?" bezog sich auf das Entfernen von im
jeweiligen Kontext nicht standardisierter/definierter Parameter. Z.B.
gibt es bei app/o-s den Parameter "padding=", aber eben auch nur dort.
Käme er bei multipart/related vor, könnte man ihn theoretisch entfernen,
weil undefiniert.
Aber auch das würde voraussetzen, daß wir sicher sind, alle Parameter zu
kennen, und da das nicht der Fall ist, ist die Frage nach dem Können IMO
eher mit "nein" zu beantworten.
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
