Forum Programmation.autre [expression régulière] détecter un caractère non espace dans une séquence.

Posté par (page perso) .
Tags : aucun
0
24
sept.
2007
Bonjour, je dois parser des fichiers textes dans lesquels des informations se trouvent à des emplacement définis.

Je cherche une regexp qui va me capturer une zone de texte de longueur définie, dans laquel, j'ai au moins un catactère non espace (ie. différent de \s)

Exemple :

J'ai la chaine " 2 HJ/KL K"
Le nombre se trouve toujours au 4ème caractère et je sais que j'ai une zone de texte de 10 caractères, dans lequel je peux avoir tout et n'importe quoi.

le problème est que si je met .{10 }, les zones totalement constituées d'espace vont matcher. je cherche donc une expression qui me garantisse que sur ces 10 caractères, j'ai tout, mais au moins un caractère non espace. C'est possible ?
  • # Re:

    Posté par . Évalué à 1.

    > C'est possible ?

    Oui vu que j'ai réussi à dessiner l'automate équivalent.
  • # parser ?

    Posté par . Évalué à 2.

    ben tu veux parser avec quoi ?

    parce que là, sans avoir plus d'info, on sait juste que c'est un regexp...
    c'est un peu juste comme enoncé.

    sinon un simple cut ou colrm pour vire les caracteres 1 à 3 et 14 et plus
    te permettrait de recuperer les caracteres 4 à 13
    • [^] # Re: parser ?

      Posté par . Évalué à 1.

      clair que ça dépend du contexte ...
      Ca te conviendra pas forcément, mais avec les commandes usuelles du shell :
      cat | grep -Ev '^.{4}[[:space:]]{10}' | cut -c 4-14
      • [^] # Re: parser ?

        Posté par . Évalué à 1.

        rha le boulet, je me gave pour bien faire apparaitre les [, et j'oublie d'échapper les < et > ...
        je pensais cat <fichier> | (...), 'videmment ...
        • [^] # Re: parser ?

          Posté par (page perso) . Évalué à 2.

          cat fichier | grep -Ev '^.{4}:space:{10}'


          Je n'ai jamais vraiment trop bien compris pourquoi autant de personnes s'obstinent à utiliser 'cat' dans ce cas, alors qu'un simple :

          grep -Ev '^.{4}:space:{10}' fichier
          fait le même travail. M'enfin...
          • [^] # Re: parser ?

            Posté par . Évalué à 2.

            parce que pendant que tu élabores la regex, c'est plus facile de modifier la fin de ta ligne (la regex) si y a pas le nom de fichier en fin de ligne.
            Après, pas pensé nettoyé ... je suis contre l'utilisation de cat dans une série d'opérations pipée aussi :)
          • [^] # Re: parser ?

            Posté par . Évalué à 1.

            Peut être aussi parce que quelque part, c'est rassurant de savoir que le fichier sera lu par cat, et envoyé à une commande (ici grep) sans être altéré.
            Il y a bien des commandes qui interviennent directement dans le fichier source, un peu comme sed -i, mais nativement, i.e. sans passer d'options. Du coup, si la commande foire, le fichier initial est foutu.
            Je ne dis pas que c'est bien, je cherche juste une justification...
            • [^] # Re: parser ?

              Posté par . Évalué à 1.

              dans la meme idée je prefere faire un

              cat fichier | sed xxxxx
              pour voir si je ne me suis pas tromper,

              et ensuite seulement un
              cat fichier | sed xxxxx >fichier_tempo

              et ensuite pour les memes arguments que gyro ou encore plus haut, ca m'evite d'avoir le nom de fichier à la fin de ma regexp, si je dois la modifier.
              • [^] # Re: parser ?

                Posté par . Évalué à 2.

                je suis plus d'accord avec Archibald là.
                le fait que j'ai mis un cat dans mon commentaire précédent, c'est vraiment un artefact de ma méthode de dév de regex. La finalisation du script consiste à virer toutes les scories du genre un cat qui traîne.
                Pour un "vrai" script, le cat aurait vite sauté :-)

                pour l'exemple que tu donnes, si tu veux conserver une copie de ton fichier de départ, je ferais plus un :

                tar czf fichier.tar.gz fichier
                sed -i xxxxx fichier
    • [^] # Re: parser ?

      Posté par (page perso) . Évalué à 2.

      Précision : c'est pour un programme en C.

      Je me suis mal exprimé...

      Mon problème : j'ai une zone d'exactement n caractères, n fixé à l'avance, dans une chaine texte. Cette zone peut contenir n'importe quel caractère.

      Je cherche une regexp qui match uniquement s'il y a au moins un caractère non espace (un \S) quelque part (je sais pas où...) dans les 10 caractères.

      Donc si j'ai
      '          ' ça matche pas, mais si j'ai
      '      *   ' ça matche

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: parser ?

        Posté par . Évalué à 2.

        fallait mettre dans programmation.c alors ;)
        et préciser le moteur de regex que tu utilises puisqu'apparement, tu en utilises un.

        Sinon, hors syntaxe particulière, la regex que tu vas chercher, c'est l'inversion de la regex qui matche 10 espaces consécutifs en fait.
        • [^] # Re: parser ?

          Posté par . Évalué à 1.

          j'aurais pas dis mieux :

          Sinon, hors syntaxe particulière, la regex que tu vas chercher, c'est l'inversion de la regex qui matche 10 espaces consécutifs en fait.


          je l'aurais juste dis differemment :
          tu cherches tous SAUF la combinaison de 10 espaces consecutifs.
          • [^] # Re: parser ?

            Posté par (page perso) . Évalué à 2.

            C'est un moteur strictement compatible perl.

            Super, j'y avais pas pensé, mais je sais pas comment l'écrire
            l'inversion c'est avec '^' non ?

            donc ^(\s{10})
            le problème est que ça signifie début de ligne, 10 espaces.

            Et si je fais
            [^\s]{10} ça veut dire : tout caractère sauf \s sur 10 caractères.

            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

            • [^] # Re: parser ?

              Posté par . Évalué à 2.

              Le problème, ce sont les 10 caractères exacts : Est-ce que la reconnaissance de ONZE espaces consécutifs serait un problème, ou bien ne cherche-tu qu'à récupérer toutes les chaînes qui contiennent au moins un caractère qui ne soit pas un espace, quelque soit leur longueur ? Auquel cas l'expression que j'ai écrite plus bas devrait s'appliquer ...

              .*[^ ]\+.*
  • # Avec l'opérateur de négation ?

    Posté par . Évalué à 2.

    La plupart des parsers d'expression rationnelle permettent de spécifier une liste de caractères reconnaissables entre crochets [ et ] et celle-ci peut-être inversée avec l'opérateur ^ (différent du marqueur de début de ligne).

    Donc, si tu veux matcher au moins une fois un non-espace, tu fais.

    .*[^ ]+.*.

    Si tu as un chiffre en quatrième position à reconnaître et que le reste des caractères ne t'importe que peu, tu peux faire

    ...[0-9].*

    Maintenant, si tu dois reconnaître exactement 10 caractères dont la nature change, c'est plus compliqué parce qu'il te faut un registre qui sort du contexte de l'automate. Ou alors il faut faire un automate à 21 états (si on veut reconnaître exactement 10 caractères) et c'est chiant à simplifier, évidemment.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.