heinetz: Mal wieder Zeichensätze

Beitrag lesen

Moin!

»» das alles ist ziemlich komplex:

War zu befürchten. Deshalb: Encoding-Monokultur, nicht wild wechseln oder umcodieren. Dann geht am wenigsten kaputt. Gegen kaputte Komponenten, die hergestellt wurden von Menschen, die das Prinzip nicht verstanden haben, hilft das allerdings nur bedingt.

»» Ich habe auf dem Frontend der Site einen Flash-Videoplayer
»» eingebaut. Dieser Videoplayer includiert ein TimedText-XML,
»» in dem die Untertitel stehen. Darin ist z.B. ein 'ü' als
»» 'ü' maskiert.

Das ist ja aber nur Lesezugriff auf die Information.

Die Maskierung hat nichts mit UTF-8 zu tun. Die angegebene Zahl ist zwar der Unicode-Codepoint (in dezimaler Schreibweise), aber die eigentlich interessante Frage ist, ob diese Schreibweise wirklich zwingend ist, oder ob ein entsprechend markiertes XML-File ohne diese numerische Zeichenreferenz vom XML-Parser in Flash auch verstanden wird. Dazu muss das XML allerdings korrekt angeben, welches Encoding verwendet wird.

OK, ich versuche neu anzufangen, die Maskierungen im xml
entfernt, "<?xml version="1.0" encoding="UTF-8"?>" in der
ersten Zeile eingefügt und es als utf-8 kodiert abgespeichert.

Soweit sogut, wenn die xml nicht etwa aus dem cache geholt
wird, stellt der flashplayer im Frontend (Darin ist UTF-8
als Zeichensatz angegeben) alle Zeichen richtig dar. OK

»» Für das Backend habe ich eine Pflegemöglichkeit dieser
»» Untertitle gebaut:
»»
»» Aus dem XML wird zunächst ein SimpleXML-Object gebildet
»» und mit den Werten daraus wird dann ein JS-Array in den
»» Quellcode geschrieben. Dort steht dann schon 'ü' statt
»» '&#252;'.

Das ist logisch. Die Schreibweise als numerische Zeichenreferenz wird vom XML-Parser aufgelöst in eine interne Speicherdarstellung des damit gemeinten Zeichens. Welche Form der Speicherung dabei verwendet wird, ist in erster Näherung erstmal irrelevant, solange die Info "intern" bleibt. Interessant wird es aber genau dann, wenn dieser interne Text über ein Interface des XML-Parsers nach außen weitergegeben wird.

Im Backend, wo der Videoplayer auch angezeigt wird, werden
die Sonderzeichen im XML von Flash auch richtig dargestellt.
Die selben Daten durch PHP:simpleXML geparsed und auf der
(nicht UTF-8) Seite in das JS-Array geschrieben und dann
in Input-Felder geschrieben, werden in diesen mit kaputten
Sonderzeichen ausgegeben. Richtig stellen kann ich das,
indem ich vor der Ausgabe PHP:utf8_decode darauf anwende.

Das dürfte in dem Kontext richtig sein, oder ?

Und danach wird es interessant:

Ich rufe durch Abschicken des (POST) Forms ein PHP-Script
auf, dass eine neue Datei (UTF-8-encodiert) anlegen und
die Daten aus POST UTF-8-encodiert dort hineinschreiben
soll.

Das POST-Array vor dem Schreiben mit utf8_encode umzuwandeln
hat geholfen. Das funktioniert also scheinbar.

Jetzt gibt es aber noch einen neuen Fallstrick:

Ich lese das XML im Backend nicht direkt ein, sondert kopiere
es vorher als temp.xml und lese dann das ein. Folgender
Hintergrund:

Beim Abschicken des Formulars wird ein PHP-Skript aufgerufen,
dass das Original.xml mit den Werten aus den Formularfeldern
überschreibt. Zusätzlich habe ich eine Funktionalität gebaut,
die diese Daten nicht durch Abschicken des Formulars, sondern
über einen Ajax.Request an das selbe Skript schickt, dass dann
aber nicht das Original.xml, sondern dass temp.xml schreibt.
So lassen sich die Eingaben testen.

Der einzige Unterschied, den ich mir zwischen dem Abschicken des
Formulars und dem Ajax.Request vorstellen kann, ist, dass der
Absender ein Andrer ist.

tausend dank und

gruesse,
heinetz