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

Mikroformatsfestival

Jag har länge varit sugen på att göra något smart med mikroformat. Jag håller för närvarande på att göra om IRIs webbplats, och där har vi en hel del uppgifter som lämpar sig för mikroformatsuppmärkning — kontaktuppgifter (hCard), kalendarium (hCalendar) och nyheter (hAtom), till exempel.

Ett designmål med IRIs webplats är att det ska vara statiska sidor — vi har inget CMS och min efterträdare måste kunna underhålla webplatsen i frontpage eller notepad. Det gör att traditionella metoder för att skapa RSS/Atom-flöden och iCalendar-feeds inte riktigt funkar. Ingenting ligger i en databas från vilken vi kan dra ut samma innehåll i flera olika versioner.

Men om de statiska sidorna är mikroformatsuppmärkta skulle jag kunna skriva ett script som tar en HTML-sida med hCalendar-data och spottar ut en iCalendar-feed, klar att inkludera i Apple iCal eller Google Calendar. Samma med nyhetssidan och valfri flödesläsare.

Det stora problemet är bara att göra det i den tekniska miljö vi har — classic ASP. Att parsa HTML med strängoperationer i VBscript känns inte så upphetsande, så helst vill jag använda mshtml. Tyvärr hittar jag ingen dokumentation om hur man kan använda MSHTML från Activescripting-världen med allt vad det innebär av Dispatchinterface och sen bindning — jag hittar inte ens rätt CLSID. doc = CreateObject("mshtml.HTMLDocument2") funkar inte, iallafall. Det finns en hel del dokumentation om hur man gör det utifrån en webbrowser control, men ett sådant objekt verkar inte gå att instansiera från serversidan. Hmm. Vid närmare efterforskningar verkar mshtml inte supportas på serversidan överhuvudtaget.

Kanske att jag ska fixa det med ett pythonscript på min egen server som använder Almost Universal Microformats Parser istället, bara för att få något som funkar?

Nätverksneutralitet

En debatt som förts med växande intensitet det senaste halvåret är den om nätverksneutralitet — enkelt uttryckt, ska infrastrukturleverantörer få prioritera eller diskriminera datatrafik från olika tjänsteleverantörer (eller olika protokoll, eller andra kriterier) allt efter eget huvud, eller ska staten reglera området och sätta ramar för hur näten hanteras?

Även om det i grunden är en fråga om statlig inblandning eller företagsfrihet (och därmed har en komplex ekonomisk/juridisk karaktär) är den faktiska nätverkstekniken viktig. Det är talande att många mycket tekniskt insatta personer, som vanligtvis tenderar att vara skeptiska till statlig inblandning, är för nätverksneutralitetslagstiftning (från ett immaterialrättsperspektiv är Lessigs liknelse mellan Fair use och nätverksneutralitet också intressant).

Därför är det bra att Ed Felten (igen!) samlat sina bloggpostningar i ämnet från det senaste halvåret i ett tiosidigt, relativt lättläst paper som inte tar ställning i den politiska frågan (åtminstone inte direkt) utan bara reder ut vad nätverkspriotering/diskriminering innebär och vad det kan få för effekter i olika sammanhang. Om rätt personer läser det kanske vi slipper höra någon svensk politiker stå i riksdagen och förklara att Internet, det är en serie tuber.

Det är bekvämligheten, dumbom!

Ed Felten kommenterar gårdagens WSJ-nyhet om att studenter vid amerikanska universitet, som har gratis tillgång till s.k. ”lagliga nedladdningstjänster” för musik (exv nya Napster) ändå väljer att antingen ladda ner via icke auktoriserade tjänster eller köper filer från ITMS — det måste ses som en ganska kraftig spik i kistan för stereotypen att fildelare är snåla jävlar som inte vill betala för sig. Det handlar inte om betalningsovillighet — det handlar om man vill ha ett system som drar största möjliga nytta av teknikens möjligheter, inte ett worst-of-breed-system som kombinerar alla nackdelar med fysiska exemplar, digital förgänglighet och fingranulerade restriktionsmöjligheter. Bekvämlighet, flexibilitet, framtidssäkerhet, och det faktiska ägandet (med vilken följer rätten att sälja sin musik i andra hand, eller låna ut den till en kompis) är minst lika viktigt som priset.

