Discussion :

[difah]

Bonjour tout le monde.

Je suis entrain de me prendre la tête sur une expression régulière et je commence a devenir fou ...

J'explique :

J'ai un fichier de logs avec des logs de ce genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[Tue Mar 25 14:47:11 2008]  [MACK] [SHANE] [c:\documents and settings\ut0gpx\bureau\bidule.exe] [kernel32.dll] [0x1da4] [IMNT]

Que je parse avec l'expression régulière suivante pour avoir chaque élément :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Regex _block_regex = new Regex("\\[([^\\[\\]]*)\\]", RegexOptions.Compiled | RegexOptions.CultureInvariant);

Ça marche nickel mais ... lorsque j'ai des chemins de fichiers avec des crochets dedans : c:\documents and settings\ut0gpx\bureau\bidule[1].exe

eh bien ça fausse tout ... je récupère uniquement : 1 et pas c:\documents and settings\ut0gpx\bureau\bidule[1].exe

Auriez vous une idée à me suggérer au sujet de mon expression régulière ?

Je vous remercie d'avance pour votre aide.

[BCmDev]

Il faut à mon avis que tu effectues un remplacement de caractère avant d'écrire dans ton log afin d'éliminer les crochets au sein des valeurs, car comment séparer les chaînes si le séparateur est contenu dans les chaînes à séparer ? Imagine qu'au lieu de [c:\documents and settings\ut0gpx\bureau\bidule[1].exe] tu aies [c:\documents and settings\ut0gpx\bureau\bidule][.exe]. Ton expression régulière décomposera bien la chaîne, mais cela ne donnera pas ce que tu souhaites...

[ced600]

et tout bétement cela "\\[\\]" -> cela ne pourrait pas marcher ?

[BCmDev]

Non.
Ou alors tu n'as pas développé toute ton idée...

[ced600]

Non.
Ou alors tu n'as pas développé toute ton idée...

si si j'ai dev toute mon idée, je suis débutant dans la construction d'expression régulière.
En fait moi j'aurais attaqué son fichier à base de split et de substring, mais bon tout le monde n'aime pas être aussi barbare.

[BCmDev]

Je ne crois pas que ce soit un problème de méthode. Tu peux utiliser Split et Substring, tu te heurteras au même mur.

[ced600]

non

[BCmDev]

Prouve-le.
(je suis un incorrigible pessimiste).

[ced600]

Bah si je suppose que ça ligne est telle qu'elle dans un fichier, il suffit de lire le fichier ligne par ligne et pour chaque ligne on fait ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
//line est la variable qui contient la ligne actuelle.
//Avant la boucle on a fait une liste de string : List<string> liste = new List<string>();
string [] elts;
elts = line.Split(' ');
foreach (string elt in elts)
{
    liste.Add(elt.SubString(1, elt.length -1 ));
}

Cela devrait marcher, j'ai juste pas envie de faire la mini appli et tester. Bien sur je considère qu'il veut récupérer tous ceux qui est entre [], s'il veut juste le path, il faut rajouter une condition où on teste la présence de \

[BCmDev]

Ça ne peut pas fonctionner. Tu découpes sur le caractère espace, mais ce n'est pas un bon critère. D'ailleurs, on peut voir dans son exemple que le nom de fichier contient un espace.
Mais ne laisse pas tomber...

[ced600]

oui j'ai oublié cela mais ce n'est pas une problème.
Je te rajoute une ou 2 variables booléenne et il n'y a plus de problème.

Il suffit de mettre le bool à vrai lorsque le string commence avec [ et tant que tu ne rencontre pas un ] il est vrai, et lorsqu'il est vrai, toutes les cases que tu parcoures appartiennent à la même "structure".

