Aber was anderes was mir in diesesm Zusammenhang gerade auffällt. WideStrings als Dateinamen? In der glBitmap benutzte ich nur normale Strings. WideStrings zu Strings konvertieren funktioniert innerhalb Pascal automatisch. Das auch halbwegs gut. Aber asiatischen Schriftzeichen gehen dabei gnadenlos verlohren. Und dann wäre es nicht möglich diese Dateien zu öffnen. Zu mindest in Delphi. Ob FreePascal bei dem FileStream automatisch WideStrings benutzt weiß ich nicht. Nichts desto trotz hätte ich zwischenzeitlich Strings und damit wäre die Informationen bereits weg. Also ich vermute mal, dass du damit später Probleme bekommen könntest.

Jetzt hast Du mich unsicher gemacht und ich habe nachgesehen:

Auszug aus der Delphi-Hilfe, Stichwort = "Erweiterte Zeichensätze"


Bei meinem eigenen Image-Objekt sieht das so aus (der T16bString ist bloß ein WideString):



Der Compiler schluckt den WideString im Konstruktor TFileStream.Create völlig kommentarlos. Die Datei kann gespeichert und auch wieder geladen werden, aber ich habe natürlich das deutsche Gebietsschema hier. Ich habe daraus abgeleitet, dass es für Delphi eigentlich unzulässig wäre, z.B. im Gebietsschema "Russisch" den String in einen T8bString (= bloß meine eigene Nomenklatur) zu konvertieren, weil UniCode-Kodierung für cyrillisch bereits nicht mehr in ein Byte hineinpasst. Sollte doch so sein, oder?

Dich zu verunsichern war nicht meine Absicht. Ich wollte nur verhindern, dass es ein "böses" erwachen gibt. Da ist es selber nicht so 100%tig genau wusste hab ich gerade mal geschaut.

Der Kompiler akzeptiert so etwas kommentarlos. Aber auch nur, weil er intern den WideString in einen AnsiString umwandelt. Und zwar benutzt er dazu Windowsfunktionen und die richten sich nach dem im System eingestellten Gebietsschema/CodePage. Also im Deutschen benutzt er die Latin-1 Codepage und im Kyrillischen die Kyrillische.

Ich habe gerade mal folgenden kyrillischen Buchstaben (Д) in einen WideString geschrieben und einem String zugewiesen. Das wurde kommentarlos in ein Fragezeichen umgewandelt. Diesen WideString an ein TFileStream zu übergeben hatte als Resultat, dass ich eine Exception bekommen hatte. Genau so bei dem Ansistring, denn Fragezeichen deuten in Windows auf ein Gerät, da CreateFile für so ziemlich alles benutzt wird. LPT, COM, etc etc etc... Mit der Methode CreateFileW hingegen ging es Problemlos. Und der Name wurde im Explorer richtig angezeigt. Aber mit der Datei kam Notepad++ gerade auch nicht klar.



Unter Delphi gibt es meines Wissens nach keinen FileStream der auch sofort mit WideStrings klar kommt. Wie das unter FreePascal aussieht weiß ich aber nicht. Evtl haben die da schon etwas gemacht.

Allerdings wenn man nicht gerade jeglichen Inhalt auf der Festplatte eines Users anzeigen will (in einem mp3 player oder so), dann wird man vermutlich auch mit AnsiStrings auskommen. Wenn es um Texturen geht, dann kann man so etwas einem Entwickler auch zumuten. Denke ich.

Entschuldige, ich wollte nicht Deinen Projekt Thread zumüllen. Eventuell kannst Du das nachträglich verschieben? Aber ich muss doch nochmal nachhaken: angenommen ich bin ein Russe und HABE das cyrillische Gebietsschema. Müsste dann nicht der Dateiname in korrektem Unicode abgespeichert werden?

Oder heißt das, die kyrillische Codepage beginnt wieder bei Null?

Habs mal getrennt und verschoben. Ist ja kein Ding. Hab ja selber damit angefangen.


Bei ANSI hast du nur 1 Byte für die Zeichen zur Verfügung. Deswegen wurden irgendwann die Codepages / Gebietsschemen erfunden. Dabei wird den Zeichenwerten ein anderes Zeichen zugeordnet. Bei der ISO 8859 sind die ersten 128 Zeichen ziemlich identisch. Zu mindest das was früher Ascii (englische Zeichen) war. Durch die Codepages hat man bei einem Text immer 2 Informationen. Der Text und die dazugehörende Codepage. Wenn du einen kyrillischen Text bei dir siehst wird da nur murks drin stehen (außer ascii). Wenn du den aber wieder in kyrillischem Gebiet betrachtest ist er wieder normal.

