Chinesisch/Russisch in Delphi nur mit Bordmitteln?

[clancy38]

Ich hab da ein großes Problem mit einem Programm, was schon mehrsprachig ist, aber jetzt um die Sprachen Chinesisch (Simple-Pinyin) und Russisch erweitert werden soll.
Die bisherigen Übersetzungen sind in Text-Files eingetragen und werden auch als TextFiles eingelesen und den Komponenten-Captions zugewiesen. Das klappt soweit auch ganz gut. Es wurde jetzt eine Excel-Datei mit einer Spalte Deutsch zum Übersetzer gegeben und mit einer zweiten Spalte Chinesisch ist sie zurückgekommen. Ich hab diese SPalte als Text-Datei abgespeichert, allerdings, was dann im Programm aus dieser Textdatei gelesen wurde, das kann man vergessen, das hat mit den Zeichen in der Excel-Tabelle nix mehr zu tun.

Ich hab hier schon einiges über die TNTControls gelesen, alles schön und gut, aber ich muß das ganze mit den vorhandenen Delphi-Bordmitteln und mit den Standardkomponenten wie TLabel realisieren.

Verwendet wird Delphi2005, das Programm läuft dann sowohl auf Rechnern mit Win2000 als auch XP.

Erstell ich die Textdatei aus Excel vielleicht falsch? Oder geht das so gar nicht mit den Bordmitteln?
Jeder Tip ist willkommen!

[Olli]

Bei Russisch sollte es klappen, wenn du einfach die Codeseite aller Komponenten auf die entsprechende Kyrillisch-Codeseite setzt. Damit sollte die "Übersetzung" aus den von dir genannten kryptischen Zeichen in kyrillische Zeichen gelingen.

Bei Chinesisch fällt mir allerdings nichts ein - zumal ja die ganze VCL ANSI-basiert ist. Da ich mich entsinne, daß es mehr chinesische Schriftzeichen gibt, als 2^8, ist es wohl auch kaum möglich durch Änderung der Codeseite etwas zu bewirken. Aber versuchen kannst du es ja ... ich kenne mich da bei Chinesisch nur nicht mit aus.

Bsp: wenn du eine kyrillische Codeseite benutzt, werden in der Darstellung aus ä, ö, ü kyrillische Buchstaben.

[jus]

@clancy38

Zitat:

Zitat von clancy38

Ich hab da ein großes Problem mit einem Programm, was schon mehrsprachig ist, aber jetzt um die Sprachen Chinesisch (Simple-Pinyin) und Russisch erweitert werden soll.
Die bisherigen Übersetzungen sind in Text-Files eingetragen und werden auch als TextFiles eingelesen und den Komponenten-Captions zugewiesen. Das klappt soweit auch ganz gut. Es wurde jetzt eine Excel-Datei mit einer Spalte Deutsch zum Übersetzer gegeben und mit einer zweiten Spalte Chinesisch ist sie zurückgekommen. Ich hab diese SPalte als Text-Datei abgespeichert, allerdings, was dann im Programm aus dieser Textdatei gelesen wurde, das kann man vergessen, das hat mit den Zeichen in der Excel-Tabelle nix mehr zu tun.

Eigentlich gibt es nur 3 Möglichkeiten wie das Textfile abgespeichert ist:

-Das Programm kann überhaupt nicht die von Excel-übergebenen Unicodezeichen abspeichern. Dann sind die chinesischen Zeichen alle als "?????" abgespeichert

-Das Programm speichert es als Multibyte Zeichen. Dann benötigt man neben installierte chinesische Schriften auch die richtige Codepage/Spracheinstellung, damit die Zeichen richtig dargestellt werden.

-Das Programm speichert es als Unicode Zeichen, zu erkennen normalerweise an die ersten 2 Bytes ($FF$FE), dann benötigt man unter Win200/WinXP neben der chinesische Schrift nur eine Unicodekomponente, die das richtig darstellen kann, und zwar vollkommen unabhängig von der gewählten Spracheinstellung, das bedeutet, dass auch in einem russischen Windows chinesische Zeichen richtig angezeigt werden, solange chinesische Schriftzeichen installiert sind.

Zitat:

Zitat von clancy38

Ich hab hier schon einiges über die TNTControls gelesen, alles schön und gut, aber ich muß das ganze mit den vorhandenen Delphi-Bordmitteln und mit den Standardkomponenten wie TLabel realisieren.

Verwendet wird Delphi2005, das Programm läuft dann sowohl auf Rechnern mit Win2000 als auch XP.

