Serialização

Na computação, serialização (ou serialização) é o processo de traduzir uma estrutura de dados ou estado de objeto em um formato que pode ser armazenado (por exemplo, arquivos em dispositivos de armazenamento secundário, buffers de dados em dispositivos de armazenamento primário) ou transmitidos (por exemplo, fluxos de dados em redes de computadores) e reconstruídos posteriormente (possivelmente em um ambiente de computador diferente). Quando a série de bits resultante é relida de acordo com o formato de serialização, ela pode ser usada para criar um clone semanticamente idêntico do objeto original. Para muitos objetos complexos, como aqueles que fazem uso extensivo de referências, esse processo não é simples. A serialização de objetos orientados a objetos não inclui nenhum dos métodos associados aos quais estavam vinculados anteriormente.

Este processo de serialização de um objeto também é chamado de empacotamento de um objeto em algumas situações. A operação oposta, extrair uma estrutura de dados de uma série de bytes, é a desserialização (também chamada de desserialização ou desserialização).

Usos

Exemplos de aplicativos de serialização incluem métodos como:

• serializando dados para transferência através de fios e redes (mensagem).
• armazenar dados (em bancos de dados, em discos rígidos).
• Chamadas de procedimento remoto, por exemplo, como em SOAP.
• distribuindo objetos, especialmente em engenharia de software baseada em componentes, como COM, CORBA, etc.
• detectando mudanças nos dados de tempo-varying.

Para que alguns desses recursos sejam úteis, a independência da arquitetura deve ser mantida. Por exemplo, para uso máximo da distribuição, um computador rodando em uma arquitetura de hardware diferente deve ser capaz de reconstruir de forma confiável um fluxo de dados serializado, independentemente do endianness. Isto significa que o procedimento mais simples e rápido de copiar diretamente o layout de memória da estrutura de dados não pode funcionar de forma confiável para todas as arquiteturas. Serializar a estrutura de dados em um formato independente de arquitetura significa evitar problemas de ordenação de bytes, layout de memória ou simplesmente diferentes formas de representar estruturas de dados em diferentes linguagens de programação.

Inerente a qualquer esquema de serialização é que, como a codificação dos dados é por definição serial, a extração de uma parte da estrutura de dados serializada requer que todo o objeto seja lido do início ao fim e reconstruído. Em muitas aplicações, essa linearidade é uma vantagem, pois permite que interfaces de E/S simples e comuns sejam utilizadas para manter e transmitir o estado de um objeto. Em aplicações onde o desempenho superior é um problema, pode fazer sentido despender mais esforço para lidar com uma organização de armazenamento não linear mais complexa.

Mesmo em uma única máquina, os objetos ponteiros primitivos são muito frágeis para serem salvos porque os objetos para os quais eles apontam podem ser recarregados em um local diferente na memória. Para lidar com isso, o processo de serialização inclui uma etapa chamada unswizzling ou unswizzling de ponteiro, onde referências diretas de ponteiro são convertidas em referências baseadas no nome ou posição. O processo de desserialização inclui uma etapa inversa chamada swizzling de ponteiro.

Como a serialização e a desserialização podem ser conduzidas a partir de código comum (por exemplo, a função Serialize no Microsoft Foundation Classes), é possível que o código comum faça as duas coisas ao mesmo tempo, e assim, 1) detecta diferenças entre os objetos que estão sendo serializados e suas cópias anteriores e 2) fornece a entrada para a próxima detecção. Na verdade, não é necessário construir a cópia anterior porque as diferenças podem ser detectadas instantaneamente, uma técnica chamada execução diferencial. Isso é útil na programação de interfaces de usuário cujo conteúdo varia no tempo — objetos gráficos podem ser criados, removidos, alterados ou transformados para lidar com eventos de entrada sem necessariamente ter que escrever um código separado para fazer essas coisas.

Desvantagens

A serialização quebra a opacidade de um tipo de dados abstrato, expondo potencialmente detalhes de implementação privada. Implementações triviais que serializam todos os membros dos dados podem violar o encapsulamento.

Para desencorajar os concorrentes de fabricar produtos compatíveis, os editores de software proprietário muitas vezes mantêm os detalhes de seus programas & #39; a serialização formata um segredo comercial. Alguns ofuscam deliberadamente ou até mesmo criptografam os dados serializados. No entanto, a interoperabilidade exige que os aplicativos sejam capazes de compreender os formatos de serialização uns dos outros. Portanto, arquiteturas de chamadas de métodos remotos como CORBA definem detalhadamente seus formatos de serialização.

