シリアル化

コンピューティングにおいて、シリアル化（またはserialisation 、 Pythonではpicklingとも呼ばれる）とは、データ構造またはオブジェクトの状態を、保存（例：二次記憶装置内のファイル、一次記憶装置内のデータバッファ）または送信（例：コンピュータネットワーク上のデータストリーム）して後で再構築（おそらくは別のコンピュータ環境）できる形式に変換するプロセスである。^[1]結果として得られる一連のビットをシリアル化形式に従って再度読み取ると、元のオブジェクトと意味的に同一のクローンを作成するために使用できる。参照を多用するオブジェクトなど、多くの複雑なオブジェクトでは、このプロセスは簡単ではない。オブジェクトのシリアル化には、以前にリンクされていた関連メソッドは含まれない。

オブジェクトをシリアル化するこのプロセスは、状況によってはオブジェクトのマーシャリングとも呼ばれます。 ^{[2] [3] [4]}反対の操作、つまり一連のバイトからデータ構造を抽出する操作は、デシリアライゼーション（アンシリアライゼーションまたはアンマーシャリングとも呼ばれます）です。

ネットワーク機器のハードウェアにおいて、シリアル化とデシリアル化を担当する部分は、一般的にSerDesと呼ばれます。

シリアル化の用途は次のとおりです。

• 有線およびネットワーク経由で転送するためにデータをシリアル化する (メッセージング)。
• データの保存（データベース、ハードディスクドライブ上）。
• リモート プロシージャ コール(例: SOAPなど) 。
• 特にCOM、CORBAなどのコンポーネントベースのソフトウェア エンジニアリングにおけるオブジェクトの配布。
• 時間とともに変化するデータの変化を検出する。

これらの機能の一部が有用であるためには、アーキテクチャの独立性を維持する必要があります。たとえば、分散を最大限に活用するには、異なるハードウェア アーキテクチャで実行されているコンピューターが、エンディアンに関係なく、シリアル化されたデータ ストリームを確実に再構築できる必要があります。つまり、データ構造のメモリ レイアウトを直接コピーするという、より単純で高速な手順は、すべてのアーキテクチャで確実に機能するわけではありません。アーキテクチャに依存しない形式でデータ構造をシリアル化すると、バイト順序、メモリ レイアウト、または単に異なるプログラミング言語でデータ構造を表現する方法の違いによる問題を防ぐことができます。

あらゆるシリアル化スキームに固有の特徴として、データのエンコードは定義上シリアルであるため、シリアル化されたデータ構造の一部を抽出するには、オブジェクト全体を最初から最後まで読み取り、再構築する必要があります。多くのアプリケーションでは、この線形性は利点となります。なぜなら、この線形性により、単純で一般的な I/O インターフェイスを使用してオブジェクトの状態を保持および渡すことができるからです。より高いパフォーマンスが問題となるアプリケーションでは、より複雑で非線形なストレージ構成に対処するために、より多くの労力を費やすことが理にかなっている場合があります。

プリミティブポインタオブジェクトは、たとえ単一のマシンであっても、ポイントするオブジェクトがメモリ内の別の場所に再ロードされる可能性があるため、保存するには脆弱すぎます。これに対処するために、シリアル化プロセスには、アンスウィズリングまたはポインタ アンスウィズリングと呼ばれる手順が含まれ、直接ポインタ参照が名前または位置に基づく参照に変換されます。デシリアル化プロセスには、ポインタ スウィズリングと呼ばれる逆の手順が含まれます。

シリアル化と逆シリアル化はどちらも共通コード (たとえば、Microsoft Foundation ClassesのSerialize関数) から実行できるため、共通コードで両方を同時に実行し、1) シリアル化されるオブジェクトとその以前のコピーの違いを検出し、2) 次のそのような検出のための入力を提供することができます。違いは実行中に検出できるため、以前のコピーを実際に構築する必要はありません。この手法は差分実行と呼ばれます。これは、コンテンツが時間によって変化するユーザー インターフェイスのプログラミングに役立ちます。つまり、グラフィカル オブジェクトを作成、削除、変更したり、入力イベントを処理させたりすることができ、それらの操作を行うために別のコードを記述する必要がありません。

シリアル化は、潜在的にプライベートな実装の詳細を公開することで、抽象データ型の不透明性を破壊します。すべてのデータメンバーをシリアル化する単純な実装は、カプセル化に違反する可能性があります。^[5]

競合他社が互換性のある製品を作るのを阻止するために、プロプライエタリ ソフトウェアの発行者は、プログラムのシリアル化形式の詳細を企業秘密にしておくことがよくあります。シリアル化されたデータを意図的に難読化したり、暗号化したりするものもあります。しかし、相互運用性を確保するには、アプリケーションが互いのシリアル化形式を理解できる必要があります。そのため、CORBAなどのリモート メソッド呼び出しアーキテクチャでは、シリアル化形式を詳細に定義しています。

アーカイブや図書館などの多くの機関では、バックアップアーカイブ(特にデータベース ダンプ)を比較的人間が判読しやすいシリアル形式 で保存することで、将来にわたって使用できるようにしています。

1980年代初頭のゼロックスネットワークシステムズクーリエ技術は、最初に広く採用された標準に影響を与えました。サンマイクロシステムズは1987年に外部データ表現（XDR）を公開しました。 ^{[6] XDRは}オープンフォーマットであり、STD 67（RFC 4506）として標準化されています。

1990 年代後半、標準のシリアル化プロトコルに代わるものを提供する動きが始まりました。SGMLのサブセットであるXML を使用して、人間が読めるテキストベースのエンコーディングが作成されました。このようなエンコーディングは、プログラミング言語に関係なく、人間が読んで理解したり、他のシステムに伝達したりできる永続オブジェクトに役立ちます。よりコンパクトなバイト ストリーム ベースのエンコーディングが失われるという欠点がありますが、この時点では、ストレージと転送容量が大きくなったため、ファイル サイズはコンピューティングの初期の頃よりも問題になりませんでした。2000 年代には、Ajax Web アプリケーションでクライアントとサーバーの間で構造化データを非同期転送するために XML がよく使用されました。XML はオープン フォーマットであり、W3C 勧告として標準化されています。

JSON はXML に代わる軽量なプレーンテキストであり、Web アプリケーションでのクライアント サーバー通信にも一般的に使用されています。JSON はJavaScript 構文に基づいていますが、JavaScript とは独立しており、他の多くのプログラミング言語でサポートされています。JSON はオープン フォーマットであり、STD 90 ( RFC  8259)、ECMA-404、および ISO/IEC 21778:2017 として標準化されています。

YAMLは JSON の厳密なスーパーセットであり、データ型タグ、循環データ構造のサポート、インデントに敏感な構文、複数の形式のスカラー データ引用符などの追加機能が含まれています。YAML はオープン フォーマットです。

プロパティ リストは、NeXTSTEP、GNUstep、macOS、およびiOS フレームワークによるシリアル化に使用されます。プロパティ リスト(略してp-list)は、単一のシリアル化形式を指すのではなく、人間が読める形式と 1 つのバイナリを含む複数の異なるバリアントを指します。

衛星データや数値気候、天気、海洋モデルの出力などの大容量の科学データセットについては、 HDF、netCDF、古いGRIBなどの特定のバイナリシリアル化標準が開発されています。

いくつかのオブジェクト指向プログラミング言語は、構文糖衣要素によって、またはそのための標準インターフェースを提供することによって、オブジェクトのシリアル化（またはオブジェクトのアーカイブ）を直接サポートします。これを行う言語には、 Ruby、Smalltalk、Python、PHP、Objective-C、Delphi、Java、および.NETファミリーの言語が含まれます。ネイティブ サポートがない言語にシリアル化のサポートを追加するライブラリも利用できます。

