MsSQL Kyrillisch in NVarChar

[Bernhard Geyer]

Zitat von Perlsau:

Doch zurück zu UTF-16: Gehe ich richtig in der Annahme, daß ich die Stringliste mit dem Parameter Unicode laden muß?
Liste.LoadFromFile(Datei, TEncoding.Unicode); statt wie bisher mit
Liste.LoadFromFile(Datei, TEncoding.UTF8); Das wäre ja einfach

Man sollte eigentlich nix brauchen wenn die Datei einen BOM hat.
Dann sollte es klar sein wie die Datei Codiert ist.

[Perlsau]

Zitat von Bernhard Geyer:

Man sollte eigentlich nix brauchen wenn die Datei einen BOM hat. Dann sollte es klar sein wie die Datei Codiert ist.

Offenbar verfügen die Dateien nicht über eine entsprechende Kennung. Wenn ich es so mache, wie du mir empfohlen hast, werden im DB-Manager wieder nur Fragezeichen statt kyrillischer Zeichen dargestellt. Offensichtlich sind das keine UTF-16-Dateien. Keine Ahnung, wie ich UTF-16-SQL-Scripte mit Delphi erzeugen kann.

Mache ich das mit UTF8 und vorangestelltem N, werden die Zeichen im DB-Manager richtig dargestellt, jedoch nicht im DBGrid, da stehen wiederum nur Fragezeichen. Bin mal gespannt, wie das mit chinesichen Zeichen wäre, aber für China ist derzeit keine Datei verfügbar, und die japanische Datei enthält keine japanischen Zeichen.

In Firebird dagegen konnte ich alle UTF-8-kodierten SQL-Dateien problemlos einlesen, sie werden dort auch alle richtig dargestellt. Jetzt werd ich mal schnell eine Testanwendung schreiben, um zu sehen, ob ich wenigstens die Firebird-Daten korrekt darstellen kann.

Vielleicht sollte ich noch einmal versuchen, den Feldtypen in MsSQL wieder auf Varchar umzustellen und danach noch einmal einlesen. Aber ich glaube nicht, daß das funktioniert, das hatte ich ja am Anfang und danach hab ich die die entsprechenden Felder erstmal alle auf NVarchar gestellt.

Das Projekt muß nicht unbedingt auf MsSQL basieren. Firebird hätte zudem den Vorteil, daß man eine Embedded-Variante erstellen könnte. Die Firebird-DB ist nach dem Einlesen aller PLZ-Daten im unnormalisierten Zustand ca. 200 MB groß, das ist vertretbar, finde ich. Mein derzeitiger Kunde/Auftraggeber/Scheffe zog MsSQL vor, weil seine eigenen Projekte hauptsächlich darauf basieren und einer seiner Großkunden, dessen Kunden teilweise in "Ostblock-Ländern" sitzen, eben auch MsSQL einsetzt. Man kann aber auch problemlos zwei Datenbanken in einer Anwendung ansprechen, wenn ich mich nicht sehr irre. Am Ende sollte das Projekt eigentlich in verschiedenen Versionen bereitstehen. Mal sehen, vielleicht investiert mein Kunde ja auch was in entsprechende Komponenten, die eine korrekte Darstellung kyrillischer Zeichen gewährleisten. Ich mach ja erst mal nur die Recherche-Arbeit und das Ausprobieren und krieg dafür erstmal auch nichts (außer der Möglichkeit, mit besserer Hard- und Software arbeiten zu können) ... Wenn das befriedigend läuft, wird man weitersehen ...