Unicode im Allgemeinen

[Punika]

Hallo Zusammen

als kleine Geschichte vorneweg:
Meine Situation sieht so aus, das ich im Moment in meinem Programm Character entweder als Unicode oder als ASCII Zeichen haben, je nachdem welche Build Settings in einstelle. Das funktioniert soweit auch ganz gut. Da ich aber Platformübergreifend das ganze schreibe wird mir der Aufwand langsam zuviel. Zudem ist es so, das langsam alle Geräte, egal ob PC oder Mobilgerät Unicode unterstützen. Daher möchte ich diese Abstraktionsebene entfernen.

Daher meine Frage:
Wie handhabt ihr das im allgemeinen? Ich sehe da zwei Möglichkeiten. Entweder ich sage, das alles was mit Charactern zu tun hat, immer Unicode ist. Das hat den Vorteil das ich das konvertieren in ASCII Charactern minimiere aber den mehr Speicher habe, wo ich vorher schon weiß das ich hier keine Unicode Zeichen brauche. Ich spare also ein wenig Rechenzeit, Programmieraufwand habe aber dafür mehr Speicher.
Oder geht man lieber denn weg, das man vorher ausmacht wo, man ASCII Zeichen will und/oder Unicode Zeichen, und damit mehr Konvertierung benötigt aber weniger Speicher braucht.

Im Moment sieht das bei mir so aus, das ich jeweils immer den vom Compiler/OS "vorgeschriebenen" Unicode Datensatz nehme. Damit habe ich bis jetzt auch noch keine großen Probleme. Meine Binärdateien sind zwar im Moment von der Umgebung abhängig, doch da könnte man noch eine Abstraktion einführen. Das soll auch nicht wirklich das Thema sein, weil dies ja schon hier im Forum besprochen wurde, und wir alle das Dilemma von C++ kennen.

Grüße

punika

[Sternmull]

Ich schätze du redest von der "Unicode-Zeichensatz verwenden"-Option im Visual Studio. Damit werden die Wide-Character-Versionen der ganzen Windows-Funktionen gewählt und TCHAR wird zu WCHAR. Damit funktioniert dann für eine ausreichend große Untermenge der Unicode-Zeichen alles super weil pro Zeichen ein 16-Bit integer verwendet wird.

Auf anderen Plattformen ist das anders gelöst. Die verwenden z.B. für APIs durchgehend utf-8. D.h. man bleibt bei Strings mit 8-Bit-Elementen, setzt aber nicht voraus das ein Element pro Zeichen verwendet wird. Statt dessen werden für nicht-ASCII-Zeichen mehrere Elemente verwendet.

Als Anwendungsprogrammierer wird man sich wohl immer dem String-Typen unterordnen die von den APIs bzw. Bibliotheken erwartet werden von denen man abhängt. Würde man z.B. unter Windows utf-8-Strings verwenden, so müsste man für WinAPI-Funktionen (z.B. CreateFile) die Strings erst zwischen utf-8 und utf-16 konvertieren. Das macht keinen Spaß. Dagegen ist der eventuelle Nachteil des höheren Speicherverbrauchs wegen der 2 Byte pro Zeichen geradezu lächerlich. Ich hab jedenfalls noch keine Anwendung gesehen die wegen Strings unangenehm hohen Speicherbedarf hat. Üblicherweise sind da eher Multimedia-Daten oder andere Sachen verantwortlich. Die paar Strings die in einer durchschnittlichen Anwendung herumgeistern die heute üblichen Gigabytes RAM nicht wirklich.

[Punika]

Hi

mit Unicode Zeichensatz wollte ich nicht auf eine speziellen Zeichensatz oder einer Option eingehen, sondern sagen alles ausser ASCII :)

Bei der ganze Frage ging es mir darum zu klären, ob man im ganzen Projekt nur Unicode verwenden sollte oder eben einen Mix macht.
Als kleines Beispiel: Mac OSX lässt z.B. UTF-8 bei Dateinamen zu(POSIX), ich denke Windows benutzt da einfach UTF-16. Sonst benutze ich aber UTF-32 da dies die gängigste Form in den Mac Libraries ist. Hier gibt es eben zwei Lösungen die mir so einfallen. Ausgehend davon das ich vorhandene Funktionen habe zum lesen von Dateien.
1. Ich lasse Unicode Zeichen zu für Dateinamen -> Die jeweilige Platformimplementierung muss dafür sorgen das es funktioniert.
2. Ich lasse nur ASCII Zeichen zu -> Das ansprechen der Funktionen wird verkompliziert dafür habe ich ne gewisse Sicherheit das das Laden nicht fehlschlägt weil jemand merkwürdige Zeichen benutzt.

