Frank Markopoulos <[EMAIL PROTECTED]> wrote on 22.05.04:
> [EMAIL PROTECTED] (Michael Heydekamp) teilte uns am 22.05.04 mit:
>>> Wie bekomme ich die Datei denn eingelesen
>> Puffer kannst Du generell mit X/I/P einlesen, Wenn sie aber im BAD
>> gelandet sind, natuerlich nicht, denn sie sind ja deswegen da
>> gelandet, weil sie nicht OK sind.
> Ich hatte jetzt auch diesen Fall (k�nnte sogar DERSELBE Artikel wie
> bei Harald gewesen sein...) -
Wenn das so ist, ist auch sein Problem bereits behoben.
> mein Puffer (_diesmal_ liegt er mir noch vor ;-) ist an die "dev"-
> Adresse unterwegs (_ohne_ Belgleitkommentar!).
Thx, das hat schon mal geholfen. Kommentar dazu siehe unten.
>> Vermutlich, weil Du eine oder mehrere defekte Nachrichten im Spool
>> liegen hast, und die werden halt nicht geloescht, solange der Puffer
>> nicht korrekt konvertiert und eingelesen wird.
> Du h�ttest Harald auch gleich noch schreiben k�nnen, *wie* es geht:
Das Reparieren mit ZPR behebt aber das eigentliche Problem nicht.
Danach kann man den Puffer zwar einlesen, aber er ist immer noch defekt
decodiert/konvertiert.
>> Also bitte mal die *.MSG oder *.IN, die sich nach einem Netcall bei
>> Dir im Spoolverzeichnis der Box (<XP>\Spool\<Boxname>) befinden, als
>> ZIP herschicken.
> Done. :-)
Ich hab' mir das kurz angesehen: Es geht bei mindestens einem Posting im
Grunde um dasselbe Problem, das auch Hans-J�rgen T�nzer schon vor
einiger Zeit gemeldet hatte und das Anla� f�r einen ziemlich umfassenden
Umbau des UUZ im Bereich Decodierung von UTF-7/8 und qp/base64 war.
Erstmal ist festzuhalten, da� das Posting mit der MsgID
<[EMAIL PROTECTED]>
v�llig defekt ist:
Es ist als UTF-8 deklariert, enth�lt aber nicht nur UTF-8-codierte
Zeichen, sondern einen Mix aus UTF-8 und ganz normalen ISO-Zeichen (die
zus�tzlich qp-codiert sind), z.B. hier:
----------8<----------
> > Wurde sein Linux/Mac/was weiss ich Rechner gehackt, d=FCrfte das wenig
^^^
> > helfen.
>=20
> Bitte ankreuzen, was f=FCr ein anderes OS nicht zutrifft:
^^^
----------8<----------
Da kommt dann wie schon bei Hans-J�rgens Posting, bei dem ein �hnliches
Problem vorlag, die UTF-8-Routine durcheinander und erzeugt u.a.
ZC-Puffer mit einem falschen LEN-Header. Dar�ber hinaus werden die ISO-
Zeichen nat�rlich auch nicht nach IBM konvertiert, weil der UUZ ja von
UTF-8 ausgeht (bisher jedenfalls).
Wer sich solche tollen MsgIDs einfallen l��t, sollte dann wenigstens
nicht selbst so einen Schrott produzieren.
Anyway, davon abgesehen liegt hier nat�rlich auch ein schon l�nger
bestehender Bug (oder eine Nachl�ssigkeit) im UUZ vor, die ich anl��lich
des Reports von HJT vor l�ngerem ausf�hrlich erl�utert hatte und die
inzwischen behoben ist.
Bei diesem Posting kommt zus�tzlich noch das Problem hinzu, da� die
UTF-8-Sequenzen ebenfalls qp-codiert sind. Das ist OK, hat aber den UUZ
bisher veranla�t, zwar eine qp-Decodierung, nicht aber die anschlie�end
erforderliche UTF-8-Decodierung vorzunehmen. Auch das ist nat�rlich
bereits behoben.
Ich wu�te nicht, da� es solche Mix-Postings (UTF-8 und ISO-8859-x)
tats�chlich gibt, aber dann ist die neue UUZ-Routine ja noch viel
realit�tsnaher als ich dachte: Die decodiert n�mlich jetzt nicht nur die
qp-codierten UTF-8-Sequenzen korrekt, sondern konvertiert auch die ISO-
Zeichen, die jetzt als ung�ltige UTF-8-Sequenz erkannt werden, nach IBM
und stellt sie in XP korrekt dar. Das kann vermutlich kein anderer
Newsreader. :)
Ich schicke zum Vergleich mal ein OLD_NEW.ZIP in das dev-Forum (mit
Bezug auf dieses Posting, einfach "#" im Lister dr�cken). Darin ist ein
UUZ_OLD.PUF und ein UUZ_NEW.PUF enthalten. In beiden einfach mal nach
dem String "utf-8" suchen und das Ergebnis des alten und neuen UUZ im
direkten Vergleich betrachten, die Unterschiede sind augenf�llig.
Und nicht wundern - das hier ...
----------8<----------
> Bitte ankreuzen, was f�r ein anderes OS nicht zutrifft:
> [ ] You can�t clean a compromised system by patching it.
^
> [ ] You can�t clean a compromised system by removing the back doors.
^
> [ ] You can�t clean a compromised system by using some 'vulnerability
^
----------8<----------
... ist kein Fehler des UUZ, sondern einfach ein korrekt decodiertes und
konvertiertes "=FF", und das ist in ISO-8869-1 und Windows-1252 nun mal
das Zeichen "�". Im RFC-Original sieht das so aus:
----------8<----------
> Bitte ankreuzen, was f=FCr ein anderes OS nicht zutrifft:
> [ ] You can=FFt clean a compromised system by patching it.
> [ ] You can=FFt clean a compromised system by removing the back doors.
> [ ] You can=FFt clean a compromised system by using some =B4vulnerability
----------8<----------
Warum diese Zeichen da �berhaupt enthalten sind, m��t Ihr den Poster
fragen, KI hat der UUZ noch nicht. ;)
Ich wei�, da� jetzt alle fragen werden, wann denn der neue UUZ
erscheinen wird. Ich schraube noch und wei� nicht, ob ich bis n�chsten
Samstag (da fahre ich in Urlaub) fertig werde. Aber falls nicht, werde
ich auf jeden Fall den aktuellen Stand als Testversion auf den FTP-
Server legen.
Ich bin hier gleichzeitig mit der Umstellung unseres Servers auf Win2K
und der Workstations auf WinXP besch�ftigt und mu� bis Samstag hier auch
was Lauff�higes stehen haben, deshalb habe ich noch weniger Zeit als
ohnehin schon. Ich geb mir M�he, aber ich kann nix versprechen.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
