In computing, serialization (or serialisation, also referred to as pickling in Python) is the process of translating a data structure or object state into a format that can be stored (e.g. files in secondary storage devices, data buffers in primary storage devices) or transmitted (e.g. data streams over computer networks) and reconstructed later (possibly in a different computer environment).^[1] When the resulting series of bits is reread according to the serialization format, it can be used to create a semantically identical clone of the original object. For many complex objects, such as those that make extensive use of references, this process is not straightforward. Serialization of objects does not include any of their associated methods with which they were previously linked.

This process of serializing an object is also called marshalling in some situations.^[2][3][4] The opposite operation, extracting a data structure from a series of bytes, is deserialization (also called unserialization or unmarshalling).

In networking equipment hardware, the part that is responsible for serialization and deserialization is commonly called SerDes.

Uses of serialization include:

• transfer across wires and networks (messaging).
• storing data (in databases, on hard disk drives).
• remote procedure calls, e.g., as in SOAP.
• distributing objects, especially in component-based software engineering such as COM, CORBA, etc.
• detecting changes in time-varying data.

For some of these features to be useful, architecture independence must be maintained. For example, for maximal use of distribution, a computer running on a different hardware architecture should be able to reliably reconstruct a serialized data stream, regardless of endianness. This means that the simpler and faster procedure of directly copying the memory layout of the data structure cannot work reliably for all architectures. Serializing the data structure in an architecture-independent format means preventing the problems of byte ordering, memory layout, or simply different ways of representing data structures in different programming languages.

Inherent to any serialization scheme is that, because the encoding of the data is by definition serial, extracting one part of the serialized data structure requires that the entire object be read from start to end, and reconstructed. In many applications, this linearity is an asset, because it enables simple, common I/O interfaces to be utilized to hold and pass on the state of an object. In applications where higher performance is an issue, it can make sense to expend more effort to deal with a more complex, non-linear storage organization.

Even on a single machine, primitive pointer objects are too fragile to save because the objects to which they point may be reloaded to a different location in memory. To deal with this, the serialization process includes a step called unswizzling or pointer unswizzling, where direct pointer references are converted to references based on name or position. The deserialization process includes an inverse step called pointer swizzling.

Since both serializing and deserializing can be driven from common code (for example, the Serialize function in Microsoft Foundation Classes), it is possible for the common code to do both at the same time, and thus, 1) detect differences between the objects being serialized and their prior copies, and 2) provide the input for the next such detection. It is not necessary to actually build the prior copy because differences can be detected on the fly, a technique called differential execution. This is useful in the programming of user interfaces whose contents are time-varying — graphical objects can be created, removed, altered, or made to handle input events without necessarily having to write separate code to do those things.

Serialization breaks the opacity of an abstract data type by potentially exposing private implementation details. Trivial implementations which serialize all data members may violate encapsulation.^[5]

To discourage competitors from making compatible products, publishers of proprietary software often keep the details of their programs' serialization formats a trade secret. Some deliberately obfuscate or even encrypt the serialized data. Yet, interoperability requires that applications be able to understand each other's serialization formats. Therefore, remote method call architectures such as CORBA define their serialization formats in detail.

Many institutions, such as archives and libraries, attempt to future proof their backup archives—in particular, database dumps—by storing them in some relatively human-readable serialized format.

The Xerox Network Systems Courier technology in the early 1980s influenced the first widely adopted standard. Sun Microsystems published the External Data Representation (XDR) in 1987.^[6] XDR is an open format, and standardized as STD 67 (RFC 4506) by IETF.

In the late 1990s, a push to provide an alternative to the standard serialization protocols started: XML, an SGML subset, was used to produce a human-readable text-based encoding. Such an encoding can be useful for persistent objects that may be read and understood by humans or communicated to other systems regardless of programming language. It has the disadvantage of losing the more compact, byte-stream-based encoding, but by this point larger storage and transmission capacities made file size less of a concern than in the early days of computing. In the 2000s, XML was often used for asynchronous transfer of structured data between client and server in Ajax web applications. XML is an open format and standardized as a W3C recommendation.

JSON is a lightweight plain-text alternative to XML and is also commonly used for client-server communication in web applications. JSON is based on JavaScript syntax but is independent of JavaScript and supported in many other programming languages. JSON is standardized as STD 90 (RFC 8259), ECMA-404, and ISO/IEC 21778:2017.

YAML is a strict superset of JSON and includes additional features such as a data type tags, support for cyclic data structures, indentation-sensitive syntax, and multiple forms of scalar data quoting. YAML is an open format.

รายการคุณสมบัติ (Property list)ถูกใช้สำหรับการแปลงข้อมูลเป็นรูปแบบที่สามารถอ่านได้โดยเฟรมเวิร์กNeXTSTEP , GNUstep , macOSและiOS รายการคุณสมบัติหรือ เรียกสั้น ๆ ว่า p-listไม่ได้หมายถึงรูปแบบการแปลงข้อมูลเพียงรูปแบบเดียว แต่หมายถึงรูปแบบที่แตกต่างกันหลายแบบ บางรูปแบบสามารถอ่านได้โดยมนุษย์ และบางรูปแบบเป็นข้อมูลไบนารี

สำหรับชุดข้อมูลทางวิทยาศาสตร์ที่มีปริมาณมาก เช่น ข้อมูลจากดาวเทียมและผลลัพธ์จากแบบจำลองสภาพภูมิอากาศ สภาพอากาศ หรือมหาสมุทรเชิงตัวเลข ได้มีการพัฒนามาตรฐานการแปลงข้อมูลเป็นไบนารีเฉพาะขึ้น เช่นHDF , netCDFและGRIBซึ่ง เป็นมาตรฐานเก่ากว่า

ภาษา โปรแกรมเชิงวัตถุหลายภาษาสนับสนุนการจัดเก็บข้อมูลวัตถุ (หรือการเก็บรักษาวัตถุ ) โดยตรง ไม่ว่าจะผ่าน ทางไวยากรณ์ที่ช่วยให้เขียน โปรแกรมได้ง่ายขึ้นหรือการจัดเตรียมอินเทอร์ เฟซมาตรฐาน สำหรับการทำเช่นนั้น ภาษาที่รองรับฟังก์ชันนี้ ได้แก่Ruby , Smalltalk , Python , PHP , Objective-C , Delphi , Javaและ ตระกูลภาษา . NETนอกจากนี้ยังมีไลบรารีที่เพิ่มการสนับสนุนการจัดเก็บข้อมูลวัตถุให้กับภาษาที่ไม่มีการรองรับโดยตรงอีกด้วย

ภาษา CและC++ไม่ได้จัดเตรียมการทำให้เป็นอนุกรม (serialization) เป็นโครงสร้างระดับสูงใดๆ แต่ทั้งสองภาษาสนับสนุนการเขียนประเภทข้อมูล ในตัวใดๆ รวมถึงโครงสร้างข้อมูลแบบเก่าๆ ให้เป็นข้อมูลไบนารี ดังนั้น การเขียนฟังก์ชันการทำให้เป็นอนุกรมแบบกำหนดเองจึงมักทำได้ง่าย นอกจากนี้ โซลูชันที่ใช้คอมไพเลอร์ เช่น ระบบ ODB ORMสำหรับ C++ และ ชุดเครื่องมือ gSOAPสำหรับ C และ C++ สามารถสร้างโค้ดการทำให้เป็นอนุกรมโดยอัตโนมัติโดยแทบไม่ต้องแก้ไขการประกาศคลาสเลย เฟรมเวิร์กการทำให้เป็นอนุกรมยอดนิยมอื่นๆ ได้แก่ Boost.Serialization ^{[ 7 ]}จากBoost Framework , เฟรมเวิร์ก S11n ^{[ 8 ]}และ Cereal ^{[ 9 ]}เฟรมเวิร์ก MFC (Microsoft) ยังมีวิธีการทำให้เป็นอนุกรมเป็นส่วนหนึ่งของสถาปัตยกรรม Document-View อีกด้วย

ด้วยการนำการเขียนโปรแกรมแบบสะท้อนกลับมาใช้ในC++26 การทำให้เป็นอนุกรมจึงง่ายขึ้นอย่างมาก การสะท้อนกลับช่วยให้สามารถแปลง JSONเป็นอนุกรมในเวลาคอมไพล์ได้ เช่นเป็นstructโครงสร้างที่สอดคล้องกัน^{[ 10 ]}

CFMLอนุญาตให้แปลงโครงสร้างข้อมูลเป็นWDDXโดยใช้<cfwddx>แท็ก และเป็นJSONโดยใช้ฟังก์ชัน SerializeJSON()

