Serialisierung

In der Informatik bezeichnet Serialisierung ( in Python auch Pickling genannt ) den Prozess, eine Datenstruktur oder einen Objektzustand in ein Format zu übersetzen, das gespeichert (z. B. Dateien auf Speichermedien, Datenpuffer auf Speichermedien) oder übertragen (z. B. Datenströme über Computernetzwerke) und später (möglicherweise in einer anderen Computerumgebung) wiederhergestellt werden kann . [ 1 ] Wenn die resultierende Bitfolge gemäß dem Serialisierungsformat ^{erneut gelesen wird} , kann daraus eine semantisch identische Kopie des ursprünglichen Objekts erstellt werden. Bei vielen komplexen Objekten, insbesondere solchen, die viele Referenzen verwenden , ist dieser Prozess nicht trivial. Die Serialisierung von Objekten umfasst keine ihrer zuvor verknüpften Methoden .

Dieser Prozess der Serialisierung eines Objekts wird in manchen Fällen auch als Marshalling bezeichnet. ^{[ 2 ] [ 3 ] [ 4 ]} Die umgekehrte Operation, das Extrahieren einer Datenstruktur aus einer Folge von Bytes, ist die Deserialisierung (auch Unserialisierung oder Unmarshalling genannt ).

In der Hardware von Netzwerkgeräten wird der Teil, der für die Serialisierung und Deserialisierung zuständig ist, üblicherweise als SerDes bezeichnet .

Anwendungsgebiete der Serialisierung sind unter anderem:

• Übertragung über Leitungen und Netzwerke ( Messaging ).
• Daten speichern (in Datenbanken , auf Festplatten ).
• Remote Procedure Calls , z. B. wie bei SOAP .
• Verteilung von Objekten, insbesondere in der komponentenorientierten Softwareentwicklung wie COM , CORBA usw.
• Erkennung von Veränderungen in zeitlich veränderlichen Daten.

Damit einige dieser Funktionen nützlich sind, muss die Architekturunabhängigkeit gewahrt bleiben. Beispielsweise sollte ein Computer mit einer anderen Hardwarearchitektur für eine optimale Nutzung der Verteilung einen serialisierten Datenstrom unabhängig von der Byte-Reihenfolge zuverlässig rekonstruieren können . Das bedeutet, dass das einfachere und schnellere Verfahren des direkten Kopierens des Speicherlayouts der Datenstruktur nicht für alle Architekturen zuverlässig funktioniert. Die Serialisierung der Datenstruktur in einem architekturunabhängigen Format vermeidet Probleme mit der Byte-Reihenfolge , dem Speicherlayout oder einfach unterschiedlichen Darstellungsweisen von Datenstrukturen in verschiedenen Programmiersprachen .

Jedem Serialisierungsverfahren ist inhärent, dass die Datenkodierung per Definition seriell ist. Um einen Teil der serialisierten Datenstruktur zu extrahieren, muss daher das gesamte Objekt von Anfang bis Ende gelesen und rekonstruiert werden. In vielen Anwendungen ist diese Linearität von Vorteil, da sie die Verwendung einfacher, gängiger E/A-Schnittstellen zum Speichern und Weitergeben des Objektzustands ermöglicht. Bei Anwendungen, in denen höhere Leistung wichtig ist, kann es sinnvoll sein, mehr Aufwand in eine komplexere, nichtlineare Speicherorganisation zu investieren.

Selbst auf einem einzelnen Rechner sind primitive Zeigerobjekte zu instabil, um sie zu speichern, da die Objekte, auf die sie verweisen, an einer anderen Speicheradresse neu geladen werden können. Um dies zu verhindern, beinhaltet der Serialisierungsprozess einen Schritt namens Unswizzling (auch Zeiger-Unswizzling genannt) , bei dem direkte Zeigerreferenzen in Referenzen basierend auf Name oder Position umgewandelt werden. Der Deserialisierungsprozess beinhaltet einen umgekehrten Schritt, das sogenannte Zeiger-Swizzling .

Da Serialisierung und Deserialisierung durch gemeinsamen Code gesteuert werden können (z. B. durch die Serialize- Funktion in Microsoft Foundation Classes ), kann dieser Code beides gleichzeitig ausführen und somit 1) Unterschiede zwischen den serialisierten Objekten und ihren vorherigen Kopien erkennen und 2) die Eingabe für die nächste Erkennung bereitstellen. Es ist nicht notwendig, die vorherige Kopie tatsächlich zu erstellen, da Unterschiede dynamisch erkannt werden können – eine Technik, die als differentielle Ausführung bezeichnet wird. Dies ist nützlich für die Programmierung von Benutzeroberflächen mit zeitlich veränderlichen Inhalten: Grafische Objekte können erstellt, entfernt, geändert oder zur Verarbeitung von Eingabeereignissen angepasst werden, ohne dass dafür separater Code geschrieben werden muss.

Die Serialisierung durchbricht die Undurchsichtigkeit eines abstrakten Datentyps , indem sie potenziell private Implementierungsdetails offenlegt. Triviale Implementierungen, die alle Datenmember serialisieren, können die Kapselung verletzen . ^{[ 5 ]}

Um Konkurrenten von der Entwicklung kompatibler Produkte abzuhalten, halten Hersteller proprietärer Software die Details ihrer Serialisierungsformate oft geheim . Manche verschleiern oder verschlüsseln die serialisierten Daten sogar absichtlich. Interoperabilität erfordert jedoch, dass Anwendungen die Serialisierungsformate anderer Anwendungen verstehen können. Daher definieren Architekturen für Remote Method Calls wie CORBA ihre Serialisierungsformate detailliert.

Viele Institutionen, wie Archive und Bibliotheken, versuchen, ihre Backup- Archive – insbesondere Datenbank-Dumps – zukunftssicher zu gestalten , indem sie diese in einem relativ für Menschen lesbaren, serialisierten Format speichern.

Die Courier-Technologie von Xerox Network Systems beeinflusste Anfang der 1980er Jahre den ersten weit verbreiteten Standard. Sun Microsystems veröffentlichte 1987 die External Data Representation (XDR). ^{[ 6 ]} XDR ist ein offenes Format und wurde von der IETF als STD 67 (RFC 4506) standardisiert .

Ende der 1990er-Jahre wurde die Entwicklung einer Alternative zu den Standard-Serialisierungsprotokollen vorangetrieben: XML , eine Teilmenge von SGML , wurde verwendet, um eine für Menschen lesbare, textbasierte Kodierung zu erzeugen . Eine solche Kodierung eignet sich für persistente Objekte, die von Menschen gelesen und verstanden oder unabhängig von der Programmiersprache an andere Systeme übertragen werden können. Sie hat den Nachteil, dass die kompaktere, bytebasierte Kodierung verloren geht. Da jedoch zu diesem Zeitpunkt größere Speicher- und Übertragungskapazitäten zur Verfügung standen, spielte die Dateigröße eine geringere Rolle als in den Anfängen der Computertechnik. In den 2000er-Jahren wurde XML häufig für die asynchrone Übertragung strukturierter Daten zwischen Client und Server in Ajax- Webanwendungen eingesetzt. XML ist ein offenes Format und als W3C-Empfehlung standardisiert.

JSON ist eine leichtgewichtige Alternative zu XML im Klartextformat und wird häufig für die Client-Server-Kommunikation in Webanwendungen verwendet. JSON basiert auf der JavaScript-Syntax , ist aber unabhängig von JavaScript und wird von vielen anderen Programmiersprachen unterstützt. JSON ist als STD 90 ( RFC  8259 ), ECMA-404 und ISO/IEC 21778:2017 standardisiert .

YAML ist eine strikte Obermenge von JSON und beinhaltet zusätzliche Funktionen wie Datentyp-Tags, Unterstützung für zyklische Datenstrukturen, einrückungssensitive Syntax und verschiedene Formen der skalaren Datenkennzeichnung. YAML ist ein offenes Format.

Eigenschaftslisten werden von den Frameworks NeXTSTEP , GNUstep , macOS und iOS zur Serialisierung verwendet . Der Begriff „Eigenschaftsliste“ oder kurz „p-Liste“ bezeichnet kein einheitliches Serialisierungsformat, sondern verschiedene Varianten, darunter lesbare und binäre.

Für große Mengen wissenschaftlicher Datensätze, wie Satellitendaten und Ergebnisse numerischer Klima-, Wetter- oder Ozeanmodelle, wurden spezifische binäre Serialisierungsstandards entwickelt, z. B. HDF , netCDF und das ältere GRIB .

