[Allegro] Firefox machts so und IE anders [war: utf8-kataloge ins internet:...]

[Bernhard Eversberg]

Thomas Berger schrieb:
> 
> Worum es urspruenglich ging, war ein Text mit bereits als "%3C" escaptem
> "<", der in PHP nach requesT geschleust wurde: Waere er nicht escaped,
> koennte requestT das escapen uebernehmen. Dass die fragliche Codierung
> aus h-php.apr stammt, hatten Sie behauptet, nicht ich.
> 
Behauptet? Es steht außer Frage.

> 
> Solange PHP im Spiel ist, waere es eine deutliche Vereinfachung, wenn es
> davon ausgehen koennte, dass die zu verarbeitenden Texte "normales" UTF-8
> sind und nicht erst einmal speziell von "gut gemeint" zu "brauchbar"
> rueckgewandelt werden muessen.
> 
Das würde sich theoretisch machen lassen, nur bekommt PHP den Text des
Registerabschnitts nicht als solchen überreicht, sondern bereits
eingebettet in die fertig aufbereitete Seite der Indexanzeige. Diese
landet in der Variablen $output, die av_out() (in av_ini.php)
nicht mehr verändern darf, es sei denn, es würde sie nochmals zerlegen,
analysieren, und nur die betr. Teile dann escapen. Elegant wär das nun
gerade auch nicht. Es reicht den Text einfach weiter.
Nein, es führt kein Weg drumrum: der FLEX-Job muß es machen, und in
diesem Fall eben die Exportparameter. Es sei denn, wir stellten den
Job ganz um und ließen ihn selber die Aufbereitung der HTM-Seite
komplett erledigen, ohne Exportparameter. Das ist jetzt möglich, weil
wir die Umcodierungen ja nun im Job machen können, aber schnell mal
eben ist das nicht zu schaffen.

B.E.