Jag har länge tänkt göra en uppföljning till det jag skrev den 1 november 2012, för att se om trenden med en plötslig ökning av vårdade för influensa och lunginflammation, speciellt bland unga, i Sverige 2011 bröts 2012. Socialstyrelsen har emellertid dröjt med att lägga ut uppgifter för slutenvårdsdiagnoser i statistikdatabasen (Socialstyrelsen 2014). I går fick jag se att de till slut gjort det: det verkar som anledningen till fördröjningen är att de utarbetat ett nytt webbgränssnitt för databasen. Detta är välkommet eftersom det innebär att man slipper osäker och klumpig insticks-Java, som tidigare krävdes. Dock fick jag erfara att gränssnittet fortfarande är en aning buggigt.

Det problem jag råkade ut för är relaterat till Unicode, som är en standard som används för teckenhantering i moderna datorsystem, och som har ambitionen att inkludera nutida och historiska skriftsystem från hela världen, typografiska och matematiska symboler etc. Tecknen indelas i 17 plan, som vart och ett har plats för $2^{16}=65536$ tecken. De mest använda tecknen, både i västerländska och österländska skriftsystem, finns i det nedersta planet, Basic Multilingual Plane (BMP), och många av de övre planen är för närvarande odefinierade (och de olika Unicodeteckensnitt som finns tillgängliga har generellt inte glyfer utritade ens för alla teckenpositioner som är definierade för synliga tecken). Det finns vidare olika teckenkodningar, som anger vilka bitsekvenser som skall representera de olika tecknen i Unicode. En sådan kodning är UTF-8, som har blivit mer eller mindre standard på webben och inom t.ex. Linux och använder mellan en och tre byte (8-bitarssekvenser) för varje tecken i BMP. UTF-16 är en annan kodning, som är vanligt förekommande i Windows och använder två byte för varje tecken i BMP. Båda kodningarna använder fyra byte för de mindre vanliga tecknen i de övre planen.

UTF-16 kan vidare använda sig av antingen little endianness (LE) eller big endianness (BE). Denna terminologi är inspirerad av en episod i Gullivers resor, där det skildras hur två önationer bråkar om man skall knäcka äggen i den tjockare eller smalare änden, och de som förespråkar det förra kallas big endians. I datorsammanhang innebär LE att den minst signifikanta byten i ett ord (t.ex. ett tecken kodat med två byte i UTF-16) kommer först (som om man t.ex. skulle skriva ental före tiotal), och BE innebär att den mest signifikanta byten kommer först (som i vårt vanliga decimalystem). Vilket system som används i en fil kodad med UTF-16 anges med en byte order mark (BOM) i början av filen, men om ingen sådan finns säger standarden att programmet skall anta BE.

När jag nu sparade ned textfiler från (Socialstyrelsen 2014) var det flera olika program som inte visade dem korrekt, bl.a. Vim och Gnumeric under Linux. Det visade sig bero på att de sparats med UTF-16LE utan att någon BOM infogats i början av filen. Kanske är Windowsprogram bättre på att tolka sådana filer automatiskt, eftersom de ofta använder UTF-16LE som standard, vilket skulle kunna förklara att folket på Socialstyrelsen, som kanske kör Windows, inte uppmärksammat buggen. Det går ändå att göra filerna läsbara i de nämnda programmen, t.ex. genom att konvertera dem till UTF-8 med programmet iconv. Gör man så krymper dessutom filerna med nära 50 procent, eftersom de nästan enbart består av de första 127 tecknen i BMP (som motsvarar den gamla teckenuppsättningen ASCII och bl.a. innehåller bokstäverna A–Z, siffror och de vanligaste skiljetecknen), där UTF-8 bara använder en byte medan UTF-16 som sagt använder två (inte för att filstorleken normalt är något större problem med denna typ av filer i moderna datorsystem).

Jag återkommer sedan med kommentar till de trender jag kunde utläsa efter att jag gjort filerna hanterbara. Hur som helst har jag skrivit till Socialstyrelsen. Förhoppningsvis rättar de till buggen, så att jag och andra personer som vill använda data från statistikdatabaserna på icke-Windowsplattformar slipper detta krånglande i fortsättningen.