Delphiมีกลไกในตัวสำหรับการบันทึกข้อมูลส่วนประกอบ (หรือเรียกว่าอ็อบเจ็กต์ถาวร) ซึ่งผสานรวมเข้ากับIDE อย่างสมบูรณ์ เนื้อหาของส่วนประกอบจะถูกบันทึกไว้ในไฟล์ DFM และโหลดกลับมาใช้งานได้ทันที

Goรองรับการแปลงข้อมูลJSONและXML ได้โดยตรง ^{[ 11 ]}นอกจากนี้ยังมีโมดูลของบุคคลที่สามที่รองรับYAML ^{[ 12 ]}และProtocol Buffers [ ^{13 ] Go}ยังรองรับGobs อีก ด้วย ^{[ 14 ]}

ใน Haskell การทำให้เป็นอนุกรมได้รับการสนับสนุนสำหรับประเภทที่เป็นสมาชิกของคลาสประเภท Read และ Show ทุกประเภทที่เป็นสมาชิกของReadคลาสประเภทจะกำหนดฟังก์ชันที่จะดึงข้อมูลจากสตริงที่แสดงข้อมูลที่ถูกดัมพ์Showคลาสประเภทนั้นเองก็มีshowฟังก์ชันที่สามารถสร้างสตริงที่แสดงวัตถุได้ โปรแกรมเมอร์ไม่จำเป็นต้องกำหนดฟังก์ชันอย่างชัดเจน เพียงแค่ประกาศประเภทให้สืบทอดจาก Read หรือสืบทอดจาก Show หรือทั้งสองอย่าง ก็สามารถทำให้คอมไพเลอร์สร้างฟังก์ชันที่เหมาะสมสำหรับหลายกรณี (แต่ไม่ใช่ทั้งหมด: ตัวอย่างเช่น ประเภทฟังก์ชันไม่สามารถสืบทอดจาก Show หรือ Read ได้โดยอัตโนมัติ) อินสแตนซ์ที่สร้างขึ้นโดยอัตโนมัติสำหรับ Show ยังสร้างซอร์สโค้ดที่ถูกต้อง ดังนั้นค่า Haskell เดียวกันจึงสามารถสร้างได้โดยการรันโค้ดที่สร้างโดย show ในตัวอย่างเช่น ล่าม Haskell ^{[ 15 ]}สำหรับการทำให้เป็นอนุกรมที่มีประสิทธิภาพมากขึ้น มีไลบรารี Haskell ที่อนุญาตให้ทำการทำให้เป็นอนุกรมด้วยความเร็วสูงในรูปแบบไบนารีเช่น binary

