Welche Unterschiede haben DOCX, XLSX, PPTX, ODT und PDF – und welches Format eignet sich wofür?

Formate und Standards im Vergleich: Open XML (DOCX/XLSX/PPTX), OpenDocument (ODT) und PDF – Struktur, Spezifikationen, Lizenz- und Implementierungsrealität

DOCX, XLSX und PPTX gehören zur Office-Open-XML-Familie (OOXML) und basieren technisch auf ZIP-Containern mit XML-Dateien und ergänzenden Ressourcen (z. B. Medien, Schriftarten, Beziehungen). ODT ist Teil von OpenDocument Format (ODF) und folgt ebenfalls einem ZIP+XML-Containerprinzip, jedoch mit eigener Semantik und Paketstruktur. PDF steht dem als seitenorientiertes Endformat gegenüber: Die primäre Zielsetzung ist visuelle Reproduzierbarkeit, nicht die verlustfreie Bearbeitung in unterschiedlichen Office-Suiten.

Für die Praxis ist weniger die Existenz einer Spezifikation entscheidend als deren Implementierungsrealität. Office-Programme unterstützen Standards häufig in profilierter, teils historisch gewachsener Ausprägung; daneben existieren herstellerspezifische Erweiterungen, Kompatibilitätsoptionen und Fallback-Mechanismen. Daraus ergeben sich messbare Unterschiede bei Roundtrip-Bearbeitung, Langzeitarchivierung und beim Austausch zwischen Plattformen.

Container- und Objektmodell: Was im Dateipaket tatsächlich steckt

OOXML und ODF verpacken mehrere Teil-Dokumente, Metadaten und Binärressourcen in einem Container. Bei OOXML steuern „Relationships“ die Verknüpfung der Teile; Styles, Nummerierungen, Themes und eingebettete Objekte liegen getrennt vor, was technische Verarbeitung (z. B. Extraktion oder DLP-Scanning) erleichtert, zugleich aber Interoperabilitätskanten sichtbar macht, wenn Anwendungen unterschiedliche Teilmengen interpretieren. ODF arbeitet mit einer klaren Trennung aus content.xml, styles.xml und Metadaten, ergänzt um Manifest-Informationen; die Semantik ist stärker auf generische Office-Strukturen ausgerichtet.

PDF ist kein „Office-Dokumentcontainer“ im gleichen Sinn, sondern beschreibt eine feste Seitengeometrie. Text, Vektoren, Rastergrafiken, Transparenzen, Farbprofile und Schriften werden so eingebettet bzw. referenziert, dass die Darstellung reproduzierbar bleibt. Interaktive Elemente wie Formularfelder, Anmerkungen, Ebenen oder eingebettete Dateien können vorhanden sein, sind aber nicht mit der Bearbeitbarkeit eines Office-Quellformats gleichzusetzen.

Spezifikationen, Profile und Normen: Offen heißt nicht automatisch interoperabel

OOXML ist standardisiert (ISO/IEC 29500), ODF ebenfalls (ISO/IEC 26300). In der Praxis wirken jedoch Profile, Kompatibilitätsmodi und anwendungsspezifische Entscheidungen stärker als die Normtexte. Beispiele sind alternative Inhaltsdarstellungen, unterschiedliche Priorisierung von Layouttreue gegenüber semantischer Struktur oder die Frage, wie Änderungsverfolgung, Kommentare, Felder und eingebettete Objekte serialisiert werden. Schon kleine Abweichungen bei Nummerierungslogik, Schriftmetriken oder Absatzabständen können im Roundtrip zwischen Programmen sichtbare Verschiebungen verursachen.

PDF ist als ISO 32000 normiert; für Archivierungszwecke definiert PDF/A (ISO 19005) verbindliche Einschränkungen, etwa beim Umgang mit externen Ressourcen, Transparenzen, Verschlüsselung oder Farbmanagement. PDF/UA (ISO 14289) adressiert Barrierefreiheit über Tags, Strukturbaum und semantische Zuordnung. Damit existieren klare Zielprofile, die bei der Beurteilung von „PDF“ als Austausch- oder Archivformat präziser sind als der bloße Dateiname.

