Frank Markopoulos <[EMAIL PROTECTED]> wrote on 26.04.04:
> [EMAIL PROTECTED] (Michael Heydekamp) teilte uns am 25.04.04 mit:
>> Nein, an Installieren dachte ich nicht. Ich brauche nur mal die
>> Nachricht (und am besten im Originalformat).
> Michael, *wenn* ich die MID noch gehabt h�tte,
Ach so... Du sagtest irgendwas davon, der Artikel sei auf dem Server
nicht mehr vorhanden gewesen, deshalb dachte ich, Du k�nntest die noch
haben.
> h�tte ich mir den Artikel schon l�ngst selber �ber Google geholt,
Blo� nicht von Google.
> mit UUZ konvertiert und geguckt, was FreeXP/XP� dann mit dem ZConnect-
> Puffer machen. (Wobei ich mal davon ausgehe, da� Google keine
> Zeilenumbr�che ins Original-Format einf�gt.)
Du kannst bei Google von gar nichts ausgehen - au�er davon, da� Du den
Artikel garantiert nie im Originalformat bekommst.
[Umbrechen von Kammquotings]
>> Was IMO wie gesagt nur zuf�llige Folge eines Bugs sein kann (oder
>> des Unverm�gens, lange Zeilen im Body auch als lange Zeilen zu
>> belassen).
> Hierum ging's. In den Artikel war ein Ausschnitt aus einem eBook mit
> der �blichen Konvention "Hard-CR/LF nur am ABSATZende" von einem
> Windoof- Fuzzi per "Copypaste" eingef�gt worden. Das _hatte_ nat�rlich
> "�berlange Zeilen" (manche sogar > 2000 Zeichen...). Und dann hat sich
> sowohl eine Funktion des OjE gebissen (Hard-Returns manchmal mitten im
> Wort),
Sowas macht der XP2-UUZ auch ganz gerne. Jochen hatte (noch zu Zeiten
von OpenXP/16) mal was eingebaut, da� bei vom UUZ selbst erzeugten
Umbr�chen wenigstens nur zwischen Worten umbrochen wird.
> und zus�tzlich hat eben m�glicherweise der "alte" UUZ aus XP� (oder
> XP� selber - woher soll ich das wissen?)
Einfach: In den Puffer gucken (Backspace auf der Nachricht). Wenn da
die CRLFs schon an den Stellen drin sind, an denen Du sie auch im Lister
siehst, war's der UUZ.
> da was "korrigiert". Jedenfalls war das Ergebnis unter XP�
> anscheinend[*] brauchbarer/lesefreundlicher. Da standen dann n�mlich
> Quotepfeile, wo bei FreeXP keine mehr waren...
Klar, wenn der XP2-UUZ lange Zeilen zerrei�t.
Das mag zwar bei OjE-Nachrichten, die nicht den Usenet-Konventionen
(Textzeilen max. 76 Zeichen lang) entsprechen, zuf�llig mal ganz
praktisch sein, ganz und gar nicht praktisch ist es aber bei den
Nachrichten, die eben diesen Konventionen entsprechen - und daran
orientiert sich FreeXP.
Wenn n�mlich usenet-konforme Nachrichten mal absichtlich lange Zeilen
enthalten (Zeilen aus einem Log, einem Source, Header, URLs u.�.),
w�rden auch diese zerrissen werden. Und das kann nicht gew�nscht sein,
speziell nicht bei URLs. Der Anspruch ist, die Nachricht m�glichst
weitgehend in dem Format in die MsgBase zu importieren, in dem sie im
Original angekommen ist.
Sorry, wegen dieser OjE-Idioten werde ich nicht dem UUZ das Schreiben
unbegrenzt langer Zeilen wieder abgew�hnen, das ich ihm erst m�hsam
beigebracht habe. Entweder lernen die das mal, oder Du mu�t auf die
neue Quoteroutine warten, die dann auch mit sowas umgehen k�nnen soll.
>> Ich darf einfach mal vermuten? Die Konvertierung, die bei Dir
>> stattfindet, ist *nicht* die Konvertierung, wie sie gew�hnlich bei
>> Multiparts stattfindet (und bei der nat�rlich der deklarierte
>> Zeichensatz des jeweiligen Nachrichtenteils korrekt ausgewertet
>> wird), sondern es ist die "stumpfe" ISO=>IBM-Konvertierung, die nur
>> deshalb bei Dir stattfindet, weil Du den Schalter "ISO-Umlaute
>> konvertieren" unter C/O/L aktiviert hast.
> Richtig - das _ist_ aktiviert. Und Du wirst lachen ;-) - damit _habe_
> ich schon "rumgespielt".
> Allerdings nicht in der Hilfe gelesen, und wenn, dann allenfalls mal
> in der von XP�.
In der steht dasselbe, das ist ein uralter Original-Mandrella-Hack, ganz
und gar nix FreeXP-spezifisches. D.h., dieses "Problem" hast Du auch
mit XP2, sofern Du diese Routine auch dort f�r die Konvertierung Deiner
Ex-Multiparts verwendest.
>> ----------8<----------
>> Wenn Sie hier [x] einstellen, konvertiert XP diese
>> Zeichen im Lister und bei Quotes in ein lesbares
>> Format. Ausgenommen ist das gro�e � - es entspricht
>> dem IBM-Grafikzeichen "-" und w�rde in Rahmengrafiken
>> sehr merkw�rdig aussehen.
>> ----------8<----------
>> Und - richtig geraten?
> Ja. Wenn ich C/O/L DEaktiviere, sehe ich "korrekte" Windoofs-Umlaute.
Ok.
> So, und nun zu der o.g. Idee: Wei�t Du eigentlich, da� Rahmengrafiken
> in Mails/News Pfuib�h sind,
Nein, wei� ich nicht. Sagt wer?
Vielmehr ist es sogar so, da� Du in Zeiten von Unicode dessen gesamtes
Zeichenreportoire benutzen kannst, sofern Du es korrekt nach UTF-7 oder
UTF-8 konvertierst/codierst und es auch entsprechend deklarierst.
> und manche Systeme die eh automagisch in ASCII umsetzen?
Alle 16bit-XPs z.B. machen das (bei RFC-Boxen allerdings nur, im Fido
z.B. nicht). Das machen sie aber nicht deshalb, weil Rahmengrafik
"pfuib�h" w�re, sondern schlicht deswegen, weil sie zwar eingehend
UTF-7/8 konvertieren k�nnen (im Rahmen der unterst�tzten Latin-
Zeichens�tze), ausgehend aber nicht.
Langfristig beabsichtige ich, FreeXP auch das beizubringen, eben *damit*
z.B. solche Rahmengrafikzeichen - oder andere Zeichen, die CP437 kennt,
ISO-8859-1/15 aber nicht - nicht mehr konvertiert werden m�ssen.
Wenn Du mal eine Mail mit korrekt UTF-8-codierten Rahmengrafikzeichen
erhalten solltest (OpenXP/32 z.B. erstellt sowas), dann wirst Du BTW
feststellen, da� FreeXP sie auch wirklich in die echten Rahmengrafik-
zeichen wieder decodiert, w�hrend XP2 sie in Fragezeichen umwandelt.
Und auch das wiederum nur, weil es nicht anders kann, und nicht, weil es
irgendwie "besser" w�re.
> Warum dann die R�cksichtname auf dieses "�"?
Diese Frage m��test Du eigentlich Peter stellen, das war schon immer so.
Aber dessen Begr�ndung steht ja in der Hilfe. ;)
Hintergrund ist wohl, da� es wie gesagt eine "stumpfe" Konvertierung
ist, die ohne R�cksicht auf den tats�chlichen Zeichensatz immer
stattfindet und von der man nie wei�, ob sie gerade pa�t. Ist wohl ein
Kompromi�.
>> Normalerweise d�rfte bei dem von Dir beschriebenen Szenario -
>> Nachricht ist keine Multipart mehr - n�mlich gar keine Konvertierung
>> mehr stattfinden. Da� sie �berhaupt stattfindet, ist ein klarer
>> Hinweis darauf, da� Du diesen Schalter aktiviert hast.
> Wowereit!
Sehe ich anders, dieser Schalter ist ein Hack aus grauer Vorzeit, den
man - wenn �berhaupt - nur tempor�r zur halbwegs korrekten Reparatur
defekter (d.h. falsch oder gar nicht deklarierter Nachrichten) einsetzen
sollte.
Wenn, m��te man im Grunde sogar noch eine <F2>-Auswahl anbieten, von
welchem Zeichensatz XP ausgehen soll. Die Zeiten, in denen es nur
CP437, CP850 und ISO-8859-1 gab, sind definitiv vorbei.
Das Prinzip jedenfalls ist: Liegt eine Nachricht nicht in dem
Zeichensatz vor, in dem sie deklariert ist, wird sie logischerweise
falsch dargestellt. Ist keine Deklaration vorhanden, geht XP von
ISO-8859-1 bzw. Win-1252 (was fast dasselbe ist) aus.
Dein Problem liegt aber in der Umwandlung von Multipart nach Singlepart,
und damit hebelst Du die Logik von XP - Singleparts konvertiert der UUZ,
Multiparts der Lister - aus.
>> Deaktiviere den Schalter, mache den Test mit einer echten Multipart,
>> und Du wirst sehen, da� das "�" wie alle anderen Umlaute korrekt
>> dargestellt wird.
> Dann ja.
Siehste. :)
>> Wenn Du aus einer Multipart eine Singlepart machst, ohne dabei auch
>> die zwingend erforderliche Konvertierung selbst vorzunehmen, sondern
>> stattdessen den ISO-Hack von XP benutzt, dann verh�lt sich das
>> nat�rlich auch so wie dokumentiert.
> Ich habe nat�rlich nicht _jeden_ Hilfetetxt gelesen...
Der ist so alt, da� ich vermutete, er k�nnte bekannt sein.
[UKA_PPP kappt Header]
>> Offenbar, obwohl FreeXP den Header nicht einmal foldet. Vielleicht
>> ist die Zeile f�r UKA_PPP zu lang und es schneidet irgendwas ab
>> (�hnlich wie XP3P).
> That seems to be the point. Oder oder es interpretiert irgendwas in
> den References als Steuerzeichen.
Eher unwahrscheinlich.
> Denn _soooo_ lang waren die paar References n�mlich nicht.
Ma gucken...
Na ja, 256 Zeichen halt, das scheint zu "reichen", um UKA_PPP aus dem
Tritt zu bringen.
> Und das war das _allererste_ Mal, bei vielen, vielen Tausend(!)
> Artikeln die ich via UKA_PPP versandt habe (davon 99% Antworten auf
> andere - also mit References, teilweise sogar mit zahlreichen...),
Durchaus m�glich, da� andere UUZ- oder XP-Versionen mehr References
(oder diese fr�her) wegwerfen. Fr�her wurden sie auch gefolded, bei
News jetzt nicht mehr (bei Mails wiederum schon). Andererseits hat
UKA_PPP stellenweise wieder Probleme gerade mit gefoldeten Headern,
bzgl. References wei� ich jetzt nicht genau.
XP selbst wirft ja auch schon welche weg, aber wenn die, die �brig
bleiben, halt jeweils entsprechend lang sind, dann k�nnen sie in der
Summe offenbar eine L�nge ergeben, die UKA_PPP aus dem Tritt bringt.
>> Interessant w�re mal zu wissen, wieviel Zeichen UKA_PPP bei
>> References verkraftet.
> Keine Ahnung. Ganz schlecht dokumentiertes Programm...
Der Source ist die Doku. ;)
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