Muitas instituições, como arquivos e bibliotecas, tentam preparar seus arquivos de backup para o futuro — em particular, dumps de banco de dados — armazenando-os em algum formato serializado relativamente legível por humanos.

Formatos de serialização

A tecnologia Xerox Network Systems Courier do início da década de 1980 influenciou o primeiro padrão amplamente adotado. A Sun Microsystems publicou o External Data Representation (XDR) em 1987. XDR é um formato aberto e padronizado como STD 67 (RFC 4506).

No final da década de 1990, começou um esforço para fornecer uma alternativa aos protocolos de serialização padrão: XML, um subconjunto SGML, foi usado para produzir uma codificação baseada em texto legível por humanos. Tal codificação pode ser útil para objetos persistentes que podem ser lidos e compreendidos por humanos ou comunicados a outros sistemas, independentemente da linguagem de programação. Ele tem a desvantagem de perder a codificação mais compacta baseada em fluxo de bytes, mas a essa altura maiores capacidades de armazenamento e transmissão tornavam o tamanho do arquivo menos preocupante do que nos primeiros dias da computação. Na década de 2000, o XML era frequentemente usado para transferência assíncrona de dados estruturados entre cliente e servidor em aplicações web Ajax. XML é um formato aberto e padronizado como recomendação do W3C.

JSON é uma alternativa leve de texto simples ao XML e também é comumente usado para comunicação cliente-servidor em aplicações web. JSON é baseado na sintaxe JavaScript, mas é independente de JavaScript e tem suporte em muitas outras linguagens de programação. JSON é um formato aberto, padronizado como STD 90 (RFC 8259), ECMA-404 e ISO/IEC 21778:2017.

YAML é um superconjunto estrito de JSON e inclui recursos adicionais, como tags de tipo de dados, suporte para estruturas de dados cíclicas, sintaxe sensível à indentação e múltiplas formas de citação de dados escalares. YAML é um formato aberto.

As listas de propriedades são usadas para serialização pelas estruturas NeXTSTEP, GNUstep, macOS e iOS. Lista de propriedades, ou p-list, abreviadamente, não se refere a um único formato de serialização, mas sim a várias variantes diferentes, algumas legíveis por humanos e uma binária.

Para conjuntos de dados científicos de grande volume, como dados de satélite e resultados de modelos numéricos climáticos, meteorológicos ou oceânicos, foram desenvolvidos padrões específicos de serialização binária, por exemplo. HDF, netCDF e o antigo GRIB.

Suporte a linguagens de programação

Várias linguagens de programação orientadas a objetos suportam diretamente a serialização de objetos (ou arquivamento de objetos), seja por meio de elementos sintáticos ou fornecendo uma interface padrão para fazer isso. As linguagens que fazem isso incluem Ruby, Smalltalk, Python, PHP, Objective-C, Delphi, Java e a família de linguagens.NET. Também existem bibliotecas disponíveis que adicionam suporte de serialização a linguagens que não possuem suporte nativo para ela.

C e C++

C e C++ não fornecem serialização como qualquer tipo de construção de alto nível, mas ambas as linguagens suportam a gravação de qualquer um dos tipos de dados integrados, bem como estruturas de dados simples e antigas, como dados binários. Como tal, geralmente é trivial escrever funções de serialização personalizadas. Além disso, soluções baseadas em compilador, como o sistema ODB ORM para C++ e o kit de ferramentas gSOAP para C e C++, são capazes de produzir automaticamente código de serialização com poucas ou nenhuma modificação nas declarações de classe. Outras estruturas de serialização populares são Boost.Serialization do Boost Framework, a estrutura S11n e Cereal. A estrutura MFC (Microsoft) também fornece metodologia de serialização como parte de sua arquitetura Document-View.

CFML

CFML permite que estruturas de dados sejam serializadas para WDDX com a tag e para JSON com a função SerializeJSON().

Delphi

O Delphi fornece um mecanismo integrado para serialização de componentes (também chamados de objetos persistentes), que é totalmente integrado ao seu IDE. O conteúdo do componente é salvo em um arquivo DFM e recarregado instantaneamente.

Vá