• Norm vs. Anwendung: ISO-Konformität beschreibt einen Spektrumbereich; Interoperabilität hängt davon ab, welche Subsets tatsächlich erzeugt und konsistent interpretiert werden.
• Profile bei PDF: Für Langzeitarchivierung ist ein deklarierter Zielstandard wie PDF/A-2 oder PDF/A-3 relevanter als „PDF“ ohne Profilbindung.
• Layouttreue vs. Semantik: Office-Formate speichern Bearbeitungssemantik (Absätze, Tabellenlogik), PDF priorisiert die Seitenvisualisierung; Rekonstruktion in editierbare Office-Strukturen bleibt grundsätzlich fehleranfällig.

Lizenz- und Implementierungsrealität: Ökosysteme, Erweiterungen, Patentlagen

„Offen“ bezieht sich auf die öffentliche Verfügbarkeit der Spezifikation und deren standardisierte Pflege, nicht automatisch auf identische Feature-Parität in allen Programmen. OOXML ist eng an das Microsoft-Office-Featuremodell gekoppelt; viele Drittanbieter implementieren Kernfunktionen sehr gut, stoßen aber bei Spezialfällen wie SmartArt, komplexen Feldern, bestimmten Diagrammtypen, Shapes, Formularlogik oder proprietären Erweiterungen an Grenzen. ODF ist konzeptionell suite-agnostischer, doch auch hier existieren optionale Elemente und herstellerspezifische Erweiterungen, die sich in der Praxis unterschiedlich verhalten.

Bei PDF bestimmt weniger ein einzelner Hersteller das Format, dennoch prägen Implementierungen die Realität: Viewer, Drucksysteme, Signaturkomponenten und Accessibility-Validatoren interpretieren Grenzfälle teils verschieden. Für Governance ist daher nicht nur die Dateiendung relevant, sondern auch die Frage, welche Erzeugerwerkzeuge zugelassen sind und welche Validierungsregeln (z. B. PDF/A-Konformitätsprüfung) verbindlich gelten.

Praktische Implikationen für Austausch und Archiv: Wahl des „Master“-Formats

Für kollaborative Bearbeitung sollte das Master-Format typischerweise dem primären Bearbeitungswerkzeug entsprechen, weil Rundläufe zwischen Formaten unvermeidlich Funktionsabgleich erfordern. OOXML eignet sich besonders dort, wo die Dokumentlogik stark auf Microsoft-Office-Features aufbaut. ODT bietet Vorteile, wenn ein offener, suiteübergreifender Bearbeitungsstandard mit geringer Bindung an herstellerspezifische Funktionen gefordert ist. PDF ist dagegen als End- und Nachweisformat geeignet, wenn Darstellung, Signaturfähigkeit und reproduzierbarer Druck im Vordergrund stehen.

• Master vs. Derivat: Quellbearbeitung in .docx/.xlsx/.pptx oder .odt, Distribution/Abnahme häufig als .pdf; damit bleibt Bearbeitbarkeit vom Nachweisformat getrennt.
• Interoperabilitätsgrenzen früh testen: Kritische Elemente sind u. a. Änderungsverfolgung, verschachtelte Tabellen, komplexe Absatz-/Listenstile, Diagramme, eingebettete Objekte und Schriftverfügbarkeit.
• Archivierungsprofil festlegen: Für PDF-Archivierung ein Ziel wie PDF/A definieren; für Office-Quellen zusätzlich Metadatenstrategie, Versionsmanagement und reproduzierbare Erzeugung (Schriften, Verknüpfungen, eingebettete Inhalte) absichern.

Kompatibilität und Funktionsverlust bei Konvertierung: Layout, Stile, Tabellen und Formeln, Diagramme, Kommentare/Änderungsverfolgung, eingebettete Objekte, Schriftarten und Medien

Bei der Konvertierung zwischen DOCX, XLSX, PPTX, ODT und PDF entstehen Funktionsverluste selten zufällig, sondern folgen typischen Bruchstellen: Unterschiede in Layout-Engines, abweichende Stilmodelle, inkompatible Objektmodelle (z. B. Zeichnungen, OLE), verschiedene Formel- und Diagramm-Implementierungen sowie uneinheitliche Metadatenmodelle für Kommentare und Änderungsverfolgung. Besonders kritisch sind Konvertierungen, die vom editierbaren Quellformat in ein „fixed layout“-Format (PDF) oder zwischen Open XML und OpenDocument wechseln.

