Le Hollandais Volant

lol^^

Oh !

Une regex dans le même genre que [0-9] et [a-z], mais pour tous les caractères imprimables de l’ascii : [ -~] (de l’espace au tilde dans la table ascii).

Pour ma, ma régex préférée, ça serait plutôt une astuce de ce style là : https://lehollandaisvolant.net/?mode=links&id=20131106104405

Donc pour faire en sorte que les caractéristiques accentués soient pris en compte dans \w, il faut ajouter le flag "u" (en minuscule).

Retourne false :

preg_match('#\w#', 'é') 

Retourne true :

preg_match('#\w#u', 'é') 

C’est simple les regex (à condition de ne pas se frotter aux références arrière & co, et ne de pas essayer de comprendre une regex existante) :)

Mais faut avoir la doc sous la main, oui (comme c’est toujours le cas en pratique).

Voir aussi celle-là, bien marrante : http://www.commitstrip.com/wp-content/uploads/2014/02/Strips-Le-dernier-des-vrais-codeurs-650-finalenglsih.jpg

Attention : les regex pour les url et les emails de cet article sont TRÈS incomplètes ! Celles-ci sont à ne surtout pas utiliser.

Les emails peuvent contenir des "+=/"* et bien d’autres caractères — y compris des espaces et de multiples « @ » — tout en étant valides !

Pour l’email, la regex qui s’approche le mieux de ce qui serait la vraie regex se trouve ici et elle mesure 6 424 caractères (elle n’est pas 100% complète, cf. les avertissements qui sont énoncés dans la page).

J’ai un outil qui teste le format d’une adresse email, et il se trouve ici.
Voir aussi cet article : http://www.bortzmeyer.org/arreter-d-interdire-des-adresses-legales.html

Des remarques similaires peuvent être faites pour les URL : une URL peut contenir des %, &, des : et d’autres caractères.

Et tout ceci ne tient pas compte des nouvelles adresses en unicode, qui va remettre tout ça en cause

(via)

Problèmes de codeur...
Ça n'arrive pas tous les jours, mais quand ça arrive, il faut mettre sa ceinture. Surtout pour les regex : http://lehollandaisvolant.net/?d=2014/12/01/18/42/45-petite-introduction-aux-regex

Alors quand on est en PHP, qu'on doit écrire du JS et que le JS doit créer une regex en html (pour les input validant le texte avec une regex), c'est le bordel.

Lol aussi sur ça : http://www.commitstrip.com/wp-content/uploads/2014/02/Strips-Le-dernier-des-vrais-codeurs-650-finalenglsih.jpg

MÀJ.

Bon, finalement la lib DOM dans PHP n’est pas parfaite.
Exemple avec mon dernier lien : http://shelgon.tumblr.com/post/137159949929/it-has-been-announced-that-the-mythical-pok%C3%A9mon

L’encodage de la page est "utf-8".
L’encodage dans headers est "utf-8"
Il n’y a pas de caractères unicode échappés dans la balise title de la page (certains caractères sont bien échappés ailleurs dans la page, mais ça ne devrait pas gêner).

Pourtant ce con me retourne un titre comme ça : « The Problematic Pokémon ».

C’est la seule page qui me retourne ça. Une autre page Tumblr avec d’autres caractères unicode dans le titre fonctionne très bien. Tout comme les articles de mon site. Tout comme un lien en local.

J’ai aussi essayé de mettre mon script en UTF-8, avec iconv_set_encoding("internal_encoding", "UTF-8") et consorts, mais rien n’y fait.

WTF.


Bon bah on retourne à la bonne vieille regex manuelle, hein. Je ne veux pas d’une lib qui merde comme elle veut.
Je viens d’ailleurs d’améliorer ladite regex, passant de ça :

preg_match('#<title>(.*)</title>#Usi', $ext_file, $titles);

à ça :

preg_match('#<title ?[^>]*>(.*)</title>#Usi', $ext_file, $titles);

Certains sites (en particulier Google Play) utilisent des attributs sur la balise title, et il faut les prendre en compte.

(BTW, cette regex fonctionne sur mon lien avec « The Problematic Pokémon », et me donne bien le « é »)


Vivement le jour où tout le monde, tous les logiciels, partout, tout le temps, utiliseront la même chose.

Oh, un outil encore plus pratique pour les Regex : on donne un texte, on donne une Regex, et il affiche en temps réel le contenu des variables $1, $2, $3… et en surlignant les occurrences correspondantes :o

Merci à LePoPeye pour le lien !

Wow.

Dans « $var = "abc $x def"; » le $x est remplacé : c’est une variable.
Dans « $var = 'abc $x def'; le $x n’est pas remplacé.

(C’est une question de single/double quotes).
Maintenant, je crois que PHP pose problème quand on considère le signe « $ » isolé.

Si je l’échappe avec un antislash dans une regex, il ne signifiera plus « fin du texte » pour le module de la regex, en revanche, il continuera de signifier « variable »PHP pour PHP, si la regex est entre double-quotes !

Exemple sur le lien, et ici :
et ça :
preg_match('/^\$bla/', '$bla'); // match
preg_match("/^\$bla/", '$bla'); // ne matche pas

Casse-gueule, non ?

Une liste d’outils pour modéliser des regex, les tester, etc.

"#<\s*/?(?:[a-zA-Z-]+)(?: (?:\s*\w+=(['\"])(?:(?!\g{1}).|(?:(?<=\\\)\g{1}))+\g{1})*(?:\s*\w*\s*))?/?>#S"

(en php, en gros : utiliser dans un preg_replace() et les remplacer par une chaine vide agira comme striptags().)

(oui, les attributs peuvent contenir un « > » ou un « < », par exemple en JS : « 2<=4 », et c’est chiant).

Un peu de doc complémtentaire :
http://www.regular-expressions.info/refadv.html
http://stackoverflow.com/questions/6050427/regex-problem-with-backreference-in-pattern-with-preg-match-all/6051114#6051114 (commentaire intéressant)
http://blog.lilhoot.eu/regex-et-preg-assertions-avant-arriere-lookahead-lookbehind-assertions-recuperer-les-chaines,a3 (en français, très intéressant et très clair)

Une journée à plancher sur OranjeProxy : je veux proxifier toutes les ressources externes (normal), donc aussi les liens.

Sauf les liens contenant mailto:, javascript: ou des trucs base 64 (data:).
Ça c’est juste pour les href et les src. Maintenant y’a tous les "onload", "onmouseover" aussi…

Sans compter les gens qui utiliser href='site' avec le guillement simple au lieu de double.

Attendez !

Dans un href="…" il peut y avoir du javascript ? Oui, et donc aussi des « ' » et même des « " » précédé d’un antislash.
Il faut donc une seule régex qui match :
<a href="prout">
<a href='prout'>
<a href="javascript:00+'étrange'bla">
<a href="javascript:00+\"étrange\"bla">
<a href="javascript:00+'étrange'bla" onclic="javascript:idem ici">
Et les mêmes avec une inversion entre ' et ". Le gros bordel.

Moi je fais ça en PHP avec des regex. J’imagine à peine le bordel que c’est que de coder un navigateur : qui doit parser du HTML, du CSS et du JS tout mélangé…

Oh, et j’ai mis 3 h à comprendre qu’en PHP, les références arrières c’est ça : \g{1} au lieu de \1. (le second n’a aucun effet chez moi : il ne matche pas même "b(o)nj\1ur", alors que le \1 devrait contenir le "o" de la première parenthèse.

Bonne nuit !

/me reprend un vieux script, basée sur des Regex.

Et même avec : http://www.regexper.com/

Certaines Regex ne me disent rien.