När jag skriver mina inlägg för denna blogg går jag till väga som jag beskrev den 1 november 2014: jag sparar inläggen som markdownfiler på min hårddisk och använder sedan Pandoc (Mac⁠Farlane 2016) för att överföra dem till HTML. På så vis kan jag automatisera hanteringen av bibliografier, fotnoter och så vidare. Sedan en tid tillbaka har jag använt mig av ett skript som dels sköter kompileringen med Pandoc, dels överför den på så sätt genererade HTML-koden till bloggen på automatisk väg, utan att jag behöver gå via WordPress webbgränssnitt. När inlägget postats returneras det ID-nummer som det tilldelats på bloggen, vilket sedan lagras i den ursprungliga källfilen. På så vis har jag enkelt kunnat göra ändringar i befintliga inlägg via skriptet.

WordPress har ett så kallat API som bygger på standarden XML-RPC för att göra det möjligt att fjärrstyra programmet, vilket jag använt mig av i mitt skript. Nu har detta emellertid slutat att fungera, och jag hittar ingen lösning. När jag söker på XML-RPC och WordPress verkar det mest som folk är arga på detta API och vill ha hjälp att stänga av det, eftersom det ofta utnyttjats för olika former av angrepp. Det tycks också som det är på väg att fasas ut till förmån för ett nyare API som använder sig av standarden REST. Jag provade att göra om skriptet så att det i stället använder sig av detta system.

Detta innebar emellertid nya problem, även om det nya API:et i sig är smidigt. För att autentisera sig är det nödvändigt att använda så kallad Basic Auth, alltså att skicka användarnamn och lösenord i ett HTTP-huvud, eller av det mer komplicerade OAuth. Det första systemet fungerade inte: det verkar som om uppgifterna filtrerades bort, och olika lösningsförslag jag sett har inte hjälpt. OAuth bygger, i alla fall i den version som används av WordPress, på att det externa programmet först får tillåtelse att kommunicera med WordPress och att användaren sedan får logga in via webbsidan. Det är avsett för att en webbtjänst skall kunna nås via webbsidor från tredje part utan att användaren skall behöva ge sina uppgifter till dessa, och det är ohanterligt med skript som inte körs i webbläsaren. Fler än jag har bekymmer med att ingen av metoderna passar (Pöntinen 2015).

Jag kan förstås återgå till att bara generera en HTML-fil via Pandoc och sedan klistra in dess bodyinnehåll i WordPress webbgränssnitt (det är så jag gör med detta inlägg), men det innebär en förlust i smidighet, speciellt om jag vill göra smärre ändringar i inläggen i efterhand. Så nu försöker jag mig i stället på att generera bloggen på min dator med hjälp av Hakyll (Jeugt 2016) – ett program som är gjort för att samarbeta med Pandoc och, i likhet med Pandoc, är utvecklat i Haskell, och som jag tidigare använt för Mortalitetsdiagram. Jag har lagt upp ett utkast till en webbplats innehållande en replik av förra inlägget på denna blogg. Hittills verkar det fungera bra. Den stora nackdelen med system av denna typ är att det inte finns något inbyggt stöd för kommentarer, när allt är lagrat som fasta HTML-filer på webbservern. Därför har jag bäddat in Disqus för att möjliggöra kommentering, även om det vore trevligt att slippa beroende av sådana externa system.

Referenser

När jag för några år sedan letade efter ett verktyg för att enkelt generera HTML med automatiska källförteckningar stötte jag på Pandoc, som jag använt flitigt sedan dess, bl.a. för denna blogg, och som jag diskuterade i min uppsats i arkivvetenskap om hållbara filformat, som jag skrev om här den 2 juni. Genom detta fick jag höra talas om Haskell, det språk i vilket Pandoc är utvecklat. Det är ett språk som skiljer sig ganska markant från de flesta väletablerade programmeringsspråk genom att det är rent funktionellt. De funktioner som finns i vanliga programmeringsspråk kan ha s.k. sidoeffekter som inte är kopplade till deras returvärde: de modifierar variabler, läser och skriver filer och skriver till skärmen. Detta gör funktionernas beteende svårförutsägbart och skiljer dem från funktioner i matematisk mening, som alltid ger bestämda utdata för en viss uppsättning indata. Haskell eliminerar sådana sidoeffekter: vill jag komma åt filsystemet eller ta emot data från användaren (annars blir det svårt att konstruera några användbara program) får jag definiera en funktion som returnerar en s.k. I/O-handling.