Das war vielleicht nicht das beste Beispiel, doch denke ich das es ein Beispiel war der Platformübergreifenden Geschichte. Wie Zeichen in den Dateien gespeichert werden, wird hier nicht berücksichtigt.

Worauf ich eben hinauswollte. Ist es klug zu sagen. Alles sind jetzt eben Unicode Zeichen. Oder nehme ich einfach den Mehraufwand hin, und sage das ich das zum Zweck geeignete Mittel nehme. Beispiel: Objekte haben einen Namen intern -> brauch nicht Unicode zu sein... Wenn ich aus Objektnamen einen Dateinamen herleiten will, brauche ich die Konvertierung...

Und dazu würde ich gerne Erfahrungen hören. Ich tendiere zum Ansatz, alles Unicode und nach mir die Sintflut. Aber da das ganze eine große Entscheidung wie ich finde ist, würde ich doch gerne Erfahrungen hören.

Grüße

punika

[Sternmull]

Deinen Punkt 2 kann ich nicht nachvollziehen. Warum sollte das Laden schiefgehen weil jemand komische Zeichen eingegeben hat? Wenn die Funktionen Unicode unterstützen, dann sollten sie das auch vollständig tun. Ich würde mir keine zusätzliche "Sicherheit" durch die Verwendung von ASCII-Zeichen erhoffen.

Ich würde sagen wenn man Unicode verwendet dann sollte man das eigentlich durchgehend tun, einfach um die ASCII-Unicode Konvertierung zu minimieren. Denn von Unicode zu ASCII hat man ja ein Problem weil sich eben nur die ASCII-Zeichen übernehmen lassen. Natürlich gibt es Stellen an denen ASCII-Strings unumgänglich sind (z.B. bei Berührung mit APIs die nur ASCII kennen). Aber das ist meiner Erfahrung nach eher selten. Jedenfalls muss man da von Fall zu Fall entscheiden wo man die ASCII/Unicode-Grenze zieht.

[Schrompf]

Da ich das Thema kürzlich auch hatte, kann ich vielleicht was beitragen.

a) ASCII ist ein totes Ende.
b) Verschiedene OS haben verschiedene Vorstellungen von Dateinamen-Kodierungen.
c) Es gibt keine Schönheit oder Konsistenz.

Wenn man c) akzeptiert hat, wird es einfacher. Ich bin bislang immernoch gescheitert, herauszufinden, welche Kodierung boost.filesystem erwartet, aber wenn Du eh Deine eigenen Kapselung um die systemspezifischen Funktionen schreibst, hast Du ja die Wahl. Du könntest:

a) Immer native verwenden und bei allen String-Ops dran denken, dass es mal ein Dateiname werden soll, um die passenden String-Ops zu verwenden. Ungünstig.
b) Eine Pfad-Klasse mit eigenen Operatoren und Konvertierungen von/zu Strings erfinden und die benutzen. Benutzung ist konsistent und fehlersicher, und Konvertierungen werden nur einmalig an der Quelle gemacht. Dafür handelst Du Dir spezielle Freude beim Serialisieren von Pfaden ein.
c) Immer eine definierte Kodierung verwenden - ich würde da UTF8 wie für alle anderen Strings auch verwenden. Dann musst Du bei jedem Datei-Öffnen je nach Plattform zum Zielformat konvertieren, hast ansonsten aber bequeme Sicherheit durch Einheitlichkeit.

Ich persönlich peile c) an, falls boost.filesystem nicht schon irgendwas in der Art mitbringt.

[Sternmull]

