Mal wieder Umlaute

Gleich vorweg, ich hab das Problem schon gelöst. Die Ursache war aber mehr als mysteriös, darum möchte ich es euch nicht vorenthalten.

Folgendes: Ich habe ein Script welches verschiedene Steuerwörter, u.a. das Wort „Füllen“ in eine Variable schreibt.
Ein weiteres Script liest diese Variable ein und wertet sie in einer Switch-Case Anweisung aus.
Jahrelang hat dies klaglos funktioniert.

Irgendwannmal NACH der rev4.0 Umstellung (genaue Build kann ich nimmer nachvollziehen) Reagierte die Switch-Case Anweisung nicht mehr auf „Füllen“.
Es wurde einfach ignoriert, keine Meldung im log, nix. alle anderen Steuerwörter wurden aber ordentlich abgeabeitet.
Da „Füllen“ nur sporadisch vorkommt habe ich den Fehler ewig lange nicht gefunden. Die ganzen zugehörigen Scripte waren uralt und als seit 100% als funktionierend bekannt. Hab deswegen schon auch schon einige Hardware ausgetauscht.
Als ich es nun doch mal hingesehen habe war das Problem rasch gefunden. „Füllen“ durch „Fuellen“ ersetzt und schon gings wieder.

Wie kann das sein ?
bb

Oberflächlich betrachtet liest sich das wie das hier diskutierte Thema: RS RainRadar Forecast (RRFC) 3.1 - Seite 4

Ich hab bis heute nicht die Muße gehabt, die Systematik im Umgang mit der Zeichensatzkodierung komplett durchzugehen (sofern man hier von Systematik reden kann). Und ähnlich wie bei den Sicherheitsaspekten schweigt sich der Hersteller dazu aus…

Hallo Bernhard,

je nach Kodierung (UTF-8 oder ISO 8859-1) sind die Bytes unterschiedlich. Da das Switch Case die Strings Byteweise vergleicht, wurde „Füllen“ einfach nicht korrekt also solches erkannt. (UTF-8 sind es 7 Bytes, bei ISO 8859-1 sind es 6 Bytes)

b Version 4.1 kannst du im Utils Control alle Skripte, Variablen ect. korrekt nach UTF-8 konvertieren lassen, damit es konsistent ist.

paresy

Ja danke.
Wie das kommt ist nachträglich betrachtet mehr oder weniger klar.
Lähmend ist sowas halt und in gewisser Weise auch gefährlich. Man kann ja kaum abschätzen wie und wo in hunderten von uralten Scripts plötzlich solche Geschichten auftauchen.
Sind halt viele Sünden der Vergangenheit, und ein gut gemachtes Script hätte das wohl abfangen können. Aber wer hat das schon konsistent.

Von da her sollte der Post mehr ein Denkanstoss für andere sein, welche mit 4.x auch erstmal unerklärliches Verhalten beobachten.

Diese Konvertierung in 4.1. Ist die 100% OK ?? Ich habe schon an anderen Stellen wegen den Umlauten nachgearbeitet, nicht das es dann wieder an anderen Stellen klemmt. Zurück auf 4.0 kann ich vermutlich, denn die 4.1 will ich lieber noch nicht nehmen.

schönen Dank für den Hinweis.
bb

Hallo
hab diese magische Umlautreparaturfunktion nun mal ausprobiert.

Gefunden und „repariert“ wurden viele viele Problemstellen. Wo und wie sich das nun genau auswirkt wird sich zeigen. :confused:

Die kaputten Umlaute in manchen Highcharts sind übrigens immer noch kaputt… :banghead:
Die stören mich aber nicht, die behalte sie mal als Indikator um zu sehen wann ihr wieder daran schraubt.

greez
bb

Hi bb,

Genau dem Problem der Darstellung der Highcharts habe ich auf zu kämpfen (solange Du im Backend unter Windows bleibst, ist das alles kein Problem).soweit ich das evaluieren konnte (ich habs dann irgendwann aufgegeben) liegt das Problem an vielen, unterschiedlichen Stellen. Dazu zählt:

  1. Scripte, die unter 3.4 erstellt wurden, sind immer ANSI codiert. Macht man ein Update auf IPS 4.0, müssten m.E. die Scripte zunächst alle nach UTF8 codiert werden (was aber nicht passiert) => diese Scripte hätten vermutlich mit dem Update besser nach UTF8 migriert werden müssen.

  2. Für mich ist nicht transparent, wie die Konsole damit umgeht (was passiert beim Öffnen von ANSI-Codierten Quellen, wie werden diese in der Konsole angezeigt und wie werden diese dann gespeichert, und umgekehrt). In der 3.4 hatte ich das mal getestet, da kamen ganz gruselige Effekte zustande.

  3. Visualisierung der Informationen im WFE: in welcher Codierung müssen Daten vorliegen, um im Browser korrekt dargestellt zu werden? Wie geht IPS damit um, wenn die Daten nicht UTF8 codiert sind? => und zumindest hier reagiert ein IPS auf Windows anders ans ein IPS unter Linux

