Serialization

In computer science, in the context of data storage and transmission, serialization is the process of converting a data structure or object into a sequence of bits so that it can be stored in a file, a memory buffer, or transmitted across a network connection link to be "resurrected" later in the same or another computer environment. 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.

This process of serializing an object is also called deflating or marshalling an object. The opposite operation, extracting a data structure from a series of bytes, is deserialization (which is also called inflating or unmarshalling).

Uses

Serialization has a number of advantages. It provides:

• a method of persisting objects which is more convenient than writing their properties to a text file on disk, and re-assembling them by reading this back in.
• a method of issuing remote procedure calls, e.g., as in SOAP
• a method for distributing objects, especially in software componentry such as COM, CORBA, etc.
• a method for 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 that we do not suffer from 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 and the deserialization process includes a 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, since differences can be detected "on the fly". This is a way to understand the technique called differential execution. It 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.

Consequences

Serialization, however, breaks the opacity of an abstract data type by potentially exposing private implementation details. 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 and often provide methods of checking the consistency of any serialized stream when converting it back into an object.

Human-readable serialization

In the late 1990s, a push to provide an alternative to the standard serialization protocols started: XML 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. A future solution to this dilemma could be transparent compression schemes (see binary XML).

XML is today often used for asynchronous transfer of structured data between client and server in Ajax web applications. An alternative for this use case is JSON, a more lightweight text-based serialization protocol that uses JavaScript syntax but is supported in other programming languages as well.

Another alternative, YAML, is effectively a superset of JSON and includes features that make it more powerful for serialization, more "human friendly," and potentially more compact. These features include a notion of tagging data types, support for non-hierarchical data structures, the option to data structure with indentation, and multiple forms of scalar data quoting.

Another human-readable serialization format is the property list format used in NeXTSTEP, GNUstep, and Mac OS X Cocoa.

Scientific serialization

For large volume scientific datasets, such as satellite data and output of numerical climate, weather, or ocean models, specific binary serialization standards have been developed, e.g. HDF, netCDF and the older GRIB.

Programming language support

Several object-oriented programming languages directly support object serialization (or object archival), either by syntactic sugar elements or providing a standard interface for doing so.

Some of these programming languages are Ruby, Smalltalk, Python, PHP, Objective-C, Java, and the .NET family of languages.

Google's protocol buffers encode and decode structured data in an efficient and extensible format. Google uses Protocol Buffers for almost all of its internal RPC protocols and file formats. The serialized data are compatible among C++, Java, and Python.

There are also libraries available that add serialization support to languages that lack native support for it.

.NET Framework

In the .NET languages, classes can be serialized and deserialized by adding the Serializable attribute to the class.

'VB Example
<Serializable()> Class Employee

// C# Example
[Serializable]
class Employee

If new members are added to a serializable class, they can be tagged with the OptionalField attribute to allow previous versions of the object to be deserialized without error. This attribute affects only deserialization, and prevents the runtime from throwing an exception if a member is missing from the serialized stream. A member can also be marked with the NonSerialized attribute to indicate that it should not be serialized. This will allow the details of those members to be kept secret.

To modify the default deserialization (for example, to automatically initialize a member marked NonSerialized), the class must implement the IDeserializationCallback interface and define the IDeserializationCallback.OnDeserialization method.

Objects may be serialized in binary format for deserialization by other .NET applications. The framework also provides the SoapFormatter and XmlSerializer objects to support serialization in human-readable, cross-platform XML.

Objective-C

In the Objective-C programming language, serialization (more commonly known as archiving) is achieved by overriding the write: and read: methods in the Object root class. (NB This is in the GNU runtime variant of Objective-C. In the NeXT-style runtime, the implementation is very similar.)

Example

The following example demonstrates two independent programs, a "sender", who takes the current time (as per time in the C standard library), archives it, and prints the archived form to the standard output; and a "receiver" which decodes the archived form, reconstructs the time, and prints it out.

When compiled, we get a sender program and a receiver program. If we just execute the sender program, we will get out a serialization that looks like:

GNU TypedStream 1D@îC¡

(with a NULL character after the 1). If we pipe the two programs together, as sender | receiver, we get