Genau genommen wird das Encoding von Dateinamen durch das Dateisystem diktiert (bzw. dadurch wie die Dateinamen bisher darin abgelegt wurden), nicht durch das OS. Beispielsweise muss man bei bei einem USB-Stick der von einem Russen mit FAT16 formatiert und benutzt wurde mit einem anderen Encoding rechnen als es vielleicht ein Deutsches Windows oder Linux erwartet. Ideotischerweise scheinen (die meisten?) Dateisysteme nicht zu hinterlegen mit welchem Encoding die Dateinamen abgelegt werden. Allerdings haben die verschiedenen OSs teilweise default Encodings. Unter Linux, FreeBSD etc. ist utf-8 üblich, aber nicht garantiert. Unter Windows dürften die Unicode-Varianten der betreffenden Funktionen (z.B. CreateFileW etc.) transparent zwischen utf-16 und dem Encoding konvertieren das Windows für das jeweilige Dateisystem annimmt.

Letzten Endes bleibt es Dabei: Wenn man Unicode unterstützen will, dann sollte man das auf eine Weise tun die einem möglichst wenige Probleme bereitet. z.B. ist utf-16 pratkisch für Windows weil man dann API-Funktionen wie CreateFileW etc. ohne Stringkonvertierung verwenden kann. Unter Linux ist utf-8 ein guter Kandidat weil die Chancen sehr hoch sind das man dort mit dieser Kodierung ohne Stringkovertierung auskommt wenn man mit Dateisystem und anderen Sachen interagiert. Ebenso wird man utf-8 preferieren wenn man mit GTK arbeitet, und utf-16 wenn man QT nimmt, denn dass sind halt die Kodierungen die deren String-Objekte verwenden.

[eXile]

Ich wollte hier noch dieses Gem aus der MSDN einstreuen:

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters.
…
The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the “\\?\” prefix. For example, “\\?\D:\very long path”.

Note The maximum path of 32,767 characters is approximate, because the “\\?\” prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length.

Korrekt: „some exceptions“ = fast alle Unicode Funktionen!

Wenn man also einer Anwendung einen Pfad mit Leerzeichen, Unicode-Zeichen und am besten auch noch oben beschriebener Überlänge gibt, kann man fast sicher sein, dass das in die Hose geht; eben weil die meisten Programmierer das nicht implementieren, sondern sich auf MAX_PATH verlassen.

Außerdem bringt Windows 8 so viel sagende Funktionsnamen wie CreateFile2.

[Sternmull]

Interessant, von CreateFile2 gibt es also keine ASCII-Variante mehr. Ansonsten ist die Kodierungsthematik aber identisch zu CreateFileW: Windows kümmert sich um die Übersetzung zwischen utf-16 und der Kodierung des Dateisystems.

[odenter]

Gabs nicht mal ne CreateFileEx? Ich war fest davon überzeugt sowas mal gesehen zu haben, scheint aber nicht mehr da zu sein. :-S

[Punika]

Um vielleicht das Thema abzuschliessen... Ich habe mich für die UTF-8 Kodierung entschieden, und bin damit sehr zufrieden. Das schöne ist das ich sukzessive meine String Funktionen umschreiben kann. Es zahlt sich jetzt auch aus das ich schon von Anfang an die C-Lib String Funktionen abstrahiert hatte, und ich so das ganze sauber ersetzen kann.

Das einzige Problem für einen Programmierer ist, das alte Funktionen zum größten Teil auf String Länge basieren. (strncpy usw.) Hier habe ich zusätzliche Funktionen hinzugefügt. Die sind aber noch nicht Perfekt. Die beste Lösung wäre, einmal Übergabe von Länge der zu kopierenden Characters und noch die Größe des Zieles. Somit kann man besser einen Buffer Overflow vermeiden und die sicher stellen, das es einen Null Terminator gibt.
Die alten Funktionen (unsicher) bleiben erstmal drin, werden aber dann herausgenommen. Eine String Klasse benutzt dann diese Funktionen.

punika

[Sternmull]