Dateinamen sind teils auch nur in Ansi gespeichert. Wenn du diese Codepage aktiv hast ist alles in Ordnung. Bist du woanders ist der Name murks. Wenn du jetzt möchtest, dass die Datei/Texte wirklich überall gleich aussehen, dann muss man sie in Unicode speichern.

Das Problem bei der Konvertierung von Unicode zu Ansi ist, dass nur das aktuelle Gebietsschema berücksichtig wird. Um vermutlich so viele lesbare zeichen wie möglich zu retten. Und alle anderen Zeichen fallen raus bzw werden zu "?". Und das ist in Dateinamen kein zulässiges Zeichen. Da weigert sich Windows, da man damit auch Gerätetreiber auswählen kann.

Benutz multibyte bezeichner und wenn delphi kein filesupport für diese bietet, dann implementier die dateizugriffe direkt über die windowsapi, denn die ist multibyte fähig.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hallo, ihr beiden,

Wenn wir das bisher Gesagte mal auf den Punkt bringen bedeutet das:

1) Windows könnte auch einen 2Byte-String(WideString) als Dateinamen haben
2) Aber Delphi-Dateiverwaltungsfunktionen und auch das Streaming funktionieren nur mit 1Byte-Strings. Daraus ergeben sich Schwierigkeiten sowohl beim Anzeigen als auch beim Lesen und Schreiben von Dateien.

Was Free Pascal betrifft, so habe ich auf dieser Website http://wiki.freepascal.org/LCL_Unicode_Support folgendes gefunden:

Tja. Sieht so aus als ob nicht nur die Delphi-Dateiverwaltung veraltet wäre. Eigentlich bräuchte man hier eine komplett neue Library, die das kann. Gabs da nicht mal irgendwelche TNT-Komponenten?

Sieht traurig aus für meinen Unicode-Support, ehrlich gesagt. Die Font kann es zwar, aber die Pascal-Unterstützung ist >>suboptimal<<.

Die Konsequenzen, die ich daraus ziehe: ich lasse den Unicode-Support für das anstehende Publishing mal fallen. Ich meine damit, dass ich keine Zeit mehr habe, das gründlich zu machen. Ich schließe es also nicht aus, sondern verschiebe es nur. Die Erfahrung hat gezeigt, dass bei überstürzten Implementierungen bloss Müll rauskommt.
Traude

Hallo,

1) Ja. Du kannst sowohl Ansi als auch Widestrings benutzen. Also echte Unicodedateinamen die überall den gleichen Namen haben. Obs es da noch unterschiede wegen Partition gibt etc will ich nicht ausschließen.

2) Ja. Delphi arbeitet da leider vollständig in Ansi. Die Unicodestrings die du intern benutzt sollten ja funktionieren sofern du immer mit WideStrings arbeitest. Wenn du nur Unicode in Streams benötigst, dann könntest du in Delphi selber eine Ableitung von THandleStream erstellen und das entsprechende Handle mit FileCreateW erstellen und zuweisen. Der Rest ist unabhängig und die Klasse wäre TStream kompatibel. Allerdings fehlen dann alle sonstigen Methoden (DeleteFile, ForceDirectories etc).

Wenn ich das auf der Seite richtig gelesen habe, dann arbeitet Lazarus überwiegend mit UTF-8 Strings. Allerdings läuft das dann wieder auf eine Unterscheidung Delphi/fpc hinaus. Die TNT Komponenten sind nur eine Ersetzung für die VCL Komponenten. Allerdings meine ich, dass es die nicht mehr zum freienDownload gibt sondern nur noch zu kaufen.

Was die Unterstützung angeht. Überwiegend arbeitet man ja mit Text innerhalb (auf komponenten). Und das sollte ja problemlos funktionieren. Ist bei meinen Fonts auch nichts anderes. Intern arbeite mit UCS-2 (0-$FFFF) aber auf Dateiebene kann ich auch nur in Ansi. Da der Rest funktioniert sehe ich das jetzt ganz so tragisch. Werde ich später irgendwann mal nachlegen.

PS: Aber ja überstürzen bringt vermutlich nicht viel. Aber ich denke fehlender Unicode Dateisupport ist etwas womit man vermutlich noch leben könnte.