CとC++ は、シリアル化を高水準の構造として提供していませんが、両方の言語とも、組み込みのデータ型や単純な古いデータ 構造体をバイナリ データとして記述することをサポートしています。そのため、カスタムのシリアル化関数を記述するのは通常簡単です。さらに、C++ のODB ORMシステムや C および C++ のgSOAPツールキットなどのコンパイラ ベースのソリューションでは、クラス宣言をほとんどまたはまったく変更せずに、シリアル化コードを自動的に生成できます。その他の一般的なシリアル化フレームワークには、Boost FrameworkのBoost.Serialization ^[7]、S11n フレームワーク、^[8]、Cereal があります。^[9] MFC フレームワーク(Microsoft) も、ドキュメント ビュー アーキテクチャの一部としてシリアル化方法論を提供しています。

CFML では、データ構造を タグを使用してWDDXにシリアル化したり<cfwddx>、SerializeJSON() 関数を使用して JSONにシリアル化したりできます。

Delphi には、コンポーネント (永続オブジェクトとも呼ばれる) をシリアル化するための組み込みメカニズムが用意されており、IDEに完全に統合されています。コンポーネントの内容は DFM ファイルに保存され、オンザフライで再ロードされます。

GoはJSONとXMLデータのアンマーシャリング/マーシャリングをネイティブにサポートしています。^[10] YAML ^[11]とプロトコルバッファ^[12]をサポートするサードパーティモジュールもあります。GoはGobsもサポートしています。^[13]

Haskellでは、ReadおよびShow型クラスのメンバーである型に対してシリアル化がサポートされています。Read型クラスのメンバーであるすべての型は、ダンプされたデータの文字列表現からデータを抽出する関数を定義します。Show型クラスには、showオブジェクトの文字列表現を生成できる関数が含まれます。プログラマは関数を明示的に定義する必要はありません。型をReadから派生するか、Showから派生するか、またはその両方を宣言するだけで、多くの場合コンパイラが適切な関数を生成できます(ただし、すべてではありません。たとえば、関数型はShowまたはReadを自動的に派生できません)。Showの自動生成されたインスタンスも有効なソースコードを生成するため、showによって生成されたコードをHaskellインタープリタなどで実行することで、同じHaskell値を生成できます。^[14]より効率的なシリアル化のために、binaryなどのバイナリ形式での高速シリアル化を可能にするhaskellライブラリがあります。

Java は自動シリアル化を提供しますが、そのためには、インターフェースを実装してオブジェクトをマークする必要があります。インターフェースを実装すると、クラスは「シリアル化可能」としてマークされ、Java は内部でシリアル化を処理します。インターフェースにはシリアル化メソッドは定義されていませんが、シリアル化可能なクラスは、特定の特別な名前とシグネチャを持つメソッドをオプションで定義できます。これらのメソッドが定義されている場合、シリアル化/デシリアライズ プロセスの一部として呼び出されます。また、この言語では、別のインターフェースであるインターフェースを実装することで、開発者がシリアル化プロセスをより徹底的にオーバーライドすることもできます。このインターフェースには、オブジェクトの状態を保存および復元するために使用される 2 つの特別なメソッドが含まれています。オブジェクトがデフォルトでシリアル化可能ではなく、Java のシリアル化メカニズムにアクセスするにはインターフェースを実装する必要がある主な理由は 3 つあります。まず、すべてのオブジェクトがシリアル化された状態で有用なセマンティクスをキャプチャするわけではありません。たとえば、オブジェクトは現在のJVMの状態に関連付けられています。デシリアライズされたオブジェクトが有用なセマンティクスを維持するコンテキストはありません。次に、オブジェクトのシリアル化された状態は、そのクラスの互換性コントラクトの一部を形成します。シリアル化可能なクラスのバージョン間の互換性を維持するには、追加の労力と考慮が必要です。したがって、クラスをシリアル化可能にすることは、デフォルトの条件ではなく、意図的な設計上の決定である必要があります。最後に、シリアル化により、他の方法ではアクセスできないクラスの非一時的なプライベート メンバーにアクセスできるようになります。機密情報 (パスワードなど) を含むクラスは、シリアル化も外部化も可能にすべきではありません。^{[15] : 339–345}標準的なエンコード方法では、オブジェクトのクラス記述子とシリアル化可能なフィールドをバイト ストリームに再帰グラフ ベースで変換します。プリミティブと、非一時的、非静的な参照オブジェクトがストリームにエンコードされます。シリアル化されたオブジェクトによって、 としてマークされていないフィールドを介して参照される各オブジェクトもシリアル化する必要があります。非一時オブジェクト参照の完全なグラフ内にシリアル化できないオブジェクトがある場合、シリアル化は失敗します。開発者は、オブジェクトを一時的としてマークしたり、オブジェクトのシリアル化を再定義して参照グラフの一部を切り捨ててシリアル化しないようにしたりすることで、この動作に影響を与えることができます。Javaは、オブジェクトをシリアル化するためにコンストラクタを使用しません。JavaオブジェクトをJDBC経由でシリアル化し、データベースに格納することは可能です。 ^[16] Swingjava.io.Serializable SerializableExternalizable
Serializable
ThreadThread

