Das deutsche Python-Forum

Hallo,

ich habe eine kleine WSGI-Anwendung deren Quelltext in UTF-8 kodierten Dateien steht. Als Content-Type schicke ich "text/html; charset=UTF-8" zum Browser, der das Ergebnis daraufhin auch als UTF-8 darzustellen versucht. Allerdings werden Umlaute dann als Zeichensalat dargestellt, obwohl der Ausgabetext direkt in der UTF-8 kodierten Python-Datei steht. Wenn ich im Browser oder im Programm dagegen ISO-8859-1 einstelle, wird alles korrekt angezeigt.

Wieso werden die Umlaute bei durchgängiger Verwendung von UTF-8 nicht korrekt dargestellt?

@deamon: Wie sehen die Header aus, die der Webserver an den Browser schickt?

Werden die Umlaute richtig dargestellt, wenn Du die empfangene Webseite lokal speicherst und diese Datei dann im Browser aufrufst?

Der Header sieht so aus: Wenn ich die empfangene Seite speichere und die Datei im Browser aufrufe, bekomme ich die gleiche, falsche Darstellung.

@deamon: Und stimmen die Bytewerte für die Umlaute in den empfangenen denn? Anscheinend ja nicht!? Wie sehen die denn vor dem Senden aus? Du musst halt herausfinden an welcher Stelle sie anfangen falsch zu sein.

Mittlerweile habe ich herausgefunden, dass WSGI noch gar nicht so richtig bei Python 3 angekommen ist und deshalb auch nicht mit UTF-8-Zeichen, die direkt innerhalb des Quelltextes eine Ausgabe definieren, umgehen kann. Wenn man ausgabe.encode("utf-8") anhängt, funktioniert es aber. Aber in einem etwas realistischeren Szenario als meinem kleinen Test dürfte der Text eh in Templates stehen ...

Hallo,

bei mitsuhiko gibt es zu dem Thema einen recht umfangreichen Blog-Eintrag: http://lucumr.pocoo.org/2010/5/25/wsgi-on-python-3

Gruß, noisefloor

Genau dafür sind eigentlich WSGI Frameworks da: Die WSGI Hürden so weit es geht ausbügeln und die Schnittstelle produktiv nutzbar zu machen.

Bottle z.B. erkennt, wenn der content-type header mit einem charset versehen wurde und codiert unicode automatisch.

Defnull hat geschrieben:Genau dafür sind eigentlich WSGI Frameworks da: Die WSGI Hürden so weit es geht ausbügeln und die Schnittstelle produktiv nutzbar zu machen.

Wenn es keinen WSGI Standard gibt lässt sich dass nur schlecht machen.

DasIch hat geschrieben:

Defnull hat geschrieben:Genau dafür sind eigentlich WSGI Frameworks da: Die WSGI Hürden so weit es geht ausbügeln und die Schnittstelle produktiv nutzbar zu machen.

Wenn es keinen WSGI Standard gibt lässt sich dass nur schlecht machen.

Sehe ich anders. wsgiref und mod_wsgi existieren beide für Python 3 und sind nutzbar. wsgiref ist dabei die offizielle Interpretation von pep333 für Python 3 und auch in der Dokumentation als "reference implementation of the WSGI specification" angegeben. Läuft eine Applikation mit wsgiref, kann man davon aus gehen das sie auch zukünftig laufen wird.

Und selbst wenn WSGI 2.0 die Kompatibilität zu wsgiref brechen sollte, wird es kein großes Problem sein, bestehende WSGI Frameworks entsprechend anzupassen. Für diesen Zweck hat WSGI den "wsgi.version" Eintrag im environ dict. Für die Applikation ändert sich im Idealfall also nichts, wenn sie auf ein gutes Framework auf setzt.

Das Problem des OP hat darüber hinaus nichts mit Python3 an sich zu tun, sondern damit das man kein Unicode über ein Netzwerkkabel schieben kann und WSGI das automatische kodieren nicht vorsieht. Das Problem existiert unter Python 2 genau so und dort gibt es einen WSGI Standard.