[[analysis-pattern-analyzer]] === Pattern Analyzer The `pattern` analyzer uses a regular expression to split the text into terms. The regular expression should match the *token separators* not the tokens themselves. The regular expression defaults to `\W+` (or all non-word characters). [float] === Definition It consists of: Tokenizer:: * <> Token Filters:: * <> * <> (disabled by default) [float] === Example output [source,js] --------------------------- POST _analyze { "analyzer": "pattern", "text": "The 2 QUICK Brown-Foxes jumped over the lazy dog's bone." } --------------------------- // CONSOLE The above sentence would produce the following terms: [source,text] --------------------------- [ the, 2, quick, brown, foxes, jumped, over, the, lazy, dog, s, bone ] --------------------------- [float] === Configuration The `pattern` analyzer accepts the following parameters: [horizontal] `pattern`:: A http://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html[Java regular expression], defaults to `\W+`. `flags`:: Java regular expression http://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html#field.summary[flags]. lags should be pipe-separated, eg `"CASE_INSENSITIVE|COMMENTS"`. `lowercase`:: Should terms be lowercased or not. Defaults to `true`. `max_token_length`:: The maximum token length. If a token is seen that exceeds this length then it is split at `max_token_length` intervals. Defaults to `255`. `stopwords`:: A pre-defined stop words list like `_english_` or an array containing a list of stop words. Defaults to `_none_`. `stopwords_path`:: The path to a file containing stop words. See the <> for more information about stop word configuration. [float] === Example configuration In this example, we configure the `pattern` analyzer to split email addresses on non-word characters or on underscores (`\W|_`), and to lower-case the result: [source,js] ---------------------------- PUT my_index { "settings": { "analysis": { "analyzer": { "my_email_analyzer": { "type": "pattern", "pattern": "\\W|_", <1> "lowercase": true } } } } } GET _cluster/health?wait_for_status=yellow POST my_index/_analyze { "analyzer": "my_email_analyzer", "text": "John_Smith@foo-bar.com" } ---------------------------- // CONSOLE <1> The backslashes in the pattern need to be escaped when specifying the pattern as a JSON string. The above example produces the following terms: [source,text] --------------------------- [ john, smith, foo, bar, com ] --------------------------- [float] ==== CamelCase tokenizer The following more complicated example splits CamelCase text into tokens: [source,js] -------------------------------------------------- PUT my_index { "settings": { "analysis": { "analyzer": { "camel": { "type": "pattern", "pattern": "([^\\p{L}\\d]+)|(?<=\\D)(?=\\d)|(?<=\\d)(?=\\D)|(?<=[\\p{L}&&[^\\p{Lu}]])(?=\\p{Lu})|(?<=\\p{Lu})(?=\\p{Lu}[\\p{L}&&[^\\p{Lu}]])" } } } } } GET _cluster/health?wait_for_status=yellow GET my_index/_analyze { "analyzer": "camel", "text": "MooseX::FTPClass2_beta" } -------------------------------------------------- // CONSOLE The above example produces the following terms: [source,text] --------------------------- [ moose, x, ftp, class, 2, beta ] --------------------------- The regex above is easier to understand as: [source,js] -------------------------------------------------- ([^\p{L}\d]+) # swallow non letters and numbers, | (?<=\D)(?=\d) # or non-number followed by number, | (?<=\d)(?=\D) # or number followed by non-number, | (?<=[ \p{L} && [^\p{Lu}]]) # or lower case (?=\p{Lu}) # followed by upper case, | (?<=\p{Lu}) # or upper case (?=\p{Lu} # followed by upper case [\p{L}&&[^\p{Lu}]] # then lower case ) --------------------------------------------------