received 1089356705

showing the object was serialized, sent, and reconstructed properly.

In essence, the sender and receiver programs could be distributed across a network connection, providing distributed object capabilities.

Sender.h

#import <objc/Object.h>
#import <time.h>
#import <stdio.h>

@interface Sender : Object
{
   time_t  current_time;
}

- (id) setTime;
- (time_t) time;
- (id) send;
- (id) read: (TypedStream *) s;
- (id) write: (TypedStream *) s;

@end

Sender.m

#import "Sender.h"

@implementation Sender
- (id) setTime
{
   //Set the time
   current_time = time(NULL);
   return self;
}

- (time_t) time;
{
   return current_time;
}

- (id) write: (TypedStream *) stream
{
   /*
    *Write the superclass to the stream.
    *We do this so we have the complete object hierarchy,
    *not just the object itself.
    */
   [super write:stream];

   /*
    *Write the current_time out to the stream.
    *time_t is typedef for an integer.
    *The second argument, the string "i", specifies the types to write
    *as per the @encode directive.
    */
   objc_write_types(stream, "i", &current_time);
   return self;
}

- (id) read: (TypedStream *) stream
{
   /*
    *Do the reverse to write: - reconstruct the superclass...
    */
   [super read:stream];

   /*
    *And reconstruct the instance variables from the stream...
    */
   objc_read_types(stream, "i", &current_time);
   return self;
}

- (id) send
{
   //Convenience method to do the writing. We open stdout as our byte stream
   TypedStream *s = objc_open_typed_stream(stdout, OBJC_WRITEONLY);

   //Write the object to the stream
   [self write:s];

   //Finish up — close the stream.
   objc_close_typed_stream(s);
}
@end

Sender.c

#import "Sender.h"

int
main(void)
{
   Sender *s = [Sender new];
   [s setTime];
   [s send];

   return 0;
}

Receiver.m

#import "Receiver.h"

@implementation Receiver

- (id) receive
{
   //Open stdin as our stream for reading.
   TypedStream *s = objc_open_typed_stream(stdin, OBJC_READONLY);

   //Allocate memory for, and instantiate the object from reading the stream.
   t = [[Sender alloc] read:s];
   objc_close_typed_stream(s);
}

- (id) print
{
   fprintf(stderr, "received %d\n", [t time]);
}

@end

Receiver.c

#import "Receiver.h"

int
main(void)
{
   Receiver *r = [Receiver new];
   [r receive];
   [r print];

   return 0;
}

Java

Java provides automatic serialization which requires that the object be marked by implementing the Template:Javadoc:SE interface. Implementing the interface marks the class as "okay to serialize," and Java then handles serialization internally. There are no serialization methods defined on the Serializable interface, but a serializable class can optionally define methods with certain special names and signatures that if defined, will be called as part of the serialization/deserialization process. The language also allows the developer to override the serialization process more thoroughly by implementing another interface, the Template:Javadoc:SE interface, which includes two special methods that are used to save and restore the object's state.

There are three primary reasons why objects are not serializable by default and must implement the Serializable interface to access Java's serialization mechanism.

1. Not all objects capture useful semantics in a serialized state. For example, a Template:Javadoc:SE object is tied to the state of the current JVM. There is no context in which a deserialized Thread object would maintain useful semantics.
2. The serialized state of an object forms part of its class's compatibility contract. Maintaining compatibility between versions of serializable classes requires additional effort and consideration. Therefore, making a class serializable needs to be a deliberate design decision and not a default condition.
3. Serialization allows access to non-transient private members of a class that are not otherwise accessible. Classes containing sensitive information (for example, a password) should not be serializable or externalizable.

The standard encoding method uses a simple translation of the fields into a byte stream. Primitives as well as non-transient, non-static referenced objects are encoded into the stream. Each object that is referenced by the serialized object and not marked as transient must also be serialized; and if any object in the complete graph of non-transient object references is not serializable, then serialization will fail. The developer can influence this behavior by marking objects as transient, or by redefining the serialization for an object so that some portion of the reference graph is truncated and not serialized.

It is possible to serialize Java objects through JDBC and store them into a database.

