Unicode och python

UnicodeDecodeError: 'ascii' codec can't decode byte 0x84 in position 1: ordinal not in range(128)

Om du programmerat python känner du säkert igen ovanstående felmeddelande. Roten av problemet är att python har två strängtyper; den ursprungliga str som innehåller en singlebytesträng utan någon vidare information om vilken teckenkodning som använts, och unicode, som är en fullständig unicodesträngtyp.

Det faktum att båda dessa typer finns, fungerar och ser nästan likadana ut gör att en pythonprogrammerare måste vara på tårna hela tiden för att vara säker på vad för sorts data han bollar med — något som tar bort mycket av fördelarna med dynamismen i språket. Annars blir det lätt så att kod som verkar fungerande helt plötsligt krashar om någon stoppar in ett åttabitarstecken nånstans där ingen hade tänkt på att kunde göra det. Och om man inte är disciplinerad är det lätt att man snärjer in sig i en röra av unicode(…) och foo.encode(‘iso-8859-1’). [1]

För lagen.nu 2.0-koden försöker jag använda unicode rakt igenom, så mycket som möjligt, och behandla str som om det vore en bytearray. Det går …sådär. ElementTree ger alltid ifrån sig unicode och man mår bäst om man bara stoppar in unicode i den (även om det går att stoppa in str, men det är inte att rekommendera att använda något med höga bitten satt). BeautifulSoup är unicode-only från och med version 3, vilket är ett stort steg framåt.

Django är dock ett sorgebarn i sammanhanget. Gränssnitten både utåt, mot webbläsaren och innåt, mot databasen, är str, dessutom utf-8-kodat (om man inte ändrat DEFAULT_CHARSET, vilket dock inte är en egentlig lösning), något som är det sämsta av bägge världar. Jag menar, len av en sträng som innehåller ‘räksmörgås’ ska vara 10, aldrig 13, men kolla vad len(u’räksmörgås’.encode(‘utf-8’)) är.

Vad värre är, det går inte att stoppa in unicode överallt heller. De modeller man skapar behöver få sina strängvärden som utf-8-kodade str, annars får man 'Warning: Data truncated for column 'subject' at row 1' och frågetecken i databasen. Åtminstone mot min MySQL-databas, som internt lagrar i utf-8 (tror jag). Är det likadant vad gäller Postgres och SQLite? Vem vet?

Det går väl att lära sig leva med. Sätt upp en barriär mellan django-land och min egen kod, och se till att all str-data kodas om till unicode, och vice versa. Det kanske ordnas innan 1.0, men det är mycket att göra.

Django är dessvärre inte ensam i detta — igår tillbringade jag alldeles för lång tid på att försöka använda email-modulen med unicodesträngar, men den modulen är inte unicodesäker. Simpleparse klarar inte heller unicodeindata. Det finns säkert fler exempel.

Just unicodehantering[2] är ett av de få områdena där jag saknar COM/CLR/Java-världen. Jag menar, multibytetecken funkade smärtfritt i VB6 för typ en miljon år sedan.

På temat unicode saknade jag igår några bra teststrängar för att testa unicodedata med lite exotiskare tecken (allt över U+0255, typ) — utländska motsvarigheter till Räksmörgås, typ. Jag hittade inget direkt, men klistrade ihop något baserat på wikipedias förstasida:

Unicode/UTF-8-test

Som en added bonus innehåller den en hel del BiDi-tester med vad jag tror är korrekt rendering. Jag hade ingen aning om att det var ett så komplicerat ämne, men nu har jag lärt mig en ny HTML-tag. Det är inte varje dag!


[1] Så ser lagen.nu 1.0-koden ut. Ibland blir jag påmind om en kompis som förklarade hur han programmerar C: ”klagar kompilatorn så sätter jag dit en ‘*’, om inte det hjälper byter jag ut den mot ett ‘&'”

[2] Och till en mindre del debugging, även om det har ändrats sedan jag upptäckte Wing IDE

4 reaktioner till “Unicode och python”

  1. SQLite lagrar det mesta som text och gör det antingen som UTF-8 eller UTF-16, beroende på hur man skapat databasen. SQLite gör dock ingen strängvalidering utan lagrar glatt det man ger den och förutsätter att det är korrekta strängar.

    På grund av detta är det många Windows-implementationer som felaktigt anropar SQLite API:et med strängar i den ANSI Code Page det råkar vara istället för UTF-8/UTF-16. Även konsollprogrammet sqlite3.exe gör fel då det är en enkel portning från Linux där strängarna är UTF-8 och ingen konvertering behövs.

    SQLite förstår sig heller inte på blandningen av versaler och gemener vad gäller internationella tecken. ‘Ä’ != ‘ä’ där ‘Z’ == ‘z’.

  2. Ett tips lägg in filen ”sitecustomize.py” i sökvägen till python och lägg då in något i still med.

    import sys
    sys.setdefaultencoding(”utf-8”)
    — eller —
    import sys
    sys.setdefaultencoding(”latin-1”)

    Då slipper du en massa problem med detta. Finns dock kvar på vissa ställen.

  3. Hej

    Jag hade precis samma problem som du, men efter att ha kollat i min mysqldata så märkte jag att fälten var satta till latin1_swedish_ci

    Ändrade till utf8_swedish_ci och helt plötsligt så började allt fungera flawless igen. Förmodligen är det din databas som är felkonfigurerad med andra ord (ett år gammal blogpost så säkert löst nu men wth…)

Kommentarer kan inte lämnas på detta inlägg.