encoding für web und telnet

[justme1968]

ich fange mal einen eigenen thread an um nicht hier Link weiter off topic zu bleiben.

- was das html encoding angeht hast du recht. ich war verwirrt weil mein safari es tatsächlich trotz charset=utf8 manchmal falsch macht und ich an der falschen stelle danach gesucht hatte (in der seite statt im header)

- für die console bzw telnet ist es aber noch nicht gelöst.

du schreibst du hast viele negative erfahrungen damit gemacht. für die anwender ist es aber eine mindestens genau so schlechte erfahrung wenn es in der console falsch dargestellt wird und es noch nicht mal die möglichkeit gib es richtig zu machen.

vielleicht wäre folgendes vorgehen hilfreicht es doch ein wenig besser in den griff zu bekommen:

- festlegen das alle ausgaben und user sichtbare texte eines devices utf8 sein sollen
- ein $hash->{Encoding} einführen das alle neuen module auf UTF-8 setzen müssen. module bei denen das nicht gesetzt ist gelten rückwärtskompatibel als latin1
- die beiden latin1_2_utf8 und utf8_to_latin1 von betateilchen in 99_Utils.pm bereitstellen (die sollten im gegensatz zu den perl Encoding funktionen auch auf fritzboxen funktionieren).
 
- attribut für telnet um das (client) encoding anzugeben
- kommando um in einer telnet session das encoding zwischen beidem umzuschalten
- für beides zunächst nur utf8 und latin1 erlauben

- zunächst beschränkung der automatischen konvertierung auf die ausgaben eines moduls aus der SetFn und GetFn
- die ausgaben der SetFn und GetFn mit den beiden obigen funktionen konvertiern wenn das telnet encoding nicht zum device encoding passt.

[rudolfkoenig]

Ich bin einverstaden damit, das alles in FHEM als UTF-8 gespeichert bzw. nach aussen gegeben wird, FHEMWEB verlaesst sich auch jetzt schon darauf.

Die beiden Konvertier-Routinen werde ich in fhem.pl aufnehmen falls einer der Module mit einer latin1 Quelle kommunizieren muss und die Quelle nicht auf UTF-8 schaltbar ist. Dazu moege sich bitte der Modul-Autor melden.

Ein telnet-Attribut bzw. fallabhaengige Konvertierung sehe ich nicht: wenn man ein telnet client mit FHEM verbindet UND Wert auf korrekte Darstellung von Umlauten legt, dann muss man im Terminal-Fenster UTF-8 einstellen.
Es ist nicht FHEMs Aufgabe Character-sets zu konvertieren, sondern die der Anzeige-Programme (Browser/telnet-Fenster/etc), alles was von FHEM kommt ist UTF-8.

Konvertieren ist auf den ersten Blick leicht, wird aber kompliziert, wenn weitere Teilnehmer (wie z.Bsp. Datenbanken) auf die gleiche Idee kommen. Wenn dann nicht ganz klar ist, wer was wie speichert, kommt ein Durcheinander zustande.

[justme1968]

das konvertieren ist ganz leicht. auch in verbindung mit datenbanken und beliebig vielen beteiligten. vorausgesetzt es wird eine einzige regel eingehalten: es muss zu jeder zeit und an jeder stelle ganz klar sein in welchem encoding ein text gerade ist.

die eigentliche schwierigkeit ist nicht das konvertieren sondern die information über das encoding konsequent überall mit zu schleifen und nicht aus versehen an irgend einer stelle eine annahme zu treffen die nicht stimmt. das client encoding für das telnet interface konfigurierbar zu machen würde genau das erlauben.

ich würde schon sehen das es eben genau aufgabe des jeweiligen ausgabe moduls ist dafür zu sorgen das das encoding stimmt. beim fhemweb ist das kein problem weil das protokoll das schon vorsieht. bei telnet gibt es genau diese möglihkeit das der server dem client das encoding der daten mitteilt aber leider nicht und es kracht dann eben genau deshalb weil jede seite der meinung ist es ist eigentlich aufgabe der anderen statt einzusehen das beide seiten zusammen etwas dafür tun müssen das es reibungslos geht.

