EQL: Unicode escape sequences #62832
Assignees
Labels
Comments
rw-access
added
team-discuss
:Analytics/EQL
|
Pinging @elastic/es-ql (:Query Languages/EQL) |
matriv
added a commit
to matriv/elasticsearch
that referenced
this issue
Mar 17, 2021
Occationally, it's useful to be able to use non-printable,
RTL (right-to-left) or other non-standard unicode characters
in an EQL query.
Introducing the standard \uXXXX escape sequence as well as
the variable 2-8 char escape sequence \u{XXXXXXXX}, e.g.:
```
\u0023
\u{35}
\u{1f2da}
\u{002acd1}
```
Closes: elastic#62832
matriv
added a commit
that referenced
this issue
Mar 22, 2021
Occasionally, it's useful to be able to use non-printable,
RTL (right-to-left) or other non-standard unicode characters
in an EQL query.
Introducing an escape sequence `\u{XXXXXXXX}` where 2-8 hex
digits are allowed within the curly braces, where zero padding from the
left is implied e.g.:
```
\u{35}
\u{1f2da}
\u{002acd1}
```
Closes: #62832
matriv
added a commit
that referenced
this issue
Mar 23, 2021
Occasionally, it's useful to be able to use non-printable,
RTL (right-to-left) or other non-standard unicode characters
in an EQL query.
Introducing an escape sequence `\u{XXXXXXXX}` where 2-8 hex
digits are allowed within the curly braces, where zero padding from the
left is implied e.g.:
```
\u{35}
\u{1f2da}
\u{002acd1}
```
Closes: #62832
(cherry picked from commit cb6a6e0)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Related to #61659
This is a proposal to add two new escape sequences for unicode code points to EQL
"strings. Occasionally, we need to inject non-printable unicode characters into an EQL string. The first case we realized this was for the MITRE 2019 eval. We managed to workaround this by carefully copying and pasting a character. It was a little tricky because the character happened to be the RTL encoding character. So as soon as it was pasted, all the subsequent text was flipped, since it was immediately interpreted in the browser.I propose we add these new escape sequences, which are widely used, and how JSON typically escapes non-ascii characters.
\uXXXX\UXXXXXXXXI believe our current escape sequences are these:
\nfor newlines\rfor carriage returns\bfor backspace\tfor a tab\ffor form feed\\for backslashCurrently, if
\is not followed by one of these characters, it is invalid syntax. So this change is purely additive and doesn't break. I'm indifferent if this targets 7.10 vs 7.11.Update:
Use an alternative, less visually ambiguous form for the escape sequence:
\u{xxxxxxxx}(2-8 hex characters)The text was updated successfully, but these errors were encountered: