Die Datenbank ist in latin1 weil das auch so von MySQL gemeldet wird (steht oben in einem code-Abschnitt). Eines Tages könnte ich versuchen, die Daten mit UTF-8 in MySQL anzulegen. Dann befürchte ich, später mal Probleme bei der Dateneingabe direkt unter MySQL, bzw. mit der Kommunikation mit Flatfiles zu bekommen, das alles bereiche sind, wo es heute problemlos läuft.
Zum Experimentieren um die richtige Lösung zu finden bin ich hoffentlich bei dem nächsten Unicode-Problem bereit.
Breite von "ä": Huch, wenn len("ä") = 2 auch wenn man alles "richtig" eingibt, ist ja komisch. In den Breitengraden aus denen ich komme (Finnland, Schweden usw.) ist "ä" ein (1) Buchstabe und keineswegs ein "zusammengesetztes Zeichen" oder irgendeine Spezialform von "a" (wie es hier südlich vom Ostsee der Fall zu sein scheint). "ä" kommt sortiermäßig auch nach "z" (... xyzåäö). Also würde in diesem Falle die "richtige" Lösung überhaupt nicht die tatsächlich richtige Lösung sein, zumindest aus meiner Sicht (locale).
Darii hat geschrieben:Wie BlackJack schon schrieb, lass das lieber und versuch zu verstehen, wie das mit den Zeichenkodierungen funktioniert, sonst wirst du bestimmt bald wieder irgendwelche Probleme kriegen.kajarno hat geschrieben:Also habe ich die Lösung selbst gebastelt, denn eigentlich ist alles was ich brauche eine Funktion, die die *Druckbreite* eines Strings errechnet, anstatt die Speicherbreite (die beim Drucken herzlich egal ist).
Die Druckbreite zu bestimmen ist übrigens wirklich nicht so einfach.Ein druckbares Zeichen kann nämlich durchaus aus mehreren Zeichen zusammengesetzt sein.Code: Alles auswählen
>>> ae = unicodedata.normalize("NFD", u"ä") >>> print ae, len(ae), repr(ae) ä 2 u'a\u0308'