Hex coderen

Hexadecimaal is een manier om bytes op te schrijven, en een byte heeft precies 256 mogelijke waarden, oftewel twee hexadecimale cijfers. Daarom heeft de uitvoer altijd een even aantal cijfers — een oneven lengte is een zeker teken dat er onderweg iets is weggevallen.

Een teken is daarentegen niet noodzakelijk één byte. Een `a` is dat wel, een `ë` twee, een Chinees teken drie en een emoji vier. Wie wil weten hoe lang een tekst in bytes is, ziet dat hier rechtstreeks, en het is regelmatig een stuk meer dan het aantal tekens waarmee een veldgrens is uitgerekend.

Een tekst is een rij tekens; hij wordt pas bytes via een codering. De vraag «welke bytes heeft deze tekst» is dus onvolledig zolang er niet bij staat welke. Hier is dat UTF-8, omdat het web, Linux, macOS, JSON en vrijwel elk modern protocol daarop zijn vastgelegd.

Waar iets anders in het spel is — een oude Windows-codetabel, Latin-1 in een databasekolom — verschillen de bytes, en ze verschillen juist bij de tekens boven ASCII. Een `ë` is `c3 ab` in UTF-8 en de enkele byte `eb` in Latin-1. Komen jouw waarden niet overeen, dan is dat de eerste plek om te kijken.

Dubbele punten tussen de bytes is de vorm waarin OpenSSL certificaatvingerafdrukken afdrukt en waarin MAC-adressen worden gelezen. Spaties is de vorm van een hexdump, zoals `xxd` of een netwerkopname die toont. Zonder scheidingsteken is wat er in een databaseveld, in een configuratieregel of in een hashvergelijking hoort.

In de praktijk hangt de keuze dus af van waar de waarde heen gaat en niet van wat er beter uitziet. Een vergelijking tussen twee vingerafdrukken faalt verrassend vaak alleen omdat de ene met dubbele punten is genoteerd en de andere zonder — de bytes zijn gelijk, de teksten niet.

Voor de waarde van een byte maakt het hoofdlettergebruik niets uit: `ff` en `FF` zijn hetzelfde getal. Voor een tekstvergelijking verandert het alles, dus de vraag houdt op cosmetisch te zijn zodra de waarde wordt vergeleken, gehasht of als sleutel gebruikt.

De conventies lopen uiteen: Unix-gereedschap en de meeste bibliotheken schrijven in kleine letters, Windows-gereedschap en veel certificaatvensters in hoofdletters, en MAC-adressen allebei, afhankelijk van de fabrikant. Wie vergelijkt, normaliseert eerst; en wie een handtekening berekent, moet weten welk hoofdlettergebruik de specificatie vraagt, want anders is de hash een andere.

De serieuste reden om een tekst in hex te bekijken is een vergelijking die faalt terwijl de twee waarden er identiek uitzien. In de byteweergave zie je meteen wat het scherm verbergt: een `c2 a0` van een harde spatie, een `0d` vóór de `0a` van een Windows-regeleinde, een `09` van een tab waar een spatie hoorde te staan.

Even vaak staat er een `ef bb bf` vooraan — de byte order mark die Excel en sommige Windows-editors aan het begin van een bestand zetten. Hij is onzichtbaar, hoort bij de inhoud, en is de reden dat de eerste kolom van een CSV soms een naam heeft die geen enkel programma herkent.

Windows sluit een regel af met `0d 0a`, Unix en macOS met `0a`. Op het scherm zien ze er identiek uit; in de bytes niet — en daarom verschillen de checksums van twee «gelijke» bestanden, wijzen versiebeheersystemen wijzigingen aan op ongewijzigde regels en faalt een vergelijking die triviaal leek.

Op deze pagina zie je het rechtstreeks: plak tekst met een regeleinde erin en kijk of er vóór de `0a` een `0d` staat. Het is de snelste manier om vast te stellen of een van de stappen in de keten de regeleindes heeft herschreven — iets wat Git afhankelijk van de instelling met opzet doet.

Allebei schrijven ze bytes als afdrukbare tekst, en kiezen tussen de twee is kiezen tussen leesbaarheid en omvang. Hexadecimaal heeft twee tekens per byte nodig, dus het dubbele; Base64 heeft ongeveer een derde meer nodig dan de ruwe gegevens en is daarmee flink zuiniger.

Daar staat tegenover dat hexadecimaal zich laat lezen. Je kunt naar een bepaalde byte op een bepaalde plek kijken, twee waarden naast elkaar leggen en het eerste verschil vinden, en de grenzen tussen bytes zijn zichtbaar. In Base64 werkt niets daarvan, want daar smelten drie bytes samen tot vier tekens. Vandaar hex bij hashes en vingerafdrukken, en Base64 bij nuttige gegevens.

Het voorvoegsel `0x` is een conventie uit programmeertalen en zegt tegen de compiler dat de cijfers erachter hexadecimaal gelezen worden. Het hoort vóór één los getal in code, niet vóór elke byte van een reeks: `0x48 0x61` is een lijst van twee getallen, `4861` zijn twee bytes.

Daarom wordt hier geen voorvoegsel gemaakt. De andere richting is ruimhartiger: de decoder op deze site neemt een `0x` vóór elke byte aan, want zulke lijsten uit broncode komen werkelijk binnen. Genereren en aannemen mogen verschillen, en hier doen ze dat met opzet.

Veel protocollen en API’s geven hun grenzen in bytes op terwijl mensen tekens tellen. Een veld dat 64 bytes toestaat, past 64 letters uit het ASCII-bereik maar aanmerkelijk minder Nederlandse tekst met trema’s en accenten erin, en nog veel minder als er emoji in staan.

Deze pagina geeft daar het exacte antwoord op: tel de cijfers en deel door twee. Het is de directe manier om te controleren waarom een naam als «Van Ideeën» net over een grens valt terwijl de teller in het formulier zegt dat het past — en het scheelt een middag zoeken in de verkeerde laag.

Er is bewust geen bestandsinvoer. De hexweergave van een bestand van enige omvang is onwerkbaar in een tabblad — een megabyte levert ruim twee miljoen tekens op — en het gereedschap dat het wél goed doet staat al op je machine: `xxd` op Linux en macOS, `Format-Hex` in PowerShell op Windows.

De vraag die wel in een browser thuishoort, is die over een kort stuk tekst: waarom komen twee waarden niet overeen, wat zit er onzichtbaar in dit veld, hoeveel bytes is deze naam. Dat past in een tekstveld, en het is precies waar deze pagina op is gesneden.

In dit veld belandt meestal juist de waarde die je liever niet verplaatst: een veld uit een record dat zich vreemd gedraagt, een sleutel, een kandidaat-wachtwoord dat je met een checksum wilt vergelijken. Omdat het omzetten op de pagina gebeurt, is er geen verstrekking aan ons.

Het is te controleren in het netwerktabblad: terwijl je het gebruikt vertrekt er geen enkel verzoek dat je invoer draagt. Wat er wel is staat in de privacyverklaring — het bezoek en de advertentie- en statistiekverzoeken. De inhoud van het veld zit daar niet bij, en bij dit soort waarden is dat het enige dat telt.