Qu’est-ce qu’un encodage et à quoi ça sert

1. Notion d’encodage (encoding)

Commençons par la question principale : qu’est-ce qu’un encodage ?

Imaginez que vous arrivez à une conférence internationale. Chacun parle sa langue, mais tout le monde veut se comprendre. Il faut un interprète qui sait que le mot "hello" en anglais correspond à "hello" en russe et à "hola" en espagnol. Dans le monde de l’informatique, l’encodage joue ce rôle d’interprète.

Un encodage est une façon de représenter les caractères sous forme d’octets

Un ordinateur est simple : il ne comprend que des zéros et des uns, c’est‑à‑dire des bits et des octets. Mais les humains veulent voir des lettres, des chiffres, des emoji et même — oh, horreur ! — des idéogrammes chinois. Pour que l’ordinateur puisse « écrire » un caractère, il faut convenir à quel ensemble d’octets correspond chaque caractère.

Un encodage (encoding) est un ensemble de règles qui transforment des caractères (lettres, chiffres, signes de ponctuation, emoji, etc.) en octets pour le stockage et la transmission, et inversement : des octets en caractères pour l’affichage.

Exemple : la lettre 'A' (cyrillique) dans différents encodages

• En encodage UTF-8, la lettre 'A' (cyrillique) est encodée sur deux octets : 0xD0 0x90.
• En encodage Windows-1251, la même lettre — un seul octet : 0xC0.
• Quant à la lettre latine 'A', dans presque tous les encodages populaires, c’est 0x41.

Si vous lisez un fichier avec un mauvais encodage, les caractères se transforment en « charabia » (signes incompréhensibles ou points d’interrogation).

2. Pourquoi les encodages sont nécessaires

Pourquoi ne pas simplement stocker les lettres telles quelles ?

Parce qu’un ordinateur ne comprend que des nombres (des zéros et des uns). Le nombre associé à chaque lettre — c’est précisément le rôle de l’encodage.

Exemple : « Hello » sur le disque

Quand vous écrivez dans un fichier le mot "Hello", pour l’ordinateur il ne s’agit que d’une séquence d’octets. La manière d’interpréter ces octets dépend de l’encodage.

• Si le fichier est enregistré en UTF-8, chaque lettre cyrillique du mot occupe deux octets.
• Si c’est en Windows-1251, chaque lettre occupe un octet, mais avec d’autres valeurs d’octet.

Où les encodages sont-ils nécessaires ?

• Lors de l’écriture de texte dans un fichier : pour que les octets puissent ensuite être lus correctement.
• Lors de la lecture de texte depuis un fichier : pour transformer les octets en lettres.
• Lors de l’envoi de texte sur le réseau (par exemple, HTTP, e‑mail).
• Lors du travail avec des bases de données : là aussi, il faut savoir dans quel encodage le texte est stocké.

Si vous ne précisez pas l’encodage…

C’est comme ouvrir un texte dans une langue inconnue et essayer de le lire. Vos chances augmentent si vous savez de quelle langue il s’agit. Sinon — au mieux, vous ne comprendrez rien, au pire — vous obtiendrez de l’abracadabra.

3. Problèmes sans encodage correct

Caractères illisibles et perte de données

La plainte la plus fréquente des débutants (et pas seulement) : « Pourquoi au lieu de "Hello" je vois "Привет" ou même uniquement des points d’interrogation ? »

Cela arrive quand un fichier a été écrit avec un encodage et lu avec un autre. Par exemple, le fichier a été créé sur un ancien Windows en Windows-1251, et vous l’ouvrez sous Linux, où l’encodage par défaut est UTF-8. Ou l’inverse.

Exemple

• Fichier enregistré en Windows-1251 : la première lettre (cyrillique) du mot vaut 0xCF.
• Ouverture en UTF-8 : le programme attend que la cyrillique soit sur deux octets, mais reçoit un seul octet. Tout casse.

Perte de données

Si, à l’écriture, un caractère n’est pas pris en charge par l’encodage choisi (par exemple, vous essayez de sauvegarder un emoji en ASCII), il disparaîtra ou sera remplacé par un point d’interrogation. Tout ce qui « n’entre pas » dans l’encodage est perdu.

Problèmes lors de l’échange de fichiers

Des fichiers enregistrés dans un encodage peuvent s’afficher incorrectement sur d’autres machines si l’encodage par défaut y est différent. Cela arrive souvent lors d’échanges entre Windows et Linux, ou à l’ouverture de vieux fichiers.

4. Encodage en Java : représentation interne et externe

À l’intérieur de la JVM : toujours Unicode (UTF-16)

En Java, les chaînes (String) à l’intérieur du programme sont toujours stockées en Unicode (plus précisément, en UTF-16). Cela signifie que vous pouvez affecter à des variables des chaînes dans n’importe quelle langue du monde, et Java « digérera » le tout.

String hello = "Bonjour, monde ! 😀";

En mémoire JVM, ce texte est stocké comme un ensemble de nombres sur 16 bits (char), où chaque caractère a son code dans la table Unicode.

Fait intéressant
En Java, un char fait 16 bits (2 octets). Mais certains caractères (par exemple, des idéogrammes rares ou des emoji) nécessitent deux char : ce sont des « paires de substitution » (surrogate pairs).