Språket är uppkallat efter logikern Haskell Curry (1900–1982), och har en specifik koppling till honom. Han bidrog till utvecklingen av currying, en teknik som innebär att en funktion med flera argument omvandlas till en kedja av enställiga funktioner: har vi t.ex. en tvåställig funktion \(x-y\), kan vi för \(x=2\) definiera en ny enställig funktion \(2-y\). Currying är centralt i Haskell eftersom alla funktioner är enställiga.

För ett par månader sedan uppmärksammades i Wired att Facebook numera använder Haskell för att utveckla sitt antispamsystem (Metz 2015). Olika fördelar med språket när det gäller sådana tillämpningar diskuteras, men programmeraren Mathias Biilmann liknar det vid ett språk från en alternativ framtid som aldrig kommer att infalla och säger att det är så annorlunda jämfört med etablerade språk att det inte finns en chans att det kommer att bli vanligt.

Jag undrar om inte barriären när det gäller ökad användning av Haskell handlar mycket om bristen på färdiga väldokumenterade bibliotek. Det är t.ex. en tilltalande tanke att använda funktionella språk för analys och visualisering av data (vanliga kalkylblad är, som påpekas av HaskellWiki (2015), bara en specialiserad form av funktionell programmering), men om det inte finns verktyg för att hantera datatabeller och generera diagram utifrån dessa kräver det mycket arbete från grunden, och det är nog få som är motiverade att göra detta när de har tillgång till språk som Python (med Pandas), R och Julia.

Situationen har dock förbättrats de senaste åren. Nu i somras laddades t.ex. paketet Frames upp till Haskells stora paketförråd Hackage (Cowley 2015a). Detta paket kan användas för att läsa in CSV-filer (eller textfiler separerade med andra tecken) i en tabellstruktur, och paketet har ett överskådligt tutorial (Cowley 2015b). Jag provade att göra ett enkelt program för att generera diagram utifrån Socialstyrelsens matriser över incidens i cancer i Sverige, som jag skrivit om i de senaste inläggen, och det finns tillgängligt via GitHub. Om programmet kompileras och textfilen IncWebR2011.txt finns tillgänglig kan nedanstående diagram över utvecklingen av incidensen (åldersstandardiserad till 2000 års svenska befolkning) i akut myeloisk leukemi (ICD 2050) i Sverige 1960–2011 sparas till aml.svg genom att ./secanc 2050 1960 2011 bef2000 aml.svg anges i en terminal. Själva diagrammen genereras med hjälp av paketet Chart (Docker 2014).

Diagrammet visar åldersstandardiserad incidens i akut myeloisk leukemi i Sverige 1960–2011. Rådata tillgängliga via Socialstyrelsen (2015).

Haskells krav på typsäkerhet gör att datatabeller är litet mer komplicerade att hantera än i språk som Python, vilket kan vara en bidragande orsak till att utvecklingen av verktyg som Frames hållits tillbaka. Frames använder sig av s.k. Template Haskell för att med hjälp av källfilen för en tabell baka in kod som definierar tabellstrukturen i programmet vid kompileringen. När jag försökte göra det med hela IncWebR2011.txt identifierades inte alla kolumntyper korrekt: vissa kolumner med flyttal kom t.ex. att definieras som booleska värden, vilket fick till följd att kanske 95 procent av raderna ignorerades. Jag löste det genom att klippa ut de tre första raderna i filen och använda dem för att läsa in strukturen.

Sedan är det inte riktigt praktiskt att ha 24 olika typer för de olika incidenskolumnerna; det vore mer hanterligt att ha tabellen i ”långt” format, med en incidenskolumn och sedan en textkolumn för att ange åldersgrupp eller standardbefolkning. Det finns en funktion melt för att ”smälta” tabeller och göra just detta (liknande funktioner finns tillgängliga för de ovannämnda etablerade språken). Dessvärre äter funktionen upp minnet i datorn när jag försöker använda den på den aktuella tabellen; vet inte om jag gör något dumt eller om det är en bugg (eller kanske båda delarna).

För några dagar sedan publicerades i SvD en understreckare med anledning av att det idag, den 10 december 2015, är 200 år sedan Ada Lovelace, som beskrivits som världens första programmerare, föddes (Burman 2015). Även Häggström (2015) uppmärksammar detta jubileum, som han menar är något mycket större än Nobeldagen. Lovelace samarbetade med Charles Babbage, som beskrev en Analytical Engine, som, om den färdigställts under 1800-talet, hade blivit världens första datorsystem med ett turingfullständigt maskinspråk. Turingfullständighet är en egenskap som innebär att ett system kan beräkna varje beräkningsbar funktion¹. Egenskapen kan gälla dels programmeringsspråk (moderna programmeringsspråk är i regel turingfullständiga)², dels fysiska datorer (som dock inte uppfyller den fullständigt, eftersom de har begränsat minne). Lovelace utarbetade bl.a. en algoritm för att med hjälp av denna tilltänkta maskin generera Bernoullital. Dessutom diskuterade hon hur maskinen skulle kunna användas för att utföra uppgifter utöver manipulation av siffror, som skulle kunna beskrivas matematiskt, som att komponera musik.

