Sonderzeichen und CDATA in kml Dateien

[jschoch]

Ich benutze Routeconverter häufig um irgendwelche tracks aus GPS Geräten zu bereinigen (mit Douglas Peucker Algorithmus) und sie dann im kml 4.2 Format zu speichern und später auf einer Webseite mit dem google javascript API anzuzeigen.

Namen von Positionslisten sind ja Freitext und können theoretisch auch Sonderzeichen enthalten. (z.b. franz. Ortsnamen mit Akzenten).
Routeconverter speichert diese in den kml Feldern <name> und <description>.
Wenn darin Zeichen größer ASCII 128 sind, also zum Beispiel Buchstaben mit Akzenten drauf, dann machen die javascript Bibliotheken von Google nicht mehr mit und zeigen den Track nicht auf der Karte an. (Weil dies xml Standards verletzt.)

Solche Sonderzeichen müssen in CDATA gekapselt werden
<name><![CDATA[Text mit Akzenten und Sonderzeichen á Ü é à]]></name>

Ich habe mich bisher immer beholfen, indem ich in die kml Datei mit einem Editor das CDATA hinzugefügt habe. Ist aber auf die Dauer lästig (Außerdem kann ich mir die Nomenklatur nicht merken und muss sie jedes mal nachschauen.)
Könnte Routeconverter diese Feldinhalte nicht automatisch in CDATA verpacken, oder zumindest immer dann, wenn ein Zeichen > Ascii 128 drin ist?

Viele Grüße
Jürgen

[lundefugl]

Hallo Jürgen,

Wenn darin Zeichen größer ASCII 128 sind, also zum Beispiel Buchstaben mit Akzenten drauf, dann machen die javascript Bibliotheken von Google nicht mehr mit und zeigen den Track nicht auf der Karte an. (Weil dies xml Standards verletzt.)

Wie du richtig geschrieben hast, ist KML ein XML-Format . Da es in UTF-8 codiert ist, müssen solche Sonderzeichen nicht zwingend gekapselt werden. Es müssen nur Dinge per CDATA gekapselt werden, die irgendwelche in XML reservierten Zeichen enthalten (z.B. < oder >).

Da ich mal annehme, dass Christian beim schreiben der Files auf eine XML-Bibliothek zurückgreift, dürfte er nur wenig Einfluss darauf haben, ob CDATA geschrieben wird oder nicht. Das entscheidet die Bibliothek selbst.

Ich würde daher mal behaupten, dass die verwendete Google-Library sich nicht 100%ig an den XML-Standard hält. (oder KML sieht zwar wie XML aus - ist aber keins und Google hat das selbst anders definiert).

Gruß
Thomas

[jschoch]

Was die Kodierung von xml in utf8 anbelangt hast du wahrscheinlich recht. Aber die Erfahrung zeigt, dass die kml Dateien vom Google Api 3 nicht angezeigt werden, wenn sie Akzente enthalten.

Habe in routeconverter mal ein > Zeichen ins Namensfeld eingegeben. Dies wird als html entity kodiert: &gt;

Grüße
Jürgen

[lundefugl]

Hallo Jürgen,

Habe in routeconverter mal ein > Zeichen ins Namensfeld eingegeben. Dies wird als html entity kodiert: &gt;

wie ich schon geschrieben habe, entscheiden die XML-Bibliotheken selbst, wie sie die Daten in der Datei schreiben. Nach welchen Regeln dass passiert, bleibt deren Geheimnis. So lange der XML-Standard eingehalten wird, spielt das für den Anwender auch keine Rolle. Hauptsache nach der Codierung/Decodierung kommt wieder der richtige Inhalt heraus. Die Codierung mit &gt; ist genauso legitim (und wahrscheinlich üblicher) wie mit CDATA.

Gruß
Thomas

[routeconverter]

Wenn darin Zeichen größer ASCII 128 sind, also zum Beispiel Buchstaben mit Akzenten drauf, dann machen die javascript Bibliotheken von Google nicht mehr mit und zeigen den Track nicht auf der Karte an. (Weil dies xml Standards verletzt.)

Wie du richtig geschrieben hast, ist KML ein XML-Format . Da es in UTF-8 codiert ist, müssen solche Sonderzeichen nicht zwingend gekapselt werden. Es müssen nur Dinge per CDATA gekapselt werden, die irgendwelche in XML reservierten Zeichen enthalten (z.B. < oder >).

Da ich mal annehme, dass Christian beim schreiben der Files auf eine XML-Bibliothek zurückgreift, dürfte er nur wenig Einfluss darauf haben, ob CDATA geschrieben wird oder nicht. Das entscheidet die Bibliothek selbst.

Korrekt. RouteConverter verwendet JAXB, was wiederum den Standard JDK-Parser für XML verwendet. Mit Kodierung habe ich da nichts zu tun, das erledigt alles der XML-Parser.

Ich würde daher mal behaupten, dass die verwendete Google-Library sich nicht 100%ig an den XML-Standard hält. (oder KML sieht zwar wie XML aus - ist aber keins und Google hat das selbst anders definiert).

Das habe ich auch schon erlebt: Google Earth liest alles mögliche und nicht nur wohlgeformtes KML.

Ich kann mir noch eine weitere Fehlerursache für den Akzent vorstellen: die Kodierung der KML-Datei wird verändert. Wenn im Dateikopf UTF-8 steht, die Datei aber ISO-8859-1 oder Windows-1252 ist, bekommt die Google Maps API falsche Daten serviert. @Jürgen: kannst Du das nochmal überprüfen?

[routeconverter]

Was die Kodierung von xml in utf8 anbelangt hast du wahrscheinlich recht. Aber die Erfahrung zeigt, dass die kml Dateien vom Google Api 3 nicht angezeigt werden, wenn sie Akzente enthalten.

Du meinst damit den KMLLayer?

Habe in routeconverter mal ein > Zeichen ins Namensfeld eingegeben. Dies wird als html entity kodiert: &gt;

Völlig standardkonform: damit kann ein string nicht die Wohlgeformtheit des XML-Dokumentes zerstören.

[jschoch]

Du meinst damit den KMLLayer?

Ich binde folgende Javascript-Dateien in meine Webseite ein:
http://maps.google.com/maps/api/js?sensor=false
http://ajax.googleapis.com/ajax/libs/jqu...ery.min.js

Habe in routeconverter mal ein > Zeichen ins Namensfeld eingegeben. Dies wird als html entity kodiert: &gt;

Völlig standardkonform: damit kann ein string nicht die Wohlgeformtheit des XML-Dokumentes zerstören.

Das ist mir klar und darüber beschwere ich mich ja nicht. Habe es nur mal getestet, weil die vorherige Antwort meinte, es würde daran liegen, dass es nicht funktioniert.

[routeconverter]

Hast Du mal die Kodierung der Dateien überprüft wie oben angesprochen?

[jschoch]

Hast Du mal die Kodierung der Dateien überprüft wie oben angesprochen?

Ja, ist UTF-8, sowohl im ersten xml tag vermerkt als auch de facto, was der Editor anzeigt.