Extension:AbuseFilter/Rules format/ja

zh:Wikipedia:防滥用过滤器/操作指引 規則は、C言語、Java、Perlに類似したプログラミング言語の条件文と同様の書式です.

文字列
You can specify a literal by placing it in single or double quotes (for strings), or by typing it in as-is (for numbers, both floating-point and integer). 改行は 、タブ文字は  、引用符文字はバックスラッシュを付けて表記します.

Use the  (plus) symbol to concatenate two literal strings or the values of two vars with a string value.


 * 例:

User-defined variables
You can define custom variables for ease of understanding with the assign symbol  in a line (closed by  ) within a condition. Such variables may use letters, underscores, and numbers (apart from the first character) and are case sensitive. Example (from w:Special:AbuseFilter/79):

Arrays
AbuseFilter has support for non-associative arrays, which can be used like in the following examples.

コメント
You can specify comments using the following syntax: /* This is a comment */

Arithmetic
You can use basic arithmetic symbols to do arithmetic on variables and literals with the following syntax:


 * — Subtract the right-hand operand from the left-hand operand.
 * — Add the right-hand operand to the left-hand operand.
 * — Multiply the left-hand operand by the right-hand operand.
 * — Divide the left-hand operand by the right-hand operand.
 * — Raise the left-hand operand to the exponential power specified by the right-hand operand.
 * — Return the remainder given when the left-hand operand is divided by the right-hand operand.

The type of the returned result is the same that would be returned by PHP, for which a lot of documentation may be found online. More exhaustive examples may be found in this AF parser test.

論理演算子
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 – 条件のいずれかが true の場合に true を返します.
 * &mdash; AND – 条件の両方が true の場合に true を返します.
 * &mdash; XOR – 条件の片方のみが true の場合に true を返します.
 * &mdash; NOT – 条件が true ではない場合に true を返します.

Examples

単純な比較
You can compare variables with other variables and literals with the following syntax:


 * &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.

Built-in variables
不正利用フィルターでは、さまざまな変数をその変数名でパーサーに渡せます. これらの変数へは、リテラルを使用できるような場所に入力することでアクセスできます. 不正利用記録内の各リクエストに関連付けられた変数を閲覧することもできます.

注記
When, only the  ,  ,   and   variables are available. The  variables are also available, but the prefix is replaced by   and , that represent the values of the original article name and the destination one, respectively. For example,  and   instead of.

Since MediaWiki 1.28 (https://gerrit.wikimedia.org/r/#/c/295254/),  is only used when publishing an upload, and not for uploads to stash. A new  is introduced, which is used for all uploads, including uploads to stash. This behaves like  used to, and only provides file metadata variables. Variables related to the page edit, including,   and several others, are now available for. For every file upload, filters may be called with  (for uploads to stash), and are always called with  ; they are not called with.

Filter authors should use  in filter code when a file can be checked based only on the file contents – for example, to reject low-resolution files – and   only when the wikitext parts of the edit need to be examined too – for example, to reject files with no description. This will allow tools that separate uploading the file and publishing the file (e.g. UploadWizard or upload dialog) to inform the user of the failure before they spend the time filling in the upload details.

Performance
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. More specifically:

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.

キーワード
The following special keywords are included for often-used functionality:


 * (または ) は、左辺が右辺のグロブパターンに一致する場合に true を返します.
 * は、右辺 (文字列) が左辺を含む場合に true を返します. 注: 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. 注: empty strings are not contained in, nor contain, any other string (not even the empty string itself).
 * (または )、  は、左辺が右辺の正規表現に一致する (含む) 場合に true を返します (  は大文字を区別しません (insensitive)).

このシステムは PCRE を使用します. The only PCRE option enabled is  (modifier   in PHP); for   both   and   are enabled (modifier  ).



例

Functions
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.

Order of operations
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 (except for T43693). The evaluation order is:


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

Examples

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

Condition counting
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.

Useful links

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