Go suporta nativamente desempacotamento/empacotamento de dados JSON e XML. Existem também módulos de terceiros que suportam YAML e buffers de protocolo. Go também suporta Gobs.

Haskell

Em Haskell, a serialização é suportada para tipos que são membros das classes de tipo Read e Show. Cada tipo que é membro da classe de tipo Read define uma função que extrairá os dados da representação em string dos dados despejados. A classe do tipo Show, por sua vez, contém a função show a partir da qual uma representação em string do objeto pode ser gerada. O programador não precisa definir as funções explicitamente - simplesmente declarar um tipo como derivado de Read ou derivado de Show, ou ambos, pode fazer o compilador gerar as funções apropriadas para muitos casos (mas não todos: tipos de função, por exemplo, não podem derivar automaticamente Show ou Ler). A instância gerada automaticamente para Show também produz código-fonte válido, portanto, o mesmo valor Haskell pode ser gerado executando o código produzido por show, por exemplo, em um interpretador Haskell. Para uma serialização mais eficiente, existem bibliotecas haskell que permitem serialização de alta velocidade em formato binário, por ex. binário.

Java

Java fornece serialização automática que requer que o objeto seja marcado pela implementação da interface java.io.Serializable. A implementação da interface marca a classe como “OK para serializar” e o Java então trata a serialização internamente. Não há métodos de serialização definidos na interface Serializable, mas uma classe serializável pode opcionalmente definir métodos com certos nomes e assinaturas especiais que, se definidos, serão chamados como parte do processo de serialização/desserialização. A linguagem também permite que o desenvolvedor substitua o processo de serialização de forma mais completa, implementando outra interface, a interface Externalizable, que inclui dois métodos especiais que são usados para salvar e restaurar o estado do objeto.< br/> Existem três razões principais pelas quais os objetos não são serializáveis por padrão e devem implementar a interface Serializable para acessar o mecanismo de serialização do Java.
Em primeiro lugar, nem todos os objetos capturam semântica útil em um estado serializado. Por exemplo, um objeto Thread está vinculado ao estado da JVM atual. Não há contexto no qual um objeto Thread desserializado manteria uma semântica útil.
Em segundo lugar, o estado serializado de um objeto faz parte de sua classe' contrato de compatibilidade. Manter a compatibilidade entre versões de classes serializáveis requer esforço e consideração adicionais. Portanto, tornar uma classe serializável precisa ser uma decisão deliberada de design e não uma condição padrão.
Por último, a serialização permite acesso a membros privados não transitórios de uma classe que não seriam acessíveis de outra forma. Classes contendo informações confidenciais (por exemplo, uma senha) não devem ser serializáveis nem externalizáveis. O método de codificação padrão usa uma tradução recursiva baseada em gráfico do descritor de classe do objeto e campos serializáveis em um fluxo de bytes. Objetos referenciados primitivos e não transitórios e não estáticos são codificados no fluxo. Cada objeto referenciado pelo objeto serializado por meio de um campo que não esteja marcado como transient também deve ser serializado; e se algum objeto no gráfico completo de referências de objetos não transitórios não for serializável, a serialização falhará. O desenvolvedor pode influenciar esse comportamento marcando objetos como transitórios ou redefinindo a serialização de um objeto para que alguma parte do gráfico de referência seja truncada e não serializada.
Java não usa construtor para serializar objetos. É possível serializar objetos Java através de JDBC e armazená-los em um banco de dados. Embora os componentes Swing implementem a interface Serializable, não é garantido que eles sejam portáveis entre diferentes versões da Java Virtual Machine. Como tal, um componente Swing, ou qualquer componente que o herde, pode ser serializado em um fluxo de bytes, mas não é garantido que isso será reconstituível em outra máquina.

JavaScript

Desde ECMAScript 5.1, JavaScript inclui o objeto JSON integrado e seus métodos JSON.parse() e JSON.stringify(). Embora JSON seja originalmente baseado em um subconjunto de JavaScript, há casos limites em que JSON não é JavaScript válido. Especificamente, JSON permite terminadores de linha Unicode U+2028 LINE SEPARADOR e U+2029 SEPARADOR DE PARÁGRAFO< /span> apareça sem escape nas strings entre aspas, enquanto o ECMAScript 2018 e anteriores não. Veja o artigo principal sobre JSON.

Júlia