Mehrere objektorientierte Programmiersprachen unterstützen die Objektserialisierung (oder Objektarchivierung ) direkt, entweder durch syntaktischen Zucker oder durch eine standardisierte Schnittstelle . Zu diesen Sprachen gehören Ruby , Smalltalk , Python , PHP , Objective-C , Delphi , Java und die .NET- Sprachfamilie. Darüber hinaus gibt es Bibliotheken, die Serialisierungsfunktionen für Sprachen bereitstellen, die diese nicht nativ unterstützen.

C und C++ bieten keine Serialisierung als explizites High-Level-Konstrukt, unterstützen aber beide Sprachen das Schreiben aller integrierten Datentypen sowie einfacher Datenstrukturen als Binärdaten. Daher ist es in der Regel trivial, eigene Serialisierungsfunktionen zu schreiben. Darüber hinaus können Compiler-basierte Lösungen wie das ODB ORM- System für C++ und das gSOAP- Toolkit für C und C++ automatisch Serialisierungscode mit wenigen oder gar keinen Änderungen an den Klassendeklarationen generieren. Weitere gängige Serialisierungs-Frameworks sind Boost.Serialization ^{[ 7 ]} aus dem Boost Framework , das S11n-Framework ^{[ 8 ]} und Cereal ^{[ 9 ]} . Das MFC-Framework (Microsoft) bietet ebenfalls eine Serialisierungsmethodik als Teil seiner Document-View-Architektur.

Mit der Einführung der reflexiven Programmierung in C++26 wurde die Serialisierung erheblich vereinfacht. Reflexion ermöglicht die Serialisierung von beispielsweise JSON zur Kompilierzeit in ein Objekt structmit entsprechender Struktur. ^{[ 10 ]}

CFML ermöglicht die Serialisierung von Datenstrukturen in WDDX mit dem <cfwddx>Tag und in JSON mit der Funktion SerializeJSON() .

Delphi bietet einen integrierten Mechanismus zur Serialisierung von Komponenten (auch persistente Objekte genannt), der vollständig in die IDE integriert ist . Der Inhalt der Komponente wird in einer DFM-Datei gespeichert und bei Bedarf neu geladen.

Go unterstützt nativ das Unmarshalling/Marshalling von JSON- und XML- Daten. ^{[ 11 ]} Es gibt auch Drittanbietermodule, die YAML ^{[ 12 ]} und Protocol Buffers ^{[ 13 ]} unterstützen . Go unterstützt außerdem Gobs . ^{[ 14 ]}

In Haskell wird Serialisierung für Typen unterstützt, die Mitglieder der Typklassen `Read` und `Show` sind . Jeder Typ einer Readdieser Klassen definiert eine Funktion, die die Daten aus der String-Repräsentation der ausgegebenen Daten extrahiert. Die Typklasse Showselbst enthält die showFunktion, mit der eine String-Repräsentation des Objekts generiert werden kann. Der Programmierer muss die Funktionen nicht explizit definieren – die Deklaration eines Typs als Ableitung von `Read` oder `Show` (oder beider) genügt, damit der Compiler in vielen Fällen die passenden Funktionen generiert (jedoch nicht in allen: Funktionstypen können beispielsweise nicht automatisch von `Show` oder `Read` ableiten). Die automatisch generierte Instanz von `Show` erzeugt ebenfalls gültigen Quellcode, sodass derselbe Haskell-Wert generiert werden kann, indem der von `show` erzeugte Code beispielsweise in einem Haskell-Interpreter ausgeführt wird. ^{[ 15 ]} Für eine effizientere Serialisierung gibt es Haskell-Bibliotheken, die eine Hochgeschwindigkeitsserialisierung im Binärformat ermöglichen, z. B. ` binary` .

