INI Russisch

[greenmile]

Hallo,

die Übersetzung meiner Anwendung (Windows) liegt in INI Dateien. Klingt komisch, is' aber so :) Nun muss ich eine russische Übersetzung reinladen und irgendwie sehe ich den Wald vor lauter Bäumen nicht mehr. Wenn ich die Quelldatei als UTF8 speichere, sieht sie zwar im TotalCommander gut aus, dafür kommen im Delphi nur ???? an.

FIniFile := TMemIniFile.Create(Filename, TEncoding.UTF8);
FIniFile.Encoding := TEncoding.UTF8;

oder

FIniFile := TMemIniFile.Create(Filename, TEncoding.Unicode);
FIniFile.Encoding := TEncoding.Unicode;

Funktionieren nicht. Normalerweise bin ich mit ANSI recht gut gefahren, jetzt peile ich es aber irgendwie nicht. Geht das nicht automatisch? Quasi: Lies ein was da ist und stell es automatisch ein? Ist das .Encoding notwendig? Und was für einen String Typ muss ich nehmen? Einfach nur String? Oder irgendwas besonderes?

[a.def]

Ich meine hier im Forum mal gelesen zu haben, dass das grundsätzlich ein Problem mit Ini-Dateien ist.
Du hast eine sehr schlechte Wahl getroffen, deine Sprachtexte im Ini-Format zu speichern :P

[himitsu]

Wenn die INI mit einer russischen Codepage codiert ist, dann mußt du auch ein russisches Encoding verwenden. :roll:

Grundsätzlich kann die Windows-INI-API aber nicht nur ANSI, sondern auch Unicode (UTF-16).

[greenmile]

Wenn ich eine TMemIni verwende, dann muss ich die Kodierung ja mitgeben. Gibt es da nicht die möglichkeit eines AutoDetect's? Außer mit TryExcept alles durchprobieren?

[Uwe Raabe]

Das im Create übergebene Encoding wirkt lediglich auf eine neu geschriebene Datei. Damit eine UTF8-Datei als solche lesend erkannt werden kann, muss sie ein entsprechendes BOM an Anfang haben. Wie hast du die Datei denn als UTF8 abgespeichert?

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

Zitat von a.def (Beitrag 1360308)

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:

Zitat von Der schöne Günther (Beitrag 1360318)

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:

Zitat von Der schöne Günther (Beitrag 1360318)

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

[p80286]

Naja es gibt ja Leute, die sagen, daß Konfigurationsdateien (ini,xml,json...) NIE in einem Editor sondern nur mit dem entsprechenden Programm bearbeitet werden sollen.
Wenn man sich daran hält, hat man auch keine Probleme (theoretisch).
Wie wäre es z.B. mit einer Erweiterung:

Code:

[LangDef]
codierung=utf8

oder

Code:

[LangDef]
codierung=ANSI CP1245

dann packt man noch einen String hinein, der nur mit der richtigen Kodierung funktioniert, und fertig ist die Laube.
(Natürlich hilft das nicht gegen Böswilligkeit)

Gruß
K-H

[DeddyH]

Ich kenne div. Programme, die sog. *.lng-Dateien benutzen. Schaut man da rein, sind das auch nur Schlüssel-Werte-Paare im Klartext, die man mit TStrings-Eigenschaften lesen/bearbeiten kann. Editiert man die mit dem falschen Programm, hat man dasselbe Problem, das hat mit dem Ini-Format recht wenig zu tun. Man könnt die Übersetzungen aber z.B. in entsprechende Ressourcen-DLLs auslagern, die bearbeitet normalerweise niemand.

[a.def]

Also ein generelles Problem mit Klartext-basierten Dateien?
Gut zu wissen.

[p80286]

Zitat:

Zitat von a.def (Beitrag 1360338)

Also ein generelles Problem mit Klartext-basierten Dateien?
Gut zu wissen.

Nö, je böswilliger Dein Gegenüber desto unsicherer die Dateien. Wir beide sind ja nicht die einzigen, die wissen wie man mit einem Hexeditor umgeht.

Die Frage ist eher, welchen Aufwand treibe ich um Daten sicher(?) zu speichern.

Gruß
K-H

[Whookie]

Oder man zipped sie eingach (evtl. auch noch mit Passwort) und beim Programmstart holt man sich die gewünschte Sprachdatei.

[Neutral General]

Zitat:

Zitat von Whookie (Beitrag 1360358)

Oder man zipped sie eingach (evtl. auch noch mit Passwort) und beim Programmstart holt man sich die gewünschte Sprachdatei.

Wieso? Wenn sich der Benutzer sein Programm zerschießen will dann soll er halt.

[Uwe Raabe]

Zitat:

Zitat von Neutral General (Beitrag 1360366)

Wieso? Wenn sich der Benutzer sein Programm zerschießen will dann soll er halt.

Genau :thumb:

Um es dem Anwender aber nicht gar zu leicht zu machen, kann man die Datei auch in einen Ordner verschieben, der für den Normal-Benutzer nicht so offensichtlich erreichbar ist (z.B. CommonAppData) bzw. nur mit Admin-Rechten verändert werden kann.

[Aviator]

Zitat:

Zitat von Uwe Raabe (Beitrag 1360369)

Zitat:

Zitat von Neutral General (Beitrag 1360366)

Wieso? Wenn sich der Benutzer sein Programm zerschießen will dann soll er halt.

Genau :thumb:

Ich würde es ja ähnlich sehen. Aber da ich bei uns nicht nur für die Programmierung sondern auch für die Administration verantwortlich bin, ist es mir lieber wenn alles läuft und funktioniert. Deshalb bin ich eher für die zweite Lösung von Uwe:

Zitat:

Zitat von Uwe Raabe (Beitrag 1360369)

Um es dem Anwender aber nicht gar zu leicht zu machen, kann man die Datei auch in einen Ordner verschieben, der für den Normal-Benutzer nicht so offensichtlich erreichbar ist (z.B. CommonAppData) bzw. nur mit Admin-Rechten verändert werden kann.

[greenmile]

Zitat:

Zitat von Uwe Raabe (Beitrag 1360290)

Das im Create übergebene Encoding wirkt lediglich auf eine neu geschriebene Datei. Damit eine UTF8-Datei als solche lesend erkannt werden kann, muss sie ein entsprechendes BOM an Anfang haben. Wie hast du die Datei denn als UTF8 abgespeichert?

Die wurde im Notepad++ als UTF8 gespeichert.

[Uwe Raabe]

Zitat:

Zitat von greenmile (Beitrag 1360391)

Die wurde im Notepad++ als UTF8 gespeichert.

Dann wähle doch dort mal die Kodierung UTF-8 (nicht UTF-8 ohne BOM).

Du könntest die Datei auch mal hier anhängen, dann könnte man es auch selber mal probieren.

[Whookie]

Zitat:

Zitat von Neutral General (Beitrag 1360366)

Zitat:

Zitat von Whookie (Beitrag 1360358)

Oder man zipped sie eingach (evtl. auch noch mit Passwort) und beim Programmstart holt man sich die gewünschte Sprachdatei.

Wieso? Wenn sich der Benutzer sein Programm zerschießen will dann soll er halt.

In einer idealen Welt hast du vollkommen recht :!: