Kodierung SQL_ASCII <> UTF8

Moin!

Ich weiß, dass es zu diesem Thema bereits einige Threads in diesem Forum gibt, aber wirklich fündig geworden bin ich bzgl. meines Problems noch nicht. Ein wirkliches Problem ist es auch nicht (da ich mir die Konstellation lediglich ausgedacht habe), dennoch interessiert mich, ob eine Lösung existiert.

Ich habe eine Datenbank “alt” mit der Kodierung SQL_ASCII. Diese sichere ich mit dem folgenden Befehl:

pg_dump -E UTF8 alt > alt.sql

Nun erstelle ich eine Datenbank “neu”:

createdb -T template0 -E UTF8 neu

Und anschließend versuche ich, mit dem folgenden Kommando, den Inhalt der alten Datenbank zurückzusichern:

psql -f alt.sql neu

Dabei kommt es zu folgenden Fehlermeldungen:

psql:alt.sql:1470: ERROR:  invalid UTF-8 byte sequence detected near byte 0xdf
CONTEXT:  COPY firma, line 1, column strasse: "Blablastra_e" psql:alt.sql:1481: ERROR:  invalid UTF-8 byte sequence detected near byte 0xdf
CONTEXT:  COPY personen, line 3, column strasse: "Teststra_e"
psql:alt.sql:1510: ERROR:  invalid UTF-8 byte sequence detected near byte 0xfc
CONTEXT:  COPY plz, line 3, column ort: "Utopiab|ttel"

Ganz offensichtlich liegen die gesicherten Daten nicht in der korrekten Kodierung vor. Aber: Wie dumpe ich die Datenbank, so dass ich alles ohne Probleme in eine zweite Datenbank mit anderer Kodierung schreiben kann?

Es eilt nicht, denn wie gesagt: es handelt sich nicht um eine produktive Datenbank, sondern lediglich um ein Test-Szenario, das mich interessierte. Trotzdem wäre ich für Lösungs-Vorschläge dankbar… Wer weiß, was noch alles auf einen zukommt! :wink:

Schönen Gruß, eazy

Hallo eazy,

“pg_dump -E …” bestimmt die Client-Encoding

-E encoding
–encoding=encoding

Create the dump in the specified character set encoding. By default, the dump is created in the database encoding. (> Another way to get the same result is to set the PGCLIENTENCODING environment variable to the desired dump encoding.> )

Das kann also so nicht funktionieren. Maßgeben ist die ENCODING der Datenbank.

Suche mal im Dump-File an nach angebenen ENCODING. Sollte man manuel ändern können.



mfg

fristo

Kann jetzt leider nicht nachschauen (bin erst morgen wieder auf der Arbeit :wink: ), bin aber der Meinung, dass dort tatsächlich als Kodierung UTF8 gesetzt wird. Habe allerdings sowohl UTF8, SQL_ASCII als auch ohne Parameter einen Dump durchgeführt mit dem “Erfolg”, dass alle drei Versuche die gleichen Fehler hervorriefen!

Morgen früh gibt’s genauere Informationen…

Gruß, eazy

Guten Morgen!

Ich habe jetzt mal im Dump-File geschaut und da steht lediglich:

SET client_encoding = 'UTF8';

Was genau bewirkt dann der Parameter -E mit Setzen der entsprechenden Kodierung? Für Die Daten im Dump spielt es offensichtlich überhaupt keine Rolle. Ich bin auch der Meinung, mal was darüber gelesen zu haben, dass ein Konvertieren von SQL_ASCII nach UTF8 nicht möglich sei, aber ich finde es nicht mehr in der Dokumentation.

Also: Hat noch jemand irgendwelche anderen Vorschläge? :wink:

Gruß, eazy

Hallo eazy,

arbeitet Dein Betriebssytem auch mit UTF8?


mfg

fristo

Mahlzeit!

Gute Frage, höchstwahrscheinlich nicht (Win 2000 Server) … Das ist natürlich ein guter Einwand! :wink: Ich werde das Montag mal verifizieren…

