Détecteur/convertisseur d'encodage et de base

Collez une chaîne et cet outil classe les encodages/formats probables (base64, hex, JWT, GUID, hash, JSON, YAML, etc.), avec des aperçus de décodage sûrs.

Chargement de la simulation interactive...

La détection annonce un pourcentage parce que la certitude n’est pas disponible 🖖

Chaque chiffre hexadécimal — 0 à 9 et a à f — est aussi un caractère Base64 légal, donc toute chaîne hexadécimale dont la longueur se divise par quatre est également une chaîne Base64 syntaxiquement valide. Aucun examen de l’alphabet ne peut séparer les deux, et c’est pourquoi cet outil vous donne un score de confiance plutôt qu’un verdict. Ce qui tranche vraiment, c’est la structure et le sens : le remplissage, l’arithmétique de la longueur, et le fait que le décodage produise ou non quelque chose de sensé. L’échantillon base64Json est le cas propre — il se décode en {"name":"Spock","role":"scientist","active":true}, et une hypothèse qui donne du JSON valide a presque certainement raison.

Encoder n'est pas chiffrer 🖖

Quand une chaîne paraît brouillée, on est tenté d'y voir un secret à percer. Pourtant, la plupart des textes opaques sont seulement remodelés, pas cachés : Base64 et hexadécimal sont entièrement réversibles, un GUID n'est qu'une étiquette unique, et un hachage comme SHA-256 est une empreinte à sens unique qu'on ne peut jamais reconvertir en sa donnée d'origine. Cet outil range les chaînes dans ces catégories pour que vous sachiez si le décodage est seulement possible.

Base64 agrandit les données, il ne les réduit pas 🖖

On confond souvent Base64 avec de la compression, alors qu'il fait l'inverse : chaque 3 octets (24 bits) devient 4 caractères imprimables, gonflant les données d'environ 33%, des signes = complétant le dernier groupe. Il existe pour une raison historique : les premiers courriels (MIME sur SMTP 7 bits) ne pouvaient pas transporter de binaire brut, si bien que les pièces jointes devaient être réexprimées avec un alphabet sûr de 64 caractères. Cet héritage explique pourquoi les images circulent encore aujourd'hui sous forme de texte gonflé dans des URL data:.

Problèmes entièrement résolus

Passer à 68 caractères depuis une charge utile JSON ASCII de 49 caractères et inversement 5 étapes
L'entrée est eyJuYW1lIjoiU3BvY2siLCJyb2xlIjoic2NpZW50aXN0IiwiYWN0aXZlIjp0cnVlfQ==, et le contenu utile sous-jacent est le JSON ASCII de 49 caractères {"name":"Spock","role":"scientist","active":true}. Le panneau affiche 68 pour Caractères et 68 pour Octets. Arrivez à 68 à partir de 49 sans compter la chaîne encodée — puis faites le chemin inverse.
1. Le Base64 est un changement de base, pas un chiffrement. 64 = 2⁶, donc chaque caractère de sortie transporte 6 bits ; 3 octets d'entrée transportent 24 bits ; et 6 divise 24 exactement. C'est tout le format : 3 octets en entrée, 4 caractères en sortie, sans reste.
  
  $2^{24} = 6 4^{4} ⟹ L = 4 ⌈ \frac{n}{3} ⌉$
2. 49 octets représentent 16 triplets complets et 1 octet restant. Les triplets sont la partie facile — 16 × 4 = 64 caractères, chacun d'eux transportant 6 bits complets.
  
  $n = 49 = 3 \times 16 + 1 ⟹ 16 \times 4 = 64$
3. L'octet orphelin est la source du remplissage. 8 bits n'est pas un multiple de 6, il est donc complété par 4 bits à zéro pour faire 12, ce qui donne 2 caractères, et 2 signes '=' complètent le quatuor. 64 + 2 + 2 = 68. Chaque '=' marque une position de caractère qui ne possédait pas de bits propres.
  
  $8 bits + 4 12 = 2 \times 6, p = 2 ⟹ L = 64 + 2 + 2 = 68$
4. Les deux lignes du panneau indiquent 68, et cette concordance ne dit rien sur cette chaîne. L'alphabet base64 étant ASCII, chaque caractère émis vaut exactement 1 octet ; la ligne Octets suivrait la ligne Caractères pour n'importe quelle entrée en base64.
  
  $S = L = 68 (ASCII)$
5. Maintenant, faites le chemin inverse. 68 ÷ 4 = 17 quatuors, 17 × 3 = 51 emplacements d'octets, moins les 2 emplacements que le remplissage indique comme vides : 49. Vous venez de retrouver la taille du contenu utile sans en décoder le moindre octet.
  
  $n = \frac{3 L}{4} - p = \frac{3 \times 68}{4} - 2 = 51 - 2 = 49$
Réponse

68 caractères pour 49 octets, et ce sont les signes '=' qui permettent de relire directement 49 depuis l'enveloppe. Cette inversion est la moitié utile. La longueur d'une chaîne base64 dépend de la longueur de son contenu utile et de rien d'autre, de sorte que vous pouvez déclarer la taille exacte de quelque chose qu'il ne vous est pas permis d'ouvrir — ce qui est une affirmation plus forte que n'importe quel détecteur de cette page ne fait sur le contenu. L'autre moitié est l'addition. 4 caractères pour 3 octets ne s'améliore jamais, donc le base64 coûte 4/3 à la limite : un fichier de 1 MiB arrive sous forme de 1 398 104 caractères, soit 341 KiB de pur emballage. Cette chaîne fait pire, à 68/49 = 1,388, car les 2 caractères de remplissage sont un surcoût fixe et 49 octets est bien trop court pour l'amortir.

