Tag-arkiv: Encoding

All your base

… are belong to us!
(Nej, vi er ikke blevet hackede!)

I går aftes tumlede jeg blot kortvarigt (igen) med et af de mest fejl-skabende områder inden for programmeringsverdenen; encoding.

Base64 encoding og decoding er smart til overførsel og delvist til lagring af binære data over ikke binære forbindelser / lagerdestinationer. Eksempelvis som HTTP POST data eller svar data på et HTTP GET request, og ligeledes til lagring i en cookie, eller en flash variabel og så videre.

Problemet opstår når et led i data-kæden misforstår base64 og urlencoder det “bare for at være sikker” og fordi “det plejer man da at gøre”. Urlencoding anvendes ofte på streng data for at sikre at disse data kan overleve at indgå som en parameter i en URL adresse. Her vil man typisk omforme mellemrum, specialtegn med videre, til gyldige URL adresse tegn (se kapitel 2 i RFC3986).

Problemet var nemt løst, men som altid med encoding-problemer, handler fejlsøgningen mest af alt om at forstå/gennemskue hele vejen dataene rejser fra start til slut og tilbage igen.

All your base64 YXJlIGJlbG9uZyB0byB1cw==

Y2k+10 bug

Knapt er vi kommet os over panikken omkring år 2000-problemet, også kendt som Y2k, der nærmest truede med verdens undergang i en sådan skala at det gør selv 2012 filmen til skamme, inden at vi rammes af en ny katastrofe; 2010 årsskiftet!

Som man kan læse i denne artikel, er Dankort systemet i ca. 1.600 P-automater i København, umiddelbart lige efter kl. 23.59 d. 31/12-2009, ophørt med at fungere til stor undren for folkene bag, og stor irritation for alle øvrige.

Det er en påstand herfra, at P-automat betalingssystemet der anvendes utvivlsomt er udviklet efter år 2000-problemet blev konstateret og løst.

Dels har det jo kørt upåklageligt da årstallet viste “00”, “01”, “02”, “03”, …, og “09”, og der ville nok først igen opstå problemer når der trilles over de “99” til “00” (lige som sidst). Desværre vippede det nye årstal ikke rundt til et “10” som man vist havde regnet med, men istedet til “0A”, der er det hexadecimale talsystems repræsentation af decimaltallet 10. Det hexadecimale talsystem er et som computere har det ret godt med – en byte omfatter 8 bits, der dækker decimaltallene 0 til 255, eller hexadecimalt 00-FF. Og så gik maskineriet i selvsving, “0A” og “10” kunne ikke sammenholdes mellem den grænseflade der er mellem betalingssystemet og yderligere systemer.

Den anden vinkel på hvorfor P-automat betalingssystem må og skal være etableret efter Y2k er at det simpelthen ville være opdaget i 1999 også; decimaltallet 99 repræsenteres som 63 hexadecimalt. Mon ikke der havde været rod i et regnskab eller to, med bogføring af indkomster fra 1963 i år 1999 uden nogen form for renteindtægt eller forudgående poster med langsigtede krediteringer?

Hvis vi tænker lidt over hvorfor man efter en så voldsom omgang skruen på kode der vedrører datoer, alligevel er kommet frem til at holde årstallet i en byte og repræsentere denne talværdi i systemet hexadecimalt både internt og eksternt, ja så er min personlige konklusion helt klar. Tanken må have været at alle da bare skal se i en fart at få lært det hexadecimale talsystem. Det er jo over 2,5 gange mere fremtidssikret med hensyn til hvornår en ny Y2K fejl opstår, vi har jo med talrummet fra 0 til 255 at gøre og ikke kun 0 til 99. Desuden vil det fjerne enhver form for enkodnings- og/eller formatteringsproblematik der måtte være en gang for alle, ved ganske enkelt blot at anvende et fælles og maskinelt nemt behandlingsbart talsystem.

Snedigt! 😉

Der er flere der er ramt af andre nye årstals problemer, blandt andet kan nævnes Windows Mobile. Her er problemet at SMS beskeder ankommer i 2010 som om de er sendt i 2016. Det skyldes samme problemstilling bare vendt på hovedet: “10” kommer ind, og behandles hexadecimalt, hvilket giver decimalværdien 16.

Alle SAP systemer er tilsyneladende også ramt af 2010 problemet, det kan man læse mere om her.

Så husk det nu: Enkodning, formattering og valg af datatyper er vigtigt.