Tag zusammen,
ich spiele gerade mal wieder mit Umlauten in Alias-Attributen. Dabei ist mir in FHEM ein etwas seltsames Verhalten aufgefallen:
Ich habe mir zum testen einen Dummy gebaut:
define a dummy
Anschließend ein Umlaut als alias:
attr a alias öäü
Das funktioniert einwandfrei.
Nun ein paar Umlaute:
attr a alias ÖÄ
Auch hier, einwandfrei.
Jetzt kommt der Hammer:
attr a alias Ü
Jetzt hängt das Terminal-Fenster FHEM. Keine Regung mehr. Schließt man das Fenster und zeigt anschließend den Alias-Wert an, so ist dieser _leer_.
Macht man das Ganze mit
attr a alias ÄÜ
so findet sich im Inhalt des Alias-Attributes danach der Wert 'Ä'. Ü funktioniert augenscheinlich nicht.
Es kommt noch seltsamer. Liest man sich die UTF-8 Characters einzeln für das vorher gesetzte "ÄÜ" aus, so findet sich folgende Folge wieder:
0xc3 0x84 0xc3
0xc3 0x84 ist laut Tabelle ein großes Ä - das passt.
0xc3 ist nichts. Das gibt es so nicht. Ein Ü wäre ein 0xc3 0x9c. Das findet sich nicht.
Kann damit jemand etwas anfangen? Das sieht verdammt nach einem Umwandlungsfehler in irgendeinem Regexp aus.
Viele Grüße und vielen Dank!
Matthias
Edit:
ÜÄ als Alias zu setzen ist auch ganz nett. Das ergibt die Hex-Folge c3 c3 84 - das kann die Konsole nicht mehr parsen und stellt ein nettes Fragezeichen dar :-).
Da du scheinbar Terminal (also die telnet Schnittstelle) verwendest: hast du das FHEM encoding Befehl abgesetzt, und mit welchen Parametern? Welches encoding verwendet dein Terminal?
Hi,
nein, das Encoding ist auf Default. Standardmäßig nützt FHEM UTF-8, oder? Das hatte ich letztens in einem Beitrag gelesen. Die Konsole ist UTF-8 - Linux default.
Matthias
ich hab eben dein beispiel attr a alias Üprobiert und es geht problemlos.
auf welcher platform verwendest du welchen telnet client?
hat du das encoding mit 'encoding utf8' gesetzt?
welches encoding hat deine shell/terminal fenster?
gruss
andre
Hi,
seltsam. Ich habe gerade mal das encoding via
attr telnetPort encoding utf8
gesetzt. Selber Fehler.
Ich versuche jetzt mal eben noch einen Update zu machen. Die Version ist die von der FHEM-Homepage ohne Updates o.ä....
Plattform ist Ubuntu 13.10, die normale Bash.
Die Bash nutzt UTF8.
Matthias
setz mal bitte das encoding direkt in der telnetverbindung. nicht (nur) das attribut auf dem telnet device. also wirklich encoding utf8tippen.
gruss
andre
edit: und was gibt 'locale' in der shell?
Update gemacht => keine Änderung
encoding utf8
auch nochmal probiert. Ebenfalls keine Änderung ...
attr a alias Ü
hängt wieder. Jetzt würde mich aber wirklich interessieren, warum es bei anderen funktioniert ... /bin/sh funktioniert übrigens bei mir auch nicht ... Jetzt gehen mir die Ideen aus ...
Noch der Output von locale (den Befehl kannte ich noch nicht :-)):
LANG=de_DE.UTF-8
LANGUAGE=de_DE
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
Sieht auch stark nach UTF8 aus ...
was gibt 'locale' auf der shell?
sh ist ziemlich sicher nur ein alias für die bash mit etwas anderen defaults.
gruss
andre
@justme1968: siehe oben :-). Sorry, wir haben uns gerade etwas gekreuzt.
das schaut nach utf8 aus.
bitte setz mal den alias im web frontend und schau ihn dir da an und auch per telnet.
die frage ist ob es beim setzen schief geht oder beim auslesen oder beim übertragen und anzeigen.
du kannst auch mal die telnet debug ausgabe einschalten. dann siehst du auf byte ebene was übertragen wird.
gruss
andre
Ok, wenn ich den Alias via fhemweb setze, dann wird er in beiden Frontends richtig angezeigt. Setze ich den Alias über Telnet, bekomme ich in FHEMWEB ein paar Fragezeigen. Jetzt schaue ich noch eben nach der Debug Ausgabe, moment ...
also wenn du telnet offen hast:
- ^] senden
- set netdata on
- ^] senden
- set prettydump on
dann ein list auf deinen dummy
gruss
andre
Seltsam, diese Kommandos wollen bei mir nicht. Muss man irgendwo noch ein netdata bzw. ein prettydump definieren? Sonst bekomme ich nur
fhem> ^]
Unknown command ^], try help.
fhem> set netdata on
Please define netdata first
fhem>
Ich bin schon richtig in der FHEM-Telnet-Konsole, oder?
Bei Verbose 5 findet man alle Kommandos, die in FHEM ankommen.
Ein
attr a alias ÜÄ
findet sich im Log dann als
2013.11.21 15:57:05 5: Cmd: >attr a alias �<
wieder.
Dämlich. Den Debug Modus habe ich gefunden - IBM hat eine nette Doku dazu. Daten bekomme ich trotzdem nicht angezeigt ... ich versuche es mal noch weiter.
ja richtig in der fhem telnet konsole
^] ist ctrl und ] gleichzeitig. dann landest du in einem prompt innerhalb des telnet programms. die beiden set sind kommandos für telnet nicht für fhem.
was das log angeht: schau mal ob der eintrag anders ausschaut wenn du den alias über das web frontend setzt. es kann sein das das logfile einfach nur ascii ist.
gruss
andre
setzen sollte so aussehen:attr a alias Ä
> 0x0 61 74 74 72 20 61 20 61 6c 69 61 73 20 c3 84 0a
das ende von list so:.
.
.
< 0xb0 65 73 3a 0a 20 20 20 61 6c 69 61 73 20 20 20 20
< 0xc0 20 20 c3 84 0a 0a
.
.
.
Attributes:
alias Ä
da ist jedes mal das c8 84 korrekt drin.
gruss
andre
Vermutlich ist das Terminal-Programm auf Latin-1 gestellt.
Interessiert eigentlich den telnet client, worauf LANG & co gestellt sind?
Den Terminal ziemich sicher nicht, es wird ja normalerweise vor dem Setzen dieser Variablen gestartet.
irgendwo in der kette scheint eine komponente nicht richtig auf utf8 zu stehen. aber es ist komisch das es dann überhaupt geht.
die ausgabe von lokale deutet eigentlich auch darauf hin das es stimmt. ausser das terminal (xterm&co) ist explizit auf ein anderes encoding geschaltet.
telnet reicht die zeichen 1:1 durch und weiss nichts vom encoding und wertet LANG&co auch nicht aus. es gibt nur die unterscheidung zwischen 7 und 8 bit mode je richtung.
theoretisch gibt es eine telnet erweiterung mit der der server das encoding der shell auf dem client erfragen kann damit alles automatisch funktioniert. leider wird das meines wissens nach nirgendwo unterstützt. d.h. es müssen alle komponenten zusammen passen: server und client müssen jeweils das encoding senden das der andere erwartet und telnet in der mitte muss für den 8bit/utf8 fall auf 8bit mode geschaltet werden.
gruss
andre
@matthias: wie schaut dein setup genau aus?
ist das eine linux konsole oder irgend ein grafisches frontend? knome/kde/...?
kannst du das encoding des terminal programms sehen/einstellen ?
gruss
andre
Hi,
also FHEMWEB steht richtig im Log. Der Telnet netcat output scheint in Ubuntu kaputt zu sein - jedenfalls kommt gerade kein Output, auch wenn ich ein explizites Tracefile einschalte. Ich versuche jetztdann mal netcat direkt dazwischen zu hängen.
Zum Setup:
Das ist ein ganz normales Ubuntu (Default-Shell). Theoretisch verwende ich noch einen Terminal-Emulator (tmux) dazwischen, das spielt aber keine Rolle. Wenn ich den rauslasse bekomme ich das selbe Ergebnis. Das Encoding kann man dort einstellen, ja. Das steht aber per default schon auf UTF-8. Ich kann natürlich mal versuchen es auf ISO-8859 zu stellen, aber ich glaube dann endet es endgültig im Encoding-Chaos :-).
Mir wäre das grundsätzlich egal. Ich halte Umlaute in solchen Programmen für ehrlich gesagt ziemlich überflüssig. Ich bin auch darauf gekommen, weil ich Umlaute in andFHEM für Telnet zum Laufen bringen wollte, weil ein Nutzer das verwenden wollte... Wie sieht denn euer Setup aus? Eventuell kann ich es ebenfalls so ausprobieren - damit wüssten wir wenigstens genau dass das nur ein Sonderfall der dämlichen Ubuntu Telnet Implementierung ist...
Matthias
P.S.: Mit nc direkt funktioniert das Setzen des Alias (via nc localhost 7072). Damit ist es definitiv kein FHEM Fehler, sondern eine nicht funktionierende Ubuntu Shell. Danke für die Hilfe!
eigentlich kommt die ausgabe wenn du netdata einschaltest direkt auf der konsole. du brauchst kein tracefile.
wenn du latin1/ISO-8859 verwendest musst du natürlich das encoding für das fhem telnet auch auf latin1 setzen.
gruss
andre
Klar, will ich ja nicht. UTF-8 ist gut :-). Da will ich definitiv nicht weg von. Der Trace kommt in der Telnet-Implementierung nicht. Frag mich bitte nicht warum. Ich tippe tatsächlich auf irgendeinen Ubuntu Schmuh. da gibt es noch einen Bug-Report dazu ...