$\frac{L}{n} = \frac{68}{49} = 1.388 ⟶ \frac{4}{3}, 2^{20} B \Rightarrow L = 1398104$
Bits aléatoires dans un GUID/UUID v4 et identifiants générés avant une répétition 6 étapes
L'entrée est 550e8400-e29b-41d4-a716-446655440000, que le panneau qualifie de GUID/UUID v4 tout en proposant de le décoder en Base64URL. Calculez combien de ses bits ont réellement été choisis au hasard, et combien de tels identifiants peuvent être générés avant qu'une répétition cesse d'être improbable.
1. Comptons d'abord la forme : 8-4-4-4-12 chiffres hexadécimaux avec 4 traits d'union entre les groupes, soit 32 + 4 = 36 caractères, et la ligne Octets correspond à 36 car les chiffres hexadécimaux et les traits d'union sont tous en ASCII. Remarquez ce que valent ces 4 traits d'union. Situés à des positions fixes, ils transportent 0 bit.
  
  $L = 32 8 + 4 + 4 + 4 + 12 + 4 = 36 = S$
2. Chaque chiffre hexadécimal vaut 4 bits, donc les 32 qui comptent en contiennent 128. C'est le nombre habituellement cité pour un UUID, et pour cette chaîne, il est trop élevé.
  
  $32 \times 4 = 128 bits$
3. Le 13e chiffre et le 17e chiffre en sont la raison. Le 13e chiffre est 4, et il s'agit du champ de version — un UUID de version 4 est tenu d'y placer un 4, donc ces 4 bits n'ont jamais été un choix. Le 17e chiffre est 'a', qui vaut 1010 en binaire, et ses 2 bits de poids fort sont l'étiquette de variante, fixée à 10. 6 bits consacrés à nommer le format laissent 122.
  
  $d_{13} = 4 (4 bits), d_{17} = a = 101 0_{2} (2 bits) ⟹ 128 - 6 = 122$
4. L'espace est donc de 2¹²², soit environ 5,32 × 10³⁶ — et non les 3,40 × 10³⁸ que 128 bits auraient donnés.
  
  $N = 2^{122} = 5.32 \times 1 0^{36} (2^{128} = 3.40 \times 1 0^{38})$
5. Les répétitions suivent la règle des anniversaires plutôt que la taille de l'espace. En tirant n identifiants au hasard, la probabilité qu'une paire corresponde croît comme n²/(2N), et en fixant cela à 0,5, on obtient n = 1,177√N. Le décompte varie comme la racine carrée, c'est pourquoi les 6 bits perdus à l'étape 3 coûtent un facteur 8 et non un facteur 64.
  
  $1 - e^{- n^{2} /2 N} = 0.5 ⟹ n = 2 N ln 2 = 1.177 N$
6. √N vaut 2,31 × 10¹⁸, donc n ressort à 2,7 × 10¹⁸.
  
  $n = 1.177 \times 2.31 \times 1 0^{18} = 2.7 \times 1 0^{18}$
Réponse

122 bits, et 2,7 × 10¹⁸ UUID avant que la probabilité d'une répétition n'atteigne 0,5. Générés à raison de 10⁹ par seconde, cela représente 86 ans, et c'est tout l'argument en faveur de laisser chaque machine générer les siens sans registre ni coordination — pas un protocole, juste un nombre trop grand pour être atteint. Mettez cela en regard du premier problème et le contraste résume la raison d'être de cette page. Le Base64 compacte 6 bits dans chaque caractère ; cette chaîne consacre 36 caractères à 122 bits, soit 3,4 bits chacun, de sorte que le même identifiant tiendrait dans 21 caractères base64url. Les 15 autres achètent la lisibilité, pas l'information. Et le décodage Base64URL proposé par le panneau revient signalé comme binaire plutôt que texte pour la raison la plus simple qui soit : rien n'y a jamais été encodé.

$n_{1/2} = 1.177 2^{122} = 2.7 \times 1 0^{18}, ⌈ \frac{122}{6} ⌉ = 21$

Références (1)

The alphabets and padding rules the detector reasons about, normatively: S. Josefsson, "The Base16, Base32, and Base64 Data Encodings." RFC 4648, IETF, 2006.

Par l’équipe 42Math · Mis à jour 2026-05-23

Vérifié sur des sources publiées. Corrections bienvenues. Politique éditoriale · Corrections

Toutes les leçons : Informatique →

Exemples de problèmes

json en base64 - Une charge utile en Base64 se décode en texte JSON structuré.
texte en hex - Une charge utile hexadécimale se décode en message UTF-8 lisible.
token de type JWT - Un jeton de type JWT expose des sections d'en-tête et de charge utile en base64url.
guid/uuid - Un GUID/UUID est détecté comme identifiant, et non comme texte chiffré déchiffrable.
hash sha-256 - Une empreinte de la longueur d'un hachage indique probablement un condensé SHA-256.
type yaml - Une structure de type YAML est identifiée grâce à l'indentation des paires clé-valeur et des listes.
manifeste HLS (m3u8) - Une playlist HLS — manifeste M3U8 détecté à 100%, #EXT-X-KEY signale un DRM SAMPLE-AES
manifeste MPEG-DASH (MPD) - Un manifeste DASH — MPD MPEG-DASH avec descripteurs Widevine et PlayReady, et XML à 92%
markdown - Un document Markdown — titres, puces et un lien, détecté à 100%, rien à décoder
latex - Un fichier source LaTeX — \documentclass et un bloc d’environnement, détecté à 100%