[R] Aide pour pattern RegExp

[jguinch]

Bonjour.
J'aurais besoin d'un peu d'aide avec une expression régulière.
J'aimerais n'avoir qu'un seul StringRegExp dans la condition.

Je souhaite vérifier qu'une chaîne :
- ne commence pas par ;
- soit composé de n'importe quoi, suivi du signe=
- suivi de quelque chose (non obligatoire)

Ex :
key=value [OK]
key= [OK]
;key= [OK], il y a un espace au début
;key=value [Pas OK] commence pas ;
key [Pas OK] ne contient pas =

Pour l'instant, j'y arrive avec :

Code : Tout sélectionner

$line = ";key=value"
If StringRegExp($line, "\A(?!.+?=.*)" ) OR StringRegExp($line, "\A;") Then MsgBox(16, "", "Erreur")

Mais j'aimerais bien tout faire dans le même pattern...

Merci d'avance

[jchd]

Selon ce que tu considères valide pour la clé, ça peut convenir ou demander ajustement :

► Afficher le texte

Local $aTest[6] = [ _
"key=value [OK]", _
"key= [OK]", _
" key= [OK], il y a un espace au début", _
";key=value [Pas OK] commence par ;", _
"key [Pas OK] ne contient pas =", _
"=abc [Pas OK] ne contient pas de clé" _
]

For $s In $aTest
ConsoleWrite('"' & $s & '"' & " convient ? " & (StringRegExp($s, "^(?!;)[\s\w]+=") = 1) & @LF)
Next

Le "negative look-ahead" (?!;) n'est pas vraiment utile, car ; n'est pas actuellement dans le jeu de caractères admis dans la clé. C'est juste pour illustration que je le laisse.

[mikell]

Selon ce que tu considères valide pour la clé

Le cahier des charges a été clairement énoncé

► Afficher le texte

Code : Tout sélectionner

Local $aTest[7] = [ _
"key=value [OK]", _
"#key= [OK]", _
"key=  ", _
" ;key= [OK], il y a un espace au début", _
";key=value [Pas OK] commence par ;", _
"key [Pas OK] ne contient pas égale", _
"=abc [Pas OK] ne contient pas de clé" _
]

For $s In $aTest
ConsoleWrite('"' & $s & '"' & " convient ? " & (StringRegExp($s, "^[^;].+=") = 1) & @LF)
Next

[jguinch]

Merci à vous.
C'était pourtant super simple, mais j'étais parti dans un délire, désolé.

@jc : je ne comprends pas trop ta remarque : ; n'est pas actuellement dans le jeu de caractères admis dans la clé.
Quand je lis la doc (actuelle), je vois dans la partie Lookahead assertions :
\w+(?=;)
matches a word followed by a semicolon
Je ne comprends pas le terme "semicolon". C'est de çà que tu parles ?

Merci encore, bonne soirée les regex-men !

[jchd]

Si je renifle bien le contexte, c'est un style .INI et je doute que tous les caractères soient admis au niveau de la clé. D'où ma remarque, impliquant que, justement, le véritable cahier des charges pourrait mériter d'être plus précis.
Par exemple @TAB & "=abc" est-il acceptable ?

(?!;) est un "look-ahead" négatif et signifie "le prochain caractère ne doit pas être un point-virgule (semicolon).
Au contraire, (?>;) est un "look-ahead" positif et signifie "le prochain caractère doit être un point-virgule.

En tout état de cause, j'ai anticipé (peut-être à tort) quela clé ne pouvait contenir que des \w ou des \s. Là aussi, ça manque de précision car l'exemple plus haut avec @TAB n'est peut-être pas valide.

Pour ça, je laisse les portes ouvertes à une adaptation au cas réels envisagés.

[mikell]

@jchd
Ton anticipation était certainement exacte mais ne correspondait pas à la demande telle qu'exprimée littéralement, et si je me suis permis d'intervenir c'était manière d'insister sur cette idée que la précision dans l'énoncé du cahier des charges est primordiale
Sorry

@jguinch
Je crois que le problème avec jchd c'est que sa cervelle a toujours un temps d'avance sur son clavier
" ; n'est pas actuellement dans le jeu de caractères admis dans la clé" je le comprends comme
" ; n'est pas actuellement dans le jeu de caractères admis dans le set qui représente ce qui doit précéder le = dans l'expression"

