Penúltima parada del recorrido OSI: la capa 6 o capa de presentación. Las capas 1 a 5 han conseguido que los datos lleguen enteros, en orden, al proceso correcto y dentro de un diálogo vivo — pero nadie ha preguntado todavía algo esencial: ¿qué significan esos bytes? Un mismo chorro de bytes puede ser texto en una codificación u otra, un JSON, una imagen, datos comprimidos o un galimatías cifrado. La capa de presentación es la que OSI dedica a la representación de los datos: garantizar que lo que un extremo emite es exactamente lo que el otro entiende, aunque sus sistemas sean distintos por dentro. Como la capa de sesión, hoy no existe como pieza separada — vive dentro de las aplicaciones y sus librerías —, pero sus problemas son de los más frecuentes que verás: la eñe convertida en ñ en un fichero, una API que no entiende el formato recibido, un certificado que no valida. Todos son, conceptualmente, incidencias de capa 6.

1. La función de la capa de presentación dentro del modelo
2. Codificación de caracteres: de ASCII a UTF-8 (y los acentos rotos)
3. Formatos y serialización: JSON y XML
4. Compresión
5. Cifrado: TLS visto desde OSI
6. Por qué la capa 6 vive dentro de las aplicaciones

El problema de fondo es que los dos extremos de una comunicación pueden representar internamente los datos de formas distintas: sistemas operativos diferentes, lenguajes de programación diferentes, convenciones diferentes para el texto, los números o las fechas. Si cada uno enviara sus datos "tal como los tiene en memoria", el otro leería basura.

La solución que formaliza OSI: acordar una representación común para el tránsito. El emisor traduce de su formato interno al común; el receptor, del común al suyo. Esa doble traducción es la esencia de la capa 6:

• Qué recibe de arriba (capa 7): datos con significado para la aplicación (texto, estructuras, imágenes).
• Qué servicio ofrece: una representación de tránsito entendible por ambos extremos — lo que implica tres familias de servicios: traducción de formatos (codificaciones, serialización), compresión y cifrado.
• Qué usa de abajo (capa 5): el diálogo establecido por el que fluyen los bytes ya representados.
• Su PDU: datos.

Una analogía: dos empresas, una española y una japonesa, negocian un contrato. Cada una piensa y archiva en su idioma (formato interno), pero el contrato se redacta en inglés (representación común de tránsito), quizá se envía en un sobre lacrado (cifrado) y en versión resumida para el burofax (compresión). Los traductores de ambas partes son la capa de presentación.

El ejemplo más antiguo y todavía el más frecuente de problema de representación es el texto. En el fondo de la red solo viajan números (bytes), así que hace falta un acuerdo sobre qué número representa cada carácter:

• ASCII (años 60): 128 caracteres — el alfabeto inglés sin acentos, dígitos y símbolos básicos. La A es el 65, la a el 97. Suficiente para inglés; inútil para "informática" o "Bilbao añade".
• Décadas de parches regionales: tablas de 256 caracteres donde los códigos 128-255 significaban cosas distintas según el país (la europea occidental "latin-1"/Windows-1252 incluía nuestras tildes y la ñ). Dos sistemas con tabla distinta = texto corrupto.
• UTF-8 (el estándar actual): una codificación del catálogo universal Unicode, capaz de representar cualquier carácter de cualquier idioma. Su genialidad: los primeros 128 caracteres coinciden con ASCII byte a byte (compatibilidad total hacia atrás), y los demás usan 2, 3 o 4 bytes. Hoy es la codificación de facto de la web y de casi todo.

Síntoma: Jon exporta desde una aplicación antigua de Bilbao un fichero llamado clientes.csv y lo deja en el servidor de ficheros. Marta lo abre en Valencia y ve esto:

Diagnóstico de capa 6: el fichero llegó perfecto — ni un bit alterado; capas 1-5 impecables (la copia por la red y el servidor de ficheros no tienen culpa alguna). El problema es de interpretación: la ñ de "Begoña" se guardó en UTF-8, que la representa con dos bytes (0xC3 0xB1). El programa de Marta asumió que el fichero estaba en la tabla antigua de un byte por carácter, e interpretó cada byte por separado: 0xC3 es Ã y 0xB1 es ± en esa tabla. Resultado: cada letra acentuada se convierte en dos caracteres extraños. (El fenómeno inverso también existe: un fichero guardado en la tabla antigua y leído como UTF-8 muestra � o da errores.)

La firma del error: un carácter con tilde/ñ → dos símbolos raros que empiezan por Ã delata casi siempre "UTF-8 leído como latin-1". Solución: no hay que "reparar la red" ni el fichero — hay que abrirlo indicando la codificación correcta (los editores y hojas de cálculo permiten elegirla al importar), y de cara al futuro, acordar UTF-8 en ambos extremos: exportar en UTF-8 desde la aplicación de Bilbao. Es la solución de capa 6 canónica: acordar la representación común.

Un peldaño por encima de los caracteres está la estructura. Las aplicaciones manejan datos organizados (un cliente con nombre, ciudad y teléfono; una lista de pedidos), pero por la red solo viajan secuencias de bytes. Serializar es convertir una estructura en memoria a una secuencia de bytes transmisible; deserializar, reconstruir la estructura en el otro extremo. Es traducción de representación pura: capa 6 de libro.

Los dos formatos de texto más comunes que verás:

En Meridiano conviven ambos: la intranet moderna expone sus datos en JSON (cuando el navegador de Marta pide la lista de proyectos, recibe JSON y lo convierte en la tabla que ella ve), mientras que el intercambio de facturación con un cliente grande usa XML porque así lo exige el sistema veterano del cliente. Y nótese que ambos son texto, así que la capa anterior sigue aplicando: un JSON con "Begoña" también necesita su codificación acordada (por convención, JSON es UTF-8 — una decisión de capa 6 tomada por el estándar para eliminar la ambigüedad).

Existen también formatos de serialización binarios (más compactos y rápidos, no legibles a simple vista), habituales entre servicios internos de alto rendimiento; te basta con saber que existen y que responden al mismo problema.

Tercer servicio: representar lo mismo con menos bytes. La compresión explota las redundancias de los datos (texto repetitivo, patrones) para reducir su tamaño antes de transmitir, y deshacerse en el destino. Dos matices de profesional:

• Sin pérdida vs con pérdida: la compresión sin pérdida (la de un fichero comprimido, o la que aplican los servidores web al HTML) restaura el original exacto. La compresión con pérdida (JPEG, el audio/vídeo de la videollamada) sacrifica detalle imperceptible a cambio de reducciones enormes — por eso una videollamada cabe por la VPN de Meridiano.
• Comprimir lo ya comprimido no sirve (y puede hasta engordar el resultado): los datos comprimidos ya no tienen redundancia que explotar. Por eso la copia nocturna de Meridiano no gana nada recomprimiendo las fotos JPEG del archivo comercial.

Ejemplo cotidiano invisible: cuando el navegador de Marta pide la intranet, anuncia qué compresiones entiende, y el servidor responde con el HTML comprimido; el navegador lo descomprime sin que nadie lo note. Emisor y receptor negocian la representación — otra vez el patrón central de la capa 6.

El cuarto servicio es el que hoy tiene más peso: el cifrado, transformar los datos para que solo el destinatario legítimo pueda interpretarlos. Visto desde OSI, cifrar es también un cambio de representación: los mismos datos, en una forma ilegible para terceros — la más radical de las traducciones de la capa 6.

Ya conoces TLS de 02-05 como "la S de HTTPS", y en la lección anterior viste su faceta de sesión. Completemos ahora su ficha OSI, porque TLS es el ejemplo perfecto de por qué las capas 5-7 se funden en la práctica — un solo protocolo que presta servicios de dos capas:

Y encima de él viaja HTTP, que es capa 7. Cuando Marta abre https://intranet.grupomeridiano.example, la "pila" real de su navegador es HTTP sobre TLS sobre TCP: tres piezas de software cubriendo las capas 7-6-5-4 sin respetar las fronteras teóricas. El modelo OSI no describe cómo está construido TLS; describe qué funciones cumple — y eso basta para razonar: si el problema es "certificado no válido", es la faceta de establecimiento/identidad (5-6); si es "los datos llegan pero corruptos tras descifrar", es representación (6); si es "error 500", es la aplicación (7). Los datos, eso sí, se cifran antes de bajar a la capa 4: los routers, la VPN y cualquier fisgón de la red ven solo bytes opacos — la representación cifrada cruza intacta las capas inferiores.

Como con la sesión, la pregunta final: ¿por qué no hay "un servicio de presentación" del sistema operativo? La respuesta es la misma historia con otro protagonista: cada aplicación necesita representaciones distintas, y resultó más práctico resolverlo con librerías que cada programa incorpora, que con una capa universal:

• El texto lo resuelven las librerías de codificación de cada lenguaje (todas saben leer y escribir UTF-8).
• La serialización, las librerías de JSON/XML de cada entorno.
• La compresión, librerías estándar que navegadores y servidores integran.
• El cifrado, librerías TLS que usan navegadores, servidores y casi todo lo que habla por red.

Para un desarrollador —quizá tu caso— esto tiene una lectura muy directa: cuando eliges la codificación de un fichero, defines el JSON de una API o configuras TLS, estás trabajando en la capa 6, aunque ningún manual de tu framework la llame así. Y para el diagnóstico, la consecuencia ya conocida: los problemas de presentación (acentos rotos, "formato inesperado", fallos de certificado) ocurren con la red perfecta — ninguna herramienta de capas 1-4 los verá, porque los bytes llegan impecables; lo roto es el acuerdo sobre su significado.

• Culpar a la red (o al fichero) de los acentos rotos. Si aparece ñ donde iba una ñ, los bytes llegaron perfectos: es un desacuerdo de codificación entre quien escribió y quien lee. Se arregla eligiendo la codificación correcta al abrir, y se previene estandarizando UTF-8.
• Creer que UTF-8 usa siempre un byte por carácter. Los caracteres ASCII sí; tildes y ñ usan dos bytes. La mitad de los errores de codificación nacen de código que asume "1 carácter = 1 byte".
• Pensar que el cifrado es "cosa de la capa de red" porque protege la comunicación. Conceptualmente es un servicio de representación (capa 6): transforma los datos en los extremos; las capas 1-4 transportan bytes opacos sin saber que van cifrados. (La VPN de Meridiano cifra a nivel de paquete, más abajo — distinto mecanismo para distinto objetivo; el TLS de la intranet es el de capa 6.)
• Intentar encajar TLS en una sola capa OSI. No encaja, y no pasa nada: presta servicios de sesión (5) y de presentación (6) sobre transporte (4). El modelo sirve para nombrar sus funciones, no para clasificar el protocolo entero.
• Consejo: estandariza UTF-8 en todo lo que toques (ficheros, bases de datos, exportaciones) y declara siempre la codificación explícitamente donde el formato lo permita. El 90% de los problemas de texto desaparecen con esa única política.
• Consejo: ante datos "que llegan mal", pregunta primero: ¿llegan mal los bytes (capas 1-4: raro, y lo delatarían las retransmisiones) o llega mal su interpretación (capa 6: codificación, formato, descifrado)? La respuesta casi siempre es lo segundo.

Ejercicio 1. Clasifica cada elemento en su servicio de capa 6 (codificación de caracteres, serialización, compresión, cifrado) — o indica que no es capa 6: (a) la intranet devuelve la lista de proyectos en JSON; (b) el servidor envía el HTML comprimido al navegador de Ana; (c) el candado de HTTPS en la intranet; (d) el fichero de Jon que Marta ve con ñ; (e) el TTL que decrementan los routers de la VPN.

