When Elasticsearch compares one token with another, it does so at the byte level. In other words, for two tokens to be considered the same, they need to consist of exactly the same bytes. Unicode, however, allows you to write the same letter in different ways.
For instance, what’s the difference between é and é? It
depends on who you ask. According to Elasticsearch, the first one consists of
the two bytes
0xC3 0xA9, and the second one consists of three bytes,
According to Unicode, the differences in how they are represented as bytes is
irrelevant, and they are the same letter. The first one is the single letter
é, while the second is a plain
e combined with an acute accent
If you get your data from more than one source, it may happen that you have
the same letters encoded in different ways, which may result in one form of
déjà not matching another!
Fortunately, a solution is at hand. There are four Unicode normalization
forms, all of which convert Unicode characters into a standard format, making
comparable at a byte level:
It doesn’t really matter which normalization form you choose, as long as all
your text is in the same form. That way, the same tokens consist of the
same bytes. That said, the compatibility forms allow you to compare
ﬃ with their simpler representation,
icu_normalizer token filter mentioned previously, there is also an
icu_normalizer character filter, which does the same job as the token
filter, but does so before the text reaches the tokenizer. When using the
standard tokenizer or
icu_tokenizer, this doesn’t really matter. These
tokenizers know how to deal with all forms of Unicode correctly.
However, if you plan on using a different tokenizer, such as the
pattern tokenizers, it would make sense to use the
icu_normalizer character filter in preference to the token filter.
Usually, though, you will want to not only normalize the byte order of tokens,
but also lowercase them. This can be done with
the custom normalization form
nfkc_cf, which we discuss in the next section.