INI Russisch

[Dalai]

Die Windows API unterstützt ANSI und UTF-16, aber NICHT UTF-8, wenn es um die Funktionen GetPrivateProfileString/WritePrivateProfileString geht. TIniFile greift auf eben diese Funktionen zurück. Im Total Commander Forum wurde das übrigens auch schon mehrfach diskutiert.

TL;DR: Benutze entweder ANSI oder UTF-16, aber kein UTF-8 (sofern du Klassen verwendest, die auf TIniFile aufbauen).

EDIT: Merke grade, dass es ja um TMemIniFile geht. Egal, ich lass den Kommentar trotzdem mal stehen.

Grüße
Dalai

[Der schöne Günther]

Ich verstehe das Problem nicht ganz - Sind das immer wieder neue Dateien die von jemand anderem erstellt werden oder hast du das in der Hand? Wenn ja, dann öffne die Datei doch einmal z.B. in Notepad++ und stelle die Kodierung fest auf z.B. "UTF-8 mit BOM".

Dann kann man z.B.

Zitat:

[someValues]
greetingMessage=Сука Блять

problemlos mit

Delphi-Quellcode:

var
   iniFile:   TMemIniFile;
   greeting:   String;
begin
   iniFile := TMemIniFile.Create('y:\someIniFile.ini');
   greeting := iniFile.ReadString('someValues', 'greetingMessage', '');
   ShowMessage(greeting);
end;

lesen.

[a.def]

Auf solche Spielereien würde ich mich nicht verlassen.
Es braucht dann nur jemand mit dem Windows Editor die Datei zu bearbeiten und zu speichern und schon zeigt das Programm falsche Texte an.
Ini schön und gut, aber für Sprachen zu speichern ist es keine gute Wahl.

[Der schöne Günther]

Zitat von a.def:

Es braucht dann nur jemand mit dem Windows Editor die Datei zu bearbeiten und zu speichern und schon zeigt das Programm falsche Texte an.

Tut es das? Das wäre mir neu.

[a.def]

Ich stand mal vor demselben Problem und sobald man die Ini geändert hat und andere Zeichen als A-Z, 0-9 drin waren, wurde es falsch angezeigt.

[Sherlock]

Doch, das passiert gerne. Aber nur in heterogenen Systemen(Mac und Win über Parallels greifen auf gleiche Ini zu) oder wenn Software sich beim Speichern nicht an die Vorgabe bzw. den Originalzustand hält.

Sherlock

[a.def]

Ich glaube am besten wäre es sich einen eigenen Reader zu bauen der ebenfalls eine Art Ini-Format ausließt.
Oder sogar was komplett anderes.

XML statt Ini vielleicht. Weiß nicht, ob das dann mit Umlauten usw funktioniert.
Jedenfalls braucht man für diese XML-Unit fast keine Änderungen an den aktuellen Ini-Stellen im Code zu treffen:
http://www.swissdelphicenter.ch/de/showcode.php?id=2269

[Der schöne Günther]

Aber wenn

• beliebige Software hinterrücks die Kodierung von bestehenden Dateien ändert
• und die eigentliche Software eine bestehende Kodierung erwartet

hat man generell ein Problem. Das hat ja weder speziell etwas mit ini-Dateien, noch mit Lokalisierung zu tun.

[a.def]

Zitat von Der schöne Günther:

Aber wenn

• beliebige Software hinterrücks die Kodierung von bestehenden Dateien ändert
• und die eigentliche Software eine bestehende Kodierung erwartet

hat man generell ein Problem. Das hat ja weder speziell etwas mit ini-Dateien, noch mit Lokalisierung zu tun.

Das Problem hier ist...
lass dein Programm mal eine Ini-Datei mit Umlauten speichern.
Nun verändere diese Umlaute in Notepad++ ohne an der Kodierung was zu verändern.
Nun lese die neue Ini-Datei mit deinem Programm ein. Die Werte werden nun nicht korrekt eingelesen ... eigentlich.

[Sherlock]

Zitat von Der schöne Günther:

Aber wenn

• beliebige Software hinterrücks die Kodierung von bestehenden Dateien ändert
• und die eigentliche Software eine bestehende Kodierung erwartet

hat man generell ein Problem. Das hat ja weder speziell etwas mit ini-Dateien, noch mit Lokalisierung zu tun.

Korrekt. Darum liegen Übersetzungen auch häufiger in Resourcefiles oder Datenbanken, als in Inifiles.

Sherlock