Joachim Merkel <[EMAIL PROTECTED]> wrote on 21.07.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schreibt:
>> Aber lassen wir UTF-8 mal beiseite, darum geht's im Moment nicht.
> Ja genau, es war ja wohl auch nur als �berlegung gedacht, wenn
> ich keinen charset habe, ob dann noch UTF-8 was bringt.
Wenn ich wirklich keinen Charset habe, kann ich gar nicht nach UTF-8
codieren, weil ich nicht wei�, welches Zeichen ich gerade codieren soll.
UTF-8 kam mir bzgl. IBM437 nur deshalb in den Sinn, weil dort keine
verlustbehaftete Konvertierung stattfindet (und insofern der Forderung
im ZC-Draft Rechnung getragen wird), und "IBM437" halt zwar kein
unzul�ssiger, aber doch extrem selten verwendeter und vermutlich noch
seltener verstandener Charset im RFC-Umfeld ist.
>> Die Frage war eher, ob man wie bisher "TYP: TRANSPARENT" ignoriert
>> und bei fehlendem CHARSET:-Header weiterhin fr�hlich nach ISO-8859-1
>> konvertiert (weil man bei fehlendem "CHARSET:" von CP437 ausgeht),
>> oder ob man den Wunsch des Erstellers respektiert und die Nachricht
>> so verschickt, wie sie ist (ob als "IBM437" deklariert oder
>> UTF-8-codiert, ist dabei zweitrangig und nahezu gleichwertig, au�er
>> da� "IBM437" viele Programme nicht kennen, weil das kein
>> IANA-registrierter MIME-Alias ist und es f�r CP437 seltsamerweise
>> auch keinen gibt).
> Das war auch meine �berlegung, wenn ich eine Nachricht ohne
> charset bekomme, dann legt mir die ZConnect-Draft nahe, diese
> im ZConnect-Zeichensatz anzuzeigen.
> Ob ich dieser auch noch beim Weiterversand diesen Zeichensatz
> verpassen darf, ist f�r mich eine weitere �berlegung.
D�rfen tut man schon, wenn nicht gar m�ssen (letzteres ist ja das, was
"TYP: TRANSPARENT" signalisiert, wenn ich's nicht ganz falsch verstanden
habe).
> Wenn der Header TYP: gesetzt ist, aber der Bezeichner nicht bekannt
> ist, wird von einer Bin�rnachricht ausgegangen.
>> TRANSPARENT ist aber doch nicht unbekannt...?
> Aber in RFC nicht bekannt.
Ok, aber ich bin ja im Moment der Konvertierung erstmal noch auf
ZConnect-Seite (dort ist die Quelle). Und da kenne ich den Typ.
Den Wert des TYP:-Headers als solchen transportiere ich in der
konvertierten RFC-Nachricht ja gar nicht.
> Also liege ich doch nicht verkehrt, da� eine Nachricht ohne CHARSET,
> aber mit TYP: TRANSPARENT ins RFC-Land als Bin�rnachricht zu versenden
> ist.
Wei� nicht... Ich gehe auch nach nochmaliger Lekt�re davon aus, da� wir
es klarerweise mit einer Textnachricht in IBM437 zu tun haben
(angenommen, CHARSET: existiert nicht). Und die darf eben nicht
(verlustbehaftet) konvertiert werden.
Man m��te wissen, was der genaue inhaltliche Hintergrund dieses Headers
ist. Ich bin bisher davon ausgegangen, da� hier jemand z.B. eines der
beliebten Bildchen aus Rahmen- und Blockgrafikzeichen gebastelt hat, das
bei einer Konvertierung z.B. nach ISO-8859-1 weitgehend zerst�rt w�rde.
Um das zu verhindern, setzt der User "TYP: TRANSPARENT".
Davon ausgehend, n�tzt ein Bin�rtransport in den RFC-Raum insofern
nichts, als da� bei app/o-s der Parameter "charset=" nicht existiert.
Das Zielsystem w��te daher nicht, in welchem Zeichensatz der
Nachrichteninhalt darzustellen ist, geschweige denn, da� es sich
�berhaupt um Text handelt.
Also stellt er die Daten - wenn �berhaupt - z.B. auf einem Windows-
System im lokalen Charset Win-1252 dar und heraus kommt nur Schrott...
Das kann IMO nicht der Sinn von "TYP: TRANSPARENT" sein, zumal dann
besser gleich "TYP: BIN" deklariert worden w�re, dann w�re die Absicht
wenigstens eindeutig.
> Du hast es doch hier nicht mit einem Versand ins ZConnect-Land zu tun,
> sondern stellst Dir eher die Frage, was kann ich tun, damit sie unter
> Umst�nden wenn sie wieder nach ZConnect zur�ckkommt, noch dieselbe
> ist.
Eher stelle ich mir erstmal die Frage, wie ich sie unbeschadet nach RFC
kriege (bzw. ob das �berhaupt das ist, was "TYP: TRANSPARENT" inhaltlich
will).
Aber OK, unter dem Gesichtspunkt R�ckkehr nach ZConnect ist das wieder
was anderes - da h�lfe in der Tat nur bin�r, weil sonst die Gefahr
best�nde, da� sie aus RFC als UTF-8 bei ZConnect ankommt, wo der Inhalt
dann vermutlich als nachhaltig geschrottet empfunden wird. :)
>> Die Frage ist doch genau umgekehrt: Wie soll man eine Nachricht
>> vern�nftig lesen k�nnen, wenn man nicht wei�, in welchem Charset sie
>> vorliegt?
> Genau, da r�t Dir der eine zu reinem Ascii, der andere zu IBM437
> und der n�chste sagt, wenn sie nicht 7-Bit-clean ist, dann nimm
> meinen Standardzeichensatz ISO-8859-1
Deshalb: Bei text/* Charset deklarieren, dann gibt's auch kein Vertun.
>>> Du kannst dann nur noch eine reine Bin�rnachricht draus machen und
>>> application/octet-stream setzen und base64-codieren.
>> Bis auf application/octet-stream alles Transportebene und kein
>> Zusammenhang zu "TYP: TRANSPARENT", IMO. Ob das b64-, qp- oder gar
>> nicht codiert ist, ist in diesem Zusammenhang wumpe und zudem eine
>> Sache, die die MTAs schon aushandeln.
> Ja und wenn die Nachricht wieder nach ZConnect kommt, hat
> sie Zeichensatz ISO1 und der TYP: TRANSPARENT steht nirgendwo.
Den TYP:-Header selbst kannst Du eh nicht r�berretten (ich w��te
jedenfalls nicht, wie). Und wegen ISO1: Ob das verhindert werden mu�
und wie es zu verhindern w�re, ist ja gerade Gegenstand dieses Threads.
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
