Cookies voor statistiek en advertenties
We gebruiken cookies voor statistiek en voor advertenties, allebei naar Google. Weigeren verandert niets aan wat je te zien krijgt.Lees de privacypagina
Plak hexadecimaal in de vorm waarin je het hebt gekopieerd en lees de tekst die eronder zit. Scheidingstekens worden genegeerd, dus een dump uit een logbestand werkt net zo goed als een lijst met komma’s uit broncode. Wat geen geldige UTF-8 vormt, wordt als zodanig gemeld in plaats van in vraagtekens veranderd — dat verschil beslist tussen een antwoord krijgen en een verkeerd antwoord krijgen.
Waar het draait
Er wordt niets geüpload, want er is geen bestand — het wordt in deze pagina uitgerekend.
Geen wachtrij, geen account
Het antwoordt zo snel als je machine kan, en vraagt nooit wie je bent.
Zo vaak als je wilt
Er wordt niets geteld en niets begrensd — nog eens antwoorden kost ons niets.
Spaties, dubbele punten, komma’s, regeleindes en `0x`-voorvoegsels worden eruit gehaald voordat er wordt gelezen. Wat je plakt mag dus uit een netwerkopname komen, uit de uitvoer van OpenSSL of uit de definitie van een array in C, zonder dat je het eerst opschoont.
Wat niet vrijblijvend is, is het aantal cijfers dat overblijft: dat moet even zijn, want een byte is er twee. Een oneven lengte is geen randgeval dat je stilletjes met een nul aanvult — het betekent dat er bij het kopiëren iets is weggevallen, en daarom wordt het gemeld.
Een rij bytes kan net zo goed een PNG, een PDF of een ZIP zijn als een zin. Een PNG begint met `89 50 4e 47`, een PDF met `25 50 44 46`, een ZIP met `50 4b`. Die gegevens als UTF-8 lezen levert vervangingstekens op, of een reeks die technisch klopt en niets betekent.
In plaats van iets terug te geven dat op een resultaat lijkt, wordt hier gezegd dat de bytes geen tekst zijn en hoeveel het er zijn. Dat is het bruikbare antwoord: het sluit de zoektocht naar een coderingsfout die niet bestaat en verlegt de aandacht naar de juiste vraag, namelijk wat voor gegevens het dan wel zijn.
UTF-8 heeft een structuur die met wat oefening te lezen is. Bytes onder `80` zijn ASCII, één teken elk. Een byte tussen `c2` en `df` opent een reeks van twee, tussen `e0` en `ef` een van drie, tussen `f0` en `f4` een van vier, en alle vervolgbytes liggen tussen `80` en `bf`.
Daaruit volgt een bruikbare vuistregel voor Nederlandse gegevens: een `c3` midden in de dump is vrijwel zeker een letter met een trema of een accent, want `c3 ab` is ë, `c3 a9` is é en `c3 af` is ï. En een `e2 82 ac` is het euroteken. Wie een `c3` ziet staan op de plek waar een ë hoort, weet daarmee dat de bytes kloppen en dat het probleem in de weergave zit.
Begint de reeks met `ef bb bf`, dan staat daar een UTF-8-BOM. Hij is onzichtbaar, hoort bij de inhoud, en is de reden dat de eerste kolom van een uit Excel geëxporteerde CSV soms een naam heeft die geen enkel inleesprogramma herkent.
Dezelfde markering kan `fe ff` of `ff fe` zijn bij een andere codering — dan gaat het om UTF-16 en niet om UTF-8, en zijn de bytes hier niet als tekst te lezen. Een `ff fe` aan het begin gevolgd door nullen tussen de letters is de typische signatuur van een bestand uit oudere versies van Kladblok.
Staat er in de dump een `00` tussen elke leesbare byte, dan is de codering UTF-16 en geen UTF-8. `48 00 61 00` is «Ha» in UTF-16 met de minst betekenende byte eerst — dezelfde letters, een andere codering, en als UTF-8 gelezen levert het tekst met stuurtekens ertussen op.
Het komt voor in exports uit het Windows-register, in sommige velden van SQL Server en in alles wat door de Unicode-variant van de Windows-API is gegaan. Het herkennen is eenvoudig zodra je de bytes ziet — en dat is het echte nut van deze pagina tegenover een hulpmiddel dat alleen een antwoord uitspuwt.
Elke rij bytes laat zich als Latin-1 lezen, want daar is elk van de 256 bytes een teken. Een decoder die bij ongeldige UTF-8 stilletjes daarop terugvalt, geeft dus altijd iets terug — en dat iets is onzin bij binaire gegevens, en het bekende gedrocht van vreemde letters bij verkeerd gelezen UTF-8.
Zulke omwegen veranderen een herkenbare fout in een plausibel resultaat, en dat is van de twee de slechtste eigenschap. Hier is er geen tweede codering die stil wordt geprobeerd: het is geldige UTF-8, of je hoort dat het dat niet is en beslist zelf wat dat betekent.
Een veelvoorkomende aanleiding is het vergelijken van twee certificaatvingerafdrukken of twee checksums, waarvan de ene met dubbele punten en in hoofdletters is genoteerd en de andere zonder en in kleine letters. De bytes zijn identiek, de teksten niet, en een tekstvergelijking meldt dus een verschil.
Wie ze allebei door dit veld haalt, ziet meteen of het dezelfde bytes zijn. Zijn ze dat, dan was het een opmaakprobleem; zijn ze het niet, dan verschillen ze werkelijk, en dan is de volgende vraag er een van veiligheid en niet van netheid.
Een hexdump uit Wireshark, uit `xxd` of uit een logbestand heeft doorgaans twee extra kolommen: links een positieaanduiding als `00000000` en rechts de leesbare tekens. Die horen niet bij de gegevens, en als je ze meeplakt, komen er bytes bij die er nooit waren.
De positiekolom is er extra verraderlijk, want die bestaat zelf uit geldige hexcijfers. Kopieer dus alleen de middelste kolom, of controleer of het aantal bytes klopt met wat je verwachtte. Loopt de gedecodeerde tekst na een vast aantal tekens telkens vast, dan is dit vrijwel altijd de oorzaak.
Er is geen uitvoer als bestand. Zijn de bytes een PNG, dan zou deze pagina genoeg informatie hebben om hem als download aan te bieden — en dat gebeurt niet, want het is een andere taak en een waarbij je moet weten wat je doet. Een uitvoerbaar bestand samenstellen uit een dump van vreemde herkomst is geen gebaar dat een teksthulpmiddel er terloops bij hoort te doen.
De grens is dus bewust getrokken bij lezen. Wat je hier krijgt is de tekst, of de mededeling dat het geen tekst is met het aantal bytes erbij. Wie het bestand werkelijk nodig heeft, bouwt het met gereedschap dat daarvoor is gemaakt, waar de stap zichtbaar en opzettelijk is.
Er zit geen automatische herkenning van de codering in. Zulke herkenning werkt op statistiek en is bij korte invoer onbetrouwbaar, en ze vergist zich juist wanneer het ertoe doet: bij een handvol bytes met één afwijkend teken erin.
Wat de pagina in plaats daarvan doet, is zeggen dat het geen UTF-8 is. De beslissing wat het dan wel is, heb jij beter in de hand dan een gok — je weet meestal waar de bytes vandaan komen, en dat is een sterker signaal dan welke heuristiek ook uit de bytes zelf kan halen.
Een hexdump uit een logbestand of een netwerkopname bevat vaak precies wat er werd verstuurd: inloggegevens, sessiesleutels, payloads met namen erin. Omdat er hier op de pagina wordt gedecodeerd, is er geen verstrekking aan ons en dus ook geen verwerking in onze opdracht van die inhoud.
Bij dit soort waarden is dat het beslissende punt. Een opname is per definitie iets dat je niet nog eens naar buiten wilt brengen, en een hulpmiddel dat haar op een vreemde server decodeert heeft haar al gezien. Het netwerktabblad laat zien dat er hier niets vertrekt.
Nee. Spaties, dubbele punten, komma’s, regeleindes en 0x-voorvoegsels worden genegeerd. Een dump uit een netwerkopname werkt net zo goed als een lijst met komma’s uit broncode.
Omdat de bytes geen geldige UTF-8 vormen. Bij binaire gegevens is dat normaal: een PNG, een PDF of een ZIP is geen tekst. Dat wordt uitdrukkelijk gezegd in plaats van iets terug te geven dat op een resultaat lijkt.
Dat de codering UTF-16 is en geen UTF-8. Dat is typisch voor exports uit het Windows-register, voor sommige velden van SQL Server en voor alles wat door de Unicode-variant van de Windows-API is gegaan.
Omdat een byte twee hexadecimale cijfers is, dus een oneven lengte betekent dat er iets ontbreekt. Het alternatief zou zijn er stilletjes een nul bij te zetten, en dat maakt van een kopieerfout een plausibel verkeerd resultaat.
Nee. Er wordt op deze pagina gedecodeerd. Bij dumps telt dat extra, want die bevatten vaak precies wat er werd verstuurd: inloggegevens, sessiesleutels, payloads.