Java มีกลไกการซีเรียลไลซ์อัตโนมัติซึ่งกำหนดให้ต้องมี การทำเครื่องหมายวัตถุโดยการใช้งาน อินเท java.io.Serializableอร์เฟซ การใช้งานอินเทอร์เฟซจะทำเครื่องหมายคลาสว่า "สามารถซีเรียลไลซ์ได้" และ Java จะจัดการการซีเรียลไลซ์ภายในเอง ไม่มีเมธอดซีเรียลไลซ์ใด ๆ ที่กำหนดไว้ในSerializableอินเทอร์เฟซ แต่คลาสที่สามารถซีเรียลไลซ์ได้สามารถกำหนดเมธอดที่มีชื่อและลายเซ็นพิเศษบางอย่างได้ ซึ่งหากกำหนดไว้ เมธอดเหล่านั้นจะถูกเรียกใช้เป็นส่วนหนึ่งของกระบวนการซีเรียลไลซ์/ดีซีเรียลไลซ์ ภาษายังอนุญาตให้นักพัฒนาสามารถเขียนทับกระบวนการซีเรียลไลซ์ได้อย่างละเอียดมากขึ้นโดยการใช้งานอินเทอร์เฟซอื่นExternalizableซึ่งก็คืออินเทอร์เฟซ ซึ่งมีเมธอดพิเศษสองเมธอดที่ใช้ในการบันทึกและกู้คืนสถานะของวัตถุมีเหตุผลหลักสามประการที่ทำให้วัตถุไม่สามารถซีเรียลไลซ์ได้โดยค่าเริ่มต้นและต้องใช้งานSerializableอินเทอร์เฟซเพื่อเข้าถึงกลไกการซีเรียลไลซ์ของ Java ประการแรก วัตถุบางอย่างไม่ได้เก็บความหมายที่มีประโยชน์ในสถานะซีเรียลไลซ์ ตัวอย่างเช่น วัตถุจะผูกติดกับสถานะของ JVMThreadปัจจุบันไม่มีบริบทใดที่วัตถุที่ถูกดีซีเรียลไลซ์จะยังคงรักษาความหมายที่มีประโยชน์ไว้ได้ประการที่สอง สถานะซีเรียลไลซ์ของวัตถุเป็นส่วนหนึ่งของสัญญาความเข้ากันได้ของคลาส การรักษาความเข้ากันได้ระหว่างเวอร์ชันของคลาสที่สามารถทำให้เป็นอนุกรมได้นั้นต้องใช้ความพยายามและการพิจารณาเพิ่มเติม ดังนั้น การทำให้คลาสสามารถทำให้เป็นอนุกรมได้จึงต้องเป็นการตัดสินใจออกแบบโดยตั้งใจ ไม่ใช่เงื่อนไขเริ่มต้นสุดท้าย การทำให้เป็นอนุกรมช่วยให้สามารถเข้าถึงสมาชิกส่วนตัวที่ไม่ใช่แบบชั่วคราวของคลาสที่ไม่สามารถเข้าถึงได้ในกรณีอื่น คลาสที่มีข้อมูลที่ละเอียดอ่อน (เช่น รหัสผ่าน) ไม่ควรทำให้เป็นอนุกรมหรือทำให้เป็นภายนอกได้^{[ 16 ] : 339–345} วิธีการเข้ารหัสมาตรฐานใช้การแปลแบบกราฟแบบเรียกซ้ำของตัวอธิบายคลาสของวัตถุและฟิลด์ที่สามารถทำให้เป็นอนุกรมได้เป็นสตรีมไบต์ พรีมิทีฟรวมถึงวัตถุอ้างอิงที่ไม่ใช่แบบชั่วคราวและไม่ใช่แบบคงที่จะถูกเข้ารหัสลงในสตรีม วัตถุแต่ละชิ้นที่ถูกอ้างอิงโดยวัตถุที่ทำให้เป็นอนุกรมผ่านฟิลด์ที่ไม่ได้ทำเครื่องหมายไว้จะต้องถูกทำให้เป็นอนุกรมด้วย และหากวัตถุใด ๆ ในกราฟที่สมบูรณ์ของการอ้างอิงวัตถุที่ไม่ใช่แบบชั่วคราวไม่สามารถทำให้เป็นอนุกรมได้ การทำให้เป็นอนุกรมจะล้มเหลว นักพัฒนาสามารถมีอิทธิพลต่อพฤติกรรมนี้ได้โดยการทำเครื่องหมายวัตถุเป็นแบบชั่วคราว หรือโดยการกำหนดนิยามใหม่ของการทำให้เป็นอนุกรมสำหรับวัตถุเพื่อให้ส่วนใดส่วนหนึ่งของกราฟอ้างอิงถูกตัดทอนและไม่ถูกทำให้เป็นอนุกรมJava ไม่ใช้คอนสตรัคเตอร์เพื่อทำให้วัตถุเป็นอนุกรม เป็นไปได้ที่จะทำให้วัตถุ Java เป็นอนุกรมผ่านJDBCและจัดเก็บลงในฐานข้อมูล^{[ 17 ]}ในขณะที่SwingThreadtransient components do implement the Serializable interface, they are not guaranteed to be portable between different versions of the Java Virtual Machine. As such, a Swing component, or any component which inherits it, may be serialized to a byte stream, but it is not guaranteed that this will be re-constitutable on another machine.

Since ECMAScript 5.1,^[18]JavaScript has included the built-in JSON object and its methods JSON.parse() and JSON.stringify(). Although JSON is originally based on a subset of JavaScript,^[19] there are boundary cases where JSON is not valid JavaScript. Specifically, JSON allows the Unicode line terminatorsU+2028LINE SEPARATOR and U+2029PARAGRAPH SEPARATOR to appear unescaped in quoted strings, while ECMAScript 2018 and older does not.^[20][21] See the main article on JSON.

Julia implements serialization through the serialize() / deserialize() modules,^[22] intended to work within the same version of Julia, and/or instance of the same system image.^[23] The HDF5.jl package offers a more stable alternative, using a documented format and common library with wrappers for different languages,^[24] while the default serialization format is suggested to have been designed rather with maximal performance for network communication in mind.^[25]