Julia implementa serialização através dos módulos serialize() / deserialize(), destinados a funcionar dentro da mesma versão de Julia e/ou instância da mesma imagem do sistema. O pacote HDF5.jl oferece uma alternativa mais estável, usando um formato documentado e uma biblioteca comum com wrappers para diferentes linguagens, enquanto sugere-se que o formato de serialização padrão tenha sido projetado com desempenho máximo para comunicação de rede em mente.

Lisp

Geralmente uma estrutura de dados Lisp pode ser serializada com as funções "read" e "imprimir". Uma variável foo contendo, por exemplo, uma lista de arrays seria impressa por (print foo). Da mesma forma, um objeto pode ser lido de um fluxo chamado s por (read s). Essas duas partes da implementação do Lisp são chamadas de Impressora e Leitor. A saída de "print" é legível por humanos; usa listas delimitadas por parênteses, por exemplo: (4 2,9 "x" y< /span>). Em muitos tipos de Lisp, incluindo Common Lisp, a impressora não pode representar todos os tipos de dados porque não está claro como fazê-lo. No Common Lisp, por exemplo, a impressora não pode imprimir objetos CLOS. Em vez disso, o programador pode escrever um método na função genérica print-object, que será invocado quando o objeto for impresso. Isso é um pouco semelhante ao método usado em Ruby. O próprio código Lisp é escrito na sintaxe do leitor, chamada sintaxe de leitura. A maioria das linguagens usa analisadores separados e diferentes para lidar com código e dados, o Lisp usa apenas um. Um arquivo contendo código lisp pode ser lido na memória como uma estrutura de dados, transformado por outro programa e, em seguida, possivelmente executado ou gravado, como em um loop read-eval-print. Nem todos os leitores/escritores suportam estruturas cíclicas, recursivas ou compartilhadas.

.NET Framework

O.NET Framework possui vários serializadores projetados pela Microsoft. Existem também muitos serializadores de terceiros. Mais de uma dúzia de serializadores são discutidos e testados aqui. e aqui

OCaml

A biblioteca padrão do OCaml fornece empacotamento através do módulo Marshal e das funções Pervasives output_value e input_value. Embora a programação OCaml seja estaticamente verificada por tipo, o uso do módulo Marshal pode quebrar as garantias de tipo, pois não há como verificar se um fluxo não empacotado representa objetos do tipo esperado. No OCaml é difícil empacotar uma função ou estrutura de dados que contém uma função (por exemplo, um objeto que contém um método), porque o código executável em funções não pode ser transmitido entre programas diferentes. (Existe um sinalizador para empacotar a posição do código de uma função, mas ela só pode ser desempacotada exatamente no mesmo programa). As funções de empacotamento padrão podem preservar o compartilhamento e manipular dados cíclicos, que podem ser configurados por um sinalizador.

Perl

Vários módulos Perl disponíveis no CPAN fornecem mecanismos de serialização, incluindo Storable JSON::XS e FreezeThaw. Armazenável inclui funções para serializar e desserializar estruturas de dados Perl de e para arquivos ou escalares Perl. Além de serializar diretamente em arquivos, Storable inclui a função freeze para retornar uma cópia serializada dos dados compactados em um escalar e thaw para desserializar tal escalar. Isto é útil para enviar uma estrutura de dados complexa através de um soquete de rede ou armazená-la em um banco de dados. Ao serializar estruturas com Storable, existem funções seguras de rede que sempre armazenam seus dados em um formato que pode ser lido em qualquer computador com um pequeno custo de velocidade. Essas funções são denominadas nstore, nfreeze, etc. funções para desserializar essas estruturas - as estruturas regulares de desserialização thaw e recuperar serializadas com o "n" funções e seus equivalentes específicos da máquina.

PHP

O PHP implementou originalmente a serialização através das funções integradas serialize() e unserialize(). PHP pode serializar qualquer um de seus tipos de dados, exceto recursos (ponteiros de arquivo, soquetes, etc.). A função interna unserialize() costuma ser perigosa quando usada em dados completamente não confiáveis. Para objetos, existem dois "métodos mágicos" que podem ser implementados em uma classe — __sleep() e __wakeup() — que são chamados de serialize() e unserialize (), respectivamente, que podem limpar e restaurar um objeto. Por exemplo, pode ser desejável fechar uma conexão com o banco de dados na serialização e restaurar a conexão na desserialização; esta funcionalidade seria tratada nesses dois métodos mágicos. Eles também permitem que o objeto escolha quais propriedades serão serializadas. Desde o PHP 5.1, existe um mecanismo de serialização orientado a objetos para objetos, a interface Serializable.

