Outils de développement · Encodeur et décodeur Base64
URI de données expliqué : comment fonctionne data:image/png;base64 et d'où il vient
· Contexte
base64 codage
Le schéma data: URL a été spécifié dans 1998 comme moyen d'intégrer de petites ressources directement dans une page. Cet article explique sa grammaire, pourquoi Base64 est facultatif et où les navigateurs fixent des limites.
Le favicon qui était une URL de 1,300 caractères — rencontrant une donnée : URI dans la nature et lisant ses parties
Un data: URI intègre une petite ressource directement dans une URL, évitant ainsi une requête HTTP distincte. Le format est spécifié dans la RFC 2397 (défini dans 1998) et utilise une grammaire avec un schéma, un type de média facultatif, un indicateur de codage facultatif et la charge utile elle-même. Par exemple, data:text/plain,hello est un URI de données en texte brut contenant le mot bonjour. Le navigateur traite cela de la même manière qu’une requête HTTP, mais au lieu de récupérer le contenu sur le réseau, il le décode à partir de l’URL elle-même.
Les URI de données sont les plus courants pour les petites images, les icônes CSS et les appareils de test. Un URI data : avec encodage Base64 ressemble à ceci : data:image/png;base64,iVBORw0K.... La répartition est la suivante : data : est le schéma ; image/png est le type de média ; ;base64 est l'indicateur d'encodage ; la longue chaîne correspond aux octets de l'image codés en Base64. Lorsqu'un navigateur voit cette URL, il décode le Base64 pour récupérer les octets d'origine, puis restitue l'image en utilisant ces octets.
Lecture d'un URI de données à partir de sa grammaire visible — type de média, marqueur Base64 facultatif et charge utile
Si l'indicateur d'encodage est omis (data:text/html,<p>hello</p>),, la charge utile est codée en pourcentage en texte UTF-8, et non en base64. La présence de ;base64 indique au navigateur quelle règle de décodage appliquer. Le type de média dans une donnée : URI est un type MIME, la même chaîne de type utilisée dans les en-têtes HTTP Content-Type. image/png, text/plain, application/json et image/svg+xml sont des exemples courants. Si aucun type de média n'est spécifié, la valeur par défaut est text/plain;charset=US-ASCII..
Un navigateur doit déterminer comment restituer les octets en fonction du type de média : s'il indique image/png,, les octets sont PNG ; s'il est indiqué text/html,, le contenu est HTML. Spécifier un mauvais type de support peut produire des résultats confus ; un fichier PNG étiqueté text/plain s'affichera sous forme de caractères inutiles au lieu d'une image. Base64 est facultatif dans un data:URI. Pour le contenu textuel, le codage en pourcentage (le même codage que celui utilisé dans les chaînes de requête URL) est souvent plus compact que la base64. Un consommateur d'URI de données décide comment interpréter la charge utile à partir du type de média et du marqueur avant la virgule. L'encodeur Base64 fournit uniquement les caractères de charge utile. Il n'ajoute pas de type MIME, ne choisit pas si les octets décrivent PNG ou SVG, ni ne valide l'adresse assemblée.
Pourquoi Base64 est facultatif : charges utiles de texte codé en pourcentage pour SVG et texte brut par rapport à Base64 pour binaire
Les données URI :text/html,<p>Hello</p> contiennent le code HTML sous forme de caractères littéraux (avec un codage en pourcentage pour tous les caractères spéciaux tels que des guillemets ou des crochets angulaires). Base64 est utile pour les données binaires qui ne peuvent pas être représentées sous forme de texte et pour les cas où la charge utile contient de nombreux caractères spéciaux que le codage en pourcentage gonflerait. Un petit fichier SVG ou texte peut être codé avec un pourcentage plus petit ; un fichier binaire doit être en base64. Construire une donnée : URI à la main nécessite de connaître le type de média et l'encodage.
Pour une icône SVG, vous pouvez utiliser data:image/svg+xml suivi soit d'un balisage SVG codé en pourcentage, soit d'octets codés en base64 et en base64. Pour l'encodage en pourcentage, enveloppez le SVG dans data:image/svg+xml, puis encodez en pourcentage tous les crochets angulaires, guillemets et autres caractères spéciaux. Le résultat est long mais lisible par l’homme. Pour base64, prenez les octets SVG, encodez-les en base64 et produisez data:image/svg+xml;base64, puis ajoutez la chaîne base64. Base64 est généralement plus compact pour le binaire, mais pour le texte SVG, la forme codée en pourcentage peut être plus courte.
Exemple pratique : création manuelle d'une donnée : URI pour un petit SVG – codage du balisage sous forme de texte et assemblage de la chaîne
Les navigateurs et les applications consommatrices peuvent imposer des limites ou des restrictions de politique sur les URI de données, mais ce référentiel n'établit pas de plafond numérique portable. L'utilisation de la mémoire, le comportement de l'analyseur et la politique de sécurité dépendent également de l'endroit où la valeur apparaît. Testez donc le navigateur cible exact et le contexte d'intégration au lieu de vous fier à une limite mémorisée.
Une image 5 MB intégrée dans chaque fichier HTML augmenterait la taille de la page. Les URI de données conviennent mieux aux petites ressources : icônes CSS, petites images ou données de test. Pour les fichiers volumineux, une requête externe est plus rapide car le navigateur peut mettre en cache la réponse et la réutiliser sur plusieurs pages ; a data : l'URI est intégré à chaque chargement de la page.
Limites de sécurité et du navigateur à vérifier dans l'application consommatrice plutôt que de supposer
Un seuil courant est de quelques kilo-octets ; en dessous, les données : les URI sont efficaces ; au-delà, les fichiers externes sont généralement plus rapides. Les politiques de sécurité et de navigateur restreignent l'utilisation des données : URI dans certains contextes. Une navigation de niveau supérieur (cliquer sur un lien qui pointe vers une donnée : URI avec un contenu HTML) est souvent bloquée pour empêcher le phishing. Un URI data: dans un attribut src de script peut exécuter du JavaScript arbitraire, créant un risque de sécurité.
Les navigateurs appliquent les règles de la politique de sécurité du contenu (CSP) aux données : URI ; un CSP strict peut les interdire complètement. Un URI data: dans un src img ou un src iframe est généralement autorisé, mais l'intégration dans un contexte de style ou de script peut être restreinte. Vérifiez toujours la compatibilité du navigateur et la politique de sécurité de votre environnement cible. Les URI de données en CSS sont courants pour les petites images d'arrière-plan. La syntaxe est la même : url(data:image/png;base64,...).
Où les données : les URI sont toujours le bon outil : icônes CSS, images en ligne sécurisées pour les e-mails et appareils de test
Un fichier CSS avec des données intégrées : les URI peuvent être expédiés sous forme de fichier unique avec toutes les images incluses, réduisant ainsi les requêtes HTTP. Ceci est utile pour les petits jeux d’icônes ou les graphiques simples. Les grandes images intégrées dans CSS gonflent le fichier et ralentissent son analyse. Les outils de construction modernes (comme Webpack) peuvent automatiquement convertir de petites images en données : des URI en CSS et des images externes en URL normales, équilibrant ainsi les performances.
Le format data: URI est défini par RFC 2397, un court document qui spécifie la grammaire mais ne définit pas où les data: URI peuvent ou ne peuvent pas être utilisés. Les fournisseurs de navigateurs ont ajouté leurs propres restrictions en fonction de problèmes de sécurité et de performances.
Ce que ceci ne couvre pas — blob : URL, URL d'objet et accès au système de fichiers
Certains systèmes ont des données obsolètes : prise en charge des URI dans certains contextes (comme form-action au niveau CSP 3) pour éviter les abus. Lorsque vous utilisez un data: URI, testez-le dans votre navigateur cible ; la RFC indique que le format est valide, mais la politique de sécurité du navigateur peut le bloquer.
Création d'une donnée : l'URI manuellement est rare en production ; la plupart des outils de construction et des bibliothèques gèrent la conversion. Mais comprendre le format est utile pour le débogage. Si vous voyez une longue URL data:image/... dans votre CSS ou HTML, vous pouvez la décoder avec l'outil d'encodeur et de décodage Base64 : supprimez le préfixe data:image/...;base64,, collez la chaîne restante dans l'outil et décodez-la pour voir les octets réels.
À retenir : un petit format avec une grammaire stricte – comment l'encodeur et le décodeur Base64 gèrent l'étape d'encodage du texte afin que vous puissiez assembler un URI valide
Pour les données SVG : URI, vous pouvez décoder en pourcentage le formulaire de texte et lire le balisage XML. Comprendre l'anatomie d'une donnée : l'URI facilite le dépannage des ressources intégrées. Les URI de données sont une norme Web (RFC 2397) qui permet d'intégrer des ressources directement sous forme d'URL. Ils sont plus efficaces pour les petites ressources stables qui ne bénéficient pas d’une mise en cache séparée. Le format comprend une spécification facultative du type de média et un indicateur de codage (base64 ou codage en pourcentage implicite).
Le codage Base64 est requis pour les données binaires mais facultatif pour le texte ; Le SVG codé en pourcentage peut être plus lisible. Les politiques de sécurité du navigateur limitent l'endroit où les données : les URI peuvent être utilisées. Il est donc essentiel de comprendre les restrictions de votre environnement cible. L'outil d'encodage et de décodage Base64 peut vous aider à encoder manuellement une ressource ou à décoder un URI intégré pour inspecter son contenu.