perlunicode — online w chmurze

PROGRAM:

IMIĘ

perlunicode — obsługa Unicode w Perlu

OPIS

Jeśli jeszcze tego nie zrobiłeś, przed przeczytaniem tego dokumentu powinieneś zapoznać się z obydwoma
perlunitut i perluniintro.

Unicode ma na celu UNI-fy en-KOD-ings wszystkich światowych zestawów znaków w jednym
Standard. Dla wielu różnych standardów kodowania, które istniały, gdy istniał Unicode
stworzony po raz pierwszy, konwersja z każdego na Unicode zasadniczo oznaczała dodanie stałej do każdego
punkt kodowy w oryginalnym standardzie, a konwersja z powrotem oznaczała po prostu odjęcie tego samego
stały. W przypadku ASCII i ISO-8859-1 stała wynosi 0. W przypadku ISO-8859-5 (cyrylica)
stała to 864; dla hebrajskiego (ISO-8859-8) jest to 1488; tajski (ISO-8859-11), 3424; a więc
naprzód. Ułatwiło to konwersję i ułatwiło przyjęcie Unicode.

I zadziałało; obecnie te starsze standardy są rzadko używane. Większość używa każdy
Unikod.

Unicode to kompleksowy standard. Określa wiele rzeczy poza zakresem Perla,
takie jak sposób wyświetlania sekwencji znaków. Aby uzyskać pełną dyskusję na temat wszystkich aspektów
Unicode, zobhttp://www.unicode.org>.

Ważny Ostrzeżenia
Chociaż niektóre fragmenty tej sekcji mogą być dla Państwa niezrozumiałe w pierwszym czytaniu, my
myślę, że jest wystarczająco ważne, aby podkreślić niektóre z gotchas przed zagłębieniem się dalej, więc
tutaj idzie:

Obsługa Unicode to obszerne wymaganie. Podczas gdy Perl nie implementuje Unicode
standard lub towarzyszące mu raporty techniczne od deski do deski, Perl obsługuje wiele z nich
Funkcje Unicode.

Ponadto użycie Unicode może powodować problemy z bezpieczeństwem, które nie są oczywiste. Przeczytaj Unicode
Względy bezpieczeństwahttp://www.unicode.org/reports/tr36>.

Najbezpieczniej, jeśli „użyjesz funkcji„ unicode_strings ””
Aby zachować kompatybilność wsteczną, Perl nie włącza pełnej wersji wewnętrznej
Obsługa Unicode, chyba że określono pragma „użyj funkcji „unicode_strings””. (Ten
jest wybierany automatycznie, jeśli „użyjesz 5.012” lub nowszego.) Niezastosowanie się do tego może
wywołać nieoczekiwane niespodzianki. Zobacz „Błąd Unicode”” poniżej.

Ta pragma nie ma wpływu na operacje we/wy. Nie zmienia też wewnętrznej reprezentacji
ciągi znaków, tylko ich interpretacja. Nadal istnieje kilka miejsc, w których Unicode
nie jest w pełni obsługiwany, na przykład w nazwach plików.

Warstwy wejściowe i wyjściowe
Użyj warstwy „:encoding(...)”, aby odczytywać i zapisywać uchwyty plików za pomocą
określone kodowanie. (Patrz otwarte.)

Powinieneś przekonwertować swoje skrypty Perla inne niż ASCII, inne niż UTF-8 na UTF-8.
Zobacz kodowanie.

„użyj utf8” nadal potrzebne do włączenia UTF-8 w skryptach
Jeśli twój skrypt Perla jest zakodowany w UTF-8, pragma „use utf8” musi być
jawnie uwzględnione, aby umożliwić rozpoznanie tego (w ciągu znaków lub wyrażeniu regularnym
literały lub w nazwach identyfikatorów). To zdjęcie is dotychczasowy tylko czas jeśli chodzi o komunikację i motywację an wyraźny "posługiwać się utf8"
is potrzebne. (Patrz utf8).

Automatyczne wykrywanie skryptów oznaczonych „BOM” i skryptów UTF-16
Jeśli jednak skrypt Perla zaczyna się od Unicode „BOM” (UTF-16LE, UTF16-BE lub
UTF-8) lub jeśli skrypt wygląda jak kod UTF-16 bez oznaczenia „BOM” albo endianizmu, Perl
będzie poprawnie odczytany w skrypcie jako odpowiednie kodowanie Unicode. („BOM” – mniej
UTF-8 nie może być skutecznie rozpoznany ani odróżniony od ISO 8859-1 lub innego
kodowanie ośmiobitowe).

Bajt i Postać Semantyka
Przed Unicode większość kodowań używała 8 bitów (jeden bajt) do kodowania każdego znaku. Zatem
znak był bajtem, a bajt był znakiem, a mogło ich być tylko 256 lub mniej
możliwe postacie. Odnosi się do tego „Semantyka bajtów” w tytule tej sekcji
zachowanie. Nie było potrzeby rozróżniania „Bajtów” i „Znaków”.

Potem pojawia się Unicode, który ma miejsce na ponad milion znaków (a Perl na to pozwala
nawet więcej). Oznacza to, że znak może wymagać więcej niż jednego bajtu do przedstawienia
to, więc te dwa terminy nie są już równoważne. Jakie znaczenie mają postacie
całych bytów, a nie zwykle składających się na nie bajtów. Na tym polega termin
„Semantyka znaków” w tytule tej sekcji odnosi się do.

Perl musiał zmienić się wewnętrznie, aby oddzielić „bajty” od „znaków”. To jest ważne, by
ty też zmień swoje pomysły, jeśli jeszcze tego nie zrobiłeś, więc „bajt” i „znak” nie
oznaczają już to samo w twoim umyśle.

Podstawowym elementem składowym łańcuchów Perla zawsze był „znak”. Zmiany
zasadniczo sprowadza się do tego, że implementacja nie myśli już, że postać jest zawsze
tylko jeden bajt.

Należy zwrócić uwagę na różne rzeczy:

· Funkcje obsługi ciągów w większości nadal działają w zakresie
postacie. „length()”, na przykład, zwraca liczbę znaków w łańcuchu,
tak jak wcześniej. Ale ta liczba niekoniecznie jest już taka sama jak liczba
bajtów w łańcuchu (może być więcej bajtów niż znaków). Drugi taki
funkcje obejmują „chop()”, „chomp()”, „substr()”, „pos()”, „index()”, „rindex()”,
„sort()”, „sprintf()” i „write()”.

Wyjątkami są:

· zorientowany bitowo „vec”

· zorientowany bajtowo format „pakuj”/„rozpakowuj” „C”.

Jednak specyfikator „W” działa na całych znakach, podobnie jak „U”
specyficzny.

· niektórzy operatorzy współpracujący z systemem operacyjnym platformy

Przykładami są operatory zajmujące się nazwami plików.

· gdy funkcje są wywoływane z zakresu pragmy „use bytes”.

Prawdopodobnie i tak powinieneś używać tego tylko do debugowania.

· Łańcuchy — w tym klucze skrótu — i wzorce wyrażeń regularnych mogą zawierać znaki
które mają wartości porządkowe większe niż 255.

Jeśli do edytowania programu używasz edytora Unicode, mogą wystąpić znaki Unicode
bezpośrednio w ciągach znaków w kodowaniu UTF-8 lub UTF-16. (Były
wymaga „BOM” lub „użyj utf8”, to drugie wymaga „BOM”.)

„Tworzenie Unicode” w perluniintro daje inne sposoby umieszczania znaków innych niż ASCII
twoje stringi.

· Funkcje „chr()” i „ord()” działają na całych znakach.

· Wyrażenia regularne dopasowują całe znaki. Na przykład, "." pasuje do całości
znak zamiast pojedynczego bajtu.

· Operator „tr///” tłumaczy całe znaki. (Zauważ, że "tr///CU"
funkcjonalność została usunięta. Aby zapoznać się z podobną funkcjonalnością, zobacz „pack('U0',
...)" i "pack('C0', ...)").

· „Scalar reverse()” odwraca raczej o znak niż o bajt.

· Operatory ciągów bitowych, "& | ^ ~" i (począwszy od wersji 5.22) "&. |. ^. ~." może działać
na znakach, które nie mieszczą się w bajcie. Jednak obecne zachowanie prawdopodobnie
zmiana. Nie należy używać tych operatorów w ciągach zakodowanych w UTF-8. Jeśli
nie masz pewności co do kodowania łańcucha, zmień jego wersję na niższą przed użyciem któregokolwiek z nich
operatorzy; możesz użyć „utf8::utf8_downgrade()”.

Najważniejsze jest to, że Perl zawsze ćwiczył „semantykę znaków”, ale z
pojawienie się Unicode, który jest teraz inny niż „Byte Semantics”.

ASCII Zasady przeciwko Unicode Zasady
Przed Unicode, kiedy znak był bajtem był znakiem, Perl wiedział tylko o 128
znaki zdefiniowane przez ASCII, punkty kodowe od 0 do 127 (z wyjątkiem „użyj ustawień regionalnych”).
To pozostawiło punkty kodowe od 128 do 255 jako nieprzypisane i dostępne do dowolnego użytku
program może chcieć. Jedyna semantyka, jaką mają, to ich liczebniki porządkowe i to oni
nie należą do żadnej z nieujemnych klas postaci. Żaden nie jest uważany za pasujący
Na przykład „\w”, ale wszystkie pasują do „\W”.

Unicode, oczywiście, przypisuje każdemu z tych punktów kodowych określone znaczenie (wraz z
powyżej 255). Aby zachować kompatybilność wsteczną, Perl używa tylko znaczeń Unicode
gdy istnieją pewne oznaki, że Unicode jest tym, czym jest zamierzony; w przeciwnym razie nie-ASCII
punkty kodowe pozostają traktowane tak, jakby były nieprzypisane.

Oto sposoby, dzięki którym Perl wie, że łańcuch powinien być traktowany jako Unicode:

· W zakresie „użyj utf8”

Jeśli cały program jest w formacie Unicode (co oznacza 8-bit Unikod Tprzekształcenie
Format), to wszystkie ciągi w nim zawarte muszą być Unicode.

· W zakresie „użyj funkcji „unicode_strings””

Ta pragma została stworzona, abyś mógł wyraźnie powiedzieć Perlowi, że operacje zostały wykonane
w jej zakresie mają używać reguł Unicode. Nowsze mają wpływ na więcej operacji
Perle. Zobacz „Błąd Unicode” .

· W zakresie „użytkowania 5.012” lub nowszego

To niejawnie włącza „użyj funkcji„ unicode_strings ””.

· W zakresie "użyj ustawień regionalnych 'not_characters'" lub "użyj ustawień regionalnych" i bieżących
ustawienia regionalne to ustawienia regionalne UTF-8.

Pierwsza jest zdefiniowana tak, aby sugerować obsługę Unicode; a ten ostatni wskazuje na Unicode
locale, stąd interpretacja Unicode wszystkich zawartych w nim łańcuchów.

· Gdy łańcuch zawiera punkt kodowy obsługujący tylko Unicode

Perl nigdy nie zaakceptował punktów kodowych powyżej 255 bez Unicode, więc ich użycie
implikuje Unicode dla całego łańcucha.

· Gdy łańcuch zawiera punkt kodowy o nazwie Unicode "\N{...}"

Konstrukcja „\N{...}” jawnie odnosi się do punktu kodu Unicode, nawet jeśli jest to jeden
to jest również w ASCII. Dlatego ciąg znaków, który go zawiera, musi być w formacie Unicode.

· Gdy łańcuch pochodzi z zewnętrznego źródła oznaczonego jako Unicode

Opcja wiersza poleceń „-C” może określić, że niektóre dane wejściowe do programu są
Unicode, a jego wartości można odczytać za pomocą kodu Perla, patrz „${^UNICODE}” w
perlvar.

· Gdy łańcuch został uaktualniony do UTF-8

