1. Introduction
Imaginez que vous recevez d’un comptable un fichier de rapport enregistré en « Windows-1251 » (un ancien encodage pour le cyrillique). Votre application Java attend toutes les données d’entrée en « UTF-8 », sinon elle commence à « se plaindre » et affiche des hiéroglyphes à la place des lettres. Ou, par exemple, vous vous intégrez à un système qui n’accepte que « ISO-8859-1 ». Que faire ? Bien sûr, ré-encoder le fichier !
Ré-encodage — c’est le processus par lequel vous lisez du texte depuis un fichier avec un encodage et vous l’enregistrez avec un autre encodage. C’est comme réécrire une lettre d’une langue dans une autre pour que le destinataire comprenne parfaitement votre message.
Comment fonctionne le ré-encodage en Java : approche générale
En Java, les chaînes (String) dans le programme sont toujours stockées en Unicode (UTF‑16). Cela signifie qu’une fois le texte lu depuis le fichier, il est déjà « universel » et peut être écrit dans n’importe quel encodage pris en charge. Par conséquent, le ré-encodage est simple :
- Lire le fichier en tant que lignes en indiquant l’encodage source correct.
- Écrire ces lignes dans un nouveau fichier en spécifiant explicitement l’encodage cible souhaité.
Schéma :
[Fichier en encodage A] --(lecture avec Charset A)--> [String en mémoire] --(écriture avec Charset B)--> [Fichier en encodage B]
2. Algorithme pas à pas de ré-encodage
Étape 1. Déterminer l’encodage source et l’encodage cible
L’encodage source est celui dans lequel le fichier d’origine a été enregistré (par exemple, « Windows-1251 »). L’encodage cible est celui dans lequel vous voulez obtenir le résultat (par exemple, « UTF-8 »).
Étape 2. Ouvrir un flux de lecture avec l’encodage requis
Utilisez Files.newBufferedReader(Path, Charset) ou la classe classique InputStreamReader.
Étape 3. Ouvrir un flux d’écriture avec l’encodage requis
Utilisez Files.newBufferedWriter(Path, Charset) ou la classe classique OutputStreamWriter.
Étape 4. Lire les lignes et les écrire dans le nouveau fichier
Lisez ligne par ligne (ou en entier si le fichier est petit), en écrivant chaque ligne dans le nouveau fichier.
Étape 5. Fermer les flux (mieux vaut utiliser try-with-resources)
Ainsi, vous garantissez la libération correcte des ressources. Appliquez la construction try-with-resources.
3. Exemple de code : ré-encodage Windows-1251 → UTF-8
Implémentons un petit programme qui ré-encode un fichier de Windows‑1251 vers UTF‑8. Un tel exemple est fréquent en pratique, notamment si vous travaillez avec des données russophones.
import java.io.*;
import java.nio.charset.Charset;
import java.nio.charset.StandardCharsets;
import java.nio.file.*;
public class FileReencoder {
public static void main(String[] args) throws IOException {
// Chemins de fichiers
Path inputPath = Paths.get("input-1251.txt");
Path outputPath = Paths.get("output-utf8.txt");
// Ouvrons un reader avec l’encodage source Windows-1251
try (
BufferedReader reader = Files.newBufferedReader(inputPath, Charset.forName("Windows-1251"));
BufferedWriter writer = Files.newBufferedWriter(outputPath, StandardCharsets.UTF_8)
) {
String line;
while ((line = reader.readLine()) != null) {
writer.write(line);
writer.newLine(); // ne pas oublier le saut de ligne !
}
}
System.out.println("Fichier ré-encodé avec succès de Windows-1251 vers UTF-8 !");
}
}
Ici, nous indiquons explicitement l’encodage pour la lecture (Charset.forName(« Windows-1251 »)) et pour l’écriture (StandardCharsets.UTF_8). Ensuite, nous utilisons try-with-resources afin que les flux se ferment automatiquement même en cas d’erreurs. writer.newLine() — saut de ligne pour conserver la structure du fichier.
4. Points importants et astuces
Comment connaître l’encodage source du fichier ?
- Un fichier ne contient pas en soi une « étiquette » indiquant l’encodage (exception : BOM, mais il n’est pas toujours présent).
- Si vous avez créé le fichier, utilisez le même encodage que lors de l’écriture.
- Si le fichier vient d’ailleurs, essayez de l’ouvrir dans un éditeur qui affiche l’encodage (par exemple, Notepad++, Visual Studio Code).
- Sous Linux, vous pouvez utiliser la commande file -i nom_du_fichier, mais elle ne détermine pas toujours correctement l’encodage.
Que se passe-t-il si vous indiquez un mauvais encodage source ?
Vous obtiendrez du charabia illisible ou une perte de caractères. Par exemple, si vous lisez un fichier enregistré en Windows‑1251 comme s’il était en UTF‑8, le cyrillique se transformera en "Привет".
Gestion des exceptions
Lors de la manipulation de fichiers, des erreurs sont toujours possibles : fichier introuvable, droits insuffisants, encodage incorrect. Utilisez la gestion des exceptions (try-catch) ou propagez-les (throws) afin que l’application ne tombe pas en panne « sans explication ».
Traitement de gros fichiers
Si le fichier est énorme (gigaoctets !), utilisez la lecture et l’écriture ligne par ligne, comme dans les exemples. Ne lisez pas tout le fichier en mémoire — sinon vous obtiendrez OutOfMemoryError.
Ré-encodage « à la volée » (streaming)
Si le fichier est très volumineux, vous pouvez même ne pas créer de fichier intermédiaire et lire/écrire « à la volée » — par exemple, lors d’un traitement en flux de données provenant du réseau.
5. Erreurs typiques lors du ré-encodage de fichiers
Erreur n° 1 : Mauvais encodage source. Si vous vous trompez d’encodage source, le résultat sera catastrophique : « Bonjour » se transformera en "Привет". Déterminez toujours dans quel encodage le fichier a été créé.
Erreur n° 2 : Utilisation implicite de l’encodage système. Si vous n’indiquez pas l’encodage explicitement, Java utilise l’encodage système par défaut (System.getProperty("file.encoding")). Cela peut conduire à des résultats différents selon les machines (par exemple, sous Windows — cp1251, sous Linux — UTF‑8).
Erreur n° 3 : Lire et écrire tout le fichier en mémoire. Pour les gros fichiers, cette approche entraînera un dépassement de mémoire. Utilisez la lecture et l’écriture ligne par ligne.
Erreur n° 4 : Exceptions non gérées. Les fichiers peuvent ne pas exister, être verrouillés par d’autres processus ou contenir des caractères corrompus. Gérez toujours les exceptions ou utilisez try-with-resources.
Erreur n° 5 : Ré-encodage de fichiers binaires. N’essayez pas de ré-encoder des images, des PDF, des archives et autres fichiers binaires ! Cela les corrompra. Le ré-encodage n’a de sens que pour les fichiers texte.
GO TO FULL VERSION