Struktura XML

SVG odstaje od wszystkich innych formatów na tej stronie, bo nie jest binarny: to zwykły tekst XML. Możesz otworzyć plik SVG w edytorze tekstu i po prostu go przeczytać. Usuwanie metadanych jest przez to prostsze w teorii, ale za to jest więcej miejsc, w których informacje mogą się schować.

Metadane mogą występować jako osobne elementy, atrybuty przy dowolnym elemencie, komentarze XML albo instrukcje przetwarzania. Edytory wektorowe uwielbiają upychać w plikach SVG własne dane.

Podstawowa struktura 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">

  <!-- Elementy z metadanymi -->
  <title>Mój rysunek</title>
  <desc>Autor: Jan Kowalski</desc>
  <metadata>
    <rdf:RDF xmlns:rdf="...">
      <!-- Metadane RDF/Dublin Core -->
    </rdf:RDF>
  </metadata>

  <!-- Treść wektorowa -->
  <circle cx="50" cy="50" r="40" fill="red"/>
</svg>

Najważniejsze elementy

<svg>:element główny z viewBox i wymiarami
xmlns:deklaracje przestrzeni nazw
<defs>:definicje wielokrotnego użytku (gradienty, wzory)
<g>:element grupujący

Elementy z metadanymi

Specyfikacja SVG opisuje kilka sposobów dołączania metadanych, a każde narzędzie robi to inaczej. Niektóre są oczywiste (jest dosłownie element <metadata>), inne mniej rzucają się w oczy.

<metadata>

Pojemnik na uporządkowane metadane, zwykle RDF/Dublin Core. Może zawierać nazwisko twórcy, datę utworzenia, informacje o prawach i wiele więcej.

<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>Jan Kowalski</dc:creator>
      <dc:date>2024-01-15</dc:date>
    </rdf:Description>
  </rdf:RDF>
</metadata>

<title>

Czytelny tytuł całego pliku SVG albo pojedynczych elementów. Często służy dostępności, ale może zdradzić przeznaczenie dokumentu.

<desc>

Element opisu. Może zawierać szczegółowe informacje o obrazie, jego twórcy albo przeznaczeniu.

Komentarze XML

 może zawierać notatki autora, daty utworzenia, nazwę programu albo informacje diagnostyczne.

Przestrzenie nazw edytorów

Tu SVG robi się nieporządny. Każdy edytor wektorowy dodaje własne atrybuty w swojej przestrzeni nazw, żeby zapisać funkcje, których SVG nie obsługuje natywnie. Otwórz plik z Inkscape, a zobaczysz wszędzie atrybuty inkscape: i sodipodi:. Same w sobie nie są zagrożeniem dla prywatności, ale zdradzają, jakiego programu używasz.

inkscape:* / sodipodi:*

Inkscape dodaje własne atrybuty z nazwami warstw, pozycjami prowadnic, ustawieniami dokumentu i historią edycji.

<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="moj-rysunek.svg">
  <sodipodi:namedview inkscape:current-layer="layer1"/>
</svg>

Adobe Illustrator

Illustrator zapisuje sporo metadanych: wersję programu, ustawienia obszarów roboczych, a czasem całe dane w formacie AI.

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

Sketch / Figma

Nowoczesne narzędzia projektowe potrafią zapisać we własnych atrybutach nazwy warstw, identyfikatory komponentów i ustawienia eksportu.

Instrukcje przetwarzania

Instrukcje przetwarzania XML (<?...?>) na początku plików SVG mogą zdradzać, w jakim programie powstał plik.

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

Co zostaje, a co znika

• deklaracja <?xml ...?>:zostaje (wymagana)
• <?xml-stylesheet ...?>:zostaje (funkcjonalna)
• pozostałe instrukcje przetwarzania:usuwane

Przetwarzanie oparte na DOM

Ponieważ SVG jest poprawnym XML-em, możemy wczytać go do drzewa DOM i chirurgicznie usunąć to, czego nie chcemy. To dokładniejsze niż podejście oparte na wyrażeniach regularnych i nie zepsuje przypadkiem poprawnej treści.

Wczytanie XML

Wczytanie SVG jako dokumentu XML, z zachowaniem struktury

Usunięcie elementów z metadanymi

Skasowanie elementów <metadata>, <title> i <desc>

Usunięcie atrybutów edytorów

Skasowanie atrybutów inkscape:*, sodipodi:* i innych przestrzeni nazw edytorów

Usunięcie komentarzy

Wycięcie wszystkich komentarzy XML z dokumentu

Uporządkowanie przestrzeni nazw

Usunięcie nieużywanych deklaracji przestrzeni nazw z elementu głównego

Serializacja

Zapis wyczyszczonego XML z powrotem jako pliku SVG

Podsumowanie przetwarzania

Co zostaje

• cała grafika wektorowa (ścieżki, kształty, tekst)
• style i CSS
• gradienty i wzory
• filtry i efekty
• osadzone obrazy (do których są odwołania)
• viewBox i wymiary
• standardowe przestrzenie nazw SVG

Co usuwamy

• element <metadata>
• element <title>
• element <desc>
• komentarze XML
• atrybuty inkscape:*
• atrybuty sodipodi:*
• przestrzenie nazw Adobe i Sketcha
• nieużywane deklaracje przestrzeni nazw

Osadzone obrazy

Jest tu pułapka, która zaskakuje wiele osób: pliki SVG mogą osadzać obrazy rastrowe jako data URI w base64. Takie osadzone pliki JPEG albo PNG mogą mieć w środku własne metadane EXIF.

Obecne ograniczenie

PicScrub usuwa dziś metadane z poziomu samego SVG, ale nie dekoduje i nie przetwarza osadzonych obrazów rastrowych:

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

PicScrub obecnie nie przetwarza obrazów rastrowych osadzonych w plikach SVG. Dla pełnej prywatności wyodrębnij takie obrazy i wyczyść je osobno.

Format SVG