Layout und Paginierung: Umbrüche, Seitenränder, Kopf-/Fußzeilen

Textverarbeitungsformate (DOCX, ODT) speichern Layoutinformationen in unterschiedlichen Strukturen: Absatz- und Abschnittseigenschaften, Seitenformat, Spalten, Fußnoten, Endnoten, Kopf-/Fußzeilen sowie Felder (z. B. Inhaltsverzeichnis) sind jeweils an Engine-spezifische Interpretationen gekoppelt. Beim Import in eine andere Suite treten Abweichungen häufig bei Seitenumbrüchen, Zeilenabständen, Silbentrennung, Textfluss um Grafiken und bei „verankerten“ Objekten auf. Selbst bei korrekter Stilübernahme kann die Paginierung variieren, wenn Schriftmetriken oder Standardwerte für Absatzabstände abweichen.

PDF ist in diesem Kontext primär eine Zielform: Es konserviert visuelles Layout, verliert jedoch semantische Strukturen (z. B. Stilhierarchien) für Weiterbearbeitung. Re-Import von PDF in DOCX/ODT erfolgt über Rekonstruktion und führt typischerweise zu fragmentierten Absätzen, unzuverlässigen Tabellen und neu erzeugten Textboxen.

Stile, Vorlagen und Listen: semantische Struktur vs. optische Nachbildung

DOCX (WordprocessingML) und ODT (OpenDocument Text) besitzen jeweils eigene Stildefinitionen, Vererbungsmodelle und Default-Styles. Konverter bilden Stile häufig „optisch“ nach, statt semantische Beziehungen 1:1 zu übertragen. Sichtbar wird das bei mehrstufigen Nummerierungen, gemischten Absatz-/Zeichenstilen, Tabellenformatvorlagen sowie Dokumentthemen (Farben/Schriften) in DOCX, für die ODT kein identisches Pendant kennt. In Präsentationen treten ähnliche Effekte bei Folienmastern, Layouts und Platzhaltern auf: PPTX-Mastermodelle lassen sich nicht immer verlustfrei in ODP-ähnliche Strukturen überführen; häufig werden Layouts dupliziert oder Platzhalter in normale Textfelder umgewandelt.

Tabellen und Formeln: Zellmodelle, Datentypen, Referenzen

Zwischen XLSX und ODS sind Umrechnungen am fehleranfälligsten, wenn Formeln, Pivot-Logik, Datenmodelle oder moderne Funktionen im Spiel sind. XLSX-Formeln folgen Excel-spezifischen Funktionsnamen, Berechnungsdetails und teils proprietären Erweiterungen (z. B. für dynamische Arrays). ODS speichert Formeln nach OpenFormula, wobei Programme unterschiedlich vollständig implementieren. In der Praxis werden unbekannte Funktionen bei der Konvertierung entweder ersetzt (mit potenziell anderer Semantik), als Text konserviert oder als Ergebniswerte „eingefroren“. Auch Formatierungen sind betroffen: bedingte Formatierung, Datenüberprüfung, benutzerdefinierte Zahlenformate, Datums-/Zeitserialisierung und Lokalisierung (Dezimaltrennzeichen, Funktionsnamen) sind häufige Fehlerquellen.

Diagramme und Visualisierungen: Datenbindung, Achsen, Stilbibliotheken

Diagramme wirken auf den ersten Blick portabel, hängen aber stark von der internen Repräsentation ab. In Office-Formaten (insbesondere XLSX/PPTX) sind Diagramme oft als eigenständige Chart-Objekte mit spezifischer Format- und Datenbindung gespeichert. Beim Wechsel in OpenDocument-Umgebungen werden Diagrammtypen, Achsenskalierungen, Trendlinien, Beschriftungsregeln, sekundäre Achsen, Kombinationsdiagramme und Formatvorlagen nicht immer exakt abgebildet. Häufige Folge ist eine optisch ähnliche Darstellung bei veränderter Semantik (z. B. andere automatische Achsenskalierung) oder das „Flattening“ zu statischen Grafikobjekten, wodurch die Datenbindung verloren geht.

Kommentare und Änderungsverfolgung: Metadatenmodelle, Autorenschaft, Zeitstempel