Gruß, eazy

Hallo eazy,

[quote=“eazy”]Mahlzeit!

Gute Frage, höchstwahrscheinlich nicht (Win 2000 Server) … Das ist natürlich ein guter Einwand! ]
kannst Du gerne machen, ist nicht UTF8. Die Clientencoding beschreibt den Zeichensatz des Betriebssystems. Windows hat seinen eigenen, und da die Befehle unter DOS ausgeführt werden, ist der DOS-Zeichensatz gültig. Bei Angabe des richtigen Zeichensatzen (Clientencoding) sollte trotzdem der Transfer von Daten von einer ASCII-Datenbank in eine UTF8-Datenbank in dieser Weise funktionieren, da die ersten 128 Zeichen in UTF8 den ASCII-Code entsprechen.



mfg

fristo

Dann kann ich ja vorab hier auch schon mal fragen, wie ich den korrekten Zeichensatz rausfinde. Ist das unter Windows dann ISO-sonstwas-blabla? Ich merke schon, dass ich mich da am Montag zunächst mal schlau lesen muß.

Danke schon mal für die Hinweise…

Gruß und schönen Sonntag, eazy!

Wird wohl nicht nur PostgreSQL, sondern auch Windows betreffen.

Unter Windows / DOS nennt sich das Codepage. Eine gute Backgrounseite kannst findest Du hier: Zeichensatztabelle – Wikipedia . Da ich mit Win2000 nicht arbeite, kann ich Dir auch nicht sagen, welche Codepage auf dem Betriebsystem eingestellt ist. Ich weiß auch im Augenblick selbst nicht, wo man das im Betriebssystem einstellen kann. Die richtigen Schlagwörter in einer Internet-Suchmaschine werden Dir da wohl auch weiterhelfen.



mfg

fristo

Morgen!

Die von dir genannte Seite hat tatsächlich weitergeholfen. Danke, fristo.

Die Codepage, mit der Windows arbeitet, ist äquivalent zu dem von PostgreSQL angebotenen Character Set “LATIN1” bzw. “LATIN9”. Latin-1 ist identisch mit den ersten 256 Zeichen des Unicode-Zeichensatzes, der neuere Latin-9-Zeichensatz unterscheidet sich dahingehend von Latin-1, dass u.a. das Euro-Zeichen unterstützt wird.

PostgreSQL unterstützt folgende automatische Konvertierung zwischen Character Sets:

Server --> Client
LATIN1 --> UTF8
LATIN9 --> UTF8
UTF8 --> alle unterstützten Codepages
SQL_ASCII --> alle (wobei keine Konvertierung durchgeführt wird)

Wird für den Client das Character Set “SQL_ASCII” eingestellt, wird außerdem keine Konvertierung durchgeführt. Eine Datenbank mit dem server-seitigen Character Set “SQL_ASCII” macht also wirklich ausschließlich Sinn, wenn nur Zeichen aus dem ASCII-Zeichensatz verwendet werden, was aber schon bei vielen deutschen Namen (z.B. Müller) nicht mehr der Fall ist.

Mein spezielles Problem war nun mit den folgenden Befehlen zu lösen:

pg_dump -E LATIN9 alt > alt.sql
createdb -T template0 -E LATIN9 neu
psql -f alt.sql neu

Prinzipiell müßte es jedoch möglich sein, die Datenbank (auch unter Windows) mit dem Zeichensatz “UTF8” laufen zu lassen, da dann eine automatische Konvertierung erfolgt.

So, das war’s erstmal von meiner Seite. Ich wende mich mal wieder meinen “echten” Problemen zu… :wink:

Gruß, eazy

Hallo eazy,

aus Deinen Überlegungen kann man nur schließen, dass Du die Doku noch nicht vollständig gelesen hast, ansonsten sollten CLIENT_ENCODING und SERVER_ENCODING für dich ein Begriff sein.




mfg

fristo

Hallo fristo,

