Stringirrsinn - Unicode, UTF8, Widestring,....

[kupferstecher]

habe ich die Hoffnung und die Beschäftigung mit Lazarus und dem damit verbundenen Chaos aufgegeben.
[...]
Meine Forderung ist:

Wozu, wenn du eh schon aufgegeben hast...

[Mathias]

Da stände im Win-Explorer dann "1091-Z'#$FC'rich.tif" statt "1091-Zürich.tif". Das ist ja noch schlimmer als "1091-Zuerich.tif" !

Bei Sachen die wirklich heikel sind, verwende ich nur Zeichen unterhalb von #127. Auch Leerzeichen meide ich, ich nehme immer Unterline.
Es gibt viele Kommandozeilentools, welche Probleme mit Umlauten und Leerzeichen haben.

[wp_xyz]

Ich habe nämlich davon keine Ahnung und will sie eigentlich auch nicht erwerben

Noch ein schönes Zitat aus deinem Beitrag, aus dem Zusammenhang gerissen, ok, aber doch eigentlich symptomatisch. Kein Problem damit wenn jemand "keine Ahnung" über eine bestimmte Sache hat und sich darin auch nicht einarbeiten will, aber woher nimmt der dann die Berechtigung, darüber so massiv zu lästern wie du?

[Niesi]

Liebe*r wp_xyz,
ich bin erst jetzt zufällig über Google mal wieder in dieses Forum hineingestolpert, denn wie ich schon im Beitrag vom 17.12.23 angedeutet habe, habe ich die Hoffnung und die Beschäftigung mit Lazarus und dem damit verbundenen Chaos aufgegeben. Aber erst einmal danke für Deine Antwort, die ich deshalb erst heute gesehen habe. Auch Dein Beitrag vom 18.1.2016 wie auch weitere und die von Michl nützen mir überhaupt nichts ohne eine verlässliche Qelle für ein aktuelles Lazarus *) mit dem das garantiert funktioniert bzw. eine Liste der notwendigen Komponenten und Compilersettings. Ich habe nämlich davon keine Ahnung und will sie eigentlich auch nicht erwerben; ich habe Lazarus ca. Mitte 2022 heruntergeladen und seitdem nichts dran verändert. Ich habe zwar mal etwas von RC1 gelesen, aber keine Ahnung wie und was ich damit machen sollte und könnte.

An sich kann ich mir Fälle, in denen es gut wäre, wenn die ganze Welt und alle Compiler Unicode und möglichst auch noch UTF-8 verwenden würden, gut vorstellen. Da die Welt aber bekanntlich vom Optimum weit entfernt ist, darf niemand, der auch nur einen Hauch von Intelligenz besitzt, fest davon ausgehen. Das scheint aber z.B. bei den Lazarus-Entwicklern und anderen der Fall zu sein. Es scheint leider so zu sein, dass der Herr Windows und der Herr Lazarus davon ausgehen, dass der jeweils andere sich nach der Nase des Gegenübers richtet - was mitnichten der Fall ist !

Meine Forderung ist: Ein Programm darf unter keinen Umständen die vorhandene Codierung verändern und dann auch noch sämtliche Workarounds vernageln wie Lazarus (z.B. ein Typ TFilenamen, garantiert ohnne Umcodierung), es sei denn, es kann das laufende Betriebssystem dazu bringen, die andere (dessen) Codierung richtig zu verarbeiten.

In dem Sinne ist Dein kleines Beispiel am Ende genau das, was ich nicht möchte, denn es macht nichts weiter, als einen Filenamen in einer Windows-fremden (UTF-8) Codierung zu schreiben, was Windows klaglos akzeptiert, und der dann ebenso klaglos wieder eingelesen werden kann. Das könnte ich natürlich problemlos auch machen: einfach durch Lazarus meine Fileliste in UTF-8 neu abspeichern und alles gut ? - nein ! Da stände im Win-Explorer dann "1091-Z'#$FC'rich.tif" statt "1091-Zürich.tif". Das ist ja noch schlimmer als "1091-Zuerich.tif" !
Gruß JK