Ich schätze das weisst du schon, aber trotzem (weil ich die letzten zwei Stunden sinnlos verbracht hab, und nun was nützliches tun will ;) ): Das nette an utf-8 ist ja das man die ganzen Funktionen für Null-terminierte single-Byte-Strings (also die C-typischen Strings) weiterhin verwenden kann weil in einer utf-8-Sequenz keine Null vorkommen kann. Außerdem sind valide ASCII-Strings auch valide utf-8-Strings, brauchen also nicht konvertiert werden. Beim Kopieren und Erstellen durch Formatierungsfunktionen etc. kann man also bei den guten alten ASCII-kompatiblen Funktionen bleiben. Problematisch wird es nur wenn man die Anzahl oder die Speicherposition von Zeichen braucht. Da nicht-ASCII-Zeichen durch mehrere Bytes reräsentiert werden muss man hier also die utf-8 Kodierung interpretieren. Ein einfaches strlen liefert z.B. die Anzahl der Bytes, nicht unbedingt die der Zeichen im String. Zu Pufferüberläufen sollte man sich abgesehen davon (Zeichenanzahl <= benötigte Puffergröße) eigentlich nicht mehr Gedanken machen müssen als vorher. Eine brauchbare String-Klasse sollte diese Probleme aber lösen.

[Punika]

Ja das wollte ich schon mit dem vorherigen Post sagen. Das ganze hält sich natürlich in Grenzen, alle Charakterbasierenden Funktionen wie strncpy, strlen usw. funktionieren natürlich nicht mehr...

Aber ich denke, man könnte das Thema hier auch schliessen. Vielleicht können ja doch noch ein paar Leute was aus diesem Fazit ziehen.

punika

[Biolunar]

Was ich grade entdeckt habe und zum Thema passt: http://www.utf8everywhere.org/

[BeRsErKeR]

Ich finde alles jenseits von ASCII für Dateinamen fehl am Platz. Dateiinhalt ok, aber warum muss man denn Dateinamen mit Sonderzeichen oder chinesischen Schriftzeichen unterstützen? Das ist nicht nur aufwendig, sondern wie schon erwähnt auch wenig bzw. nur mit viel Aufwand portabel. Zumal man in Dateien über ein BOM oder eine Auszeichnung sehr gut das Encoding speichern kann was im Dateisystem nicht so wirklich möglich ist. Außerdem sind Dateinamen in der Regel nicht mit landes- bzw. sprachspezifischen Informationen gefüllt. Das ist nicht die Aufgabe eines Dateinamens. Dazu dient der Dateiinhalt.

[Biolunar]

Jo is klar.
Zeichen wie „ und “ und — und ß kommen bei mir in Dateinamen vor. Wenn ein Programm damit nicht umgehen kann, liegt der Fehler deiner Meinung nach bei mir.

[BeRsErKeR]

Jo is klar.
Zeichen wie „ und “ und — und ß kommen bei mir in Dateinamen vor. Wenn ein Programm damit nicht umgehen kann, liegt der Fehler deiner Meinung nach bei mir.

Um ehrlich zu sein: Jein. Wenn ein Programm festlegt, dass es nur ASCII-Dateinamen akzeptiert, dann muss man als Nutzer eben dafür sorgen, dass der Input korrekt ist. Das ist nicht nur auf Dateinamen beschränkt. Wenn das Programm aber sagt, dass es alles frisst und dann nicht mit einem gewissen Input klar kommt ist das eine andere Sache. Und warum soll ich viel Zeit damit verbringen, dass ein Programm alles mögliche fressen kann, anstatt einfach festzulegen, dass ein gewisses Format (z.B. des Dateinamens) als Input vorliegen muss? Ich handle mir damit weniger Ärger ein, brauche weniger Zeit dafür und habe auch im Nachhinein weniger Wartungsaufwand.

[Sternmull]

Das scheint mir doch eine sehr naive Einstellung. Lieferst du dann eine ASCII Tabell mit deinem Programm aus? Meine Oma hat nämlich nicht im Kopf welche Zeichen ASCII sind. Ich bin mir sicher das auch viele andere Menschen nicht wissen wollen was ASCII überhaupt ist. Und freuen werden die sich ganz bestimmt nicht wenn sie hier und dort wegen diesem oder jenem Programm auf keinen Fall ein "ä" oder "ö" benutzen dürfen weil dann Fehlfunktionen in irgendwelchen Programmen auftreten. Innerhalb von Textdateien dürfen sie aber wieder alles schreiben... Klasse.

