Base32 / Base58 átalakító

Ezek két válasz ugyanarra a kérdésre: egy szöveget továbbító csatornát bájtok továbbítására kérnek. A Base32 és a Base58 nem titkosítás és nem hashelés — nem rejtenek el semmit, és nem rövidítenek semmit. Egy bájtsort egy rögzített, olvasható karakterkészlettel írnak át, és aki tudja, melyik készletet használták, egyenesen visszaalakíthatja. Az egyik helyett a másik azért választható, amit a fogadó oldal a karakterekkel csinál.

Két család írja át teljesen eltérő módon, és a különbség magyarázza az oldalon szinte minden meglepetést:

• Bitcsomagolás — Base32, Base32 Hex, Crockford Base32, z-base-32. A bájtokat rögzített csoportokra vágják, és minden öt bit egy karaktert ad. A kimenet hossza a bemenet hosszából megjósolható, az utolsó, részben kitöltött csoportot kitöltő karakterekkel jelölik vagy rövidnek hagyják.
• Nagy szám átalakítása — minden Base58-tábla. A teljes bájtsort egyetlen óriási számként olvassák 256-os alapon, majd újra kiírják 58-as alapon. Nincsenek csoportok és nincs kitöltés; a hossz semmibe sem osztható fel, és minden vezető nullabájt egy vezető nulla szimbólummá lesz.

Minden ábécé teljes egészében ki van írva, nem csak leírva, mert két eszköz, amely különböző karaktereket ír ki ugyanazon név alatt, nem fog egyetérteni egymással, bármit is mond a címke. Az RFC 4648 sorok normatívak; a Crockford- és a z-base-32-sorok a formátum szerzője által közzétett változatot követik; a három Base58-sor elterjedt konvenció, nem szabvány, ezért vannak külön felsorolva.

Az ábécé a I, L, O és U karaktereket elhagyja, hogy egyik szimbólum se legyen összetéveszthető egy másikkal. Ami marad, a bemenetnél kis- és nagybetű-érzéketlen: az i és az l az 1 számjegyként olvasódik, az o a 0 számjegyként, a kötőjelek pedig csak a hosszú sztring olvashatóbbá tételére vannak. Ráadásul a formátum egy opcionális ellenőrző szimbólumot határoz meg: a szimbólumsztring értéke mint 32-es alapú szám, modulo 37, és öt további szimbólummal írva a 32-36 értékekhez.

Az ellenőrző szimbólum a szimbólumsztringen számolódik, nem a bájtokon: mivel a kódoló az utolsó csoportot nullákkal bővíti, ugyanazon karakterek dekódolása mindig ugyanabba az értékbe vezet. Ezért a táblázat ellenőrző értéke kézzel is újraszámolható a kódolt oszlopból. A további öt szimbólum: *, ~, $, = és U, a 32, 33, 34, 35 és 36 értékekhez, így az ellenőrző szimbólum nem mindig szám vagy betű.

A z-base-32 megtartja az RFC 4648 Base32 öt bites csomagolását, és csak a harminckét karakter sorrendjét változtatja meg. A sorrendet úgy választották, hogy azok a karakterek, amelyeket az ember a legvalószínűbben leírni kénytelen, a legkönnyebben írhatók és a legkevésbé összetéveszthetők legyenek. Nincs kitöltése, ezért az olvasónak tudnia kell, hány szimbólumot vár egy érték; ez az ára annak, hogy egy elsősorban kézzel olvasásra tervezett formátumról van szó.

A Base58 önmagában nem tudja megkülönböztetni az elgépelt karakterláncot a helyestől, mert ötvennyolc karakterének szinte bármely kombinációja érvényes szám. A Base58Check ezt úgy oldja meg, hogy az adatot egy burokba helyezi: egy verzióbájt, majd a hasznos adat, majd a SHA-256 első négy bájtja, amelyet az első két részre kétszer alkalmaznak egymás után. A fogadó program újraszámolja ezt a négy bájtot, és elutasítja a karakterláncot, ha eltérnek. A verzióbájt mondja meg a tárcának, hogy fizetési címet, szkriptcímet vagy privát kulcsot néz-e.

