HTML Formulardaten mit Umlauten in Plone verarbeiten

Django, Flask, Bottle, WSGI, CGI…
Antworten
henning

Hallo,

ich benutze PloneContacts und ein Telefonbuch in Plone zu realisieren. Dazu habe ich per Script eine CSV Datei importiert (->durchlaufen->für jeden Eintrag Object angelegt). Da einige Namen Umlaute enthalten, musste ich die Strings in UTF-8 konvertieren (->string.encode('utf-8')).

Nun funktioniert allerdings meine Suche nicht für Namen mit Umlauten. Das Pythonscript bekommt die Formulardaten. Ich wandle den Input folgendermaßen um, wobei searchFor der Suchtext ist:

Code: Alles auswählen

searchtext = unicode(searchFor, 'iso-8859-15').encode('utf-8').lower()
Gebe ich diesen String via plone_log aus, ergibt das z.B. "krÀmer" für krämer. Führe ich die gleichen Operationen an einen Pythonstring "krämer" aus, erhalte ich dagegen "krämer", was identisch mit den codierten Namen im Objekt ist. Das heißt also, dass die Formulardaten "falsch" codiert sind.

Hat jemand eine Idee, wie ich das lösen kann? Fehlermeldungen gibt es keine, es wird eben nur kein Namen gefunden. Das ganze ist Plone 2.0.5 auf Windows 2000.

Henning
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mit welchen charset besitzt denn die html Seite??? Wenn du da utf-8 angibst, solltest du vom Browser auch utf8 bekommen:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Man kann außerdem bei machen HTML-Formularteilen ein accept-charset="UTF-8" angeben...

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Henning

UTF-8 ist jetzt sowohl im HTML-Dokument, als auch im Formular gesetzt. Suche ich nach "ä", wird es in 0xc3 0xa4 codiert, was dem ä in UTF-8 entspricht.

Wie sage ich Python denn nun, dass er einen UTF-8 String hat? unicode(string,'utf-8') meldet "decoding of unicode ist not supported" und string.encode('utf-8') sagt mir "0xc3 ist nicht mehr im ascii bereich" (sinngemäß). Lasse ich die Funktionen weg, schlägt die Suche (string.find(searchtext)) mit letzterer Fehlermeldung fehl...
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Schau dir nochmal http://p-nand-q.com/python/unicode_faq.html an ;)

Es müßte mit txt.decode( "utf_8" ) gehen...

Vielleicht hilft dir auch das http://www.python-forum.de/viewtopic.php?p=20637#20637 weiter...

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

henning hat geschrieben: ich benutze PloneContacts
[...]
Da einige Namen Umlaute enthalten, musste ich die Strings in UTF-8 konvertieren (->string.encode('utf-8')).
Hi Henning!

Sieh dich mal im Collector um. Vielleicht entdeckst du etwas, was mit deinem jetzigen oder vorherigen Problem übereinstimmt.

http://plone.wardandsmith.com/collector

Evt. genügt es, Plone und Zope korrekt auf UTF-8 zu stellen, PloneContacts neu zu installieren und vor dem Importieren der CSV-Dateien, diese mit dem Editor (notepad unter Windows) nach UTF-8 umzuwandeln. (Speichern unter... Codierung: UTF-8)

Unter Linux kannst du mit den Editoren **bluefish**, vim, emacs, usw. die Datei umwandeln. Wichtig beim Umwandeln nach utf-8 ist, dass die Datei umgewandelt wird. Das Umwandeln des Inhalts ist nicht genug.

Damit das ZMI auch unter UTF-8 läuft, muss dieses umgestellt werden:

http://gerold.bcom.at/zope_plone/zope_a ... lone_utf8/
(siehe **UTF-8 als Standard**)

Ob das jetzt alles hilft? Keine Ahnung! Ich kenne PloneContacts nicht.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Henning

Hmm, Unicode scheint nicht so mein Ding zu sein. Aber von meiner nachträglich selbseingebauten Suche mal abgesehen, kann ich Kontakte, mit Umlauten im Namen nicht bearbeiten. PloneContacts benutzt ja Archetypes, wobei "firstname" und "lastname" required sind. Die id habe ich in meinem CSV-Import-Script via generateUniqueId() automatisch erzeugt. Klicke ich nun bspw. auf einen Jürgen und möchte in dem Formular diesen Kontakt bearbeiten, erhalte ich nach einem Klick auf Save

Code: Alles auswählen

UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 1: ordinal not in range(128) 
Aber das eben nur bei Leuten mit Umlauten im Namen. Das ZMI habe ich auf utf-8 gestellt, bei den PloneProperties ist default_encoding ebenfalls utf-8. Ist das normal? Oder ist mit meinem Unicodesupport irgendetwas generell nicht in Ordnung?
Henning

Hallo

Nachdem ich Unicode nun halbwegs verstanden habe, funktioniert die Suche. Ich habe den Namen einfach via string.encode('latin-1') umgewandelt. Das gleiche geht mit dem Suchtext erst, nachdem man Python via string.decode('utf-8') gesagt hat, dass da ein utf-8 codierter String kommt, was zu folgendem Statement führt:

Code: Alles auswählen

firstname = row.getObject().firstname.encode('latin-1').lower()
searchtext = searchFor.decode('utf-8').encode('latin-1').lower()
if firstname.find(searchtext):
   newresults.append(row.getObject())
Bleibt das Problem mit dem Ändern von Objekten, die Umlaute in den Feldern firstname bzw. lastname (nicht in der id!) haben. Der Fehler wird von

Code: Alles auswählen

Module Products.PluginIndexes.TextIndex.GlobbingLexicon, line 246, in Splitter
"geschmissen". Liegt da eine Fehlkonfiguration vor (d.h. klappt das bei anderen?), gibt es dafür bekannte "Tweaks" oder muss ich im Quelltext rumwühlen?

Danke schonmal für die Antworten
Henning
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Hm! Dann arbeitest du mit Windows? Denn latin-1 ist von Windows... Wenn nun jemand unter Linux/MacOS eine Suchanfrage stellt, dürfte es mit latin-1 nicht mehr gehen...

Hat die Such-Form.-Seite auch, wie ich geschrieben hab, ein charset angegeben?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Henning

jens hat geschrieben:Hm! Dann arbeitest du mit Windows? Denn latin-1 ist von Windows... Wenn nun jemand unter Linux/MacOS eine Suchanfrage stellt, dürfte es mit latin-1 nicht mehr gehen...
Nein, das sollte funktionieren, weil die Werte ja nur auf ein einheitliches Format gebracht werden, d.h. latin-1 wird nur intern benutzt. Die Seiten selber sind utf-8. Warum es ohne latin-1 nicht funktioniert, weiß ich nicht.
Hat die Such-Form.-Seite auch, wie ich geschrieben hab, ein charset angegeben?
Ja, accept-charset ist auf utf-8 gestellt. Ich glaube das ändert aber nichts.
Henning

fortsetzung von oben:

Das sollte aber nichts ändern, weil das Seitenencoding ohnehin schon auf utf-8 gesetzt ist.
BlackJack

jens hat geschrieben:Hm! Dann arbeitest du mit Windows? Denn latin-1 ist von Windows... Wenn nun jemand unter Linux/MacOS eine Suchanfrage stellt, dürfte es mit latin-1 nicht mehr gehen...
`latin-1` ist nicht "Windows" sondern eine Zeichenkodierung. Die kann man auch problemlos unter Linux verwenden. War vor der Umstellung auf `utf-8` bei mir und wohl fast allen deutschsprachigen, wenn nicht sogar allen westeuropäischen, Linux-Systemen die Standard-Einstellung.

Wenn vom Webformular `utf-8` kommt, das dann in `latin-1` umkonvertiert wird, dann gibt's grundsätzlich mit jedem Betriebsystem Probleme, wenn Zeichen eingegeben werden, die nicht in der `latin-1`-Kodierung enthalten sind.

Frage an Henning: Wieso lässt Du die vorhanden Daten nicht als Unicode-Zeichenkette und dekodierst nur den Suchtext von `utf-8` in eine Unicode-Zeichenkette?
Henning

Frage an Henning: Wieso lässt Du die vorhanden Daten nicht als Unicode-Zeichenkette und dekodierst nur den Suchtext von `utf-8` in eine Unicode-Zeichenkette?
Wie gesagt, weil es denn komischerweise nicht funktioniert. Ich verstehe zwar nicht warum, aber es erscheinen dann keine Suchergebnisse. Da es mit latin-1 aber funktioniert, ist mir das ziemlich egal.

Nicht egal, ist mir aber, dass man offensichtliche solche Objekte nicht bearbeiten kann. PloneContacts benutzt Archetypes. Der Titel (title) der Objekte wird automatisch aus dem Namen erzeugt. Lasse ich die dafür zuständige Funktion einfach "bla" returnen (also etwas ohne Umlaute), funktioniert alles. Mit Umlauten meckert aber ZCatalog rum. Kenne jemand das Problem?
Gast

Henning hat geschrieben:
Frage an Henning: Wieso lässt Du die vorhanden Daten nicht als Unicode-Zeichenkette und dekodierst nur den Suchtext von `utf-8` in eine Unicode-Zeichenkette?
Wie gesagt, weil es denn komischerweise nicht funktioniert. Ich verstehe zwar nicht warum, aber es erscheinen dann keine Suchergebnisse. Da es mit latin-1 aber funktioniert, ist mir das ziemlich egal.
Manchmal tut Blödheit einfach nur weg. Habe eben nach einem falschen Namen gesucht...
Vorher dachte ich wohl, dass ich die Kombination schon hatte.
Henning

Moin.

Auch das ändern funktionier jetzt. Das Problem war, dass die beim Plone-Windowsinstaller mitgelieferte Pythonversion ascii als defaultencoding eingestellt hatte. Dazu muss man in C:\Programme\Plone 2\Python\lib\Site.py die Variable defaultencoding entsprechend ändern.

Danke nochmal für die Hilfe,
Henning
Antworten