Detection fichier binaire néfaste
Char Snipeur -  
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.
--
Salutation ! (il faut bien que vous compreniez que j'ai TOUJOURS raison)
Char Snipeur
Configuration: AMD Atlhon XP 2400+
1Go DDRAM 2700
CM : ABIT AN7
Radeon Asus 9600SE
OS : win XP pack1; Mandrake 10.0

14 réponses

  1. lami20j Modérateur
    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?!!
    0
    1. Char Snipeur Auteur Contributeur
      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.
      0
      1. jipicy Modérateur
        Salut,

        Est-ce qu'avec un :
        cat toto.cc
        l'affichage est correct ?
        0
        1. lami20j Modérateur
          Re,

          Que te dit la commande?
          file toto.cc
          0
          1. jipicy Modérateur
            Salut,

            Extrait du #2 :
            même file me sort comme type "data" alors qu'il sort un type correct pour les autres .cc.

            ;-))
            0
          2. lami20j Modérateur
            @jipicySalut,

            Je n'ai pas vu celui là ;-), j'ai vu ta réponse seulement ;-))
            0
        3. lami20j Modérateur
          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.
          0
          1. Char Snipeur Auteur Contributeur
            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.
            0
            1. lami20j Modérateur
              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.
              0
              1. lami20j Modérateur
                Re,

                Prends juste quelques lignes de ton fichier et exécute cette commande
                perl -ne 's/(.)/ord($1)/eg;print "$_\n"' quelque_lignes.cc

                0
                1. dubcek
                  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
                  0
                  1. lami20j Modérateur
                    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 ;-)
                    0
                    1. Char Snipeur Auteur Contributeur
                      é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 ?
                      0
                      1. lami20j Modérateur
                        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
                        0
                    2. Char Snipeur Auteur Contributeur
                      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.
                      0
                      1. jipicy Modérateur
                        Re-

                        Extrait du man file :
                               -r, --raw
               Don't  translate  unprintable  characters to \ooo.
               Normally file translates unprintable characters to
               their octal representation.
                        A suivre...
                        0
                      2. Char Snipeur Auteur Contributeur
                        @jipicyOk, mais je n'ai pas utilisé file...
                        maintenant, il faut trouver comment virer ces trucs.PS : je ne connais file que depuis aujourd'hui, et je m'en sert juste en tant qu'affichage. Pour une fois je trouve que le man est mal fait.
                        0
                      3. lami20j Modérateur
                        @Char SnipeurRe,

                        Ben, laissons la théorie et passons à la pratique ;-)
                        Si ton fichier n'est pas confidentiel, compresse le et mets le sur cjoint, je vais regarder ce soir quand j'arrive à la maison si entre temps tu n'auras pas une solution.
                        0
                    3. Char Snipeur Auteur Contributeur
                      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.
                      0
                      1. lami20j Modérateur
                        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é ;-)
                        0

                        Discussions similaires

                        Ouvrir un fichier .pub sans Publisher
                        baissaoui

                        0 réponse