Kommentarsysteme und Track-Changes-Funktionen sind stark suite-spezifisch. DOCX speichert Änderungsmarken, Autorinformationen und Zeitstempel detailliert; ODT implementiert ebenfalls Änderungsverfolgung, aber nicht jede Markup-Variante ist deckungsgleich. In Konvertierungen gehen deshalb häufig Details verloren: verschachtelte Änderungen, Formatänderungen vs. Textänderungen, Zuordnung von Antworten in Kommentar-Threads oder Zustände wie „akzeptiert/abgelehnt“. Beim Export nach PDF können Kommentare je nach Exportoption als Anmerkungen erscheinen, werden aber oft nicht als editierbares Review-Modell weitergeführt. In Präsentationen sind Kommentare meist besser übertragbar als Änderungsverfolgung, dennoch können Thread-Strukturen, Erwähnungen oder Status-Flags beim Suitewechsel abweichen.

Eingebettete Objekte, Verknüpfungen und Makro-Nähe: OLE, ActiveX, externe Daten

Eingebettete Objekte sind ein Kernrisiko für Funktionsverlust. OLE-Pakete, ActiveX-Steuerelemente, eingebettete Office-Dateien, verknüpfte Diagramme, externe Datenquellen oder eingebettete Medien werden beim Wechsel zwischen Ökosystemen häufig entfernt, in Platzhalter umgewandelt oder als nicht editierbare Vorschau gerendert. Bei Tabellenkalkulationen gilt Ähnliches für Datenverbindungen und Abfragen: Beim Austausch bleiben oft nur Momentaufnahmen (Werte) erhalten. PDF kann eingebettete Dateien oder Rich Media unterstützen, jedoch ist die Interoperabilität zwischen PDF-Viewern uneinheitlich; in vielen Workflows werden solche Inhalte aus Sicherheits- oder Compliance-Gründen deaktiviert.

• Typischer „Flattening“-Effekt: Interaktive oder modellbasierte Elemente werden bei Konvertierung zu statischen Darstellungen (z. B. Diagramm als Bild), wodurch Bearbeitbarkeit und Datenbindung verloren gehen.
• Verknüpfungen als Bruchstelle: Relative Pfade und Netzwerklocations sind zwischen Plattformen instabil; besonders fehleranfällig sind Verweise auf file://-Ressourcen und UNC-Pfade wie \\server\share\....
• Makro-nahe Inhalte: Objekte, die typischerweise mit VBA/Automation zusammenspielen (z. B. Formularsteuerelemente), verlieren beim Wechsel in makroarme Umgebungen häufig ihre Logik, auch wenn die Optik erhalten bleibt.

Schriftarten, Typografie und Medien: Metriken, Einbettung, Codecs

Viele Layoutdifferenzen lassen sich auf Schriftarten zurückführen. Wird eine Schrift nicht gefunden, greifen Substitutionen, deren Metriken (Zeichenbreiten, Kerning, Zeilenhöhe) abweichen; daraus folgen andere Zeilenumbrüche, verschobene Seitenumbrüche und überlaufende Textboxen. DOCX/PPTX können Schriften je nach Erstellung und Einstellungen einbetten; ODT/ODS/ODP unterstützen ebenfalls Font-Einbettung, die tatsächliche Interoperabilität hängt jedoch von Lizenzflags, Programmunterstützung und der Art der Einbettung ab. Für PDF ist Font-Einbettung zentral, um Layouttreue zu sichern; fehlt sie, sind Substitutionsartefakte möglich.

Bei Medien ist die Container-/Codec-Frage entscheidend. PPTX kann Audio/Video einbetten oder verknüpfen; beim Import in andere Suites werden Medien teils neu verpackt oder fallen aus, wenn Codecs nicht unterstützt werden. Ähnlich verhält es sich mit Vektorgrafiken: EMF/WMF sind in Windows-nahen Umgebungen verbreitet, werden aber außerhalb davon teils gerastert oder konvertiert; SVG wird nicht in jeder Office-Anwendung identisch behandelt. In allen Fällen steigt das Risiko, dass Transparenzen, Ebenen oder Farbprofile abweichen.

Makros, Größen- und Versionsgrenzen sowie Langzeitarchivierung: Risikoanalyse, praktische Limits, Abhängigkeiten und Empfehlungen für Austausch und Archivformate (inkl. PDF/A)

Makros: Unterstützung, Sicherheitsmodell und typische Risikopfade

