Règles de prompting pour réduire les incidents de mojibake avec Codex sous Windows

Quand on fait travailler Codex sous Windows sur des fichiers contenant du japonais, ce qui aide le plus au départ n’est pas d’aligner parfaitement tous les réglages de l’éditeur et du shell, mais d’expliciter à Codex « comment lire, comment écrire, et où s’arrêter ».

Les situations qui posent le plus de problèmes sont notamment les suivantes.

• Des fichiers en UTF-8, CP932 et de la famille UTF-16 coexistent
• Le texte semble lisible à l’écran, mais l’interprétation réelle des octets est décalée
• On croit n’avoir fait qu’une petite retouche à un fichier existant, mais il est réenregistré dans un autre encodage lors de la sauvegarde
• La casse se produit dans du « non-code » : CSV, TXT, journaux, Markdown, fichiers de configuration
• Un script temporaire ou une sortie shell est enregistré tel quel, et l’incident devient permanent

Codex d’OpenAI est plus stable si on le traite moins comme un interlocuteur de chat ponctuel que comme un coéquipier utilisé en continu, à qui l’on donne des réglages et des règles de travail. En particulier, si votre flux de travail fait lire AGENTS.md à Codex, il est plus efficace d’y inscrire durablement les règles relatives à l’encodage des caractères plutôt que de les répéter oralement à chaque fois.

Dans cet article, nous organisons, dans une perspective pratique, les instructions les plus efficaces à donner d’entrée à Codex pour qu’il traite en toute sécurité des fichiers japonais sous Windows.

1. La conclusion d’abord

Dans un environnement Windows, le moyen le plus efficace de réduire les incidents de mojibake avec Codex est de fixer d’abord la procédure de travail relative à l’encodage des caractères.

Voici les règles qui ont le plus d’effet.

• Pour les fichiers existants contenant du japonais, faire vérifier l’encodage probable, la présence d’un BOM et le style de fin de ligne avant la lecture
• Pour les fichiers où le mojibake est suspecté, ne pas laisser enregistrer tant que la confiance n’est pas acquise
• Pour les fichiers existants, faire préserver l’encodage, le BOM et les fins de ligne d’origine
• Pour les nouveaux fichiers, s’orienter vers UTF-8, conformément aux conventions du dépôt
• Pour les écritures, n’autoriser que les méthodes permettant d’expliciter l’encodage
• Après l’enregistrement, faire relire le fichier et vérifier des lignes japonaises représentatives

En version courte pour l’usage quotidien, cela donne à peu près ceci.

• Vérifier avant de lire
• Interdire l’enregistrement en cas de doute
• Préserver l’existant, UTF-8 uniquement pour le nouveau
• Interdire les chemins d’écriture ambigus
• Relire à la fin pour vérifier

À l’inverse, voici le genre d’instructions dangereuses.

• « Corrige le mojibake »
• « Passe tout en UTF-8 »
• « Sors-moi un CSV »
• « Adapte comme tu peux »
• « Enregistre pour voir, on verra bien »

Aucune de ces instructions ne précise à quel stade Codex doit s’arrêter. Pour la prévention du mojibake, il faut préciser non seulement ce qu’il faut faire, mais aussi où s’arrêter avant d’enregistrer.

2. Pourquoi les incidents de mojibake sont-ils si fréquents sous Windows ?

Le vrai problème n’est pas que Codex serait faible en japonais, mais que du côté des ressources Windows, plusieurs encodages et plusieurs chemins d’écriture coexistent.

Dans la pratique, ce genre de mélange n’a rien d’exceptionnel.

• Les sources récentes et le Markdown sont en UTF-8
• Les anciens CSV, TXT, journaux et fichiers de configuration sont de la famille CP932
• Certaines sorties et certains artefacts générés par des outils sont de la famille UTF-16
• Les chemins d’enregistrement diffèrent selon l’éditeur, le shell ou les sorties issues d’Excel
• Les fins de ligne mélangent elles aussi LF et CRLF

Dans cet état, si Codex fait ne serait-ce qu’une seule mauvaise interprétation, il peut continuer l’édition suivante en traitant une chaîne qu’il n’a pas réellement su lire comme si elle avait été lue correctement. Et si l’enregistrement se fait tel quel, ce n’est plus un problème d’affichage, mais une corruption du fichier lui-même, désormais figée.