Funkcja „utf8::utf8_upgrade()” może być jawnie użyta do trwałego (chyba że
kolejne wywołanie „utf8::utf8_downgrade()”) powoduje, że łańcuch jest traktowany jako
Unikod.

· Istnieją dodatkowe metody dla wzorców wyrażeń regularnych

Wzorzec skompilowany z modyfikatorami „/u” lub „/a” jest traktowany jako Unicode
(chociaż istnieją pewne ograniczenia związane z „/ a”). Pod modyfikatorami „/d” i „/l”
istnieje kilka innych wskazań dla Unicode; patrz „Modyfikatory zestawów znaków” w
Perlre.

Zauważ, że wszystkie powyższe są nadpisywane w zakresie „użyj bajtów”; ale powinieneś
używaj tego pragma tylko do debugowania.

Należy również zauważyć, że niektóre interakcje z systemem operacyjnym platformy nigdy nie używają Unicode
zasady.

Kiedy obowiązują zasady Unicode:

· Operatory translacji wielkości liter używają tabel translacji wielkości liter Unicode.

Zauważ, że „uc()” lub „\U” w ciągach interpolowanych przekłada się na wielkie litery, podczas gdy
„ucfirst” lub „\u” w ciągach interpolowanych przekłada się na wielkość liter w językach, które
dokonaj rozróżnienia (co jest równoważne z wielkimi literami w językach bez rozszerzenia
różnica).

Dostępny jest moduł CPAN „Unicode::Casing”, który umożliwia zdefiniowanie własnego
odwzorowania do użycia w „lc()”, „lcfirst()”, „uc()”, „ucfirst()” i „fc” (lub ich
wersje z podwójnymi cudzysłowami, takie jak „\U”). (Przed Perlem 5.16 this
funkcjonalność była częściowo zapewniona w rdzeniu Perla, ale cierpiała z powodu wielu
wad nie do pokonania, więc zamiast tego napisano moduł CPAN.)

· Klasy znaków w wyrażeniach regularnych dopasowują się na podstawie właściwości znaków
określony w bazie danych właściwości Unicode.

„\w” może być użyte na przykład do dopasowania japońskiego ideogramu; i „[[:cyfra:]]” a
Numer bengalski.

· Można używać nazwanych właściwości Unicode, skryptów i zakresów bloków (jak w nawiasach
klas znaków) za pomocą konstrukcji „\p{}” „dopasowuje właściwość” i „\P{}”
negacja, „nie pasuje do właściwości”.

Zobacz „Właściwości znaków Unicode”, aby uzyskać więcej informacji.

Możesz zdefiniować własne właściwości znaków i użyć ich w wyrażeniu regularnym
z konstrukcją „\p{}” lub „\P{}”. Więcej informacji można znaleźć w sekcji „Właściwości znaków zdefiniowane przez użytkownika”.
detale.

Rozszerzona Grafem Klastry (Logiczny postacie)
Rozważ postać, powiedz „H”. Może pojawić się z różnymi znakami wokół niego, takimi jak
ostry akcent lub daszek, lub różne haczyki, kółka, strzały, itd., powyżej, poniżej, do
w jedną lub drugą stronę, itp. Istnieje wiele możliwości wśród języków świata.
Liczba kombinacji jest astronomiczna, a gdyby istniał znak dla każdej
kombinacja, wkrótce wyczerpałaby ponad milion możliwych znaków Unicode. Więc
Unicode przyjął inne podejście: istnieje znak dla podstawy „H” i znak
dla każdego z możliwych znaków, które można łączyć na różne sposoby, aby uzyskać ostateczną logikę
postać. Tak więc znak logiczny — który wydaje się być pojedynczym znakiem — może być a
ciąg więcej niż jednego pojedynczego znaku. Standard Unicode nazywa je
„rozszerzone klastry grafemów” (które są ulepszoną wersją już nieużywanych
„klaster grafemów”); Perl dostarcza konstrukcję wyrażenia regularnego „\X”, która pasuje do takiego wyrażenia
sekwencje w całości.

Ale intencją Unicode jest ujednolicenie istniejących standardów i praktyk dotyczących zestawów znaków oraz
kilka wcześniej istniejących standardów ma pojedyncze znaki, które oznaczają to samo, co niektóre z nich
te kombinacje, jak ISO-8859-1, który ma ich całkiem sporo. Na przykład „ŁACIŃSKA
WIELKA LITERA E Z OSTRĄ” była już w tym standardzie, kiedy pojawił się Unicode.
Dlatego Unicode dodał go do swojego repertuaru jako ten pojedynczy znak. Ale ta postać
jest uważany przez Unicode za odpowiednik sekwencji składającej się ze znaku
„ŁACIŃSKA WIELKA LITERA E”, po której następuje znak „ŁĄCZONY AKCENT OSTRY”.

„ŁACIŃSKA WIELKA LITERA E Z OSTRĄ” nazywana jest znakiem „wstępnie skomponowanym”, a jej
równoważność z sekwencją „E” i „AKCENT ŁĄCZONY” nazywana jest kanoniczną
równorzędność. Mówi się, że wszystkie wstępnie skomponowane postacie mają rozkład (na
sekwencja równoważna), a typ rozkładu jest również nazywany kanonicznym. Ciąg może
składać się w jak największym stopniu z wcześniej skomponowanych znaków lub może składać się z
całkowicie zdekomponowane postacie. Unicode nazywa je odpowiednio „formularzem normalizacji
Złożony” (NFC) i „Normalization Form Decomposed”. Moduł „Unicode::Normalize”
zawiera funkcje, które konwertują między nimi. Ciąg może również mieć oba złożone
postacie i postacie rozłożone; tego modułu można użyć, aby wszystko było jednym lub jednym
inny.

Możesz otrzymać ciągi znaków w dowolnej z tych równoważnych form. Obecnie jest
nic w Perlu 5, co ignoruje różnice. Więc będziesz musiał specjalnie go obsługiwać.
Zwykłą radą jest przekonwertowanie danych wejściowych na „NFD” przed dalszym przetwarzaniem.

Aby uzyskać bardziej szczegółowe informacje, zobhttp://unicode.org/reports/tr15/>.

Unicode Postać Właściwości
(Jedyny raz, kiedy Perl traktuje sekwencję pojedynczych punktów kodowych jako pojedynczą
znak logiczny znajduje się we wspomnianej już konstrukcji „\X”. Dlatego
„znak” w tej dyskusji oznacza pojedynczy punkt kodowy Unicode.)

Prawie wszystkie właściwości znaków Unicode są dostępne za pomocą wyrażeń regularnych
używając konstrukcji „\p{}” „pasuje do właściwości” i „\P{}” „nie pasuje do właściwości” dla
jego zaprzeczenie.

Na przykład „\p{wielkie litery}” dopasowuje dowolny pojedynczy znak z „wielkimi literami” Unicode
właściwość, podczas gdy „\p{L}” dopasowuje dowolny znak z kategorią „General_Category” o wartości „L” (litera)
właściwość (patrz „General_Category” poniżej). W przypadku pojedynczej litery nawiasy nie są wymagane
nazw właściwości, więc „\p{L}” jest równoważne z „\pL”.

Bardziej formalnie, „\p{wielkie litery}” pasuje do dowolnego pojedynczego znaku, którego Unicode „wielkie litery”
wartością właściwości jest „True”, a „\P{wielkie litery}” pasuje do każdego znaku, którego „duże litery”
wartość właściwości to „False” i mogły zostać zapisane jako „\p{wielkie litery=true}” i
odpowiednio „\p{wielkie litery=fałsz}”.

Ta formalność jest potrzebna, gdy właściwości nie są binarne; to znaczy, jeśli mogą znieść więcej
wartości niż tylko „Prawda” i „Fałsz”. Na przykład właściwość „Bidi_Class” (patrz
„Typy znaków dwukierunkowych” poniżej), mogą przyjmować kilka różnych wartości, np
„Lewy”, „Prawy”, „Odstępy” i inne. Aby je dopasować, należy określić zarówno
nazwa właściwości („Bidi_Class”) ORAZ dopasowana wartość („Left”, „Right”, itd.).
Odbywa się to, jak w powyższych przykładach, poprzez oddzielenie dwóch składników równym
znak (lub zamiennie dwukropek), na przykład „\p{Bidi_Class: Left}”.

Wszystkie właściwości znaków zdefiniowane w Unicode mogą być zapisywane w tych złożonych formach
"\P{właściwość=wartość}" lub "\p{wartość nieruchomości}", ale Perl udostępnia kilka dodatkowych właściwości
które są napisane tylko w postaci pojedynczej, a także skróty w postaci pojedynczej dla wszystkich binarnych
właściwości i niektóre inne opisane poniżej, w których można pominąć nazwę właściwości i
znak równości lub separator dwukropka.

Większość właściwości znaków Unicode ma co najmniej dwa synonimy (lub aliasy, jeśli wolisz): a
krótki, który jest łatwiejszy do wpisania, i dłuższy, który jest bardziej opisowy, a tym samym
łatwiej zrozumieć. Zatem powyższe właściwości „L” i „Litera” są równoważne i mogą
być używane zamiennie. Podobnie „duże” jest synonimem „wielkich liter” i moglibyśmy
zapisali „\p{duże litery}” równoważnie jako „\p{duże}”. Są też typowo
różne synonimy wartości, jakie może mieć właściwość. W przypadku właściwości binarnych „True” ma wartość 3
synonimy: „T”, „Tak” i „Y”; a „Fałsz” ma odpowiednio „F”, „Nie” i „N”. Ale bądź
ostrożny. Krótka forma wartości dla jednej właściwości może nie oznaczać tego samego, co to samo
krótka forma dla innego. Zatem dla właściwości „Kategoria_ogólna” „L” oznacza „Literę”,
ale dla właściwości „Bidi_Class” „L” oznacza „Lewo”. Pełna lista właściwości i
synonimy jest w perluniprops.

Różnice wielkich i małych liter w nazwach i wartościach właściwości są nieistotne; więc "\p{Górny}"
oznacza to samo co "\p{upper}" lub nawet "\p{UpPeR}". Podobnie możesz dodać lub
odjąć podkreślenia w dowolnym miejscu w środku słowa, tak aby były one również równoważne
do „\p{U_p_p_e_r}”. A biała przestrzeń jest nieistotna w sąsiedztwie znaków innych niż słowa, takich jak
jak nawiasy klamrowe i znaki równości lub separatory dwukropków, więc „\p{ Upper }” i „\p{ Upper_case
: Y }" również są ich odpowiednikami. W rzeczywistości białe znaki, a nawet łączniki zwykle mogą
dodawać lub usuwać w dowolnym miejscu. Więc nawet „\p{ Up-per case = Yes}” jest równoważne. To wszystko
jest nazywany przez Unicode „luźnym dopasowaniem”. Nieliczne miejsca, w których stosuje się ściślejsze dopasowanie, to
w środku liczb oraz we właściwościach rozszerzenia Perla, które zaczynają się lub kończą na an
podkreślać. Bardziej rygorystyczne dopasowanie dba o białe znaki (z wyjątkiem sąsiadujących z niebędącymi słowami
znaków), myślników i podkreśleń innych niż wewnętrzne.

Możesz także użyć negacji zarówno w „\p{}”, jak i „\P{}”, wprowadzając daszek („^”) między
pierwszy nawias klamrowy i nazwa właściwości: "\p{^Tamil}" jest równe "\P{Tamil}".

Prawie wszystkie właściwości są odporne na dopasowywanie bez uwzględniania wielkości liter. To znaczy dodanie „/i”
modyfikator wyrażenia regularnego nie zmienia tego, co pasują. Są dwa komplety
dotknięty. Pierwszy zestaw to „Wielka litera_litera”, „Mała litera_litera” i
„Titlecase_Letter”, z których wszystkie pasują do „Cased_Letter” pod dopasowaniem „/i”. I drugi
zestaw to „Wielkie litery”, „Małe litery” i „Titlecase”, z których wszystkie pasują do „Cased” pod „/ i”
dopasowanie. Ten zestaw zawiera również jego podzbiory „PosixUpper” i „PosixLower”, z których oba
pod "/i" pasuje do "PosixAlpha". (Różnica między tymi zestawami polega na tym, że niektóre rzeczy,
takie jak cyfry rzymskie, są pisane zarówno wielkimi, jak i małymi literami, więc są „obudowane”, ale nie są
uważane za litery, więc nie są to „Cased_Letter”.)

