Formats L6 - Présentation

Formats L6 — Couche Présentation

Couche OSI : L6 — Présentation

La couche Présentation traduit les données entre le format réseau et le format compréhensible par l’application. En pratique, elle est souvent fusionnée avec L7. Elle regroupe l’encodage des caractères, la sérialisation des données et la compression.

---

JSON — JavaScript Object Notation

Format de sérialisation texte, lisible par l’humain, basé sur des paires clé/valeur. Standard de facto pour les APIs REST.

{
  "utilisateur": {
    "id": 42,
    "nom": "Alice",
    "roles": ["admin", "developer"],
    "actif": true,
    "score": 98.5,
    "adresse": null
  }
}

Type JSON	Exemple
Chaîne	"Alice"
Nombre	42, 98.5
Booléen	true, false
Null	null
Tableau	["a", "b", "c"]
Objet	{"clé": "valeur"}

Avantages : lisible, simple, supporté partout
Inconvénients : verbeux (répétition des clés), pas de types stricts, pas de schéma natif
Usage : APIs REST, configuration, stockage (MongoDB, Elasticsearch)

---

XML — eXtensible Markup Language

Format de sérialisation texte basé sur des balises imbriquées. Plus verbeux que JSON, mais plus expressif (attributs, namespaces, schémas).

<?xml version="1.0" encoding="UTF-8"?>
<utilisateurs>
  <utilisateur id="42">
    <nom>Alice</nom>
    <roles>
      <role>admin</role>
      <role>developer</role>
    </roles>
    <actif>true</actif>
  </utilisateur>
</utilisateurs>

Avantages : schéma strict (XSD), namespaces, transformation (XSLT), mature
Inconvénients : très verbeux, plus difficile à lire
Usage : SOAP, configuration Java/Maven/Spring, fichiers Office (docx = zip de XML), SVG

---

Protobuf — Protocol Buffers (Google)

Format de sérialisation binaire, compressé, typé, avec schéma obligatoire (.proto). Utilisé par gRPC.

// Définition du schéma (.proto)
syntax = "proto3";
 
message Utilisateur {
  int32 id = 1;
  string nom = 2;
  repeated string roles = 3;
  bool actif = 4;
}

JSON équivalent  : {"id":42,"nom":"Alice","roles":["admin"],"actif":true}  → ~60 octets
Protobuf         : [données binaires]                                      → ~15 octets

Avantages : 3-10x plus compact que JSON, sérialisation/désérialisation rapide, schéma strict
Inconvénients : non lisible par l’humain, nécessite le schéma .proto
Usage : gRPC, communication inter-services haute performance, Kubernetes interne

---

UTF-8 — Unicode Transformation Format 8 bits

Encodage de caractères universel, capable de représenter tous les caractères Unicode (140 000+) en utilisant 1 à 4 octets par caractère.

Caractère  Unicode  UTF-8 (hex)
'A'        U+0041   41           → 1 octet (ASCII compatible)
'é'        U+00E9   C3 A9        → 2 octets
'€'        U+20AC   E2 82 AC     → 3 octets
'😀'       U+1F600  F0 9F 98 80  → 4 octets

Encodage	Plage	Taille	Usage
ASCII	128 caractères (anglais)	1 octet fixe	Legacy, anglais seulement
Latin-1 (ISO-8859-1)	256 caractères (Europe occidentale)	1 octet fixe	Anciens systèmes
UTF-8	1 114 112 caractères (tous)	1-4 octets variable	Standard moderne
UTF-16	Tous	2-4 octets	Windows interne, Java
UTF-32	Tous	4 octets fixe	Rare (mémoire)

UTF-8 est rétrocompatible avec ASCII : les 128 premiers caractères ASCII ont le même encodage. C’est pourquoi il a dominé.

# Vérifier l'encodage d'un fichier
file -i mon-fichier.txt
# → mon-fichier.txt: text/plain; charset=utf-8
 
# Convertir Latin-1 vers UTF-8
iconv -f ISO-8859-1 -t UTF-8 ancien.txt > nouveau.txt

---

JPEG / PNG / WebP — Formats d’images

Formats de compression d’images transmis dans les réponses HTTP.

Format	Compression	Transparence	Usage
JPEG	Avec perte (lossy)	Non	Photos, images complexes
PNG	Sans perte (lossless)	Oui (alpha)	Logos, captures d’écran, illustrations
WebP	Les deux modes	Oui	Web moderne (30% plus léger que JPEG)
AVIF	Sans perte	Oui	Très récent, excellent ratio
SVG	Vectoriel (XML)	Oui	Icônes, logos scalables
GIF	Sans perte, 256 couleurs	Partielle	Animations (obsolète pour les photos)

---

Compression — gzip / brotli

La couche Présentation peut compresser les données avant envoi :

Réponse HTTP non compressée : 150 Ko (HTML)
Réponse gzip               : 35 Ko  (-77%)
Réponse brotli             : 28 Ko  (-81%)

Client → Serveur : Accept-Encoding: gzip, br
Serveur → Client : Content-Encoding: br
                   [données compressées en brotli]
Client décompresse → affiche le HTML

Algorithme	Ratio	Vitesse	Usage
gzip	Bon	Rapide	Standard HTTP, universellement supporté
brotli	Meilleur (+20%)	Légèrement plus lent	HTTP/2, navigateurs modernes
zstd	Excellent	Très rapide	Kafka, Kubernetes, base de données

---

En relation avec

• Protocoles OSI - Index — tous les protocoles par couche
• Couches OSI — L6 Présentation dans le modèle OSI
• Requêtes HTTP et HTTPS — JSON et XML sont transportés dans HTTP
• RPC — gRPC utilise Protobuf comme format de sérialisation
• TLS et SSL — TLS opère aussi en L6