[jguinch]

[interflora]La différence entre vous deux, c'est que mikell répond en fonction de ce qui est demandé, jc répond en fonction de ce qui se cache derrière l'énoncé (il est devin très certainement, puisque c'est tout le temps comme ça). Mais vos réponses sont toujours réfléchies et instructives.[/interflora]

Revenons à nos moutons...
Merci jc pour ces explications. Tu as bien flairé le truc, c'était en rapport avec les fichier INI.
J'ai ouvert un postsur le forum US pour fait part d'un comportement étrange avec IniWriteSection(), du moins c'est mon impression.

Je suis parti dans l'idée de recréer l'équivalent de toutes les fonctions INI, mais en pouvant au passage crypter le contenu du fichier, et ne pas avoir à repasser par un fichier temporaire pour lire les données décryptées.
Pour chaque fonction, j'effectue différents tests pour essayer d'être le plus proche du résultat des différentes fonctions INI (hormis ce genre de comportement du aux API).
J'ai quasiment fini, il ne me reste que IniWriteSection() qui me pose des problèmes car en testant la fonction d'origine, j'ai des comportements bizarres... On dirait que le paramètre "data" n'est pas vraiment vérifié.

Qu'en penses-tu ?

[jchd]

Oui j'ai bien vu ça là-bas. Pour ma part je considère les .ini comme un truc préhistorique. C'est limité en taille et en possibilités de structuration, mal défini (comme ton problème de @LF le démontre), pas directement compatible Unicode ou binaire, difficile à protéger aussi bien contre les manipulations malveillantes que contre les accès concurents, etc.

On peut toujours y stocker deux ou trois bricoles comme les 10 derniers fichiers ouverts et la taille et position d'une GUI, mais utiliser ce réceptacle pour de véritables données applicatives est un non-sens AMHA.

Dès lors qu'on parle de données dépassant quelques paramètres, je préconise SQLite (contre vents et marées) qui a justement été créé initialement pour stocker des données applicatives. Une fois le b-a-ba de SQL acquis, on gagne beaucoup en souplesse, en robustesse et en capacité d'évolution (autant en volume et en complexité qu'en portabilité).

Pour en revenir à ton @LF, je suppose qu'il provient du chiffrement. Tout chiffrement sérieux produit ce qui apparaît comme du bruit blanc, sans aucune prédictibilité à une quelconque échelle. Tout valeur d'octet à une probabilité de 1/256 exactement. Du coup tu récupères dans ta valeur chiffrée des caractères de contrôle, des 0x00 (fin de ligne pour beaucoup de primitives chaîne), des @LF et autres bonbons qui collent aux dents des fonctions .ini, natives ou émulées.

Tu peux toujours stocker ces valeurs chiffrées sous forme de chaîne hexa, ça ne posera plus de souci, mais on débouche sur une usine à gaz. Si un jour tu dois balayer ton .ini pour déterminer si une section emploie déja le chemin "D:\users\xxx\yyy\zzz" alors que ce chemin doit être unique dans ton cas, tu vois ce que tu vas devoir dérouler comme code pour parvenir à la conclusion souhaitée. Ce n'est bien sûr qu'un exemple bête lancé au hasard, mais tu comprends bien que ce format de stockage n'est pas le plus adapté.

[jguinch]

Merci jc pour toutes ces infos.
Je partage ton avis sur les limites des fichiers INI, pour y avoir été confronté. D'ailleurs, j'utilise de plus en plus SQL(ite) (même si ça prend plus de temps), ça permet de mieux penser chaque projet et offre beaucoup plus de souplesse (ça n'a rien à voir).

Le but, à l'origine de ce post, était de proposer un petit UDF avec des fonctions identiques aux fonctions Ini_x, mais qui permettrait de crypter/décrypter les données au passage (c'est un besoin qui revient de temps en temps sur le forum).
Maintenant, après avoir lu tes remarques intéressantes concernant le cryptage, je pense gérer ça autrement (certainement en hexa), enfin, je verrai bien ce que ça donne...

Je posterai un de ces jours ces fonctions, en espérant que ça serve à quelqu'un (en tout cas pas à jc c'est sûr )