Nop hat geschrieben: ↑06.05.2019, 20:28
Ich hatte mir über'n Tag gedacht, eigentlich kann es in Java keine Probleme mit Umlauten geben, denn alle Strings sind standardmäßig in UTF-8 codiert und können alle internationalen Zeichen.
Stimmt so nicht ganz: Die interne Speicherung von Zeichen (char) und damit auch von Strings in Java ist 16-Bit-Unicode. Die externe Kodierung beim Speichern in Dateien kann UTF-8 sein, muss aber nicht.
In Java wird zwischen Byte und Character unterschieden. In UTF-8 haben ja Character unterschiedliche Byte-Zahl.
WWAK hat geschrieben: ↑06.05.2019, 23:39
ich kann bestätigen, das Problem in meine beiden WIN10 Systemen bei den Umlaut Tracks ist ANSI bei der essence.csv, ist aber auch ansi bei der "ae","oe" usw Versionen, wo es ja ohne Probleme mit der Uebersichtskarte funktioniert!!
Bei den ersten 127 Zeichen sind ANSI, UTF-8, 7-Bit-ASCII und viele andere Codesysteme identisch. Daher macht "ae" in ANSI keine Schwierigkeiten, da binär identisch mit UTF-8.
WWAK hat geschrieben: ↑06.05.2019, 23:39
Ich denke, es ist nicht mehr nötig, die entsprechenden *.csv files hoch zu laden. Lieber warte ich, ob es einen Hinweis gibt, ob TG/NOP das Problem lösen kann,
Du solltest per Autoupdate eine Version 0.71 bekommen, die mit fester Codierung speichert. Bitte mal ausprobieren.
Ok, V0.71 verarbeitet Umlaute jetzt ohne Schluckauf.
Nur bei einem Track von lon -117 bis +113 (Speicherabzug eines Garmin) geht die Übersichtskarte nicht .
Unter GNU/Linux gibt es keine äöü-Probleme. Ich habe mal etliche gpx-Dateien mit Umlauten versehen (Dateiname & Trackname) und
konnte keine Probleme feststellen.
danke für den schnellen Update, es sieht (bei mir) gut aus und TC verschluckt sich auch nicht an Pfadnamen mit Umlauten ! Essence.csv ist jetzt, nachdem ich die alte gelöscht habe im UTF8 Format, wie sie wohl auch sein muß - siehe Anlage