Prólogo

Prolog, que é a única estrutura de dados da linguagem, pode ser serializada através do predicado integrado write_term/3 e serializada -in por meio dos predicados integrados read/1 e read_term/2. O fluxo resultante é texto não compactado (em alguma codificação determinada pela configuração do fluxo de destino), com quaisquer variáveis livres no termo representadas por nomes de variáveis de espaço reservado. O predicado write_term/3 é padronizado na Especificação ISO para Prolog (ISO/IEC 13211-1) nas páginas 59 e seguintes. ("Escrevendo um termo, § 7.10.5"). Portanto, espera-se que os termos serializados por uma implementação possam ser serializados por outra sem ambigüidades ou surpresas. Na prática, extensões específicas de implementação (por exemplo, dicionários SWI-Prolog) podem usar estruturas de termos não padronizadas, de modo que a interoperabilidade pode ser interrompida em casos extremos. Como exemplos, consulte as páginas de manual correspondentes para SWI-Prolog, SICStus Prolog, GNU Prolog. Se e como os termos serializados recebidos pela rede são verificados em relação a uma especificação (após a desserialização do fluxo de caracteres ter ocorrido) é deixado para o implementador. As gramáticas de cláusulas definidas integradas do Prolog podem ser aplicadas nesse estágio.

Python

O principal mecanismo de serialização geral é o módulo de biblioteca padrão pickle, aludindo ao termo de sistemas de banco de dados pickling para descrever a serialização de dados (unpickling para desserializando). Pickle usa uma máquina virtual simples baseada em pilha que registra as instruções usadas para reconstruir o objeto. É um formato de serialização personalizável entre versões, mas inseguro (não seguro contra dados errados ou maliciosos). Dados malformados ou construídos de forma maliciosa podem fazer com que o desserializador importe módulos arbitrários e instancie qualquer objeto. A biblioteca padrão também inclui módulos serializados para formatos de dados padrão: json (com suporte integrado para tipos escalares e de coleção básicos e capaz de suportar tipos arbitrários por meio de ganchos de codificação e decodificação). plistlib (com suporte para formatos de lista de propriedades binárias e XML). xdrlib (com suporte para o padrão de Representação de Dados Externos (XDR), conforme descrito na RFC 1014). Finalmente, é recomendado que o __repr__ de um objeto seja avaliável no ambiente certo, tornando-o uma correspondência aproximada para o print-object do Common Lisp. Nem todos os tipos de objetos podem ser selecionados automaticamente, especialmente aqueles que contêm recursos do sistema operacional, como identificadores de arquivos, mas os usuários podem registrar "redução" e funções de construção para apoiar a decapagem e decapagem de tipos arbitrários. Pickle foi originalmente implementado como o módulo pickle puro do Python, mas, em versões do Python anteriores a 3.0, o módulo cPickle (também integrado) oferece desempenho aprimorado (até até 1000 vezes mais rápido). O cPickle foi adaptado do projeto Unladen Swallow. No Python 3, os usuários devem sempre importar a versão padrão, que tenta importar a versão acelerada e volta para a versão pura do Python.

R

R tem a função dput que grava uma representação de texto ASCII de um objeto R em um arquivo ou conexão. Uma representação pode ser lida de um arquivo usando dget. Mais especificamente, a função serialize serializa um objeto R para uma conexão, sendo a saída um vetor bruto codificado em formato hexadecimal. A função unserialize permite ler um objeto de uma conexão ou de um vetor bruto.

REBOL

REBOL será serializado em arquivo (save/all) ou em string! (mold/all). Strings e arquivos podem ser desserializados usando a função polimórfica load. RProtoBuf fornece serialização de dados entre linguagens em R, usando buffers de protocolo.

Rubi