Makros erhöhen die Automatisierbarkeit von Office-Dokumenten, vergrößern aber zugleich die Angriffsfläche. Praktisch relevant ist weniger, ob ein Format theoretisch Makros tragen kann, sondern wie Anwendungen Makrocode signieren, isolieren, blockieren oder beim Austausch stillschweigend entfernen. Bei Open XML wird Makroinhalt in der Regel über makrofähige Container gekapselt (z. B. .docm, .xlsm, .pptm), während .docx/.xlsx/.pptx selbst keine Makros enthalten sollen. OpenDocument sieht Makro-Bindungen vor, die Interoperabilität hängt jedoch stark von der jeweiligen Suite, den Sicherheitseinstellungen und der verwendeten Skriptsprache ab. PDF unterstützt JavaScript in bestimmten Profilen, für Archivzwecke wird es jedoch üblicherweise ausgeschlossen oder deaktiviert.

Risikotreiber sind vor allem eingebettete oder nachgeladene Inhalte, die Ausführung beim Öffnen (oder bei Dokumentereignissen) sowie die Umgehung von Inhaltsfiltern durch Verschleierung. Signaturen verbessern die Nachvollziehbarkeit, ersetzen aber keine restriktive Ausführungspolitik. In Unternehmensumgebungen wird Makroausführung typischerweise über Richtlinien gesteuert, ergänzt um Blocklisten für aus dem Internet stammende Dateien (Mark-of-the-Web) und Zonenlogik.

• Makrofähige Open-XML-Container: .docm, .xlsm, .pptm kapseln VBA-Projekte separat; .docx, .xlsx, .pptx gelten als nicht-makrofähig, auch wenn Exploits andere Inhaltsbestandteile missbrauchen können.
• Typische Angriffskette: Social Engineering + Makroausführung (oder DDE/ActiveX/COM-Automation je nach Anwendung) + Nachladen von Payloads über http(s) oder über Dateifreigaben; die technische Ausprägung ist stark versions- und policy-abhängig.
• Schutzmaßnahmen auf Dokumentebene: Makros signieren, nur signierte Makros zulassen; dokumentierte Trennung von „Austauschformat“ ohne Makros (.docx/.xlsx/.pptx) und „Automationsformat“ mit Makros (.docm/.xlsm/.pptm).
• Schutzmaßnahmen auf Plattformebene: In Windows-Umgebungen sind Zonen-/Herkunftsmarkierungen relevant (z. B. Datei trägt Zone.Identifier); der PowerShell-Befehl Get-Item -Stream Zone.Identifier -Path "C:\Pfad\Datei.docm" kann zur Diagnose dienen.
  Unblock-File -Path "C:\Pfad\Datei.docm" entfernt die Markierung nur nach Risikoabwägung.
• PDF-Sonderfall: Interaktiver Inhalt (z. B. JavaScript, eingebettete Dateien) ist für Langzeitarchivierung in der Regel unerwünscht; für Archivprofile wird auf restriktive Konformität (z. B. PDF/A) gesetzt.

Praktische Größen- und Ressourcenlimits: Was in der Produktion tatsächlich bremst

„Maximale Dateigröße“ ist selten ein harter Standardwert, sondern ergibt sich aus einer Kombination aus Formatgrenzen, Implementierungsdetails, verfügbarem RAM, 32-/64‑Bit-Prozessgrenzen, Grafik-/Medienhandling und Netzwerk- bzw. Cloud-Limits. Bei ZIP-basierten Formaten (Open XML, ODF) können viele eingebettete Objekte, hochauflösende Medien oder umfangreiche Änderungsverfolgung (track changes) Dateien stark aufblähen, während Kompression den Effekt maskiert. Bei Tabellen sind weniger die reinen Zellobergrenzen kritisch als Formeln, Pivot-Caches, bedingte Formatierung, externe Verknüpfungen und Add-ins.

Bei sehr großen Dateien verschieben sich Risiken in Richtung Datenverlust durch Abbrüche bei Cloud-Synchronisation, Timeouts beim Virenscan, Konflikte bei gleichzeitiger Bearbeitung sowie instabile Wiederherstellung nach Abstürzen. Versionierungssysteme für Binärformate liefern zudem schnell unhandliche Deltas; für Nachvollziehbarkeit sind Export-Artefakte (PDF/A) und Metadatenprotokolle häufig robuster als „ewige“ Bearbeitungshistorien innerhalb eines Dokuments.