*) ich arbeite nur mit dem GUI, der Quelltext ist nagelneu, mit Lazarus geschrieben und getestet. Wie gesagt, das Programm ist nicht so ganz trivial, aber funktioniert bis auf die Umlaute bestens.

Was ist Dein Problem? Du regst Dich mächtig darüber auf, dass Dateinamen "in einer Windows-fremden" Umgebung erstellt werden und dann in Windows nicht korrekt angezeigt werden?

Das kann ich nicht nachvollziehen, diese Problem kenn ich nicht. Da ich aus Erfahrung weiß, dass es mit Umlauten Probleme geben kann, habe ich das mal mit einem vorhandenem Testprogramm nachvollzogen und Dateien erstellt, welche Umlaute, ß und Leerzeichen im Dateinamen enthalten. Vier Dateien habe ich unter Linux erstellt, die "Win mit öÖ äÄ üÜ ß.txt" unter Windows - die werden auf beiden Systemen korrekt angezeigt.

Grundsätzlich vermeide ich aber Leerzeichen und Sonderzeichen in Dateinamen, da es besonders auf älteren Systemen Ärger damit geben kann ...

Linux_und_Windows.png (163.39 KiB) 2866 mal betrachtet

Du solltest Dir auch noch einmal gut überlegen, ob Du es mit dem Programmieren nicht lieber lassen solltest - das Gemotze in Deinem Text ist sehr daneben und zeugt von Unkenntnis, Unwilligkeit und Überheblichkeit. Das sind zur Softwareentwicklung die denkbar schlechtesten Voraussetzungen. Gärtnern kann auch sehr schön sein.

Es ist keine Schande, nichts zu wissen,
wohl aber, nichts lernen zu wollen ...

(Platon)

Eine weitere Erfahrung von mir ist: Die, die nichts zustande bringen, motzen am lautesten ...

[fliegermichl]

...
Eine weitere Erfahrung von mir ist: Die, die nichts zustande bringen, motzen am lautesten ...

Haha, das gilt nicht nur in der Softwareentwicklung sondern auch in der Politik

[Niesi]

Na klar - ich meine sogar: Überall ...

[Jokra]

Hintergrund, alles und nur unter Windows: Ich habe eine Anzahl (>200) gleichartiger Files (Wanderkarten als .tif) in einem Verzeichnis, dazu eine zugehörige Liste der Filenamen als .txt. Die Filenamen enthalten Nummern oder UTM-Koordinaten und zur (menschlichen) Orientierung zusätzlich (Text-) Namen, diese zu ca. 10% auch Umlaute. Die Files sollen anhand der Nummern identifiziert und nötigenfalls automatisch ausgewählt und dazugeladen werden. Funktioniert einwandfrei, so lange kein Umlaut im Spiel ist. Dann aber wird z.B. aus einem (Windows-{cp1252}) "ü" ein '#$FC' und nichts geht mehr. Das Problem entsteht, weil beim Übergeben des Filenamens aus einer automatisch hereingeladenen Stringliste, die noch ok ist und bleibt, in einen String die >#127 automatisch in UTF-8 umcodiert werden. Beim anschließenden if FileExists(MapFileName)then kommt folglich eine Fehlermeldung, weil der Filename so nicht existiert. Ich suche seit fast einem Jahr nach einem Weg, das zu verhindern.
Damit ist die Antwort auf die Frage (kupferstecher), warum Lazarus für mich inzwischen mental abgemeldet ist, schon beantwortet: ich habe es einfach aufgegeben und will damit nicht noch mehr Zeit vergeuden. Im Gegensatz dazu scheint sich matthias mit dem Chaos abgefunden zu haben. Wahrscheinlich sind für ihn andere Gesichtspunkte wichtiger, akzeptiert. Für mich muß aber ein Programm genau das machen, was ich will und wenn das partout nicht geht, ist das Programmiertool für mich keine wirkliche Option - eigentlich schade !
Ein Kommentar über den Rest der Beiträge erübrigt sich.