Java bietet automatische Serialisierung, die die Implementierung des Interfaces ` serialize` erfordert . Die Implementierung dieses Interfaces kennzeichnet die Klasse als serialisierbar, und Java übernimmt die Serialisierung intern. Das Interface selbst definiert keine Serialisierungsmethoden, aber eine serialisierbare Klasse kann optional Methoden mit bestimmten Namen und Signaturen definieren, die, falls definiert, im Rahmen der Serialisierung/Deserialisierung aufgerufen werden. Die Sprache erlaubt es Entwicklern außerdem, den Serialisierungsprozess durch die Implementierung eines weiteren Interfaces, des Interfaces `serialize` , genauer zu überschreiben. Dieses Interface enthält zwei spezielle Methoden zum Speichern und Wiederherstellen des Objektzustands. Es gibt drei Hauptgründe, warum Objekte nicht standardmäßig serialisierbar sind und das Interface `serialize` implementieren müssen, um auf Javas Serialisierungsmechanismus zugreifen zu können. Erstens erfassen nicht alle Objekte in einem serialisierten Zustand sinnvolle Semantik. Beispielsweise ist ein Objekt an den Zustand der aktuellen JVM gebunden . Es gibt keinen Kontext, in dem ein deserialisiertes Objekt sinnvolle Semantik beibehalten würde. Zweitens ist der serialisierte Zustand eines Objekts Teil des Kompatibilitätsvertrags seiner Klasse. Die Aufrechterhaltung der Kompatibilität zwischen Versionen serialisierbarer Klassen erfordert zusätzlichen Aufwand und sorgfältige Überlegung. Daher sollte die Serialisierbarkeit einer Klasse eine bewusste Designentscheidung und keine Standardeinstellung sein. Die Serialisierung ermöglicht zudem den Zugriff auf nicht- transiente private Klassenmember, die sonst nicht zugänglich wären. Klassen mit sensiblen Informationen (z. B. Passwörtern) sollten weder serialisierbar noch externalisierbar sein. ^{[ 16 ] : 339–345.} Die Standardkodierungsmethode verwendet eine rekursive, graphenbasierte Übersetzung des Klassendeskriptors und der serialisierbaren Felder des Objekts in einen Bytestrom. Primitive Datentypen sowie nicht-transiente, nicht-statische referenzierte Objekte werden in den Strom kodiert. Jedes Objekt, auf das das serialisierte Objekt über ein nicht als serialisierbar markiertes Feld verweist, muss ebenfalls serialisiert werden. Ist ein Objekt im vollständigen Graphen der nicht-transienten Objektreferenzen nicht serialisierbar, schlägt die Serialisierung fehl. Der Entwickler kann dieses Verhalten beeinflussen, indem er Objekte als transient kennzeichnet oder die Serialisierung eines Objekts so umdefiniert, dass ein Teil des Referenzgraphen abgeschnitten und nicht serialisiert wird. Java verwendet keinen Konstruktor zur Serialisierung von Objekten. Es ist möglich, Java-Objekte über JDBC zu serialisieren und in einer Datenbank zu speichern. ^{[ 17 ]} Während Swingjava.io.SerializableSerializableExternalizableSerializableThreadThreadtransientKomponenten implementieren zwar die Serializable-Schnittstelle, ihre Portabilität zwischen verschiedenen Versionen der Java Virtual Machine ist jedoch nicht garantiert. Daher kann eine Swing-Komponente oder eine davon abgeleitete Komponente zwar in einen Byte-Stream serialisiert werden, es ist aber nicht gewährleistet, dass dieser auf einem anderen Rechner wiederhergestellt werden kann.

Seit ECMAScript 5.1 ^{[ 18 ]} enthält JavaScript das integrierte JSONObjekt `JSON` und seine Methoden JSON.parse(). JSON.stringify()Obwohl JSON ursprünglich auf einer Teilmenge von JavaScript basiert ^{[ 19 ]} , gibt es Grenzfälle, in denen JSON kein gültiges JavaScript ist. Insbesondere erlaubt JSON die Verwendung der Unicode-Zeilenumbrüche U+2028 LINE SEPARATOR und U+2029 PARAGRAPH SEPARATOR ohne Maskierung in Zeichenketten, während ECMAScript 2018 und ältere Versionen dies nicht zulassen. ^{[ 20 ] [ 21 ]} Siehe den Hauptartikel zu JSON .

Julia implementiert die Serialisierung über die serialize()/ deserialize()Module ^{[ 22 ]} , die für die Verwendung innerhalb derselben Julia-Version und/oder Instanz desselben Systemabbilds vorgesehen sind. ^{[ 23 ]} Das HDF5.jlPaket bietet eine stabilere Alternative durch die Verwendung eines dokumentierten Formats und einer gemeinsamen Bibliothek mit Wrappern für verschiedene Sprachen ^{[ 24 ]} , während das Standard-Serialisierungsformat vermutlich eher auf maximale Leistung bei der Netzwerkkommunikation ausgelegt ist. ^{[ 25 ]}