Zobacz „Poza punktami kodowymi Unicode”, aby uzyskać specjalne uwagi dotyczące dopasowywania Unicode
właściwości względem punktów kodowych innych niż Unicode.

Kategoria_ogólna

Każdemu znakowi Unicode przypisana jest ogólna kategoria, którą jest „najbardziej zwyczajowa”.
kategoryzacja postaci” (zhttp://www.unicode.org/reports/tr44>).

Złożony sposób ich zapisywania jest podobny do „\p{General_Category=Number}” (w skrócie:
"\p{gc:n}"). Ale Perl zapewnia skróty, w których wszystko w górę przez równe lub
separator dwukropka jest pominięty. Zamiast tego możesz po prostu napisać „\pN”.

Oto krótkie i długie formy wartości, jakie może mieć właściwość „Kategoria ogólna”:

Krótki długi

Litera L
LC, L& Cased_Letter (czyli: [\p{Ll}\p{Lu}\p{Lt}])
Lu Wielka litera_
Ll Mała litera_Litera
Porucznik Titlecase_Letter
Litera_modyfikatora Lm
Lo Other_List

Marek M
Mn Nonspacing_Mark
Mc Odstęp_Mark
Ja załączając_Mark

Liczba N.
Nd liczba_dziesiętna (również cyfra)
Nl Litera_Numer
Brak innego_numeru

P Interpunkcja (również interpunkcja)
PC Connector_Punctuation
Pd Dash_Punpunkcja
Ps Otwarta_interpunkcja
Pe Close_Interpunkcja
Pi Początkowa_interpunkcja
(może zachowywać się jak Ps lub Pe w zależności od zastosowania)
Pf Końcowa_interpunkcja
(może zachowywać się jak Ps lub Pe w zależności od zastosowania)
Po Inne_interpunkcja

Symbol S
Sm Math_Symbol
Sc Waluta_Symbol
Sk Modyfikator_Symbol
Więc inny_symbol

Separator Z
Zs Space_Separator
Zl Line_Separator
Zp Paragraf_Separator

C Inne
Kontrola Cc (także Cntrl)
Zobacz format
Surogat Cs
Wspólne użytkowanie prywatne
Cn Nieprzypisane

Jednoliterowe właściwości pasują do wszystkich znaków we wszystkich dwuliterowych właściwościach podrzędnych
zaczynające się na tę samą literę. „LC” i „L&” są specjalne: oba są aliasami zestawu
składający się ze wszystkiego, co pasuje do „Ll”, „Lu” i „Lt”.

dwukierunkowa Postać rodzaje

Ponieważ pisma różnią się kierunkowością (hebr. i arab
lewo, na przykład) Unicode dostarcza właściwość „Bidi_Class”. Niektóre z tych wartości
nieruchomość może mieć to:

Znaczenie wartości

L Od lewej do prawej
Osadzanie LRE od lewej do prawej
LRO Zastąpienie od lewej do prawej
R Od prawej do lewej
List arabski AL
Osadzanie RLE od prawej do lewej
RLO Nadpisanie od prawej do lewej
Format kierunkowy PDF Pop
PL Numer europejski
Europejski separator ES
Europejski Terminator ET
Numer arabski
Wspólny separator CS
Znak bez odstępu NSM
BN Granica Neutralna
Separator akapitu B
Separator segmentu S
WS Białe znaki
ON Inne neutralne

Właściwość ta jest zawsze zapisywana w postaci złożonej. Na przykład „\p{Bidi_Class:R}”
dopasowuje znaki, które normalnie są pisane od prawej do lewej. W przeciwieństwie do kategorii „General_Category”
właściwość, ta właściwość może mieć więcej wartości dodanych w przyszłej wersji Unicode. Te
wymienione powyżej zawierały pełny zestaw dla wielu wydań Unicode, ale inne zostały dodane
w Unikodzie 6.3; zawsze możesz znaleźć aktualne w perluniprops. I
<http://www.unicode.org/reports/tr9/> opisuje, jak z nich korzystać.

skrypty

Języki świata są pisane wieloma różnymi pismami. To zdanie (chyba że jesteś
czytając to w tłumaczeniu) jest napisany po łacinie, podczas gdy rosyjski jest napisany cyrylicą, a
Grecki jest zapisany, cóż, po grecku; Japoński głównie w hiraganie lub katakanie. Jest wiele
więcej.

Właściwości „Script” i „Script_Extensions” Unicode określają, jaki skrypt ma dany znak
jest w. Dowolną właściwość można określić za pomocą formy złożonej, takiej jak „\p{Script=Hebrajski}”
(w skrócie: "\p{sc=hebr}") lub "\p{Script_Extensions=jawajski}" (w skrócie: "\p{scx=java}"). W
ponadto Perl udostępnia skróty do wszystkich nazw właściwości „Script”. Możesz pominąć
wszystko aż do znaku równości (lub dwukropka) i po prostu napisz „\p{Latin}” lub
"\ P {cyrylica}". (Nie dotyczy to „Script_Extensions”, które jest wymagane
zapisane w postaci złożonej).

Różnica między tymi dwiema właściwościami dotyczy znaków, które są używane w wielu
skrypty. Na przykład cyfry od „0” do „9” są używane w wielu częściach świata.
Są one umieszczane w skrypcie o nazwie „Wspólne”. Inne znaki są używane tylko w kilku
skrypty. Na przykład „KATAKANA-HIRAGANA PODWÓJNY ŁĄCZNIK” jest używany w obu japońskich
skrypty, katakana i hiragana, ale nigdzie indziej. Właściwość „Script” umieszcza wszystkie
znaki, które są używane w wielu skryptach w skrypcie „Wspólny”, podczas gdy
Właściwość „Script_Extensions” umieszcza te, które są używane tylko w kilku skryptach, w każdym z nich
te skrypty; przy jednoczesnym użyciu „Wspólnego” dla tych używanych w wielu skryptach. Zatem oba te
mecz:

"0" =~ /\p{sc=Common}/ # Pasuje
"0" =~ /\p{scx=Common}/ # Pasuje

i tylko pierwszy z nich pasuje:

"\N{KATAKANA-HIRAGANA DOUBLE HYPHEN}" =~ /\p{sc=Common} # dopasowań
"\N{KATAKANA-HIRAGANA PODWÓJNY ŁĄCZNIK}" =~ /\p{scx=Common} # Brak dopasowania

I tylko dwa ostatnie pasujące:

"\N{KATAKANA-HIRAGANA PODWÓJNY ŁĄCZNIK}" =~ /\p{sc=Hiragana} # Brak dopasowania
"\N{KATAKANA-HIRAGANA PODWÓJNY ŁĄCZNIK}" =~ /\p{sc=Katakana} # Brak dopasowania
"\N{KATAKANA-HIRAGANA PODWÓJNY ŁĄCZNIK}" =~ /\p{scx=Hiragana} # dopasowań
"\N{KATAKANA-HIRAGANA PODWÓJNY ŁĄCZNIK}" =~ /\p{scx=Katakana} # dopasowań

„Script_Extensions” jest zatem ulepszonym „Skryptem”, w którym jest mniej znaków
skrypt „Wspólny” i odpowiednio więcej w innych skryptach. Jest nowy w Unicode
wersji 6.0, a jej dane prawdopodobnie znacznie się zmienią w późniejszych wydaniach, ponieważ rzeczy
załatwić się. Nowy kod prawdopodobnie powinien używać „Script_Extensions”, a nie zwykłego
"Scenariusz".

(Właściwie, oprócz „Powszechnego”, skrypt „Dziedziczony” zawiera znaki używane w
wiele skryptów. Są to znaki modyfikujące, które dziedziczą wartość skryptu
kontrolujący charakter. Niektóre z nich są używane w wielu skryptach, więc przejdź do „Dziedziczone”
zarówno w „Script”, jak i „Script_Extensions”. Inne są używane tylko w kilku skryptach, podobnie jak
w „Dziedziczone” w „Skrypcie”, ale nie w „Rozszerzenia_skryptu”.)

Warto podkreślić, że istnieje kilka różnych zestawów cyfr w Unicode
równoważne 0-9 i są dopasowywane przez „\d” w wyrażeniu regularnym. Jeśli są używane w
tylko w jednym języku, znajdują się one w „Script” i „Script_Extension” tego języka. Jeśli
są używane w więcej niż jednym skrypcie, będą w "sc=Common", ale tylko wtedy, gdy są
używane w wielu skryptach, powinny być w „scx=Common”.

Pełna lista skryptów i ich skrótów znajduje się w perluniprops.

Zastosowanie of dotychczasowy "Jest" Prefiks

Aby zapewnić kompatybilność wsteczną (z Perlem 5.6), wszystkie właściwości można zapisywać bez użycia metody
wymienione do tej pory formy złożone mogą mieć przed nazwą przedrostek „Is” lub „Is_”, więc
Na przykład „\P{Is_Lu}” jest równe „\P{Lu}”, a „\p{IsScript:Arabski}” jest równe
"\ p {arabski}".

Bloki

Oprócz skrypty, Unicode również definiuje Bloki znaków. Różnica pomiędzy
skrypty i bloki polega na tym, że koncepcja skryptów jest bliższa językom naturalnym, podczas gdy
koncepcja bloków jest bardziej sztucznym grupowaniem opartym na grupach Unicode
znaków z kolejnymi wartościami porządkowymi. Na przykład blok „Podstawowa łacina” to wszystko
znaki, których liczebniki porządkowe zawierają się w przedziale od 0 do 127 włącznie; innymi słowy, ASCII
postacie. Skrypt „łaciński” zawiera kilka liter z tego, a także kilka innych
bloki, takie jak „Dodatek Latin-1”, „Latin Extended-A”, itd., ale nie zawiera wszystkich
postacie z tych bloków. Nie zawiera np. cyfr 0-9,
ponieważ te cyfry są wspólne dla wielu skryptów, a zatem znajdują się w skrypcie „Wspólnym”.

Aby uzyskać więcej informacji na temat skryptów i bloków, zobacz UAX#24 „Właściwość skryptu Unicode”:
<http://www.unicode.org/reports/tr24>

Właściwości „Script” lub „Script_Extensions” prawdopodobnie będą tymi, których chcesz użyć
podczas przetwarzania języka naturalnego; Właściwość „Blokuj” może czasami być przydatna
praca z nakrętkami i śrubami Unicode.

Nazwy bloków są dopasowywane w postaci złożonej, na przykład „\p{Blok: Strzałki}” lub
"\p{Blk=hebrajski}". W przeciwieństwie do większości innych właściwości, tylko kilka nazw bloków ma kod Unicode-
zdefiniowana nazwa skrócona. Ale Perl zapewnia (niewielki, już nie zalecany) skrót:
Możesz powiedzieć na przykład „\p{In_Arrows}” lub „\p{In_hebrew}”.

Aby zapewnić kompatybilność wsteczną, przedrostek „In” można pominąć, jeśli nie ma konfliktu nazw
ze skryptem lub inną właściwością, a zamiast tego możesz nawet użyć przedrostka „Is”.
sprawy. Ale nie rób tego dla nowego kodu, ponieważ Twój kod może się zepsuć w nowych wersjach i
to już się wydarzyło: był czas w bardzo wczesnych wydaniach Unicode, kiedy
„\p{hebrajski}” pasowałby do blok Hebrajski; teraz nie.

Jak dotąd użycie przedrostka „In” pozwala uniknąć tej dwuznaczności. Ale nowe wersje Unicode są kontynuowane
aby dodać nowe właściwości, których nazwy zaczynają się od „In”. Istnieje możliwość, że jeden z
pewnego dnia będą kolidować z twoim użytkowaniem. Ponieważ jest to tylko rozszerzenie Perla,
Nazwa Unicode będzie miała pierwszeństwo, a Twój kod zostanie uszkodzony. Również Unicode jest
swobodnie dodawać skrypt, którego nazwa zaczyna się od „In”; to spowodowałoby problemy.

Dlatego przy określaniu bloków lepiej jest używać formy złożonej. I bądź pewien
to jest to, co naprawdę chcesz zrobić. W większości przypadków skrypty są tym, czego chcesz
zamiast.

Pełna lista bloków i ich skrótów znajduje się w perluniprops.

Inne Właściwości

Istnieje o wiele więcej właściwości niż te bardzo podstawowe opisane tutaj. Pełna lista
jest w perluniprops.

Unicode definiuje wszystkie swoje właściwości w postaci złożonej, więc wszystkie właściwości pojedynczej formy są
rozszerzenia Perla. Większość z nich to tylko synonimy Unicode, ale niektóre są
oryginalne rozszerzenia, w tym kilka w formie złożonej. I całkiem sporo
są one faktycznie zalecane przez Unicode (whttp://www.unicode.org/reports/tr18>).

Ta sekcja zawiera szczegółowe informacje na temat wszystkich rozszerzeń, które nie są tylko synonimami złożonego
z właściwości Unicode (w przypadku tych właściwości należy odwołać się do pliku Unicode
Standardhttp://www.unicode.org/reports/tr44>.

"\całun}"
To pasuje do każdego możliwego punktu kodu. Jest odpowiednikiem „qr/./s”. W przeciwieństwie do wszystkich
inna niezdefiniowana przez użytkownika właściwość „\p{}” zostanie dopasowana, żadne ostrzeżenie nie zostanie nigdy wygenerowane, jeśli to nastąpi
is jest dopasowywana do punktu kodu innego niż Unicode (zobacz „Beyond Unicode code
punkty” poniżej).

"\p{Alnum}"
Dopasowuje dowolny znak „\p{Alphabetic}” lub „\p{Decimal_Number}”.

"\p{dowolny}"
To pasuje do dowolnego punktu kodu Unicode 1_114_112. Jest synonimem dla
"\p{Unicode}".

"\p{ASCII}"
Dopasowuje to dowolny ze 128 znaków w zestawie znaków US-ASCII, czyli a
podzbiór Unicode.

"\p{Przypisany}"
To pasuje do dowolnego przypisanego punktu kodowego; to znaczy dowolny punkt kodowy, którego ogólna kategoria
nie jest „Nieprzypisane” (lub równoważnie nie jest „Cn”).

"\p{Puste}"
To jest to samo, co „\h” i „\p{HorizSpace}”: Znak zmieniający odstępy
poziomo.

"\p{Typ_dekompozycji: Non_Canonical}" (Krótko: "\p{Dt=NonCanon}")
Dopasowuje znak, który ma rozkład niekanoniczny.

Omówiono powyższą sekcję „Rozszerzone klastry grafemów (znaki logiczne)”.
rozkłady kanoniczne. Jednak znacznie więcej postaci ma inny typ
dekompozycja, dekompozycja „kompatybilna” lub „niekanoniczna”. Sekwencje, które
z tych dekompozycji nie są uważane za kanonicznie równoważne z pre-
złożony charakter. Przykładem jest „SUPERSCRIPT ONE”. To trochę jak A
zwykła cyfra 1, ale nie do końca; jego rozkład na cyfrę 1 nazywa się a
„kompatybilny” rozkład, w szczególności „super” rozkład. Istnieje kilka
takie dekompozycje kompatybilności (zobhttp://www.unicode.org/reports/tr44>),
w tym jeden o nazwie „compat”, co oznacza jakiś inny rodzaj rozkładu
który nie pasuje do innych kategorii dekompozycji wybranych przez Unicode.

Zauważ, że większość znaków Unicode nie ma rozkładu, więc ich rozkład
typ to „Brak”.

Dla Twojej wygody Perl dodał typ dekompozycji „Non_Canonical”.
dowolny z kilku rozkładów zgodności.

"\p{Wykres}"
Pasuje do dowolnego znaku graficznego. Teoretycznie oznacza to postać, która na
drukarka spowodowałaby zużycie atramentu.

"\p{przestrzeń pozioma}"
To jest to samo, co „\h” i „\p{Blank}”: znak, który zmienia odstępy
poziomo.

"\p{W=*}"
To jest synonim dla „\p{Present_In=*}”

"\p{PerlSpace}"
To jest to samo co "\s", ograniczone do ASCII, a mianowicie "[ \f\n\r\t]" i zaczynające się w
Perl v5.18, zakładka pionowa.

Mnemonik: (oryginalna) przestrzeń Perla

"\p{PerlWord}"
To jest to samo co „\w”, ograniczone do ASCII, a mianowicie „[A-Za-z0-9_]”

Mnemonik: (oryginalne) słowo Perla.

"\p{Posix...}"
Istnieje kilka z nich, które są odpowiednikami, używając notacji „\ p{}”, dla
klasy Posix i są opisane w „Klasy znaków POSIX” w perlrecharclass.

"\p{Present_In: *}" (Krótko: "\p{In=*}")
Ta właściwość jest używana, gdy trzeba wiedzieć, w jakich wersjach Unicode jest dany znak.

„*” powyżej oznacza dwucyfrowy numer wersji Unicode, na przykład 1.1 lub 4.0; Lub
„*” może być również „Nieprzypisane”. Ta właściwość będzie pasować do punktów kodowych, których
ostateczna dyspozycja została ustalona na podstawie wydania Unicode podanego przez wersję
numer; „\p{Present_In: Unassigned}” dopasuje te punkty kodowe, których znaczenie ma
jeszcze do przypisania.

Na przykład „U + 0041” „ŁACIŃSKA WIELKA LITERA A” była obecna w pierwszym Unicode
dostępne wydanie, czyli 1.1, więc ta właściwość jest prawdziwa dla wszystkich prawidłowych wersji „*”.
Z drugiej strony, „U+1EFF” nie zostało przypisane do wersji 5.1, kiedy stało się „LATYNOWE
MAŁA LITERA Y Z PĘTLĄ”, więc jedyne „*”, które by do niej pasowały, to 5.1, 5.2 i
później.

Unicode zapewnia właściwość „Wiek”, z której to pochodzi. Problem z Wiek
jest to, że ścisła interpretacja tego (którą przyjmuje Perl) ma dopasowanie dokładne
zwolnij znaczenie punktu kodowego jest wprowadzone w. Zatem „U + 0041” pasowałoby tylko do 1.1;
i tylko „U+1EFF” 5.1. To zwykle nie jest to, czego chcesz.

Niektóre implementacje właściwości Age w języku innym niż Perl mogą zmienić jej znaczenie na
taka sama jak właściwość Perla „Present_In”; po prostu bądź tego świadomy.

Innym zamieszaniem związanym z obiema tymi właściwościami jest to, że definicja nie mówi, że
punkt kodowy był przydzielony, ale znaczenie punktu kodowego było
ustalona. Dzieje się tak, ponieważ 66 punktów kodowych zawsze będzie nieprzypisanych, a więc
„Wiek” to dla nich wersja Unicode, w której podjęto decyzję o ich wykonaniu.
Na przykład „U+FDD0” ma być trwale nieprzypisane do postaci i decyzji
aby to zrobić, zostało wykonane w wersji 3.1, więc „\p{Age=3.1}” pasuje do tego znaku, jak również
robi „\p{Present_In: 3.1}” i nowsze.

"\p{Drukuj}"
To pasuje do każdego znaku graficznego lub pustego, z wyjątkiem kontrolek.

"\p{SpacePerl}"
Jest to to samo, co „\s”, w tym poza ASCII.

Mnemonik: Przestrzeń, zmodyfikowana przez Perla. (Nie obejmuje pionowej karty, dopóki
v5.18, który zarówno standard Posix, jak i Unicode uwzględniają białe znaki).

"\p{Tytuł}" i "\p{wielka litera}"
W przypadku dopasowywania z uwzględnieniem wielkości liter oba pasują do tych samych punktów kodowych, co „\p{General
Category=Titlecase_Letter}" ("\p{gc=lt}"). Różnica polega na tym, że pod "/i" bez wielkości liter
pasujące, pasują tak samo jak „\p{Cased}”, podczas gdy „\p{gc=lt}” pasują
"\p{Cased_Letter").

"\p{Unicode}"
To pasuje do dowolnego punktu kodu Unicode 1_114_112. "\p{dowolny}".

"\p{Przestrzeń pionowa}"
Jest to to samo, co „\v”: znak, który zmienia odstępy w pionie.

"\p{Słowo}"
Jest to to samo co „\w”, w tym ponad 100_000 znaków poza ASCII.

"\p{XPosix...}"
Jest ich kilka, które są w pełni rozszerzonymi standardowymi klasami Posix
Zakres Unicode. Są one opisane w „Klasach znaków POSIX” w perlrecharclass.

Określony przez użytkownika Postać Właściwości
Możesz zdefiniować własne właściwości znaków binarnych, definiując podprogramy, których nazwy
zaczynać się od „In” lub „Is”. (Eksperymentalna funkcja „(?[ ])” w perlre zapewnia
alternatywa, która pozwala na bardziej złożone definicje.) Podprogramy mogą być definiowane w dowolny sposób
pakiet. Właściwości zdefiniowane przez użytkownika mogą być używane w wyrażeniu regularnym "\p{}" i
konstrukcje "\P{}"; jeśli używasz właściwości zdefiniowanej przez użytkownika z pakietu innego niż
w którym się znajdujesz, musisz określić jego pakiet w konstrukcji „\p{}” lub „\P{}”.

# zakładając właściwość Is_Foreign zdefiniowaną w Lang::
pakiet główny; # wymagana nazwa pakietu właściwości
if ($txt =~ /\p{Lang::IsForeign}+/) { ... }

język paczki; # nazwa pakietu właściwości nie jest wymagana
if ($txt =~ /\p{IsForeign}+/) { ... }

Zauważ, że efekt jest w czasie kompilacji i niezmienny po zdefiniowaniu. Jednak podprogramy
przekazywany jest pojedynczy parametr, który wynosi 0, jeśli obowiązuje dopasowywanie z uwzględnieniem wielkości liter i nie
zero, jeśli obowiązuje dopasowywanie bez wielkości liter. Podprogram może zwracać różne wartości
w zależności od wartości flagi, a jeden zestaw wartości będzie obowiązywał niezmiennie
wszystkie dopasowania z uwzględnieniem wielkości liter, a drugi zestaw dla wszystkich dopasowań bez uwzględniania wielkości liter.

Zauważ, że jeśli wyrażenie regularne jest skażone, Perl raczej umrze niż wywoła
podprogramu, gdy nazwa podprogramu jest określona przez skażone dane.

Podprogramy muszą zwracać specjalnie sformatowany łańcuch z jednym lub więcej znakami nowej linii
rozdzielone linie. Każda linia musi być jedną z następujących:

· Pojedyncza liczba szesnastkowa oznaczająca punkt kodowy do uwzględnienia.

· Dwie liczby szesnastkowe oddzielone poziomymi białymi znakami (spacją lub tabliczką
znaków) oznaczających zakres punktów kodowych do uwzględnienia.

· Coś do dołączenia, poprzedzone „+”: wbudowana właściwość znaku (poprzedzona przez
„utf8::”) lub w pełni kwalifikowany (wraz z nazwą pakietu) znak zdefiniowany przez użytkownika
właściwość, aby reprezentować wszystkie znaki w tej właściwości; dwa kody szesnastkowe
punkty za zakres; lub pojedynczy szesnastkowy punkt kodowy.

· Coś do wykluczenia, poprzedzone „-”: istniejąca właściwość znaku (poprzedzona przez
„utf8::”) lub w pełni kwalifikowany (wraz z nazwą pakietu) znak zdefiniowany przez użytkownika
właściwość, aby reprezentować wszystkie znaki w tej właściwości; dwa kody szesnastkowe
punkty za zakres; lub pojedynczy szesnastkowy punkt kodowy.

· Coś do zanegowania, poprzedzone „!”: istniejąca właściwość znaku (poprzedzona przez
„utf8::”) lub w pełni kwalifikowany (wraz z nazwą pakietu) znak zdefiniowany przez użytkownika
właściwość, aby reprezentować wszystkie znaki w tej właściwości; dwa kody szesnastkowe
punkty za zakres; lub pojedynczy szesnastkowy punkt kodowy.

· Coś, z czym się przecina, poprzedzone „&”: istniejąca właściwość znaku (prefiks
przez „utf8::”) lub w pełni kwalifikowany (w tym nazwę pakietu) znak zdefiniowany przez użytkownika
właściwość, dla wszystkich znaków z wyjątkiem znaków we właściwości; dwa
szesnastkowe punkty kodowe dla zakresu; lub pojedynczy szesnastkowy punkt kodowy.

Na przykład, aby zdefiniować właściwość, która obejmuje zarówno japońskie sylabariusze (hiragana i
katakana), możesz zdefiniować

sub InKana {
powrót <
3040\t309F
30A0\t30FF
KONIEC
}

Wyobraź sobie, że znacznik końcowy here-doc znajduje się na początku linii. Teraz możesz użyć
„\p{InKana}” i „\P{InKana}”.

Mogłeś również użyć istniejących nazw właściwości bloku:

sub InKana {
powrót <<'KONIEC';
+utf8::InHiragana
+utf8::InKatakana
KONIEC
}

Załóżmy, że chcesz dopasować tylko przydzielone znaki, a nie surowe zakresy bloków: in
innymi słowy, chcesz usunąć nieprzypisane znaki:

sub InKana {
powrót <<'KONIEC';
+utf8::InHiragana
+utf8::InKatakana
-utf8::IsCn
KONIEC
}

Negacja jest przydatna do definiowania (niespodzianka!) zanegowanych klas.

sub InNotKana {
powrót <<'KONIEC';
!utf8::InHiragana
-utf8::WKatakanie
+utf8::IsCn
KONIEC
}

Spowoduje to dopasowanie wszystkich punktów kodowych innych niż Unicode, ponieważ każdy z nich nie znajduje się w Kana. Ty
w razie potrzeby można użyć przecięcia, aby je wykluczyć, jak pokazuje ten zmodyfikowany przykład:

sub InNotKana {
powrót <<'KONIEC';
!utf8::InHiragana
-utf8::WKatakanie
+utf8::IsCn
&utf8::Dowolny
KONIEC
}

&utf8::any musi być ostatnim wierszem definicji.

Przecięcie jest zwykle używane do uzyskiwania wspólnych znaków dopasowanych przez dwa (lub więcej)
klasy. Ważne jest, aby pamiętać, aby nie używać „&” dla pierwszego zestawu; to byłoby
przecinające się z niczym, co daje pusty zbiór.

W przeciwieństwie do niezdefiniowanych przez użytkownika dopasowań właściwości „\p{}”, żadne ostrzeżenie nie jest nigdy generowane, jeśli te
właściwości są dopasowywane do punktu kodowego innego niż Unicode (zobacz „Poza punktami kodowymi Unicode”
poniżej).

Określony przez użytkownika Walizka Mapowania (Na poważny hakerzy tylko)
To zdjęcie cecha ma być usunięte as of Perl 5.16. Zapewnia moduł CPAN „Unicode::Casing”.
lepszą funkcjonalność bez wad, które miała ta funkcja. Jeśli używasz Perla
wcześniej niż 5.16, ta funkcja została w pełni udokumentowana w wersji 5.14 tego poda:
<http://perldoc.perl.org/5.14.0/perlunicode.html#User-Defined-Case-Mappings-%28for-serious-hackers-only%29>

Postać Kodowanie dla Wkład i Wydajność
Zobacz kodowanie.

Unicode Regularna Wyrażenie Wsparcie poziom
Poniższa lista obsługiwanych funkcji Unicode dla wyrażeń regularnych opisuje wszystkie
funkcje obecnie obsługiwane bezpośrednio przez rdzeń Perla. Odniesienia do „Poziomu N” i
numery sekcji odnoszą się do standardu technicznego Unicode nr 18, „Unicode Regular
Expressions”, wersja 13, z sierpnia 2008 r.

· Poziom 1 — podstawowa obsługa Unicode

RL1.1 Notacja szesnastkowa - gotowe [1]
Właściwości RL1.2 - gotowe [2][3]
Właściwości zgodności z RL1.2a — gotowe [4]
RL1.3 Odejmowanie i przecinanie — eksperymentalne [5]
RL1.4 Proste granice słów - gotowe [6]
RL1.5 Proste luźne mecze - gotowe [7]
Granice linii RL1.6 — BRAK [8][9]
Dodatkowe punkty kodowe RL1.7 — gotowe [10]

[1] "\N{U+...}" i "\x{...}"
[2] "\p{...}" "\P{...}"
[3] obsługuje nie tylko minimalną listę, ale wszystkie właściwości znaków Unicode (patrz Unicode
Właściwości postaci powyżej)
[4] "\d" "\D" "\s" "\S" "\w" "\W" "\X" "[:rekwizyt:]" "[:^prop:]"
[5] Eksperymentalna funkcja rozpoczynająca się w wersji 5.18 „(?[...])” umożliwia to.
Zobacz "(?[ ])" w perlre. Jeśli nie chcesz korzystać z funkcji eksperymentalnej, możesz to zrobić
użyj jednego z poniższych:

· Wyrażenie regularne z wyprzedzeniem

Możesz naśladować odejmowanie klas za pomocą podglądu. Na przykład, co UTS#18
może napisz jak

[{Block=grecki}-[{NIEPRZYPISANY}]]

w Perlu można zapisać jako:

(?!\p{Nieprzypisany})\p{Blok=Grecki}
(?=\p{Przypisany})\p{Blok=Grecki}

Ale w tym konkretnym przykładzie prawdopodobnie naprawdę chcesz

\p{grecki}

które będą pasować do przypisanych znaków, o których wiadomo, że są częścią pisma greckiego.

· Moduł CPAN „Unicode::Regex::Set”

Implementuje pełne grupowanie, przecinanie, łączenie i usuwanie UTS # 18
składnia (odejmowanie).

· „Właściwości znaków zdefiniowane przez użytkownika”

„+” dla sumy, „-” dla usunięcia (różnica zestawu), „&” dla przecięcia

[6] "\b" "\B"
[7] Zauważ, że Perl wykonuje pełne składanie przypadków w dopasowaniu, a nie w prostym:
Na przykład „U+1F88” jest odpowiednikiem „U+1F00 U+03B9”, a nie tylko „U+1F80”.
Ta różnica ma znaczenie głównie dla niektórych greckich wielkich liter z pewnymi
modyfikatory: pełne składanie rozkłada literę, podczas gdy proste składanie
fold zmapuje go do pojedynczego znaku.

[8] Perl traktuje "\n" jako ogranicznik linii początkowej i końcowej. Unicode określa więcej
postaci, które należy tak interpretować.
Są to:

VT U+000B (\v w C)
FF U+000C (\f)
CR U+000D (\r)
NEL U+0085
LS U+2028
PS U+2029

„^” i „$” we wzorcach wyrażeń regularnych mają pasować do wszystkich tych wzorców, ale
nie. Znaki te również nie wpływają, ale powinny wpływać na „<>” $. i linię skryptu
numery.

Ponadto wiersze nie powinny być dzielone w obrębie „CRLF” (tzn. nie ma pustej linii pomiędzy
„\r” i „\n”). W przypadku „CRLF” wypróbuj warstwę „:crlf” (zobacz PerlIO).

[9] Ale dostępny jest „Unicode::LineBreak”.
Ten moduł zapewnia łamanie linii zgodne z UAX#14 „Unicode Line Breaking
Algorytm"http://www.unicode.org/reports/tr14>.

[10] UTF-8/UTF-EBDDIC używane w Perlu pozwala nie tylko na „U+10000” do „U+10FFFF”, ale także
poza „U+10FFFF”
· Poziom 2 - Rozszerzona obsługa Unicode

RL2.1 Odpowiedniki kanoniczne - BRAK [10][11]
RL2.2 Domyślne klastry grafemów — BRAK [12]
RL2.3 Domyślne granice słów — GOTOWE [14]
RL2.4 Domyślne luźne dopasowania — BRAK [15]
Właściwości nazwy RL2.5 — GOTOWE
Właściwości symboli wieloznacznych RL2.6 — BRAK

[10] patrz UAX#15 „Formularze normalizacji Unicode”
[11] mają Unicode::Normalize, ale nie są zintegrowane z wyrażeniami regularnymi
[12] mają \X i \b{gcb}, ale nie mamy „klastra grafemów
Tryb"
[14] patrz UAX#29, Granice słów
[15] Jest to omówione w rozdziale 3.13 (w Unicode 6.0)

· Poziom 3 — Wsparcie dostosowane do potrzeb

RL3.1 Dostosowana interpunkcja — BRAK
RL3.2 Dopasowane klastry grafemów — BRAK [17] [18]
RL3.3 Dostosowane granice słów — BRAK
RL3.4 Dopasowane luźne mecze — BRAK
Zakresy dostosowane do RL3.5 — BRAK
Dopasowanie kontekstu RL3.6 — BRAK [19]
RL3.7 Dopasowania przyrostowe — BRAK
(Udostępnianie zestawu Unicode RL3.8)
RL3.9 Możliwe zestawy meczowe — BRAK
RL3.10 Pasowanie składane - BRAK [20]
RL3.11 Dopasowania podrzędne — BRAK

[17] patrz UAX#10 „Algorytmy sortowania Unicode”
[18] mają Unicode::Collate, ale nie są zintegrowane z wyrażeniami regularnymi
[19] mają (?<=x) i (?=x), ale patrzą w przód lub w tył
powinien widzieć poza docelowym podłańcuchem
[20] potrzebują niewrażliwego dopasowania dla innych cech językowych
niż przypadek; na przykład hiragana do katakana, szeroka i
wąski, uproszczony Han na tradycyjny Han (patrz UTR#30
„Składanie znaków”)

Unicode Kodowanie
Znaki Unicode są przypisane do kod zwrotnica, które są liczbami abstrakcyjnymi. Aby użyć tych
liczby, potrzebne są różne kodowania.

· UTF-8

UTF-8 to kodowanie o zmiennej długości (od 1 do 4 bajtów), niezależne od kolejności bajtów. W większości
dokumentacji Perla, w tym w innych częściach tego dokumentu, termin „UTF-8” oznacza
także „UTF-EBCDIC”. Ale w tej sekcji „UTF-8” odnosi się tylko do używanego kodowania
Platformy ASCII. Jest to nadzbiór 7-bitowego US-ASCII, więc wszystko zakodowane w ASCII ma
identyczna reprezentacja po zakodowaniu w UTF-8.

Poniższa tabela pochodzi z Unicode 3.2.

Punkty kodowe 1. bajt 2. bajt 3. bajt 4. bajt

U+0000..U+007F 00..7F
U+0080..U+07FF * C2..DF 80..BF
U+0800..U+0FFF E0 * A0..BF 80..BF
U+1000..U+CFFF E1..EC 80..BF 80..BF
U+D000..U+D7FF ED 80..9F 80..BF
U+D800..U+DFFF +++++ surogaty utf16, niedozwolone utf8 +++++
U+E000..U+FFFF EE..EF 80..BF 80..BF
U+10000..U+3FFFF F0 * 90..BF 80..BF 80..BF
U+40000..U+FFFFF F1..F3 80..BF 80..BF 80..BF
U+100000..U+10FFFF F4 80..8F 80..BF 80..BF

Zwróć uwagę na luki oznaczone „*” przed kilkoma powyższymi wpisami bajtów. To są
spowodowane przez legalne kodowanie UTF-8 unikające nie najkrótszych kodowań: jest to technicznie możliwe
kodowanie UTF-8 pojedynczego punktu kodowego na różne sposoby, ale jest to wyraźnie zabronione,
i zawsze należy używać najkrótszego możliwego kodowania (i tak właśnie robi Perl).

Innym sposobem spojrzenia na to jest bity:

Punkty kodowe 1. bajt 2. bajt 3. bajt 4. bajt

0aaaaaaaa 0aaaaaaaa
00000bbbbbaaa 110bbbbb10aaaaaa
ccccbbbbbbaaaaa 1110cccc 10bbbbbb 10aaaaaaaa
00000dddccccccbbbbbbbbaaaaaa 11110ddd 10cccccc 10bbbbbb 10aaaaaa

Jak widać, wszystkie bajty kontynuacji zaczynają się od „10”, a wiodące bity od
bajt początkowy mówi, ile bajtów zawiera zakodowany znak.

Oryginalna specyfikacja UTF-8 dopuszczała do 6 bajtów, aby umożliwić kodowanie liczb
do „0x7FFF_FFFF”. Perl nadal na to pozwala i rozszerzył tę liczbę do 13
bajtów do zakodowania punktów kodowych aż do tego, co zmieści się w 64-bitowym słowie. Jednak Perl to zrobi
ostrzegaj, jeśli któryś z nich zostanie wyświetlony jako nieprzenośny; i pod ścisłym wejściem UTF-8
protokołów, są one zabronione.

· UTF-EBCDIC

Podobnie jak UTF-8, ale bezpieczny dla EBCDIC, tak jak UTF-8 jest bezpieczny dla ASCII. To oznacza, że ​​wszystko
podstawowe znaki (w tym wszystkie, które mają odpowiedniki ASCII (jak „A”,
„0”, „%”, itd.) są takie same zarówno w EBCDIC, jak i UTF-EBCDIC.)

UTF-EBCDIC jest używany na platformach EBCDIC. Największe punkty kodu Unicode zajmują 5 bajtów
do reprezentowania (zamiast 4 w UTF-8), a Perl rozszerza go do maksymalnie 7 bajtów, aby
encode pode wskazuje na to, co zmieści się w 32-bitowym słowie (zamiast 13 bajtów i
64-bitowe słowo w UTF-8).

· UTF-16, UTF-16BE, UTF-16LE, surogaty i „BOM” (znaki kolejności bajtów)

Poniższe elementy są głównie w celach informacyjnych i ogólnej wiedzy o Unicode, Perl
nie używa tych konstrukcji wewnętrznie.

Podobnie jak UTF-8, UTF-16 jest kodowaniem o zmiennej szerokości, ale tam, gdzie UTF-8 używa kodu 8-bitowego
jednostek, UTF-16 wykorzystuje 16-bitowe jednostki kodu. Wszystkie punkty kodowe zajmują 2 lub 4 bajty
UTF-16: punkty kodowe „U+0000..U+FFFF” są przechowywane w pojedynczej jednostce 16-bitowej, a kod
wskazuje „U + 10000.. U + 10FFFF” w dwóch jednostkach 16-bitowych. Ten ostatni przypadek jest używany surogaty,
pierwszą 16-bitową jednostką jest wysoka surogat, a drugim jest Niska
surogat.

Surogaty to punkty kodowe przeznaczone do kodowania zakresu „U+10000..U+10FFFF”
Punkty kodowe Unicode w parach jednostek 16-bitowych. The wysoka surogaty są zakresem
„U+D800..U+DBFF” i Niska surogaty to zakres „U+DC00..U+DFFF”. Surogat
kodowanie jest

$hi = ($uni - 0x10000) / 0x400 + 0xD800;
$lo = ($uni - 0x10000) % 0x400 + 0xDC00;

i dekodowanie jest

$uni = 0x10000 + ($hi - 0xD800) * 0x400 + ($lo - 0xDC00);

Ze względu na 16-bitowość, UTF-16 jest zależny od kolejności bajtów. Można użyć samego UTF-16
do obliczeń w pamięci, ale jeśli wymagane jest przechowywanie lub przesyłanie, albo UTF-16BE
Należy wybrać kodowanie (big-endian) lub UTF-16LE (little-endian).

To wprowadza kolejny problem: co jeśli po prostu wiesz, że twoje dane to UTF-16, ale
nie wiesz jaka endianność? Znaki kolejności bajtów lub „BOM” są rozwiązaniem
Ten. Znak specjalny został zarezerwowany w Unicode do działania jako kolejność bajtów
znacznik: znak z punktem kodowym „U+FEFF” to „BOM”.

Sztuczka polega na tym, że jeśli przeczytasz „BOM”, poznasz kolejność bajtów, ponieważ gdyby tak było
napisany na platformie big-endian, odczytasz bajty „0xFE 0xFF”, ale gdyby tak było
napisany na platformie little-endian, odczytasz bajty „0xFF 0xFE”. (A jeśli
platforma źródłowa pisała w platformie ASCII UTF-8, odczytasz bajty
„0xEF 0xBB 0xBF”.)

Sposób, w jaki ta sztuczka działa, polega na tym, że znak z punktem kodowym „U + FFFE” nie jest
ma być w strumieniach wejściowych, więc sekwencja bajtów „0xFF 0xFE” jest jednoznacznie
„BOM”, reprezentowane w formacie little-endian” i nie może być „U+FFFE”, reprezentowane w
formacie big-endian”.

Surogaty nie mają żadnego znaczenia w Unicode poza ich użyciem w parach do reprezentowania innych
punkty kodowe. Jednak Perl pozwala na ich indywidualną reprezentację wewnętrzną, np
przykład mówiąc „chr(0xD801)”, tak aby wszystkie punkty kodowe, a nie tylko te ważne dla
otwarta wymiana, są reprezentowalne. Unicode definiuje dla nich semantykę, na przykład
ich „Ogólna_kategoria” to „Cs”. Ale ponieważ ich użycie jest nieco niebezpieczne, Perl
ostrzeże (używając kategorii ostrzeżenia „surrogat”, która jest podkategorią „utf8”)
jeśli podejmowana jest próba zrobienia rzeczy, takich jak wzięcie małej litery jedynki lub dopasowanie wielkości liter-
niewrażliwe lub do ich wyprowadzania. (Ale nie próbuj tego na Perlach przed 5.14.)

· UTF-32, UTF-32BE, UTF-32LE

Rodzina UTF-32 jest bardzo podobna do rodziny UTF-16, z wyjątkiem tego, że jednostki są
32-bitowy, dlatego schemat zastępczy nie jest potrzebny. UTF-32 to stała szerokość
kodowanie. Podpisy „BOM” to „0x00 0x00 0xFE 0xFF” dla BE i „0xFF 0xFE 0x00
0x00" dla LE.

· UCS-2, UCS-4

Starsze kodowanie o stałej szerokości zdefiniowane w normie ISO 10646. UCS-2 jest 16-bitowym
kodowanie. W przeciwieństwie do UTF-16, UCS-2 nie jest rozszerzalny poza „U + FFFF”, ponieważ tak nie jest
korzystać z zastępców. UCS-4 to 32-bitowe kodowanie, funkcjonalnie identyczne z UTF-32 (tzw
różnica polega na tym, że UCS-4 nie zabrania ani surogatów, ani punktów kodowych większych niż
"0x10_FFFF").

· UTF-7

Bezpieczne siedmiobitowe (nie ośmiobitowe) kodowanie, które jest przydatne podczas transportu lub przechowywania
nie jest bezpieczny dla ośmiu bitów. Zdefiniowane w dokumencie RFC 2152.

Nieznakowy kod zwrotnica
66 punktów kodowych jest zarezerwowanych w Unicode jako „nieznakowe punkty kodowe”. To wszystko ma
„Nieprzypisana” („Cn”) „Ogólna_kategoria” i żadna postać nigdy nie zostanie przypisana do żadnej z
ich. Są to 32 punkty kodowe między „U+FDD0” i „U+FDEF” włącznie oraz 34
punkty kodowe:

U+FFFE U+FFFF
U+1FFFF U+1FFFF
U+2FFFF U+2FFFF
...
U+EFFF U+EFFF
U+FFFF U+FFFF
U+10FFFF U+10FFFF

Aż do Unicode 7.0 znaki niebędące znakami to „zabroniony do użytku w otwartej wymianie
Dane tekstowe Unicode”, aby kod przetwarzający te strumienie mógł używać tych punktów kodowych
jako wartownicy, których można było mieszać z danymi postaci i zawsze tak będzie
odróżnić od tych danych. (Wyróżnienia powyżej i w następnym akapicie zostały dodane
ten dokument.)

Unicode 7.0 zmienił sformułowanie tak, że są one „nie Zalecana do użytku na otwartej przestrzeni
wymiana danych tekstowych Unicode”. Standard 7.0 mówi dalej:

„Jeśli w otwartej wymianie otrzymany zostanie znak niebędący znakiem, aplikacja nie musi tego robić
interpretować to w jakikolwiek sposób. Dobrą praktyką jest jednak uznanie go za tzw
noncharacter i podjąć odpowiednie działania, takie jak zastąpienie go ciągiem „U+FFFD”
znak zastępczy, wskazujący problem w tekście. Nie zaleca się
po prostu usuń nieznakowe punkty kodowe z takiego tekstu, ze względu na potencjał
problemy z bezpieczeństwem spowodowane usuwaniem niezinterpretowanych znaków. (Patrz klauzula zgodności
C7 w sekcji 3.2, Wymagania dotyczące zgodności i Raport techniczny Unicode nr 36,
„Uwagi dotyczące bezpieczeństwa Unicode”
<http://www.unicode.org/reports/tr36/#Substituting_for_Ill_Formed_Subsequences>)."

Ta zmiana została wprowadzona, ponieważ stwierdzono, że różne narzędzia komercyjne, takie jak edytory lub
dla rzeczy takich jak kontrola kodu źródłowego, zostały napisane tak, że nie poradziłyby sobie
pliki programów, które korzystały z tych punktów kodowych, skutecznie wykluczając ich użycie prawie
całkowicie! A to nigdy nie było zamierzone. Zawsze miały nadawać się do użytku wewnątrz
aplikacji lub współpracującego zestawu aplikacji, do woli.

Jeśli piszesz kod, taki jak edytor, powinien on być w stanie obsłużyć dowolny
danych tekstowych Unicode, to nie powinieneś sam używać tych punktów kodowych, a zamiast tego
pozwól im wejść. Jeśli potrzebujesz strażników, powinni zamiast tego być kimś takim
nie jest legalnym Unicode. W przypadku danych UTF-8 możesz użyć bajtów 0xC1 i 0xC2 jako wartowników, ponieważ
nigdy nie pojawiają się w dobrze sformułowanym UTF-8. (Istnieją odpowiedniki dla UTF-EBCDIC). Możesz
przechowuj także swoje punkty kodowe Unicode w zmiennych całkowitych i używaj wartości ujemnych jako
strażnicy.

Jeśli nie piszesz takiego narzędzia, to czy akceptujesz znaki inne niż znaki jako dane wejściowe, zależy od tego
(chociaż Standard zaleca, aby tego nie robić). Jeśli przeprowadzasz ścisłe sprawdzanie strumienia wejściowego
w Perlu te punkty kodowe są nadal zabronione. Ma to na celu utrzymanie wstecz
kompatybilność (w przeciwnym razie mogą się otworzyć potencjalne luki w zabezpieczeniach, jako niczego niepodejrzewający
aplikacja, która została napisana przy założeniu, że znaki niebędące znakami zostaną wcześniej odfiltrowane
się do niego dostać, mógłby teraz, bez ostrzeżenia, zacząć je zdobywać). Aby przeprowadzić ścisłą kontrolę,
możesz użyć warstwy „:encoding('UTF-8')".

Perl nadal ostrzega (używając kategorii ostrzeżeń „nonchar”, która jest podkategorią
„utf8”), jeśli podejmowana jest próba wyprowadzenia znaków niebędących znakami.

Poza Unicode kod zwrotnica
Maksymalny punkt kodu Unicode to „U+10FFFF”, a Unicode definiuje tylko operacje na kodzie
wskazuje przez to. Ale Perl działa na punktach kodowych do maksymalnego dopuszczalnego poziomu
niepodpisany numer dostępny na platformie. Jednak Perl nie zaakceptuje ich z danych wejściowych
strumieni, chyba że używane są luźne reguły, i będzie ostrzegać (używając kategorii ostrzeżeń
„non_unicode”, która jest podkategorią „utf8”), jeśli jakieś są wyprowadzane.

Ponieważ reguły Unicode nie są zdefiniowane w tych punktach kodowych, jeśli operacja zdefiniowana w Unicode
jest na nich zrobione, Perl używa zasad, które uważamy za rozsądne, jednocześnie ogólnie ostrzegając,
przy użyciu kategorii „non_unicode”. Na przykład „uc("\x{11_0000}")" wygeneruje taki a
ostrzeżenie, zwracając parametr wejściowy jako wynik, ponieważ Perl definiuje wielkie litery
każdy punkt kodowy inny niż Unicode będzie sam w sobie punktem kodowym. (Wszystko się zmienia
operacje, a nie tylko wielkie litery, działają w ten sposób.)

Sytuacja z pasującymi właściwościami Unicode w wyrażeniach regularnych, "\p{}" i
Konstrukcje „\ P {}” w stosunku do tych punktów kodowych nie są tak jednoznaczne i jak one są
obsługiwane zmieniało się wraz ze zdobywaniem doświadczenia.

Jedną z możliwości jest traktowanie dowolnego dopasowania do tych punktów kodowych jako niezdefiniowanego. Lecz odkąd
Perl nie ma pojęcia, że ​​dopasowanie jest niezdefiniowane, konwertuje to na niepowodzenie lub
"FAŁSZ". To jest prawie, ale nie całkiem, to, co Perl zrobił od wersji 5.14 (kiedy używa się tych kodów
punkty stały się ogólnie niezawodne) do wersji 5.18. Różnica polega na tym, że Perl traktował wszystkich
„\p{}” oznacza niepowodzenie, ale wszystkie dopasowania „\P{}” oznaczają sukces.

Jednym z problemów jest to, że w niektórych przypadkach prowadzi to do nieoczekiwanych i mylących rezultatów
przypadki:

chr(0x110000) =~ \p{ASCII_Hex_Digit=True} # Błąd w <= v5.18
chr(0x110000) =~ \p{ASCII_Hex_Digit=False} # Niepowodzenie! na <= v5.18

Oznacza to, że potraktował oba dopasowania jako niezdefiniowane i przekonwertował je na fałsz (podnosząc a
ostrzeżenie na każdym). Pierwszy przypadek to wynik oczekiwany, ale drugi jest prawdopodobny
sprzeczne z intuicją: „Jak oba mogą być fałszywe, skoro są dopełnieniami?” Kolejny problem
było to, że implementacja zoptymalizowała wiele dopasowań właściwości Unicode do już
istniejące prostsze, szybsze operacje, które nie generują ostrzeżenia. Postanowiliśmy nie rezygnować
te optymalizacje, które pomagają większości dopasowań, tylko po to, by wygenerować ostrzeżenie
dla mało prawdopodobnego zdarzenia, w którym porównywany jest punkt kodu powyżej Unicode.

W wyniku tych problemów, począwszy od wersji 5.20, Perl traktuje kody inne niż Unicode
punkty kodowe jako zwykłe nieprzypisane znaki Unicode i odpowiednio dopasowują.
(Uwaga: Unicode ma nietypowe nieprzypisane punkty kodowe. Na przykład ma kod niebędący znakiem
punkty i takie, które, kiedy już zostaną przydzielone, są przeznaczone do zapisania Prawo do-
lewo, podobnie jak arabski i hebrajski. Perl zakłada, że ​​żaden punkt kodowy inny niż Unicode go nie ma
nietypowe właściwości).

Perl w większości przypadków zgłosi ostrzeżenie, gdy dopasuje punkt kodu powyżej Unicode
względem właściwości Unicode, gdy wynikiem jest „PRAWDA” dla „\p{}” i „FAŁSZ” dla „\P{}”.
Na przykład:

chr(0x110000) =~ \p{ASCII_Hex_Digit=True} # Błąd, brak ostrzeżenia
chr(0x110000) =~ \p{ASCII_Hex_Digit=False} # Sukces, z ostrzeżeniem

W obu tych przykładach dopasowywany znak nie jest Unicode, więc Unicode nie
zdefiniuj jak to ma pasować. To wyraźnie nie jest cyfrą szesnastkową ASCII, więc pierwszy przykład
wyraźnie powinien zawieść, i tak też się dzieje, bez ostrzeżenia. Ale można dyskutować, że to drugie
example powinien mieć niezdefiniowany wynik, stąd „FALSE”. W związku z tym pojawia się ostrzeżenie.

Tak więc ostrzeżenie pojawia się w znacznie mniejszej liczbie przypadków niż we wcześniejszych wersjach Perla i tylko wtedy, kiedy co
wynik może być dyskusyjny. Okazuje się, że żadna z optymalizacji wykonanych przez Perla
(lub prawdopodobnie kiedykolwiek zostaną wykonane) powodują pominięcie ostrzeżenia, więc rozwiązuje oba
problemy wcześniejszego podejścia Perla. Najczęściej używana właściwość, na którą ma wpływ
ta zmiana to „\p{Nieprzypisane}”, co jest skróconą formą
"\p{kategoria_ogólna=Nieprzypisany}". Począwszy od wersji 5.20, wszystkie punkty kodowe inne niż Unicode są
uważane za „nieprzypisane”. We wcześniejszych wersjach dopasowania nie powiodły się, ponieważ wynik był
uważane za nieokreślone.

Jedynym miejscem, w którym ostrzeżenie nie jest podnoszone, gdy powinno być, jest if
optymalizacje powodują, że nawet nie próbuje się dopasować całego wzorca. Na przykład Perla
może dowiedzieć się, że aby łańcuch pasował do określonego wzorca wyrażenia regularnego, ciąg
musi zawierać podłańcuch „foobar”. Przed próbą dopasowania Perl może wyszukać
ten podłańcuch, a jeśli nie zostanie znaleziony, natychmiast zakończy się niepowodzeniem dopasowania bez faktycznego wypróbowania go;
więc żadne ostrzeżenie nie zostanie wygenerowane, nawet jeśli ciąg zawiera punkt kodowy powyżej Unicode.

To zachowanie jest bardziej „Zrób to, co mam na myśli” niż we wcześniejszych wersjach Perla dla większości aplikacji. Ale
wychwytuje mniej problemów z kodem, który musi być ściśle zgodny z Unicode. Dlatego
dostępny jest dodatkowy tryb działania obsługujący taki kod. Ten tryb jest
włączone, jeśli wzorzec wyrażenia regularnego jest kompilowany w zakresie leksykalnym, w którym
Klasa ostrzegawcza „non_unicode” została uznana za śmiertelną, powiedzmy przez:

użyj ostrzeżeń FATAL => "non_unicode"

(patrz ostrzeżenia). W tym trybie działania Perl podniesie ostrzeżenie dla wszystkich dopasowań
przeciwko punktowi kodowemu innemu niż Unicode (nie tylko spornym) i pomija
optymalizacje, które mogą spowodować, że ostrzeżenie nie zostanie wyświetlone. (Obecnie nadal nie
ostrzec, jeśli nawet nie podjęto próby dopasowania, jak w powyższym przykładzie „foobar”).

Podsumowując, Perl obecnie normalnie traktuje punkty kodowe inne niż Unicode jako typowe nieprzypisane znaki Unicode
punkty kodowe dla dopasowań wyrażeń regularnych, podnosząc ostrzeżenie tylko wtedy, gdy jest to dyskusyjne
jaki powinien być wynik. Jeśli jednak to ostrzeżenie stało się śmiertelne, nie jest
pominięto.

Od tego wszystkiego jest jeden wyjątek. „\p{All}” wygląda jak właściwość Unicode, ale jest to a
Rozszerzenie Perla, które jest zdefiniowane jako prawdziwe dla wszystkich możliwych punktów kodowych, Unicode lub nie, więc
żadne ostrzeżenie nie jest nigdy generowane podczas dopasowywania tego do punktu kodu innego niż Unicode. (Wcześniejszy
do wersji 5.20 był to dokładny synonim „\p{Any}”, pasujący do punktów kodowych od 0 do 0x10FFFF.)

Bezpieczeństwo Implikacje of Unicode
Najpierw przeczytaj Uwagi dotyczące bezpieczeństwa Unicodehttp://www.unicode.org/reports/tr36>.

Zwróć też uwagę na następujące kwestie:

· Zniekształcony UTF-8

Niestety oryginalna specyfikacja UTF-8 pozostawia pewne pole do interpretacji
ile bajtów zakodowanego wyjścia należy wygenerować z jednego wejścia Unicode
postać. Ściśle mówiąc, powinna to być najkrótsza możliwa sekwencja bajtów UTF-8
generowany, ponieważ w przeciwnym razie istnieje możliwość przepełnienia bufora wejściowego w
odbierający koniec połączenia UTF-8. Perl zawsze generuje UTF-8 o najkrótszej długości,
a przy włączonych ostrzeżeniach Perl będzie ostrzegał o niekrótszej długości UTF-8 wraz z innymi
zniekształcenia, takie jak surogaty, które nie są ważnymi punktami kodowymi Unicode
wymieniać.

· Dopasowywanie wzorców wyrażeń regularnych może Cię zaskoczyć, jeśli nie jesteś do tego przyzwyczajony
Unikod. Począwszy od Perla 5.14, dostępnych jest kilka modyfikatorów wzorców
to, zwane modyfikatorami zestawu znaków. Szczegóły podano w „Zestaw znaków
modyfikatory” w perlre.

Jak omówiono w innym miejscu, Perl ma jedną stopę (dwa kopyta?) osadzone w każdym z dwóch światów: the
stary świat ASCII i jednobajtowych ustawień regionalnych oraz nowy świat Unicode, aktualizacja kiedy
niezbędny. Jeśli twój starszy kod nie używa wyraźnie Unicode, nie ma automatycznego przełączania
do Unicode powinno się zdarzyć.

Unicode in Perl on EBCDIC
Unicode jest obsługiwany na platformach EBCDIC. Zobacz perlebcdic.

O ile nie omawia się konkretnie kwestii ASCII vs. EBCDIC, odniesienia do UTF-8
kodowanie w tym dokumencie i gdzie indziej należy rozumieć jako oznaczające UTF-EBCDIC na EBCDIC
platformy. Zobacz „Unicode i UTF” w perlebcdic.

Ponieważ UTF-EBCDIC jest tak podobny do UTF-8, różnice są w większości ukryte przed tobą;
„use utf8” (a NIE coś takiego jak „use utfebcdic”) deklaruje, że skrypt jest w
„natywne” 8-bitowe kodowanie platformy Unicode. (Podobnie dla warstwy „:utf8”.)

Lokalny
Zobacz „Unicode i UTF-8” w perllocale

Kiedy Unicode Czy Nie Happen
Nadal istnieje wiele miejsc, w których można podać Unicode (w takim czy innym kodowaniu).
argumenty lub otrzymane jako wyniki, lub jedno i drugie w Perlu, ale tak nie jest, mimo że Perl ma
rozbudowane sposoby wprowadzania i wyprowadzania danych w Unicode oraz kilka innych „punktów wejścia”, takich jak
@ARGV tablica (która czasami może być interpretowana jako UTF-8).

Poniżej przedstawiono takie interfejsy. Zobacz także „Błąd Unicode””. Za to wszystko
interfejsy Perl obecnie (od wersji 5.16.0) po prostu przyjmuje łańcuchy bajtów zarówno jako argumenty
i wyników lub łańcuchy znaków UTF-8, jeśli użyto (przestarzałej) pragmy „kodowania”.

Jednym z powodów, dla których Perl nie próbuje określić roli Unicode w takich sytuacjach
jest to, że odpowiedzi w dużym stopniu zależą od systemu operacyjnego i systemów plików.
Na przykład, czy nazwy plików mogą być w Unicode iw jakim dokładnie rodzaju kodowaniu
niezupełnie przenośna koncepcja. Podobnie dla "qx" i "system": jak dobrze będzie
„interfejs wiersza poleceń” (i który z nich?) obsługuje Unicode?

· "chdir", "chmod", "chown", "chroot", "exec", "link", "lstat", "mkdir", "rename",
„rmdir”, „stat”, „dowiązanie symboliczne”, „obetnij”, „odłącz”, „utime”, „-X”

· %ENV

· „glob” (inaczej „<*>”)

· "otwórz", "opendir", "sysopen"

· "qx" (inaczej operator backtick), "system"

· „readdir”, „readlink”

Kurs „Unikod Błąd"
Termin „błąd Unicode” został zastosowany do niespójności z punktami kodowymi w
Blok „Latin-1 Supplement”, czyli między 128 a 255. Bez określenia ustawień regionalnych,
w przeciwieństwie do wszystkich innych znaków lub punktów kodowych, te znaki mogą mieć bardzo różne
semantykę w zależności od obowiązujących reguł. (Znaki, których punkty kodowe są powyżej 255
wymusić reguły Unicode; mając na uwadze, że zasady dotyczące znaków ASCII są takie same w obu ASCII
i zasady Unicode).

Zgodnie z regułami Unicode te górne znaki łacińskie1 są interpretowane jako punkty kodowe Unicode,
co oznacza, że ​​mają taką samą semantykę jak kontrolki Latin-1 (ISO-8859-1) i C1.

Jak wyjaśniono w sekcji „Zasady ASCII a zasady Unicode”, zgodnie z regułami ASCII są one brane pod uwagę
być nieprzypisanymi postaciami.

Może to prowadzić do nieoczekiwanych rezultatów. Na przykład semantyka łańcucha może nagle
zmień, jeśli zostanie do niego dołączony punkt kodowy powyżej 255, co zmieni reguły z ASCII na
Unikod. Jako przykład rozważmy następujący program i jego wynik:

$perl -le'
brak funkcji „unicode_strings”;
$s1 = "\xC2";
$s2 = "\x{2660}";
dla ($s1, $s2, $s1.$s2) {
drukuj /\w/ || 0;
}
'
0
0
1

Jeśli nie ma „\w” w „s1” ani w „s2”, dlaczego ich konkatenacja ma jeden?

Ta anomalia wynika z próby Perla, aby nie przeszkadzać starszym programom, które nie były używane
Unicode, wraz z pragnieniem Perla płynnego dodania obsługi Unicode. Ale wynik
okazał się nie być płynny. (Nawiasem mówiąc, możesz wybrać ostrzeżenie, gdy np
to się zdarzyło. Patrz „kodowanie::ostrzeżenia”.)

dodano opcję „użyj funkcji „unicode_strings””, począwszy od Perla w wersji 5.12, aby rozwiązać ten problem
problem. Wpływa na te rzeczy:

· Zmiana wielkości liter w skalarach, czyli użycie „uc()”, „ucfirst()”, „lc()”, oraz
„lcfirst()” lub „\L”, „\U”, „\u” i „\l” w kontekstach podwójnych cudzysłowów, takich jak zwykły
podstawienia wyrażeń.

Pod „unicode_strings”, począwszy od Perla 5.12.0, generalnie używane są reguły Unicode.
Zobacz „lc” w perlfunc, aby uzyskać szczegółowe informacje o tym, jak to działa w połączeniu z różnymi innymi
pragmy.

· Używanie dopasowywania wyrażeń regularnych bez wielkości liter ("/i").

Począwszy od Perla 5.14.0, wyrażenia regularne skompilowane w zakresie
„unicode_strings” używają reguł Unicode nawet wtedy, gdy są wykonywane lub kompilowane w większe regularne
wyrażenia poza zakresem.

· Dopasowanie dowolnej z kilku właściwości w wyrażeniach regularnych.

Te właściwości to "\b" (bez nawiasów klamrowych), "\B" (bez nawiasów klamrowych), "\s", "\S", "\w",
„\W” i wszystkie klasy znaków Posix z wyjątkiem "[[:ascii:]]".

Począwszy od Perla 5.14.0, wyrażenia regularne skompilowane w zakresie
„unicode_strings” używają reguł Unicode nawet wtedy, gdy są wykonywane lub kompilowane w większe regularne
wyrażenia poza zakresem.

· W "quotemeta" lub jego inline odpowiedniku "\Q".

Począwszy od Perla 5.16.0, w ramach zakresu używane są spójne reguły cytowania
„unicode_strings”, jak opisano w „quotemeta” w perlfunc. Wcześniej lub na zewnątrz
jego zakres, żadne punkty kodowe powyżej 127 nie są cytowane w ciągach zakodowanych w UTF-8, ale w bajtach
zakodowane ciągi, punkty kodowe między 128-255 są zawsze cytowane.

Z powyższego widać, że efekt „unicode_strings” wzrósł w ciągu kilku
wydania Perla. (A obsługa Perla dla Unicode stale się poprawia; najlepiej jest używać
najnowszą dostępną wersję, aby uzyskać jak najpełniejsze i najdokładniejsze wyniki.)
Zauważ, że „unicode_strings” jest wybierane automatycznie, jeśli „użyjesz 5.012” lub nowszego.

Dla Perlów wcześniejszych niż te opisane powyżej lub gdy łańcuch jest przekazywany do funkcji
poza zakresem „unicode_strings”, zobacz następną sekcję.

Wymuszanie Unicode in Perl (Lub Bez zmuszania Unicode in Perl)
Czasami (patrz „Kiedy nie występuje Unicode” lub „Błąd Unicode”) zdarzają się sytuacje
gdzie wystarczy wymusić ciąg bajtów na UTF-8 lub odwrotnie. Standard
można do tego użyć modułu Encode lub wywołań niskiego poziomu „utf8::upgrade($bytestring)”
i „utf8::downgrade($utf8string[, FAIL_OK])”.

Należy pamiętać, że funkcja „utf8::downgrade()” może się nie powieść, jeśli ciąg zawiera znaki, które nie pasują
w bajt.

Wywołanie dowolnej funkcji na ciągu znaków, który jest już w żądanym stanie, nie jest możliwe.

„Reguły ASCII a reguły Unicode” przedstawiają wszystkie sposoby tworzenia ciągu znaków w celu korzystania z Unicode
zasady.

Korzystanie z Unicode in XS
Zobacz „Obsługa Unicode” w perlguts, aby zapoznać się z wprowadzeniem do Unicode na poziomie XS i
„Obsługa Unicode” w perlapi, aby uzyskać szczegółowe informacje na temat interfejsu API.

włamanie Perl do praca on wcześniej Unicode Wersje (Na początku. poważny hakerzy tylko)
Perl domyślnie ma wbudowaną najnowszą obsługiwaną wersję Unicode, ale celem jest
aby umożliwić zmianę na dowolną wcześniejszą. Jednak w Perls v5.20 i v5.22 plik
Najwcześniejsza dostępna wersja to Unicode 5.1. Perl v5.18 jest w stanie obsłużyć wszystko wcześniej
wersje.

Pobierz pliki w żądanej wersji Unicode ze strony internetowej Unicode
<http://www.unicode.org>). Powinny one zastąpić istniejące pliki w biblioteka/unicore
Drzewo źródłowe Perla. Postępuj zgodnie z instrukcjami w CZYTAJ.perl w tym katalogu, aby coś zmienić
ich nazw, a następnie zbuduj perl (patrz INSTALACJA).

Przenoszenie kod od perl-5.6.X
Perle począwszy od wersji 5.8 mają inny model Unicode niż 5.6. W wersji 5.6 programista był
wymagane jest użycie pragmy „utf8” w celu zadeklarowania, z jakim danym zakresem ma się do czynienia
danych Unicode i musiałem upewnić się, że tylko dane Unicode osiągnęły ten zakres. Jeśli ty
masz kod, który działa z wersją 5.6, będziesz potrzebować niektórych z poniższych poprawek
Twój kod. Przykłady są napisane w taki sposób, że kod będzie nadal działał w wersji 5.6, tzw
powinieneś być bezpieczny, aby je wypróbować.

· Uchwyt pliku, który powinien czytać lub zapisywać UTF-8

jeśli ($] > 5.008) {
tryb binarny $fh, ":kodowanie(utf8)";
}

· Skalar, który będzie przekazywany do jakiegoś rozszerzenia

Czy to „Compress::Zlib”, „Apache::Request” czy dowolne rozszerzenie, o którym nie ma wzmianki
Unicode na stronie podręcznika, musisz upewnić się, że flaga UTF8 została usunięta. Notatka
że w momencie pisania tego tekstu (styczeń 2012 r.) wspomniane moduły nie są
Obsługuje UTF-8. Sprawdź dokumentację, aby sprawdzić, czy nadal jest to prawdą.

jeśli ($] > 5.008) {
wymagają kodowania;
$val = Encode::encode_utf8($val); # twórz oktety
}

· Skalar, który otrzymaliśmy z rozszerzenia

Jeśli uważasz, że skalar wraca jako UTF-8, najprawdopodobniej będziesz potrzebować flagi UTF8
odrestaurowany:

jeśli ($] > 5.008) {
wymagają kodowania;
$val = Encode::decode_utf8($val);
}

· To samo, jeśli jesteś naprawdę pewien, że jest to UTF-8

jeśli ($] > 5.008) {
wymagają kodowania;
Koduj::_utf8_on($val);
}

