[regex][CSV]Exclure les séparateurs entre guillemets

Version imprimable

05/08/2007, 17h55
Eric Berger

[regex][CSV]Exclure les séparateurs entre guillemets
Je suis une bille en expressions régulières..... j'ai donc tout naturellement un problème avec ces dernières...

Je parse des fichiers CSV pour splitter sur les séparateurs, or il se trouve que j'ai des séparateurs qui se trouvent entre guillemets et que ceux-ci doivent être ignorés.... et là.... je bloque....

Exemple

Code:

aaa,bbb,"cc,c",ddd

devrait donner:
Code:

1 2 3 4 aaa bbb ccc ddd
et non:
Code:

1 2 3 4 5 aaa bbb cc c ddd
Je cherche donc une expression régulière qui me permet d'ignorer les virgules si elles sont entre guillemets.

Merci d'avance pour vos réponses.

Eric
06/08/2007, 19h49
harakatyouness

J'ai le meme probleme que toi , j'espere que tu as trouve la solution , sinon tu peux me proposer des solution que tu as essaye...

Je propose cela :

Code:

1
2
3
4
5
6
7
8
9
10
11
 
            string s = "aaa,bbb,\"cc,c\",ddd"; 
 
            Regex r = new Regex("(((([^,\"]+),?)*)(\")(.*?)(\",)((([^,\"]+),?)*))+");
            GroupCollection gs = r.Match(s).Groups;
 
            var captures = (new List<Group> { gs[4], gs[6], gs[9] })
                           .SelectMany(g => from c in g.Captures.OfType<Capture>() select c);
 
            foreach (var c in captures)
                Console.WriteLine(c.Value);

Je n'ai pas réussi avec le Split, alors j'ai essayé de procéder autrement
Code:

1 2 3 4 5 6 7 string input = "aaa,\"\",\"\",bbb,,\"cc,c\",\"jjj,j\",ddd"; string pattern = "(\"[^\"]*\"|[^,]*),?"; MatchCollection coll = Regex.Matches(input, pattern); for (int i = 0; i < coll.Count - 1; i++) { string s = coll[i].Groups[1].Value; }
Le dernier item de la collection ne correspond à rien, donc j'ai utilisé un for plutôt qu'un foreach.

Si ca peut aider :)

C'est vrai que c'est plus beau comme ça :

Code:

1
2
3
4
5
 
string s = "aaa,bbb,\"cc,c\",ddd";
Regex r = new Regex("((\"[^\"]*\"|[^,]*),?)*");
foreach (Capture c in r.Match(s).Groups[2].Captures)
    Console.WriteLine(c.Value);

07/08/2007, 08h08
SaumonAgile

J'aurais tendance à trouver celle-là plus jolie :

Code:

"((?<token>\".*?\"|[^,]*),?)*"

J'ai préféré utiliser un quantifieur feignant, pour améliorer le traitement des longues chaines.

Je comprend l'intéret des expressions régulière mais c'est super chiant à débuguer pourquoi ne pas faire :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
public string[] Decoupage (string s)
{
	string[] temp = s.Split(',');
	string temp2 = "";
	string temp3 = "";
	for (int i = 0; i < temp.Length; i++)
	{
		if (temp[i].StartsWith("\""))
		{
			temp2 = temp[i].Substring(1,temp[i].Length);
			i++;
			while (!temp[i].EndsWith("\""))
			{
				temp2 = temp2 + temp[i];
				i++;
			}
			temp3 = temp3 + "," + temp2;
			temp2 = "";
		}
		else
		{
			temp3 = temp3 + "," + temp[i];
		}
	}
	return temp3.Split(',');
}

Je trouve cela plus clair :D

07/08/2007, 12h02
SaumonAgile
Citation:
Envoyé par ced600

Je comprend l'intéret des expressions régulière mais c'est super chiant à débuguer pourquoi ne pas faire :

Code:

1 2 3 4 5 public string[] Decoupage (string s) { }

Je trouve cela plus clair :D
ARGGHHH 8O
07/08/2007, 13h10
StormimOn

Citation:

Envoyé par SaumonAgile

ARGGHHH 8O

Le cri du coeur :lol:
C'est vrai que ca pique les yeux quand même :mouarf:

ced600, tu trouves peut être plus clair sans expression régulière parce que tu n'y est pas habitué, parce que finalement c'est beaucoup plus clair avec que sans :)
07/08/2007, 13h14
maa

Citation:

Je trouve cela plus clair

Il est fou ?? 8O :lol:

Citation:

J'aurais tendance à trouver celle-là plus jolie :
Code :

"((?<token>\".*?\"|[^,]*),?)*"

J'ai préféré utiliser un quantifieur feignant, pour améliorer le traitement des longues chaines.

Je ne comprends pas trop ce bout de code : ?<token>
Pourrais-tu me l'expliquer ?
07/08/2007, 13h57
SaumonAgile

?<token> donne un nom au groupe contenu entre les parenthèse. Dans ce cas-là, le nom du groupe sera token.
07/08/2007, 14h34
maa

ok.

J'ai tenté d'utiliser un quantifieur paresseux pour la seconde alternative, comme ceci :

Code:

"((\".*?\"|.*?),?)*"

Mais ça ne fonctionne pas car la virgule n'est pas dans le même groupe.

Je pensais qu'écrire cela :

Code:

"((\".*?\"|.*?,{0}),?)*"

pourrais marcher. C'est à dire utiliser la virgule pour permettre l'utilisation du quantifieur paresseux, mais sans la capturer. Mais bon ça ne fonctionne pas...
07/08/2007, 14h38
ced600

Je me doutais que cela ferait réagir. :D
Le problème des expressions régulières, c'est que pour les comprendre vous devez avoir l'habitude de les utiliser, alors que du code c'est quasiment de l'algo.

Je dit juste qu'à mon avis c'est plus simple à comprendre qu'une expression régulière pour quelqu'un qui est :

Citation:

une bille en expressions régulières

comme notre ami Eric Berger (je pourrais peut être me rajouter dans le lot des billes en expression régulière :) )

Donc voila j'ai souhaité proposer une alternative, maintenant à lui de voir ce qu'il préfère.
07/08/2007, 14h45
maa

Ok, mais tu admettra que quand on a l'habitude des expressions régulières (est l'habitude vient vite) il suffit d'un clins d'oeil pour comprendre ce qui est fait alors qu'avec ton code il faut prendre le temps de lire ces 15 lignes. Pour peu que tu en ait plusieurs comme cela, ton code devient rapidement fastidieux à lire.
En plus, je pense qu'au niveau performance, c'est moins bon avec ta méthode.
07/08/2007, 17h13
ced600

Heu je pourrais te dire la même chose avec le code : Quand tu as l'habitude du code tu le lis en un clin d'oeil :) (si si)
Par contre je suis d'accord avec toi au niveau des performances, les expression régulières torchent mon code.

Mais ne dit on pas :

Citation:

Rien ne sert de courir, il faut partir à point

Moi je dis mieux vaut un code moins performant, mais maitrisé et fonctionnelle, qu'un code performant, non maitrisé et donc dont on est pas sur s'il est fonctionnelle tout le temps.

:mrgreen:

Je vois que j'arrive après l'orage....

Désolé, j'ai pas pu me connecter avant...