Lovelace dog i cancer 1852 – en av medlemmarna i den otursamma [35, 39]-klubb, som annars inkluderar personer som Bob Marley, Arthur Rimbaud, Eva X Moberg och den Karin som beskrivs av Malmquist (2015). Babbage dog vid 79 års ålder 1871, utan att ha förverkligat sin analytiska maskin. Både Burman (2015) och Häggström (2015) framhåller skönlitteratur som diskuterar vad som hade hänt om Lovelace och Babbage fått maskinen färdig under 1800-talet. Detta kontrafaktiska scenario kan vi inte veta mycket om: Burman säger att kontrafaktisk historia är ”både lockande och ovetenskaplig” (fast ägnar sig inte seriösa historiker åt orsaksförklaringar, som kan antas ge stöd åt vissa påståenden om hur det hade gått om ett visst villkor inte varit uppfyllt?). Med hänsyn till de resonemang kring känsligheten hos personlig identitet som utvecklats av Parfit (1984) (hade våra föräldrar väntat bara ett litet tag, eller haft litet mer bråttom, hade det varit andra än vi som existerat) kanske det ändå är rimligt att tro att ingen av de personer födda under 1900-talet som refereras i detta inlägg hade existerat.

I förra veckan publicerade jag min masteruppsats i arkivvetenskap vid Uppsala universitet (Pettersson 2015). Utgångspunkten är att alltmer textdokument skapas och bevaras elektroniskt, samtidigt som det är oklart vilka filformat som är att föredra givet målen att dokument både bevaras intakta och hålls användbara. Jag diskuterar i arkivsammanhang välkända format som oformaterad text, PDF/A och Office Open XML Document (.docx). Dessutom tar jag upp Markdown, ett format som hittills inte har fått så mycket uppmärksamhet i diskussionen kring bevarande, kanske för att det är relativt nytt och inte kommer från någon av de stora aktörerna i området.

Markdown har flera egenskaper som är önskvärda när det gäller bevarande av textdokument: genom minimalistisk uppmärkning kan dokumentens struktur och formatering bevaras, samtidigt som dokumentinnehållet kan återges i en enkel textredigerare på ett mycket mer genomskinligt sätt än med vanliga XML-baserade format. Det bör därför kunna användas för digitalt bevarande i många sammanhang, även om det inte kan ersätta PDF/A när det gäller att säkra minutiöst bevarande av dokumentens utseende. Som jag skrev om här den 1 november skriver jag inläggen på denna blogg i Markdown, som jag sedan överför till HTML med programmet Pandoc (Mac⁠Farlane 2013). Ett problem med att använda Markdown för långtidsbevarande är dock att det för närvarande inte existerar någon vedertagen formell specifikation av detta format (i motsats till ISO-standardiserade format som PDF/A och Office Open XML), och att det finns olika delvis inkompatibla dialekter av formatet. Dock finns initiativ från bl.a. Pandocs skapare när det gäller att utarbeta rigoröst specificerade versioner av Markdown (Mac⁠Farlane 2015).

Jag har också arbetat en del på sidan med diagram över mortalitetstrender jag skrev om i förra inlägget. Det finns numera ett GitHub-förråd med skript för att generera diagrammen och för att ladda hem datafilerna från WHO:s hemsida och läsa in dem i en MySQL/MariaDB-databas. På sidan finns för närvarande diagram för 24 befolkningar. Jag har valt ut sådana som har relativt obrutna dataserier för både dödsfall och befolkningsstorlek tillgängliga från 50-talet via WHO (2014), vilket förklarar överrepresentationen av rika västländer. Det finns 22 dödsorsakgrupper, och trender kan visas som dödstal eller som andel av den totala dödligheten. För dödstal finns diagram för åldersgrupperna 15–44, 45–64, 65–74 och 75–84 år, och det som visas är genomsnittliga dödstal över 5-åriga åldersintervall inom dessa grupper, för att kompensera för förändringar i åldersstrukturen. Andelar är ofta mer relevanta att studera ur ett livstidsperspektiv, samtidigt som det också kan vara intressant att se i vilken mån de drivs av trender i mycket hög ålder, där rapporteringen ofta är osäker. Därför visas de i stället för alla åldersgrupper, eller för personer under och över 85 år. Totalt finns nu 3600 diagram på sidan.