gerade beim telnet client denke ich (ganz wirklich ohne den aufwand zu unterschätzen) das es relativ einfach möglich ist das problem zu lösen wenn eindeutig festgelegt ist was von der fhem seite kommt.

ich bin auch gerne bereit dafür patches zu liefern. aber das macht natürlich keinen sinn ohne dein ok :)

edit: es gibt sogar ein rfc (http://tools.ietf.org/html/rfc2066) für telnet und encoding. scheinbar hat das niemals jemand umgesetzt...

[betateilchen]

Die beiden Konvertier-Routinen werde ich in fhem.pl aufnehmen falls einer der Module mit einer latin1 Quelle kommunizieren muss und die Quelle nicht auf UTF-8 schaltbar ist. Dazu moege sich bitte der Modul-Autor melden.

Also ich brauche diese Konvertierungsroutinen in meinem derzeit entstehenden 55_GDS und Boris nutzt latin1_to_utf8() in 59_Weather.

Man sollte auf jeden Fall auf eine eindeutige Benennung der beiden Funktionen achten. Ich verwende derzeite <sourceCharset>_2_<targetCharset> und Boris <sourceCharset>_to_<targetCharset>

Wenn die Funktionen in fhem.pl integriert sind, brauchen wir sie beide nicht mehr in unseren Modulen.

[justme1968]

ich habe ein wenig mit dem encoding im telnet modul gespielt und für die ausgabe richtung funktioniert es ohne probleme wenn man vor dem syswirte an den client $ret ein mal durch utf8_2_latin1 schickt wenn der client latin1 möchte.

ich glaube also immer noch das es ein sehr kleiner patch an genau einer definierten schnittstelle von und zu fhem wäre.

[rudolfkoenig]

>  Wenn die Funktionen in fhem.pl integriert sind, brauchen wir sie beide nicht mehr in unseren Modulen.

Ich habe die Funktion aus 59_Weather.pm als latin1ToUtf8 in fhem.pl uebernommen, da wenn ich mich recht erinnere, irgendwo wir uns mal auf diese Schreibweise geeinigt haben.


>  ich glaube also immer noch das es ein sehr kleiner patch an genau einer definierten schnittstelle von und zu fhem wäre.

Na gut, ich ergebe mich. Bevor ich unglueckliche Mitstreiter habe... :)

[betateilchen]

Ich habe die Funktion aus 59_Weather.pm als latin1ToUtf8 in fhem.pl uebernommen, da wenn ich mich recht erinnere, irgendwo wir uns mal auf diese Schreibweise geeinigt haben.

Hallo Rudi,

könntest Du das Gegenstück utf8ToLatin1 bitte auch noch aufnehmen?

Code Auswählen Erweitern


sub
utf8ToLatin1($)
{
  # http://perldoc.perl.org/perluniintro.html, UNICODE IN OLDER PERLS
  my ($s)= @_;
  $s =~ s/([\xC2\xC3])([\x80-\xBF])/chr(ord($1)<<6&0xC0|ord($2)&0x3F)/eg;
  return $s;
}


Danke & viele Grüße
Udo

[rudolfkoenig]

eingecheckt.

[justme1968]

Na gut, ich ergebe mich. Bevor ich unglueckliche Mitstreiter habe... :)

und ich hatte gehofft du sagst ja weil du siehst das es sinnvoll ist :)

hier ein vorschlag für einen patch der das encoding bei der ausgabe für telnet konfigurierbar macht.

- ein attribut encoding mit den möglichen werten utf8 und latin1. der default ist utf8.
- wenn das encoding auf latin1 gestellt ist wird utf8ToLatin1 vor dem senden der daten an den client aufgerufen

- ein 'encoding' kommando um das encoding zur laufzeit abzufragen und zu setzen.

das attribut habe ich schon dokumentiert. das kommando noch nicht.ich wusste zum einen nicht so recht wo und zum anderen nicht ob dir der teil auch noch gefällt :)

