2016-08-09 63 views
2

Ich habe eine sehr große Sicherung (.BAK) einer in Laos verwendeten Datenbank erhalten, die ich auf einem SQL Server 2014 Express (lokalen) Server wiederhergestellt habe . Es ist eine Datenbank mit vielen Spalten, die Lao-Text enthalten. Wenn die Benutzer, die die Datenbank verwenden, über die Client-Anwendung (eine Art thailändisches Buchhaltungsprogramm) darauf zugreifen, können alle Lao-Daten korrekt angezeigt werden, wenn sie ihre angezeigte Schriftart auf Saysettha setzen, eine Unicode-Schriftart mit Lao-Zeichen.Exportieren von Daten aus SQL Server 2014 in Lao Sprache [Kodierung/Sortierung]

Ich versuche jedoch, die Daten in den Tabellen (durch eine einfache Text- oder CSV-Datei, da der Exportprozess einfach und wiederholbar sein muss) aus SSMS zu exportieren, und die Daten werden nie richtig angezeigt. Nicht einmal wenn ich eine Tabellenabfrage in SSMS mache.

Ich weiß, das ist wahrscheinlich ein Problem mit der Codierung/Sortierung. Die Spalten sind in VARCHAR Spalten gespeichert. Ich habe versucht, sie in NVARCHAR Spalten zu werfen, die das Problem nicht löst. Ich habe auch versucht, die Spalte der Lao-Kollatierung zuzuordnen (die Server-Kollatierung ist nach der Wiederherstellung der Sicherung auf Thai_CI_AS gesetzt);

SSMS trial

ich versuchte, die Ausgabetabelle als CSV und TXT-Datei mit anderer Kodierung zu speichern, aber wenn ich öffne sie in z.B. Notepad ++ Ich sehe die gleichen falschen Zeichen.

Leider habe ich kein Beispiel dafür, wie der Text aussehen sollte, da die Client-Software nicht auf meinem Laptop läuft.

Idealerweise könnte ich die Spalten in UTF-8-Codierung exportieren.

Antwort

0

Mein Verständnis ist, dass Lao Text im Allgemeinen in UTF-8-Codierung, UTF-16-Codierung oder Code page 1133 Codierung gespeichert ist.

Wenn die Anzeigeanwendung die gleiche Kodierung verwendet, die beim Speichern der Daten verwendet wurde, sieht sie OK aus. Leider manchmal die Anzeige Anwendung nicht genau gesagt, welche Kodierung verwendet wurde, so dass es "hilfreich" versucht, guess, und manchmal ist es falsch raten. Normalerweise sind falsche Vermutungen für einen Menschen offensichtlich, der auf das Display schaut - die Buchstaben sind nicht einmal aus der richtigen Sprache.

Noch schlimmer, wenn Sie einer Anwendung mitteilen, Daten aus einer Datenbank zu exportieren, anstatt einfach die unverarbeiteten Textbytes zu exportieren, kann die Anwendung die Daten "hilfreich" in eine andere Kodierung konvertieren. Wenn die Anwendung die tatsächliche Codierung der Daten in der Datenbank kennt, funktioniert die Konvertierung in UTF-16 oder UTF-8 beim Export sehr gut. Andernfalls sind die exportierten Daten im Allgemeinen fehlerhaft und unbrauchbar.

Manchmal sind die am schwierigsten zu lösenden Probleme diejenigen, bei denen das System tatsächlich korrekt funktioniert, aber ich (fälschlicherweise) denke, dass es ein Problem gibt. Manchmal geschieht dies aufgrund eines Fehlers in den Tools, mit denen ich das Problem anschaue. Wenn Sie meist Lao Zeichen in Notepad ++ sehen, oder Sie können die Codierung in Notepad ++ ändern, bis Sie meist Lao Zeichen sehen, dann vermute ich die Daten in Ihrem Text oder CSV-Datei und die Codierung, die Notepad ++ guessed oder die Sie wahrscheinlich mit Encoding -> Encode festgelegt richtig.

Gibt es eine Möglichkeit für Sie zu sehen, ob die Daten tatsächlich von der Datenbank korrekt gespeichert, verarbeitet, exportiert, etc. und korrekt von der Client-Anwendung angezeigt werden, aber ein Rendering-Fehler in Notepad oder SSMS ist fälschlicherweise einige Akzentmarkierungen?

+1

Das war die Hilfe, die ich brauchte. Ich konnte die Daten über den Massenexport exportieren, wo ich das Zeichenformat ("-c") verwendete und explizit die Microsoft-Codepage [874] (https://en.wikipedia.org/wiki/ISO/IEC_8859) erwähnte -11) (durch Hinzufügen von "-C 874"), die Codepage 1133 enthält. Obwohl in ASCII, kann ich die exportierte CSV/TXT-Datei lesen. Ein Export nach UTF-8 wird jetzt gemacht. – robberth