Penúltima parada del recorregut OSI: la capa 6 o capa de presentació. Les capes 1 a 5 han aconseguit que les dades arribin senceres, en ordre, al procés correcte i dins d'un diàleg viu — però ningú no ha preguntat encara una cosa essencial: què signifiquen aquests bytes? Un mateix doll de bytes pot ser text en una codificació o una altra, un JSON, una imatge, dades comprimides o un galimaties xifrat. La capa de presentació és la que OSI dedica a la representació de les dades: garantir que el que un extrem emet és exactament el que l'altre entén, encara que els seus sistemes siguin diferents per dins. Com la capa de sessió, avui no existeix com a peça separada — viu dins de les aplicacions i les seves llibreries —, però els seus problemes són dels més freqüents que veuràs: la enya convertida en ñ en un fitxer, una API que no entén el format rebut, un certificat que no valida. Tots són, conceptualment, incidències de capa 6.

1. La funció de la capa de presentació dins del model
2. Codificació de caràcters: d'ASCII a UTF-8 (i els accents trencats)
3. Formats i serialització: JSON i XML
4. Compressió
5. Xifratge: TLS vist des d'OSI
6. Per què la capa 6 viu dins de les aplicacions

El problema de fons és que els dos extrems d'una comunicació poden representar internament les dades de maneres diferents: sistemes operatius diferents, llenguatges de programació diferents, convencions diferents per al text, els números o les dates. Si cadascun enviés les seves dades "tal com les té a la memòria", l'altre llegiria brossa.

La solució que formalitza OSI: acordar una representació comuna per al trànsit. L'emissor tradueix del seu format intern al comú; el receptor, del comú al seu. Aquesta doble traducció és l'essència de la capa 6:

• Què rep de dalt (capa 7): dades amb significat per a l'aplicació (text, estructures, imatges).
• Quin servei ofereix: una representació de trànsit entenedora per a tots dos extrems — cosa que implica tres famílies de serveis: traducció de formats (codificacions, serialització), compressió i xifratge.
• Què fa servir de baix (capa 5): el diàleg establert pel qual flueixen els bytes ja representats.
• La seva PDU: dades.

Una analogia: dues empreses, una espanyola i una japonesa, negocien un contracte. Cadascuna pensa i arxiva en el seu idioma (format intern), però el contracte es redacta en anglès (representació comuna de trànsit), potser s'envia en un sobre lacrat (xifratge) i en versió resumida per al burofax (compressió). Els traductors de totes dues parts són la capa de presentació.

L'exemple més antic i encara el més freqüent de problema de representació és el text. Al fons de la xarxa només viatgen números (bytes), així que cal un acord sobre quin número representa cada caràcter:

• ASCII (anys 60): 128 caràcters — l'alfabet anglès sense accents, dígits i símbols bàsics. La A és el 65, la a el 97. Suficient per a l'anglès; inútil per a "informàtica" o "Bilbao añade".
• Dècades de pedaços regionals: taules de 256 caràcters on els codis 128-255 significaven coses diferents segons el país (l'europea occidental "latin-1"/Windows-1252 incloïa els nostres accents i la ñ). Dos sistemes amb taula diferent = text corrupte.
• UTF-8 (l'estàndard actual): una codificació del catàleg universal Unicode, capaç de representar qualsevol caràcter de qualsevol idioma. La seva genialitat: els primers 128 caràcters coincideixen amb ASCII byte a byte (compatibilitat total cap enrere), i els altres fan servir 2, 3 o 4 bytes. Avui és la codificació de facto de la web i de gairebé tot.

Símptoma: en Jon exporta des d'una aplicació antiga de Bilbao un fitxer anomenat clientes.csv i el deixa al servidor de fitxers. La Marta l'obre a València i veu això:

Diagnòstic de capa 6: el fitxer va arribar perfecte — ni un bit alterat; capes 1-5 impecables (la còpia per la xarxa i el servidor de fitxers no en tenen cap culpa). El problema és d'interpretació: la ñ de "Begoña" es va guardar en UTF-8, que la representa amb dos bytes (0xC3 0xB1). El programa de la Marta va assumir que el fitxer era en la taula antiga d'un byte per caràcter, i va interpretar cada byte per separat: 0xC3 és Ã i 0xB1 és ± en aquella taula. Resultat: cada lletra accentuada es converteix en dos caràcters estranys. (El fenomen invers també existeix: un fitxer guardat en la taula antiga i llegit com a UTF-8 mostra � o dona errors.)

La signatura de l'error: un caràcter amb accent/ñ → dos símbols rars que comencen per Ã delata gairebé sempre "UTF-8 llegit com a latin-1". Solució: no cal "reparar la xarxa" ni el fitxer — cal obrir-lo indicant la codificació correcta (els editors i fulls de càlcul permeten triar-la en importar), i de cara al futur, acordar UTF-8 a tots dos extrems: exportar en UTF-8 des de l'aplicació de Bilbao. És la solució de capa 6 canònica: acordar la representació comuna.

Un graó per sobre dels caràcters hi ha l'estructura. Les aplicacions manegen dades organitzades (un client amb nom, ciutat i telèfon; una llista de comandes), però per la xarxa només viatgen seqüències de bytes. Serialitzar és convertir una estructura en memòria en una seqüència de bytes transmissible; deserialitzar, reconstruir l'estructura a l'altre extrem. És traducció de representació pura: capa 6 de llibre.

Els dos formats de text més comuns que veuràs:

A Meridiano conviuen tots dos: la intranet moderna exposa les seves dades en JSON (quan el navegador de la Marta demana la llista de projectes, rep JSON i el converteix en la taula que ella veu), mentre que l'intercanvi de facturació amb un client gran fa servir XML perquè així ho exigeix el sistema veterà del client. I fixa't que tots dos són text, així que la capa anterior segueix aplicant: un JSON amb "Begoña" també necessita la seva codificació acordada (per convenció, JSON és UTF-8 — una decisió de capa 6 presa per l'estàndard per eliminar l'ambigüitat).

Existeixen també formats de serialització binaris (més compactes i ràpids, no llegibles a simple vista), habituals entre serveis interns d'alt rendiment; en tens prou de saber que existeixen i que responen al mateix problema.

Tercer servei: representar el mateix amb menys bytes. La compressió explota les redundàncies de les dades (text repetitiu, patrons) per reduir-ne la mida abans de transmetre, i desfer-se a la destinació. Dos matisos de professional:

• Sense pèrdua vs amb pèrdua: la compressió sense pèrdua (la d'un fitxer comprimit, o la que apliquen els servidors web a l'HTML) restaura l'original exacte. La compressió amb pèrdua (JPEG, l'àudio/vídeo de la videotrucada) sacrifica detall imperceptible a canvi de reduccions enormes — per això una videotrucada cap per la VPN de Meridiano.
• Comprimir el que ja està comprimit no serveix (i fins i tot pot engreixar el resultat): les dades comprimides ja no tenen redundància per explotar. Per això la còpia nocturna de Meridiano no hi guanya res recomprimint les fotos JPEG de l'arxiu comercial.

Exemple quotidià invisible: quan el navegador de la Marta demana la intranet, anuncia quines compressions entén, i el servidor respon amb l'HTML comprimit; el navegador el descomprimeix sense que ningú no ho noti. Emissor i receptor negocien la representació — un altre cop el patró central de la capa 6.

El quart servei és el que avui té més pes: el xifratge, transformar les dades perquè només el destinatari legítim les pugui interpretar. Vist des d'OSI, xifrar és també un canvi de representació: les mateixes dades, en una forma il·legible per a tercers — la més radical de les traduccions de la capa 6.

Ja coneixes TLS de 02-05 com "la S d'HTTPS", i a la lliçó anterior en vas veure la faceta de sessió. Completem ara la seva fitxa OSI, perquè TLS és l'exemple perfecte de per què les capes 5-7 es fonen a la pràctica — un sol protocol que presta serveis de dues capes:

I a sobre seu viatja HTTP, que és capa 7. Quan la Marta obre https://intranet.grupomeridiano.example, la "pila" real del seu navegador és HTTP sobre TLS sobre TCP: tres peces de programari cobrint les capes 7-6-5-4 sense respectar les fronteres teòriques. El model OSI no descriu com està construït TLS; descriu quines funcions compleix — i això basta per raonar: si el problema és "certificat no vàlid", és la faceta d'establiment/identitat (5-6); si és "les dades arriben però corruptes després de desxifrar", és representació (6); si és "error 500", és l'aplicació (7). Les dades, això sí, es xifren abans de baixar a la capa 4: els routers, la VPN i qualsevol tafaner de la xarxa veuen només bytes opacs — la representació xifrada creua intacta les capes inferiors.

Com amb la sessió, la pregunta final: per què no hi ha "un servei de presentació" del sistema operatiu? La resposta és la mateixa història amb un altre protagonista: cada aplicació necessita representacions diferents, i va resultar més pràctic resoldre-ho amb llibreries que cada programa incorpora, que amb una capa universal:

• El text el resolen les llibreries de codificació de cada llenguatge (totes saben llegir i escriure UTF-8).
• La serialització, les llibreries de JSON/XML de cada entorn.
• La compressió, llibreries estàndard que navegadors i servidors integren.
• El xifratge, llibreries TLS que fan servir navegadors, servidors i gairebé tot el que parla per xarxa.

Per a un desenvolupador —potser el teu cas— això té una lectura molt directa: quan tries la codificació d'un fitxer, defineixes el JSON d'una API o configures TLS, estàs treballant a la capa 6, encara que cap manual del teu framework no l'anomeni així. I per al diagnòstic, la conseqüència ja coneguda: els problemes de presentació (accents trencats, "format inesperat", fallades de certificat) passen amb la xarxa perfecta — cap eina de capes 1-4 no els veurà, perquè els bytes arriben impecables; el que està trencat és l'acord sobre el seu significat.

• Culpar la xarxa (o el fitxer) dels accents trencats. Si apareix ñ on hi anava una ñ, els bytes van arribar perfectes: és un desacord de codificació entre qui va escriure i qui llegeix. S'arregla triant la codificació correcta en obrir, i es preveu estandarditzant UTF-8.
• Creure que UTF-8 fa servir sempre un byte per caràcter. Els caràcters ASCII sí; accents i ñ fan servir dos bytes. La meitat dels errors de codificació neixen de codi que assumeix "1 caràcter = 1 byte".
• Pensar que el xifratge és "cosa de la capa de xarxa" perquè protegeix la comunicació. Conceptualment és un servei de representació (capa 6): transforma les dades als extrems; les capes 1-4 transporten bytes opacs sense saber que van xifrats. (La VPN de Meridiano xifra a nivell de paquet, més avall — mecanisme diferent per a un objectiu diferent; el TLS de la intranet és el de capa 6.)
• Intentar encaixar TLS en una sola capa OSI. No hi encaixa, i no passa res: presta serveis de sessió (5) i de presentació (6) sobre transport (4). El model serveix per anomenar les seves funcions, no per classificar el protocol sencer.
• Consell: estandarditza UTF-8 en tot el que toquis (fitxers, bases de dades, exportacions) i declara sempre la codificació explícitament on el format ho permeti. El 90% dels problemes de text desapareixen amb aquesta única política.
• Consell: davant de dades "que arriben malament", pregunta primer: arriben malament els bytes (capes 1-4: estrany, i ho delatarien les retransmissions) o arriba malament la seva interpretació (capa 6: codificació, format, desxifratge)? La resposta gairebé sempre és la segona.

Exercici 1. Classifica cada element en el seu servei de capa 6 (codificació de caràcters, serialització, compressió, xifratge) — o indica que no és capa 6: (a) la intranet retorna la llista de projectes en JSON; (b) el servidor envia l'HTML comprimit al navegador de l'Ana; (c) el cadenat d'HTTPS a la intranet; (d) el fitxer d'en Jon que la Marta veu amb ñ; (e) el TTL que decrementen els routers de la VPN.

Exercici 2. La Marta obre clientes.csv i veu Begoña en comptes de Begoña. (a) Explica què va passar a nivell de bytes (el fitxer és en UTF-8 i el seu programa el llegeix com a taula antiga d'un byte). (b) Per què pots afirmar que la xarxa i el servidor de fitxers no en tenen cap culpa? (c) Indica la solució immediata i la preventiva.

Exercici 3. La intranet de Meridiano exposa dades en JSON a una petita aplicació d'escriptori que fa servir l'equip d'administració. Després d'una actualització del servidor, l'aplicació falla amb "format de resposta no vàlid", encara que el navegador mostra la intranet perfectament i el ping, el DNS i el certificat estan impecables. (a) A quina capa conceptual situes el problema i què descartes amb les dades donades? (b) Proposa dues causes plausibles coherents amb "el navegador funciona però l'aplicació no".

Solució 1. (a) Serialització (estructura → text JSON). (b) Compressió (mateixa informació, menys bytes, negociada entre navegador i servidor). (c) Xifratge (TLS en la seva faceta de capa 6; l'establiment/identitat té a més faceta de capa 5). (d) Codificació de caràcters (desacord UTF-8 vs taula antiga). (e) No és capa 6: el TTL és capa 3 (xarxa).

Solució 2. (a) La ñ es va escriure en UTF-8 com a dos bytes (0xC3 0xB1). El programa de la Marta, assumint un byte per caràcter, va traduir cada byte per separat amb la taula antiga: 0xC3→Ã, 0xB1→±, i va mostrar ñ. Cada caràcter no ASCII del fitxer pateix la mateixa duplicació. (b) Perquè els bytes rebuts són idèntics als enviats — si la xarxa hagués corromput dades, la capa 2 hauria descartat les trames (FCS) i TCP hauria retransmès; a més l'error és sistemàtic (tots els accents, sempre igual), cosa que delata interpretació, no corrupció aleatòria. (c) Immediata: reobrir/importar el fitxer indicant UTF-8. Preventiva: acordar UTF-8 a tots dos extrems — que l'aplicació de Bilbao exporti en UTF-8 (o que es declari la codificació en el procés d'intercanvi).

Solució 3. (a) Capa 6 (representació/serialització): les capes 1-4 queden descartades pel ping i pel fet que hi ha resposta; el DNS i el certificat descarten la resolució i l'establiment segur; i que el navegador funcioni indica que el servei (capa 7) respon. El que falla és l'acord de format entre el servidor actualitzat i l'aplicació d'escriptori. (b) Causes plausibles: l'actualització va canviar l'estructura del JSON (camps reanomenats, moguts o eliminats) i l'aplicació deserialitza contra l'esquema antic — el navegador no ho pateix perquè la web es va actualitzar alhora; o el servidor va canviar algun aspecte de la representació que el navegador tolera i l'aplicació no (p. ex., ara respon comprimit per defecte, o va canviar la codificació/declaració del contingut, i l'aplicació no ho negocia ni ho maneja). En tots dos casos, la solució és al programari i al seu contracte de dades, no a la xarxa.

La capa de presentació és la guardiana del significat: on les capes 1-5 garanteixen que els bytes arribin, la 6 garanteix que s'interpretin igual a tots dos extrems. Els seus quatre serveis t'acompanyaran cada dia: codificació de caràcters (ASCII → UTF-8, amb la signatura inconfusible del ñ quan l'acord es trenca), serialització (JSON i XML com a representacions comunes d'estructures), compressió (el mateix en menys bytes, negociat i amb l'advertència del que ja està comprimit) i xifratge (TLS com a canvi radical de representació, a cavall entre les capes 5 i 6). I la moralitat compartida amb la sessió: aquesta capa viu a les aplicacions i les seves llibreries, així que les seves avaries es presenten amb la xarxa en perfecte estat. Ja només queda un graó: el punt on la xarxa toca per fi els programes i les persones que els fan servir — què vol dir exactament que HTTP o DNS "siguin capa 7", i com es veu el model complet des de dalt. La capa d'aplicació tanca el recorregut a la propera lliçó.