Kies Coderen of Decoderen, kies een schema en klik op de actieknop. Alle verwerking blijft in uw browser.
Wat zijn Base32 en Base58?
Het zijn twee antwoorden op één vraag: een kanaal dat tekst draagt, moet bytes dragen. Base32 en Base58 zijn geen versleuteling en geen hashing — ze verbergen niets en ze verkorten niets. Ze herschrijven een bytereeks met een vaste set leesbare tekens, en wie weet welke set er is gebruikt, kan ze direct terugdraaien. De enige reden om de ene boven de andere te verkiezen, is wat het ontvangende eind met de tekens doet.
Twee families doen die herschrijving op totaal verschillende manieren, en het verschil verklaart bijna elke verrassing op deze pagina:
- Bitpakking — Base32, Base32 Hex, Crockford Base32, z-base-32. De bytes worden in vaste groepen geknipt en elke vijf bits worden één teken. De uitvoerlengte is voorspelbaar uit de invoerlengte, en de laatste, deels gevulde groep wordt ofwel met opvultekens gemarkeerd ofwel kort gelaten.
- Grootgetalconversie — elke Base58-tabel. De hele bytereeks wordt als één enorm getal in grondtal 256 gelezen en daarna in grondtal 58 weer opgeschreven. Er zijn geen groepen en geen opvulling; de lengte deelt op niets, en elke voorloopnulbyte wordt één voorloopnulsymbool.
Waar de zes databits naartoe gaan: Base32 gebruikt vijf bits per teken, dus het heeft acht tekens nodig voor elke vijf invoerbytes — ongeveer 60% groter. Base58 gebruikt ongeveer 5,86 bits per teken, dus het komt uit op ongeveer 37% groter. Base64 past zes bits per teken en komt uit op 33%. Grotere alfabetten zijn korter maar moeilijker hardop voor te lezen, en dat is precies de afweging die elk van hen maakt.
De zeven alfabetten op deze pagina
Elk alfabet wordt volledig afgedrukt in plaats van beschreven, omdat twee hulpmiddelen die verschillende tekens onder dezelfde naam afdrukken het nooit met elkaar eens zullen zijn, wat het label ook zegt. De RFC 4648-rijen zijn normatief; de Crockford- en z-base-32-rijen volgen wat de auteur van het formaat heeft gepubliceerd; de drie Base58-rijen zijn wijdverbreide conventies in plaats van standaarden, en daarom staan ze apart.
Crockford Base32 en het controleteken modulo 37
Het alfabet laat I, L, O en U weg, zodat geen enkel symbool als een ander kan worden gelezen. Wat overblijft is hoofdletterongevoelig bij invoer: i en l worden gelezen als het cijfer 1, o als het cijfer 0, en streepjes bestaan alleen om een lange tekenreeks leesbaarder te maken. Daarbovenop definieert het formaat een optioneel controleteken, dat de waarde van de symboolreeks is, gelezen als getal in grondtal 32, modulo 37, en geschreven met vijf extra symbolen voor de waarden 32 tot 36.
Het controleteken wordt berekend over de tekenreeks van symbolen, niet over de bytes: omdat de encoder de laatste groep met nullen opvult, keert het decoderen van dezelfde tekens altijd terug naar dezelfde waarde. Daarom kan de controlewaarde in de tabel met de hand worden nagerekend uit alleen de gecodeerde kolom. De vijf extra symbolen zijn *, ~, $, = en U voor de waarden 32, 33, 34, 35 en 36, dus een controleteken is niet altijd een cijfer of een letter.
z-base-32
z-base-32 behoudt de vijfbitsgroepering van RFC 4648 Base32 en wijzigt alleen de volgorde van de tweeëndertig tekens. De volgorde is zo gekozen dat de tekens die iemand het vaakst moet opschrijven de tekens zijn die het makkelijkst te schrijven zijn en het moeilijkst te verwarren. Er is geen opvulling, dus een lezer moet weten hoeveel symbolen een waarde zou moeten hebben; dat is de prijs van een formaat dat in de eerste plaats met de hand gelezen moet kunnen worden.
Base58Check: één versiebyte, de payload, vier bytes controlesom
Base58 alleen heeft geen manier om een verkeerd getypte tekenreeks van een juiste te onderscheiden, omdat bijna elke combinatie van zijn achtenvijftig tekens een geldig getal is. Base58Check lost dat op door de data in een omhulsel te zetten: één versiebyte, daarna de payload, en daarna de eerste vier bytes van SHA-256, twee keer achter elkaar toegepast op de eerste twee delen. Een ontvangend programma berekent die vier bytes opnieuw en weigert de tekenreeks wanneer ze verschillen. De versiebyte vertelt een wallet of het een betaaladres, een scriptadres of een privésleutel ziet.
De generator onder de converter neemt de versiebyte en de payload als hexadecimaal en schrijft de Base58Check-tekenreeks; de verifier leest er een in, splitst de vier controlesombytes af, berekent ze opnieuw en meldt zowel de gevonden als de verwachte. Een verkeerde controlesom betekent hier dat de tekenreeks verkeerd is getypt of gewijzigd — het betekent nooit dat de payload zelf verkeerd is, want de payload wordt nooit geïnterpreteerd.
Veelvoorkomende misverstanden
- "Base64 is versleuteling." Nee. Er is geen sleutel en geen geheim; de uitvoer is door iedereen terug te draaien. Base32 en Base58 staan in dezelfde positie, en het door alle drie halen van een waarde voegt ook geen bescherming toe.
- "Een Base58-tekenreeks is een Bitcoin-adres." Alleen als hij ook de Base58Check-controlesom doorstaat en een versiebyte draagt die de ontvangende software herkent. Base58-tekenreeksen komen op veel andere plekken voor, inclusief gewone identificaties zonder enige controlesom.
- "De drie Base58-alfabetten zijn inwisselbaar." Ze gebruiken dezelfde achtenvijftig tekens in drie verschillende volgordes, zodat dezelfde bytes drie verschillende tekenreeksen opleveren. Een hulpmiddel moet weten welke u gebruikt, en deze pagina meldt altijd welke ze gebruikte.
- "Opvulling is onderdeel van de waarde." De
=-tekens markeren alleen de laatste groep. Twee Base32-tekenreeksen die alleen in hun opvulling verschillen, beschrijven dezelfde bytes, en daarom accepteert de decoder een tekenreeks waarvan de opvulling is afgeknipt. - "Elk teken werkt." Elk alfabet is een vaste set. Een teken van buiten de set heeft geen waarde, dus de decoder stopt en noemt het teken en de positie in plaats van te raden.
Vragen die vaak opkomen
Waarom gebruikt Base32 2-7 en niet 0-9? Omdat RFC 4648 het alfabet zo koos dat het binnen de tekens blijft die een domeinnaam mag bevatten, en zodat het makkelijk hardop te lezen is. Base32 Hex gebruikt in plaats daarvan 0-9 A-V wanneer natuurlijke sortering belangrijker is.
Waarom begint een Base58-tekenreeks zo vaak met 1? Elke voorloopnulbyte van de invoer wordt één voorloop-1 (het eerste teken van de Bitcoin- en Flickr-alfabetten). Een versiebyte 0x00 is één nulbyte, dus de meeste mainnet-Bitcoinadressen beginnen met precies één 1.
Wat laadt de knop Voorbeeld? Het voorbeeld dat bij het schema en de richting op het scherm hoort, nooit een vaste tekst. De encoder krijgt de tekst van het eigen voorbeeld van het schema — de RFC 4648-sectie 10-vectoren voor Base32 en Base32 Hex, Crockfords 12345, de z-base-32-rijen die hierboven zijn afgedrukt — en de decoder krijgt de gecodeerde tekenreeks voor het gekozen alfabet, wat het voorbeeld in beide richtingen bruikbaar maakt. De drie Base58-rijen dragen bewust dezelfde tekst, zodat het wisselen van schema en opnieuw drukken op Voorbeeld de drie volgordes van dezelfde achtenvijftig tekens naast elkaar laat zien. Met het aangevinkte Crockford-controleteken krijgt de decoder de waarde met het symbool aan het eind, en dat is de enige manier om te zien dat de verifier er een accepteert.
Stuurt deze pagina mijn gegevens ergens naartoe? Nee. Elke conversie gebeurt in dit browsertabblad, en de pagina bevat geen netwerkaanroepen van welke soort dan ook. Daarom werkt hij ook met het bestand direct vanaf schijf geopend.
Welke moet ik voor een geheim gebruiken? TOTP- en HOTP-authenticatorgeheimen zijn meestal Base32 in het RFC 4648-alfabet, omdat het geheim met de hand moet worden ingetypt. Gebruik de variant die uw ontvangende software vraagt, en vertrouw voor geheimhouding nooit op de codering zelf.
