Encodeur/décodeur Base64
Base64 est un schéma d'encodage binaire-texte qui représente des données binaires à l'aide de 64 caractères ASCII. Il est couramment utilisé pour intégrer des données binaires dans des formats texte comme JSON, XML et les URL. Cet outil décode le Base64 pour révéler le contenu original et détecte automatiquement si le résultat est du JSON, du XML ou d'autres formats analysables.
Specifications
Cas d'utilisation courants
- Décoder des charges utiles API et webhooks encodés en Base64
- Inspecter les données encodées dans les jetons JWT
- Décoder les pièces jointes d'e-mails (MIME Base64)
- Déboguer les messages d'erreur et traces de pile encodés
- Visualiser les valeurs de configuration encodées dans les variables d'environnement
Fonctionnalites
- Décoder du Base64 standard en texte UTF-8
- Gérer les variantes Base64 URL-safe (- et _ au lieu de + et /)
- Détection automatique du type de contenu décodé (JSON, XML, etc.)
- Chaînage vers l'analyseur approprié lorsque des données structurées sont détectées
- Encoder du texte en Base64
- Aperçu d'image pour les données binaires d'image décodées
- Visionneuse hexadécimale pour les données binaires non UTF-8
- Badge de détection de format (Standard / URL-Safe / Mixte)
Exemples
Conseils
- Base64 est un encodage, pas un chiffrement. Il n'offre aucune sécurité.
- Le remplissage = à la fin peut être omis dans certaines implémentations.
- Le Base64 URL-safe remplace + par - et / par _ pour éviter les problèmes d'encodage URL.
- Le Base64 augmente la taille des données d'environ 33%.
Comprendre Encodeur/décodeur Base64
Base64 est un schéma d'encodage binaire-texte défini dans la RFC 4648 qui représente des données binaires arbitraires en utilisant 64 caractères ASCII imprimables (A-Z, a-z, 0-9, +, /) plus le caractère de remplissage (=). Son objectif principal est de transporter des données binaires à travers des systèmes basés sur le texte qui peuvent ne pas gérer correctement les octets bruts, tels que les e-mails, les charges utiles JSON, les documents XML et les paramètres URL.
Le processus d'encodage prend chaque groupe de trois octets (24 bits) de l'entrée et les divise en quatre groupes de 6 bits. Chaque valeur de 6 bits correspond à l'un des 64 caractères. Lorsque la longueur de l'entrée n'est pas un multiple de trois octets, un remplissage avec un ou deux caractères = complète la sortie pour atteindre un multiple de quatre caractères. Cela signifie que les données encodées en Base64 sont environ 33% plus grandes que l'original.
Deux variantes principales existent. Le Base64 standard utilise + et / et est utilisé dans l'encodage MIME des e-mails. Le Base64 URL-safe (base64url) remplace + par - et / par _ pour éviter les caractères réservés dans les URL. Les jetons JWT utilisent la variante URL-safe sans remplissage. Certaines implémentations omettent le remplissage final = car la longueur des données originales peut être déduite.
Le Base64 apparaît partout en développement web. Les URI de données intègrent des images et polices dans le HTML/CSS. Les jetons JWT sont trois segments encodés en Base64url. Les messages SAML sont du XML encodé en Base64. Les réponses API peuvent encoder du contenu binaire en Base64 dans du JSON. Il est important de noter que le Base64 est un encodage, pas un chiffrement — il n'offre aucune sécurité ni confidentialité.
Le Base64 n'est pas une forme de chiffrement et ne devrait jamais être traité comme tel. Il transforme les données en une représentation différente sans clé ni secret, et n'importe qui peut décoder une chaîne Base64 instantanément. Si des données sensibles sont encodées en Base64, elles sont complètement exposées. Pour des données qui doivent rester secrètes, utilisez de vrais algorithmes de chiffrement comme AES ou RSA. Le Base64 standard utilise + et / comme caractères 62 et 63, tandis que le Base64 URL-safe (base64url, défini dans la RFC 4648 Section 5) les remplace par - et _ car + et / ont une signification spéciale dans les URL. Les jetons JWT utilisent toujours la variante URL-safe sans remplissage.
Les caractères de remplissage = garantissent que la longueur de la sortie encodée est toujours un multiple de 4 caractères. Puisque le Base64 encode 3 octets en 4 caractères, les entrées dont la longueur n'est pas un multiple de 3 nécessitent un remplissage : 1 octet restant produit ==, et 2 octets restants produisent =. Certaines implémentations, y compris JWT, omettent entièrement le remplissage car le décodeur peut calculer la longueur originale à partir de la longueur de la chaîne encodée.
L'augmentation de taille de 33% est inhérente à l'encodage : chaque 3 octets (24 bits) deviennent 4 caractères ASCII (32 bits), un ratio d'expansion fixe de 4/3 qui ne peut être réduit. Si la taille est une préoccupation, compressez les données avant l'encodage. Pour les gros actifs binaires, envisagez des mécanismes de transfert binaire appropriés comme les uploads multipart ou les trames WebSocket binaires plutôt que d'intégrer du Base64 dans des formats texte.