Kiedy używać Unicode Normalization Forms NFC i NFD?

Question

Unicode Normalization FAQ zawiera następujący akapit:

Programy powinny zawsze porównanie kanoniczny równoważne ciągi Unicode jako równe ... Standard Unicode zapewnia dobrze zdefiniowanych form normalizacji, które mogą być wykorzystywane do tego: NFC i NFD.

i trwa ...

Wybór których użycie zależy od konkretnego programu lub systemu. NFC jest najlepszą formą dla ogólnego tekstu, ponieważ jest bardziej kompatybilny z ciągami konwertowanymi ze starszych kodowań. ... NFD i NFKD są najbardziej przydatne do wewnętrznego przetwarzania.

Moje pytania są następujące:

Co sprawia, że ​​najlepsze dla NFC "dokument". Co definiuje "wewnętrzne przetwarzanie" i dlaczego najlepiej pozostawić NFD? I wreszcie, nieważne, co jest "najlepsze", czy te dwie formy są wymienne, o ile porównywane są dwa struny za pomocą tej samej formy normalizacyjnej?

Answer 1

1. NFC jest powszechną formą zdrowego rozsądku, które należy wykorzystać, ä jest 1 punkt kod tam i to ma sens.

2. NFD sprawdza się w niektórych procesach wewnętrznych - jeśli chcesz dokonywać wrażliwych na akcentowanie wyszukiwań lub sortowania, posiadanie łańcucha w NFD znacznie ułatwia i przyspiesza proces. Innym zastosowaniem jest tworzenie solidniejszych tytułów slug. Są to najbardziej oczywiste, jestem pewien, że istnieje wiele więcej zastosowań.

3. Jeśli dwóch ciągów x i y są kanoniczne ekwiwalenty, następnie
   toNFC (x) = toNFC (y)
   toNFD (x) = toNFD (y)

   Czy to właśnie Oznaczało?

Answer 2

Często zadawane pytania są nieco mylące, począwszy od użycia słowa "powinien", a następnie niespójnego zastosowania "wymogu" dotyczącego tej samej rzeczy. Sam standard Unicode (cytowany w FAQ) jest dokładniejszy. Zasadniczo nie powinieneś oczekiwać, że programy traktują kanonicznie równoważne łańcuchy jako różne, ale nie należy oczekiwać, że wszystkie programy traktują je jako identyczne.

W praktyce naprawdę zależy to od tego, jakie oprogramowanie musi wykonać. W większości przypadków nie trzeba wcale normalizować, a normalizacja może niszczyć istotne informacje w danych.

Na przykład U + 0387 GRECJA ANO TELEIA (·) jest zdefiniowany jako kanoniczny odpowiednik U + 00B7 MIDDLE DOT (·). To był błąd, ponieważ postacie są naprawdę różne i powinny być renderowane inaczej i traktowane inaczej w przetwarzaniu. Ale jest za późno, aby to zmienić, ponieważ ta część Unicode została wykuta w kamień. W związku z tym, jeśli konwertujesz dane na NFC lub w inny sposób odrzucasz różnice między kanonicznie równoważnymi ciągami, ryzykujesz uzyskanie niewłaściwych znaków.

Istnieje ryzyko związane z normalizacją przez , a nie.Na przykład litera "ä" może pojawić się jako pojedynczy znak Unicode U + 00E4 LATIN MAŁA LITERA A Z DIAERESIS lub jako dwa znaki Unicode U + 0061 LATIN MAŁY LIST A A U + 0308 COMBINING DIAERESIS. Będzie to przede wszystkim ta pierwsza, to znaczy forma z góry złożona, ale jeśli jest to druga i twoje testy kodu dla danych zawierających "ä", tylko przy użyciu wstępnie skomponowanej formy, to nie wykryje ona tej ostatniej. Ale w wielu przypadkach nie robisz takich rzeczy, ale po prostu przechowujesz dane, łączysz łańcuchy, drukujesz je itd. Wtedy istnieje ryzyko, że te dwie reprezentacje powodują nieco różne renderowania.

Ma również znaczenie, czy oprogramowanie przekazuje dane znakowe do innego oprogramowania. Odbiorca może oczekiwać, ze względu na naiwne domyślne założenia lub świadomie iw udokumentowany sposób, że jego dane wejściowe są znormalizowane.