transient
コンポーネントは Serializable インターフェイスを実装していますが、Java 仮想マシンの異なるバージョン間で移植可能であることは保証されていません。そのため、Swing コンポーネント、またはそれを継承するコンポーネントはバイト ストリームにシリアル化できますが、別のマシンで再構成可能であることは保証されません。

ECMAScript 5.1以降、^[17] JavaScriptには組み込みJSONオブジェクトとそのメソッドJSON.parse()およびが含まれていますJSON.stringify()。JSONはもともとJavaScriptのサブセットに基づいていますが、^[18] JSONが有効なJavaScriptではない境界ケースがあります。具体的には、JSONではUnicodeの行末文字 U+2028 LINE SEPARATORとU+2029 PARAGRAPH SEPARATORを引用符で囲まれた文字列内でエスケープせずに使用できますが、ECMAScript 2018以前では使用できません。^{[19] [20]} JSONのメイン記事を参照してください。

Juliaはserialize()/deserialize()モジュールを通じてシリアル化を実装しており^[21] 、同じバージョンのJulia内、または同じシステムイメージのインスタンス内で動作するように設計されています。^[22]パッケージHDF5.jlは、文書化された形式と、さまざまな言語のラッパーを備えた共通ライブラリを使用して、より安定した代替手段を提供します。^[23]一方、デフォルトのシリアル化形式は、ネットワーク通信の最大パフォーマンスを念頭に置いて設計されていると示唆されています。^[24]

一般に、Lispreadデータ構造は関数 " " および " "を使用してシリアル化できますprint。たとえば、配列のリストを含む変数 foo は、 によって印刷されます(print foo)。同様に、オブジェクトは によって s という名前のストリームから読み取ることができます(read s)。Lisp 実装のこれらの 2 つの部分は、プリンタとリーダーと呼ばれます。 " print" の出力は人間が読める形式で、括弧で区切られたリストを使用します。たとえば、 です。Common Lispを含む多くの種類の Lisp では、プリンタはすべてのタイプのデータを表現できません。その方法が明確でないためです。たとえば、Common Lisp では、プリンタは CLOS オブジェクトを印刷できません。代わりに、プログラマは汎用関数 にメソッドを記述できます。これは、オブジェクトが印刷されるときに呼び出されます。これは、Ruby で使用されるメソッドに多少似ています。Lisp コード自体は、読み取り構文と呼ばれるリーダーの構文で記述されます。ほとんどの言語は、コードとデータを処理するために別々の異なるパーサーを使用しますが、Lisp では 1 つのみを使用します。 Lisp コードを含むファイルは、データ構造としてメモリに読み込まれ、別のプログラムによって変換され、読み取り - 評価 - 印刷ループなどで実行または書き出される可能性があります。すべてのリーダー/ライターが循環構造、再帰構造、または共有構造をサポートしているわけではありません。 (4 2.9 "x" y)print-object

.NETにはMicrosoftが設計したシリアライザーがいくつかあります。また、サードパーティ製のシリアライザーも多数あります。12種類以上のシリアライザーがここで説明され、テストされています。^[25]そしてここ^[26]