Erstell ich die Textdatei aus Excel vielleicht falsch? Oder geht das so gar nicht mit den Bordmitteln?
Jeder Tip ist willkommen!

Ich kenne zwar den Grund nicht warum du Tntkomponenten nicht benützen willst/darfst, aber meine Meinung ist, dass der Umweg über die Spracheinstellung/Codepages eher an Amateurbastellösung grenzt als an sauberer Lösung in einem vom Haus aus unicodefähigen Betriebssystem wie Win2000 und WinXP. Und das Tolle an TNTControls ist noch, dass der Autor Troy Wolbrink absichtlich die Komponentennamen und Befehle sehr ähnlich wie die Delphi VCL Komponenten gewählt hat. (z.B. statt TLabel.Caption -> TTntLabel.Caption, TMemo -> TTntMemo, usw.)

Grüsse,
jus

P.S.: Ja, ich gebe es zu. Es gibt noch mehr Möglichkeiten in Unicode zu speichern wie UTF8, Unicode Big-Endian,... :duck:

[Olli]

Zitat:

Zitat von jus

als an sauberer Lösung in einem vom Haus aus unicodefähigen Betriebssystem wie Win2000 und WinXP.

Ob das mal jemand Borland verklickern kann? Windows NT 4.0 kam vor 10 Jahren raus und beherrschte auch bereits Unicode ;)

Übrigens: "?????" kann auch ein Hinweis dafür sein, daß der aktuelle Font das Zeichen nicht kennt. Je nach Font kann das auch als kleines Quadrat dargestellt sein.

[jus]

Zitat:

Zitat von Olli

Zitat:

Zitat von jus

als an sauberer Lösung in einem vom Haus aus unicodefähigen Betriebssystem wie Win2000 und WinXP.

Ob das mal jemand Borland verklickern kann? Windows NT 4.0 kam vor 10 Jahren raus und beherrschte auch bereits Unicode ;)

Ja, ich würde mir auch ein unicodefähiges VCL für Win32 von Haus aus wünschen. :)

Zitat:

Zitat von Olli

Übrigens: "?????" kann auch ein Hinweis dafür sein, daß der aktuelle Font das Zeichen nicht kennt. Je nach Font kann das auch als kleines Quadrat dargestellt sein.

Wenn bei mir eine Komponente Kästchen ausgibt, dann ist es für mich ein Zeichen, dass die Schrift das Zeichen nicht unterstützt. Das mit den Fragezeichen war für mich bisher immer ein Zeichen dafür, dass das Programm nicht mit Unicode umgehen kann. Aber man lernt ja nie aus. :wink:

@clancy38
Vielleicht können wir uns auch leichter tun, wenn du einen kurzen Ausschnitt deiner Textdatei hier posten kannst.

Grüsse,
jus

[SirThornberry]

ich tippe das die Textdatei nicht unicode ist. So weit ich weiß ist Delphi doch seit BDS2005 oder BDS2006 Unicodefähig (zumindest der Quelltexteditor wenn ich mich recht entsinne)

[Olli]

Zitat:

Zitat von jus

Wenn bei mir eine Komponente Kästchen ausgibt, dann ist es für mich ein Zeichen, dass die Schrift das Zeichen nicht unterstützt. Das mit den Fragezeichen war für mich bisher immer ein Zeichen dafür, dass das Programm nicht mit Unicode umgehen kann. Aber man lernt ja nie aus. :wink:

Hab's nachgeprüft. Du hast vollkommen recht. Asche auf mein Haupt ;) :pale:

[DP-Maintenance]

Dieses Thema wurde von "sakura" von "Programmieren allgemein" nach "VCL / WinForms / Controls" verschoben.

[himitsu]

der Typ TextFile ist definitiv nicht Unicodetauglich ... man kann da zwar beim Read/ReadLn/Write/WriteLn einen WideString verwenden, aber dieser wird intern in einen AnsiString umgewandelt ... also aus/in eine(r) Datei wird da immer nur als AnsiString gelesen/geschrieben.

Mit DelphiBoardmitteln kann man das nicht umgehen ... also entweder 'nen Stream, per File / File of irgendwas, oder per WinAPI das direkt in 'nen WideString einlesen. (allerdings muß man da natülich selber das String/Zeilenende suchen)

[merlin17]

hier ist auch etwas interessantes zum Thema unicode und "unsere" VCL:
DThorpe: UniCode und VCL

:-) thomas

[Olli]

