codierungsproblem utf8

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
Aprilia
User
Beiträge: 50
Registriert: Dienstag 15. April 2008, 12:09
Wohnort: Görlitz (östlichste stadt Dtl's)

Freitag 27. Juni 2008, 08:08

Guten Morgen,

und zwar habe ich folgendes Problem:
ich nutze xmlrpclib, wenn ich vom client eine frage an den server stelle, bekomme ich eine liste die unicode codiert ist.

doch konfiguriert ist am client und am server uft8

im server ist die liste noch utf8.
und am client ist sie dann unicode codiert...

--> WARUM ?

hoffe es kann mir jemand helfen
danke schonmal
Pekh
User
Beiträge: 482
Registriert: Donnerstag 22. Mai 2008, 09:09

Freitag 27. Juni 2008, 08:18

Vermutlich, weil sich das Modul an die empfohlene Arbeitsweise hält und Eingaben decodiert. Du solltest dich dem anschließen und intern mit Unicode weiterarbeiten und erst die wirklichen Ausgaben in die Zielcodierung bringen. Erleichtert dann auch eine eventuelle Verteilung auf andere Systeme, die vielleicht nicht mit UTF-8 arbeiten.
audax
User
Beiträge: 830
Registriert: Mittwoch 19. Dezember 2007, 10:38

Freitag 27. Juni 2008, 08:24

weil die liebe xmlrpclib das unicode-Umwandeln für die übernimmt.
Deshalb gibt man das Encoding an :]
Aprilia
User
Beiträge: 50
Registriert: Dienstag 15. April 2008, 12:09
Wohnort: Görlitz (östlichste stadt Dtl's)

Freitag 27. Juni 2008, 09:01

ok danke ...

ich werde jetzt bei allen ausgaben .encode('utf-8') dahinterschreiben...
das müsste funktionieren

@Pekh: eine umrüstung wäre im meinem fall zu umständlich und würde zu viel zeit in anspruch nehmen...trotzdem danke
Software & Knowledge Engineering
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Freitag 27. Juni 2008, 09:31

Aprilia hat geschrieben:ich werde jetzt bei allen ausgaben .encode('utf-8') dahinterschreiben...
das müsste funktionieren
Uhm, das ist ja mal eine schlechte Idee. Du machst es genau andersrum als wie es sinnvoll wäre (Hint: in Python 3.0 wird sowas noch schlechter möglich sein - zu Recht).
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Aprilia
User
Beiträge: 50
Registriert: Dienstag 15. April 2008, 12:09
Wohnort: Görlitz (östlichste stadt Dtl's)

Freitag 27. Juni 2008, 10:12

wie ist es sinnvoller???
ich kann das nicht auf unic. umstellen ...
das ist mein problem
Software & Knowledge Engineering
Pekh
User
Beiträge: 482
Registriert: Donnerstag 22. Mai 2008, 09:09

Freitag 27. Juni 2008, 10:16

Ist das wirklich ein so großer Aufwand. vor allem im Vergleich zu der Lösung die du oben angegeben hast? Du mußt lediglich an allen Stellen, wo du Daten aus externen Quellen übernimmst, sicherstellen, daß diese entweder schon als unicode vorliegen oder sie explizit decodieren. Und natürlich die Ausgaben codieren. Für die internen Abläufe in deinem Programm sollte sich eigentlich nichts ändern.

Edit: Doch ja, du solltest allen Strings, die in deinem Programmcode herumgeistern ein `u` voranstellen.
Aprilia
User
Beiträge: 50
Registriert: Dienstag 15. April 2008, 12:09
Wohnort: Görlitz (östlichste stadt Dtl's)

Freitag 27. Juni 2008, 10:32

nagut, ich werde es mal probieren ...

..thx..
Software & Knowledge Engineering
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Freitag 27. Juni 2008, 11:07

Pekh hat geschrieben:Edit: Doch ja, du solltest allen Strings, die in deinem Programmcode herumgeistern ein `u` voranstellen.
Ab 2.6 wird es da auch einen __future__-Import geben.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Antworten