[gelöst] Frage zu Steuerzeichen, CDATA und Kodierung

[INC.]

Hallo!

XML-Dokumente bestechen ja unter anderem auch dadurch, dass man ohne große Kenntnisse deren Aufbau verstehen und Nachbilden kann. Jetzt stellen sich mir aber doch einige Fragen.

1. Es gibt ja diese CDATA Markierungen. Laut Wikipedia dienen diese dazu, den gekapselten Inhalt aufjedenfall als Text anzuerkennen, auch wenn er aus Steuerzeichen besteht.
Wenn ich nun z.B. eine Bücherverwaltung schreiben möchte und auch Buchtitel wie "Math > Me" darin vorkommen, sollte ich dann die Buchtitel im <title>-Element aufjedenfall mit CDATA kapseln?
Also wenn ich den Wiki-Artikel richtig deute, dann aufjedenfall schon. Allerdings habe ich vor kurzem im Netz eine Radiosender-Playlist entdeckt, welche durch PHP aus XML generiert wurde und dann in HTML gegossen wurde. Da waren auch Titel mit "<" dabei, und ich kann definitiv ausschließen, dass in der Quell-XML CDATA benutzt wurde. Warum hat das trotzdem funktioniert? Hat das die entsprechende PHP-Funktion einfach nicht gejuckt, dass das Dokument genaugenommen nicht valid ist?

2. Sind <, > und & alle Steuerzeichen, oder muss man noch auf andere aufpassen? Gilt cdata nur für Element-Inhalte, oder muss man auch Attribute bei Bedarf so kapseln?

3. Sehe ich das richtig, dass man XML-Dateien nicht einfach so erzeugen kann, wenn unbekannte Strings darin gespeichert werden sollen - selbst wenn man CDATA zur Absicherung benutzt?

Was ich mir konkret als Problem vorstelle:
Ich möchte String-Felder aus einer Datenbank in einem XML-Dokument abspeichern, von mir aus mittels PHP. Da die Strings in der Datenbank Steuerzeichen enthalten können, verwende ich in XML also CDATA an den entsprechenden Stellen. Wenn jetzt zufälligerweise ein String aus der DB das CDATA Close-Tag "]]>" enthält, machts aber trotzdem Bumm, oder?
Sprich: automatisch XML generieren ohne vorher den Inhalt zu überprüfen ist nicht drin?

4. Noch eine Frage zur Kodierung. Wenn ich das Dokument in UTF-8 abspeichere, kann es ja Problemlos ä, ö, ü und Co. enthalten.
Wenn jetzt eine aufrufende Stelle das XML zwischenspeichert - allerdings in mit einer anderen Kodierung - dann sind die Umlaute ja dahin (zumindest, solange nicht wieder UTF-8 verwendet wird). Folglich steht irgendein Kauderwelsch da.
Ist es möglich, dass dieses Kauderwelsch (aufgrund der falschen Kodierung) nun zufällig ausgerechnet XML-Steuerzeichen enthält und das Dokument somit invalid macht?
Sprich, das Dokument ist nichtmehr gültig, obwohl nur die Kodierung, nicht aber der Inhalt verändert wurde.



Danke

[wahsaga]

Sind <, > und & alle Steuerzeichen, oder muss man noch auf andere aufpassen?

Doppelte Anführungszeichen und Hochkommata sind ggf. ebenso zu berücksichtigen, wenn sie als Attributwertbegrenzer eingesetzt werden.

Gilt cdata nur für Element-Inhalte, oder muss man auch Attribute bei Bedarf so kapseln?

Das Inhaltsmodell der meisten Attribute ist bereits #CDATA.

Wenn ich nun z.B. eine Bücherverwaltung schreiben möchte und auch Buchtitel wie "Math > Me" darin vorkommen, sollte ich dann die Buchtitel im <title>-Element aufjedenfall mit CDATA kapseln?

Nein, das macht man in der Praxis nicht - man kodiert einfach die ggf. enthaltenen Sonderzeichen, und gut is'.

Sehe ich das richtig, dass man XML-Dateien nicht einfach so erzeugen kann, wenn unbekannte Strings darin gespeichert werden sollen - selbst wenn man CDATA zur Absicherung benutzt?