Om man skall distribuera t.ex. en uppsats via Internet är det i allmänhet en bra idé att använda sig av PDF-formatet hellre än något ordbehandlingsformat. I så fall finns åtminstone en rimlig chans att dokumentet återges korrekt med avseende på teckensnitt, sidbrytningar och så vidare på mottagarnas skärmar och skrivare.

När det gäller de krav som ställs för långtidsbevarande i elektroniska arkiv har emellertid även det vanliga PDF-formatet egenskaper som kan ställa till problem. Det kan finnas inbäddat ljud- och videoinnehåll som kräver speciella program för att återges korrekt, och teckensnittsfiler kan vara länkade snarare än inbäddade (så att den som läser dokumentet måste ha teckensnitten installerade för att det skall återges korrekt). Det har därför utarbetas en ISO-standard, PDF/A, som specificerar att sådana problematiska funktioner som de ovannämnda inte får förekomma. Det finns sedan olika varianter av PDF/A-standarden: den idag kanske mest spridda, som föreskrivs av t.ex Riksarkivet (2009) för bevarande av kontorsdokument, är PDF/A-1. Ett dokument kan dessutom vara förenligt med standarden på nivå a eller b, där b är den mest grundläggande.

Jag skriver för närvarande på en masteruppsats om filformat för digitalt bevarande av text och gick också nyligen en kurs om digitalt bevarande. Som ett experiment provade jag att överföra mitt eget kurs-PM till PDF/A-1b. Den ursprungliga PDF-filen KarlPetterssonPMDigitaltBevarande.pdf hade skapats via LaTeX: det var ett enkelt 9-sidigt dokument med litet färgade hyperlänkar men inga bilder. Följande kommando skapar utifrån denna ett PDF/A-dokument med namnet KarlPetterssonPMDigitaltBevarandeA.pdf:

$ gs -dPDFA -dBATCH -dNOPAUSE -dPDFACompatibilityPolicy=1 \
-dEmbedAllFonts=true -dSubsetFonts=false -dUseCIEColor -sDEVICE=pdfwrite \
-sOutputFile=KarlPetterssonPMDigitaltBevarandeA.pdf \
PDFA_def.ps KarlPetterssonPMDigitaltBevarande.pdf

Kommandot använder sig alltså av programmet Ghostscript. Filen PDFA_def.ps används som prefix till dokumentet och innehåller bl.a. inställningar för ICC-profil för att få korrekt färgåtergivning. När man öppnar en fil genererad på ovanstående sätt i Adobe Reader visas normalt ett meddelande mot blå bakgrund om att den överensstämmer med PDF/A-standarden och att den öppnats i skrivskyddat läge. Detta innebär emellertid inget annat än att filen utger sig för att vara PDF/A. För att avgöra om den verkligen överensstämmer med standarden måste den köras genom en validator. Jag provade att testa mitt dokument mot en sådan validator, Apache Preflight (tillgänglig via Apache Software Foundation (2014)). Den senaste tillgängliga versionen, 1.8.8, var inte körbar, så jag använde mig av en något äldre version (1.8.5):

$ java -jar preflight-app-1.8.5.jar \
KarlPetterssonPMDigitaltBevarandeA.pdf

Detta medförde, som dokumentet från början var utformat, en ca 50 kB lång lista med felmeddelanden, som handlade om teckensnittsfel, som saknade glyfer. Om jag inte använde inställningen UseCIEColor resulterade det i ännu fler felmeddelanden om färgnamn. Enligt en onlinevalidator (PDF Tools AG 2015) var dokumentet emellertid giltigt enligt PDF/A-1b.

Jag lyckades efter en stund lista ut att problemet hade att göra med teckensnittsinbäddning. I den ursprungliga filen hade jag använt mig av OpenType-teckensnitt. PDF 1.4 (som ligger till grund för PDF/A-1) har inte stöd för inbäddning av sådana teckensnitt, vilket innebär att de måste konverteras, t.ex. till Adobe Typ1. Jag provade att ändra ursrpungsdokumentet så att det använde sig av Typ1-teckensnitt, och då fick jag en PDF/A som gick igenom båda validatorerna. Någonting relaterat till konverteringen av OpenType-teckensnitten gav upphov till felmeddelandena. Sedan vet jag inte om det var något som hade kunnat vålla verkliga problem vid digitalt bevarande eller om det var att betrakta som falskt positivt utslag från Apache Preflight. Hur som helst är det bekymmersamt att olika validatorer från etablerade leverantörer ger så pass olika resultat när det gäller att avgöra om ett dokument uppfyller en utbredd standard för arkivsäkerhet eller inte.

