Base64, Hex, procentcodering en Base85: kies op transport

Vergelijk byte-overhead, escapes en interoperabiliteit zonder tekstcodering te verwarren met numerieke radix-conversie.

Een codering is alleen nuttig als beide partijen het erover eens zijn. De kleinste weergave is niet noodzakelijkerwijs de beste keuze wanneer de ontvanger een bekend alfabet nodig heeft, de lading door een persoon moet worden getypt of de omringende syntaxis bepaalde tekens speciaal behandelt. Begin met het ontvangstprotocol.

Hex is uitgebreid maar gemakkelijk te inspecteren

Hexadecimaal schrijft elke byte als twee cijfers. De bytereeks FF 00 41 wordt ff0041. Elk paar heeft een zichtbare bytegrens, wat helpt bij het inspecteren van bestandshandtekeningen, checksums en protocolpakketten. Het verdubbelt het aantal tekens, maar het kleine alfabet past meestal gemakkelijk in logs en foutopsporingstools.

Base64 brengt omvang en interoperabiliteit in evenwicht

Base64 vertegenwoordigt drie bytes met vier tekens. Het is gebruikelijk voor binaire velden in op tekst gebaseerde formaten. Standaard Base64 bevat plus en slash; Base64URL vervangt deze tekens wanneer een protocol een ander alfabet nodig heeft. Regels voor opvulling en witruimte vereisen nog overeenstemming. Geen van beide vormen vertelt de ontvanger of de gedecodeerde bytes tekst, een afbeelding of gecomprimeerde inhoud zijn.

Percentagecodering behoort tot de URL-componenten

Percentagecodering schrijft een ontsnapte byte als %HH. Het is niet simpelweg een bulkvervanger voor Base64. De component bepaalt welke tekens moeten worden geëscaped en tekst moet eerst worden gecodeerd als UTF-8. Een schuine streep kan padsegmenten scheiden terwijl een vraagteken een zoekopdracht start; het behandelen van de hele URL als één ondoorzichtige component verandert de betekenis ervan.

console.log(encodeURIComponent('a+b / 中文'));
// a%2Bb%20%2F%20%E4%B8%AD%E6%96%87

Base85 heeft een exacte variant nodig

Veel Base85-schema's vertegenwoordigen vier bytes met vijf tekens, maar hun alfabetten, scheidingstekens en speciale gevallen verschillen. ASCII85 en Z85 kunnen niet als onderling uitwisselbaar worden beschouwd. Z85 stelt ook eisen aan de blokgrootte. Een alfabet met hoge dichtheid kan leestekens bevatten die in het omringende formaat opnieuw moeten worden geëscaped, waardoor het schijnbare voordeel wordt verminderd.

Verwar deze bytecoderingen niet met het converteren van het gehele getal 255 tussen getalbases. Een bestand kan beginnen met nul bytes, terwijl een geheeltallige representatie de voorloopnullen kan weggooien. Een omkeerbare bestandscodec moet definiëren hoe lengte en voorloopnullen behouden blijven.

Gebruik Hex voor byte-inspectie, de gespecificeerde Base64-variant voor interoperabel binair transport, URL-componentcodering voor URL's en een gespecialiseerd schema alleen wanneer beide partijen hetzelfde contract implementeren. Vergelijk de end-to-end-grootte na ontsnappen en compressie. RFC 4648 definieert de standaardfamilies Base16, Base32 en Base64, inclusief hun verschillende alfabetten.