Generally a Lisp data structure can be serialized with the functions "read" and "print". A variable foo containing, for example, a list of arrays would be printed by (print foo). Similarly an object can be read from a stream named s by (read s). These two parts of the Lisp implementation are called the Printer and the Reader. The output of "print" is human readable; it uses lists demarked by parentheses, for example: (42.9"x"y). In many types of Lisp, including Common Lisp, the printer cannot represent every type of data because it is not clear how to do so. In Common Lisp for example the printer cannot print CLOS objects. Instead the programmer may write a method on the generic function print-object, this will be invoked when the object is printed. This is somewhat similar to the method used in Ruby. Lisp code itself is written in the syntax of the reader, called read syntax. Most languages use separate and different parsers to deal with code and data, Lisp only uses one. A file containing lisp code may be read into memory as a data structure, transformed by another program, then possibly executed or written out, such as in a read–eval–print loop. Not all readers/writers support cyclic, recursive or shared structures.

.NET has several serializers designed by Microsoft. There are also many serializers by third parties. More than a dozen serializers are discussed and tested hereArchived 2015-05-08 at the Wayback Machine.^[26] and here^[27]

OCaml's standard library provides marshalling through the Marshal module^[3] and the Pervasives functions output_value and input_value. While OCaml programming is statically type-checked, uses of the Marshal module may break type guarantees, as there is no way to check whether an unmarshalled stream represents objects of the expected type. In OCaml it is difficult to marshal a function or a data structure which contains a function (e.g. an object which contains a method), because executable code in functions cannot be transmitted across different programs. (There is a flag to marshal the code position of a function but it can only be unmarshalled in exactly the same program). The standard marshalling functions can preserve sharing and handle cyclic data, which can be configured by a flag.

Several Perl modules available from CPAN provide serialization mechanisms, including Storable , JSON::XS and FreezeThaw. Storable includes functions to serialize and deserialize Perl data structures to and from files or Perl scalars. In addition to serializing directly to files, Storable includes the freeze function to return a serialized copy of the data packed into a scalar, and thaw to deserialize such a scalar. This is useful for sending a complex data structure over a network socket or storing it in a database. When serializing structures with Storable, there are network safe functions that always store their data in a format that is readable on any computer at a small cost of speed. These functions are named nstore, nfreeze, etc. There are no "n" functions for deserializing these structures — the regular thaw and retrieve deserialize structures serialized with the "n" functions and their machine-specific equivalents.

PHP originally implemented serialization through the built-in serialize() and unserialize() functions.^[28] PHP can serialize any of its data types except resources (file pointers, sockets, etc.). The built-in unserialize() function is often dangerous when used on completely untrusted data.^[29] For objects, there are two "magic methods" that can be implemented within a class — __sleep() and __wakeup() — that are called from within serialize() and unserialize(), respectively, that can clean up and restore an object. For example, it may be desirable to close a database connection on serialization and restore the connection on deserialization; this functionality would be handled in these two magic methods. They also permit the object to pick which properties are serialized. Since PHP 5.1, there is an object-oriented serialization mechanism for objects, the Serializable interface.^[30]

Prolog's term structure, which is the only data structure of the language, can be serialized out through the built-in predicate write_term/3 and serialized-in through the built-in predicates read/1 and read_term/2. The resulting stream is uncompressed text (in some encoding determined by configuration of the target stream), with any free variables in the term represented by placeholder variable names. The predicate write_term/3 is standardized in the ISO Specification for Prolog (ISO/IEC 13211-1) on pages 59 ff. ("Writing a term, § 7.10.5"). Therefore it is expected that terms serialized-out by one implementation can be serialized-in by another without ambiguity or surprises. In practice, implementation-specific extensions (e.g. SWI-Prolog's dictionaries) may use non-standard term structures, so interoperability may break in edge cases. As examples, see the corresponding manual pages for SWI-Prolog,^[31] SICStus Prolog,^[32] GNU Prolog.^[33] Whether and how serialized terms received over the network are checked against a specification (after deserialization from the character stream has happened) is left to the implementer. Prolog's built-in Definite Clause Grammars can be applied at that stage.

