INI Russisch

[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

[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 von a.def:

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.