Falsche Umlautkodierung in /etc/config/crRFD/data/linkData.conf und XMLRPC/getLinks

[jens-maus]

Eine kleine Ungereimtheit ist mir jedoch in der jetzt in den in der WebUI korrekt angezeigten Umlaute bei Direktverknüpfungen noch aufgefallen: Wirft man z.B. einen Blick in die /etc/config/crRFD/data/linkData.conf Datei mittels folgendem Kommando zur Ausgabe der Datei als hexadezimal Werte:

# hexdump -C /etc/config/crRFD/data/linkData.conf | grep pfung | tail -10
00006120  6e c3 83 c2 bc 70 66 75  6e 67 20 42 65 77 65 67  |n....pfung Beweg|
00006300  c2 bc 70 66 75 6e 67 20  45 69 6e 67 61 6e 67 73  |..pfung Eingangs|
000063c0  c2 bc 70 66 75 6e 67 20  45 69 6e 67 61 6e 67 73  |..pfung Eingangs|
000065a0  c2 bc 70 66 75 6e 67 20  45 69 6e 67 61 6e 67 73  |..pfung Eingangs|
000066b0  65 72 6b 6e c3 83 c2 bc  70 66 75 6e 67 20 54 61  |erkn....pfung Ta|
00006880  6b 6e c3 83 c2 bc 70 66  75 6e 67 20 54 61 73 74  |kn....pfung Tast|
000069f0  83 c2 bc 70 66 75 6e 67  20 54 61 73 74 65 72 20  |...pfung Taster |
00006aa0  83 c2 bc 70 66 75 6e 67  20 45 69 6e 67 61 6e 67  |...pfung Eingang|
00006be0  72 6b 6e c3 83 c2 bc 70  66 75 6e 67 20 45 69 6e  |rkn....pfung Ein|
00006ca0  72 6b 6e c3 83 c2 bc 70  66 75 6e 67 20 54 61 73  |rkn....pfung Tas|

Dann fällt auf das die Umlaute hier in der *.conf Datei falsch utf-8 kodiert abgelegt werden. Das ü von "Standardverknüpfung" sollte hier lediglich mit einer 2-byte c3 bc Zeichenfolge kodiert werden. Jedoch sieht man das hier offensichtlich die 4-byte Hexwerte c3 83 c2 bc verwendet werden was wiederum der eigentlich falschen ü Zeichnkette entspricht.

Das erklärt meines Erachtens auch, dass in der 3.63.8.20220330 mit der ungepatchten tcl 8.6 version die Umlaute in der WebUI falsch dargestellt wurden - eben weil sie im Grunde falsch in der conf Datei falsch abgelegt werden und folglich auch via XMLRPC getLinks dann auch falsch ausgeliefert werden. Die WebUI mit der zurückgepatchten tcl 8.6 version (die standardmäßig wieder die 'identity' Zeichenkodierungserkennung verwendet) konvertiert dann diese zwar falsch abgelegten Zeichen jedoch für die WebUI wieder (vmtl. zufälligerweise) in korrekt lesbare Umlaut-Zeichen. Aber im Grunde liegen wie gesagt die Umlaute falsch in der linkData.conf Datei und sollten entweder korrekt als 2-byte utf8 Zeichen abgelegt werden oder als iso8859-1 Zeichen.
Denn ich bin mir relativ sicher, das wenn man sich jetzt via XMLRPC getLinks Kommando die Daten der Direktverknüpfungen inkl. Description ausgeben lassen würde, dann bekommt man sicherlich auch diese falschen Umlautkodierungen zurück und muss die irgendwie anders behandeln bzw. genauso verkurkst zurückkonvertieren wie die WebUI. Nur gibt es eben bisher meines Wissens keine externe App (ausser vllt. Homematic Manager) der die Direktverknüpfungen inkl. Description anzeigt/auswertet und daher ist das bis dato noch nicht wirklich aufgefallen.