Im Allgemeinen kann eine Lisp -Datenstruktur mit den Funktionen `print read()` und `read() print` serialisiert werden. Eine Variable `foo`, die beispielsweise eine Liste von Arrays enthält, wird mit `print (print foo)()` ausgegeben. Ebenso kann ein Objekt aus einem Datenstrom namens `s` mit `read()` gelesen werden (read s). Diese beiden Teile der Lisp-Implementierung werden Drucker und Leser genannt. Die Ausgabe von `print( print)` ist lesbar; sie verwendet Listen, die durch Klammern abgegrenzt sind, zum Beispiel: `(a, b)` . In vielen Lisp-Varianten, einschließlich Common Lisp , kann der Drucker nicht jeden Datentyp darstellen, da dies nicht eindeutig definiert ist. In Common Lisp kann der Drucker beispielsweise keine CLOS-Objekte ausgeben. Stattdessen kann der Programmierer eine Methode für die generische Funktion `print()` schreiben , die beim Ausgeben des Objekts aufgerufen wird. Dies ähnelt der Methode in Ruby. Lisp-Code selbst wird in der Syntax des Lesers geschrieben, der sogenannten Lesesyntax. Die meisten Sprachen verwenden separate Parser für Code und Daten, Lisp hingegen nur einen. Eine Datei mit Lisp-Code kann als Datenstruktur in den Speicher eingelesen, von einem anderen Programm transformiert und anschließend ausgeführt oder ausgegeben werden, beispielsweise in einer Lese-Auswertungs-Ausgabe-Schleife . Nicht alle Lese-/Schreibprogramme unterstützen zyklische, rekursive oder gemeinsam genutzte Strukturen. (42.9"x"y)print-object

.NET verfügt über mehrere von Microsoft entwickelte Serialisierer . Darüber hinaus existieren zahlreiche Serialisierer von Drittanbietern. Mehr als ein Dutzend Serialisierer werden hier (archiviert am 08.05.2015 in der Wayback Machine) ^{[ 26 ]} und hier ^{[ 27 ]} diskutiert und getestet .

Die OCaml -Standardbibliothek bietet Marshalling über das MarshalModul ^{[ 3 ]} und die Pervasives-Funktionen output_value. input_valueObwohl OCaml statisch typgeprüft ist, Marshalkann die Verwendung des Moduls die Typgarantien verletzen, da nicht überprüft werden kann, ob ein deserialisierter Datenstrom Objekte des erwarteten Typs repräsentiert. In OCaml ist es schwierig, eine Funktion oder eine Datenstruktur, die eine Funktion enthält (z. B. ein Objekt mit einer Methode), zu marshallen, da ausführbarer Code in Funktionen nicht zwischen verschiedenen Programmen übertragen werden kann. (Es gibt zwar ein Flag, um die Codeposition einer Funktion zu marshallen, aber sie kann nur innerhalb desselben Programms deserialisiert werden.) Die Standard-Marshalling-Funktionen können gemeinsam genutzte Daten erhalten und zyklische Daten verarbeiten, was über ein Flag konfiguriert werden kann.

Mehrere Perl- Module, die über CPAN verfügbar sind, bieten Serialisierungsmechanismen, darunter `storable` Storable, ` storable` JSON::XSund `storable` FreezeThaw. `storable` enthält Funktionen zum Serialisieren und Deserialisieren von Perl-Datenstrukturen in und aus Dateien oder Perl-Skalaren. Neben der direkten Serialisierung in Dateien Storablebietet `storable` die freezeFunktion `serialize`, die eine serialisierte Kopie der in einen Skalar gepackten Daten zurückgibt, sowie thawdie Funktion `deserialize`, die einen solchen Skalar deserialisiert. Dies ist nützlich, um komplexe Datenstrukturen über einen Netzwerk-Socket zu senden oder in einer Datenbank zu speichern. Bei der Serialisierung von Strukturen mit Storable`storable` gibt es netzwerksichere Funktionen, die die Daten stets in einem Format speichern, das auf jedem Computer lesbar ist, allerdings mit geringem Geschwindigkeitsverlust. Diese Funktionen heißen `serialize` nstore, nfreeze`deserialize` usw. Es gibt keine „n“-Funktionen zum Deserialisieren dieser Strukturen – die regulären ` thawstorable`- und retrieve`deserialize`-Funktionen serialisieren Strukturen mit den „n n“-Funktionen und ihren maschinenspezifischen Entsprechungen.