· Opakowanie dla DBI „fetchrow_array” i „fetchrow_hashref”

Gdy baza danych zawiera tylko kod UTF-8, wygodnym sposobem jest użycie funkcji lub metody opakowania
aby zastąpić wszystkie wywołania „fetchrow_array” i „fetchrow_hashref”. Funkcja opakowująca
ułatwi także dostosowanie się do przyszłych udoskonaleń sterownika bazy danych. Notatka
że w chwili pisania tego tekstu (styczeń 2012 r.) DBI nie ma na to ustandaryzowanego sposobu
radzi sobie z danymi w formacie UTF-8. Sprawdź dokumentację DBI, aby sprawdzić, czy nadal tak jest
prawdą.

pobierz subskrypcję {
# $co to jest fetchrow_{array,hashref}
my($self, $sth, $co) = @_;
jeśli ($] < 5.008) {
zwróć $sth->$co;
} Else {
wymagają kodowania;
jeśli (zmarszczka) {
mój @arr = $sth->$co;
dla (@arr) {
zdefiniowano && /[^\000-\177]/ && Encode::_utf8_on($_);
}
zwróć @arr;
} Else {
mój $ret = $sth->$co;
if (ref $ret) {
za mój $k (klucze %$ret) {
zdefiniowane
&& /[^\000-\177]/
&& Koduj::_utf8_on($_) dla $ret->{$k};
}
zwróć $ret;
} Else {
zdefiniowano && /[^\000-\177]/ && Encode::_utf8_on($_) dla $ret;
zwróć $ret;
}
}
}
}

· Znany duży skalar może zawierać tylko kod ASCII

Skalary zawierające tylko ASCII i oznaczone jako UTF-8 czasami utrudniają pracę
program. Jeśli rozpoznajesz taką sytuację, po prostu usuń flagę UTF8:

utf8::downgrade($val) jeśli $] > 5.008;

Używaj perlunicode online, korzystając z usług onworks.net