While Swing components do implement the Serializable interface, they are not portable between different versions of the Java Virtual Machine. As such, a Swing component, or any component which inherits it, may be serialized to an array of bytes, but it is not guaranteed that this storage will be readable on another machine.

Example

import java.io.*;

/**
 * The object to serialize.
 */
class ObjectToSerialize implements Serializable {
    static private final long serialVersionUID = 42L;

    private String firstAttribute;
    private int secondAttribute;

    public ObjectToSerialize(String firstAttribute, int secondAttribute) {
        this.firstAttribute = firstAttribute;
        this.secondAttribute = secondAttribute;
    }

    @Override
    public String toString() {
        return firstAttribute + ", " + secondAttribute;
    }
}

public class Main {
    /**
     * Saves an object.
     */
    private static void saveObject(Serializable object, String filename) throws IOException {
        ObjectOutputStream objstream = new ObjectOutputStream(new FileOutputStream(filename));
        objstream.writeObject(object);
        objstream.close();
    }

    /**
     * Loads an object.
     */
    private static Object loadObject(String filename) throws ClassNotFoundException, IOException {
        ObjectInputStream objstream = new ObjectInputStream(new FileInputStream(filename));
        Object object = objstream.readObject();
        objstream.close();
        return object;
    }

    public static void main(String[] args) {
        ObjectToSerialize original = new ObjectToSerialize("some text", 123);
        System.out.println(original);
        try {
            saveObject(original, "object.ser");
            ObjectToSerialize loaded = (ObjectToSerialize) loadObject("object.ser");
            System.out.println(loaded);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

ColdFusion

ColdFusion allows data structures to be serialized to WDDX with the <cfwddx> tag.

OCaml

OCaml's standard library provides marshalling through the Marshal module (its documentation) 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 the exact same program.)

Perl

Several Perl modules available from CPAN provide serialization mechanisms, including Storable and FreezeThaw.

Storable includes functions to serialize and deserialize Perl data structures to and from files or Perl scalars.

use Storable;

# Create a hash with some nested data structures
my %struct = ( text => 'Hello, world!', list => [1, 2, 3] );

# Serialize the hash into a file
store \%struct, 'serialized';

# Read the data back later
my $newstruct = retrieve 'serialized';

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.

C

The tpl library supports serializing C data structures into an efficient, native binary representation. The serialized data can be reversibly converted to a human-readable XML representation.

The open source gSOAP toolkit provides serialization of C data structures in XML using a C data binding for XML schema. The toolkit supports SOAP, WSDL and XSD specifications.

The c11n ("cerialization") project is a C variant of the libs11n C++ library, geared towards serializing client-side C objects. c11n is internally ignorant of any file formats and provides handlers for several different ones (e.g. XML, SQL, and custom formats).

C++

Boost Serialization, libs11n, Sweet Persist, and Google Protocol Buffers are libraries that provide support for serialization from within the C++ language itself. They all integrate well with the C++ Standard Library. Boost Serialization supports serialization in XML, text and binary formats. Sweet Persist supports serialization in XML, JSON, Lua, and binary formats. The libs11n library supports serialization to and from several text formats (including 3 flavors of XML) as well as sqlite3. Google Protocol Buffers supports serialization to a binary format.

The Microsoft Foundation Class Library has comprehensive support for serialization to a binary format. It doesn't have support for the STL but does support its own containers.

Alternatively XML Data Binding implementations, like XML Schema to C++ data binding compiler and gSOAP, provide support for serialization to and from XML by generating C++ source code from an intermediate specification (e.g. an XML schema).

Ebenezer Enterprises provides an on line service that writes efficient C++ marshalling code.

Python

Python implements serialization through the standard library module pickle, and to a lesser extent, the older marshal modules. marshal does offer the ability to serialize Python code objects, unlike pickle.

PHP

PHP implements serialization through the built-in serialize and unserialize functions. PHP can serialize any of its data types except resources (file pointers, sockets, etc.).

For objects (as of at least PHP 4) 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.

As of PHP 5.1.0 there's another method to hook into internal serialize/unserialize mechanism - Serializable interface .

REBOL

REBOL will serialize to file (save/all) or to a string! (mold/all). Strings and files can be deserialized using the polymorphic load function.

Ruby

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 can't be serialized (doing so would raise a TypeError exception):

• bindings,
• procedure objects,
• instances of class IO,
• singleton objects

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.

class Klass
  def initialize(str)
    @str = str
  end
  def sayHello
    @str
  end
end

o = Klass.new("hello\n")
data = Marshal.dump(o)
obj = Marshal.load(data)
obj.sayHello   »  "hello\n"

SeriaLizer

SL was introduced in 2009 under the GPL license. Made to allow communication between cross-platform and cross-language applications. This also to be done easily and with as little overhead as possible. A more detailed description and some examples can be found at the SeriaLizer website.

Smalltalk

Squeak Smalltalk

There are several ways in Squeak Smalltalk to serialize and store objects. The easiest and most used method will be shown below. Other classes of interest in Squeak for serializing objects are SmartRefStream and ImageSegment.

To store a Dictionary (sometimes called a hash map in other languages) containing some nonsense data of varying types into a file named "data.obj":

| data rr |
data := Dictionary new.
data at: #Meef put: 25;
 at: 23 put: 'Amanda';
 at: 'Small Numbers' put: #(0 1 2 3 four).
rr := ReferenceStream fileNamed: 'data.obj'.
rr nextPut: data; close.

To restore the Dictionary object stored in "data.obj" and bring up an inspector containing the data:

| restoredData rr |
rr := ReferenceStream fileNamed: 'data.obj'.
restoredData := rr next.
restoredData inspect.
rr close.

Other Smalltalk dialects

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 [1] and some RPC packages. A solution to this problem is SIXX [2], which is an package for multiple Smalltalks that uses an XML-based format for serialization.

Lisp

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: (4 2.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. See REPL.

There are also binary serialization libraries like cl-store and cl-serializer.

Haskell

In Haskell, serialization is supported for types by inheritance of the Read and Show type classes. Every type that inherits the Read class defines a function that will extract the data from the string representation of the dumped data. The Show class, in turn, contains the show function from which a string representation of the object can be generated.

The programmer need not define the functions explicitly -- merely declaring a type to be deriving Read or deriving Show, or both, will make the compiler generate the appropriate functions.

Windows PowerShell

Windows 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.

# Create a hash with some nested data structures
$struct = @{text = 'Hello, world!'; list = 1,2,3}

# Serialize the hash into an XML file
$struct | Export-CliXML serialized.xml

# Read the data back later
$newstruct = Import-CliXML serialized.xml

The serialized data structures are stored in XML format:

<Objs Version="1.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">
  <Obj RefId="RefId-0">
    <TN RefId="RefId-0">
      <T>System.Collections.Hashtable</T>
      <T>System.Object</T>
    </TN>
    <DCT>
      <En>
        <S N="Key">text</S>
        <S N="Value">Hello, world!</S>
      </En>
      <En>
        <S N="Key">list</S>
        <Obj N="Value" RefId="RefId-1">
          <TN RefId="RefId-1">
            <T>System.Object[]</T>
            <T>System.Array</T>
            <T>System.Object</T>
          </TN>
          <LST>
            <I32>1</I32>
            <I32>2</I32>
            <I32>3</I32>
          </LST>
        </Obj>
      </En>
    </DCT>
  </Obj>
</Objs>

Two dimensional data structures can also be (de)serialized in CSV format using the built-in cmdlets Import-CSV and Export-CSV.

See also

• Differential Execution
• Hibernate (Java)
• Persistor.NET
• XML Schema

External links

For Java:

• Java Object Serialization documentation
• Java 1.4 Object Serialization documentation.
• Java Object Serialization Specification
• Java Object Serialization
• Durable Java: Serialization
• XML Data Binding Resources

For C:

• c11n

For C++:

• Serialization and Unserialization
• Boost Serialization
• s11n
• Sweet Persist
• Dynamic Dialogs

For PHP:

• Recovering Truncated PHP Serialized Arrays

For Protocol Buffers (C++, Java, Python):

• Google Protocol Buffers Developer Guide