Eller, för att ta ett exempel. För en månad sedan släpptes Entombeds nya EP, ”When in Sodom”. Jag har inte hört den än. Den finns inte på svenska ITMS. Den finns inte på CDON downloads. På Homedownloads kommer jag inte ens in, varken med Firefox eller IE. Den finns inte ens på de vanliga nätbutikerna, ni vet de där old school-relikerna som säljer plastbitar. Gissa vad som är det bekväma alternativet?

Lagen.nu 2.0 – vägkarta

Det här ämnar jag göra med lagen.nu 2.0:

  • Rättskällor: Flera rättskällor (förutom SFS även förarbeten, rättsfall, vissa nämnd/myndighetsbeslut (ARN, JO), EG-direktiv, EG-domstolsdomar)
  • Annotering: Göra rättskällorna kommenterbara och även bygga en generell jurist-wiki
  • Koppling: Koppla ihop rättskällor och wikiartiklar med varandra semi-automatiskt (en generaliserad version av dagens länkar till rättsfall och lagändringar under kommentarerna)

Det här skulle vara nice-to-haves:

  • Inkorporering av doktrin
  • Rättsfall i litteraturen

Det finns också några saker jag inte kommer göra:

  • Allt som kräver manuell interaktion med myndigheter eller andra — lagen.nu måste kunna köra och uppdateras i princip obevakat, som det gjort det senaste året.

Använder du lagen.nu? Vad skulle du vilja ha ut av en rättsinformationstjänst?

Det digitala analoghålet

Jag var ute och joggade igår. Som bakgrundsmusik hade jag laddat min JOS-MP100 (old school!) med In FlamesCome Clarity”, inköpt på iTunes Music Store. Det funkade riktigt bra, men än så länge känns ”Soundtrack to your escape” vassare. Dead End, med Lisa Miskovsky på gästsång, är dock en riktig hit.

Om du hajade till av föregående stycke, och det inte var relaterat till min kassa musiksmak, är du förmodligen en äkta tekniknörd. Det jag gjort — spelat ITMS-inköpt musik på en icke-iPod — går ju inte, om man ska tro den vanliga rapporteringen kring Apple, iTunes och anklagelserna kring missbruk av monopolställning.

Min lösning är synnerligen lowtech – jag använde helt enkelt iTunes inbyggda CD-bränningsfunktion för att skapa en vanlig ljud-CD. Denna rippade jag sedan till MP3 med EAC. Som en bonus har jag musiken uppbackad tills nästa gång hårddisken kraschar. Detta steg – vilket vi kan kalla ett digitalt analoghål – avlägsnar den tekniska skyddsåtgärd som FairPlay-DRM-systemet utgör. Samtidigt försämrar det ljudkvalitén, eftersom ljuddatat måste[1] gå igenom ett ytterligare komprimeringssteg utöver den AAC-komprimering som filerna är kodade med vid köptillfället.
Men man bör notera att även om ITMS hade sålt musiken utan DRM hade jag inte automatiskt kunnat flytta musiken till min MP-100. Samma sak om jag hade kunnat använda hymn för att ta bort skyddet. Anledningen är att filerna som sagt är AAC-komprimerade. Det finns inga[2] digitala musikspelare förutom iPods som hanterar AAC-komprimering. Detta problem är dock mindre; det finns inte något som hindrar[3] spelartillverkarna att stödja AAC på samma sätt som nästan alla idag stödjer WMA, och man kan anta att om ITMS började sälja icke-DRMad AAC så skulle andra tillverkare än Apple börja stödja det.

En spännande fråga är dock om jag bröt mot 52 d § URL när jag brände ljud-CDn. Jag antar att det faktum att iTunes har, och alltid har haft, brännarfunktionen för ITMS-köpta låtar, är en indikation på att rättsinnehavarna gett sitt samtycke till kringgående av den aktuella skyddsåtgärden. Eller så kan man se det som att ett tekniskt skydd som det är möjligt att kringgå utan att man märker det omöjligtvis kan vara verkningsfullt, och att förfarandet därmed skulle falla utanför 52 b § 2 st.

[1] Såvida inte ens spelare klarar okomprimerad WAV, FLAC eller annat lossless-format, och har gott om lagringsutrymme.

[2] Såvitt jag vet — om du har en modell som stöds av Rockbox kan du eventuellt spela AAC på det viset.

[3] Förutom diverse mjukvarupatent, men såvitt jag vet är patentsituationen för AAC-dekodning inte mer snårig än för MP3 och WMA — jag kan ha fel här, dock.