Detection fichier binaire néfaste
Char Snipeur
Messages postés
9813
Date d'inscription
Statut
Contributeur
Dernière intervention
-
lami20j Messages postés 21331 Date d'inscription Statut Modérateur, Contributeur sécurité Dernière intervention -
lami20j Messages postés 21331 Date d'inscription Statut Modérateur, Contributeur sécurité Dernière intervention -
Bonjour,
voilà, je suis sous Redhat, et j'ai un jolie fichier texte (toto.cc) et kate me le détecte en, fichier binaire.
Pourtant c'est un bon fichier source tout ce qu'il y a de plus classique.
Comment changer ce type de détection ?
merci pour l'aide.
voilà, je suis sous Redhat, et j'ai un jolie fichier texte (toto.cc) et kate me le détecte en, fichier binaire.
Pourtant c'est un bon fichier source tout ce qu'il y a de plus classique.
Comment changer ce type de détection ?
merci pour l'aide.
A voir également:
- Detection fichier binaire néfaste
- Fichier bin - Guide
- Fichier epub - Guide
- Fichier rar - Guide
- Comment réduire la taille d'un fichier - Guide
- Fichier .dat - Guide
14 réponses
Salut,
Je ne connais pas Kate, mais peut être qu'il ne reconnaît pas l'extension .cc.
Si tu mets .c, ça donne quoi?
Et même s'il le decte comme binaire, il l'ouvre quand même?!!
Je ne connais pas Kate, mais peut être qu'il ne reconnaît pas l'extension .cc.
Si tu mets .c, ça donne quoi?
Et même s'il le decte comme binaire, il l'ouvre quand même?!!
Non, ce n'est pas ça, car j'ouvre sans souci les autres fichier .cc.
même file me sort comme type "data" alors qu'il sort un type correct pour les autres .cc.
Le problème c'est qu'il l'ouvre mais qu'il ne veux pas que je l'enregistre, car sinon ça ferai un fichier corrompu pattati pattata.
Merci, de ta réponse, mais ce n'est malheureusement pas aussi simple.
même file me sort comme type "data" alors qu'il sort un type correct pour les autres .cc.
Le problème c'est qu'il l'ouvre mais qu'il ne veux pas que je l'enregistre, car sinon ça ferai un fichier corrompu pattati pattata.
Merci, de ta réponse, mais ce n'est malheureusement pas aussi simple.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Re,
Tu pourras affiche le contenu.
Peut être qu'à cause d'un caractère au début de fichier le fichier n'est pas reconnu correctement.
Peut être un cat -A sur le fichier.
Tu pourras affiche le contenu.
Peut être qu'à cause d'un caractère au début de fichier le fichier n'est pas reconnu correctement.
Peut être un cat -A sur le fichier.
Merci, mais non, pas de problème en début de fichier...
dans le cat -A, j'ai vu de "^I" qui doivent correspondre au tabulations et de $ qui correspondent aux fin de ligne.
quelques "^@" que j'ai alors supprimé.
Le fichier faisant pas loin de 1000 lignes, il n'est pas facile de détecter des erreurs.
Néanmoins, le souci semblait bien venir de ces "^@". C'est caractère sont apparau à la place de "é" ou de "à" dans le texte.
Il n'y a pas un petit programme qui pourrai nétoyé tout ça ?
Merci.
dans le cat -A, j'ai vu de "^I" qui doivent correspondre au tabulations et de $ qui correspondent aux fin de ligne.
quelques "^@" que j'ai alors supprimé.
Le fichier faisant pas loin de 1000 lignes, il n'est pas facile de détecter des erreurs.
Néanmoins, le souci semblait bien venir de ces "^@". C'est caractère sont apparau à la place de "é" ou de "à" dans le texte.
Il n'y a pas un petit programme qui pourrai nétoyé tout ça ?
Merci.
Salut,
Ben, je pense que tu peux déjà depister le code des caractères et faire le néttoyage soir avec sed soit avec perl
Normalement il suffira une ligne de commande.
Ben, je pense que tu peux déjà depister le code des caractères et faire le néttoyage soir avec sed soit avec perl
Normalement il suffira une ligne de commande.
Re,
Prends juste quelques lignes de ton fichier et exécute cette commande
Prends juste quelques lignes de ton fichier et exécute cette commande
perl -ne 's/(.)/ord($1)/eg;print "$_\n"' quelque_lignes.cc
hello
file ne teste que le début du fichier selon /etc/magic ou /usr/share/file/magic
que dit
od -c toto.cc|head
file ne teste que le début du fichier selon /etc/magic ou /usr/share/file/magic
que dit
od -c toto.cc|head
Salut,
file ne teste que le début du fichier selon /etc/magic ou /usr/share/file/magic
Justement, le fait d'voir "data" comme résultat m'a fait penser qu'il y a un problème au début de fichier (voir message 7 ;-)
file ne teste que le début du fichier selon /etc/magic ou /usr/share/file/magic
Justement, le fait d'voir "data" comme résultat m'a fait penser qu'il y a un problème au début de fichier (voir message 7 ;-)
étonnement les caractères qui posaient problème n'étaient pas au début mais assez loin.
od affiche des caractères classiques.
Merci pour la commande perl, mais à part afficher un grand nombre de caractère, ça fait quoi ?
od affiche des caractères classiques.
Merci pour la commande perl, mais à part afficher un grand nombre de caractère, ça fait quoi ?
Re,
Ben, en fait le fichier sera transformer en code ASCII
C'est une commande d'analyse et pas de modification.
Faire la commande sur une ligne qui contient les caractères bizarre, nous permettra de depister la(les) séquences de codes (à savoir que tu dois normalement avoir le caractère sur au moins 2 octets)
Une fois le code depister on pourra efectuer un s/// en utilisant des caractères en hexa
Ben, en fait le fichier sera transformer en code ASCII
C'est une commande d'analyse et pas de modification.
Faire la commande sur une ligne qui contient les caractères bizarre, nous permettra de depister la(les) séquences de codes (à savoir que tu dois normalement avoir le caractère sur au moins 2 octets)
Une fois le code depister on pourra efectuer un s/// en utilisant des caractères en hexa
la séquence qui pose problème semble être plein de 0 (3 en hexadécimal, soit trois caractère à 0).
j'ai repéré avec hexdump. Le code perl donne pareil.
j'ai repéré avec hexdump. Le code perl donne pareil.
Ba en fait, la solution pour ce fichier là, je l'ai trouvé : supprimer à la main les caractères à la con (il y avai 3 séquences dans tout le fichier). Ensuite, le fichier est plutôt confidentiel :-(.
En fait, ce que je cherchais, c'est un automatisme pour traiter l'ensemble des fichiers du programme (1500) afin que le problème se reproduise le moins possible.
Et il risque de se reproduire, car les fichiers sont transporté de windows à linux par ftp et http, et éditer avec pleins d'éditeurs différents. Même si la consigne de ne plus mettre de caractères accentués dans les sources, il en reste toujours, c'est si vite fait d'en mettre un en tapant les commentaires... (même s'il est vrai qu'il faudrait passer aussi à l'anglais)
Merci de ta proposition en tout cas, c'est très sympa de ta part.
En fait, ce que je cherchais, c'est un automatisme pour traiter l'ensemble des fichiers du programme (1500) afin que le problème se reproduise le moins possible.
Et il risque de se reproduire, car les fichiers sont transporté de windows à linux par ftp et http, et éditer avec pleins d'éditeurs différents. Même si la consigne de ne plus mettre de caractères accentués dans les sources, il en reste toujours, c'est si vite fait d'en mettre un en tapant les commentaires... (même s'il est vrai qu'il faudrait passer aussi à l'anglais)
Merci de ta proposition en tout cas, c'est très sympa de ta part.
Re,
D'accord pour le confidentiel.
supprimer à la main les caractères à la con (il y avai 3 séquences dans tout le fichier).
En revanche tu ne peux pas produire un exemple de fichier avec ces séquences pour pouvoir tester dans le même environnment?
Tu peux mettre le lien en MP.
P.S. J'ai déjà traité des données confidentielle, réçu par des gens sur CCM ;-)), mais je ne peux pas te dire de la part de qui et quoi j'ai traité ;-)
D'accord pour le confidentiel.
supprimer à la main les caractères à la con (il y avai 3 séquences dans tout le fichier).
En revanche tu ne peux pas produire un exemple de fichier avec ces séquences pour pouvoir tester dans le même environnment?
Tu peux mettre le lien en MP.
P.S. J'ai déjà traité des données confidentielle, réçu par des gens sur CCM ;-)), mais je ne peux pas te dire de la part de qui et quoi j'ai traité ;-)