Versionsabhängigkeiten und Konvertierungsfallen: Format ist nicht gleich Implementierung

Office-Dateiformate sind spezifiziert, die reale Kompatibilität hängt jedoch an Parsern, Rendering-Engines und Feature-Matrizen einzelner Programme. Unterschiede zeigen sich besonders bei Layout (Zeilenumbruch, Silbentrennung, Schriftmetriken), bei Diagrammen, SmartArt-Äquivalenten, Formularfeldern, Inhaltssteuerelementen, Kommentarmodellen sowie bei Makro- und Add-in-Schnittstellen. Selbst innerhalb einer Produktfamilie können Updates das Rendering verändern; für rechtsverbindliche oder archivwürdige Dokumente gilt daher: Darstellung muss von der Bearbeitbarkeit entkoppelt werden.

• DOCX/ODT-Konvertierung: Häufige Verluste betreffen Absatz-/Zeichenstile, Listenebenen, Textfelder, Fußnoten-/Endnotenlayout, Inhaltsverzeichnisse sowie Änderungsverfolgung; bei komplexen Layouts ist ein zusätzlicher PDF-Export zur Sichtprüfung üblich.
• XLSX/ODS-Konvertierung: Unterschiede bei Formelfunktionen, Pivot-Funktionalität, Diagrammdefinitionen, bedingter Formatierung und Makros; für Austausch rechnen viele Workflows mit „Freeze“ auf Werte und statische Diagramme.
• PPTX/ODP-Konvertierung: Übergänge, Animationen, Medien-Codec-Unterstützung und Schrift-Einbettung führen regelmäßig zu Abweichungen; bei Präsentationen ist ein zusätzliches „Handout-PDF“ als Referenz sinnvoll.

Langzeitarchivierung und Austausch: Empfehlungen für Archivformate und PDF/A-Konformität

Für Langzeitarchivierung zählen Reproduzierbarkeit, Standardkonformität, geringe Abhängigkeit von proprietären Renderern sowie kontrollierte Einbettung externer Ressourcen (Schriften, Farbprofile). Bearbeitungsformate (DOCX, ODT, XLSX, ODS, PPTX, ODP) eignen sich für Arbeitsstände, sind aber als alleiniger Archivträger riskant, weil spätere Softwarestände Inhalte anders interpretieren können. PDF/A dient als konservierendes Endformat: Es zielt auf selbstenthaltende Dokumente ohne externe Abhängigkeiten und mit eingeschränkten interaktiven Funktionen. Für strukturierte Daten (z. B. Tabellen als Datenbasis) bleibt zusätzlich ein „Quellformat“ nötig, weil PDF/A primär die Darstellung konserviert.

In der Praxis wird Archivierung als Paket gedacht: (1) editierbare Masterdatei für Nachnutzung, (2) konservierte Sichtfassung als PDF/A, (3) Begleitmetadaten (Erstellsoftware, verwendete Fonts, Prüfsummen) sowie ggf. (4) extrahierte Datenformate wie .csv oder .xml. Bei PDF/A ist eine Validierung mit einem dedizierten Konformitätsprüfer sinnvoll, weil „PDF/A exportieren“ je nach Tool und Einstellungen dennoch zu nicht-konformen Dateien führen kann, etwa durch nicht eingebettete Schriften, verbotene Transparenzen in bestimmten Profilen oder problematische Farbprofile.

• Archivprinzip: Bearbeitungsformat und Archivformat trennen; Masterdatei unverändert aufbewahren, zusätzlich eine PDF/A-Fassung als referenzierbare Darstellung ablegen.
• Makro-Policy für Archive: Makrofähige Dateien (.docm/.xlsm/.pptm) nicht als alleinige Archivgrundlage verwenden; falls fachlich notwendig, Signaturstatus, Hashwerte und Ausführungsrestriktionen dokumentieren.
• Reproduzierbarkeit: Bei layoutkritischen Dokumenten Schriften einbetten (wo zulässig) und Render-Referenz erzeugen; für PDF/A die Einbettung und Farbprofile prüfen lassen.
• Integrität: Prüfsummen pro Datei ablegen (z. B. SHA-256) und bei Migrationen erneut berechnen; dies reduziert das Risiko stiller Korruption in Langzeitspeichern.