Umgang mit Textdateien verschiedener Kodierungen.

[Papaschlumpf73]

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.

[Jumpy]

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.

[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.

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.

[himitsu]

@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.

[Uwe Raabe]

Zitat von himitsu:

@UWE, geht das ìnzwischen auch bei DFMs?

In Delphi 10.4.1 wird (unabhängig von der Default-Codierung) ein UTF8-BOM geschrieben, wenn die Datei Non-ASCII Zeichen für Delphi Identifier enthält. Alle Non-ASCII Zeichen in String-Werten werden dagegen (schon) immer als Escape-Sequenzen dargestellt und erfordern keine UTF8 Codierung der DFM.

[Rolf Frei]

Wenn du eine Stringlist in Ansi speichern willst schreibe es so:

  Strings.SaveToFile('abc.txt', TEncoding.Ansi);

[MechMac666]

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...

[himitsu]

Jetzt wo du es sagst.

Vor paar Tagen war mir das im Windows auch aufgefallen. (ich dachte aber ich hätte nur nicht richtig geguckt)
Notepad speichert neuerdings als UTF-8, wenn man eine neue Textdatei erstellt hat.
(auf Arbeit bekomm ich sowas nicht mit, weil jemand der meinung war wir müssen unbedingt so einen hässlichen Notepad2-mod installieren, der bei ALLEN die notepad.exe ersetzt)

[MechMac666]

Zitat von himitsu:

Jetzt wo du es sagst.

Vor paar Tagen war mir das im Windows auch aufgefallen. (ich dachte aber ich hätte nur nicht richtig geguckt)
Notepad speichert neuerdings als UTF-8, wenn man eine neue Textdatei erstellt hat.
(auf Arbeit bekomm ich sowas nicht mit, weil jemand der meinung war wir müssen unbedingt so einen hässlichen Notepad2-mod installieren, der bei ALLEN die notepad.exe ersetzt)

Tja, wenn du mal was verrücktes sehen willst:
Create ne Tstringlist, adde eine Zeile "Hello MS" und speichere.
Das macht du nochmal mit "Hällo M$" und wieder speichern.

Die erste Datei ist in UTF8 und die zweite in ANSI. Selbst wenn du explizit in beiden
Fällen sagst er soll als ANSI speichern.

Zumindest wenn man Notepad glaubt...

[himitsu]

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.