C’est pourquoi la prévention du mojibake revient, en fin de compte, à la question de la gestion de la procédure d’E/S.

3. Les règles à fixer en premier pour Codex

3.1 Faire vérifier l’encodage probable, le BOM et les fins de ligne avant la lecture

La première règle est celle-ci.

Avant de lire un fichier existant contenant du japonais, vérifiez l’encodage probable actuel, la présence d’un BOM et le style de fin de ligne ; si quelque chose semble suspect, ne poursuivez pas directement l’interprétation du contenu.

Le point clé est de passer à l’approche « avant de lire le texte, on regarde d’abord les prémisses du fichier ».

3.2 Ne pas laisser enregistrer sur simple supposition un fichier où le mojibake est suspecté

Ce point est particulièrement important.

Lorsque le mojibake est suspecté, traitez le fichier en lecture seule pendant l’investigation et interdisez l’écrasement tant que l’interprétation ne semble pas fiable.

C’est vrai aussi pour un humain : il ne faut jamais enregistrer un fichier qu’on n’a pas réellement su lire. Enregistrer en se disant « ça a l’air un peu cassé, mais c’est probablement ça » transforme cette supposition en version définitive de l’incident.

3.3 Préserver les fichiers existants, et ne passer à UTF-8 par défaut que pour les nouveaux fichiers

Dans le contexte de la prévention du mojibake, « unifie tout en UTF-8 » est étonnamment dangereux.

Décider, à terme, de faire migrer tout le dépôt vers UTF-8 peut être légitime, mais il est plus sûr de le traiter comme une tâche séparée, menée en examinant le diff et le périmètre d’impact. Pour les modifications du quotidien, ce mode de fonctionnement est le plus stable.

• Lors de l’édition d’un fichier existant, préserver son encodage d’origine
• Lors de l’ajout d’un nouveau fichier, le créer en UTF-8 conformément aux conventions du dépôt
• Si la conversion d’un fichier existant est nécessaire, la séparer des corrections fonctionnelles habituelles

3.4 Ne pas laisser utiliser par défaut des chemins d’écriture ambigus

Ce qui multiplie les incidents sous Windows, c’est « comme c’est une petite sortie, on l’écrit sans soin depuis le shell ».

• Rediriger la sortie directement
• Enregistrer directement avec une commande pratique
• Promouvoir tel quel un artefact temporaire au rang de fichier de production

Ces chemins n’explicitent souvent pas l’encodage, ce qui en fait un terreau propice aux incidents. Il est donc plus sûr de fixer aussi, pour Codex, la façon de choisir le moyen d’écriture.

3.5 Après l’enregistrement, faire relire le fichier et vérifier des lignes japonaises représentatives

« L’enregistrement a réussi » et « rien n’est cassé » ne sont pas la même chose.

L’important est de faire relire, après l’enregistrement, des lignes japonaises représentatives, et de faire vérifier les points suivants.

• Aucun caractère de remplacement U+FFFD ne s’est glissé
• Le nombre de ? n’a pas augmenté de façon anormale
• Le diff n’est pas devenu un énorme changement portant uniquement sur le BOM ou les fins de ligne
• Le texte japonais qui n’était pas censé changer métier est resté intact

3.6 En cas de signe anormal, faire rapporter avant de corriger

Pour les incidents d’encodage, on limite mieux les dégâts en faisant arrêter et rapporter Codex plutôt qu’en le forçant à corriger.

Par exemple, si l’un des signes suivants apparaît, il est plus sûr de le traiter d’emblée comme une anomalie.

• Une augmentation de U+FFFD
• Une augmentation de ?
• Un changement de BOM inattendu
• Un diff massif portant uniquement sur les fins de ligne
• Seules les lignes japonaises changent de façon anormalement importante

4. Comme instruction courte à joindre à chaque tâche

Pour une version courte à joindre à chaque tâche, ceci est déjà largement suffisant.

Dans cette tâche, éviter les incidents d'encodage des caractères est la priorité absolue.

