Hallo,

ich bin gerade über die Änderung in Win10 gestolpert das Textdateien nun in UTF8 gespeichert werden.
Abschalten möchte ich dies nicht, da es ja nicht nur auf meinem Rechner so ist.

Es ist so das ich in meinen Programmen viele Einstellungen in Textdateien speichere. Bisher im ANSI format.
Dazu nutze ich fast überall die TStringlist.
Nun habe ich nach einem Wechsel auf Win10 gemischte Dateien, da einige nur aus Win7 übernommen wurden.
(Soll heißen UTF8 und ANSI)

Eine Testanwendung in der aktuellen Delphi IDE (memo1.lines.loadfromfile(...)) hat eine UTF8 Datei nicht richtig gelesen bezüglich der Sonderzeichen.

Wie sollte ich hier am besten vorgehen? Also auch in Hinblick auf die Zukunft.
Theoretisch müsste ich ja nun grundsätzlich vor jedem öffnen das Dateiformat erkennen und ggf. konvertieren.

Gruß, Andreas

Erstmal die Frage: Woran machst du das überhaupt fest? UTF-8 und ANSI unterscheiden sich ja u.U. gar nicht. Gibt es ein UTF-8 BOM?

Zitat:

Wie sollte ich hier am besten vorgehen? Also auch in Hinblick auf die Zukunft.

Am Besten alles als UTF-8 speichern. Um alte und neue Dateien zu unterscheiden, kannst du ein UTF-8 BOM hinzufügen. Unüblich, aber erlaubt. Alles ohne BOM als ANSI betrachten und konvertieren.

Zitat von jfheins:

Erstmal die Frage: Woran machst du das überhaupt fest?

Was mache ich fest? (Verstehe die Frage nicht.)
Zu der letzten Frage: Windows scheint nicht mit BOM zu speichern. Zumindest ist es in Notepad nicht so eingestellt.


Ich habe einige Versuche gemacht mit "tstrings".
-Delphi scheint weiterhin als ANSI zu speichern.
-Wenn ich eine UTF8 Datei lade und wieder speichere ist sie weiterhin UTF8, auch bei modifikation mit ASCII zeichen.
Bei Modifikation mit z.B. "ä" oder "ü" wird daraus beim speichern eine ANSI Datei.


