Hans-Juergen Taenzer <[EMAIL PROTECTED]> wrote on 27.03.04:
> Michael Heydekamp ([EMAIL PROTECTED]) wrote:
>> Du k�nntest evtl. ein XPFILTER-Muster bauen, das in Headerzeilen
>> dieses Posters den String "?UTF-8?" durch "?ISO-8859-1?" ersetzt.
>> ;-)
> Das l�st vermutlich nicht das Problem mit dem falschen LEN-Header.
Der etwas scherzhaft gemeinte Hinweis war ohnehin Bl�dsinn, weil
XPFILTER ja gar nicht auf die RFC-Nachricht wirkt (und der ZC-Puffer
enth�lt den String "?UTF-8?" gar nicht mehr).
W�re ersteres der Fall, w�rde dieses Vorgehen allerdings schon das
Problem mit dem LEN-Header beheben.
>>> Mal ne dumme Frage: warum wird denn nicht im Hauptspeicher die
>>> komplette Headerzeile zusammengebaut?
>> Wird sie seit dem Enhanced UUZ doch. Aber nicht alle Routinen, an
>> die die Headerzeile �bergeben wird, sind darauf ausgelegt, sondern
>> arbeiten wie bisher mit Strings. Das gilt insbesondere f�r die
>> diversen Decodierroutinen.
> Und diese ebenfalls umzustellen ist nicht m�glich oder sinnvoll?
Es ist sicher m�glich und vielleicht auch sinnvoll - aber es w�re zu
nicht unerheblichen Teilen ein Rewrite von XP insgesamt.
>>> [...] Oder wird die gleiche Routine auch f�r den Body benutzt?
>> Eben, und das hatte ich ja auch erw�hnt (sonst w�rde ja auch das
>> Problem mit diesem Header gar nicht entstehen, siehe meine
>> Analyse). Und speziell Jochens Fix bezieht sich eigentlich *nur*
>> auf den Body, denn das urspr�nglich damit zu fixende Szenario kann
>> nur dort vorkommen.
> Ist schon ein Gewurschtel mit den 16-Bit bzw. dem arg beschr�nktem
> Speicherplatz unter DOS. ;)
Die Aussage oben hat eigentlich nichts mit 16bit oder dem Hauptspeicher
unter DOS zu tun. Das von Jochen behobene Problem stellt sich
prinzipiell bei 32bit ganz genauso (ob es dort behoben wurde, kann ich
dem Code nicht entnehmen, weil ich mit den umgeschriebenen Sourcen nicht
vertraut bin, man m��te es halt mal testen).
Die Art und Weise von Jochens Fix ist allerdings 16bit-typisch, schon
richtig. Daraus entstehende Probleme - wie eben das, �ber das wir hier
reden - waren im Grunde vorhersehbar, wenn einem die entsprechenden
Szenarien eingefallen w�ren und man sie als praxisrelevant eingestuft
h�tte.
Ich h�tte bis zum Beweis des Gegenteils wohl auch bestritten, da� es
b64-codierte Header gibt, die in ISO-8859-* vorliegen, aber
f�lschlicherweise als UTF-8 deklariert sind.
Im Grunde workarounden wir ja auch mal wieder Bugs anderer Newsreader.
> Aber grad drum ein Kompliment daf�r, da� es in dem allermeisten F�llen
> sauber l�uft.
Ich kenne jedenfalls aktuell keinen UUZ, bei dem es trotz noch sovieler
Bits sauberer liefe. :)
>> Da es bei Dir offenbar pressiert, kann ich Dir aber vorab mal eine
>> lauff�hige Testversion zuschicken, damit Du wenigstens die Gruppen,
>> in denen dieser Poster schreibt, weiterhin beziehen kannst. Falls
>> ich das tun soll, bitte Bescheid geben.
> Ich bitte darum. :)
Kommt heute. Ich suche noch nach dieser omin�sen Formel, von der in
RFC2279 die Rede ist und will noch die saubere Trennung zwischen
einzelnen Headern bzw. zwischen Header und Body insgesamt einbauen.
Wenn ich die Formel nicht finde, tut's die aktuelle Pr�fung auf g�ltige
UTF-8-Sequenzen aber auf jeden Fall schon mal.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
