Dlaczego powinieneś ponownie skomponować Unicode (NFC) w drodze na zewnątrz?

Question

TomC zaleca dekomponowanie znaków Unicode po drodze i ponowne skomponowanie po drodze (http://www.perl.com/pub/2012/04/perl-unicode-cookbook-always-decompose-and-recompose.html).

Pierwszy z nich ma dla mnie sens, ale nie rozumiem, dlaczego poleca przekomponowanie go w drodze. Potencjalnie możesz zaoszczędzić trochę miejsca, jeśli twój tekst jest ciężki z europejskimi akcentowanymi znakami, ale po prostu naciskasz to na czyjąś funkcję dekompozycji.

Czy są inne oczywiste powody, których mi brakuje?

Answer 1

Jak Ven'Tatsu pisze w komentarzu, istnieje oprogramowanie, które może obsłużyć złożone znaki, ale nie rozłożone postacie. Choć teoretycznie jest to możliwe, nigdy nie widziałem tego w praktyce i oczekuję, że będzie to rzadkie.

Aby wyświetlić tylko rozłożony znak, oprogramowanie renderujące musi radzić sobie z łączeniem znaków diakrytycznych. Nie wystarczy znaleźć ich w czcionce. Render musi poprawnie umieścić znak diakrytyczny, używając informacji o wymiarach znaku bazowego. Często pojawiają się w tym problemy, które powodują słabe renderowanie - zwłaszcza jeśli renderowanie używa diakrytycznych czcionek! Rezultat nie może być lepszy niż to, co osiąga się po prostu poprzez wyświetlanie glifu z prekomponowaną postacią, np. "É", zaprojektowaną przez typografa.

(renderowania oprogramowanie może również analizować sytuację i efektywnie odwzorować rozłożony znak do precomposed charakteru. Ale to wymagałoby dodatkowego kodu.)

Answer 2

Ułatwi to np. Edytor tekstu, ponieważ użytkownik końcowy oczekiwałby, że jedna widoczna postać będzie jedną, a nie kilkoma. Zapobiega to również problemom z systemami, które nie traktują rozłożonych znaków jako "pojedynczych" znaków.

Poza tym nie widzę żadnej szczególnej korzyści.

Answer 3

To dość proste: większość narzędzi ma ograniczone wsparcie dla Unicode; zakładają, że postacie są w formie NFC.

Na przykład, jest powszechnie jak ludzie porównują łańcuchy:

perl -CSDA -e"use utf8; if ($ARGV[0] eq "Éric") { ... }" 

I oczywiście, „e” jest w formie NFC (ponieważ to właśnie niemal wszystko produkuje), więc ten program akceptuje tylko argumenty Formularz NFC.

Answer 4

Tom Christiansen jest aktywnym uczestnikiem na StackOverflow i odpowiedzi na wiele pytań Perl . Jest spora szansa, że ​​odpowie na to pytanie.

Pewne sekwencje znaków, takich jak ff można przedstawić UTF-8 albo dwa znaki unikodowe f i f lub jako jeden znak unikodową (ff). Kiedy rozkładają swoich bohaterów, robisz rzeczy takie jak ff stać się dwoma oddzielnymi znakami, które byłyby ważne dla sortowania. Chcesz, aby to sortowanie było dwoma oddzielnymi literami: f.

Po ponownym skomponowaniu UTF-8 f i f, wracają one do pojedynczego znaku UTF-8, który byłby ważny dla wyświetlania (chcesz, aby były ładnie sformatowane) i do edycji (chcesz go edytować jako pojedynczy postać).

Niestety, moja teoria rozpada się z takimi rzeczami jak hiszpański ñ.Jest to reprezentowane jako U + 00F1 jako pojedynczy znak i rozkłada się do U + 006E (n) i U + 0303 (w miejscu ~). Może Perl ma wbudowaną logikę, aby obsłużyć ten typ dwóch rozkładów znaków w rozkładzie UTF-8.

Answer 5

Powinieneś jedną formę normalizacji, aby wszystkie dane miały taką samą normalizację, więc dlaczego nie wybrać potencjalnie krótszego?

Co do czyjejś dekompozycji, pamiętaj, że chcesz być surowy w stosunku do tego, co wypowiadasz, ale za to, co akceptujesz. :)