กลไกการซีเรียลไลเซชันทั่วไปหลักคือ โมดูล pickleไลบรารีมาตรฐานซึ่งอ้างอิงถึงคำศัพท์ในระบบฐานข้อมูลที่เรียกว่าpickling ^{[ 34 ] [ 35 ] [ 36 ]}เพื่ออธิบายการซีเรียลไลเซชันข้อมูล ( unpicklingสำหรับการดีซีเรียลไลเซชัน ) Pickle ใช้เครื่องเสมือนแบบstack ที่เรียบง่ายซึ่งบันทึกคำสั่งที่ใช้ในการสร้างวัตถุขึ้นใหม่ เป็นรูปแบบการซีเรียลไลเซชัน ที่ปรับแต่งได้ข้ามเวอร์ชันแต่ไม่ปลอดภัย (ไม่ปลอดภัยจากข้อมูลที่ผิดพลาดหรือเป็นอันตราย) ข้อมูลที่ผิดรูปแบบหรือสร้างขึ้นอย่างเป็นอันตรายอาจทำให้ดีซีเรียลไลเซอร์นำเข้าโมดูลตามอำเภอใจและสร้างวัตถุใดๆ ก็ได้^{[ 37 ] [ 38 ]}ไลบรารีมาตรฐานยังรวมถึงโมดูลที่ซีเรียลไลซ์ไปยังรูปแบบข้อมูลมาตรฐาน: (พร้อมการสนับสนุนในตัวสำหรับประเภทสเกลาร์และคอลเลกชันพื้นฐานและสามารถรองรับประเภทตามอำเภอใจผ่านhook การเข้ารหัสและการถอดรหัส ) (พร้อมการสนับสนุนสำหรับรูปแบบ รายการคุณสมบัติทั้งแบบไบนารีและ XML ) (พร้อมการสนับสนุนสำหรับมาตรฐาน External Data Representation (XDR) ตามที่อธิบายไว้ใน RFC 1014) สุดท้ายนี้ ขอแนะนำให้ประเมินวัตถุในสภาพแวดล้อมที่เหมาะสม ซึ่งทำให้ตรงกับ Common Lisp โดยประมาณ ไม่ใช่วัตถุทุกประเภทที่จะสามารถจัดเก็บได้โดยอัตโนมัติ โดยเฉพาะอย่างยิ่งวัตถุที่เก็บ ทรัพยากร ของระบบปฏิบัติการเช่นตัวจัดการไฟล์แต่ผู้ใช้สามารถลงทะเบียนฟังก์ชัน "ลด" และการสร้างแบบกำหนดเองเพื่อรองรับการจัดเก็บและการยกเลิกการจัดเก็บข้อมูลของประเภทต่างๆ ได้ Pickle เดิมทีถูกนำไปใช้เป็นโมดูล Python บริสุทธิ์ แต่ในเวอร์ชันของ Python ก่อน 3.0 โมดูล (ซึ่งเป็นโมดูลในตัวเช่นกัน) ให้ประสิทธิภาพที่ดีขึ้น (เร็วขึ้นถึง 1000 เท่า^{[ 37 ]} ) ได้รับการดัดแปลงมาจาก โครงการ Unladen Swallowใน Python 3 ผู้ใช้ควรนำเข้าเวอร์ชันมาตรฐานเสมอ ซึ่งจะพยายามนำเข้าเวอร์ชันที่เร่งความเร็วและจะใช้เวอร์ชัน Python บริสุทธิ์หากไม่ได้ผล^{[ 39 ]}jsonplistlibxdrlib__repr__print-objectpicklecPicklecPickle

Rมีฟังก์ชันdputที่เขียนข้อความ ASCII ที่แสดงถึงวัตถุ R ลงในไฟล์หรือการเชื่อมต่อ สามารถอ่านการแสดงผลจากไฟล์ได้โดยใช้dget[ ^{40 ] โดย}เฉพาะอย่างยิ่ง ฟังก์ชันserializeจะแปลงวัตถุ R เป็นอนุกรมไปยังการเชื่อมต่อ โดยผลลัพธ์จะเป็นเวกเตอร์ดิบที่เข้ารหัสในรูปแบบเลขฐานสิบหกunserializeฟังก์ชันนี้อนุญาตให้อ่านวัตถุจากการเชื่อมต่อหรือเวกเตอร์ดิบได้^{[ 41 ]}

REBOL will serialize to file (save/all) or to a string! (mold/all). Strings and files can be deserialized using the polymorphicload function. RProtoBuf provides cross-language data serialization in R, using Protocol Buffers.^[42]

