regex_quote
regex_quote is especially useful when your APL query constructs regular expressions dynamically using user input or field values. Without escaping, strings like .* or [a-z] would behave like regex wildcards or character classes, potentially leading to incorrect results or vulnerabilities. With regex_quote, you can ensure the string is treated exactly as-is.
Usage#
Syntax#
regex_quote(value)Parameters#
| Name | Type | Description |
|---|---|---|
| value | string | The input string to be escaped for regex safety. |
Returns#
A string where all regular expression metacharacters are escaped so that the result can be used safely in regex patterns.
Use case examples#
You want to find requests where the uri contains an exact match of a user-provided pattern, such as /api/v1/users[1], which includes regex metacharacters. Use regex_quote to safely escape the pattern before matching.
Query
let pattern = '/api/v1/users[1]';
['sample-http-logs']
| where uri matches regex regex_quote(pattern)
| project _time, id, uri, statusOutput
| _time | id | uri | status |
|---|---|---|---|
| 2025-06-10T15:42:00Z | user-293 | /api/v1/users[1] | 200 |
This query searches for logs where the uri exactly matches the string /api/v1/users[1], without interpreting [1] as a character class.
You want to isolate spans whose trace_id includes a literal substring that happens to resemble a regex pattern, such as abc.def[0]. Using regex_quote ensures the pattern is treated literally.
Query
let search_id = 'abc.def[0]';
['otel-demo-traces']
| where trace_id matches regex regex_quote(search_id)
| project _time, trace_id, span_id, ['service.name'], durationOutput
| _time | trace_id | span_id | ['service.name'] | duration |
|---|---|---|---|---|
| 2025-06-10T13:20:00Z | abc.def[0] | span-91 | frontend | 00:00:01 |
This query avoids misinterpretation of [0] as a regex character class and treats the whole trace_id literally.
You want to scan for potential path traversal attempts where a user’s input includes strings like ..\..\windows\system32. To search this string safely, you use regex_quote.
Query
let attack_pattern = '../../windows/system32';
['sample-http-logs']
| where uri matches regex regex_quote(attack_pattern)
| project _time, id, uri, status, ['geo.country']Output
| _time | id | uri | status | ['geo.country'] |
|---|---|---|---|---|
| 2025-06-11T10:15:00Z | user-103 | ....\windows\system32 | 403 | DE |
This query detects malicious-looking strings literally, without treating . as a wildcard.
Other query languages#
Splunk SPL users
In Splunk, the re.escape() function isn’t available natively in SPL, so you often handle escaping in external scripts or manually. In APL, regex_quote provides built-in support for quoting regular expression metacharacters.
Splunk example
| eval pattern="hello.*world"
| eval safe_pattern=replace(pattern, "\.", "\\.")APL equivalent
let pattern = 'hello.*world';
print safe_pattern = regex_quote(pattern)ANSI SQL users
ANSI SQL lacks a standard function to escape regular expression strings. Escaping is typically handled manually or with vendor-specific features. In APL, regex_quote handles all necessary escaping for you, making regex construction safer and more convenient.
SQL example
SELECT REGEXP_LIKE(col, 'hello\\.*world') FROM table;APL equivalent
let pattern = 'hello.*world';
print is_match = tostring('hello.*world') matches regex regex_quote(pattern)