Une structure XML

SVG se distingue de tous les autres formats présentés sur ce site : il n’est pas binaire, c’est simplement du texte XML. Vous pouvez ouvrir un SVG dans un éditeur de texte et le lire. La suppression des métadonnées en devient conceptuellement plus simple, mais les informations ont aussi davantage d’endroits où se cacher.

Les métadonnées peuvent apparaître sous forme d’éléments dédiés, d’attributs sur n’importe quel élément, de commentaires XML ou d’instructions de traitement. Les éditeurs vectoriels adorent glisser leurs propres données dans les fichiers SVG.

Structure de base d’un SVG

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     width="100" height="100" viewBox="0 0 100 100">

  <!-- Éléments de métadonnées -->
  <title>Mon dessin</title>
  <desc>Créé par Jean Dupont</desc>
  <metadata>
    <rdf:RDF xmlns:rdf="...">
      <!-- Métadonnées RDF/Dublin Core -->
    </rdf:RDF>
  </metadata>

  <!-- Contenu vectoriel -->
  <circle cx="50" cy="50" r="40" fill="red"/>
</svg>

Éléments clés

<svg> : élément racine, avec viewBox et dimensions
xmlns : déclarations d’espaces de noms
<defs> : définitions réutilisables (dégradés, motifs)
<g> : élément de groupement

Éléments de métadonnées

La spécification SVG prévoit plusieurs façons d’attacher des métadonnées, et chaque outil a ses habitudes. Certaines sont évidentes (il existe littéralement un élément <metadata>), d’autres sont plus discrètes.

<metadata>

Conteneur de métadonnées structurées, généralement en RDF/Dublin Core. Peut renfermer le nom du créateur, la date de création, les droits, etc.

<metadata>
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
           xmlns:dc="http://purl.org/dc/elements/1.1/">
    <rdf:Description>
      <dc:creator>Jean Dupont</dc:creator>
      <dc:date>2024-01-15</dc:date>
    </rdf:Description>
  </rdf:RDF>
</metadata>

<title>

Titre lisible du SVG ou de certains éléments. Souvent utilisé pour l’accessibilité, mais il peut révéler la finalité du document.

<desc>

Élément de description. Peut contenir des informations détaillées sur l’image, son créateur ou son usage.

Commentaires XML

 peut contenir des notes de l’auteur, des dates de création, des infos sur le logiciel ou des informations de débogage.

Les espaces de noms des éditeurs

C’est là que le SVG devient brouillon. Chaque éditeur vectoriel ajoute ses propres attributs, sous son espace de noms, pour stocker des fonctions que SVG ne gère pas nativement. Ouvrez un fichier Inkscape et vous verrez des attributs inkscape: et sodipodi: partout. Ce ne sont pas des risques pour la vie privée à proprement parler, mais ils identifient votre logiciel.

inkscape:* / sodipodi:*

Inkscape ajoute des attributs sous espace de noms pour les noms de calques, la position des guides, les réglages du document et l’historique d’édition.

<svg xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
     xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
     inkscape:version="1.2"
     sodipodi:docname="mon-dessin.svg">
  <sodipodi:namedview inkscape:current-layer="layer1"/>
</svg>

Adobe Illustrator

Illustrator intègre de nombreuses métadonnées : numéro de version, réglages des plans de travail et parfois des données AI complètes.

xmlns:i="http://ns.adobe.com/AdobeIllustrator/10.0/"
xmlns:x="http://ns.adobe.com/Extensibility/1.0/"

Sketch / Figma

Les outils de conception modernes peuvent intégrer des noms de calques, des identifiants de composants et des réglages d’export dans des attributs personnalisés.

Instructions de traitement

Les instructions de traitement XML (<?...?>) placées au début des fichiers SVG peuvent identifier le logiciel utilisé.

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="style.css"?>
<!-- Créé avec Inkscape (http://www.inkscape.org/) -->

Conservé ou supprimé

• Déclaration <?xml ...?> : conservée (obligatoire)
• <?xml-stylesheet ...?> : conservée (fonctionnelle)
• Autres instructions de traitement : supprimées

Un traitement fondé sur le DOM

Comme le SVG est du XML valide, nous pouvons l’analyser sous forme d’arbre DOM et retirer chirurgicalement ce qui ne doit pas rester. C’est plus précis que les approches à base d’expressions régulières, et cela ne risque pas de casser du contenu valide.

Analyser le XML

Analyser le SVG comme un document XML, en préservant sa structure

Supprimer les éléments de métadonnées

Supprimer les éléments <metadata>, <title> et <desc>

Retirer les attributs d’éditeur

Supprimer inkscape:*, sodipodi:* et les autres espaces de noms d’éditeurs

Supprimer les commentaires

Retirer tous les commentaires XML du document

Nettoyer les espaces de noms

Supprimer de l’élément racine les déclarations d’espaces de noms inutilisées

Sérialiser

Réécrire le XML nettoyé sous forme de fichier SVG

Récapitulatif du traitement

Conservé

• Tous les graphiques vectoriels (tracés, formes, textes)
• Les styles et le CSS
• Les dégradés et les motifs
• Les filtres et les effets
• Les images intégrées (référencées)
• viewBox et dimensions
• Les espaces de noms SVG standards

Supprimé

• L’élément <metadata>
• L’élément <title>
• L’élément <desc>
• Les commentaires XML
• Les attributs inkscape:*
• Les attributs sodipodi:*
• Les espaces de noms Adobe/Sketch
• Les déclarations d’espaces de noms inutilisées

Images intégrées

Voici un piège qui surprend beaucoup de monde : les fichiers SVG peuvent intégrer des images matricielles sous forme d’URI de données en base64. Ces JPEG ou PNG intégrés peuvent renfermer leurs propres métadonnées EXIF.

Limite actuelle

PicScrub supprime aujourd’hui les métadonnées au niveau du SVG, mais ne décode pas et ne traite pas les images matricielles intégrées :

<image href="data:image/jpeg;base64,/9j/4AAQ..." />

PicScrub ne traite pas actuellement les images matricielles intégrées dans les fichiers SVG. Pour une confidentialité complète, extrayez ces images et traitez-les séparément.

Format SVG