Hinter den 3 Punkten verbergen sich noch weitere, feiner aufgelöste Problemfragen. Leider ist bisher diese gesamte Kette intransparent, da der Hersteller sich dazu nicht auslässt …

Nope, bei mir war immer nur Windows im Spiel. Allerdings hatte ich zu 3.4 Zeiten manche Scripte auch mit einem externen Editor bearbeitet. Erst mit 4.0 waren dann die Umlaute kaputt. Manchmal konnte ichs durch Öffnen und neu Abspeichern in der Konsole beheben, manchmal aber auch nicht.

Solange es sich nur um Anzeigeprobleme handelt sehe ich das eher belustigt. es macht IPS ein bisl menschlicher und liebenswert.:loveips:
Die Sache mit dem Switch-Case war aber sehr gemein, dadurch hat über Monate der Wasserwechsel im Aquarium nur teilweise funktioniert, mit teils auch schlimmen Auswirkungen.

Thema Transparenz:
Sehe ich nicht so, als Anwender will ich da gar nicht so tief reinblicken und habe auch nur ganz selten die Kompetenz dazu. Besser wäre wenn es einfach nur funktioniert. Darum sind wir Windows Anwender.
Wenn du mehr Transparenz willst mußt du zu einer OpenSource Lösung wechseln.

Übrigens deine Mailbox ist tot, ich wollte dir in alter Freundschaft gestern schon zu ein paar Zeilen zu deinen Formulierungen was schreiben, ging aber nicht.

schoene Gruesse
bb

ich bin über meine gmx.de-Adresse (wie auch im Impressum meiner HP) erreichbar :wink:

Hallo
ich störe mich auch schon länger an dem Sonderzeichen Thema in Highcharts Grafiken. Es gab ja den Workaround mit den Unicode Zeichen \u00c4 etc… aber leider half das nicht dafür das zB. in Jahresgraphen das ä des März immer komisch aussah.
Die Tage hatte ich mal wieder etwas Zeit zum probieren und bin zufällig darüber gestolpert das ich mit diesem Befehl

$CfgDaten['title']['text'] = mb_convert_encoding($CfgDaten['title']['text'], 'ISO-8859-15', 'UTF-8');

die Grafiküberschrift korrigieren kann. (bis auf das Eurozeichen…)


	$CfgDaten['title']['text'] = "Heizungsventile äöü ÄÖÜ ß@€ ";
	$CfgDaten['title']['text'] = mb_convert_encoding($CfgDaten['title']['text'], 'ISO-8859-15', 'UTF-8');

Nun meine ich das man am ende des config Scriptes vielicht einfach das Array $CfgDaten einmal komplett konvertieren sollte…
Aber mein versuch das Array rekursiv zu durchlaufen funktioniert leider nicht…


...
       recursive($CfgDaten);
	
	$s = IPS_GetScript($CfgDaten['HighChartScriptId']); 	// Id des Highcharts-Scripts
	include($s['ScriptFile']);

	// das ist ab V3.000 der neue Aufruf
	RunHighcharts($CfgDaten);

   function recursive($array)
         {
   	 foreach($array as $key => $value)
             {
   	         //If $value is an array.
   	         if(is_array($value))
                 {
   	         //We need to loop through it.
   	         recursive($value);
   	         } 
                 else
                 {
   	         $value = mb_convert_encoding($value, 'ISO-8859-15', 'UTF-8');
		 }
   	     }
	}

Hat einer eien Idee was ich falsch mache?

Joachim

Versuche es mal mit utf8_decode(„März“). Funktioniert bei mir wunderbar. Habe IPS auf Raspberry laufen und Windows, Android, IOS und Linux als Anzeigegeräte. Nirgendwo ein Problem.
Viele Grüße
Jürgen

Hallo Jürgen
Kannst Du mir bitte noch kurz schildern an welcher Stelle Du das wie eingebunden hast?
Danke…
Bei mir läuft IPS 4.0 auch auf dem Raspi und ansonsten super problemlos…:slight_smile:
Gruß
Joachim

Hallo Joachim,
einfach an jeder Stelle, an der Umlaute ausgegeben werden sollen. Beispiel:

	$CfgDaten['title']['text'] = utf8_decode("Überschrift");

Klappt einwandfrei.
Viele Grüße
Jürgen