Path: ...!news.mixmin.net!weretis.net!feeder8.news.weretis.net!news.trigofacile.com!usenet-fr.net!.POSTED!not-for-mail
From: Olivier Miakinen <om+news@miakinen.net>
Newsgroups: fr.comp.lang.regexp
Subject: Du nouveau dans les expressions rationnelles : I-Regexp
Date: Sat, 14 Oct 2023 11:37:28 +0200
Organization: There's no cabale
Lines: 49
Message-ID: <ugdngp$hnj$1@cabale.usenet-fr.net>
NNTP-Posting-Host: 200.89.28.93.rev.sfr.net
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-Trace: cabale.usenet-fr.net 1697276249 18163 93.28.89.200 (14 Oct 2023 09:37:29 GMT)
X-Complaints-To: abuse@usenet-fr.net
NNTP-Posting-Date: Sat, 14 Oct 2023 09:37:29 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Firefox/52.0 SeaMonkey/2.49.4
X-Mozilla-News-Host: news://news.galacsys.net:119
Bytes: 3048

Bonjour,

Le RFC 9485 vient tout juste d'être publié, qui a vocation à devenir
un standard internet (pour le moment à l'étape PROPOSED STANDARD).

Lien : <https://www.rfc-editor.org/info/rfc9485>

Celui-ci définit I-Regexp, un format d'expressions rationnelles avec
quelques limitations dans le but d'être le plus possible interopérable
dans différentes bibliothèques de regexp.

Parmi les limitations :

- Il n'y a pas de possibilité de capturer une sous-chaîne, que ce soit
 pour la retrouver ailleurs dans la chaîne ou pour la retourner à
 l'appelant. Par exemple on peut tester par "(http|https)://(.*)" si
 une chaîne ressemble à une URL, mais on ne pourra pas savoir si c'était
 http ou https, ni extraire le nom de domaine et le chemin.

- Il n'y a pas de séquence \lettre comptant pour une classe de caractères.
 Par exemple, au lieu de \d il faut écrire [0-9] et au lieu de \S ce
 sera [^ \n\t\r]. Cela présente un réel intérêt pour l'interopérabilité,
 parce que par exemple dans certains langages de regexp le \d regroupe
 n'importe quel caractère Unicode qui soit un chiffre dans n'importe
 quel système d'écriture.

- Il n'y a pas d'assertions, ni positives ni négatives, ni en avant ni
 en arrière. C'est évidemment normal puisque ceci n'existe que dans des
 systèmes de regexp avancés tels que Perl et PCRE, mais il s'agissait
 de mon mécanisme préféré, celui sur lequel j'ai le plus écrit dans ce
 groupe.

En contrepartie, pour prétendre être compatible I-Regexp, il faut :

- prendre en charge tout Unicode, aussi bien dans les expressions
 elles-mêmes que dans le texte traité ;

- prendre en charge les propriétés Unicode, par exemple \p{N} pour
 un chiffre dans n'importe quel système d'écriture, \p{Lu} pour
 une lettre majuscule ou \P{Ll} pour tout ce qui n'est pas une
 lettre minuscule.

En outre, il est vivement recommandé aux implémenteurs d'I-Regexp de
passer une série de tests pour vérifier que leur implémentation est
strictement conforme, et de documenter si ces tests de conformité ont
été (ou n'ont pas été) effectués.

-- 
Olivier Miakinen