- Pour les fichiers existants contenant du japonais, vérifier l'encodage probable, la présence d'un BOM et le style de fin de ligne avant la lecture
- Ne pas enregistrer sur simple supposition un fichier où le mojibake est suspecté
- Préserver l'encodage / le BOM / les fins de ligne d'origine des fichiers existants
- Créer les nouveaux fichiers en UTF-8, conformément aux conventions du dépôt
- N'utiliser pour l'écriture que des méthodes permettant d'expliciter l'encodage
- Après l'enregistrement, relire le fichier et vérifier que les lignes japonaises représentatives ne sont pas cassées
- Signaler comme anomalie toute augmentation de `U+FFFD` ou de `?`, tout incident de BOM / fin de ligne, ou tout diff massif

Si en plus les fichiers concernés sont déjà connus, ajouter cette ligne stabilise considérablement les choses.

Fichiers concernés : <paths> / Chaînes représentatives : "<examples>"

Fournir des chaînes représentatives est remarquablement efficace : cela donne à Codex un point de vigilance concret, « ce texte japonais ne doit pas être cassé ».

5. Un modèle à inscrire durablement dans AGENTS.md

Plutôt que de répéter le même avertissement encore et encore, mieux vaut l’inscrire dans AGENTS.md. Voici un modèle orienté pratique, destiné aux dépôts qui manipulent des fichiers japonais sous Windows.

# Text Encoding Rules

## Scope
This repository may contain Japanese text and mixed legacy encodings.
Avoid mojibake and accidental re-encoding above all else.

## Mandatory Rules
- Before reading or editing an existing text file that may contain Japanese, first determine:
  - likely encoding
  - BOM presence
  - newline style
- If mojibake is suspected, do not save the file until the encoding interpretation is credible.
- Preserve the original encoding, BOM, and newline style for existing files.
- Treat "convert to UTF-8" as a separate, explicit task.
- New files should follow repository convention. If there is no clear rule, prefer UTF-8 and state whether BOM is used.
- Do not use ambiguous write paths by default, such as shell redirection or convenience commands without explicit encoding control.
- After writing, reopen the file and verify representative Japanese lines.
- If any of the following appears, stop and report:
  - replacement characters
  - unexpected `?`
  - unintended BOM change
  - unintended newline conversion
  - whole-file diffs without a business reason

## Reporting Format
For each changed text file, report:
- path
- detected or preserved encoding
- BOM presence
- newline style
- how verification was performed
- whether representative Japanese text remained intact

Ce qui rend ce modèle intéressant, c’est qu’il fixe non seulement comment éditer, mais aussi comment ne pas casser les choses. Ces deux lignes, en particulier, sont particulièrement efficaces :

• If mojibake is suspected, do not save ...
• Treat "convert to UTF-8" as a separate, explicit task.

6. Mauvaises instructions et bonnes instructions

Pour la prévention du mojibake, la granularité des instructions influence fortement le résultat.

Le point clé est de toujours écrire à la fois les vérifications à faire avant d’agir et la validation après l’enregistrement.

7. Liste de vérification pour la relecture

Une fois que Codex a terminé son travail, fixer également les points de contrôle à vérifier côté humain rend l’ensemble encore plus fiable.

• L’encodage, le BOM et les fins de ligne sont-ils rapportés pour chaque fichier modifié ?
• Seules les lignes japonaises ont-elles changé de façon anormalement importante ?
• Y a-t-il un grand nombre de diffs portant uniquement sur les fins de ligne ?
• Le nombre de U+FFFD ou de ? a-t-il augmenté ?
• Y a-t-il des diffs globaux sans rapport avec le changement métier ?
• Les CSV ou les journaux présentent-ils un décalage de colonnes ou des guillemets mal fermés ?

Ce qui compte dans la prévention du mojibake, c’est d’arrêter rapidement les diffs suspects, plus que d’accumuler des diffs réussis.

8. En résumé

Quand on fait traiter des fichiers japonais par Codex sous Windows, ce qui aide le plus au départ n’est pas de peaufiner parfaitement la configuration du PC, mais d’expliciter à Codex la procédure de travail relative à l’encodage des caractères.

Cinq points sont particulièrement à retenir.