Du coup je me suis débrouillé avec un traitement en 2 temps, tout dabord un split sur la virgule, puis un merge des champs contenant des guillements (vu qu'elles se retrouvaient coupées par la virgule) c'est pass super-propre, mais ça fonctionne bien.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
        private List<String> _ParseLine(String line)
        {
 
            Regex regex = new Regex(_separator.ToString());
 
            String[] fieldsArray = regex.Split(line);
 
            List<String> fieldsList = new List<string>();
 
            bool merging = false;
            String mergingString = "";
            foreach (String field in fieldsArray)
            {
                //Post Process for quoted values
                if (field.Contains("\"") || merging)
                {
                    if (!merging)
                    {
                        merging = true;
                        mergingString = field;
                    }
                    else if (field.Contains("\""))
                    {
                        fieldsList.Add(mergingString + _separator + field);
                        merging = false;
                    }
                    else //No quote in field but in merging process
                    {
                        mergingString += _separator + field;
                    }
                }
                else
                {
                    fieldsList.Add(field);
                }
            }
            return fieldsList;
        }

En tout cas merci à tous!

08/08/2007, 11h19
cinemania

Que celui qui a osé dire que les Regex c'était pas de l'algo se flagelle en public ...

Si tu avais "subis" des cours de théorie intensive et très poussée tu te rendrais vite compte que les expressions à elles seules sont un language correspondant à de l'algorithmique.

Elles sont basées sur la théorie des langages qui est la base même de l'informatique actuel et des "langages impératifs" tels que tu les connais... (et cela dit meme des "langages fonctionnels")

Et effectivement je préfere de très loin une écriture avec les Regexp. De plus soit dis en passant... Ton algo tu l'écrit en C# qui utilise donc des dll .NET qui sont exécutées par la CLR. Il n'est donc pas écrit en natif.
Le mécanisme des regexp implanté dans System.Text.RegularExpressions est une des meilleurs qui m'ai été donné de voir en terme de performances, surtout pour peu que tu ajoute l'option RegexOptions.Compiled.
Au final, les regexp sont sensiblement plus rapides que ton code.
Le contraire eu été vrai en Perl, mais pas en C#.

Bravo SaumonAgile pour ta regexp ?<token> j'adore :)
08/08/2007, 11h40
ced600

Heu... Je n'ai jamais dit que mon code était plus rapide que les regexp. Je sais qu'elles sont plus rapide. Je disais juste qu'il vaut mieux utiliser une solution que l'on maitrise plutot qu'une que l'on ne maitrise pas. Car dans le premier cas, on pourra la modifier, et dans le deuxième on aura beaucoup de mal à la modifier.
En général je cherche à faire un code propre et qui marche puis ensuite, si j'en ai le temps et le besoin, j'optimise mon code.
Utiliser les méthodes de l'objet string et des boucles pour découper une string, c'est propre et je maitrise mieux.
Dans un deuxième temps utiliser les expressions régulières pour optimiser le code ces bien.
Donc j'ai proposé cette alternative au cas où (et j'ai été un peu provocateur par jeu sur les expressions régulières :D ).
Et puis une dernière chose, lorsque vous développez une application pour une entreprise, vous ne serez pas forcement celui qui s'occupera de la maintenance de l'application. Donc il faut penser un peu à celui qui va reprendre le code, si vous utilisez du code super compressé et jolie mais difficilement compréhensible votre application sera inmaintenable :aie:
Cela me fait penser au C et à ses fonctions de 50 lignes compréssable en 1 ligne incompréhensible :aie:
08/08/2007, 11h52
SaumonAgile

Citation:

Envoyé par ced600

Utiliser les méthodes de l'objet string et des boucles pour découper une string, c'est propre et je maitrise mieux..

Je pense que tu voulais évidemment écrire :

Citation:

ce n'est pas propre mais je maitrise mieux

;)

Citation:

Envoyé par ced600

Donc il faut penser un peu à celui qui va reprendre le code

Le nivellement par le haut est toujours la pire solution envisageable. Ce n'est pas parce que certaines personnes ne sauront jamais conduire une voiture correctement qu'il faut en abandonner l'usage pour tous les autres.

Code:

1
2
3
4
5
6
7
8
9
10
11
12

	Code:
	
123 Citation:
ced600 a écrit :
Utiliser les méthodes de l'objet string et des boucles pour découper une string, c'est propre et je maitrise mieux..
Je pense que tu voulais évidemment écrire :


	Code:
	
12 Citation:
ce n'est pas propre mais je maitrise mieux

En quoi ce ne serais pas propre ? C'est juste plus lent.

08/08/2007, 14h10
maa

Citation:

Donc il faut penser un peu à celui qui va reprendre le code, si vous utilisez du code super compressé et jolie mais difficilement compréhensible votre application sera inmaintenable

