C API: Unicode Normalization.
Old Unicode normalization API.
This API has been replaced by the unorm2.h API and is only available for backward compatibility. The functions here simply delegate to the unorm2.h functions, for example unorm2_getInstance() and unorm2_normalize(). There is one exception: The new API does not provide a replacement for unorm_compare(). Its declaration has been moved to unorm2.h.
unorm_normalize transforms Unicode text into an equivalent composed or decomposed form, allowing for easier sorting and searching of text. unorm_normalize supports the standard normalization forms described in Unicode Standard Annex #15: Unicode Normalization Forms.
Characters with accents or other adornments can be encoded in several different ways in Unicode. For example, take the character A-acute. In Unicode, this can be encoded as a single character (the "composed" form):
00C1 LATIN CAPITAL LETTER A WITH ACUTE
or as two separate characters (the "decomposed" form):
0041 LATIN CAPITAL LETTER A
0301 COMBINING ACUTE ACCENT
To a user of your program, however, both of these sequences should be treated as the same "user-level" character "A with acute accent". When you are searching or comparing text, you must ensure that these two sequences are treated equivalently. In addition, you must handle characters with more than one accent. Sometimes the order of a character's combining accents is significant, while in other cases accent sequences in different orders are really equivalent.
Similarly, the string "ffi" can be encoded as three separate letters:
0066 LATIN SMALL LETTER F
0066 LATIN SMALL LETTER F
0069 LATIN SMALL LETTER I
or as the single character
FB03 LATIN SMALL LIGATURE FFI
The ffi ligature is not a distinct semantic character, and strictly speaking it shouldn't be in Unicode at all, but it was included for compatibility with existing character sets that already provided it. The Unicode standard identifies such characters by giving them "compatibility" decompositions into the corresponding semantic characters. When sorting and searching, you will often want to use these mappings.
unorm_normalize helps solve these problems by transforming text into the canonical composed and decomposed forms as shown in the first example above. In addition, you can have it perform compatibility decompositions so that you can treat compatibility characters the same as their equivalents. Finally, unorm_normalize rearranges accents into the proper canonical order, so that you do not have to worry about accent rearrangement on your own.
Form FCD, "Fast C or D", is also designed for collation. It allows to work on strings that are not necessarily normalized with an algorithm (like in collation) that works under "canonical closure", i.e., it treats precomposed characters and their decomposed equivalents the same.
It is not a normalization form because it does not provide for uniqueness of representation. Multiple strings may be canonically equivalent (their NFDs are identical) and may all conform to FCD without being identical themselves.
The form is defined such that the "raw decomposition", the recursive canonical decomposition of each character, results in a string that is canonically ordered. This means that precomposed characters are allowed for as long as their decompositions do not need canonical reordering.
Its advantage for a process like collation is that all NFD and most NFC texts - and many unnormalized texts - already conform to FCD and do not need to be normalized (NFD) for such a process. The FCD quick check will return UNORM_YES for most strings in practice.
unorm_normalize(UNORM_FCD) may be implemented with UNORM_NFD.
For more details on FCD see the collation design document: https://htmlpreview.github.io/?https://github.com/unicode-org/icu-docs/blob/main/design/collation/ICU_collation_design.htm
ICU collation performs either NFD or FCD normalization automatically if normalization is turned on for the collator object. Beyond collation and string search, normalized strings may be useful for string equivalence comparisons, transliteration/transcription, unique representations, etc.
The W3C generally recommends to exchange texts in NFC. Note also that most legacy character encodings use only precomposed forms and often do not encode any combining marks by themselves. For conversion to such character encodings the Unicode text needs to be normalized to NFC. For more usage examples, see the Unicode Standard Annex.
Definition in file unorm.h.
Iterative normalization forward.
This function (together with unorm_previous) is somewhat similar to the C++ Normalizer class (see its non-static functions).
Iterative normalization is useful when only a small portion of a longer string/text needs to be processed.
For example, the likelihood may be high that processing the first 10% of some text will be sufficient to find certain data. Another example: When one wants to concatenate two normalized strings and get a normalized result, it is much more efficient to normalize just a small part of the result around the concatenation place instead of re-normalizing everything.
The input text is an instance of the C character iteration API UCharIterator. It may wrap around a simple string, a CharacterIterator, a Replaceable, or any other kind of text object.
If a buffer overflow occurs, then the caller needs to reset the iterator to the old index and call the function again with a larger buffer - if the caller cares for the actual output. Regardless of the output buffer, the iterator will always be moved to the next normalization boundary.
This function (like unorm_previous) serves two purposes:
1) To find the next boundary so that the normalization of the part of the text from the current position to that boundary does not affect and is not affected by the part of the text beyond that boundary.
2) To normalize the text up to the boundary.
The second step is optional, per the doNormalize parameter. It is omitted for operations like string concatenation, where the two adjacent string ends need to be normalized together. In such a case, the output buffer will just contain a copy of the text up to the boundary.
pNeededToNormalize is an output-only parameter. Its output value is only defined if normalization was requested (doNormalize) and successful (especially, no buffer overflow). It is useful for operations like a normalizing transliterator, where one would not want to replace a piece of text if it is not modified.
If doNormalize==true and pNeededToNormalize!=NULL then *pNeeded... is set true if the normalization was necessary.
If doNormalize==false then *pNeededToNormalize will be set to false.
If the buffer overflows, then *pNeededToNormalize will be undefined; essentially, whenever U_FAILURE is true (like in buffer overflows), this result will be undefined.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4