Zum verlinkten Blog-Eintrag:
Tja, was soll man dazu sagen. Wiedermal ist die (Rückwärts-)Kompatibilität die Begründung etwas zu vermeiden ...

Dieses Problem hätte lange gelöst sein können, wenn man global Präprozessor-Defines in den Projektoptionen mitgeben könnte. Damit könnte man Unicode- und Ansi-VCL sauber getrennt halten und würde dennoch all jene zufriedenstellen, die berechtigtes Interesse an einer Unicode-Version haben. Offensichtlich ist Borland selbst nicht international genug um die Dimension dieser Fehlentscheidung zu erkennen.
Delphi 2, das erste 32-Bit-Delphi überhaupt, wurde im Jahr 1996 veröffentlicht. Zu diesem Zeitpunkt gab es schon 4 (? - bin nicht sicher) Jahre lang NT 3.51 welches ebenfalls unicode-fähig war und in ebenjenem Jahr 1996 kam Windows NT 4.0 heraus. Es gibt also keine Entschuldigung, daß in Delphi 2006 - 10 Jahre danach - noch immer kein Unicode-Support enthalten ist. Und Hand auf's Herz: es gab zwischenzeitlich auch andere Änderungen, die die Kompatibilität bedroht haben ... auf der anderen Seite sind garnicht alle Komponenten empfindlich für eine Änderung der VCL von Ansi nach Unicode. Es gibt schließlich Komponenten die ganz simpel auf keine der Funktionen zugreifen, welche in Ansi- und Unicode-Variante existieren.

Alles etwas seltsam und - wenn man sich die Jahreszahlen anschaut - leicht unbegreiflich, wieso Unicode nicht von Anfang an voll unterstützt wurde.

[himitsu]

Was mit beim Thema Unicode noch stört, ist daß intern WideStrings auf OLE-Strings auf umgebogen werden.
Warum kann Borland da nicht auch, wie bei den AnsiStrings, das "eigene" Format benutzen (keine OLE32.dll mehr nötig und, neben anderen Vorteilen, vorallem endlich mit Referenzzählung..)

[merlin17]

Zitat:

Tja, was soll man dazu sagen. Wiedermal ist die (Rückwärts-)Kompatibilität die Begründung etwas zu vermeiden ...

und wir bei Nevrona kriegen damit auch noch "Prügel", weil unsere Win32-ReportEngine, basierend auf VCL, nicht Unicode-fähig
ist und wird (ich meine Win32, nicht .net, hier ist UniCode auch bei Rave enthalten!)


:-) thomas, TeamNevrona

[himitsu]

Ach, am Besten war ich vorrige Woche über die RessourceStrings gestolpert ... OK im Programm (Quellcode) kann man da zwar nur ANSI angeben, aber in den Resourcen ist der String ja als Unicode gespeichert ... also dachte ich ist ja geil, ein String der nur gespeichert wird, wenn er auch verwendet wird (anders, wenn man Resourcen per {$R...} reinläd, welche ja immer eingebunden werden, egal ob man das $R in eine nichtverwendete Procedur verschachtelt hat) und dazunoch die möglichkeit über einfach Technicken nachträglich andere Sprachen drüberzuladen (per DLL sogar abhängig von der in Windows verwendeten Sprache), aber nein, der wird dann auch noch als ANSI wieder ausgelesen und es gibt wohl keine Möglichkeit ihn selber per LoadStringW auszulesen :cry:

[clancy38]

Also, erstmal danke für alle antworten.

Das Problem ist jetzt soweit gelöst:
Die Excel-Tabelle wird nach Word exportiert, dort kann sie mit (im Gegensatz zu Excel)
als "Nur-Text" gespeichert werden bei gleichzeitiger Auswahl eines Zeichensatzes.

Mit dem Editor ist sie dann zwar nicht mehr lesbar, verändert man dann in Delphi aber bei Auswahl
von chinesischer Sprache den Wert für Charset, hat im Betriebssystem die Unterstützung für
ostasiatische Sprachen installiert, dann werden alle chinesischen Schriftzeichen so wie in der
Exceltabelle vollkommen korrekt angezeigt.

Das klappt u.a. genauso mit Russisch und Japanisch

@Jus
Hmm, wenn du einen Chef hast, der sogar notwendige Updates für Delphi komplett ablehnt und sog.
Fremdkomponenten als Werk des Teufels (hat er ja nicht selber geschrieben) bezeichnet, was willste da
machen?

Trotzdem nochmals Danke an alle, die mir Tips hier reingeschrieben haben.