Natürlich kann man.

Ich möchte String-Felder aus einer Datenbank in einem XML-Dokument abspeichern, von mir aus mittels PHP. Da die Strings in der Datenbank Steuerzeichen enthalten können, verwende ich in XML also CDATA an den entsprechenden Stellen. Wenn jetzt zufälligerweise ein String aus der DB das CDATA Close-Tag "]]>" enthält, machts aber trotzdem Bumm, oder?

]]> beendet den CDATA-Bereich, also wäre an der Stelle eine entsprechende Behandlung dieser Teilzeichenkette, die eine Sonderbedeutung hat, nötig.

Sprich: automatisch XML generieren ohne vorher den Inhalt zu überprüfen ist nicht drin?

"Überprüfen" ist der falsche Ausdruck - kontextgerechte Behandlung ist natürlich erforderlich. Das ist aber immer der Fall, wenn du einen Wert von einem Kontext in einen anderen überführst - also stellt dein Problem hier keineswegs einen Sonderfall, sondern einen absoluten Normalfall dar.

Noch eine Frage zur Kodierung. Wenn ich das Dokument in UTF-8 abspeichere, kann es ja Problemlos ä, ö, ü und Co. enthalten.
Wenn jetzt eine aufrufende Stelle das XML zwischenspeichert - allerdings in mit einer anderen Kodierung - dann sind die Umlaute ja dahin

Dann hat die "aufrufende Stelle" Mist gebaut, ihr Problem.

[combie]

Simplexml und DOM behandeln die Daten korrekt beim einfügen. Also überlass denen das.

Und wenn du deine XML verrückter Weise unbedingt von Hand zusammenklöppeln willst, könnte dir htmlspecialchars() gute Dienste leisten.

[INC.]

Vielen Dank euch beiden.

Doppelte Anführungszeichen und Hochkommata sind ggf. ebenso zu berücksichtigen, wenn sie als Attributwertbegrenzer eingesetzt werden.

Ich würde dich höflichst um ein Beispiel bitten

Das Inhaltsmodell der meisten Attribute ist bereits #CDATA.

Anscheinend ist die Materie doch etwas komplexer, als ich bisher angenommen habe. Ich dachte, als CDATA gilt genau das, was man mit der entsprechenden Notation umklammert. Du meinst, Attribute werden auch ohne entsprechende Ausweisung mit ![CDATA... automatisch so behandelt wie markierte Abschnitte, ohne dass es am Dokument direkt ersichtlich ist?

Nein, das macht man in der Praxis nicht - man kodiert einfach die ggf. enthaltenen Sonderzeichen, und gut is'.

(Hat sich erübrigt).
[COLOR="Silver"]Ich nehme an, mit Sonderzeichen meinst du in diesem Zusammenhang die Steuerzeichen aus XML? Alles andere dürfte ja keinen Ärger machen.
Und was meinst du mit kodieren, etwa ein ä durch irgendeine kryptische (hexa-)dezilmalen-Buchstabenkombination ersetzen oder wie?
Und: Für was braucht man dann die CDATA Schreibweise überhaupt, wenn man das auch ohne lösen kann? Habe jetzt extra nochmal hier nachgelesen, da kommt es auch so rüber, als bräuchte man dieses CDATA.[/COLOR]

]]> beendet den CDATA-Bereich, also wäre an der Stelle eine entsprechende Behandlung dieser Teilzeichenkette, die eine Sonderbedeutung hat, nötig.

Etwa: den vorangehenden CDATA-Bereich durch einfügen von "]]>" aka CDEnd beenden, dann die Teilzeichenkette ]]> ausgeben (welche eben unbewusst identisch ist mit CDEnd), und danach wieder mit ![CDATA... beginnen? So hätte man ]]> "ausgeklammert".

"Überprüfen" ist der falsche Ausdruck - kontextgerechte Behandlung ist natürlich erforderlich. Das ist aber immer der Fall, wenn du einen Wert von einem Kontext in einen anderen überführst - also stellt dein Problem hier keineswegs einen Sonderfall, sondern einen absoluten Normalfall dar.

