L’article ne peut pas être activé avec JavaScript. Vous pouvez également activer JavaScript dans votre navigateur et sur la nouvelle page.
Claude Code remplaçait tous les caractères non-ASCII d’un fichier qu’il ne pouvait pas lire en UTF-8, et la réparation fournie par Anthropic n’est pas une meilleure conversion. C’est un refus. L’entrée du journal des modifications pour la version 2.1.296 se lit comme suit : « Fixed Edit et NotebookEdit remplaçant chaque caractère non-ASCII dans les fichiers qui ne sont pas valides UTF-8 (Windows-1252, Shift-JIS, GBK) ; ces modifications sont désormais refusées. »
Il s’agit d’un bug d’intégrité des données plutôt que d’un crash. Un outil qui échoue bruyamment vous fait perdre votre après-midi. Un outil qui réécrit un fichier avec chaque lettre accentuée, chaque tréma et chaque caractère japonais ou chinois échangé vous laisse avec un fichier qui s’ouvre, se compile peut-être et est erroné d’une manière qu’une différence ne montre que si vous le regardez.
Trois encodages, et tous sont toujours utilisés
Les trois noms anthropiques sont ceux qu’un développeur rencontre dans l’ancien code plutôt que dans le nouveau. Windows-1252 est le codage sur un octet que Windows utilise pour le texte d’Europe occidentale depuis des années, et c’est ce qu’un CSV exporté à partir d’un ancien outil Windows a encore tendance à être. Shift-JIS est le codage japonais antérieur à l’adoption d’Unicode dans ce pays, et GBK couvre le chinois simplifié. Aucun d’entre eux n’est UTF-8 valide, donc un lecteur qui suppose que UTF-8 voit des octets invalides et doit décider quoi en faire. L’ancienne réponse de Claude Code était de remplacer, ce qui est le comportement standard d’un décodeur indulgent et le mauvais pour un fichier que vous êtes sur le point de réécrire sur le disque.
Anthropic ne publie aucun CVE, aucun indice de gravité et aucune gamme de versions affectées, et ne précise pas quand le comportement a commencé. Ce qui est daté, c’est le correctif. La version 2.1.296 a été envoyée au registre npm à 16:58:10 UTC le 9 octobre, et le registre la répertorie toujours comme les deux. dernier et suivantavec le canal stable séparé le 2.1.287 à partir du 1er octobre. Ces chiffres ont été lus à 21h52 UTC le 10 octobre et le journal des modifications à 21h35 UTC le même jour.
Deux autres correctifs dans la même version ont également perdu le texte
2.1.296 est une version importante, regroupée par Anthropic en ajouts, modifications, neuf améliorations et 56 corrections de bugs, et deux de ces correctifs ont la même saveur. On lit : « Corrigé CLAUDE_CODE_TRANSCRIPT_LOCAL_GC supprimer un message de la transcription enregistrée lorsque son texte contenait une ligne Unicode ou un séparateur de paragraphe (U+2028, U+2029). » L’autre : « Corrigé Claude Purge laissant une invite dans le fichier historique lorsque son texte contenait une ligne Unicode ou un séparateur de paragraphe (U+2028, U+2029). »
U+2028 et U+2029 sont des caractères invisibles qui signifient un saut de ligne et un saut de paragraphe, et ils arrivent dans une invite via un collage à partir d’un traitement de texte ou d’une page Web plutôt que par quelqu’un qui les tape. Une faute a laissé tomber un message qui aurait dû être conservé, l’autre a conservé une invite qui aurait dû être purgée, et les deux activent un personnage que personne ne peut voir. Le journal des modifications enregistre une erreur similaire plus tôt dans le mois, lorsque la version 2.1.286 a comblé quatre lacunes de rédaction secrète, l’une d’entre elles étant ouverte par un personnage invisible.
La lecture de fichiers volumineux et les fins de lignes Windows ont également changé
Deux autres entrées dans la version concernent ce que l’outil ouvrira et ne ouvrira pas. Anthropique « Ajout d’un autoriser_large option à l’outil de lecture afin que Claude puisse lire un fichier texte au-delà des limites de taille habituelles en un seul appel lorsqu’il a besoin du fichier entier et que le contexte a de la place », et il « Correction de l’outil Workflow refusant les fichiers de script avec des fins de ligne CRLF, tels que les fichiers extraits sous Windows ». Les deux pointent dans le même sens que le correctif d’encodage : à l’écart entre ce qu’un fichier contient réellement et ce qu’un outil suppose qu’il contient.
Il n’y a aucune action à entreprendre au-delà de la mise à jour, et aucune déclaration d’Anthropic concernant les fichiers qui ont été modifiés avant l’arrivée du correctif. Trois versions numérotées ont été publiées dans les deux jours qui l’ont précédé, et celle qui a ouvert cette exécution était la 2.1.293, qui a retiré un correctif de session cloud deux jours après son expédition.