PHP implementierte die Serialisierung ursprünglich über die eingebauten Funktionen `serialize` serialize()und unserialize()`serialize`. ^{[ 28 ]} PHP kann alle seine Datentypen außer Ressourcen (Dateizeiger, Sockets usw.) serialisieren. Die eingebaute unserialize()Funktion `serialize` ist oft gefährlich, wenn sie auf völlig ungesicherte Daten angewendet wird. ^{[ 29 ]} Für Objekte gibt es zwei „ magische Methoden“, die innerhalb einer Klasse implementiert werden können – `serialize` __sleep()und `deserialize` –, die von `serialize` bzw. `deserialize` __wakeup() aufgerufen werden und ein Objekt bereinigen bzw. wiederherstellen können. Beispielsweise kann es wünschenswert sein, eine Datenbankverbindung bei der Serialisierung zu schließen und bei der Deserialisierung wiederherzustellen; diese Funktionalität wird durch diese beiden magischen Methoden abgedeckt. Sie ermöglichen es dem Objekt außerdem, die zu serialisierenden Eigenschaften auszuwählen. Seit PHP 5.1 gibt es einen objektorientierten Serialisierungsmechanismus für Objekte, das Interface `serialize`. ^{[ 30 ]}serialize()unserialize()Serializable

Die Termstruktur von Prolog , die einzige Datenstruktur der Sprache, kann mittels des eingebauten Prädikats `serialize` ausgegeben write_term/3und mittels der eingebauten Prädikate `serialize` read/1und `serialize` wieder eingelesen werden read_term/2. Der resultierende Datenstrom ist unkomprimierter Text (in einer durch die Konfiguration des Zieldatenstroms festgelegten Kodierung), wobei freie Variablen im Term durch Platzhaltervariablennamen repräsentiert werden. Das Prädikat `serialize` write_term/3ist in der ISO-Spezifikation für Prolog (ISO/IEC 13211-1) ab Seite 59 standardisiert („Schreiben eines Terms, § 7.10.5“). Daher ist zu erwarten, dass Terme, die von einer Implementierung ausgegeben wurden, von einer anderen Implementierung ohne Mehrdeutigkeiten oder Überraschungen serialisiert werden können. In der Praxis können implementierungsspezifische Erweiterungen (z. B. die Wörterbücher von SWI-Prolog) nicht standardisierte Termstrukturen verwenden, sodass die Interoperabilität in Grenzfällen beeinträchtigt sein kann. Beispiele hierfür finden sich in den entsprechenden Handbuchseiten für SWI-Prolog ^{[ 31 ]} , SICStus Prolog ^{[ 32 ]} und GNU Prolog. ^{[ 33 ]} Ob und wie serialisierte Terme, die über das Netzwerk empfangen werden, anhand einer Spezifikation überprüft werden (nach der Deserialisierung aus dem Zeichenstrom), obliegt dem Implementierer. Die in Prolog integrierten Definite Clause Grammars können in diesem Schritt angewendet werden.

Der zentrale allgemeine Serialisierungsmechanismus ist das pickleStandardbibliotheksmodul Pickle, das sich an den Begriff „Pickling“ aus Datenbanksystemen ^{[ 34 ] [ 35 ] [ 36 ]} anlehnt und die Datenserialisierung ( bzw. das Entpacken zur Deserialisierung ) beschreibt . Pickle verwendet eine einfache, stackbasierte virtuelle Maschine , die die Anweisungen zur Rekonstruktion des Objekts aufzeichnet. Es handelt sich um ein versionsübergreifend anpassbares , aber unsicheres Serialisierungsformat (nicht sicher gegen fehlerhafte oder bösartige Daten). Fehlerhafte oder bösartig erzeugte Daten können dazu führen, dass der Deserialisierer beliebige Module importiert und beliebige Objekte instanziiert. ^{[ 37 ] [ 38 ]} Die Standardbibliothek enthält außerdem Module zur Serialisierung in Standarddatenformate: json(mit integrierter Unterstützung für grundlegende Skalar- und Sammlungstypen und der Möglichkeit, beliebige Typen über Kodierungs- und Dekodierungs-Hooks zu unterstützen ), plistlib(mit Unterstützung für binäre und XML- Eigenschaftslisten ) xdrlibund (mit Unterstützung für den External Data Representation (XDR)-Standard gemäß RFC 1014). Abschließend wird empfohlen, dass ein Objekt __repr__in der richtigen Umgebung auswertbar ist, was eine grobe Übereinstimmung mit Common Lisps `pickle` ermöglicht print-object. Nicht alle Objekttypen können automatisch serialisiert werden, insbesondere solche, die Betriebssystemressourcen wie Dateihandles enthalten . Benutzer können jedoch benutzerdefinierte Reduktions- und Konstruktionsfunktionen registrieren, um das Serialisieren und Deserialisieren beliebiger Typen zu unterstützen. Pickle wurde ursprünglich als reines Python- pickleModul implementiert, aber in Python-Versionen vor 3.0 cPicklebietet das Modul `pickle` (ebenfalls ein integriertes Modul) eine verbesserte Leistung (bis zu 1000-mal schneller ^{[ 37 ]} ). Dieses Modul cPicklewurde vom Unladen Swallow -Projekt adaptiert. In Python 3 sollten Benutzer immer die Standardversion importieren, die versucht, die beschleunigte Version zu importieren und bei Bedarf auf die reine Python-Version zurückgreift. ^{[ 39 ]}

