> > nach zwei Polls (RFC) hab ich Probleme mit der Konvertierung der *.MSG > nach ZConnect durch den aktuellen E-UUZ. > > Wie es aussieht, werden LEN-Header falsch generiert. >
Richtig. Allerdings war meine urspruengliche Annahme, es handele sich um einen "klaren" Bug des UUZ, etwas verfrueht. Nachdem ich das jetzt eingehend analysiert habe, liegen die Ursachen in einer Gemengelage aus verschiedenen Umstaenden (erst in Kurzfassung, spaeter Erlaeuterungen dazu): 1. Der Subject:-Header der beiden besagten Postings ist defekt und somit Mitverursacher des Problems. 2. Das Problem existiert UUZ-seitig in dieser Form seit rund 2 Jahren (genauer seit der Version vom 30./31.03.2002). Ursache ist ein Bugfix von Jochen, der sowohl von Robo/XP2 als auch von uns uebernommen wurde (und den man daher auch nicht einfach rueckgaengig machen kann). > > Interessanterweise(?) erzeugt der alte, dem UKAW-Paket beiliegende UUZ: > > ZConnect <-> RFC/UUCP/SMTP Converter with MIME (c) '93-99 PM > XP2-Version v3.30.002 DOS/16 beta (c) 2000 by XP2 Team <[EMAIL PROTECTED]> > 3. Das Fragezeichen ist berechtigt. ;) Dass das Problem mit diesem auf einem aelteren Stand befindlichen UUZ von XP2 nicht auftritt, liegt schlicht daran, dass dieser noch zwei Bugs hat, die zufaelligerweise das durch den defekten Subject:-Header verursachte Problem kompensieren. Es tritt auch mit aelteren UUZs von OpenXP/16 vor dem 30.03.2002 nicht auf. Jetzt etwas ausfuehrlicher (ich habe die uebrigen inzwischen verfassten Beitraege gelesen und eigentlich gehoert das fast schon eher in das Entwickler-Forum, aber ich kann von hier aus kein Xpost und F'up2 setzen und vielleicht ist es ja auch fuer den einen oder anderen User ganz interessant): zu 1.: ------ Der Subject:-Header ist insofern defekt, als dass das vorgeblich b64- und UTF-8-codierte Subject gar nicht UTF-8-codiert ist, sondern ganz schlicht in b64-codiertem ISO-8859-1 oder Win-1252 vorliegt. Eine korrekte Decodierung ist daher nicht moeglich bzw. man koennte wieder nur raten, dass hier ein Fehler auf Seiten des Posters vorliegt. Zum Testen einfach mal das "UTF-8" durch "ISO-8859-1" ersetzen, den rnews-Header anpassen (5 Bytes draufschlagen), ggf. CRLF durch LF ersetzen und mit dem E-UUZ konvertieren - voila. Offenbar hat der Poster in seinem KNode als Zeichensatz UTF-8 eingestellt und nun wird das blind auch dort deklariert, wo es gar nicht zutrifft. HJT, Du solltest den User mal darauf hinweisen, denn den Header duerfte kaum ein Programm "richtig" decodieren koennen. zu 2.: ------ Nun zur Entstehung des Problems mit dem falschen LEN-Header: Jochen hat - weil es mal so ein Szenario im real life gab - seinerzeit einen Fix fuer Faelle eingebaut, in denen ein UTF-8-Multibyte "zerrissen" ist (sich ueber mehrere Zeilen erstreckt). Sowas ist bei base64- oder qp-codierten Texten ein absolut realistisches Szenario, kann aber auch bei extrem und unzulaessig langen encoded words in Headern (die haeppchenweise decodiert wuerden) zum Tragen kommen. Als ich mir vor Monaten diese Sache mal genauer angesehen hatte, dachte ich mir schon "hoffentlich geht das gut". Ich hatte dann Robo auf moegliche Probleme angesprochen, aber der meinte, die Leute sollten gefaelligst korrekt codieren und deklarieren. Na ja, zwei Jahre ging's ja nun auch gut. Allerdings hatte ich keine Probleme mit falschen LEN-Headern vorhergesehen, hoechstens ein paar "falsch" decodierte Zeichen, die aber eben auf falsch codierte/deklarierte Header zurueckzufuehren gewesen waeren. Jochens Fix besteht darin, dass ein evtl. unvollstaendiges Multibyte in einer initialisierten Konstanten 'sc-rest' (siehe Prozedur UTF8ToIBM in mimedec.pas) abgelegt wird, die einmal beim Programmstart initialisiert wird und ihren Wert bis zum jeweils naechsten Eintritt in die Routine behaelt. Kommen jetzt die noch fehlenden Bytes mit dem naechsten Teilstring an, wird sc-rest vor diesen Teilstring kopiert und das Zeichen kann korrekt decodiert werden. Aber eben nur, wenn es auch korrekt bzw. ueberhaupt UTF-8-codiert ist. Ist das nicht der Fall, haengt in der Konstanten 'sc-rest' quasi Muell herum, der bei der naechsten beliebigen UTF-8-Decodierung (ggf. sogar erst bei einer der naechsten Nachrichten!) zu Problemen fuehren kann. Was hier passiert ist, ist nun folgendes: Beim Versuch, nach erfolgter b64-Decodierung beim Wort "Br�che" (zum Glueck konnte ich mir das "�" hier aus dem gequoteten Text besorgen :)) eine anschliessende UTF-8-Decodierung vorzunehmen, hat die Routine erkannt, dass da noch ein paar Bytes fehlen (aus dem ersten Zeichen einer UTF-8-Bytesequenz wird die Anzahl der erforderlichen Bytes der Sequenz errechnet, und im Falle eines "�" kommt die Routine zum Ergebnis, dass die Sequenz 6 Bytes haben muesse). Also wird "�che" in 'sc-rest' abgelegt in der Erwartung, dass mit dem naechsten Teilstring die noch fehlenden Bytes nachgeliefert werden. Die kommen aber nicht, weil sind keine mehr da (Header ist zuende). ;) Auch in den uebrigen RFC-Headern befindet sich kein UTF-8-codiertes Wort mehr, so dass die Routine 'UTF8ToIBM' nicht mehr durchlaufen wird. Nun ist irgendwann der Header abgearbeitet und es kommt der Body dran, der immer zweimal gelesen wird: Beim ersten Mal wird nur die Laenge ermittelt, um den LEN-Header schreiben und den Header damit abschliessen zu koennen, beim zweiten Mal wird er gelesen, um halt den Body an den nunmehr fertigen ZC-Header anhaengen zu koennen. In diesem Fall liegt der Body in UTF-8 vor, also kommen wir mit der ersten Textzeile wieder in "UTF8ToIBM' vorbei. Da wir aber immer noch von eben das "�che" in 'sc_rest' stehen haben und die Routine nix davon weiss, ob wir uns bereits in einem anderen Header oder gar im Body befinden, krallt sich die Routine die ersten beiden Zeichen "Fl" von "Flora Gunn" und versucht nun, die Sequenz "�cheFl" zu decodieren. Dabei kommt letztlich heraus, dass es sich um ein unkonvertierbares Zeichen handelt, die Routine ersetzt die beiden Zeichen "Fl" durch #177 (Platzhalter fuer unkonvertierbare Zeichen) und leert die Konstante 'sc_rest'. Rumms - damit haben wir ein Byte gekillt, ermitteln demzufolge eine um ein Byte zu kurze Laenge und haben den Salat. Beim zweiten Lesen und anschliessenden Schreiben des Body ist 'sc_rest' inzwischen ja wieder leer, daher stimmen ermittelte und geschriebene Laenge nicht ueberein. Zum Fix weiter unten. zu 3.: ------ Wie schon gesagt, verdankt der aeltere UUZ von XP2 (neuere muessten dasselbe Problem haben, aber die habe ich hier nicht zur Hand, der von jgXP hat es aber definitiv) wie auch aeltere OpenXP/16-Versionen das Nichtauftreten dieses Problems zwei eigenen Bugs: a) Bei der Decodierung und Konvertierung von MIME-Headern wird ein deklarierter Charset komplett ignoriert. Ob da "UTF-8" oder "Big5" steht, es wird immer von ISO-8859-1 ausgegangen (eigentlich unglaublich). Genau in diesem Fall passt das aber zufaellig, weil der Header ja in der Tat gar nicht UTF-8-codiert ist. b) Selbst wenn a) nicht der Fall waere, haben die UUZs dieser Generation Jochens oben beschriebenen Bugfix nicht und wuerden auch daher von dem Problem mit dem falschen LEN-Header verschont bleiben (haetten dafuer aber Probleme mit zerrissenen Multibytes). > > Vielleicht kann sich das ja mal jemand anschauen. > Done. Es war schneller analysiert als die Analyse zu verfassen. ;) Ich habe auch bereits diverse Massnahmen getroffen, um diese Probleme zu vermeiden, ohne Jochens Fix komplett eliminieren zu muessen: 1. RFC2279 warnt ausdruecklich davor, den Versuch zu unternehmen, ungueltige Byte-Sequenzen zu decodieren. Da eine UTF-8-Sequenz nie im Leben 7bit-Zeichen enthalten kann, ist bereits bei "�che" eigentlich klar, dass es sich hier nicht um gueltiges UTF-8 handeln kann. Es wird jetzt also auf 7bit-Zeichen geprueft und im Falle des Vorkommens die angeblich inkomplette Byte-Sequenz nicht mehr in 'sc_rest' abgelegt. 2. Enthaelt die inkomplette Byte-Sequenz tatsaechlich nur 8bit-Zeichen, wird sie zunaechst in 'sc_rest' abgelegt. Folgen aber dann im naechsten Teilstring wieder 7bit-Zeichen, die die Sequenz komplettieren sollen, wird 'sc_rest' ignoriert (dann ist der Header eh nicht korrekt codiert). 3. In den Faellen 1. und 2. wird vermutet, dass es sich um einen falsch deklarierten Header bzw. Body handelt und es wird eine ISO=>IBM-Konvertierung vorgenommen. Die Pruefung (und die daraus folgende Aktion) erfolgt fuer jede UTF-8-Bytesequenz einzeln. Was noch zu tun waere: - Pruefen, ob es ausser dem Vorkommen von 7bit-Zeichen noch weitere Kriterien gibt, anhand derer man eine ungueltige UTF-8-Sequenz erkennen kann. Ich habe mich anlaesslich dieses Bugs erstmals etwas naeher mit der Decodierung selbst beschaeftigt und bin da noch keineswegs sattelfest. In RFC2279 wird auch auf den Annex R von ISO-10646 sowie auf den Unicode-Standard 2.0 verwiesen, wo ausfuehrlichere Ausfuehrungen bzw. sogar Routinen enthalten sein sollen. Wenn hier jemand weiterfuehrende Infos beschaffen koennte, wuerde uns das helfen. - Definitiv verworfen werden muss jeder etwaig noch in 'sc_rest' befindliche Inhalt, wenn eine Headerzeile beendet wurde und mit der naechsten weitergemacht wird (und es darf gar kein Rest entstehen, wenn man weiss, dass man sich am Ende eines Headers befindet). Dasselbe gilt, wenn der Header insgesamt beendet und bereits der Body an der Reihe ist. Das wird nur ueber eine unit-weite Variable zu loesen sein (oder ueber einen Parameter, den man aber ueber etliche Routinen mitschleppen muesste). Mit letzterem werde ich mich heute noch beschaeftigen, denn damit waere bereits 100%ig gewaehrleistet, dass keine falschen LEN-Header mehr entstehen *und* keine Zeichen am Ende des Headers mehr verlorengehen koennen. Die Pruefung auf ungueltige Bytesequenzen (so es noch weitere Kriterien als 7bit-Zeichen gibt) waere noch eine zusaetliche, aber nicht zwingend notwendige, Absicherung. Ich bin am Freitag wieder im Buero und hoffe, dass wir am WE eine gefixte UUZ-Version rausgeben koennen. Ich hatte BTW schon vor laengerem in genau dieser Routine einen weiteren Bug gefixt, der aber nur die Decodierung von Multiparts in UTF-8 im Lister betraf (bei Zeilen laenger 510 Zeichen funktionierte Jochens o.a. Fix nicht mehr). Da es hier nur um ein Darstellungsproblem ging, sah ich keine Notwendigkeit, nur deswegen eine neue FreeXP-Version zu veroeffentlichen. Bei einem UUZ, der falsche LEN-Header erzeugt (wenn auch durch Fehler anderer mitverursacht), ist das was anderes. Deshalb lag mir auch daran, dass ich mich sofort drum kuemmere und insofern hat diese Reise auch ihr Gutes. :-) Michael -- Posted via phpBB2 ------------------------------------------------------------------------ FreeXP Support-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