Faut pas exagérer, y a rien de bien compliqué dans les expressions régulières. En se documentant un peu on comprends vite comment ça marche. Et puis il ya d'autre avantages dans les expressions régulières. Une Regex est un objet. Tu peux le passer en paramètre par exemple.

Par contre je n'ai pas eu de réponse à ma question :

Citation:

J'ai tenté d'utiliser un quantifieur paresseux pour la seconde alternative, comme ceci :

"((\".*?\"|.*?),?)*"

Mais ça ne fonctionne pas car la virgule n'est pas dans le même groupe.

Je pensais qu'écrire cela :

"((\".*?\"|.*?,{0}),?)*"

pourrais marcher. C'est à dire utiliser la virgule pour permettre l'utilisation du quantifieur paresseux, mais sans la capturer. Mais bon ça ne fonctionne pas...
08/08/2007, 14h10
cinemania

tout a fait d'accord le nivellement par le haut est la pire des solutions.

Une application reste maintenable... suffit à ton successeur d'apprendre. S'il ne sait pas, il faut qu'il se remette en question.

En plus j'adore le C et les expressions à ralonge d'une ligne qui en remplace 50. J'en utilise partout, dans ce projet pourtant écrit en C#.
Ensuite c'est une question d'expérience.
Un développeur chevronné ne doit pas être gêné par l'écriture
a = (b && c) ? d : e;
au lieu de
if (b && c) a=d; else a=e;
C'est exactement le meme principe pour les expressions régulières.

Malheureusement et je te le consède, le langage des regexp est assez complexe en soit, et pas forcément facile à maitriser de prime abord. néanmoins, il est indispensable dès que tu fait du traitement sur des chaines de caractères.
08/08/2007, 15h02
ced600

Citation:

tout a fait d'accord le nivellement par le haut est la pire des solutions.

Une application reste maintenable... suffit à ton successeur d'apprendre. S'il ne sait pas, il faut qu'il se remette en question.

En plus j'adore le C et les expressions à ralonge d'une ligne qui en remplace 50. J'en utilise partout, dans ce projet pourtant écrit en C#.
Ensuite c'est une question d'expérience.
Un développeur chevronné ne doit pas être gêné par l'écriture
a = (b && c) ? d : e;
au lieu de
if (b && c) a=d; else a=e;
C'est exactement le meme principe pour les expressions régulières.

Malheureusement et je te le consède, le langage des regexp est assez complexe en soit, et pas forcément facile à maitriser de prime abord. néanmoins, il est indispensable dès que tu fait du traitement sur des chaines de caractères.

Je plein ceux qui passent derrière toi et reprenne ton code. Ils doivent se tirer les cheveux.

Citation:

a = (b && c) ? d : e;

Source d'erreur, difficilement compréhensible, code illisible.
Tu n'as plus qu'à me dire que tu ne commentes pas ton code et je me tire une balle en pleine tête.
08/08/2007, 18h24
Eric Berger

On dirait que j'ai donné naissance à un troll :mouarf:

Pour mettre tout le monde d'accord ( en bon Suisse que je suis), je dirais.... ça dépend. Ca dépend du projet et de ses objectifs, si un projet doit être très maintenable, que son code doit être régulièrement retravaillé, de longues et complexes expressions régulières ralentiront inévitablement ce travail (même si un développeur les maitrisant s'en chargeait). Par contre, pour des portions de code très sollicitées, l'efficacité de celui-ci primera à tous les coups et les expressions régulières s'imposeront naturellement.

Il n'y a pas une bonne façon de coder et une mauvaise si le contexte n'est pas posé.

Walà... je vous laisse troller maintenant que j'ai soufflé sur les braises :aie:
09/08/2007, 11h57
ced600
Je suis tout à fait d'accord avec toi, c'est pour cela que j'ai posté un autre type de solution.
Mais j'insiste sur un point :

Code:

a = (b && c) ? d : e;

Ce n'est pas plus efficace que :
Code:

1 2 3 4 5 6 7 8 9 If (b && c) { a = d; } else { a = e; }
Et donc cela aucun intérêt sauf t'embrouiller l'esprit.