R verfügt über eine Funktion dput, die eine ASCII-Textdarstellung eines R-Objekts in eine Datei oder Verbindung schreibt. Eine solche Darstellung kann mit `read()` aus einer Datei gelesen werden dget. ^{[ 40 ]} Genauer gesagt serializeserialisiert die Funktion ein R-Objekt in eine Verbindung, wobei die Ausgabe ein roher Vektor im Hexadezimalformat ist. Die unserializeFunktion ermöglicht das Lesen eines Objekts aus einer Verbindung oder einem rohen Vektor. ^{[ 41 ]}

REBOL serialisiert in eine Datei ( save/all) oder in ein string!( ). Zeichenketten und Dateien können mithilfe der polymorphen Funktion mold/alldeserialisiert werden . bietet sprachübergreifende Datenserialisierung in R unter Verwendung von Protocol Buffers . ^{[ 42 ]}loadRProtoBuf

Ruby enthält das Standardmodul Marshalmit zwei Methoden dump, loadähnlich den Unix-Dienstprogrammen `std::serialize` dumpund restore`std::resolve`. Diese Methoden serialisieren Daten in die Standardklasse `Object` String, d. h. sie werden zu einer Bytefolge. Einige Objekte können nicht serialisiert werden (dies würde eine TypeErrorAusnahme auslösen): Bindungen, Prozedurobjekte, Instanzen der Klasse `IO`, Singleton-Objekte und Schnittstellen. Benötigt eine Klasse eine benutzerdefinierte Serialisierung (z. B. für bestimmte Aufräumaktionen beim Sichern/Wiederherstellen), kann dies durch die Implementierung der beiden Methoden `std::resolve` _dumpund `std::resolve` erreicht werden _load. Die Instanzmethode_dump sollte ein Objekt zurückgeben, Stringdas alle Informationen enthält, die zur Wiederherstellung von Objekten dieser Klasse und aller referenzierten Objekte bis zu einer maximalen Tiefe (definiert als Integer-Parameter) erforderlich sind (der Wert -1 deaktiviert die Tiefenprüfung). Die Klassenmethode_load sollte ein Objekt vom Typ `Object` entgegennehmen Stringund ein Objekt dieser Klasse zurückgeben.

Serdeist die am weitesten verbreitete Bibliothek bzw. das am häufigsten verwendete Crate für die Serialisierung in Rust , die die Traits Serializeund bereitstellt .Deserialize