Natürlich gibt es Programm die nur mit ASCII oder einer bestimmten Codepage klarkommen. Aber die sind einfach nicht mehr zeitgemäß und sollten so schnell wie möglich angepasst oder durch was Ordentliches ersetzt werden. In diesem Thread wurden ja nun genug Hinweise zur Verwendung von Unicode in C++ genannt und verlinkt. Als vernünftiger Programmierer sollte man sich dieser Thematik stellen statt zu versuchen ihr aus dem Weg zu gehen (was auf Dauer eh nicht funktionieren wird). Wenn man ein mal die Kurve gekriegt hat ist das auch eigentlich kein Mehraufwand mehr.

[BeRsErKeR]

Wenn du deiner Oma sagst, dass sie keine Umlaute verwenden darf, dann wird sie das schon verstehen. Vorallem aber kann das Programm auch einfach prüfen ob alle Zeichen ASCII sind und ggf. eine Fehlermeldung ausgeben. Du wirst ja sicher auch nicht jedes x-beliebige Dateiformat untersützen. Da musst du deiner Oma theoretisch auch weiterhelfen oder eine Prüfung im Programm einbauen. Warum ist das beim Dateinamen nun soviel anders? Man legt ein Format fest und daran muss man sich halten. Zum Vergleich: Ich kann beispielswiese grep auch nicht irgendwelche beliebigen Texte oder Optionen mitgeben. Man muss schon wissen was das Programm frisst. Und dazu gibt es manpages oder ähnliches. ;)

[Sternmull]

Du kannst deiner Oma ja gern die man pages von grep schicken. Aber meine hat erst vor kurzem gelernt was ein "@" ist und wird sicherlich auch nichts böses ahnen während sie eine Datei namens "häkeln.doc" anlegt. Natürlich wird sie aber ratlos vor der Kiste sitzen wenn auf einmal irgend ein Programm eine Fehlermeldung beim öffnen dieser Datei meldet (oder einfach abstürzt) obwohl die Datei "stricken.doc" die direkt daneben liegt keine Probleme macht.

Du erwartest vom Nutzer das er (ungeachtet aller Programme die vernünftig mit Unicode umgehen) sich für alle Datei- und Pfadnamen auf ASCII beschränkt, nur um Fehler mit schlecht programmierter Software zu vermeiden. Das ist großer Mist. Noch dazu wenn meine Oma versucht sich dran zu halten und ihr Dokument dann doch mal im von Windows selbst angebotenen Vertzeichnis "Öffentliche Dokumente" ablegt.

Es macht auch keinen Sinn das mit der Kommandozeilenschnittstelle von grep zu vergleichen. Was du willst ist ungefähr so als würdest du Unicodezeichen im Suchstring von Grep verbieten wollen weil es einige Konsolen gibt die damit nicht klarkommen.

[BeRsErKeR]

Meine Ansicht rührt wohl daher, dass die Programme die ich schreibe ausschließlich für Leute gedacht sind, die sich gut mit dem PC auskennen und in der Regel englisch sprechen oder aber der englischen Sprache mächtig sind. Und von denen würde niemand auf die Idee kommen Umlaute in Dateinamen zu schreiben. Das bezieht sich auf C++ wo das ganze Encoding-Gedöns halt alles andere als trivial ist.

Die von dir angesprochene Zielgruppe wird aber sehr wahrscheinlich zu 99% an einem PC mit Windows sitzen und eher Schreibprogramme etc nutzen. Solche windows-spezifischen GUI-Applikationen schreib ich dann eh mit C# und da brauch ich mir um das Encoding von Dateinamen wenig Gedanken machen. ;)

Ich ging hier eher von Spielen und Konsolenanwendungen aus und die werden wie gesagt von anderen Leuten genutzt und bedient als von deiner oder meiner Oma. Und da muss man meiner Meinung nach nicht unnötig Aufwand in Dateinamen-Encodings investieren.

[Schrompf]

Schaue er folgenden Link an: http://zfx.info/viewtopic.php?f=4&t=2247

Da hatte jemand mein Spiel in einem Verzeichnis namens "Anhänge" abgelegt und prompt starb das Spiel, weil es manche der eigenen Dateien nicht mehr gefunden hat. Es ist langsam Zeit, dass Du einsiehst, dass Deine angenehm bequeme Haltung nicht mehr haltbar ist.