Tu peux même splitter sur le [, et deviner lorsque tu es dans un path, et vérifier si celui-ci est contenu sur x cases, et donc reconstruire le path d'origine.

[ced600]

Bien sur j'ai supposé : Fichier non erroné, mais en se penchant sur le problème il y a moyen de vérifier si celui-ci est erronné ou non.

Utiliser les strings est certainement plus lourd, mais en attendant de trouver la bonne expression régulière, c'est une solution.

En plus avec un peu de chance la séparation est faite par des doubles espaces.
Dans ce cas tu remplaces les doubles espaces par un ' est hop tu split sur le '

[BCmDev]

Ça ne fonctionne toujours pas.
Essaie tes algorithmes sur l'exemple de difah : [c:\documents and settings\ut0gpx\bureau\bidule[1].exe].
Le double espace c'est pareil : tu peux en avoir dans un nom de fichier.

Je reste persuadé que la solution est d'encoder les caractères "[" et "]" des données à logguer, et j'attends ta solution avec toujours plus d'impatience...

[ced600]

Bon bah je te remplace "] [" par un caractère interdit dans les rep, et je split dessus !!!!
Au par avant je fait une substring pour enlever le premier [ et le dernier ].
Pour l'instant je n'ai pas le temps de faire l'application, mais si tu me trouves encore un problème je te le ferais.

Je sens que tu mets en doute la possibilité de faire ce que je te dit sans spliter les [ et ], mais bon c possible, je suis assez tordu pour te trouver la solution même si je considère qu'elle est moins performante que la regexp.

Et si tu me dis que tu peux avoir "] [" dans un répertoire, moi je veux voir le path !!!!

[Skalp]

Il faut à mon avis que tu effectues un remplacement de caractère avant d'écrire dans ton log afin d'éliminer les crochets au sein des valeurs, car comment séparer les chaînes si le séparateur est contenu dans les chaînes à séparer ? Imagine qu'au lieu de [c:\documents and settings\ut0gpx\bureau\bidule[1].exe] tu aies [c:\documents and settings\ut0gpx\bureau\bidule][.exe]. Ton expression régulière décomposera bien la chaîne, mais cela ne donnera pas ce que tu souhaites...

Après y avoir réfléchi de mon côté, je suis arrivé à la même conclusion que BCmDev.

Mais si difah (qui n'a pas répondu depuis...) n'a pas la main sur les log, il va falloir ajouter des règles de gestion plus barbares (c'est là que ced600 intervient ) en vérifiant les caractères voisins des séparateurs pour pouvoir dire si oui non le caractère courant est un séparateur.

[BCmDev]

Bon bah je te remplace "] [" par un caractère interdit dans les rep, et je split dessus !!!!

Abandonne cette idée puisque "] [" peut être présent dans un chemin d'accès.

Et si tu me dis que tu peux avoir "] [" dans un répertoire, moi je veux voir le path !!!!

La question n'est pas de savoir si cela est courant ou non. Si cela peut arriver, alors il faut considérer que cela va arriver. C'est une question de fiabilité.

Mais si difah (qui n'a pas répondu depuis...) n'a pas la main sur les log, il va falloir ajouter des règles de gestion plus barbares (c'est là que ced600 intervient ) en vérifiant les caractères voisins des séparateurs pour pouvoir dire si oui non le caractère courant est un séparateur.

Je maintiens que de telles règles n'existent pas. Si difah n'a pas la main sur les logs, alors on ne pourra aboutir qu'à une approximation, à un programme qui ne fonctionne que dans la plupart des cas.

[Louis-Guillaume Morand]

je préviens, je vais revenir faire le ménage dans ce thread car ca papote pour ne rien dire ici

Je maintiens que de telles règles n'existent pas. Si difah n'a pas la main sur les logs, alors on ne pourra aboutir qu'à une approximation, à un programme qui ne fonctionne que dans la plupart des cas.

BCmDev a tout à fait raison.
tu as une source de données, tu dois t'adapter et pas demander à recoder le programme à l'origine du log.

il veut un seul élément donc on peut p-e tenter une belle regex

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

new Regex("\\[.*\\+.*\\]")

tadammmmmmmmmmmmmmmmm.
explication. on export tous les blocs entre crochets qui contiennent au moins un slash.
on enleve donc tous les blocs qui nous interessent pas (heure, fichier, etc)
et on ne recupere pas non plus [1] car un nom de fichier ne peut pas contenir de backslash dans son nom

[ced600]

Je maintiens que de telles règles n'existent pas. Si difah n'a pas la main sur les logs, alors on ne pourra aboutir qu'à une approximation, à un programme qui ne fonctionne que dans la plupart des cas.

Un tel programme est simple et rapide à faire, donc avec un faible coup de développement.
Ecrire un programme plus fiable, c'est plus long et plus complexe, et donc cela a un plus gros coup de développement.

Au final il faut juger si la grande fiabilité du programme est necessaire. En effet, qu'elles sont les risques en cas de plantage à cause d'un fichier log bizzare ? Est ce necessaire de faire plus fiable pour éviter ces problèmes.

Personnellement je travaille en ce moment sur l'analyse de fichiers logs à l'aide d'un programme que je crée (regexp et utilisation des méthodes de string).
Le fichier log est crée par un logiciel libre. Je le connais et je suis sur que 95% des cas il me fournis un fichier log avec la même structure.
Donc je m'appuis la dessus pour analyser ce fichier comme si c'était 100% des cas.
En fait pour les 5% des autres cas, le fichier log est complétement erroné, et ce du as des problèmes qui sont intervenus lors de l'utilisation de se logiciel libre.
Ce logiciel libre est piloté par un autre de mes programmes, et lorsqu'il y a de tel problème, mon piloteur le détectera et je ne ferais pas d'analyse de log.

[c:\documents and settings\ut0gpx\bureau\bidule][.exe]

Supposer cela n'a pas réellement de sens car nous ne connaissons pas l'outil qui fournis ces fichiers logs, et nous ne savons pas si cela peut arriver ou pas.

Non parce que si l'on part dans ce genre d'hypothèse, on peut tout imaginer, et tout prévoir est impossible :
Imaginez que le fichier log de temps à autre soit générer avec que des lignes --------------------- dans celui-ci et au final fasse 16mo.
Je dit n'importe quoi ? Bah si je reprends mon exemple perso, les 5% de cas où le fichier log est erronée, bah il l'est de cette façon !!!!

Bref il vaut mieux s'appuyer sur la structure du fichier log telle qu'elle est décrite dans une spec de l'outil qui les généres, et ne pas imaginer d'autre cas possible que ce qui est écrit (sauf si constaté). Cela ne sert pas à grand chose, tu ne peux pas tout imaginer, et être 100 % fiable, lorsque l'outil qui génére les logs n'est pas 100% fiables sur la génération des logs.

[ced600]

il veut un seul élément donc on peut p-e tenter une belle regex

Code :
new Regex("\\[.*\\+.*\\]")

Et bien voilà la réponse correcte
Celle que l'on n'a pas été capable de fournir car on n'est pas assez compétent dans le domaine des regexp (du moins moi).
Du coup plus besoin de mes splits, et donc notre débat tombe à l'eau

[Louis-Guillaume Morand]

Du coup plus besoin de mes splits, et donc notre débat tombe à l'eau

pas besoin de débat, t'avais tord Enfin de mon avis, j'étais à 100% d'accord sur tout ce qu'a dit BCmDev.

quant à ma regex, je ne l'ai pas testé, j'ai fais ca en deux secondes donc elle ne marche p-e pas.