Extension:AbuseFilter/Rules format/fr

Les règles sont formatées comme des conditions dans un langage similaire à C/Java/Perl.

Chaînes
Vous pouvez spécifier un littéral en le plaçant entre guillemets simples ou doubles (pour les chaînes), ou en le tapant tel quel (pour les nombres, à la fois en virgule flottante et les entiers). Vous pouvez obtenir des sauts de ligne avec, des caractères de tabulation avec  , et vous pouvez également échapper le caractère apostrophe avec une barre oblique inverse.

Utilisez le symbole  (plus) pour concaténer deux chaînes littérales ou les valeurs de deux variables avec une valeur de chaîne.


 * Exemples:

Variables définies par l'utilisateur
Vous pouvez définir des variables personnelles pour faciliter la compréhension en utilisant le symbole d'assignation  sur une ligne (fermée par  ) à l'intérieur d'une condition. De telles variables peuvent utiliser des lettres, des traits de soulignement et des chiffres (à part le premier caractère) et sont sensibles à la casse. Exemple (de w:Special:AbuseFilter/79) :

Tableaux
AbuseFilter prend en charge les tableaux non associatifs pouvant être utilisés comme dans les exemples suivants.

Commentaires
Vous pouvez écrire des commentaires en utilisant la syntaxe suivante : /* Ceci est un commentaire */

Arithmétique
Vous pouvez utiliser les symbloles de base de l'arithmétique sur les variables et les littérraux avec la syntaxe suivante :


 * — Soustraire l'opérande de droite de l'opérande de gauche.
 * — Ajouter l'opérande de droite à l'opérande de gauche.
 * — Multiplier l'opérande de gauche par l'opérande de droite.
 * — Diviser l'opérande de gauche par de l'opérande de droite.
 * — Elever l'opérande de gauche à la puissante exponentielle spécifiée par l'opérande de droite.
 * — Retourner le reste quand l'opérande de gauche est divisé par l'opérande de droite.

Le type du résultat retourné est le même que celui qui aurait été retourné par PHP, pour lequel vous pouvez trouver beaucoup de documentation en ligne. Vous pouvez voir d'autres exemples plus exhaustifs sur ce test de l'analyseur syntaxique AF.

Opérations booléennes
You can match if and only if all of a number of conditions are true, one of a number of conditions are true, or one and only one of all conditions are true.


 * &mdash; OR – retourne  si une ou plusieurs conditions sont vraies.
 * &mdash; AND – retourne  si à la fois les deux conditions sont vraies.
 * &mdash; XOR – retourne  si une et une seule des deux conditions est vraie.
 * &mdash; NOT – retourne  si la condition n'est pas vraie.

Exemples

Comparaisons simples
Vous pouvez comparer des variables avec d'autres variables ou des littéraux en utilisant la syntaxe suivante :


 * &mdash; Return true if the left-hand operand is less than/greater than the right-hand operand respectively. Watch out: operands are casted to strings and, like it happens in PHP,  and.
 * &mdash; Return true if the left-hand operand is less than or equal to/greater than or equal to the right-hand operand respectively. Watch out: operands are casted to strings and, like it happens in PHP,  and.
 * (or ),   &mdash; Return true if the left-hand operand is equal to/not equal to the right-hand operand respectively.
 * &mdash; Return true if the left-hand operand is equal to/not equal to the right-hand operand AND the left-hand operand is the same/not the same data type to the right-hand operand respectively.

Variables embarquées
The abuse filter passes various variables by name into the parser. These variables can be accessed by typing their name in, in a place where a literal would work. You can view the variables associated with each request in the abuse log.

Performances
As noted in the table above, some of these variables can be very slow. While writing filters, remember that the condition limit is not a good metric of how heavy filters are. For instance, variables like  or   always need a DB query to be computed, while   variables will have to perform parsing of the text, which again is a heavy operation; all these variables should be used very, very carefully. For instance, on Italian Wikipedia it's been observed that, with 135 active filters and an average of 450 used conditions, filters execution time was around 500ms, with peaks reaching 15 seconds. Removing the  variable from a single filter, and halving the cases when another filter would use   brought the average execution time to 50ms. Plus particulièrement :

Last but not least, note that whenever a variable is computed for a given filter, it'll be saved and any other filter will immediately retrieve it. This means that one single filter computing this variable counts more or less as dozens of filters using it.
 * Use  variables when you need high accuracy and checking for "http://..." in other variables (for instance,  ) could lead to heavy malfunctioning;
 * Use  variables when you're really sure that non-PST variables aren't enough. You may also conditionally decide which one to check: if, for instance, you want to examine a signature, check first if   contains  ;
 * In general, when dealing with these variables, it's always much better to consume further conditions but avoid computing heavy stuff. In order to achieve this, always put heavy variables as last conditions.

Mots-clé
The following special keywords are included for often-used functionality:


 * (or ) returns true if the left-hand operand matches the glob pattern in the right-hand operand.
 * returns true if the right-hand operand (a string) contains the left-hand operand. Note : empty strings are not contained in, nor contain, any other string (not even the empty string itself).
 * works like, but with the left and right-hand operands switched. Note : empty strings are not contained in, nor contain, any other string (not even the empty string itself).
 * (or ) and   return true if the left-hand operand matches (contains) the regex pattern in the right-hand operand (  is case insensitive).

The system uses PCRE. The only PCRE option enabled is  (modifier   in PHP); for   both   and   are enabled (modifier  ).



Exemples

Fonctions
A number of built-in functions are included to ease some common issues. They are executed in the general format, and can be used in place of any literal or variable. Its arguments can be given as literals, variables, or even other functions.

Ordre des opérations
Operations are generally done left-to-right, but there is an order to which they are resolved. As soon as the filter fails one of the conditions, it will stop checking the rest of them (due to short-circuit evaluation) and move on to the next filter. The evaluation order is:


 * 1) Anything surrounded by parentheses (  and  ) is evaluated as a single unit.
 * 2) Turning variables/literals into their respective data. (e.g.,   to 0)
 * 3) Function calls (,  , etc.)
 * 4) Unary   and   (defining positive or negative value, e.g. ,  )
 * 5) Mots-clés (,  , etc.)
 * 6) Inversion booléenne
 * 7) Exponentiation
 * 8) Multiplication-related (multiplication, division, modulo)
 * 9) Addition and subtraction
 * 10) Comparisons.
 * 11) Boolean operations.

Exemples

 * is equivalent to, not to  . In particular, both   and   evaluates to.
 * is equivalent to, not to  . In particular, both   and   evaluates to.

Comptage des conditions
The condition limit is (more or less) tracking the number of comparison operators + number of function calls entered.

Further explanation on how to reduce conditions used can be found at.

Exclusions
Although the AbuseFilter examine function will identify "rollback" actions as edits, the AbuseFilter will not evaluate rollback actions for matching.

Liens utiles

 * PCRE pattern syntax
 * Edit filters benefiting to various local Wikiprojects