From 215eb9ccd80b69eb91ed061ca11c585766e1c7d7 Mon Sep 17 00:00:00 2001 From: Gemma Lamont Date: Fri, 12 Jan 2024 11:40:35 +0100 Subject: [PATCH] PR review changes --- modules/ROOT/pages/functions/string.adoc | 32 +++++++++++++++--------- 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/modules/ROOT/pages/functions/string.adoc b/modules/ROOT/pages/functions/string.adoc index 81eaf618e..c06d2cb5a 100644 --- a/modules/ROOT/pages/functions/string.adoc +++ b/modules/ROOT/pages/functions/string.adoc @@ -153,13 +153,19 @@ RETURN ltrim(' hello') [[functions-normalize]] == normalize() -`normalize()` returns the given `STRING` normalized using the `NFC` normalization form. +`normalize()` returns the given `STRING` normalized using the `NFC` Unicode normalization form. + +[NOTE] +==== +Unicode normalization is a process that transforms different representations of the same string into a standardized form. +For more information, see the documentation for link:https://unicode.org/reports/tr15/#Norm_Forms[Unicode normalization forms]. +==== The `normalize()` function is useful for converting `STRING` values into comparable forms. When comparing two `STRING` values, it is their Unicode codepoints that are compared. -In Unicode, a codepoint for a character that looks the same may actually be represented by two, or more, different codepoints. -For example, the character `<` can be represented as `\uFE64` or `\u003C`. Visually, the character may look the same, -but if compared, Cypher will return false as `\uFE64` does not equal `\u003C`. Using the `normalize()` function one can +In Unicode, a codepoint for a character that looks the same may be represented by two, or more, different codepoints. +For example, the character `<` can be represented as `\uFE64` (﹤) or `\u003C` (<). Visually, the character may look the same, +but if compared, Cypher will return false as `\uFE64` does not equal `\u003C`. Using the `normalize()` function, it is possible to normalize the codepoint `\uFE64` to `\u003C`, creating a single codepoint representation, allowing them to be successfully compared. *Syntax:* @@ -225,16 +231,18 @@ RETURN normalize('\u212B') = '\u00C5' AS result `normalize()` returns the given `STRING` normalized using the specified normalization form. The normalization form can be of type `NFC`, `NFD`, `NFKC` or `NFKD`. -There are two main types of normalization forms. One is based on the concept of canonical equivalence, and the other is based on compatibility. +There are two main types of normalization forms: -The two forms `NFC` (default) and `NFD` are forms of canonical equivalence. This means that codepoints which represent the same abstract character will -be normalized to the same codepoint. The same abstract character means that the character has the same visual appearance and behavior. -The difference between `NFC` and `NFD` is that `NFC` form will always give the *composed* canonical form, one where combined codes are replaced with the single representation, if possible. -Whereas, `NFD` gives the *decomposed* form, this is the opposite of composed, converting combined codepoints into the split form if possible. +* *Canonical equivalence*: The `NFC` (default) and `NFD` are forms of canonical equivalence. +This means that codepoints that represent the same abstract character will +be normalized to the same codepoint (and have the same appearance and behavior). +The `NFC` form will always give the *composed* canonical form (in which the combined codes are replaced with a single representation, if possible). +The`NFD` form gives the *decomposed* form (the opposite of the composed form, which converts the combined codepoints into a split form if possible). -The two forms `NFKC` and `NFKD` are forms of compatibility normalization. All canonically equivalent sequences are compatible, but not all compatible sequences are canonical. -This means that a character normalized in `NFC` or `NFD` should also be normalized in `NFKC` and `NFKD`, and other characters that may have a slightly different visual appearance, -but are considered close enough in appearance to be compatibly equivalent. +* *Compatability normalization*: `NFKC` and `NFKD` are forms of compatibility normalization. +All canonically equivalent sequences are compatible, but not all compatible sequences are canonical. +This means that a character normalized in `NFC` or `NFD` should also be normalized in `NFKC` and `NFKD`. +Other characters with only slight differences in appearance should be compatibly equivalent. For example, the Greek Upsilon with Acute and Hook Symbol `ϓ` can be represented by the Unicode codepoint: `\u03D3`.