[wennerer]

Falls du noch einen Versuch starten möchtest dann lese mal diesen Beitrag:

viewtopic.php?f=25&t=9459

Keine Ahnung ob das dein Problem löst, aber versuch macht klug.

Viele Grüße
Bernd

[BeniBela]

Hintergrund, alles und nur unter Windows: Ich habe eine Anzahl (>200) gleichartiger Files (Wanderkarten als .tif) in einem Verzeichnis, dazu eine zugehörige Liste der Filenamen als .txt. Die Filenamen enthalten Nummern oder UTM-Koordinaten und zur (menschlichen) Orientierung zusätzlich (Text-) Namen, diese zu ca. 10% auch Umlaute. Die Files sollen anhand der Nummern identifiziert und nötigenfalls automatisch ausgewählt und dazugeladen werden. Funktioniert einwandfrei, so lange kein Umlaut im Spiel ist. Dann aber wird z.B. aus einem (Windows-{cp1252}) "ü" ein '#$FC' und nichts geht mehr. Das Problem entsteht, weil beim Übergeben des Filenamens aus einer automatisch hereingeladenen Stringliste, die noch ok ist und bleibt, in einen String die >#127 automatisch in UTF-8 umcodiert werden. Beim anschließenden if FileExists(MapFileName)then kommt folglich eine Fehlermeldung, weil der Filename so nicht existiert. Ich suche seit fast einem Jahr nach einem Weg, das zu verhindern.

Das kann doch gar nicht sein

Windows verwendet doch selbst Unicode für Dateinamen

Außerdem kann man mit windows.GetFileAttributesW (Unicode) und windows.GetFileAttributesA (nicht Unicode) den Dateinamen direkt an Windows übergeben, um zu überprüfen, ob die Datei existiert. Da funkt kein FPC/Lazarus dazwischen




Unter Windows hatte ich nie irgendwelche Probleme. Aber unter Linux ist es ein Problem. Da können die Dateienamen irgendwelche Bytefolgen sein. Da geht mit Unicode gar nichts. FPC hat wenigsten noch RawByteString. Qt/KDE setzt noch mehr auf Unicode. Da habe ich schon Verzeichnisse, die sich in KDE nicht mehr löschen ließen

[siro]

Ich korrigiere mal meine Beitrag,
der war evtl. zu abstrakt für das Problem....

Ich finde auch, dass die Stringverarbeitung ein riesen Problem darstellt.
Es gibt einfach zu viele Formate, die im Laufe der Jahre immer komplexer werden.

Lazarus versucht jedoch durch eine Vielfalt von Funktionen möglichst viele Varianten abzudecken.
Das macht es aber auch entsprechend schwierig, weil man kaum noch weis, was man anwenden soll.

Es gab mal Zeiten, da hatte jeder Buchstabe sein eigenes Byte. (Mann war das geil... )
Heute hat ein Asciizeichen bis zu 4 Bytes.
Dadurch wird es schon schwierig lediglich die Länge eines Strings zu ermitteln.
Zumindest gibt die ursprpüngliche Funktion wie bei Turbo Pascal "length" halt nicht immer
die richtige Länge zurück. Hier benötigt man halt neue Funktionen.
Ich finde es auch grausam, aber dafür kann ja Lazarus nichts...

[Jokra]

