[GELÖST] XML-RPC Response mit ungültigem Zeichen?

[bumaas]

Und wer sagt das das kodiert sein muss?

Nun ja, im Header der Antwort steht:

Code: Alles auswählen

Content-Type: text/xml

ohne weitere Angabe eines speziellen "charset"

Somit kann der Client (hier Postman) das Sonderzeichen nicht darstellen.

Richtig ist es dagegen bei der Methode 'getLinks'. Hier sind die Sonderzeichen (Umlaute) kodiert und der Client stellt sie richtig dar:

[jmaus]

Nun ja, im Header der Antwort steht:

Code: Alles auswählen

Content-Type: text/xml

ohne weitere Angabe eines speziellen "charset"

Und genau das ist ja das ursprüngliche "Problem". Nämlich das die Annahme von Postman bzw. deiner Applikation nämlich nicht zu dem passt was der Server als Response sendet. Postman bzw. deine App scheint wohl immer UTF-8 kodierte Strings anzunehmen. In der Tat werden hier aber wohl auch simple ISO-8859-1 kodierte Strings zurück geliefert.

Somit kann der Client (hier Postman) das Sonderzeichen nicht darstellen.

Richtig ist es dagegen bei der Methode 'getLinks'. Hier sind die Sonderzeichen (Umlaute) kodiert und der Client stellt sie richtig dar:

Nunja, "richtig" stimmt hier wohl auch nicht ganz. Auch getLinks gibt kein charset aus sondern gibt dir im Grunde nur das zurück was in der Device Description von dir ursprünglich mal via WebUI konfiguriert wurde. Und dort ist anscheinend damals eine UTF-8 kodierte Zeichenkette gelandet und die wird jetzt einfach so plain zurück gegeben.

Ergo, du musst im Grunde immer wissen welche Kodierung die jeweilige Antwort auf dein Request hat und dann entsprechend selbst die Dinge umkodieren die du brauchst. D.h. im Falle des UNIT musst du eben von ISO 8859-1 zu UTF-8 umkonvertierten und bei dem getLinks eben nichts weil du in dem Falle von einer UTF-8 Kodierung ausgehen kannst.

In der Tat ist das natürlich etwas unbefriedigend und man kann zumindest darüber diskutieren ob an dieser Stelle man das ganze intern in der ReGa bzw xmlrpc Schnittstelle verbessern könnte in dem z.B. immer auf UTF-8 kodiert wird und dann auch in der response utf8 als Kodierung angegeben wird. Ob das allerdings nun mit älteren Applikationen dann noch läuft oder Inkompatibilitäten erzeugt müsste man dann mal genauer unter die Lupe nehmen.

[bumaas]

Und genau das ist ja das ursprüngliche "Problem". Nämlich das die Annahme von Postman bzw. deiner Applikation nämlich nicht zu dem passt was der Server als Response sendet. Postman bzw. deine App scheint wohl immer UTF-8 kodierte Strings anzunehmen. In der Tat werden hier aber wohl auch simple ISO-8859-1 kodierte Strings zurück geliefert.

In der Tat, so scheint es wohl zu sein. Zumindest in der PHP Library konnte ich finden, dass bei fehlendem charset (aus Kompatibilitätsgründen ) UTF-8 als Zeichensatz genommen wird. Obwohl dies nicht W3C konform ist: es ist für HTTP 1.0 und 1.1 klar geregelt, dass ISO-8895-1 der Standard ist...

Auch getLinks gibt kein charset aus sondern gibt dir im Grunde nur das zurück was in der Device Description von dir ursprünglich mal via WebUI konfiguriert wurde. Und dort ist anscheinend damals eine UTF-8 kodierte Zeichenkette gelandet und die wird jetzt einfach so plain zurück gegeben.

Dem möchte ich jedoch widersprechen. In den Rohdaten sieht man, dass die Umlaute kodiert ('Zeichen-Entität-Referenzen') sind. Insofern gibt es da mit dem Zeichensatz keine Probleme.

Ich habe jetzt für die von mir benutzte Library mal den Defaultzeichensatz umgesetzt

Code: Alles auswählen

$GLOBALS['xmlrpc_detectencodings'] = 'ISO-8859-1';

und siehe da, beide Methoden liefern nun das korrekte Ergebnis

Von daher sieht es nun so aus, dass alle Sonderzeichen korrekt kodiert sind: entweder als ISO-8859-1' oder durch Referenzen. Irritierend ist leider, dass es nicht einheitlich erfolgt.

In der Tat ist das natürlich etwas unbefriedigend und man kann zumindest darüber diskutieren ob an dieser Stelle man das ganze intern in der ReGa bzw xmlrpc Schnittstelle verbessern könnte in dem z.B. immer auf UTF-8 kodiert wird und dann auch in der response utf8 als Kodierung angegeben wird. Ob das allerdings nun mit älteren Applikationen dann noch läuft oder Inkompatibilitäten erzeugt müsste man dann mal genauer unter die Lupe nehmen.

Eine Umstellung der Kodierung ist eigentlich nicht notwendig. Einfacher und deutlicher wäre es, wenn im Header die verwendete Codierung (nämlich ISO-8859-1) mitgegeben würde. Dann wäre für Postman und die PHP Library alles klar gewesen. Das könnte doch überlegt werden, ohne in Kompatibilitätsprobleme zu kommen.

Also ich für meine Person habe es ja nun verstanden und kann damit leben

Besten Dank für eure Unterstützung!

Burkhard