Encodeur et Décodeur Base58 | Vérification d'adresses Bitcoin et de Base58Check dans le navigateur
Pour habiller un hash hex en adresse P2PKH Bitcoin, vérifier que votre propre implémentation Base58Check correspond à la spécification, ou désosser une clé Solana ou un CIDv0 IPFS afin d'examiner les octets bruts — cet outil encode et décode du Base58 façon Bitcoin avec cinq octets de version préréglés (P2PKH 0x00, P2SH 0x05, WIF 0x80, Testnet P2PKH 0x6f, Testnet P2SH 0xc4) et calcule le verdict du double SHA-256 dans l'onglet, via BigInt et Web Crypto.
💡 À propos de cet outil
L'alphabet Base58 de Bitcoin a été conçu pour rester lisible à la main et à l'œil. Satoshi a écarté quatre caractères — 0, O majuscule, I majuscule et l minuscule — qui se confondent sur un papier froissé, sur un QR mal scanné ou pendant une dictée vocale. Les ponctuations +, / et = ont aussi disparu, ce qui permet d'insérer le résultat dans une URL, un argument de ligne de commande ou un JSON sans aucun échappement.
Base58Check ajoute par-dessus un octet de version en tête et un checksum de quatre octets (les quatre premiers octets de SHA256(SHA256(version || payload))) afin de rejeter une faute de frappe avant qu'elle n'atteigne un portefeuille ou un client RPC. Cette même enveloppe revient dans les adresses Bitcoin mainnet et testnet, les clés privées WIF (Wallet Import Format), les clés publiques Solana (Base58 brut, sans checksum), les CIDv0 IPFS (Qm…) et même les anciens identifiants de photos Flickr.
L'outil sépare les deux flux. L'encodeur prend une chaîne hex d'octets, ajoute facultativement l'octet de version et produit la chaîne Base58 / Base58Check canonique. Le décodeur fait le chemin inverse : il affiche l'octet de version à part, présente le payload en hex et en ASCII imprimable, et indique si le checksum recalculé correspond aux octets collés. Le calcul utilise BigInt et crypto.subtle.digest('SHA-256', …), donc le résultat correspond bit à bit à ce que produisent python-base58, btcutil/base58, rust-bitcoin et bitcoinjs-lib.
Confidentialité : le préréglage WIF (0x80) peut contenir une clé privée. Les octets que vous collez ne sont pas transmis à un serveur — tout le calcul BigInt et SHA-256 a lieu dans la page.
🧐 Questions fréquentes
Q. Quelle est la différence avec Base64 ?
A. Base64 utilise 64 caractères (A-Z a-z 0-9 + / =) ; Base58 retire 0, O, I, l ainsi que la ponctuation, laissant 58. La sortie est environ 4 % plus longue qu'en Base64, mais reste sûre en URL, en copier-coller et lors d'une lecture orale.
Q. Comment se calcule le checksum Base58Check ? A. On concatène l'octet de version et le payload, on applique SHA-256 deux fois, et on prend les quatre premiers octets du second hash. Le décodeur refait le calcul sur les octets qu'il vient d'extraire et compare ses quatre octets avec ceux qu'il a recalculés. Un seul bit modifié change le checksum en profondeur, donc la plupart des fautes de frappe sont rattrapées.
Q. Puis-je traiter Litecoin, Dogecoin, Solana ou IPFS CIDv0 ici ?
A. Les clés Solana et les CIDv0 IPFS sont du Base58 brut — basculer en mode "Base58 brut" rend les octets tels quels. Litecoin (0x30 P2PKH, 0x05/0x32 P2SH) et Dogecoin (0x1e) utilisent Base58Check avec des octets de version qui ne sont pas dans les préréglages ; la solution pragmatique reste d'assembler version + payload + double_sha256(version + payload)[:4] dans votre propre script puis de coller le hex ici en mode Base58 brut pour comparer.
Q. Le verdict affiche "checksum invalide". Que vérifier ?
A. Trois causes habituelles. Un O confondu avec un 0 ou un I avec un l dans la chaîne — Base58 ne définit pas ces caractères et le décodeur s'arrête avant le checksum. Un éditeur ou une messagerie a converti des guillemets typographiques ou des caractères pleine largeur. La chaîne est en fait du Base58 brut (Solana, IPFS CIDv0) lue en mode Base58Check — il suffit de changer de mode.
Q. Pourquoi ma clé WIF décodée fait 33 octets et non 32 ?
A. Les WIF "compressed" ajoutent un octet 0x01 à la fin pour signaler que la clé publique correspondante est compressée. Les WIF "uncompressed" donnent exactement 32 octets. On distingue les deux formes en regardant la longueur du payload hex.
📚 Le saviez-vous
L'alphabet Base58 commence par 1 et non par 0 volontairement. L'encodeur Bitcoin transcrit chaque octet zéro de tête par un 1 littéral, ce qui explique pourquoi les adresses P2PKH mainnet (octet de version 0x00) commencent par 1, les P2SH (0x05) par 3, et les WIF uncompressed (0x80) par 5. Les WIF compressed commencent par K ou L parce que l'octet additionnel 0x01 décale la plage numérique au-delà de 5….
Flickr utilisait un ordre d'alphabet Base58 différent (1…9 a-z A-Z sans exclusions strictes), ce qui rend un lien https://flic.kr/p/2nABcDef incompatible avec le décodeur Bitcoin sans remappage manuel. Solana, Stellar et IPFS, à l'inverse, ont repris l'ordre Bitcoin et partagent donc leurs décodeurs sans conversion — la documentation historique de go-ipfs l'appelle encore l'alphabet "btc".