Danke Euch dreien für Eure sachlichen Beiträge (seit dem 17.3.). Könnte sein, dass mir das weiterhilft, aber ich brauche noch Zeit, um alles zu verstehen und zu probieren.
BeniBela: Ich glaube, Du hast 1/2 recht, aber ich weiß noch nicht, ob und wie Dein Hinweis helfen kann. Auf jeden Fall ist richtig, dass die deutschen Sonderzeichen (ä,ö,ü...) auch in den von Windows verwendeten Codepages 1252, 8859-1 und 8859-15 auf den Unicode-Plätzen $E4, $F6 und $FC stehen. Im Hex-Editor des Original-Filenamens steht also FC für ü. Mein Problem entsteht m.E. dadurch, dass bei der Übergabe in den Einzelstring MapFileName statt des 1-Byte-Zeichens FC noch die "Steuerzeichen" '#$__' hinzugefügt werden, gesamt also '#$FC'.
wennerer: Das mit den verschiedenen Stringtypen muss ich noch mal genauer testen; einige (rawbytestring, ansistring, string) habe ich schon probiert - ohne Erfolg. Aber jetzt mit WideString - oh Wunder - wird der Fileame im Debugger wenigstens schon mal richtig mit ä, ö, ü angezeigt. In den ShowMessage- und If MessageDlg-Texten dagegen immer noch nur mit Platzhalter. Dazu ein Haufen Warnungen im Source-Editor, dass implizite Konversionen von rawbyte- und ansistrings zu widestrings erfolgen. Und leider, beim If FileExists funktioniert es trotzdem noch nicht.

[Jokra]

Hier die Ergebnisse meiner vielen Versuche, dem Programm die richtige Verarbeitung von Umlauten beizubringen: Chaos !
Von 6 leicht unterschiedlichen Programmversionen, die bei den zahlreichen Versuchen entstanden sind, funktionieren inzwischen 4 soweit. -- Gut, aber ich weiß nicht wirklich warum. Zwingend erforderlich scheint " -dDisableUTF8RTL " in den Projekteinstellungen *) zu sein. WideString, RawByteString und " {$codepage cp1252} " habe ich z.T. weggelassen und es funktioniert trotzdem, wenn es denn funktioniert. Mit WideString zeigt z.T auch der Debugger den Umlaut richtig an, aber selbst wenn der Filename die UTF-8-"Steuerzeichen" '#$__' " enthält, wird er von FileExist akzeptiert. Wenn allerdings als Platzhalter die Raute mit dem Fragezeichen bei den zwei unten erscheint, funktioniert es nicht.
Die zwei restlichen Versionen sind durch absolut keine dieser Maßnahmen zu bewegen, dass FileExist mit einem Umlaut funktioniert, selbst nach Kalt- und Warm-Restart nicht. In meinem Souce-Code kann ich keine Ursache erkennen; es muss irgedwo etwas in den übrigen Files versteckt sein. - Oder liegt es am Wetter ?
*) Ich habe Lazarus Anfang 2022 heruntergeladen und seitdem nichts verändert.

[wp_xyz]

Irgendwie machst du etwas grundfalsch. -dDisableUTF8RTL habe ich noch nie gebraucht... Bitte poste ein kleines Programm, in dem dein Problem auftritt (mit Betonung auf "klein").

[h-elsner]

Ich verstehe die Frustration. Textdateien aus älteren Windowsversionen machen immer wieder Probleme. Gott sei dank eitert das aber langsam heraus.
Ich tippe nämlich darauf, dass die Probleme daher rühren, dass die Dateinamen aus der Textdatei gelesen werden. Man sollte also erst einmal klären, welche Kodierung die Textdatei hat. Eventuell hilft hier, die Textdatei in UTF8 umzuwandeln. Ich nehme unter Windows Notepad++ für solche Sachen.
Wie wäre es mit Hochladen von einem Sample so einer Textdatei? Dann könnte man probieren, ob sich die Dateinamen lesen lassen.

[BeniBela]

aber selbst wenn der Filename die UTF-8-"Steuerzeichen" '#$__' " enthält, wird er von FileExist akzeptiert.

Es gibt keine UTF-8-"Steuerzeichen" '#$__' !

Da zeigt der Debugger einzelne Bytes an

Vermutlich weil der String nicht Unicode ist