nicht angemeldet
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.
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
'ü'.
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.
In dem Moment, wo du den String also aus SimpleXML abgreifst, ist relevant, welches Encoding vorliegt. Außerdem ist relevant, wie dieses Encoding dann in das Javascript-Array getan wird, und auf welche Weise das JS-Array ausgeliefert wird.
Aus diesem JS-Array wird dann onload per JS
ein Form mit input-Feldern und den Werten aus dem JS-Array
geschrieben.
Im Browser und in Javascript ist alles Unicode, egal welches Encoding verwendet wurde, denn der Browser wandelt basierend auf der Encoding-Angabe alle erhaltenen Zeichen sowie auch alle Entities (ä) und numerischen Zeichenreferenzen (ü) in eine interne Speicherdarstellung für Unicode-Zeichen.
Wenn dann das Form abgeschickt wird, wird ein neues XML mit
den Werten aus diesem Form geschrieben.
Zu diesem Zeitpunkt wandelt der Browser die eingegebenen Zeichen in das Encoding der Seite (wenn Zeichen eingegeben wurden, die nicht im Encoding darstellbar sind, gehen sie dabei auf unterschiedliche Weise, je nach Browser, kaputt) und steckt sie in den POST- (oder auch GET-)Request.
Wenn ich dann das geschriebene XML erneut auf dem beschriebenen
Web einlese, sind die Umlaute im A****.
Beim Schreiben des XML muss natürlich das Encoding wieder beachtet werden.
Jetzt frage ich mich, an welcher Stelle gehen Sie kaputt
gehen.
Du hast an jeder Stelle, wo das Schriftzeichen den Zustand wechselst, ein potentielles Verlustrisiko.
- Sven Rautenberg