• Faire vérifier l’encodage / le BOM / les fins de ligne avant la lecture
• Si le mojibake est suspecté, ne pas laisser enregistrer sur simple supposition
• Préserver les fichiers existants, et n’orienter vers UTF-8 que les nouveaux fichiers
• Interdire les chemins d’écriture ambigus
• Après l’enregistrement, faire relire le fichier et vérifier des lignes japonaises représentatives

Et si vous devez le répéter à chaque fois, inscrivez-le dans AGENTS.md. C’est la solution la plus pratique.

Le cœur de la prévention du mojibake ne consiste pas à demander de « bien traiter le japonais », mais à formaliser par écrit les conditions dans lesquelles l’enregistrement est autorisé et celles où il faut s’arrêter. Une fois ce travail fait, Codex devient nettement plus facile à utiliser, même sous Windows.

9. Références

• OpenAI Codex docs, Best practices
• OpenAI Codex docs, Custom instructions with AGENTS.md
• OpenAI Codex docs, Windows

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Pourquoi Codex déforme-t-il le texte japonais (mojibake) sous Windows ?

La vraie cause n'est pas que Codex serait faible en japonais, mais que, du côté des ressources Windows, plusieurs encodages (UTF-8, CP932, la famille UTF-16, etc.) et plusieurs chemins d'écriture coexistent. Dans cet état, si Codex fait une seule mauvaise interprétation, il peut continuer l'édition suivante en traitant une chaîne qu'il n'a pas réellement su lire comme si elle avait été lue correctement. Et si l'enregistrement se fait tel quel, le problème n'est plus un simple problème d'affichage : il devient une corruption du fichier lui-même, désormais figée. C'est pourquoi la prévention du mojibake revient, en fin de compte, à la question de savoir comment gérer la procédure d'E/S.

Quelles instructions donner pour éviter le mojibake avec Codex ?

Le plus efficace est de fixer d'abord la procédure de travail relative à l'encodage des caractères. Concrètement, il s'agit de ces cinq points : faire vérifier l'encodage probable, la présence d'un BOM et le style de fin de ligne avant de lire tout fichier existant contenant du japonais ; interdire l'enregistrement d'un fichier dont le mojibake est suspecté tant que la confiance n'est pas acquise ; préserver l'encodage d'origine des fichiers existants et ne passer à UTF-8 que pour les nouveaux fichiers ; n'utiliser que des méthodes d'écriture permettant d'expliciter l'encodage ; et, après l'enregistrement, relire le fichier pour vérifier des lignes japonaises représentatives. Fournir les fichiers concernés et des « chaînes représentatives qui ne doivent pas être cassées » rend le résultat encore plus stable.

Faut-il éviter de dire « corrige le mojibake » ou « passe tout en UTF-8 » ?

Oui, ces deux instructions sont dangereuses. Elles ne précisent pas à quel stade Codex doit arrêter l'enregistrement, ce qui facilite un enregistrement fait sur simple supposition et fige l'incident. « Tout passer en UTF-8 » est particulièrement risqué : il est plus sûr de faire préserver l'encodage, le BOM et les fins de ligne d'origine lors de l'édition des fichiers existants, et de traiter le passage de tout le dépôt à UTF-8 comme une tâche séparée, menée en examinant le diff et le périmètre d'impact. À la place, il vaut mieux donner une instruction du type « distingue si c'est une corruption réelle ou un simple problème d'affichage, et n'enregistre pas sur simple supposition », en incluant à la fois les vérifications à faire avant d'agir et la validation après l'enregistrement.

Vaut-il mieux écrire les règles d'encodage dans AGENTS.md ?

Si vous devez répéter le même avertissement à chaque tâche, autant l'inscrire de façon permanente dans AGENTS.md. Regroupez-y les règles suivantes : vérification de l'encodage, du BOM et des fins de ligne avant lecture ; interdiction d'enregistrer tant que le mojibake est suspecté ; préservation des fichiers existants ; traitement de la conversion vers UTF-8 comme une tâche séparée ; interdiction des chemins d'écriture ambigus ; vérification par relecture après enregistrement ; et l'obligation de s'arrêter et de rendre compte en cas d'anomalie. En fixant en plus un format qui fait rapporter, pour chaque fichier modifié, l'encodage, le BOM, le style de fin de ligne et la méthode de vérification, la relecture côté révision devient elle aussi plus fiable.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.