Zeichenketten, Umlaute, Unicode und das ganze Gedöns

[Charlenni]

Hallo,

ich will mal wieder das Problem der Umlaute aufwärmen.

Bisher kann ja nur Earwigo durchgängig auf allen Platformen Umlaute. Wenn sich das ändern soll, dann muss man auf mehr als 7-Bit ASCII umsteigen. UTF-8 bietet sich dafür an. Dort werden weitere Zeichen in 2, 3 oder mehr zusammen gehörigen Bytes abgelegt. Ein ä besteht dort aus der Bytefolge 195 gefolgt von 164. Die deutschen Umlaute bekommt man so auf allen aktuellen Playern zum laufen.

Doch wenn man das tut, dann bekommt man Probleme mit den normalen Funktionen zum bearbeiten von Zeichenketten. Diese liefern dann nämlich für die Zeichenkette "äh" als Länge drei Bytes, wo es doch nur zwei Zeichen sind. Und auch die Funktion zum extrahieren einzelner Zeichen (string.sub) liefert eventuell nicht Zeichen, sondern einzelne Bytes.

Lange Rede, kurzer Sinn: Ich will fragen, welche Funktionen Ihr aus der string Bibliothek benutzt. Diese hat ja einige Funktionen (siehe dazu das String Library Tutorial).

Vielen Dank für Eure Mithilfe.

 

[Sabeta]

Ich verstehe die Frage nicht. Lua ist doch Lua und GS ist GS, am Ende haben wir eine gwc-Datei mit dem Umlautproblem das nur zur Laufzeit der Cartridge beseitigt werden kann. Welche Funktionen da nun verwendet werden, spielt doch dabei keine Rolle. Zudem kann ich jetzt nicht sagen, was ich im nächsten Jahr brauchen kann. Wenn ich einen Wherigo entwickle, dann schaue ich was möglich ist um mein Ziel zu erreichen, so wie ich es bei C++, Javascript oder oder tue, ich schaue was es an Befehlen/Bibliotheken gibt und nutze das am besten geeignete Mittel, das kann bisher "gsub" sein, aber morgen schon "reverse", auch wenn ich heute noch nicht daran denke.

Wenn du die Befehle kapseln möchtest, dann konsequent alle.

Sabeta

 

[Charlenni]

Im Augenblick ist das richtig. Allerdings im Augenblick. In Zukunft kannst Du Deine Cartridge in UTF-8 abliefern und ein anderer Compiler als der von GS auf einer anderen Webseite als die GS wird Dir daraus eine GWC Datei generieren, die dann auch Umlaute auf den Schirm zaubert.

Nun ist aber die Frage, wie die Wherigo Ersteller mit diesem mehr an Möglichkeiten konfrontiert werden. Müssen sie sich selbst darum kümmern, dass plötzlich ein Zeichen mehr als ein Byte hat oder nicht. Die Standard Bibliothek von Lua (string) kann nur mit Byte umgehen, aber nicht mit Zeichen. Und was passiert dann, wenn string.len("äh") == 3 ist.

Andererseits die komplette String Bibliothek umzuschreiben kann Probleme bereiten. Gerade auf den etwas leistungsschwachen Garmins kann das Probleme machen. Deshalb die Frage, ob alle Funktionen dieser Bibliothek benutzt werden. Oder eventuell können die schwer zu realisierenden auf Grund mangelnden Interesses eingespart werden

 

[TeamBunteBlitze]

Hallo Dirk,

vergiß die alten Garmins. Mit dem was über den bisherigen Umfang von Wherigos hinausgeht ist dort auf Grund fehlender Dinge (ich denke da z.B. an Konnektivität) ohnehin Schicht im Schacht. War es nicht so, das für Wherigo 2.0 die Plattformen Windows Mobile, Android und iOS angedacht waren? Endlose Abwärtskompatibilität bei den Geräten wird kaum möglich sein.

UTF8? Ist das nicht so ein wenig mit Kanonen auf Spatzen? Nur wegen der Umlaute? Wären da nicht Zeichensätze mit einem Byte je Zeichen die Lösung bei denen der Programmierer dann auswählt, welchen er verwendet?

VG

Sven

 

[WhitePawn]

Da oben fehlt die Optione "keine" :/

Bei Texteingaben beschränke ich mich meist auf ein Minimum und da ist es auch kein Problem, die meisten möglichen Versionen abzufangen.
(Andernfalls würde ich zu "alle" tendieren. Nach dem Motto: "Wenn schon, dann richtig" )

 

[Charlenni]

Nun ja, die Frage ist unabhängig vom Player eher auf den Compiler bezogen.

Garmins können ja eine ganze Anzahl an Sonderzeichen, da sie den Zeichensatz Win-1252 verwenden (allerdings nur für Wherigos, sonst verwenden sie UTF-8 ). Und UTF-8 muss sein. Nicht für die paar deutschen Sonderzeichen, aber vielleicht für die paar chinesischen Sonderzeichen .

Also ist Vorgabe, dass der Lua Quellcode in UTF-8 sein soll. Und wenn man das schon hat, dann kann man eventuell auch gleich die Garmins unterstützen. Alles noch im Rahmen von Wherigo 1.0.