En entrée/sortie : l’encodage compte !

Quand vous lisez ou écrivez des chaînes vers l’extérieur (fichiers, réseau), Java doit convertir la représentation interne (UTF-16) en séquence d’octets. C’est là qu’intervient l’encodage.

• Si vous n’avez pas précisé explicitement l’encodage, Java utilise celui du système par défaut (sur un Windows en russe, ce peut être Windows-1251, sous Linux — UTF-8).
• C’est risqué : sur un autre ordinateur, le résultat peut être différent.

Exemple : lecture et écriture d’un fichier sans indiquer l’encodage

// Mauvaise pratique ! Encodage non précisé.
FileReader reader = new FileReader("data.txt");
FileWriter writer = new FileWriter("data.txt");

Dans ce cas, Java utilise l’encodage du système. Si le fichier a été écrit sur un autre système — vous obtiendrez du charabia.

Bonne pratique : toujours préciser l’encodage

// Bien ! L'encodage est indiqué explicitement.
BufferedReader reader = new BufferedReader(
    new InputStreamReader(new FileInputStream("data.txt"), StandardCharsets.UTF_8));
BufferedWriter writer = new BufferedWriter(
    new OutputStreamWriter(new FileOutputStream("data.txt"), StandardCharsets.UTF_8));

5. Brève illustration : ce qui se passe lors de l’utilisation des encodages

Schéma : le chemin d’une chaîne du fichier au programme et retour

[Fichier sur le disque (octets, encodage X)]
        |
        V
[Java lit les octets et, avec l'encodage X, les transforme en String (UTF-16)]
        |
        V
[Vous travaillez avec la chaîne dans le programme]
        |
        V
[Java écrit la String en octets en utilisant l'encodage Y]
        |
        V
[Fichier sur le disque (octets, encodage Y)]

Si X et Y coïncident — tout va bien. S’ils diffèrent — des problèmes sont possibles.

6. Brève histoire des encodages (pour les curieux)

ASCII

ASCII est l’un des plus anciens encodages : un octet par caractère, uniquement l’alphabet anglais, les chiffres et les signes de base. Tous les autres alphabets — exclus.

Windows-1251, ISO-8859-1 et autres « anciens »

Ce sont des encodages monooctet pour différents jeux de lettres : cyrillique, latin, grec, etc. Chacun choisissait le sien, et la pagaille a commencé.

Unicode et la famille UTF

• Unicode — une table globale pour les caractères du monde entier.
• UTF-8, UTF-16, UTF-32 — différentes façons de représenter les caractères Unicode en octets.
• UTF-8 est devenu le standard pour le Web, les fichiers et l’échange inter‑systèmes.

7. Pratique : comment l’encodage influence le travail avec les fichiers

Regardons un petit exemple d’écriture et de lecture de chaînes avec des encodages différents.

Exemple : écriture et lecture dans des encodages différents

import java.io.*;
import java.nio.charset.Charset;
import java.nio.charset.StandardCharsets;

public class EncodingDemo {
    public static void main(String[] args) throws IOException {
        String text = "Bonjour, monde ! 😀";

        // Écrivons un fichier en UTF-8
        try (Writer writer = new OutputStreamWriter(
                new FileOutputStream("utf8.txt"), StandardCharsets.UTF_8)) {
            writer.write(text);
        }

        // Essayons maintenant de le lire avec un encodage incorrect
        try (Reader reader = new InputStreamReader(
                new FileInputStream("utf8.txt"), Charset.forName("Windows-1251"))) {
            int c;
            while ((c = reader.read()) != -1) {
                System.out.print((char) c);
            }
        }
        // À l'écran, ce sera du charabia !
    }
}

Conclusion : Si les encodages ne correspondent pas, le texte sera altéré.

8. Encodage et intégration avec d’autres systèmes

Dans les projets réels, les fichiers sont souvent échangés entre différents programmes, écrits dans des langages différents et fonctionnant sur des OS différents. Chacun peut attendre son propre encodage. Sans accord préalable — vous obtiendrez des « caractères illisibles » et des bogues difficiles à cerner. Cas typique : la base de données stocke le texte en UTF-8, mais le programme lit le fichier source comme Windows-1251 et charge dans la BD — les caractères seront déformés.

9. Erreurs typiques lors du travail avec les encodages

Erreur n° 1 : encodage non précisé lors de la lecture/écriture d’un fichier.
En conséquence, « ça marche sur ma machine », et chez un collègue — « caractères illisibles ».

Erreur n° 2 : utiliser des constructeurs obsolètes (FileReader, FileWriter).
Ils utilisent toujours l’encodage système — un piège pour les débutants.

Erreur n° 3 : encodage incorrect du fichier source.
Si un fichier a été écrit dans un encodage et lu dans un autre, une partie des caractères sera déformée ou remplacée par des points d’interrogation.

Erreur n° 4 : perte de caractères lors de conversions entre encodages.
Si l’encodage cible ne prend pas en charge tous les caractères (par exemple, ASCII au lieu de UTF-8), une partie du texte disparaîtra tout simplement.