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. >> Und Deine Frage war ja wohl, was ist, wenn diese Angabe fehlt. > 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. >>>> Wie sich das auf den UUZ auswirkt oder auswirken m��te, wenn der >>>> TYP: TRANSPARENT zu einem CTE binary f�hrt, kann ich auch nur >>>> vermuten. >>> Einen Zusammenhang zu CTE binary sehe ich nicht, das ist >>> Transportebene. >> Die Bin�rnachricht mit textueller Struktur kannst Du Dir nur >> erlauben, wenn der Transportweg voll bin�rf�hig ist. > Sorry, ich komme nicht mit, was das mit Bin�rnachrichten zu tun hat. > Ich spreche von einer ganz normalen 8bit-Textnachricht, die der > Autor nicht zu konvertieren w�nscht und das deshalb mit "TYP: > TRANSPARENT" kenntlich macht. Wenn der Header TYP: gesetzt ist, aber der Bezeichner nicht bekannt ist, wird von einer Bin�rnachricht ausgegangen. >> Sobald Du ZConnect verl��t und nicht voll "tunnelst", gilt jetzt >> aus RFC-Sicht (!) die Festlegung von ZConnect, da� unbekannte >> TYP:-Header als reine Bin�rnachrichten zu betrachten sind. > TRANSPARENT ist aber doch nicht unbekannt...? Aber in RFC nicht bekannt. Also liege ich doch nicht verkehrt, da� eine Nachricht ohne CHARSET, aber mit TYP: TRANSPARENT ins RFC-Land als Bin�rnachricht zu versenden ist. 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. >>> Auf jeden Fall, wenn es sich um eine Textnachricht handelt. Gar >>> keinen Charset zu deklarieren, w�re schlicht falsch. >> Halte ich f�r etwas �bertrieben, > Das ist Gesetz, und zwar ein unumst��liches (RFC2076). Nat�rlich > ist der Parameter als solcher optional, aber wenn er nicht > existiert, ist es per Definition US-ASCII. Was in der Praxis i.d.R. > dazu f�hrt, da� bei Nachrichten ohne deklarierten Charset der lokale > Zeichensatz verwendet wird. Tja. >> der eine hat dann ISO-8859-1 als Standardzeichensatz der andere >> IBM437. > Eben - und genau deshalb braucht man eine Charset-Deklaration. Nur > dann kann man ggf. lokal korrekt konvertieren. >> Wie soll das unter einen Hut gebracht werden? > Was, wie? Eben doch *durch* die Charset-Deklaration. > 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 > Ich bin jetzt ein bi�chen verwirrt, weil wir hier gerade �ber die > Grundlagen von Zeichensatzkonvertierung und MIME reden, die ich > eigentlich abgehakt hatte und um die es mir auch gar nicht ging. Ich versuche das nur irgendwie einzusortieren. >> 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. -- Salut _)oachim ------------------------------------------------------------------------ FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