storeOn:Im Allgemeinen können nicht-rekursive und nicht-teilende Objekte mithilfe des / readFrom:-Protokolls in lesbarer Form gespeichert und abgerufen werden . Die storeOn:Methode generiert den Text eines Smalltalk-Ausdrucks, der – bei Auswertung mit readFrom:– das ursprüngliche Objekt wiederherstellt. Dieses Schema ist insofern besonders, als es eine prozedurale Beschreibung des Objekts und nicht die Daten selbst verwendet. Es ist daher sehr flexibel und ermöglicht Klassen, kompaktere Darstellungen zu definieren. In seiner ursprünglichen Form verarbeitet es jedoch keine zyklischen Datenstrukturen und erhält die Identität gemeinsam genutzter Referenzen nicht (d. h. zwei Referenzen auf ein einzelnes Objekt werden als Referenzen auf zwei gleiche, aber nicht identische Kopien wiederhergestellt). Hierfür existieren verschiedene portable und nicht-portable Alternativen. Einige davon sind spezifisch für eine bestimmte Smalltalk-Implementierung oder Klassenbibliothek. In Squeak Smalltalk gibt es mehrere Möglichkeiten , Objekte zu serialisieren und zu speichern. Die einfachsten und gebräuchlichsten sind storeOn:/readFrom:binäre Speicherformate, die auf SmartRefStreamSerialisierern basieren. Darüber hinaus können gebündelte Objekte mit gespeichert und abgerufen werden ImageSegments. Beide bieten ein sogenanntes „Framework zur Speicherung binärer Objekte“, das die Serialisierung und den Abruf in kompakter Binärform unterstützt. Beide verarbeiten zyklische, rekursive und gemeinsam genutzte Strukturen, speichern und rufen Informationen zu Klassen und Metaklassen ab und beinhalten Mechanismen zur dynamischen Objektmigration (d. h. zur Konvertierung von Instanzen, die von einer älteren Version einer Klasse mit einem anderen Objektlayout erstellt wurden). Die APIs (storeBinary/readBinary) sind ähnlich, die Kodierungsdetails jedoch unterschiedlich, was die beiden Formate inkompatibel macht. Der Smalltalk/X-Code ist jedoch Open Source und kostenlos und kann in andere Smalltalk-Implementierungen geladen werden, um den dialektübergreifenden Austausch von Objekten zu ermöglichen. Die Objektserialisierung ist nicht Teil der ANSI-Smalltalk-Spezifikation. Daher variiert der Code zur Serialisierung eines Objekts je nach Smalltalk-Implementierung. Auch die resultierenden Binärdaten variieren. Beispielsweise kann ein in Squeak Smalltalk erstelltes serialisiertes Objekt nicht in Ambrai Smalltalk wiederhergestellt werden . Folglich können verschiedene Anwendungen, die mit mehreren Smalltalk-Implementierungen arbeiten und auf Objektserialisierung angewiesen sind, keine Daten zwischen diesen verschiedenen Implementierungen austauschen. Zu diesen Anwendungen gehören die Objektdatenbank MinneStore ^{[ 43 ]} und einige RPC- Pakete. Eine Lösung für dieses Problem bietet SIXX ^{[ 44 ]} , ein Paket für verschiedene Smalltalk-Varianten, das ein XML- basiertes Format für die Serialisierung verwendet.

Die Swift -Standardbibliothek stellt zwei Protokolle bereit: `serialize` Encodableund Decodable`deserialize` (zusammengesetzt als `serialize` Codable), die es ermöglichen, Instanzen konformer Typen in JSON , Eigenschaftslisten oder andere Formate zu serialisieren bzw. zu deserialisieren. ^{[ 45 ]} Standardimplementierungen dieser Protokolle können vom Compiler für Typen generiert werden, deren gespeicherte Eigenschaften ebenfalls vom Typ `JSON` Decodableoder `JSON` sind Encodable.

PowerShell implementiert die Serialisierung mithilfe des integrierten Cmdlets ` serialize` Export-CliXML. Export-CliXMLDieses serialisiert .NET-Objekte und speichert das resultierende XML in einer Datei. Um die Objekte wiederherzustellen, verwenden Sie das Import-CliXMLCmdlet `deserialize`, das aus dem XML in der exportierten Datei ein deserialisiertes Objekt generiert. Deserialisierte Objekte, oft auch als „Eigenschaftspakete“ bezeichnet, sind keine dynamischen Objekte; sie stellen Momentaufnahmen dar, die Eigenschaften, aber keine Methoden enthalten. Zweidimensionale Datenstrukturen können mithilfe der integrierten Cmdlets `serialize` und `deserialize` auch im CSV- Format serialisiert bzw. deserialisiert werden . Import-CSVExport-CSV

• Kommutierung (Telemetrie)
• Vergleich von Datenserialisierungsformaten
• Containerformat
• Hibernate (Java)
• XML-Schema
• Grundlegende Kodierungsregeln
• Google Protocol Buffers
• Wikibase
• Apache Avro

• Java-Objektserialisierungsdokumentation
• Java 1.4 Objektserialisierungsdokumentation .
• Durable Java: Serialisierung ( Archiviert am 25. November 2005 in der Wayback Machine)
• XML-Datenbindungsressourcen
• Databoard – Binäre Serialisierung mit partiellem und wahlfreiem Zugriff, Typsystem, RPC, Typanpassung und Textformat