Ejercicio 2. Marta abre clientes.csv y ve Begoña en vez de Begoña. (a) Explica qué pasó a nivel de bytes (el fichero está en UTF-8 y su programa lo lee como tabla antigua de un byte). (b) ¿Por qué puedes afirmar que la red y el servidor de ficheros no tienen culpa? (c) Indica la solución inmediata y la preventiva.

Ejercicio 3. La intranet de Meridiano expone datos en JSON a una pequeña aplicación de escritorio que usa el equipo de administración. Tras una actualización del servidor, la aplicación falla con "formato de respuesta no válido", aunque el navegador muestra la intranet perfectamente y el ping, el DNS y el certificado están impecables. (a) ¿En qué capa conceptual sitúas el problema y qué descartas con los datos dados? (b) Propón dos causas plausibles coherentes con "el navegador funciona pero la aplicación no".

Solución 1. (a) Serialización (estructura → texto JSON). (b) Compresión (misma información, menos bytes, negociada entre navegador y servidor). (c) Cifrado (TLS en su faceta de capa 6; el establecimiento/identidad tiene además faceta de capa 5). (d) Codificación de caracteres (desacuerdo UTF-8 vs tabla antigua). (e) No es capa 6: el TTL es capa 3 (red).

Solución 2. (a) La ñ se escribió en UTF-8 como dos bytes (0xC3 0xB1). El programa de Marta, asumiendo un byte por carácter, tradujo cada byte por separado con la tabla antigua: 0xC3→Ã, 0xB1→±, y mostró ñ. Cada carácter no ASCII del fichero sufre la misma duplicación. (b) Porque los bytes recibidos son idénticos a los enviados — si la red hubiera corrompido datos, la capa 2 habría descartado las tramas (FCS) y TCP habría retransmitido; además el error es sistemático (todas las tildes, siempre igual), lo que delata interpretación, no corrupción aleatoria. (c) Inmediata: reabrir/importar el fichero indicando UTF-8. Preventiva: acordar UTF-8 en ambos extremos — que la aplicación de Bilbao exporte en UTF-8 (o que se declare la codificación en el proceso de intercambio).

Solución 3. (a) Capa 6 (representación/serialización): las capas 1-4 quedan descartadas por ping y por el hecho de que hay respuesta; el DNS y el certificado descartan la resolución y el establecimiento seguro; y que el navegador funcione indica que el servicio (capa 7) responde. Lo que falla es el acuerdo de formato entre el servidor actualizado y la aplicación de escritorio. (b) Causas plausibles: la actualización cambió la estructura del JSON (campos renombrados, movidos o eliminados) y la aplicación deserializa contra el esquema antiguo — el navegador no lo sufre porque la web se actualizó a la vez; o el servidor cambió algún aspecto de la representación que el navegador tolera y la aplicación no (p. ej., ahora responde comprimido por defecto, o cambió la codificación/declaración del contenido, y la aplicación no lo negocia ni lo maneja). En ambos casos, la solución está en el software y su contrato de datos, no en la red.

La capa de presentación es la guardiana del significado: donde las capas 1-5 garantizan que los bytes lleguen, la 6 garantiza que se interpreten igual en ambos extremos. Sus cuatro servicios te acompañarán a diario: codificación de caracteres (ASCII → UTF-8, con la firma inconfundible del ñ cuando el acuerdo se rompe), serialización (JSON y XML como representaciones comunes de estructuras), compresión (lo mismo en menos bytes, negociado y con la advertencia de lo ya comprimido) y cifrado (TLS como cambio radical de representación, a caballo entre las capas 5 y 6). Y la moraleja compartida con la sesión: esta capa vive en las aplicaciones y sus librerías, así que sus averías se presentan con la red en perfecto estado. Ya solo queda un peldaño: el punto donde la red toca por fin a los programas y a las personas que los usan — qué significa exactamente que HTTP o DNS "sean capa 7", y cómo se ve el modelo completo desde arriba. La capa de aplicación cierra el recorrido en la próxima lección.