Ergebnis 1 bis 8 von 8

Thema: Encoding mit Postgres 8.4.0

  1. #1
    mkuis ist offline Benutzer
    Registriert seit
    20.08.2009
    Ort
    Bonn
    Beiträge
    50

    Unglücklich 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

  2. #2
    Gibheer ist offline Benutzer
    Registriert seit
    23.06.2008
    Beiträge
    51

    Standard

    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.

  3. #3
    mkuis ist offline Benutzer
    Registriert seit
    20.08.2009
    Ort
    Bonn
    Beiträge
    50

    Standard

    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???

  4. #4
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.468

    Standard

    Zitat Zitat von mkuis Beitrag anzeigen
    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
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  5. #5
    Gibheer ist offline Benutzer
    Registriert seit
    23.06.2008
    Beiträge
    51

    Standard

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

  6. #6
    mkuis ist offline Benutzer
    Registriert seit
    20.08.2009
    Ort
    Bonn
    Beiträge
    50

    Blinzeln

    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...

  7. #7
    Gibheer ist offline Benutzer
    Registriert seit
    23.06.2008
    Beiträge
    51

    Standard

    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.

  8. #8
    symbiont ist offline Erfahrener Benutzer
    Registriert seit
    17.03.2008
    Ort
    NULL
    Beiträge
    1.320

    Standard

    Zitat Zitat von mkuis Beitrag anzeigen
    Zum einen haben wir exotischen Zeichen wie den

    Nun muß ich nur meine Daten aufräumen, damit ich diese einspielen kann...
    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

Ähnliche Themen

  1. postgresql 8.4.5 encoding
    Von angua im Forum Konfiguration
    Antworten: 1
    Letzter Beitrag: 04.02.2011, 11:52
  2. Npgsql 2.0.9 Encoding
    Von SIJ im Forum externe Schnittstellen
    Antworten: 7
    Letzter Beitrag: 11.06.2010, 19:15
  3. Problem shp2pgsql / pgsql encoding
    Von MisterX im Forum Konfiguration
    Antworten: 1
    Letzter Beitrag: 27.11.2009, 14:19
  4. psql Konsole & Encoding
    Von Nuadu im Forum Sonstige
    Antworten: 3
    Letzter Beitrag: 02.09.2009, 08:32
  5. Encoding bei Insert befehle
    Von hretif im Forum SQL
    Antworten: 6
    Letzter Beitrag: 29.08.2008, 12:43

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Links: Tobias Bauer - IT- und Funkdienstleistungen   -   Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen   -   Funkforum