Server → Client
LATIN1 → UTF8
LATIN9 → UTF8
UTF8 → alle unterstützten Codepages
SQL_ASCII → alle (wobei keine Konvertierung durchgeführt wird)

Damit wollte ich eigentlich verdeutlichen, dass Server und Client nicht zwangsweise mit der gleichen Kodierung arbeiten müssen, jedoch eine Konvertierungsmöglichkeit nicht immer gewährleistet ist. Oder worauf wolltest du hinaus?

Gruß, eazy

Hallo eazy,

so wie Du das in den Betrag beschreibst hast Du natürlich recht. Ich hatte da etwas weiter gedacht. So kannst Du durchaus mit einer CLIENT_ENCODING z. B. UTF-8 arbeiten obwohl der Zeichensatz und damit die eigentliche CLIENT_ENCODING des Betriebssystems nicht UTF-8 nicht entspricht. Bestes Beispiel hierfür ist PGAdmin unter Windows. Windows arbeitet mit dem Zeichensatz Latin1. Die Kommunikation zwischen PGAdmin (Client) und dem Server erfolgt aber immer mit der CLIENT_ENCODING UTF-8.



mfg

fristo

Hallo,
ich habe den Artikel aufmerksam gelesen. Ich verwende ab PostgreSQL 7… alle nachfolgenden Versionen (derzeitig 8.1). Da die Daten schon lange mit unterschiedlichen Anwendungen eingepflegt wurden, gibt es Probleme. :angry:
Die Datenbank ist als SQL-ASCII angelegt worden Die Daten wurden in die Tabellen in UNICODE eingearbeitet. Im Laufe der Zeit befinden sich, wer weiss warum, in einer Tabelle Inhalte in UTF-8 und SQL-ASCII. :confused: Mit pg_dump und anschließenden recode kann ich die SQL-ASCI-Zeichen nicht in UNICODE wandeln bzw. die UNICODE-Zeichen führen zu Fehlern. :frowning: Ich brauche aber unbeding das gesamte DMS in Unicode (auch jede einzelne Datenbank und jede Tabelle) homogen.
Aus dem Artike habe ich entnommen, dass Du mit Ähnlichem kämpfst. :p Hast Du mittlerweile eine Lösung, oder kannst Du helfen?

Hall carsomm,

Eine Datenbank, deren interner Zeichensatz (SERVER-ENCODING) SQL-ASCII ist, kann nur ASCII-Zeichen enthalten. Mehr wie 7-bits sind da nicht möglich. Folglich können auch keine UTF8-Zeichen in der Datenbank vorhanden sein.

Wenn die Daten im UTF8-Zeichesatz gespeichert werden sollen, muss Du einen neue Datenbank erzeugen, dessen SERVER-ENCODING UTF8 ist. Anschließend sind die Tabellendefinitionen, etc sowie die Daten aus der alten Datenbank zu exportieren und in die neue Datenbank zu importieren.



mfg

fristo

Erst mal Danke für deine Antwort. Ich habe mir viel Zeit gelassen, aber unangenehme Jobs landen, wenn möglich meist ganz unten.
Die Daten in der DB sind natürlich SQL-ASCII, aber irgendwann wurden mal Sätze insert od. auch update mit BEGINN //encodung UNICODE oder so ähnlich. Ich habes in alten Scripten gefunden. Nun diese Sätze sin problematisch ä,ü …

Ich habe mir geholfen und entsprechend gesucht, aber es ist zu unzuverlässig?

na evtl fällt dir was ein?

Hall carsomm,

wenn Du ein pg-dump erstellst, erhälst Du auch die vollständigen Datensätze, die im UTF8 erstellt worden sind (Zeichen ä,ö,ü) ?

Die von pg-dump erstellte Datei ist eine Textdatei, so das Du mit einem Editor hineinschauen kannst. Suche dort mal nach “SQL-ASCII” und/oder “ENCODING”. Vielleicht steht dort eine falsche ENCODING für den Import der Daten in eine Datenbank, die die SERVER-ENCODING UTF8 hat.



mfg

fristo