Ruby includes the standard module Marshal with 2 methods dump and load, akin to the standard Unix utilities dump and restore. These methods serialize to the standard class String, that is, they effectively become a sequence of bytes. Some objects cannot be serialized (doing so would raise a TypeError exception): bindings, procedure objects, instances of class IO, singleton objects and interfaces. If a class requires custom serialization (for example, it requires certain cleanup actions done on dumping / restoring), it can be done by implementing 2 methods: _dump and _load. The instance method_dump should return a String object containing all the information necessary to reconstitute objects of this class and all referenced objects up to a maximum depth given as an integer parameter (a value of -1 implies that depth checking should be disabled). The class method_load should take a String and return an object of this class.

Serde is the most widely used library, or crate, for serialization in Rust which provides the Serialize and Deserialize traits.

In general, non-recursive and non-sharing objects can be stored and retrieved in a human readable form using the storeOn:/readFrom: protocol. The storeOn: method generates the text of a Smalltalk expression which – when evaluated using readFrom: – recreates the original object. This scheme is special, in that it uses a procedural description of the object, not the data itself. It is therefore very flexible, allowing for classes to define more compact representations. However, in its original form, it does not handle cyclic data structures or preserve the identity of shared references (i.e. two references a single object will be restored as references to two equal, but not identical copies). For this, various portable and non-portable alternatives exist. Some of them are specific to a particular Smalltalk implementation or class library. There are several ways in Squeak Smalltalk to serialize and store objects. The easiest and most used are storeOn:/readFrom: and binary storage formats based on SmartRefStream serializers. In addition, bundled objects can be stored and retrieved using ImageSegments. Both provide a so-called "binary-object storage framework", which support serialization into and retrieval from a compact binary form. Both handle cyclic, recursive and shared structures, storage/retrieval of class and metaclass info and include mechanisms for "on the fly" object migration (i.e. to convert instances which were written by an older version of a class with a different object layout). The APIs are similar (storeBinary/readBinary), but the encoding details are different, making these two formats incompatible. However, the Smalltalk/X code is open source and free and can be loaded into other Smalltalks to allow for cross-dialect object interchange. Object serialization is not part of the ANSI Smalltalk specification. As a result, the code to serialize an object varies by Smalltalk implementation. The resulting binary data also varies. For instance, a serialized object created in Squeak Smalltalk cannot be restored in Ambrai Smalltalk. Consequently, various applications that do work on multiple Smalltalk implementations that rely on object serialization cannot share data between these different implementations. These applications include the MinneStore object database^[43] and some RPC packages. A solution to this problem is SIXX,^[44] which is a package for multiple Smalltalks that uses an XML-based format for serialization.

The Swift standard library provides two protocols, Encodable and Decodable (composed together as Codable), which allow instances of conforming types to be serialized to or deserialized from JSON, property lists, or other formats.^[45] Default implementations of these protocols can be generated by the compiler for types whose stored properties are also Decodable or Encodable.

PowerShell implements serialization through the built-in cmdlet Export-CliXML. Export-CliXML serializes .NET objects and stores the resulting XML in a file. To reconstitute the objects, use the Import-CliXML cmdlet, which generates a deserialized object from the XML in the exported file. Deserialized objects, often known as "property bags" are not live objects; they are snapshots that have properties, but no methods. Two dimensional data structures can also be (de)serialized in CSV format using the built-in cmdlets Import-CSV and Export-CSV.

• Commutation (telemetry)
• Comparison of data serialization formats
• Container format
• Hibernate (Java)
• XML Schema
• Basic Encoding Rules
• Google Protocol Buffers
• Wikibase
• Apache Avro

• เอกสารประกอบการซีเรียลไลเซชันอ็อบเจ็กต์ Java
• เอกสารประกอบการใช้ งานJava 1.4 Object Serialization
• Java ที่ทนทาน: การทำให้เป็นอนุกรม (Serialization) เก็บถาวรเมื่อวันที่ 25 พฤศจิกายน 2005 ที่Wayback Machine
• ทรัพยากรการผูกข้อมูล XML
• ดาต้าบอร์ด - การแปลงข้อมูลไบนารีเป็นอนุกรมด้วยการเข้าถึงบางส่วนและแบบสุ่ม ระบบประเภทข้อมูล RPC การปรับเปลี่ยนประเภทข้อมูล และรูปแบบข้อความ