DN rapporterar idag om att det finns mer än 10 000 svenska webbplatser (mer precist: platser på .se-domän) baserade på WordPress, som inte har uppdaterats sedan version 3.3.1 av programmet, som kom i början av 2012, vilket gör dem sårbara för olika typer av angrepp (Örstadius 2014). Som jag sett folk kommentera är det i många fall säkert frågan om ”döda sidor”, men de som sköter sidorna måste förstås ändå se till att de antingen inaktiveras eller uppdateras, så att de inte kan utnyttjas för attacker som kan skada andra.

Utvecklingen av Internet ställer hur som helst ökade krav på de som administrerar webbplatser. När webben lanserades på 1990-talet gjorde man enkla s.k. statiska webbplatser, där webbplatsen fanns lagrad på servern i form av HTML-filer, som inte ger mycket interaktion med användaren, bortsett från hyperlänkar, och där varje HTML-fil visades i webbläsaren som ett fristående dokument.

En tidig lösning för att hantera mer komplex layout, med sådant som navigationsmenyer, var s.k. ramar (frames), där man kan göra länkar som visar en HTML-fil i en viss ram som upptar en del av huvudsidan. Förfarandet gav snabbt upphov till klagomål, bl.a. därför att det blev problem att skapa bokmärken eller länkar från andra sidor. Ändå använder sig en del webbplatser fortfarande av ramar. Jag fick erfara det nyligen när jag skrev en webbartikel för Arbetarrörelsens arkiv och bibliotek, där jag praktiserar, om Föreningen FiB-juristerna (Pettersson 2014). Föreningens organ, Tidskrift för Folkets Rättigheter, använder ännu en rambaserad lösning på sin webbplats (Föreningen FiB-juristerna 2014). Om man öppnar de två sista länkarna i referenslistan i min artikel (som går till sidor på webbplatsen) visas sidorna lyfta ur den kontext där de är tänka att visas (navigationsmenyerna försvinner).

Moderna webbplatser är ofta uppbyggda kring innehållshanteringssystem som WordPress, där inga fasta HTML-filer behöver lagras på webbservern. I stället kör servern ett skript som använder information lagrad i en databas för att generera HTML dynamiskt, när en begäran skickas från t.ex. en webbläsare. Detta har gett stor flexibilitet när det gäller att bygga upp webbplatser med komplicerad struktur och sidor med komplex layout, utan primitiva lösningar som de nämnda ramarna, och låta webbplatsens användare bidra med information. Men samtidigt kan det öppna för nya sårbarheter när användarna, när de kommunicerar med webbservern, inte längre interagerar med ett simpelt HTML-dokument, utan med ett komplext program skrivet i ett kraftfullt språk som PHP, i vilket WordPress är utvecklat. Många som använder WordPress och liknande system kanske inte har reflekterat över detta.

Denna blogg är ett exempel på en webbplats som drivs med WordPress – fast jag ser ju till att hålla programmet och de tillägg jag använder uppdaterade. Jag skriver dock inte inläggen i WordPressgränssnittet, utan lagrar dem på min lokala hårddisk som filer kodade i markdown, ett s.k. lättviktigt märkspråk, med kod som är lätt att både läsa och skriva. Sedan använder jag ett enkelt Perlskript som wrapper runt programmet Pandoc (Mac⁠Farlane 2013) för att generera HTML, som jag överför till servern. På så vis kan jag enkelt skapa referenser utifrån mina BibTeX-databaser, och det blir relativt smidigt att överföra inläggen till ett annat filformat än HTML.

Det är möjligt att det kommer att bli en viss renässans för statiska webbplatser. I dag finns verktyg som Octopress, som gör det möjligt att generera komplexa webbplatser för t.ex. bloggar på det lokala systemet och sedan ladda upp dem på en webbserver, vilket beskrivs av programmeraren Julia Evans (Evans 2014). Sidorna kan sedan skrivas i markdown. Avancerad layout kan numera skapas med hjälp av CSS och skript skrivna i t.ex. Javascript, som körs på klienten, oavsett om man har sidor som genereras dynamiskt eller finns lagrade statiskt på servern. Bygger man upp webbplatsen statiskt på detta sätt tar man förstås bort möjligheten för en godtycklig användare att ladda upp innehåll, t.ex. bloggkommentarer, som lagras på servern. En lösning, om man behöver sådana möjligheter, är att använda Javascript för att bädda in t.ex. Disqus för hantering av kommentarer. Vissa har dock uttryckt reservationer för att sådan ”outsourcing” tenderar att skapa ökat beroende av externa, proprietära system (Scheff 2011).

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.