Stimmt, da hast du natürlich recht. Von einem Sonderfall hab ich allerdings auch nie geredet, aber gut, vielleicht kommt mein ganzer Text so rüber, als sähe ich die Sache als Sonderfall. Nicht beabsichtigt.

Dann hat die "aufrufende Stelle" Mist gebaut, ihr Problem.

Jap, ihr Problem wenn da Textgequirle rauskommt. Das stört mich ja dann auch garnicht, hat der Aufrufer Pech gehabt.
Aber abgesehen davon wäre die Antwort auf die ursprüngliche Frage "ja" (sprich, die Validität eines XML-Docs kann nur durch eine andere Kodierung zerstört werden)? Ist nur so rein aus Interesse.

Simplexml und DOM behandeln die Daten korrekt beim einfügen. Also überlass denen das.

Meinst du durch entsprechendes "Maskieren" mit ![CDATA... oder so wie es wahsaga beschrieben hat? (dieses Kodieren, was ich noch nicht ganz verstanden habe).

Grüße

[combie]

Lesen: SELFHTML: XML / Regeln für XML-Dateien / Zeichen, Zeichenkodierungen und nicht interpretierte Abschnitte

[INC.]

Argh, jetzt suche ich die ganze Zeit auf der w3c-Seite rum aber den wirklich guten Link musst doch du mir liefern, vielen Dank!

@wahsaga: die Frage mit der Kodierung hat sich somit erübrigt. Bleibt noch die Frage, für was es die CDATA-Notation dann gibt.
Und: Bei normalen Umlauten kann ich aber durchaus auf die Vorteile von UTF-8 zurückgreifen und somit ü statt ü* schreiben?

*hier stand eigentlich der dezimale Wert, aber die Boardsoftware wandelt den dann (logischerweise) in ü um.

[mermshaus]

Bleibt noch die Frage, für was es die CDATA-Notation dann gibt.

Na ja, für alle Daten, die potentiell reservierte Zeichen enthalten könnten, die nicht escaped werden sollen/können. Zum Beispiel HTML-Code, der in einem XML-Tag stehen soll.

Die Sache mit der zufälligen CDATA-Endsequenz lässt sich so lösen (Wikipedia):

<![CDATA[[COLOR=green]Inhalt]][/COLOR]]]><![CDATA[[COLOR=green]>Inhalt[/COLOR]]]>

Das bleibt aber eine etwas knifflige Geschichte. (Ich weiß gerade nicht, wie Parser das handhaben. Eigentlich wären das beim Parsen *zwei* CDATA-Tags.) Wenn Escapen aus irgendeinem Grund nicht geht, aber Dateigröße keine entscheidende Rolle spielt, kann man das Problem umgehen, indem man die Daten vor dem Einfügen base64-kodiert. Sonst muss man drumrumprogrammieren.

Und: Bei normalen Umlauten kann ich aber durchaus auf die Vorteile von UTF-8 zurückgreifen und somit ü [...] schreiben

Ja, bei jedem anderen Zeichen außer den paar reservierten auch.

[h3ll]

Wieso überhaupt "per Hand" XML basteln? Gibt doch so viele fertige Funktionen und Klassen von PHP, die nativ sicher schneller laufen, als jeder selbstgeschriebene Code.

[combie]

Habe ich auch schon versucht zu sagen....

Scheint aber nicht zu interessieren. Da wird lieber so ein unwichtiges Detailproblem bis zur vergasung beackert, was man gar nicht hätte, wenn man eine der Klassen nutzen würde.

[INC.]

@mermsmaus: Danke!

@hell und combie

Ich wollte einfach nur verstehen, wie das intern gehandhabt wird. Ist das jetzt schlimm? Die PHP Klassen mögen das vielleicht können, aber diese Sicherheit habe ich an anderer Stelle eventuell nicht. Es war rein aus Interesse - tut mir leid!

[combie]

Muß dir nicht leid tun!
Interesse ist gut! Wissen auch!

Aber in der Praxis wird man eine Klasse nutzen.

aber diese Sicherheit habe ich an anderer Stelle eventuell nicht.

Es gibt keine andere Stelle. Jede (halbwegs moderne) Programmiersprache bringt mittlerweile die dazu notwendigen Tools mit. Es ist gerade das "händische" dran rumfummeln, welches fehlerträchtig ist.