Encoding mit Postgres 8.4.0

Hallo,

ich möchte meine Datenbanken von Postgresql 8.3.3 nach 8.4.0 migrieren.

Bisher war mein template1 auf SQL-ASCII eingestellt, meine Datenbanken aber in UTF8. In zahlreichen Feldern werden werden neben Umlauten auch Zeichen wie € genutzt, aber auch auch é etc…


Dazu meine beiden Fragen:

  1. welches Encoding ist für “Deutschland” optimal?? Latin9?? Wenn ja, wie muß ich das initdb ausführen, um das passende Template1 zu erhalten?
  2. wie dumpe ich die Daten so in die neue Datenbank, dass alle Umlaute und Sonderzeichen richtig rüber kommen??

Bisher habe ich zahlreichen Versuche gestartet:

  • Wenn ich unter 8.4 beim initdb keine weiteren Angaben mache, habe ich jetzt im template1 ENCODING = ‘LATIN1’ LC_COLLATE = ‘en_US.ISO8859-1’ LC_CTYPE = ‘en_US.ISO8859-1’. Hier kann ich Daten, die ein € enthalten, nicht importieren
  • Lege ich die neue Datenbank mit ENCODING = ‘SQL_ASCII’ LC_COLLATE = ‘de_DE’ LC_CTYPE = ‘de_DE’ an, kann ich zwar die Daten importieren, aber die Umlaute sind “kaputt”
  • Wenn ich beim initdb als locale=de_De angebe, kann ich nicht wie erwartet auf ENCODING=Latin9 gehen…

Danke im voraus.


mkuis

Also ISO-8859-1 kann erstmal gar kein Euro Zeichen. Ich vermute mal, dass das mit SQL-ASCII aehnlich ist, da im ASCII Satz an sich sowas garnicht vorgesehen ist.
Wie exportierst du deine Daten? pg_dump kennt naemlich --encoding, womit die Datenbank die Zeichen selber konvertiert.

wenn ich beim pg_sump das gewünschte Encoding wie z.B. -E Latin1 abgebe, dann kbricht der dump ab:

pg_dump: Error message from server: ERROR: character 0xc5b8 of encoding “UTF8” has no equivalent in “LATIN1”
pg_dump: The command was: SELECT description, classoid, objoid, objsubid FROM pg_catalog.pg_description ORDER BY classoid, objoid, objsubid

welches Encoding wäre den optimal??? Latin9???

Wenn Deine Datenbank bisher in UTF8 war und auch solche Daten enthält, was wäre dann wohl optimal?

Andreas

Wenn du schon UTF8 benutzt, warum willst du dann auf LatinX wechseln? Stellt ihr in eurer Apllikation etwa das Encoding um?

Zum einen haben wir exotischen Zeichen wie den „ (Anführungszeichen aus Word) schon mal Probleme, wenn diese später für eine Ausgabe mit php mit Client_encoding nicht gezeigt werden können.

Zum anderen fände ich es einfach gut, die Sortierung in Deutsch zu haben, also die Umlaute an der richtigen Stelle etc.

Ich habe mittlerweile rausgefunden, dass ich das richtige Template1 habe, wenn ich meine DB mit
initdb -D /date --locale=de_DE.ISO8859-15 --encoding=LATIN9
anlege.

Nun muß ich nur meine Daten aufräumen, damit ich diese einspielen kann…

Wenn du beim Dump per encoding gleich sagst, dass Latin9 benutzt werden soll, dann muesste das doch gehen. Ein paar Eintraege weiter oben hast du Latin1 benutzt, statt Latin9, vllt ging es deswegen nicht.

also fuer die darstellung im web wird das encoding ja im dokument eingestellt … also irgendwo musst du mittels php im html das encoding ausgeben was der browser verwenden soll … UTF-8 wäre eigentlich ideal

wenn du dann deine DB auch mit UTF8 betreibst und das client-encoding auch so wählst sollte es eigentlich keine “seltsamen” zeichen irgendwo geben … weil das zeuch was du aus der db liest ja genauso ins html-document geschrieben wird

die sortierung ist sache des dbms … und sollte dann auch den gängigen regeln entsprechen … zumindest ist mir gerade nicht bewusst wo bei UTF8 falsch sortiert wuerde ?!

ich wuerde das vorhaben nochmal ueberdenken