chl@jabber.at: naja wenn es primär um deutsche texte geht funktioniert das sicher gut
chl@jabber.at: wenn hingegen auch urdu ...
rist: naja sollt doch auch bei französisch, tschechisch und so weiter gehen
rist: da ich din der DB eh alles html escaped speichere
chl@jabber.at: ja, in jeder sprache, die aus us-ascii + ein paar sonderzeichen besteht
rist: naja allesn was ich irgendwie als unicde &#XXX ausdrücken kann müsst gehen - das problem ist ja schlicht und einfach, dass man in xml-rpc nit sauber encodeten text durch
chl@jabber.at: hm, sauber doppelt encodedeter text als string müsst schon problemlos funktionieren
chl@jabber.at: i.e. ü > ü > ü
rist: wie meinst doppelt encodet?
rist: wo liegt der unterschied zwischen ü und ü
chl@jabber.at: oje
chl@jabber.at: jabber und xml ...
rist: oje oje oje
chl@jabber.at: ü > AMPuuml; > AMPamp;uuml;
chl@jabber.at: wobei AMP == &
rist: ok
chl@jabber.at: so empfiehlt es ja auch der wahnsinnige winer
rist: will der winer damit sagen, dass xml-rpc auch nur encodete us-ascii zeichen kennt?
- 15:45 -
chl@jabber.at: xml-rpc selbst kennt gar nix
rist: naja wieso funktioniert das ü denn nit?
chl@jabber.at: der string selbst darf laut spec nur aus us-ascii-zeichen bestehen
rist: naja ü besteht doch aus us-asciI - oder?
chl@jabber.at: naja weil das in der html-dtd definiert is und nicht in der xml-rpc-dtd (die es gar nicht gibt)
chl@jabber.at: NEIN!
chl@jabber.at: ü is eine entity, und die m?ºssen definiert werden
rist: und weil die entity nit definiert ist kennt er sie nit - ok is klar
chl@jabber.at: xml kennt aporiori nur & amp ; und & lt ;
rist: und > chl@jabber.at: ein validierender parser regt sich da furchtbar auf
rist: oje oje oje
chl@jabber.at: läuft im gesicht rot an und motzt recht erheblich
rist: ok - langsam wird mir das klar und verständlich
chl@jabber.at: > - da bin ich mir gar nicht so sicher
chl@jabber.at: a doch - amp, lt, gt, apos, quot
rist: hätt also der winer beschlossen, damals in die nicht existierende xml-rpc-dtt alle unicode entities reinzupacken wär ich nun aus dem schneider
chl@jabber.at: wie das mit numerischen entities is weiss ich nicht
chl@jabber.at: und wie das mit den encodings genau zusammenhängt ebensowenig
rist: ok - ich fasse zusammen - ich krieg meine non-ascii texte am verlässlichsten entweder doppelt encodet oder einfach encoded als base64 auf den server
chl@jabber.at: so isses
rist: einfach encoded und base64
chl@jabber.at: sollt problemlos gehen
chl@jabber.at: auf der server-seite musst halt wieder decoden
rist: ja auf der server seite ist es glaub ich einfacher einen als base64 encodeten html encodeten string zu verarbeiten
chl@jabber.at: wer weiss!
rist: naja das base64 decoden kann ich bereits - im html-string sind nur us-ascii zeichen und dann schrieb ich den html-string in die DB