Wie löste ich UTF8 Ungültige Byte -Sequenz -Kopierfehler bei einer Wiederherstellung, wenn die Quelldatenbank in UTF8 codiert ist?

Question

Ich erhielt die Aufgabe, eine PostgreSQL 8.2.x -Datenbank auf einen anderen Server zu migrieren. Zu diesem Zweck verwende ich die PGADMIN 1.12.2 (auf Ubuntu 11.04 übrigens) und verwende das Sicherungsbackup und die Wiederherstellung mit dem Custom/Compress -Format (.backup) und der UTF8 -Codierung.

Die ursprüngliche Datenbank ist in UTF8 wie SO:

-- Database: favela

-- DROP DATABASE favela;

CREATE DATABASE favela
  WITH OWNER = favela
       ENCODING = 'UTF8'
       TABLESPACE = favela
       CONNECTION LIMIT = -1;

Ich erstelle diese Datenbank genau wie diese auf dem Zielserver. Wenn ich jedoch die Datenbank aus der .backup -Datei mit der Option Wiederherstellung wiederhere, gibt ich einige dieser Fehler:

pg_restore: restoring data for table "arena"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 2173; 0 35500 TABLE DATA arena favela
pg_restore: [archiver (db)] COPY failed: ERROR:  invalid byte sequence for encoding "UTF8": 0xe3a709
HINT:  This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
CONTEXT:  COPY arena, line 62

Wenn ich überprüfe, welcher Datensatz diesen Fehler ausgelöst hat, haben einige Vartext -Felder diakritische Zeichen wie ç (zum Beispiel in Portugiesisch verwendet, und wenn ich sie in den Aufzeichnungen manuell aus dem Text entferte, übergeht der Fehler zum nächsten Datensatz manuell Das hat sie - da die Kopie einen Fehler hat, wird das Einfügen von Daten in diese Tabelle nicht mehr eingesetzt. Und ich möchte sie nicht manuell ersetzen, um dies zu erreichen.

Aber es ist ein bisschen seltsam, denn mit UTF8 sollte es keine solchen Probleme geben, oder?

Ich weiß nicht, wie sie überhaupt dorthin gekommen sind. Ich migriere nur die Datenbank, und ich piniere, dass die Datenbank irgendwie wie in Latin1 war und dann nicht ordnungsgemäß in UTF8 geändert wurde.

Gibt es eine Möglichkeit, zu überprüfen, ob eine Tabelle/Datenbank ungültige UTF8 -Sequenzen enthält? Oder eine Möglichkeit, diese Charaktere in UFT8 durchzusetzen/umzuwandeln, damit ich keine Probleme habe, wenn ich die Wiederherstellung ausführe?

Danke im Voraus.

Answer 1

Ich habe im Internet gesehen und habe gesehen, dass dies ein ziemlich häufiges Problem ist. Die übliche Lösung besteht darin, den Dump der einfachen Textformat zu verwenden und durch ICONV zu füttern, um die Codierung zu korrigieren.

Hier ist mehr Informationen dazu.

Answer 2

"Ich weiß nicht, wie sie überhaupt dorthin gekommen sind"

Es hätte wie beschrieben passieren können hier - Obwohl dies einen Fehler bei 8.4 erzeugt:

Wenn Sie eine Tabelle mit einem Texttyp erstellen (dh Text, varchar (10) usw.), können Sie mit Octal Escapes eine ungültige Byte -Sequenz in dieses Feld einfügen.

Wenn Sie beispielsweise eine UTF8-kodierte Datenbank haben, können Sie dies tun:

=> Tabelle foo (t Text) erstellen;

=> In Foo -Werte einfügen (e ' 377');

Wenn Sie nun die Tabelle kopieren, können Sie die resultierende Datei nicht wieder kopieren. Das bedeutet, dass Ihre PG_Dump -Sicherungen nicht wiederherstellen können. Der einzige Weg, um Ihre Daten wieder einzubringen, besteht darin, diesen Wert wieder aufzutreten.

Es gibt einen guten Beitrag dazu Ausgezeichneter Blog über die allgemeinen Fragen und einige Möglichkeiten, um mit ihnen umzugehen

Answer 3

Es ist wahrscheinlich mit der Standardcodierung, die in Ihrer Unix/Linux -Umgebung verwendet wird. Um zu überprüfen, welche Codierung derzeit standardmäßig ist, führen Sie Folgendes aus:

$ echo $LANG
en_US

In diesem Fall können wir deutlich sehen, dass es sich nicht um eine UTF-8-Codierung handelt, auf die der Kopierbefehl angewiesen ist.

Um dies zu beheben, setzen wir die Lang -Variable in Beispiel auf Folgendes:

$ export LANG=en_US.UTF-8

Hinweis: Dies ist nur für die aktuelle Sitzung verfügbar. Fügen Sie es zu ~/.bashrc hinzu oder können Sie es beim Start einer zukünftigen Shell -Sitzung verfügbar haben.

Bezug

Answer 4

Ich empfehle nicht blind laufende Iconv auf dem einfachen Text -Dump, da es gültige Zeichen (z. B. chinesische Zeichen) in andere Zeichen umwandeln kann. Es ist besser, das ungültige UTF8 -Zeichen zu finden, indem Sie den Befehl unter unten ausgeführt.

grep -naxv '.*' plain_text_dump.sql

und dann Iconv für die jeweiligen Daten ausführen. Prüfen Dieser Dokument für detaillierte Schritt -für -Schritt -Erläuterung.