OCamlの標準ライブラリは、Marshalモジュール^[3]とPervasives関数output_valueおよびを通じてマーシャリングを提供しますinput_value。OCamlプログラミングは静的に型チェックされますが、Marshalモジュールを使用すると型の保証が破られる可能性があります。これは、アンマーシャリングされたストリームが期待される型のオブジェクトを表しているかどうかを確認する方法がないためです。OCamlでは、関数または関数を含むデータ構造（メソッドを含むオブジェクトなど）をマーシャリングすることは困難です。これは、関数内の実行可能コードを異なるプログラム間で転送できないためです。（関数のコード位置をマーシャリングするフラグはありますが、アンマーシャリングできるのはまったく同じプログラム内だけです）。標準のマーシャリング関数は、フラグによって構成できる共有を維持し、循環データを処理できます。

CPANから入手できるPerlモジュールには、、、など、シリアル化メカニズムを提供するものがいくつかあります。Storable には、Perl データ構造をファイルまたは Perl スカラーにシリアル化および逆シリアル化する関数が含まれています。ファイルに直接シリアル化するだけでなく、には、スカラーにパックされたデータのシリアル化されたコピーを返す関数と、そのようなスカラーを逆シリアル化する関数が含まれています。これは、複雑なデータ構造をネットワーク ソケット経由で送信したり、データベースに格納したりする場合に役立ちます。 で構造をシリアル化する場合、常に速度を少し犠牲にしてどのコンピュータでも読み取り可能な形式でデータを格納するネットワーク セーフ関数があります。これらの関数は、、、などと呼ばれます。これらの構造を逆シリアル化する「n」個の関数はありません。つまり、通常の構造と逆シリアル化構造は、「」関数とそれらのマシン固有の同等機能でシリアル化されます。 StorableJSON::XSFreezeThawStorablefreezethawStorablenstorenfreezethawretrieven

PHP は元々、組み込み関数serialize()とunserialize()関数を通じてシリアル化を実装していました。^[27] PHP はリソース (ファイル ポインタ、ソケットなど) を除くすべてのデータ型をシリアル化できます。組み込み関数は、unserialize()完全に信頼できないデータに使用すると危険な場合がよくあります。^[28]オブジェクトの場合、クラス内に実装できる2 つの「マジック__sleep()メソッド」 、つまり と があり、それぞれ__wakeup() と から呼び出されて、オブジェクトのクリーンアップと復元を行うことができます。たとえば、シリアル化時にデータベース接続を閉じ、デシリアライズ時に接続を復元することが望ましい場合があります。この機能は、これら 2 つのマジック メソッドで処理されます。また、これらのマジック メソッドにより、オブジェクトがシリアル化するプロパティを選択することもできます。PHP 5.1 以降、オブジェクト用のオブジェクト指向シリアル化メカニズムであるインターフェイスがあります。^[29]serialize()unserialize()Serializable

Prologの用語構造は言語の唯一のデータ構造であり、組み込み述語を介してシリアル化出力できwrite_term/3、組み込み述語read/1およびを介してシリアル化入力できますread_term/2。結果のストリームは圧縮されていないテキスト (ターゲット ストリームの構成によって決定されるエンコード) であり、用語内の自由変数はプレースホルダー変数名で表されます。述語は、Prolog の ISO 仕様write_term/3(ISO/IEC 13211-1) の 59 ページ以降で標準化されています(「用語の記述、§ 7.10.5」)。したがって、ある実装でシリアル化された用語は、あいまいさや予期せぬ事態なしに別の実装でシリアル化入力できることが期待されます。実際には、実装固有の拡張機能 (例: SWI-Prolog の辞書) では非標準の用語構造が使用されるため、エッジ ケースで相互運用性が損なわれる可能性があります。例として、SWI-Prolog、^[30] SICStus Prolog、^[31] GNU Prolog の対応するマニュアル ページを参照してください。^[32]ネットワーク経由で受信したシリアル化された用語が仕様に照らしてチェックされるかどうか、またどのようにチェックされるかは（文字ストリームからの逆シリアル化が行われた後に）実装者に委ねられます。Prologに組み込まれている確定節文法はその段階で適用できます。

