Encoding-Problem

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Antworten
Benutzeravatar
cofi
Python-Forum Veteran
Beiträge: 4432
Registriert: Sonntag 30. März 2008, 04:16
Wohnort: RGFybXN0YWR0

Die Daten sind in der Datenbank als Latin-1, werden aber direkt zu unicode Objekten umgewandelt.
Template-Lookup ueber:

Code: Alles auswählen

lookup = TemplateLookup(directories=[template_dir],
                        output_encoding='latin_1',
                        input_encoding='utf-8')
Die Templates sind UTF-8 kodiert.

Das Problem:
Mit obigem Lookup - die Templates bekommen nur die Daten keine Einstellungen - generiert Mako mit ``template.render`` UTF-8 fuer die Daten aus der DB, aber (richtigerweise) Latin-1 fuer die Daten/Strings im Template.

Stell ich ``output_encoding`` auf ``utf-8``, so stimmt wieder das Encoding fuer die Templatedaten, aber die DB-Daten machen einen Ausreisser, das Encoding ist da weder Latin-1, noch UTF-8 oder UTF-16 (ASCII schon gar nicht).

Kennt das Verhalten jemand oder kann mir jemand erklaeren, was Mako da macht?

Edit (Leonidas): Verschoben.
Zuletzt geändert von cofi am Mittwoch 22. Juli 2009, 08:05, insgesamt 1-mal geändert.
Benutzeravatar
cofi
Python-Forum Veteran
Beiträge: 4432
Registriert: Sonntag 30. März 2008, 04:16
Wohnort: RGFybXN0YWR0

Bei Jinja2 zeigt sich das gleiche Spiel.

Der Vollstaendigkeit halber nochmal Loader und das Schreiben:

Code: Alles auswählen

loader = jinja2.FileSystemLoader(template_dir)

Code: Alles auswählen

with open(fname, 'w') as fobj:
    fobj.write(template.render(attrs).encode('latin1'))
Die Templates sind immernoch UTF-8. Und die Ausgabe laesst mit UTF-8 lesen, auch wenn das Latin1 kodiert sein sollte...

Die Datenbank dahinter ist uebrigens MySQL, die Bindings MySQLdb-1.2.2 Latin1 kodiert, aber wie gesagt: Liegt in Unicode-Objekten vor.
frabron
User
Beiträge: 306
Registriert: Dienstag 31. März 2009, 14:36

Einen wirklichen Tipp habe ich nicht, ich kann nur ein bisschen stochern ...

Wie kommen denn die Daten in die DB, bzw. was steht denn direkt als Daten in der DB? Hast du mal einen Select direkt in der DB gemacht? Vielleicht werden sie ja schon "falsch" in die Datenbank geschrieben ...

Wie greifst du auf die Daten aus der DB zu? Mittels SqlAlchemy? Da musste ich für meine Daten aus einer Postgresql Datenbank in der Konfiguration noch

Code: Alles auswählen

    engine = engine_from_config(config, 'sqlalchemy.', convert_unicode=True)
machen, um durchgängig UTF-8 kodierte Daten zu haben. D.h. trotz UTF Datenbank und entsprechend gespeicherten Daten musste ich Sqlalchemy noch sagen, dass da UTF-8 Daten kommen. Vllt. hat ja dein DB-Layer etwas ähnliches ...
Benutzeravatar
cofi
Python-Forum Veteran
Beiträge: 4432
Registriert: Sonntag 30. März 2008, 04:16
Wohnort: RGFybXN0YWR0

Danke frabron, die meisten Angaben habe ich schon oben gemacht, aber nicht wie die Daten aus der DB kommen. Das ist ein simpler ``SELECT *``.

Die Kodierung der Datenbank stimmte nicht: UTF-8, statt Latin-1. Das hat man davon wenn man eine Datenbank aufsetzt, ohne sich mit den Tiefen der Config auseinanderzusetzen. ;)

-> Das Problem war ich ;)
frabron
User
Beiträge: 306
Registriert: Dienstag 31. März 2009, 14:36

Kein Problem :)

Wenn ich ein Problem mit Encodings habe, dann untersuche ich immer die Kette, die der Text nimmt von der Quelle hin bis zur Verarbeitung / Ausgabe. Irgendwo auf diesem Weg läufts dann meistens schief.

Mit
Hast du mal einen Select direkt in der DB gemacht
meinte ich, dass du mal Mysql anschmeisst und direkt in der Db den Kram abfragst. Es soll ja auch vorkommen, dass da drin irgendwelcher Quark steht, zumal wenn man die Daten von Dritten bezieht.

Und ich hatte noch kurz gezögert, als ich Latin1 als Encoding für Mysql gelesen hatte, denn ich dachte, seit v5 ist UTF auch Standard. Aber manchmal muss man ja auch mit ollen Kamellen arbeiten, und deshalb hab ich nix dazu gesagt. Aber es hat sich ja zum Glück geklärt ...
Antworten