Az átalakító alatti generátor a verzióbájtot és a hasznos adatot hexadecimálisan veszi, és kiírja a Base58Check-karakterláncot; az ellenőrző visszaolvas egyet, leválasztja a négy ellenőrző-összeg bájtot, újraszámolja azokat, és jelzi mind a talált, mind a várt értéket. Hibás ellenőrző összeg itt azt jelenti, hogy a karakterláncot elgépelték vagy megváltoztatták — soha nem azt, hogy a hasznos adat rossz, mert azt sosem értelmezik.

• "A Base64 titkosítás." Nem. Nincs kulcs és nincs titok; a kimenetet bárki visszafordíthatja. A Base32 és a Base58 ugyanebben a helyzetben van, és ha egy értéket mindhárom formátumon átvisznek, az sem ad védelmet.
• "Egy Base58-karakterlánc Bitcoin-cím." Csak akkor, ha a Base58Check ellenőrző összegén is átmegy, és olyan verzióbájtja van, amelyet a fogadó szoftver felismer. Base58-karakterláncok sok más helyen is megjelennek, köztük olyan egyszerű azonosítókban is, amelyeknek egyáltalán nincs ellenőrző összegük.
• "A három Base58-ábécé felcserélhető." Ugyanazt az ötvennyolc karaktert használják három különböző sorrendben, így ugyanazok a bájtok három különböző karakterláncot adnak. Az eszközt meg kell mondani, melyiket használja, és ez az oldal mindig megmondja, melyiket használta.
• "A kitöltés az érték része." Az = karakterek csak az utolsó csoportot jelölik. Két Base32-karakterlánc, amely csak a kitöltésében tér el, ugyanazokat a bájtokat írja le, ezért a dekódoló a kitöltés nélküli karakterláncot is elfogadja.
• "Bármilyen karakter működik." Minden ábécé rögzített karakterkészlet. A készleten kívüli karakternek nincs értéke, ezért a dekódoló megáll, és megnevezi a karaktert és a helyét, ahelyett hogy találgatna.

Miért használ a Base32 2-7-et, és nem 0-9-et? Mert az RFC 4648 úgy választotta az ábécét, hogy az a tartományneveknél megengedett karakterek között maradjon, és könnyű legyen hangosan felolvasni. A Base32 Hex a 0-9 A-V-t használja helyette, ha a természetes rendezés fontosabb.

Miért kezdődik gyakran egy Base58-karakterlánc 1-gyel? A bemenet minden vezető nullabájtja egy vezető 1-gyé válik (a Bitcoin- és a Flickr-ábécé első karaktere). A 0x00 verzióbájt egy nullabájt, így a legtöbb Bitcoin-főhálózati cím pontosan egy 1-gyel kezdődik.

Mit tölt be a Minta gomb? Az aktuális séma és irány példáját, sosem egy rögzített szöveget. A kódoló a séma saját példájának szövegét kapja — a Base32 és a Base32 Hex esetén az RFC 4648 10. szakasz vektorait, a Crockford 12345-jét, a fent kiírt z-base-32-sorokat — a dekódoló pedig a kiválasztott ábécéhez tartozó kódolt sztringet kapja, ami mindkét irányban használhatóvá teszi a mintát. A három Base58-sor szándékosan ugyanazt a szöveget hordozza, így a séma váltása és a Minta újranyomása egymás mellett mutatja ugyanazon ötvennyolc karakter három sorrendjét. A Crockford ellenőrző szimbólum bejelölésekor a dekódoló a szimbólummal a végén kapja az értéket, ez az egyetlen mód annak látására, hogy az ellenőrző elfogadja.

Elküldi valahová az oldal az adatokat? Nem. Minden átalakítás ebben a böngészőlapon történik, és az oldal semmilyen hálózati hívást nem tartalmaz. Ezért működik akkor is, ha a fájlt közvetlenül a lemezről nyitja meg.

Melyiket használjam titokhoz? A TOTP és HOTP hitelesítő-titkok általában RFC 4648 ábécéjű Base32-ek, mert a titkot kézzel kell beírni. A választás a fogadó szoftvertől függ, és a kódolásról sosem feltételezhető, hogy titkot biztosít.