1. ¿Por qué elegir un formato? Recordatorio breve
Cualquier objeto .NET en memoria es un conjunto de direcciones, referencias, campos, estructuras internas y otra "cocina interna". Pero no puedes guardarlo en un archivo así tal cual: los archivos deben estar estructurados en un formato que puedan leer (y preferiblemente escribir) no solo nosotros, sino otros programas. Ahí es donde entra la elección del formato de serialización.
Tareas principales del formato de serialización:
- Compacidad: espacio en disco o velocidad de transmisión por la red.
- Legibilidad (¡para humanos!): ¿se puede abrir el archivo en un editor de texto y entender qué pasa?
- Universalidad: ¿sirve para integrarse con otros sistemas y lenguajes?
- Soporte de estructuras complejas: anidamientos, colecciones, referencias, tipos.
- Seguridad y compatibilidad.
2. Serialización binaria (Binary Serialization)
Serialización binaria representa los datos como un flujo "crudo" de bytes. Imagina que no solo metes las cosas en una caja, sino que las encierras en cemento: rápido, compacto, pero luego no encontrarás tus calcetines sin un martillo demoledor.
// Ejemplo solo a modo histórico:
using System.Runtime.Serialization.Formatters.Binary;
// ... creación del objeto
var user = new User { Name = "Ivan", Age = 42 };
// Serialización
using var fs = new FileStream("user.bin", FileMode.Create);
var formatter = new BinaryFormatter();
formatter.Serialize(fs, user);
Ventajas:
- Compacidad: ocupa muy poco espacio en disco, alta velocidad.
- Soporte incorporado para tipos "nativos" de .NET.
Desventajas:
- El formato es totalmente ilegible — intenta abrir el archivo en el Bloc de notas y entrarás en la Matrix (es decir, obtendrás un conjunto de símbolos ininteligible).
- Absolutamente no universal: solo para .NET (y aun así para la misma versión).
- Vulnerable a problemas de compatibilidad entre versiones.
¿Dónde se usaba?
Dentro de .NET, cuando hacía falta "volcar" objetos rápidamente entre procesos en la misma máquina. Hoy en día se DESaconseja mucho su uso, especialmente si te importa la seguridad y el mantenimiento a largo plazo. Usar BinaryFormatter en proyectos modernos es mala práctica.
3. Formato XML (Extensible Markup Language)
XML — formato legible por humanos y máquinas, basado en etiquetas, como HTML, pero sin las bromas sobre <body>.
<User>
<Name>Ivan</Name>
<Age>42</Age>
</User>
Ejemplo de serialización:
using System.Xml.Serialization;
var user = new User { Name = "Ivan", Age = 42 };
var serializer = new XmlSerializer(typeof(User));
using var fs = new FileStream("user.xml", FileMode.Create);
serializer.Serialize(fs, user);
Ventajas:
- Legibilidad: puedes abrirlo y ver la estructura con los ojos.
- Universalidad: XML lo saben leer muchos lenguajes y programas.
- Flexibilidad (soporte de esquemas, validación, espacios de nombres, etc.).
- Bien para estructuras complejas y objetos anidados.
Desventajas:
- "Ruidoso" y pesado: ocupa mucho espacio y tráfico.
- El parseo es más lento que en formatos binarios.
- Imprecisiones al serializar ciertos tipos (por ejemplo, fechas y horas).
- Requiere configuración extra para soportar algunas colecciones u objetos no estándar.
¿Dónde se aplica?
Intercambio de datos entre sistemas corporativos, configs, integración con sistemas donde se requiere una estructura estricta.
4. Formato JSON (JavaScript Object Notation)
JSON — formato compacto, ligero y fácil de leer, que viene del mundo de JavaScript y se hizo casi omnipresente en el intercambio de datos por su concisión y simplicidad.
{
"Name": "Ivan",
"Age": 42
}
Ejemplo de serialización:
using System.Text.Json;
var user = new User { Name = "Ivan", Age = 42 };
string json = JsonSerializer.Serialize(user);
File.WriteAllText("user.json", json);
Ventajas:
- Muy legible tanto para humanos como para máquinas.
- Se integra fácilmente con tecnologías web (APIs, JavaScript y más).
- Más compacto que XML.
- Serialización/deserialización rápida en librerías modernas (System.Text.Json, Newtonsoft.Json).
Desventajas:
- No soporta comentarios (tu JSON no podrá burlarse de sí mismo).
- Limitaciones estructurales: no sabe serializar, por ejemplo, referencias entre objetos o tipos complejos (por ejemplo, diccionarios con claves no string).
- Diferencias en el manejo de formatos de fecha/hora entre distintas implementaciones.
¿Dónde se aplica?
Prácticamente en todas partes donde hace falta intercambiar información entre plataformas distintas: servicios web, apps móviles, REST APIs, etc.
5. CSV (Comma-Separated Values)
CSV — formato de texto simple que representa datos en forma de tabla (filas y columnas), donde los campos están separados por comas u otro separador.
Name,Age
Ivan,42
Olga,27
Ejemplo de escritura CSV manual:
// Para simplificar, escribimos con un StreamWriter normal
var lines = new List<string>
{
"Name,Age",
"Ivan,42",
"Olga,27"
};
File.WriteAllLines("users.csv", lines);
Ventajas:
- Es soportado por muchísimos programas (Excel, Google Docs, DBs, etc.).
- Conciso y cómodo para datos tabulares.
Desventajas:
- No sirve para objetos anidados o complejos (solo estructuras "planas").
- No guarda información de tipos (todo son strings).
- Problemas de escape si los datos contienen comas, comillas o saltos de línea.
¿Dónde se aplica?
Exportación/importación entre bases de datos, intercambio de conjuntos simples de registros, dumps desde aplicaciones.
6. Protocolos y formatos de intercambio con tipado estricto
Protocol Buffers (protobuf) y MessagePack — formatos binarios de serialización con contratos (esquemas) que hacen la serialización aún más compacta y rápida. Requieren la descripción previa de la estructura de datos.
Ejemplo en protobuf (simplificado):
No forma parte del estándar .NET, necesitas el paquete Google.Protobuf.
message User {
string name = 1;
int32 age = 2;
}
Ventajas:
- Velocidad y compacidad máximas.
- Cross-platform (muchos lenguajes soportan protobuf).
Desventajas:
- Más complicado de aprender y configurar.
- Requiere generación de código a partir del esquema.
- No siempre es necesario si el proyecto no maneja millones de mensajes por segundo.
¿Dónde se aplica?
Sistemas de alta carga, intercambio de datos entre microservicios, juegos, IoT.
7. Matices útiles
Tabla-comparativa de formatos
| Formato | Legibilidad | Compacidad | Universalidad | Objetos complejos | Estándar en .NET 9 | Seguridad |
|---|---|---|---|---|---|---|
| Binary (.NET) | No | Sí | No | Sí | No | No |
| XML | Sí | No | Sí | Sí | Sí | Sí |
| JSON | Sí | Sí | Sí | Parcialmente | Sí | Sí |
| CSV | Sí | Sí | Sí | No | No | Sí |
| Protobuf | No | Mejor | Sí | Sí | No | Sí |
¿Cómo elegir el formato de serialización para tu aplicación?
Si guardas una estructura de datos compleja y te importa la legibilidad humana — usa XML o JSON.
Si necesitas transmitir rápidamente grandes volúmenes de datos entre servicios que controlas — considera protobuf o MessagePack.
Si exportas reportes para análisis en Excel o DBs — usa CSV.
Si escribes configuración para servicios o CI/CD — YAML te puede salvar la vida.
¿Compacidad, velocidad y soporte de referencias entre objetos son críticos? Entonces toca buscar formatos binarios, pero recuerda las desventajas en seguridad y compatibilidad.
8. Trucos y errores comunes
Si decides almacenar datos en binario por "secretismo", recuerda: un volcado binario no equivale a seguridad. Un atacante puede igualmente "desensamblar" ese flujo. Usa cifrado si es necesario.
Un problema común: olvidar la codificación al trabajar con formatos de texto (XML/JSON/CSV) — usa UTF-8. No todos los editores y sistemas llevan bien el BOM.
XML, aunque parezca "viejo", es bueno para protocolos contractuales donde importa una descripción de la estructura muy estricta (por ejemplo, esquemas XSD), y JSON es para intercambios rápidos y flexibles.
Al serializar colecciones de objetos complejos, no todos los formatos soportan correctamente estructuras anidadas o recursivas. JSON y XML se llevan bien con arrays y listas, CSV no.
GO TO FULL VERSION