Ruby inclui o módulo padrão Marshal com 2 métodos dump e load, semelhantes aos utilitários padrão do Unix dump e restaurar. Esses métodos são serializados na classe padrão String, ou seja, eles efetivamente se tornam uma sequência de bytes. Alguns objetos não podem ser serializados (isso geraria uma exceção TypeError): ligações, objetos de procedimento, instâncias de classe IO, objetos singleton e interfaces. Se uma classe requer serialização personalizada (por exemplo, requer certas ações de limpeza feitas no despejo/restauração), isso pode ser feito implementando 2 métodos: _dump e _load. O método de instância _dump deve retornar um objeto String contendo todas as informações necessárias para reconstituir os objetos desta classe e todos os objetos referenciados até uma profundidade máxima dada como um parâmetro inteiro (um o valor -1 implica que a verificação de profundidade deve ser desabilitada). O método de classe _load deve pegar uma String e retornar um objeto desta classe.

Ferrugem

Serde é a biblioteca, ou crate, mais amplamente usada para serialização em Rust.

Conversa fiada

Em geral, objetos não recursivos e não compartilhados podem ser armazenados e recuperados em um formato legível por humanos usando o protocolo storeOn:/readFrom:. O método storeOn: gera o texto de uma expressão Smalltalk que – quando avaliada usando readFrom: – recria o objeto original. Este esquema é especial porque utiliza uma descrição processual do objeto, e não os dados em si. É, portanto, muito flexível, permitindo que as classes definam representações mais compactas. No entanto, em sua forma original, ele não trata estruturas de dados cíclicas nem preserva a identidade de referências compartilhadas (ou seja, duas referências de um único objeto serão restauradas como referências a duas cópias iguais, mas não idênticas). Para isso, existem diversas alternativas portáteis e não portáteis. Alguns deles são específicos para uma implementação ou biblioteca de classes específica do Smalltalk. Existem várias maneiras no Squeak Smalltalk de serializar e armazenar objetos. Os mais fáceis e mais usados são storeOn:/readFrom: e formatos de armazenamento binário baseados em serializadores SmartRefStream. Além disso, objetos agrupados podem ser armazenados e recuperados usando ImageSegments. Ambos fornecem a chamada “estrutura de armazenamento de objetos binários”, que suporta serialização e recuperação de um formato binário compacto. Ambos lidam com estruturas cíclicas, recursivas e compartilhadas, armazenamento/recuperação de informações de classes e metaclasses e incluem mecanismos para execução "on the fly" migração de objetos (ou seja, para converter instâncias que foram escritas por uma versão mais antiga de uma classe com um layout de objeto diferente). As APIs são semelhantes (storeBinary/readBinary), mas os detalhes de codificação são diferentes, tornando esses dois formatos incompatíveis. No entanto, o código Smalltalk/X é de código aberto e gratuito e pode ser carregado em outros Smalltalks para permitir o intercâmbio de objetos entre dialetos. A serialização de objetos não faz parte da especificação ANSI Smalltalk. Como resultado, o código para serializar um objeto varia de acordo com a implementação do Smalltalk. Os dados binários resultantes também variam. Por exemplo, um objeto serializado criado no Squeak Smalltalk não pode ser restaurado no Ambrai Smalltalk. Conseqüentemente, vários aplicativos que funcionam em múltiplas implementações de Smalltalk que dependem da serialização de objetos não podem compartilhar dados entre essas diferentes implementações. Esses aplicativos incluem o banco de dados de objetos MinneStore e alguns pacotes RPC. Uma solução para esse problema é o SIXX, que é um pacote para vários Smalltalks que usa um formato baseado em XML para serialização.

Rápido

A biblioteca padrão Swift fornece dois protocolos, Encodable e Decodable (compostos juntos como Codable), que permitem que instâncias de tipos conformes sejam serializado ou desserializado de JSON, listas de propriedades ou outros formatos. Implementações padrão desses protocolos podem ser geradas pelo compilador para tipos cujas propriedades armazenadas também são Decodable ou Encodable.

Windows PowerShell

O Windows PowerShell implementa a serialização por meio do cmdlet integrado Export-CliXML. Export-CliXML serializa objetos.NET e armazena o XML resultante em um arquivo. Para reconstituir os objetos, use o cmdlet Import-CliXML, que gera um objeto desserializado a partir do XML no arquivo exportado. Objetos desserializados, geralmente conhecidos como "bolsas de propriedades" não são objetos vivos; são instantâneos que possuem propriedades, mas nenhum método. Estruturas de dados bidimensionais também podem ser (des)serializadas em formato CSV usando os cmdlets integrados Import-CSV e Export-CSV.