Umgang mit Textdateien verschiedener Kodierungen.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1473220)

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

Delphi-Quellcode:

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

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