Seite 1 von 1

[bottle] von django zu bottle, Probs mit Umlauten

Verfasst: Mittwoch 21. April 2010, 11:57
von Oscar426
Hallo,

die Umstellung von Django auf Bottle läuft hier soweit ganz geschmeidig. Was mir allerdings Kopfzerbrechen bereitet ist das Encoding der Daten die aus einem Http-POST zurückkommen, also aus einem einfachen Texteingabefeld der Webseite. Der Inhalt von request.POST['irgendwas'] ist bei Django vom Typ Unicode, bei bottle hingegen vom Typ String ...
Werden über die Webseite Daten mit Umlauten drin eingegeben führt das zu Problemen bei den anderen Modulen, uA der Datenbank.
Kann ich bottle dazu bringen sich hier wie Django zu verwalten, bzw, wie kann ich den String wieder in ein verdauliches Unicode umwandeln? alle meine Versuche mit .decode, .encode schlugen bisher fehl ...

ich verwende python 2.5 und bottle 0.6.2

vielen Dank schonmal vorab.

Re: [bottle] von django zu bottle, Probs mit Umlauten

Verfasst: Mittwoch 21. April 2010, 12:31
von ms4py
Oscar426 hat geschrieben:alle meine Versuche mit .decode, .encode schlugen bisher fehl ...
Es wäre angebracht, diese dann mal mit Fehlermeldung zu posten.
`decode` mit bottle und POST funktioniert bei mir problemlos, hier ein Beispiel:
http://bitbucket.org/ms4py/bottle-wiki/ ... .py#cl-164

Edit: Vielleicht versuchst du es auch mal mit einer neuen Version von bottle, wenigstens die aktuelle aus dem PyPI.

Verfasst: Mittwoch 21. April 2010, 12:43
von Defnull
HTTP überträgt kein Unicode, sondern Byte Strings. Daher liefert Bottle die Daten auch unverändert. Wenn du die HTML Seite als utf8 auszeichnest, werden die meisten Browser Umlaute in utf8 kodieren. Ein .decode('utf8') sollte dir also die gewünschten unicode-strings liefern.

Verfasst: Mittwoch 21. April 2010, 13:03
von Oscar426
ok klappt ..
... und ein weiteres mal: danke schön :)

Verfasst: Mittwoch 21. April 2010, 15:40
von Hyperion
Defnull hat geschrieben:HTTP überträgt kein Unicode, sondern Byte Strings. Daher liefert Bottle die Daten auch unverändert.
Ohne ein Fass aufmachen zu wollen: Aber liegt da nicht das Problem bei Python3 und WSGI?

Verfasst: Mittwoch 21. April 2010, 16:21
von Defnull
Das Python3/WSGI Problem ist ein Anderes. Vor allem da der OP Python 2.x verwendet.

Verfasst: Mittwoch 21. April 2010, 16:27
von Hyperion
Defnull hat geschrieben:Das Python3/WSGI Problem ist ein Anderes. Vor allem da der OP Python 2.x verwendet.
Nee, ich meinte nicht das Problem des OPs, sondern Py3 & WSGI im Allgmeinen. Aber ok. Habe ich es immer noch nicht verstanden ;-)