Ich grüße Sie,

ich habe vor einige Werte in eine Ini-Datei zu speichern, aber die IniFiles-Uses kann wohl kein Unicode und deswegen überlege ich wie ich jetzt vorgehen soll. Eine zusätzliche Komponente möchte ich meiden, daher meine Frage: was liefert Delphi 2010 mit um die ini-Lösung zu ersetzen? Oder kann man dieser doch irgendwie Unicode beibringen?

Danke!

Normalerweise sollte D2010 INI-Files auch standardmäßig in Unicode erstellen und beschreiben.
Hast du evtl. versucht eine bereits bestehende ANSI-codierte INI-Datei zu verändern? Dann schreibt Delphi die Datei AFAIK auch weiterhin mit ANSI.

Ansonsten probiers doch mal mit einer TMemInifile und Angabe des Encodings:

markieren

Delphi-Quellcode:

FIniFile := TMemIniFile.create(Filename, TEncoding.UTF8);
FIniFile.WriteString(...,...);
...
FIniFile.UpdateFile();

Aber generell: was spricht gegen XML statt INI? Ist meist für komplexere Werte eleganter und auch nicht sonderlich schwer zu handeln...

Guten Morgen,

oder je nach Art der Daten macht sich auch ein TClientDataset ganz gut...

Grüße

Zitat von OrNEC:

ich habe vor einige Werte in eine Ini-Datei zu speichern, aber die IniFiles-Uses kann wohl kein Unicode und deswegen überlege ich wie ich jetzt vorgehen soll. Eine zusätzliche Komponente möchte ich meiden, daher meine Frage: was liefert Delphi 2010 mit um die ini-Lösung zu ersetzen?

Mit etwas Einarbeitung ist XML die flexibelste Alternative

Für einige wenige Werte ist der Overhead von XML oder TClientDataset doch viel zu groß, noch dazu bringt es keinen Vorteil. D2010 kann Unicode-Inis, wo also ist das Problem?

Bei mir kann es leider nicht, obwohl die ini-Datei von Delphi neu erstellt wird. Liegt es vllt daran, dass ich ganz normalen String Datentyp verwende und nicht WideString und wie die da alle heißen?

Wenn ich den Code von blackfin anwende, bekomme ich eine Ini in UTF8-Kodierung. Du musst wohl irgend etwas falsch machen.

Zitat von cookie22:

Für einige wenige Werte ist der Overhead von XML oder TClientDataset doch viel zu groß, noch dazu bringt es keinen Vorteil.

Da wir nicht wissen wie aufgebläht seine Ini-Datei ist wird das spekulation sein ob das Overhead ist oder nicht.
Gut ist wenn man sich grundsätzlich damit auseinander setzt. Wir setzten selbst bei kleinen Tools auf XML weil wir eine "XML-Ini"-Klasse haben welche den Mehraufwand gegenüber einer Ini-Datei gegen 0 streben lässt.

Zitat von OrNEC:

Bei mir kann es leider nicht, obwohl die ini-Datei von Delphi neu erstellt wird. Liegt es vllt daran, dass ich ganz normalen String Datentyp verwende und nicht WideString und wie die da alle heißen?

Der Type String = UnicodeString unter D2010.
Dein Problem ist wohl eher das die WinApi (TIniFile verwendet im Hintergrund die WinAPI) bei Neuanlegen standardmäßig erstmal mit Ansi-Dateien arbeitet und nicht bei bedarf diese nach Unicode ändern kann.
Wenn du die Inidatei hart mit Unicode (Ich denke eine Leere Ini-Datei mit einem UTF8/Unicode-BOM-Header sollte reichen) anlegst sollte Windows auch weiter mit Unicode arbeiten.

Zitat von Bernhard Geyer:

Wenn du die Inidatei hart mit Unicode (Ich denke eine Leere Ini-Datei mit einem UTF8/Unicode-BOM-Header sollte reichen) anlegst sollte Windows auch weiter mit Unicode arbeiten.

Wie mache ich das genau? Hast du vllt ein Beispiel? Danke!