das das  'encoding' kommando nicht an fhem durchgereicht wird sondern direkt im telnet modul behandelt wird könnte man es noch mit einem prefix (z.b. einem doppelpunkt oder semikolon) versehen um es von 'normalen' fhem kommandos zu unterscheiden. aber wenn es das einzige meta kommando bleibt ist das vielleicht auch zu viel des guten.

die eingabe habe ich mir nicht weiter angeschaut.

gruss
  andre

[rudolfkoenig]

Nach denken und Irrlaeufen:

Ich meinte zunaechst, dass man Attribute nicht mit speziellen Kommandos setzen und anzeigen sollte, sondern mit allgemeinen FHEM-internen, und habe deswegen das bisher fehlende displayattr in fhem.pl eingebaut und eingecheckt.

Erst danach ist es mir aufgefallen, dass wenn man per telnet sich verbunden hat, keine Ahnung hat, ueber welche Server-Verbindung man reingekommen ist, weiterhin kann man schlecht temporaer nur fuer die aktuele Verbindung das encoding aendern, man benoetig also doch sowas wie dein encoding Befehl.

Eigentlich traegt man Befehle in die globale %cmds ein (siehe 98_XmlList.pm), damit diese in help angezeigt werden, und von ueberall aufgerufen werden koennen. Das Aufrufen von ueberall (z.Bsp aus FHEMWEB) ist in diesem Fall nicht erwuenscht, das kann man aber pruefen: der erste Parameter einer CommandEncoding Funktion ist der hash der telnet-Verbindung.
-> Kannst Du bitte encoding auf diese Weise umbauen, damit es kein shortcut bzw. Sonderweg ist?

Weiterhin fehlt noch die Konvertierung beim input.

[justme1968]

ja. genau. es global zu machen funktioniert in diesem fall nicht. es ist wirklich verbindungsspezifisch.

natürlich kann ich das auf %cmds umbauen finde es aber eigentlich nicht so schön wenn das kommando auch im web auftaucht und dort gar keinen sinn macht. das fand ich auch bei exit und quit schon nicht schön. inform ist glaube ich noch ein kandidat der im web nicht sinnvoll ist.

was würdest du davon halten wenn man in dem commando hash für %cmds optional angeben kann das ein kommando nur beim aufruf aus einem bestimmten clientmodul heraus sinnvoll ist? z.b. in dem man zusätzlich zu Fn und Hlp noch Client setzen kann. dann könnte man ein Kommando z.b. auch bei help ausblenden wenn es nicht matched.

beim input bin ich noch dabei zu schauen wie es genau geht. der erste schritt dazu ist die verbindung auf binär zu stellen. das hat aber beim ersten versuch noch den seiteneffekt gehabt das die zeilenenden nicht mehr gepasst haben.

da man zur zeit über die telnet verbindung aber sowieso weder latin1 noch utf8 sondern nur ascii eingeben kann würde ich das dann in einem zweiten patch nur für die eingabe nach meinem urlaub machen. vorher schaffe ich das nicht mehr.

[justme1968]

hier der gleiche patch mit verwendung von %cmds.

input kommt erst nach meinem urlaub.

[rudolfkoenig]

Eingecheckt.

Hab zusaetzlich dein Vorschlag als ClientFilter eingebaut, damit ist exit/quit/inform aus FHEMWEB nicht mehr ausfuehrbar.

[justme1968]

ich nehme es zurück. hier ist doch schon eine version mit input.

das ganze funktioniert in dem fhem den telnet client auffordert in den binär modus zu schalten. die gegenrichtung wird ignoriert. erst wenn man auch die gegenrichtung umschaltet stimmen die zeilenenden nicht mehr.

getestet z.b. mit:

Code Auswählen Erweitern

set gds warnlage Baden-Württemberg
oder

Code Auswählen Erweitern

define dummy dummy
attr dummy room Büro

beides wäre vorher nicht gegangen. weder mit dem default utf8 noch mit latin1. jetzt geht es mit beidem.

gruss
  andre

ach ja: ich habe es von linux und mac os x aus getestet. was anderes habe ich nicht zur verfügung.

edit: lach. so schnell und doch zu langsam :)

[justme1968]

und noch mal nur die input seite als sauberen patch gegen die aktuelle version.