Ok, bleibt das Problem falls ich eine Datei in Notepad bearbeite und anschließend mit Delphi verwenden möchte UND Sonderzeichen enthalten sind.
Im einfachsten Fall eine Liste mit Dateipfaden welche "ä", "ö" etc. enthalten.
Wie soll ich ich nun erkennen ob das UTF8 oder ANSI ist? (Notepad kann's offensichtlich)

Gruß, Andreas

Dasselbe Problem habe ich auch mit Textdateien aus Notepad seit Win10. Wenn ich es gemerkt habe, habe ich sie dann im Notepad als Ansi gespeichert. Leider aber noch keine Zeit gehabt, mich wirklich darum zu kümmern.

Nur zum Verständnis: Werden diese Dateien auch außerhalb vom Delphi-Programm manipuliert und das ist dann das Problem? Den Delphi kannst du ja sagen, dass es immer ANSI schreiben und lesen soll.

Ich benutze immer Notepad++ als Texteditor. Da kann man die Codierung erkennen und ändern.

Seit kurzem bietet Delphi eine interaktive Option für das Standard-Dateiformat unter Tools - Optionen - Benutzeroberfläche - Editoroptionen - Standarddateocodierung. Vorher konnte man das nur über einen Registry-Eintrag ändern.

Aktuell wird die aktuelle Codierung einer Unit auch in der Statuszeile des Editors angezeigt und lässt sich auch dort ändern. Bei älteren Delphi-Versionen geht das noch über das Kontextmenü.

In allen Fällen schreibt Delphi aber ein BOM in die Datei und benutzt dieses auch für die Erkennung. Ohne BOM wird strikt ANSI angenommen. Obwohl unüblich (zumindest unter Linux) - für Delphi ist das UTF8-BOM obligatorisch! Das hat u.A. auch Vorteile bei den diversen Versionskontrollsystemen, da dort auch schon mal andere Annahmen herrschen als bisher unter Windows üblich.

@UWE, geht das ìnzwischen auch bei DFMs?

Hab es noch nicht ausprobiert, aber da ich zufällig gestern mal wieder das Problem in XE hatte, dass bei DFMs das UTF-8-BOM verschwindet.
Außerdem macht das Text-EnDecoding bzw. Binär-Text-Umkodieren dort ja eine eigene "Funktion".


Entweder Delphi/IDE muß das besser können oder ich muß an unserem fanatischen Linux-Jünger vorbei im GIT für Delphi versuchen das anzupassen.
GIT (Tortoise/GitHub) hat Merge paar Problemchen, wenn es jeweils UTF-8 und ANSI versucht zu mergen.

Zitat von Uwe Raabe:

Seit kurzem bietet Delphi eine interaktive Option für das Standard-Dateiformat unter Tools - Optionen - Benutzeroberfläche - Editoroptionen - Standarddateocodierung. Vorher konnte man das nur über einen Registry-Eintrag ändern.

Deine Aussage bezieht sich aber jetzt auf die Projektdateien (*.pas, *.dfm, etc.)
Darum geht es hier ja nicht.

Zitat von Jumpy:

Nur zum Verständnis: Werden diese Dateien auch außerhalb vom Delphi-Programm manipuliert und das ist dann das Problem?

Bis vor fünf Minuten hätte ich "Ja" gesagt, aber gerade habe ich ein Programm von mir aus 2017 gestartet, welches eine "Jobliste" ganz simpel aus einer TStringlist speichert:
Und das Ergebnis ist laut Notepad in UTF8. Allerdings macht es das auch unter WIN 7. Aber in beiden Fällen ist das nicht gewollt. Es ist nur nie aufgefallen, weil Notepad unter Win 7 das so nicht anzeigt und bisher keine Sonderzeichen enthalten waren.
Ich muss da erstmal weitere Versuche machen...

Bisher war es ja so:
* im Linux Textdateien standardmäßig als UTF-8 ohne BOM
* im Windows ANSI (ohne BOM)
** oder UTF-8 mit BOM, bzw. Unicode/UTF-16 mit BOM,
** bzw. INI/XML/JSON beim Unicode ohne BOM, aber da ist ja das 2. oder 1. Byte somit #0 (BE oder LE)


* XML überall ohne BOM ... Unicode wie beim INI an '<'#0 oder #0'<'
* und sonst ist die erste Zeile praktisch immer ASCII und im Encoding-Tag steht dann die anschließende UTF-8- oder ANSI-Codepage



Ansonsten mach ich es aktuell auch mit "Heuristik", so wie viele Texteditoren und sogar inzwischen auch die Delphi-IDE,
also auf BOM gucken und wenn nicht, dann erstmal auf Unicode #0#x oder #x#0 schauen (wenn es der Inhalt erlaubt, wie z.B. bei INI oder XML, welche mit bestimmten ASCII-Zeichen beginnen),
danach dann (wenn immernoch nichts gefunden) als UTF-8 laden, wenn's "knallt" als ANSI versuchen und wenn es da dann auch nochmal knallt (beim nachfolgenden ANSI->Unicode), dann wird es als EASCII geladen, also die AnsiChar 1:1 ins WideChar übernommen.


Und Speichern vorwiegend als UTF-8 ... meistens noch mit BOM, zumindestens wenn's im Windows bleibt und von Fremdprogrammen gelesen werden können soll.

Bei propitären Binärdateien (was fast nicht mehr vorkommt) versuche ich Formate zu verwenden, welche die Formaierung mit enthalten, wie z.B. TReader und TWriter der DFM-Resourcen, welche man problemlos auslesen/entziffern kann, ohne zu wissen was drin steht, weil die Dekodierungsinfos enthalten sind.
So wird z.B. beim Speichern von Strings dort je nach Textlänge und Codierung zwischen 3 String-Typen gewählt und beim Auslesen löst ReadString das von selbst auf.
Also entweder menschenlesbare Formate oder Formate, welche man auch lesen könnte, selbst wenn das Programm nicht mehr funktioniert und niemand mehr weiß was wie in der Datei/Stream drin steht.

TReader/TWriter ist nicht wirklich dokumentiert (könnte man aber mal machen und ist recht einfach), aber seit bestimmt 30 Jahren in den Grundlagen unverändert ... und wird bestimmt auch in Zukunft noch lange existieren.
Ich würde es fast mit dem Versuch von PDF-A vergleichen.
Für Container-Formate versuche ich auf ZIP aufzubauen, was auch schon soooooo alt ist.
Sogar viele Office-Programme nutzen inzwischen XMLs in einer ZIP, mit anderer Dateiendung, also bauen neue Formate auf altbewehrten grundlegenden Techniken auf.