Mal wieder Kodierungsprobleme. ANSI UTF8 UTF16

[LTE5]

Leider habe ich keine Ahnung wie man das machen soll.
In meiner eigenen Ableitung von TMemIniFile rufe ich im Constructor ganz normal

Delphi-Quellcode:

inherited Create(FileName);

auf (+ andere Dinge passieren dort natürlich, sonst bräuchte ich keine Ableitung).

Update: dieser Thread hat jedenfalls das Problem behoben, dass die Datei als ANSI gespeichert wird, wenn sie vorher nicht existierte, aber Umlaute in der Datei zu finden waren
http://www.delphipraxis.net/126156-d...-encoding.html

[p80286]

Zitat:

Zitat von LTE5 (Beitrag 1386526)

Ich habe gelesen, ANSI sei veraltet.

Es gibt Szenarien, in denen die Anwendung einer Ansi-Codierung nicht optimal ist.
In diesen Fällen ist die Anwendung von UTF8 oder UTF16 auf jeden Fall besser.

Zitat:

Zitat von LTE5 (Beitrag 1386526)

Wie gehe ich das denn an, wenn ich das Encoding nicht kenne?

Zunächst das Encoding heraus bekommen, und dann alle betroffenen Dateien auf das gleiche Encoding umstellen.
Welches Du verwendest, ist egal, aber es muß bei allen das selbe sein!

Gruß
K-H

Edith:

Zitat:

Zitat von LTE5 (Beitrag 1386533)

Muss man das überhaupt angeben? Speziell bei Ini-Dateien ist es komisch. Speichere ich eine frische Ini-Datei mit einer Section wo äöü vorkommt, wird es als ANSI gespeichert.
Speichere ich ohne Umlaute, Speichert Delphi es als UTF8.

Da die Umlaute den Unterschied zwischen ANSI und UTF8 ausmachen, stelle ich mir die Frage woran Du die UTF8-Codierung fest machst?

[LTE5]

Ich glaube ich bleibe bei meiner Ini-Ableitung definitiv bei der Zeile

Delphi-Quellcode:

inherited Create(aFileName);

ohne Encoding-Hexerei.
So gibt es keine Fehlermeldung. Wenn jemand meint eine Datei unbedingt selber bearbeiten zu müssen, ist es in diesem Falle das eigene Pech.

Ansonsten habe ich jetzt alle meine Dateien auf UTF8 ohne BOM umgestellt, da selbst Windows neue Dateien so anlegt.
Meinen Code aus Beitrag #1 habe ich unverändert so gelassen.

Da ich zu wenig Ahnung von dieser Hexerei habe, befasse ich mich damit nicht weiter und belasse alles so, wie es fehlerfrei funktioniert.

[mensch72]

gaaaanz einfach, nix mit Ableitungen... nur einfach selbst VORHER "erkennen" ob UTF8 oder Ansi:)

Delphi-Quellcode:

ms:TMemoryStream
s:string;

ms:=TMemoryStream.Create;
ms.LoadFromFile('filename');

if IsUTF8(ms) then
  s := DecodeUTF8toString(ms)
else
  s := DecodeANSItoString(ms);
ms.free;
 
Memo1.Text:=s;
MemIniFile.Text:=s;

Du musst dir nur fix selbst(wie empfohlen) oder per "Try" mit TEncoding folgende 3 Funktionen basteln:)

Delphi-Quellcode:

function IsUTF8(const stream:TStream):Boolean;
function DecodeUTF8toString(const stream:TStream):string;
function DecodeANSItoString(const stream:TStream):string;

[LTE5]

Da ich eine universelle Lösung brauche für das Laden von Textdateien UND das Laden/Speichern von Ini-Dateien, kann ich das leider nicht gebrauchen.
Ich belasse von nun an aber alles so wie ich es aktuell habe, da es funktioniert.

Dieser ganze Encoding-Kram ist doch der Wahnsinn!

[mensch72]