Originally posted by @jens-maus in #1782 (comment)

[jens-maus]

Nach kurzem XMLRPC Test zeigt sich zumindest folgendes:

# echo "load tclrpc.so; puts [xmlrpc 'http://127.0.0.1:2001' getLinks]" | tclsh | hexdump -C | grep pfung | tail -1
00002fc0  65 72 6b 6e c3 bc 70 66  75 6e 67 20 54 61 73 74  |erkn..pfung Tast|

# echo "load tclrpc.so; puts [xmlrpc 'http://127.0.0.1:2010' getLinks]" | tclsh | hexdump -C | grep pfung | tail -1
00005ba0  61 72 64 76 65 72 6b 6e  c3 bc 70 66 75 6e 67 20  |ardverkn..pfung |

D.h. zumindest via tclsh xmlrpc kommando scheint (wie erwartet) alles zu passen wenn man sich die Umlaute ausgeben lässt. D.h. die tcl character encoding routinen konvertieren die vermeintlich falsch abgelegten umlaute aus der linkData.conf in die richtige 2-byte UTF-8 kodierung.

[jens-maus]

Und via direkten XMLRPC Abfragen mittels curl ergeben sich folgende Ausgaben:

für BidCos-RF (Port 2001):

# curl -v -H "Content-Type: text/xml" -d "<?xml version='1.0'?><methodCall><methodName>getLinks</methodName><params/></methodCall>" http://127.0.0.1:2001 2>/dev/null | hexdump -C | grep pfung | head -1
000000a0  64 76 65 72 6b 6e c3 bc  70 66 75 6e 67 20 52 61  |dverkn..pfung Ra|

HMIPServer (Port 2010):

# curl -v -H "Content-Type: text/xml" -d "<?xml version='1.0'?><methodCall><methodName>getLinks</methodName><params/></methodCall>" http://127.0.0.1:2010 2>/dev/null | hexdump -C | grep pfung | head -1
00000440  61 72 64 76 65 72 6b 6e  c3 bc 70 66 75 6e 67 20  |ardverkn..pfung |

D.h. entgegen meiner Annahme das es hier wohl gewisse Probleme gibt scheint das praktisch nicht der Fall zu sein.

Einzig alleine der header der zurückgegebenen xml struktur <?xml version="1.0" encoding="iso-8859-1"?> scheint hier eine falsche Kodierung anzugeben weil die zurückgegebenen Daten ja eigentlich UTF-8 kodiert sind wie man in diesen Ausgaben unschwer sehen kann

[jens-maus]

Die finale Frage wäre also (da doch kein schwerwiegendes Problem hier zu existeren scheint):

Wie verhält sich hier die 3.63.8.20220330 Version in dem kontext? Gibt diese z.B. die Umlaute korrekt iso-8859-1 kodiert via rohen xmlrpc getLinks zurück wenn man diese damit nochmal frisch eingibt?!?

[franzfroemel]

Ich bin mir nicht sicher ob das Problem hiermit zu tun hat, aber in der vorherigen Version [3.63.8.20220330] konnte ich Problemlos Umlaute in den Gerätenamen verwenden.
Seit dem Update auf [3.63.9.20220430] werden die neu umbenannten Geräte Teils falsch/Teils richtig angezeigt.

Einstellungen -> Geräte

Status und Bedienung -> Geräte

PS: Hab auch schon über Copy&Paste versucht UTF8, ANSI, 8859-1 codierten Text beim umbenennen zu verwenden, kommt immer auf das gleiche Ergebnis

Nachtrag:
Hab gerade beim Durchklicken gesehen, dass beim neu anlegen von Verknüpfungen jetzt auch die unter der [3.63.8.20220330] angelegten Geräte mit Fehlern bei den Umlauten angezeigt werden. Bin mir ziemlich sicher, dass die vor dem Update richtig angezeigt wurden und die Geräte nach dem Update nicht mehr geändert wurden.

[Baxxy13]

