Erreurs cachées dans fichiers texte .txt
Résolu
lativ
-
lativ -
lativ -
Bonjour,
Je rencontre un problème curieux : j'ai écrit moi-même (sous Delphi) un programme qui traite des fichiers texte afin d'en tirer différentes informations. Tout fonctionnait très bien depuis quelques années, et brusquement plantage. J'ai examiné mon fichier texte, et suis parvenu à identifier la ligne qui faisait planter, en la supprimant le logiciel fonctionnait de nouveau. Alors j'ai retapé à la main la ligne qui faisait planter (en vérifiant soigneusement caractère par caractère), et maintenant ça ne plante plus!
Explication du mystère?
Je rencontre un problème curieux : j'ai écrit moi-même (sous Delphi) un programme qui traite des fichiers texte afin d'en tirer différentes informations. Tout fonctionnait très bien depuis quelques années, et brusquement plantage. J'ai examiné mon fichier texte, et suis parvenu à identifier la ligne qui faisait planter, en la supprimant le logiciel fonctionnait de nouveau. Alors j'ai retapé à la main la ligne qui faisait planter (en vérifiant soigneusement caractère par caractère), et maintenant ça ne plante plus!
Explication du mystère?
3 réponses
-
Sans le fichier erronné en question ça va être compliqué de répondre
Peut-être un caractère non imprimable, un problème d'encodage, un copier/coller avec une erreur d'écriture (disque dur défaillant), ça peut venir de pas mal d'endroits.
Si tu as à nouveau cette erreur copie le fichier defectueux AVANT de corriger l'erreur pour pouvoir faire une comparaison octet par octet à posteriori-
Je ne pense pas qu'il s'agisse d'une défaillance de disque dur ou similaire car le fichier texte en question s'ouvre sans problème dans le bloc notes. Le bloc notes ignorerait-il les erreurs CRC? J'ai conservé le fichier défectueux et essayé une comparaison octet par octet à l'aide de Hexedit, la zone suspecte semble identique.
-
- Le fichier provoquant l'erreur est : http://vital.chauve.free.fr/calendtmp.txt
Le fichier corrigé est : http://vital.chauve.free.fr/calend.txt
les fichiers sont différents à partir de la ligne 107, mais ce ne sont pas les lignes 107 et suivantes qui provoquaient l'erreur, ce sont les lignes 102 à 104.
Le fichier texte contient des échéances à satisfaire (heure en format hh:mm) ou déjà satisfaites (heure en format hhhmm), et le logiciel a pour fonction d'envoyer un avertissement s'il existe des échéances à moins de huit jours non satisfaites. Après l'avertissement (s'il y a lieu) le logiciel propose d'ouvrir le fichier texte dans le bloc notes pour le mettre à jour.
Merci de vous intéresser à mon problème.
-
-
-
Il y a bien une différence d'encodage entre les fichiers :
(ci dessous, "error" est le fichier déclenchant l'erreur et "clean" le fichier sans erreur ) :
$file error
error: ISO-8859 text
$file clean
clean: Non-ISO extended-ASCII text, with CRLF line terminators
Quand on fait un diff binaire :
On voit que la version "clean" utilise "0D 0A" pour un retour à la ligne -> windows
Alors que la version "error" utilise uniquement "0A", ce qui ressemble plutot à du unix.
Les fichiers ont été créés sur des machines différentes ? ou des éditeurs de textes différents qui font chacun à leur sauce ? -
merci pour tout.
Il y a bien quelques différences au début du fichier, mais ce n'étaient pas elles qui provoquaient l'erreur, à l'offset 1158h il y a un espace devant des caractères de tabulation, ainsi la ligne commence par un espace, ce qui ne plaît pas à mon programme, insuffisamment blindé. Je viens bien sûr de le corriger.
Mais ce qui est traître c'est que si on met un espace avant une tabulation, le bloc notes ne montre aucune différence!