..."Da ich eine universelle Lösung brauche für das Laden von Textdateien UND das Laden/Speichern von Ini-Dateien, kann ich das leider nicht gebrauchen."...

Jedem das seine, die paar da geschrieben Code Zeilen ergeben genau DIE UNIVERSELLE Lösung, die man sogar noch per einem weiterem IF auf zusätzlich UTF16 erweitern kann... aber mach wie du willst, nur schimpfe nicht auf das Encoding-Konzept... das hat wirklich seinen Sinn:)

[LTE5]

Ich sehe keine Möglichkeit die oben genannten Codezeilen in eine Ini-Klasse einzubauen.
Da steht zwar "IsUTF8" aber davon habe ich ja eben keine Ahnung.

Zitat:

das hat wirklich seinen Sinn

Ich verstehe es nicht einmal und werde es auch nie verstehen. Code soll einfach nur funktionieren und das machen was man ihm sagt. Ich habe keine Lust mich mit 100 verschiedenen Encodings rumschlagen zu müssen.

Habe meine Version aus #1 bearbeitet, damit ich noch weniger Kopfschmerzen wegen diesem komischen Encodingkram habe

Delphi-Quellcode:

try
 sl.LoadFromStream(ResourceStream{*, TEncoding.UTF8*});
 {$WARNINGS OFF}
 Result := UTF8ToString(sl.Text);
 {$WARNINGS ON}
finally
 sl.Free;
end;

[p80286]

Zitat:

Zitat von LTE5 (Beitrag 1386539)

Da ich eine universelle Lösung brauche für das Laden von Textdateien UND das Laden/Speichern von Ini-Dateien, kann ich das leider nicht gebrauchen.
Ich belasse von nun an aber alles so wie ich es aktuell habe, da es funktioniert.

Dieser ganze Encoding-Kram ist doch der Wahnsinn!

Nichts für ungut, aber diese Einstellung halte ich für kurzsichtig. Solange Du die Dateiinhalte auf die ASCII-Zeichen beschränken kannst, mag das gehen. Sobald Du über diesen Tellerrand hinaus gehst, muß Du Dich entscheiden, welche Codierung für Dich, oder besser die Aufgabenstellung, die richtige ist. Solltest Du den Bereich der Lateinische Schrift verlassen (müssen) ist meiner Meinung nach Unicode/UTF16 die richtige Wahl.

Gruß
K-H

[LTE5]

Ich hätte absolut kein Problem damit alles nach Unicode umzustellen.
Aber alleine schon die Tatsache, dass es eine Fehlermeldung bei Angabe des TEncodings gibt, wenn die Datei dieses Encoding aber nicht hat lässt mich alles über Board werfen, da ich auf sowas keine Lust habe.

Unicode-Anwendungen scheinen aber nicht so populär zu sein.
Beispiel an Inno Setup.
http://www.jrsoftware.org/isdl.php

1,113,859 Downloads die normale Version, 197,053 die Unicode.

[mensch72]

..."IsUTF8... Ich verstehe es nicht einmal und werde es auch nie verstehen. Code soll einfach nur funktionieren"...

=> UniCode und WideStrings sowie das "TEncoding" von Delphi sind eben NICHT perfekt, wenn es um in der Praxis durchaus übliche Files OHNE BOM geht... daher SCHREIBT MAN SICH DAS EBEN BESSER FIX SELBST, denn vom schimpfen oder verdrängen/ignorieren löst das Problem ja nicht, egal ob du dazu Lust hast oder nicht.

In #6 steht recht genau wie man diese Funktion sich selbst fix progammiert.... wenn du "später" zufällig doch mal hängst weil Delphi nun plötzlich bei abgeschalteter Warnung nun NICHT MEHR das macht was "du erwartest", sondern dann nun exakt das was du per Code gesagt hast... dann erkennst du eventuell den Vorteil von so scheinbar völlig unbedeutenten typsicheren Hilfsfunktionen;)