中核となる一般的なシリアル化メカニズムはpickle 標準ライブラリモジュールであり、データのシリアル化（デシリアライズの逆ピクル）を説明するためにデータベースシステム用語のピクル^{[33] [34] [35]}を参照しています。Pickle は、オブジェクトの再構築に使用される命令を記録する単純なスタックベースの仮想マシンを使用します。これは、バージョン間でカスタマイズ可能ですが、安全ではない（誤ったデータや悪意のあるデータに対して安全ではない）シリアル化形式です。不正な形式または悪意を持って構築されたデータにより、デシリアライザーが任意のモジュールをインポートし、任意のオブジェクトをインスタンス化する可能性があります。^{[36] [37]}標準ライブラリには、標準データ形式にシリアル化するモジュールも含まれています。（基本的なスカラー型とコレクション型の組み込みサポートがあり、エンコードおよびデコードフックを介して任意の型をサポートできます）。 （バイナリと XML の両方のプロパティリスト形式をサポート）。 （RFC 1014 で説明されている外部データ表現（XDR）標準をサポート最後に、オブジェクトのは適切な環境で評価可能であることが推奨されており、これは Common Lisp のとほぼ一致する。すべてのオブジェクト型、特にファイルハンドルなどのオペレーティングシステムのリソースを保持するオブジェクト型は自動的に pickle 化できるわけではないが、ユーザーはカスタムの「リダクション」関数と構築関数を登録して、任意の型の pickle 化と unpickle 化をサポートできる。Pickle はもともと純粋な Pythonモジュールとして実装されていたが、Python 3.0 より前のバージョンでは、モジュール (組み込み) によってパフォーマンスが向上した (最大 1000 倍高速^[36] )。はUnladen Swallowプロジェクトから採用された。Python 3 では、ユーザーは常に標準バージョンをインポートする必要があり、これにより高速化バージョンをインポートしようとして純粋な Python バージョンにフォールバックする。^[38]jsonplistlibxdrlib__repr__print-objectpicklecPicklecPickle

Rdputには、RオブジェクトのASCIIテキスト表現をファイルまたは接続に書き込む関数があります。表現はを使用してファイルから読み取ることができますdget。^[39]具体的には、関数はserializeRオブジェクトを接続にシリアル化し、出力は16進形式でコード化された生のベクトルです。関数を使用するとunserialize、接続または生のベクトルからオブジェクトを読み取ることができます。^[40]

REBOLはsave/allファイル（ ）またはstring!（ ）にシリアル化します。文字列とファイルは多態mold/all関数を使用して逆シリアル化できます。プロトコルバッファを使用して、Rで言語間のデータシリアル化を提供します。^[41] loadRProtoBuf

Ruby には、標準の Unix ユーティリティの および に似た2Marshalつのメソッド と を含むdump標準モジュールが含まれています。これらのメソッドは標準クラス にシリアル化します。つまり、実質的にバイト シーケンスになります。バインディング、プロシージャ オブジェクト、クラス IO のインスタンス、シングルトン オブジェクト、およびインターフェイスなど、一部のオブジェクトはシリアル化できません (シリアル化すると例外が発生します)。クラスでカスタム シリアル化が必要な場合 (たとえば、ダンプ/復元時に特定のクリーンアップ アクションを実行する必要があるなど)、2 つのメソッドと を実装することでこれを実現できます。インスタンス メソッドは、このクラスのオブジェクトと、整数パラメータで指定された最大深度までの参照オブジェクトすべてを再構成するために必要なすべての情報を含むオブジェクトを返す必要があります (値 -1 は深度チェックを無効にする必要があることを意味します)。クラス メソッドはを受け取り、このクラスのオブジェクトを返す必要があります。 loaddumprestoreStringTypeError_dump_load _dumpString _loadString

Serdeは、 Rustでのシリアル化に最も広く使用されているライブラリ、またはクレートです。