Ne soit pas si catégorique, il y a des utilisations parfaitement justifiées de l'opérateur ternaire. Dans plusieurs cas, la lisibilité est grandement améliorée :
Code:

1 2 3 4 5 6 7 8 9 10 11 while (reader.Read()) { string fileName = reader.IsDBNull(0) ? String.Empty : reader.GetString(0); int status = reader.IsDBNull(10) ? 0 : reader.GetInt32(10); DateTime creationTime = reader.GetDateTime(11); int fileSize = reader.IsDBNull(12) ? 0 : reader.GetInt32(12); // Do stuff } reader.Close();

Desole mais je trouve cela plus lisible :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
string fileName = "";
int status = 0;
int fileSize = 0;
while (reader.Read())
{
	if (reader.IsDBNull(0))
	{ 
		fileName = String.Empty;
	}
	else 
	{
		fileName = reader.GetString(0);
	}
 
	if (reader.IsDBNull(10))
	{
		status = 0;
	}
	else
	{
		status = reader.GetInt32(10);
	}
 
	DateTime creationTime = reader.GetDateTime(11);
 
	if (reader.IsDBNull(12))
	{
		fileSize = 0;
	}
	else
	{
		fileSize = reader.GetInt32(12);
	}
 
	// Do stuff
}
reader.Close();

Pour ce qui est de la comparaison entre utilisation d'une expression régulière et d'un algo, pour moi la chose est claire :

D'un côté on a ça :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 public string[] Decoupage (string s) { string[] temp = s.Split(','); string temp2 = ""; string temp3 = ""; for (int i = 0; i < temp.Length; i++) { if (temp[i].StartsWith("\"")) { temp2 = temp[i].Substring(1,temp[i].Length); i++; while (!temp[i].EndsWith("\"")) { temp2 = temp2 + temp[i]; i++; } temp3 = temp3 + "," + temp2; temp2 = ""; } else { temp3 = temp3 + "," + temp[i]; } } return temp3.Split(','); }
de l'autre, on a ça :

Citation:

Regex r = new Regex("((\".*?\"|[^,]*),?)*");

L'un est est bout de code que l'on peut au mieux mettre dans une procédure, l'autre est un objet dont on peut modifier des propriétés, utiliser différentes méthodes, hériter,...

L'un se lit en 25 lignes de code, l'autre en un clin d'oeil pour vu qu'on est l'habitude des expression régulières (et cette habitude et vite prise).

L'un crée une bonne série de collections et de variables "jetables" pour ne finalement renvoyer qu'un résultat, l'autre et bien plus performant.

En bref, l'un correspond à une technique que l'on pouvait utiliser il y a 20 ans et l'autre la façon moderne de traiter, vérifier des chaîne de caractères formatées. Maintenant libre à chacun de choisir ce qu'il préfère...

Pour moi les questions à se poser seraient plutôt :
Qu'est ce que l'on ne peut pas faire avec les expressions régulières que l'on peut faire avec l'algo ?
Comment améliorer les expressions régulières pour combler ces lacunes ?

09/08/2007, 13h00
SaumonAgile

Citation:

Envoyé par ced600

Desole mais je trouve cela plus lisible :

La question n'est pas de savoir si TOI tu trouves que c'est plus lisible, je dis simplement qu'en utilisant l'opérateur ternaire dans le cas que j'ai cité tu évites de masquer le code fonctionnel sous une tonne de code purement utilitaire.

Ce n'est pas un troll, c'est un exemple d'utilisation de l'opérateur. Après, que tu trouves ça illisible, libre à toi mais ce n'est pas le débat.
Mais bon peu importe, vu l'orientation que prend la discussion, je ne vois pas d'intérêt à continuer à poster.

maa : +1
09/08/2007, 15h39
ced600

Bon puisque je vois que cela enerve certaine personne et que ce n'est pas le but de mes post, je vais arrêter de poster des messages concernant les RegExp.

De toute façon chacun reste sur ses positions et ce débat n'amène à rien. Donc que chacun pense ce qu'il veut et comme cela tout le monde est content.

Fuseau horaire GMT +2. Il est actuellement 01h11.