ob das Problem hiermit zu tun hat

Nicht direkt.
Das was du zeigst wurde in #1821 schon angepackt und in #1825 dann nochmal überarbeitet.

[jens-maus]

Ich bin mir nicht sicher ob das Problem hiermit zu tun hat...

In der Tat hat das mit dem hier in diesem Ticket beschriebenem Problem absolut nix zu tun. Das einzige mit was hier vermeintlich gleich ist, sind das es bei beidem um Umlaute geht. Trotzdem gehört das hier nicht rein und wie @Baxxy13 schon sagte wurde das von dir beschriebene Problem bereits in #1821 und dann in #1825 bearbeitet und wird in der nächsten version dann behoben sein (hoffentlich!).

[jens-maus]

Mit der aktuellen 3.63.9.20220521 sieht das ganze nun wie folgt aus:

BidCos-RF:

# hexdump -C /etc/config/rfd/NEQ1631XXX.dev | grep fung
00000440  64 61 72 64 76 65 72 6b  6e fc 70 66 75 6e 67 20  |dardverkn.pfung |

# echo "load tclrpc.so; puts [xmlrpc 'http://127.0.0.1:2001' getLinks]" | tclsh | hexdump -C | grep pfung | tail -1
00002ae0  64 61 72 64 76 65 72 6b  6e fc 70 66 75 6e 67 20  |dardverkn.pfung |

# curl -vvv -H "Content-Type: text/xml" -d "<?xml version='1.0'?><methodCall><methodName>getLinks</methodName><params/></methodCall>" http://127.0.0.1:2001 2>/dev/null | hexdump -C | grep pfung | tail -1
00009d90  64 76 65 72 6b 6e fc 70  66 75 6e 67 20 54 61 73  |dverkn.pfung Tas|

homematicIP:

# hexdump -C /etc/config/crRFD/data/linkData.conf | grep pfung | tail -1
00006b40  76 65 72 6b 6e c3 bc 70  66 75 6e 67 20 54 61 73  |verkn..pfung Tas|

# echo "load tclrpc.so; puts [xmlrpc 'http://127.0.0.1:2001' getLinks]" | tclsh | hexdump -C | grep pfung | tail -1
00002ae0  64 61 72 64 76 65 72 6b  6e fc 70 66 75 6e 67 20  |dardverkn.pfung |

# curl -vvv -H "Content-Type: text/xml" -d "<?xml version='1.0'?><methodCall><methodName>getLinks</methodName><params/></methodCall>" http://127.0.0.1:2001 2>/dev/null | hexdump -C | grep pfung | tail -1
00009d90  64 76 65 72 6b 6e fc 70  66 75 6e 67 20 54 61 73  |dverkn.pfung Tas|

Aus diesen Ausgaben kann man nun folgendes erkennen:

BidCos-RF:

1. in den *.dev Dateien unter /etc/config/rfd wird nun korrekterweise alles ISO-8859-1 kodiert.
2. egal ob via tclrpc oder direktes xmlrpc wird nun korrekterweise alles ISO-8859-1 kodiert zurückgegeben. Das passt nun auch zum <?xml version="1.0" encoding="iso-8859-1"?> response via xmlrpc.

homematicIP:

1. in der /etc/config/crRFD/data/linkData.conf Datei werden die Beschreibungstexte nun korrekterweise als UTF-8 abgelegt (vorher waren hier defekte UTF-8 Kodierungen verwendet).
2. egal ob via tclrpc oder direktes xmlrpc wird nun korrekterweise alles ISO-8859-1 kodiert zurückgegeben. Das passt nun auch zum <?xml version="1.0" encoding="iso-8859-1"?> response via xmlrpc.

Ergo sollten die Änderungen die mit der 3.63.9.20220521 bzgl. Umlaut/ISO-Kodierung einhergekommen sind das hier ursprünglich aufgezeigte Kodierungsproblem in der linkData.conf bzw. via XMLRPC/getLinks beseitigen