一般に、非再帰的かつ非共有のオブジェクトは、storeOn:/readFrom:プロトコルを使用して人間が読める形式で保存および取得できます。storeOn:メソッドは、 Smalltalk 式のテキストを生成し、 を使用して評価すると、readFrom:元のオブジェクトが再作成されます。 このスキームは、データ自体ではなく、オブジェクトの手続き型記述を使用するという点で特殊です。 したがって、非常に柔軟であり、クラスがよりコンパクトな表現を定義できます。 ただし、元の形式では、循環データ構造を処理したり、共有参照の ID を保持したりしません (つまり、単一のオブジェクトに対する 2 つの参照は、2 つの等しいが同一ではないコピーへの参照として復元されます)。 このため、さまざまな移植可能な代替手段と移植不可能な代替手段が存在します。 それらのいくつかは、特定の Smalltalk 実装またはクラス ライブラリに固有のものです。Squeak Smalltalkには、オブジェクトをシリアル化して保存する方法がいくつかあります。 最も簡単で最もよく使用されるのは、シリアライザーstoreOn:/readFrom:に基づくバイナリ ストレージ形式とバイナリ ストレージ形式ですSmartRefStream。 さらに、 バンドルされたオブジェクトは を使用して保存および取得できますImageSegments。どちらも、いわゆる「バイナリ オブジェクト ストレージ フレームワーク」を提供し、コンパクトなバイナリ形式へのシリアル化とそこからの取得をサポートします。どちらも、循環的、再帰的、共有構造、クラスおよびメタクラス情報の保存/取得を処理し、オンザフライのオブジェクト移行 (つまり、異なるオブジェクト レイアウトを持つクラスの古いバージョンによって書き込まれたインスタンスを変換する) のメカニズムを備えています。API は類似していますが (storeBinary/readBinary)、エンコードの詳細が異なるため、これら 2 つの形式は互換性がありません。ただし、Smalltalk/X コードはオープン ソースで無料であり、他の Smalltalk にロードして方言間のオブジェクト交換を行うことができます。オブジェクトのシリアル化は、ANSI Smalltalk 仕様の一部ではありません。そのため、オブジェクトをシリアル化するコードは Smalltalk 実装によって異なります。結果のバイナリ データも異なります。たとえば、Squeak Smalltalk で作成されたシリアル化されたオブジェクトは、Ambrai Smalltalk では復元できません。その結果、オブジェクトのシリアル化に依存する複数の Smalltalk 実装で動作するさまざまなアプリケーションは、これらの異なる実装間でデータを共有できません。これらのアプリケーションには、MinneStoreオブジェクトデータベース^[42]やいくつかのRPCパッケージが含まれます。この問題の解決策は、複数のSmalltalk用のパッケージであるSIXX ^{[43]であり、これはシリアル化に}XMLベースの形式を使用します。

Swift標準ライブラリは、と（一緒に構成される）の2つのプロトコルを提供しており、これらを使用すると、準拠する型のインスタンスをJSON、プロパティリスト、またはその他の形式にシリアル化したり、これらの形式から逆シリアル化したりできます。 ^[44]これらのプロトコルのデフォルト実装は、格納されたプロパティがまたはである型に対してコンパイラによって生成できます。 EncodableDecodableCodableDecodableEncodable

PowerShell は、組み込みコマンドレットを通じてシリアル化を実装しますExport-CliXML。はExport-CliXML、.NET オブジェクトをシリアル化し、結果の XML をファイルに保存します。オブジェクトを再構成するには、Import-CliXMLというコマンドレットを使用します。このコマンドレットは、エクスポートされたファイルの XML から逆シリアル化されたオブジェクトを生成します。逆シリアル化されたオブジェクト (「プロパティ バッグ」とも呼ばれる) はライブ オブジェクトではなく、プロパティはあるもののメソッドがないスナップショットです。2 次元データ構造も、組み込みコマンドレットおよび を使用してCSV形式でシリアル化 (逆シリアル化) できます。 Import-CSVExport-CSV

• 通信（テレメトリ）
• データシリアル化形式の比較
• コンテナ形式
• 休止状態 (Java)
• XML スキーマ
• 基本的なエンコードルール
• Google プロトコル バッファ
• ウィキベース
• アパッチアブロ

• Java オブジェクトシリアル化ドキュメント
• Java 1.4 オブジェクト シリアル化のドキュメント。
• 耐久性のある Java: シリアル化 2005 年 11 月 25 日にWayback Machineにアーカイブされました
• XML データバインディングリソース
• Databoard - 部分的およびランダムアクセス、型システム、RPC、型適応、テキスト形式によるバイナリシリアル化