perlunicode – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

perlunicode – Unicode-Unterstützung in Perl

BESCHREIBUNG

Falls Sie es noch nicht getan haben, sollten Sie sich vor dem Lesen dieses Dokuments mit beiden vertraut machen
perlunitut und perluniintro.

Unicode zielt darauf ab UNI-fy the en-CODE-ings aller Zeichensätze der Welt in einem einzigen
Standard. Für eine ganze Reihe der verschiedenen Codierungsstandards, die es gab, als Unicode existierte
Bei der ersten Erstellung bedeutete die Konvertierung von jedem in Unicode im Wesentlichen das Hinzufügen einer Konstante zu jedem
Codepunkt im ursprünglichen Standard, und die Rückkonvertierung bedeutete lediglich, diesen zu subtrahieren
Konstante. Für ASCII und ISO-8859-1 ist die Konstante 0. Für ISO-8859-5 (Kyrillisch) ist die Konstante
Konstante ist 864; für Hebräisch (ISO-8859-8) ist es 1488; Thailändisch (ISO-8859-11), 3424; und so
her. Dies erleichterte die Konvertierung und erleichterte die Einführung von Unicode.

Und es hat funktioniert; Heutzutage werden diese alten Standards nur noch selten verwendet. Fast jeder nutzt es
Unicode.

Unicode ist ein umfassender Standard. Es spezifiziert viele Dinge außerhalb des Geltungsbereichs von Perl,
beispielsweise wie man Zeichenfolgen anzeigt. Für eine umfassende Diskussion aller Aspekte von
Unicode, siehehttp://www.unicode.org>.

Wichtig Vorsichtsmaßnahmen
Auch wenn einige Teile dieses Abschnitts für Sie beim ersten Lesen möglicherweise nicht verständlich sind, sind wir
Ich denke, es ist wichtig genug, einige der Fallstricke hervorzuheben, bevor man weiter darauf eingeht
Hier geht:

Unicode-Unterstützung ist eine umfangreiche Voraussetzung. Während Perl den Unicode nicht implementiert
Standard oder die begleitenden technischen Berichte von Anfang bis Ende, Perl unterstützt viele davon
Unicode-Funktionen.

Außerdem kann die Verwendung von Unicode Sicherheitsprobleme mit sich bringen, die nicht offensichtlich sind. Lesen Sie Unicode
Sicherheitsüberlegungenhttp://www.unicode.org/reports/tr36>.

Am sichersten ist es, wenn Sie „die Funktion ‚unicode_strings‘ verwenden“
Um die Abwärtskompatibilität zu wahren, aktiviert Perl nicht die vollständige interne Kompatibilität
Unicode-Unterstützung, sofern nicht das Pragma „use feature ‚unicode_strings‘“ angegeben ist. (Das
wird automatisch ausgewählt, wenn Sie „5.012“ oder höher verwenden.) Andernfalls kann dies passieren
lösen unerwartete Überraschungen aus. Siehe „Der „Unicode-Fehler““ weiter unten.

Dieses Pragma hat keinen Einfluss auf E/A. Es ändert auch nichts an der internen Darstellung von
Streicher, nur ihre Interpretation. Es gibt immer noch mehrere Orte, an denen Unicode verwendet wird
wird nicht vollständig unterstützt, z. B. in Dateinamen.

Eingabe- und Ausgabeebenen
Verwenden Sie die Ebene „:encoding(...)“, um mithilfe von Dateihandles zu lesen und in sie zu schreiben
angegebene Kodierung. (Siehe offen.)

Sie sollten Ihre Nicht-ASCII- und Nicht-UTF-8-Perl-Skripte in UTF-8 konvertieren.
Siehe Codierung.

„Utf8 verwenden“ ist weiterhin erforderlich, um UTF-8 in Skripten zu aktivieren
Wenn Ihr Perl-Skript selbst in UTF-8 codiert ist, muss das Pragma „use utf8“ vorhanden sein
explizit enthalten, um die Erkennung zu ermöglichen (in einer Zeichenfolge oder einem regulären Ausdruck).
Literale oder in Bezeichnernamen). Dieses is einzige Zeit wann an explizit "verwenden utf8"
is Installation! (Siehe utf8).

Mit „BOM“ markierte Skripte und UTF-16-Skripte werden automatisch erkannt
Wenn ein Perl-Skript jedoch mit dem Unicode „BOM“ (UTF-16LE, UTF16-BE oder
UTF-8) oder, wenn das Skript wie nicht mit „BOM“ markiertes UTF-16 mit Endianness aussieht, Perl
wird im Skript korrekt als entsprechende Unicode-Kodierung eingelesen. ("BOM"-weniger
UTF-8 kann nicht effektiv erkannt oder von ISO 8859-1 oder anderen unterschieden werden
Acht-Bit-Kodierungen.)

Byte und Charakter Semantik
Vor Unicode verwendeten die meisten Kodierungen 8 Bit (ein einzelnes Byte) zur Kodierung jedes Zeichens. Daher
Ein Zeichen war ein Byte, und ein Byte war ein Zeichen, und es konnten nur 256 oder weniger sein
mögliche Charaktere. Darauf bezieht sich „Byte-Semantik“ im Titel dieses Abschnitts
Verhalten. Es bestand keine Notwendigkeit, zwischen „Byte“ und „Zeichen“ zu unterscheiden.

Dann kommt Unicode, der Platz für über eine Million Zeichen bietet (und Perl erlaubt).
sogar mehr). Dies bedeutet, dass für die Darstellung eines Zeichens möglicherweise mehr als ein einzelnes Byte erforderlich ist
es, und daher sind die beiden Begriffe nicht mehr gleichwertig. Was zählt, sind die Charaktere als
ganze Entitäten und normalerweise nicht die Bytes, aus denen sie bestehen. Das ist der Begriff
„Zeichensemantik“ im Titel dieses Abschnitts bezieht sich auf.

Perl musste intern ändern, um „Bytes“ von „Zeichen“ zu entkoppeln. Es ist wichtig, dass
Auch Sie ändern Ihre Ideen, falls Sie dies noch nicht getan haben, sodass „Byte“ und „Zeichen“ Nr
bedeutet in deinem Kopf nicht mehr dasselbe.

Der Grundbaustein von Perl-Strings war schon immer ein „Zeichen“. Die Veränderungen
Im Grunde kommt es darauf an, dass die Implementierung nicht mehr davon ausgeht, dass ein Charakter immer vorhanden ist
nur ein einziges Byte.

Es gibt verschiedene Dinge zu beachten:

· String-Handhabungsfunktionen funktionieren größtenteils weiterhin im Sinne von
Figuren. „length()“ gibt beispielsweise die Anzahl der Zeichen in einem String zurück,
genau wie zuvor. Aber diese Zahl ist nicht mehr unbedingt dieselbe wie die Zahl von
Bytes in der Zeichenfolge (es können mehr Bytes als Zeichen sein). Das andere so
Zu den Funktionen gehören „chop()“, „chomp()“, „substr()“, „pos()“, „index()“, „rindex()“,
„sort()“, „sprintf()“ und „write()“.

Die Ausnahmen sind:

· das bitorientierte „vec“

· das byteorientierte „Pack“/„Unpack“-„C“-Format

Allerdings funktioniert der „W“-Bezeichner ebenso wie das „U“ auf ganze Zeichen.
Bezeichner.

· einige Betreiber, die mit dem Betriebssystem der Plattform interagieren

Beispiele hierfür sind Operatoren, die sich mit Dateinamen befassen.

· wenn die Funktionen im Rahmen des Pragmas „use bytes“ aufgerufen werden

Wahrscheinlich sollten Sie dies ohnehin nur zum Debuggen verwenden.

· Zeichenfolgen – einschließlich Hash-Schlüssel – und reguläre Ausdrucksmuster können Zeichen enthalten
die Ordnungswerte größer als 255 haben.

Wenn Sie zum Bearbeiten Ihres Programms einen Unicode-Editor verwenden, können Unicode-Zeichen auftreten
direkt innerhalb der Literalzeichenfolgen in UTF-8-Kodierung oder UTF-16. (Das Vorherige
erfordert eine „BOM“ oder „use utf8“, letzteres erfordert eine „BOM“.)

„Unicode erstellen“ in perluniintro bietet andere Möglichkeiten, Nicht-ASCII-Zeichen einzufügen
Deine Saiten.

· Die Funktionen „chr()“ und „ord()“ funktionieren auf ganzen Zeichen.

· Reguläre Ausdrücke stimmen mit ganzen Zeichen überein. Zum Beispiel, "." passt zu einem Ganzen
Zeichen anstelle nur eines einzelnen Bytes.

· Der Operator „tr///“ übersetzt ganze Zeichen. (Beachten Sie, dass das „tr///CU“
Die Funktionalität wurde entfernt. Eine ähnliche Funktionalität finden Sie unter „pack('U0',
...)“ und „pack('C0', ...)“).

· „scalar reverse()“ kehrt zeichenweise und nicht byteweise um.

· Die Bitfolgenoperatoren „& | ^ ~“ und (ab Version 5.22) „&. |. ^. ~.“ betreiben kann
auf Zeichen, die nicht in ein Byte passen. Das aktuelle Verhalten dürfte jedoch dazu führen
ändern. Sie sollten diese Operatoren nicht für Zeichenfolgen verwenden, die in UTF-8 codiert sind. Wenn
Wenn Sie sich über die Codierung einer Zeichenfolge nicht sicher sind, stufen Sie sie herunter, bevor Sie eine dieser Zeichenfolgen verwenden
Betreiber; Sie können „utf8::utf8_downgrade()“ verwenden.

Das Fazit ist, dass Perl schon immer „Zeichensemantik“ praktiziert hat, aber mit dem
Einführung von Unicode, das unterscheidet sich nun von der „Byte-Semantik“.

ASCII Regeln gegen Unicode Regeln
Vor Unicode, als ein Zeichen ein Byte war, wusste Perl nur von der 128
Durch ASCII definierte Zeichen, Codepunkte 0 bis 127 (außer unter „Gebietsschema verwenden“).
Dadurch waren die Codepunkte 128 bis 255 nicht zugewiesen und für jede beliebige Verwendung verfügbar
Programm möchte möglicherweise. Die einzige Semantik, die sie haben, sind ihre Ordnungszahlen, und das sind sie
sind Mitglieder keiner der nichtnegativen Zeichenklassen. Es wird davon ausgegangen, dass keine davon übereinstimmt
„\w“ zum Beispiel, aber alle stimmen mit „\W“ überein.

Unicode weist natürlich jedem dieser Codepunkte eine bestimmte Bedeutung zu (zusammen mit
diejenigen über 255). Um die Abwärtskompatibilität zu gewährleisten, verwendet Perl nur die Unicode-Bedeutungen
wenn es Anzeichen dafür gibt, dass Unicode beabsichtigt ist; andernfalls das Nicht-ASCII
Codepunkte bleiben so behandelt, als wären sie nicht zugewiesen.

Perl erkennt auf folgende Weise, dass eine Zeichenfolge als Unicode behandelt werden sollte:

· Im Rahmen von „utf8 verwenden“

Wenn das gesamte Programm Unicode ist (gekennzeichnet durch die Verwendung von 8-Bit UNikode TTransformation
Format), dann müssen alle darin enthaltenen Zeichenfolgen Unicode sein.

· Im Rahmen von „Funktion ‚unicode_strings‘ verwenden“

Dieses Pragma wurde erstellt, damit Sie Perl explizit mitteilen können, dass Operationen ausgeführt wurden
Innerhalb seines Geltungsbereichs liegt die Verwendung von Unicode-Regeln. Bei neueren Versionen sind mehr Vorgänge betroffen
Perlen. Siehe „Der „Unicode-Fehler““.

· Im Rahmen von „5.012 verwenden“ oder höher

Dadurch wird implizit „Funktion ‚unicode_strings‘ verwenden“ aktiviert.

· Im Rahmen von „Gebietsschema ‚not_characters‘ verwenden“ oder „Gebietsschema verwenden“ und dem aktuellen
locale ist ein UTF-8-Gebietsschema.

Ersteres ist so definiert, dass es die Unicode-Verarbeitung impliziert; und letzteres weist auf einen Unicode hin
Gebietsschema, daher eine Unicode-Interpretation aller darin enthaltenen Zeichenfolgen.

· Wenn die Zeichenfolge einen Nur-Unicode-Codepunkt enthält

Perl hat niemals Codepunkte über 255 akzeptiert, ohne dass diese Unicode sind und daher verwendet werden
impliziert Unicode für die gesamte Zeichenfolge.

· Wenn die Zeichenfolge einen Unicode-Codepunkt mit dem Namen „\N{...}“ enthält

Das „\N{...}“-Konstrukt verweist explizit auf einen Unicode-Codepunkt, auch wenn es einer ist
das ist auch in ASCII. Daher muss die Zeichenfolge, die es enthält, Unicode sein.

· Wenn die Zeichenfolge von einer externen Quelle stammt, die als Unicode gekennzeichnet ist

Die Befehlszeilenoption „-C“ kann festlegen, dass bestimmte Eingaben in das Programm erfolgen sollen
Unicode, und die Werte davon können von Ihrem Perl-Code gelesen werden, siehe „${^UNICODE}“ in
Perlvar.

· Wenn die Zeichenfolge auf UTF-8 aktualisiert wurde

Die Funktion „utf8::utf8_upgrade()“ kann explizit verwendet werden, um dauerhaft (sofern nicht a
Der nachfolgende Aufruf von „utf8::utf8_downgrade()“ führt dazu, dass ein String als behandelt wird
Unicode.

· Es gibt zusätzliche Methoden für reguläre Ausdrucksmuster

Ein Muster, das mit den Modifikatoren „/u“ oder „/a“ kompiliert wird, wird als Unicode behandelt
(obwohl es einige Einschränkungen mit „/a“ gibt). Unter den Modifikatoren „/d“ und „/l“
es gibt mehrere andere Hinweise auf Unicode; siehe „Zeichensatzmodifikatoren“ in
Perle.

Beachten Sie, dass alle oben genannten Punkte im Rahmen von „Bytes verwenden“ außer Kraft gesetzt werden. aber du solltest
Verwenden Sie dieses Pragma nur zum Debuggen.

Beachten Sie auch, dass einige Interaktionen mit dem Betriebssystem der Plattform niemals Unicode verwenden
Regeln.

Wenn Unicode-Regeln gelten:

· Fallübersetzungsoperatoren verwenden die Unicode-Fallübersetzungstabellen.

Beachten Sie, dass „uc()“ oder „\U“ in interpolierten Zeichenfolgen in Großbuchstaben übersetzt wird, while
„ucfirst“ oder „\u“ in interpolierten Zeichenfolgen wird in Titelbuchstaben in Sprachen übersetzt, die
machen Sie die Unterscheidung (was in Sprachen ohne die Großschreibung entspricht).
Unterscheidung).

Es gibt ein CPAN-Modul, „Unicode::Casing“, mit dem Sie Ihr eigenes Modul definieren können
Zuordnungen, die in „lc()“, „lcfirst()“, „uc()“, „ucfirst()“ und „fc“ (oder deren) verwendet werden sollen
Inline-Versionen mit Zeichenfolgen in doppelten Anführungszeichen wie „\U“). (Vor Perl 5.16 war dies
Die Funktionalität wurde teilweise im Perl-Kern bereitgestellt, litt jedoch unter einer Reihe von Problemen
unüberwindbare Nachteile, daher wurde stattdessen das CPAN-Modul geschrieben.)

· Zeichenklassen in regulären Ausdrücken stimmen basierend auf den Zeicheneigenschaften überein
in der Unicode-Eigenschaftendatenbank angegeben.

„\w“ kann beispielsweise für die Übereinstimmung mit einem japanischen Ideogramm verwendet werden; und „[[:digit:]]“ a
Bengalische Nummer.

· Benannte Unicode-Eigenschaften, Skripte und Blockbereiche können verwendet werden (z. B. in Klammern).
Zeichenklassen) mithilfe des Konstrukts „\p{}“ „matches property“ und des „\P{}“
Verneinung: „stimmt nicht mit der Eigenschaft überein“.

Weitere Einzelheiten finden Sie unter „Eigenschaften von Unicode-Zeichen“.

Sie können Ihre eigenen Zeicheneigenschaften definieren und diese im regulären Ausdruck verwenden
mit dem Konstrukt „\p{}“ oder „\P{}“. Weitere Informationen finden Sie unter „Benutzerdefinierte Zeicheneigenschaften“.
Details.

Verlängert Graphem Cluster (Logisch Figuren)
Betrachten Sie ein Zeichen, sagen Sie „H“. Es könnte mit verschiedenen Markierungen rundherum versehen sein, wie zum Beispiel einem
akuter Akzent oder ein Zirkumflex oder verschiedene Haken, Kreise, Pfeile, usw., oben, unten, bis
die eine oder andere Seite, etc. Es gibt viele Möglichkeiten unter den Sprachen der Welt.
Die Anzahl der Kombinationen ist astronomisch, und wenn es für jede ein Zeichen gäbe
Kombination würde es bald die mehr als eine Million möglicher Zeichen von Unicode erschöpfen. So
Unicode hat einen anderen Ansatz gewählt: Es gibt ein Zeichen für die Basis „H“ und ein Zeichen
für jede der möglichen Markierungen, und diese können vielfältig kombiniert werden, um eine endgültige Logik zu erhalten
Charakter. Ein logisches Zeichen – etwas, das wie ein einzelnes Zeichen erscheint – kann also ein sein
Folge von mehr als einem einzelnen Zeichen. Der Unicode-Standard nennt diese
„erweiterte Graphemcluster“ (eine verbesserte Version des nicht mehr häufig verwendeten
„Graphem-Cluster“); Perl stellt das reguläre Ausdruckskonstrukt „\X“ bereit, das dazu passt
Sequenzen in ihrer Gesamtheit.

Die Absicht von Unicode besteht jedoch darin, die vorhandenen Zeichensatzstandards und -praktiken zu vereinheitlichen
Mehrere bereits existierende Standards haben einzelne Zeichen, die dasselbe bedeuten wie einige von ihnen
diese Kombinationen, wie ISO-8859-1, wo es eine ganze Reihe davon gibt. Zum Beispiel „LATEIN
Der Großbuchstabe „E mit Akute“ war bereits in diesem Standard enthalten, als Unicode auf den Markt kam.
Daher hat Unicode es als einzelnes Zeichen in sein Repertoire aufgenommen. Aber dieser Charakter
wird von Unicode als äquivalent zur Sequenz betrachtet, die aus dem Zeichen besteht
„LATEINISCHER GROSSBUCHSTABE E“, gefolgt vom Zeichen „COMBINING ACUTE ACCENT“.

„LATEINISCHER GROSSBUCHSTABE E MIT AKUTE“ wird als „vorkomponiertes“ Zeichen bezeichnet, und zwar
Die Äquivalenz mit der Sequenz „E“ und „COMBINING ACCENT“ wird als kanonisch bezeichnet
Gleichwertigkeit. Alle vorkomponierten Zeichen sollen eine Zerlegung haben (in die
äquivalente Sequenz), und der Zerlegungstyp wird auch als kanonisch bezeichnet. Eine Zeichenfolge kann
so weit wie möglich aus vorkomponierten Zeichen bestehen, oder es kann aus bestehen
völlig zerlegte Charaktere. Unicode nennt diese jeweils „Normalisierungsform“.
Composed“ (NFC) und „Normalization Form Decomposed“. Das Modul „Unicode::Normalize“.
enthält Funktionen, die zwischen den beiden konvertieren. Eine Zeichenfolge kann auch beides enthalten
Zeichen und zerlegte Zeichen; Dieses Modul kann verwendet werden, um alles zu einem oder mehreren zu machen
anderen.

Möglicherweise werden Ihnen Zeichenfolgen in jeder dieser äquivalenten Formen angezeigt. Gibt es derzeit
nichts in Perl 5, das die Unterschiede ignoriert. Sie müssen es also speziell handhaben.
Der übliche Ratschlag besteht darin, Ihre Eingaben vor der weiteren Verarbeitung in „NFD“ umzuwandeln.

Ausführlichere Informationen finden Sie unterhttp://unicode.org/reports/tr15/>.

Unicode Charakter Ferienhäuser
(Das einzige Mal, dass Perl eine Folge einzelner Codepunkte als einen einzigen betrachtet
Das logische Zeichen befindet sich im oben bereits erwähnten Konstrukt „\X“. Deshalb
„Zeichen“ bedeutet in dieser Diskussion einen einzelnen Unicode-Codepunkt.)

Auf nahezu alle Unicode-Zeicheneigenschaften kann über reguläre Ausdrücke zugegriffen werden
unter Verwendung des Konstrukts „\p{}“ „Matches Property“ und des „\P{}“ „Does’t Match Property“ für
seine Verneinung.

Beispielsweise stimmt „\p{Uppercase}“ mit jedem einzelnen Zeichen mit dem Unicode „Uppercase“ überein.
Eigenschaft, während „\p{L}“ mit jedem Zeichen mit der „General_Category“ von „L“ (Buchstabe) übereinstimmt.
Eigenschaft (siehe „General_Category“ unten). Für einzelne Buchstaben sind keine Klammern erforderlich
Eigenschaftsnamen, daher ist „\p{L}“ äquivalent zu „\pL“.

Formaler ausgedrückt: „\p{Uppercase}“ entspricht jedem einzelnen Zeichen, dessen Unicode „Uppercase“
Der Eigenschaftswert ist „True“ und „\P{Uppercase}“ entspricht jedem Zeichen, dessen „Uppercase“
Der Eigenschaftswert ist „False“ und sie hätten auch als „\p{Uppercase=True}“ geschrieben werden können
„\p{Uppercase=False}“.

Diese Formalität ist erforderlich, wenn Eigenschaften nicht binär sind; das heißt, wenn sie mehr aushalten können
Werte als nur „Wahr“ und „Falsch“. Beispielsweise die Eigenschaft „Bidi_Class“ (siehe
„Bidirektionale Zeichentypen“ weiter unten) kann verschiedene Werte annehmen, z
„Links“, „Rechts“, „Leerzeichen“ und andere. Um diese abzugleichen, muss man beide angeben
Eigenschaftsname („Bidi_Class“) UND der Wert, mit dem abgeglichen wird („Left“, „Right“, usw.).
Dies geschieht, wie in den obigen Beispielen, indem die beiden Komponenten durch ein Gleiches getrennt werden
Zeichen (oder austauschbar ein Doppelpunkt), wie „\p{Bidi_Class: Left}“.

Alle von Unicode definierten Zeicheneigenschaften können in diesen zusammengesetzten Formen geschrieben werden
"\P{Eigenschaft=Wert}" oder "\p{Eigentumswert}", aber Perl bietet einige zusätzliche Eigenschaften
die nur in der Einzelform geschrieben sind, sowie Einzelform-Abkürzungen für alle Binärdateien
Eigenschaften und bestimmte andere unten beschriebene Eigenschaften, in denen Sie den Eigenschaftsnamen und weglassen können
das Gleichheits- oder Doppelpunkttrennzeichen.

Die meisten Unicode-Zeicheneigenschaften haben mindestens zwei Synonyme (oder Aliase, wenn Sie es vorziehen): a
eine kurze, die einfacher zu tippen ist, und eine längere, die aussagekräftiger und daher aussagekräftiger ist
leichter zu verstehen. Somit sind die oben genannten Eigenschaften „L“ und „Buchstabe“ gleichwertig und können
austauschbar verwendet werden. Ebenso ist „Upper“ ein Synonym für „Uppercase“, und das könnten wir auch
habe „\p{Uppercase}“ äquivalent zu „\p{Upper}“ geschrieben. Außerdem gibt es sie typischerweise
verschiedene Synonyme für die Werte, die die Eigenschaft haben kann. Für binäre Eigenschaften hat „True“ den Wert 3
Synonyme: „T“, „Ja“ und „Y“; und „Falsch“ hat entsprechend „F“, „Nein“ und „N“. Aber sei
vorsichtig. Eine Kurzform eines Werts für eine Eigenschaft bedeutet möglicherweise nicht dasselbe
Kurzform für ein anderes. Für die Eigenschaft „General_Category“ bedeutet „L“ also „Buchstabe“,
aber für die Eigenschaft „Bidi_Class“ bedeutet „L“ „Left“. Eine vollständige Liste der Eigenschaften und
Synonyme sind in Perluniprops.

Unterschiede in Groß-/Kleinschreibung bei Eigenschaftsnamen und -werten sind irrelevant; also „\p{Upper}“
bedeutet dasselbe wie „\p{upper}“ oder sogar „\p{UpPeR}“. Ebenso können Sie oder hinzufügen
Subtrahieren Sie Unterstriche irgendwo in der Mitte eines Wortes, damit auch diese gleichwertig sind
zu „\p{U_p_p_e_r}“. Und Leerzeichen neben Nicht-Wort-Zeichen, wie z
als geschweifte Klammern und Gleichheits- oder Doppelpunkttrennzeichen, also „\p{ Upper }“ und „\p{ Upper_case
:Y }" sind ebenfalls äquivalent zu diesen. Tatsächlich können Leerzeichen und sogar Bindestriche dies normalerweise tun
irgendwo hinzugefügt oder gelöscht werden. Also ist sogar „\p{ Up-per case = Yes}“ gleichwertig. All das
wird von Unicode als „lose Übereinstimmung“ bezeichnet. Die wenigen Stellen, an denen eine strengere Übereinstimmung verwendet wird, sind
in der Mitte von Zahlen und in den Perl-Erweiterungseigenschaften, die mit einem beginnen oder enden
unterstreichen. Bei einer strengeren Übereinstimmung werden Leerzeichen berücksichtigt (außer neben Nicht-Wörtern).
Zeichen), Bindestriche und nicht innere Unterstriche.

Sie können die Negation auch sowohl in „\p{}“ als auch in „\P{}“ verwenden, indem Sie dazwischen ein Caretzeichen („^“) einfügen
die erste geschweifte Klammer und der Eigenschaftsname: „\p{^Tamil}“ ist gleich „\P{Tamil}“.

Fast alle Eigenschaften sind immun gegen den Abgleich ohne Berücksichtigung der Groß-/Kleinschreibung. Das heißt, das Hinzufügen eines „/i“
Der Modifikator für reguläre Ausdrücke ändert nicht, was mit ihnen übereinstimmt. Es gibt zwei Sets
betroffen. Der erste Satz ist „Uppercase_Letter“, „Lowercase_Letter“ und
„Titlecase_Letter“, die alle mit „Cased_Letter“ unter „/i“ übereinstimmen. Und der zweite
Die Menge besteht aus „Großbuchstaben“, „Kleinbuchstaben“ und „Titelbuchstaben“, die alle mit „Groß-/Kleinschreibung“ unter „/i“ übereinstimmen.
passend. Diese Menge umfasst auch die Teilmengen „PosixUpper“ und „PosixLower“, die beide vorhanden sind
unter „/i“ entspricht „PosixAlpha“. (Der Unterschied zwischen diesen Sets besteht darin, dass einige Dinge,
B. römische Ziffern, gibt es sowohl in Groß- als auch in Kleinbuchstaben, sodass sie „in Groß- und Kleinschreibung“ geschrieben sind, dies ist jedoch nicht der Fall
werden als Buchstaben betrachtet, sind also nicht „Cased_Letter“.)

Besondere Überlegungen beim Abgleich von Unicode finden Sie unter „Über Unicode-Codepunkte hinaus“.
Eigenschaften gegen Nicht-Unicode-Codepunkte.

Allgemeine_Kategorie

Jedem Unicode-Zeichen ist eine allgemeine Kategorie zugeordnet, die „am häufigsten“ ist
Kategorisierung eines Charakters“ (aushttp://www.unicode.org/reports/tr44>).

Die zusammengesetzte Schreibweise lautet „\p{General_Category=Number}“ (kurz:
„\p{gc:n}“). Aber Perl bietet Abkürzungen, bei denen alles durch das Gleiche oder geht
Das Doppelpunkttrennzeichen wird weggelassen. Sie können also stattdessen einfach „\pN“ schreiben.

Hier sind die Kurz- und Langformen der Werte, die die Eigenschaft „Allgemeine Kategorie“ haben kann:

Kurz lang

L-Buchstabe
LC, L& Cased_Letter (das heißt: [\p{Ll}\p{Lu}\p{Lt}])
Lu-Großbuchstabe
Ll Kleinbuchstabe
Lt Titlecase_Letter
Lm Modifier_Letter
Siehe Other_Letter

M Mark
Mn Nonspacing_Mark
Mc Spacing_Mark
Ich umschließe_Mark

N Nummer
Nd Decimal_Number (auch Ziffer)
Nl Letter_Number
Keine andere_Nummer

P Interpunktion (auch Punct)
PC Connector_Interpunktion
Pd Dash_Punctuation
Ps Open_Punctuation
Pe Close_Punctuation
Pi Initial_Interpunktion
(kann sich je nach Verwendung wie Ps oder Pe verhalten)
Pf Final_Interpunktion
(kann sich je nach Verwendung wie Ps oder Pe verhalten)
Po Other_Punctuation

S-Symbol
Sm Math_Symbol
Sc Währungssymbol
Sk Modifier_Symbol
Also Other_Symbol

Z-Trennzeichen
Zs Space_Separator
Zl Line_Separator
Zp Paragraph_Separator

C Sonstiges
Cc-Steuerung (auch Cntrl)
Siehe Format
Cs-Ersatz
Co Private_Use
Cn Nicht zugewiesen

Einbuchstabige Eigenschaften stimmen mit allen Zeichen in allen aus zwei Buchstaben bestehenden Untereigenschaften überein
beginnend mit demselben Buchstaben. „LC“ und „L&“ sind etwas Besonderes: Beide sind Aliase für die Menge
bestehend aus allem, was mit „Ll“, „Lu“ und „Lt“ übereinstimmt.

bidirektionale Charakter Typen

Weil sich Schriften in ihrer Richtung unterscheiden (Hebräisch und Arabisch werden richtig geschrieben).
links) Unicode stellt eine „Bidi_Class“-Eigenschaft bereit. Einige der Werte dies
Eigentum kann Folgendes haben:

Wertbedeutung

L Von links nach rechts
LRE-Einbettung von links nach rechts
LRO-Override von links nach rechts
R Von rechts nach links
AL Arabischer Buchstabe
RLE-Einbettung von rechts nach links
RLO-Überschreibung von rechts nach links
PDF-Pop-Richtungsformat
EN Europäische Nummer
ES Europäischer Separator
ET Europäischer Terminator
EINE arabische Zahl
Gemeinsames CS-Trennzeichen
NSM Non-Spacing Mark
BN-Grenzneutral
B Absatztrennzeichen
S-Segmenttrenner
WS-Leerzeichen
ON Andere Neutrale

Diese Eigenschaft wird immer in zusammengesetzter Form geschrieben. Beispiel: „\p{Bidi_Class:R}“
Entspricht Zeichen, die normalerweise von rechts nach links geschrieben werden. Im Gegensatz zur „General_Category“
Für diese Eigenschaft können in einer zukünftigen Unicode-Version weitere Werte hinzugefügt werden. Diese
Die oben aufgeführten Versionen umfassten den vollständigen Satz für viele Unicode-Versionen, andere wurden jedoch hinzugefügt
in Unicode 6.3; Sie können immer in Perluniprops finden, was die aktuellen sind. Und
<http://www.unicode.org/reports/tr9/> beschreibt, wie man sie verwendet.

Scripts

Die Sprachen der Welt werden in vielen verschiedenen Schriften geschrieben. Dieser Satz (es sei denn, Sie sind
das Lesen in Übersetzung) ist in Latein verfasst, während Russisch in Kyrillisch verfasst ist, und
Griechisch wird auf Griechisch geschrieben; Japanisch hauptsächlich in Hiragana oder Katakana. Da sind viele
more.

Die Unicode-Eigenschaften „Script“ und „Script_Extensions“ geben an, welches Skript ein bestimmtes Zeichen hat
ist in. Jede Eigenschaft kann mit der zusammengesetzten Form wie „\p{Script=Hebrew}“ angegeben werden.
(kurz: „\p{sc=hebr}“), oder „\p{Script_Extensions=Javanese}“ (kurz: „\p{scx=java}“). In
Darüber hinaus stellt Perl Verknüpfungen für alle „Script“-Eigenschaftsnamen bereit. Kann man weglassen
alles durch das Gleichheitszeichen (oder den Doppelpunkt) hoch und schreiben Sie einfach „\p{Latin}“ oder
„\P{Kyrillisch}“. (Dies gilt nicht für „Script_Extensions“, was erforderlich ist
in zusammengesetzter Form geschrieben.)

Der Unterschied zwischen diesen beiden Eigenschaften besteht darin, dass Zeichen mehrfach verwendet werden
Skripte. Beispielsweise werden in vielen Teilen der Welt die Ziffern „0“ bis „9“ verwendet.
Diese werden in einem Skript mit dem Namen „Common“ abgelegt. Andere Zeichen werden nur in wenigen verwendet
Skripte. Beispielsweise wird in beiden japanischen Sprachen der doppelte Bindestrich „KATAKANA-HIRAGANA“ verwendet
Drehbücher, Katakana und Hiragana, aber nirgendwo sonst. Die Eigenschaft „Script“ platziert alle
Zeichen, die in mehreren Skripten im „Common“-Skript verwendet werden, während die
Die Eigenschaft „Script_Extensions“ platziert diejenigen, die nur in wenigen Skripten verwendet werden, in jedem von ihnen
diese Skripte; während für diejenigen, die in vielen Skripten verwendet werden, immer noch „Common“ verwendet wird. Also beides
Spiel:

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

und nur das erste davon stimmt überein:

"\N{KATAKANA-HIRAGANA DOUBLE HYPHEN}" =~ /\p{sc=Common} # Übereinstimmungen
"\N{KATAKANA-HIRAGANA DOUBLE HYPHEN}" =~ /\p{scx=Common} # Keine Übereinstimmung

Und nur die letzten beiden davon stimmen überein:

"\N{KATAKANA-HIRAGANA DOUBLE HYPHEN}" =~ /\p{sc=Hiragana} # Keine Übereinstimmung
"\N{KATAKANA-HIRAGANA DOUBLE HYPHEN}" =~ /\p{sc=Katakana} # Keine Übereinstimmung
"\N{KATAKANA-HIRAGANA DOUBLE HYPHEN}" =~ /\p{scx=Hiragana} # Übereinstimmungen
"\N{KATAKANA-HIRAGANA DOUBLE HYPHEN}" =~ /\p{scx=Katakana} # Übereinstimmungen

„Script_Extensions“ ist somit ein verbessertes „Script“, in dem weniger Zeichen enthalten sind
im „Common“-Skript und entsprechend mehr in anderen Skripten. Es ist neu in Unicode
Version 6.0, und ihre Daten werden sich in späteren Versionen wahrscheinlich erheblich ändern
geklärt werden. Neuer Code sollte wahrscheinlich „Script_Extensions“ verwenden und nicht einfach sein
"Skript".

(Tatsächlich enthält das Skript „Inherited“ neben „Common“ Zeichen, die in verwendet werden
mehrere Skripte. Dies sind Modifikatorzeichen, die den Skriptwert des erben
kontrollierender Charakter. Einige davon werden in vielen Skripten verwendet und gehen daher in „Geerbt“
sowohl in „Script“ als auch in „Script_Extensions“. Andere werden nur in wenigen Skripten verwendet
in „Inherited“ in „Script“, aber nicht in „Script_Extensions“.)

Es ist erwähnenswert, dass es in Unicode mehrere verschiedene Ziffernsätze gibt
äquivalent zu 0-9 und können durch „\d“ in einem regulären Ausdruck abgeglichen werden. Wenn sie verwendet werden
Nur in einer einzigen Sprache befinden sie sich im „Script“ und in der „Script_Extension“ dieser Sprache. Wenn
Wenn sie in mehr als einem Skript verwendet werden, sind sie in „sc=Common“ enthalten, jedoch nur, wenn dies der Fall ist
Wird in vielen Skripten verwendet, wenn sie in „scx=Common“ vorliegen.

Eine vollständige Liste der Skripte und ihrer Verknüpfungen finden Sie in perluniprops.

Verwenden Sie die of "Ist" Vorsilbe

Aus Gründen der Abwärtskompatibilität (mit Perl 5.6) sind alle Eigenschaften ohne Verwendung von beschreibbar
Bisher erwähnte zusammengesetzte Formen können „Is“ oder „Is_“ vor ihrem Namen haben, also
„\P{Is_Lu}“ ist beispielsweise gleich „\P{Lu}“ und „\p{IsScript:Arabic}“ ist gleich
„\p{Arabisch}“.

Blockiert

Zusätzlich zu den Modi Skripte, Unicode definiert auch Blöcke von Charakteren. Der Unterschied zwischen
Skripte und Blöcke bestehen darin, dass das Konzept der Skripte näher an natürlichen Sprachen liegt
Das Konzept der Blöcke ist eher eine künstliche Gruppierung basierend auf Unicode-Gruppen
Zeichen mit aufeinanderfolgenden Ordnungswerten. Zum Beispiel reicht der Block „Basic Latin“ aus
die Zeichen, deren Ordnungszahlen zwischen 0 und 127 (einschließlich) liegen; mit anderen Worten, das ASCII
Figuren. Die „lateinische“ Schrift enthält einige Buchstaben davon sowie mehrere andere
Blöcke wie „Latin-1 Supplement“, „Latin Extended-A“, usw., aber es enthält nicht alles
die Zeichen aus diesen Blöcken. Es enthält beispielsweise nicht die Ziffern 0-9,
weil diese Ziffern in vielen Skripten gemeinsam verwendet werden und daher im „Common“-Skript enthalten sind.

Weitere Informationen zu Skripten und Blöcken finden Sie unter UAX#24 „Unicode Script Property“:
<http://www.unicode.org/reports/tr24>

Die Eigenschaften „Script“ oder „Script_Extensions“ sind wahrscheinlich diejenigen, die Sie verwenden möchten
bei der Verarbeitung natürlicher Sprache; Die Eigenschaft „Block“ kann gelegentlich nützlich sein
Arbeiten mit den Grundlagen von Unicode.

Blocknamen werden in zusammengesetzter Form abgeglichen, z. B. „\p{Block: Pfeile}“ oder
„\p{Blk=Hebräisch}“. Im Gegensatz zu den meisten anderen Eigenschaften haben nur wenige Blocknamen einen Unicode-
definierter Kurzname. Aber Perl bietet eine (kleine, nicht mehr empfohlene) Abkürzung:
Sie können zum Beispiel „\p{In_Arrows}“ oder „\p{In_Hebrew}“ sagen.

Aus Gründen der Abwärtskompatibilität kann das Präfix „In“ weggelassen werden, wenn kein Namenskonflikt besteht
mit einem Skript oder einer anderen Eigenschaft, und Sie können in diesen sogar ein „Is“-Präfix verwenden
Fälle. Tun Sie dies jedoch nicht für neuen Code, da Ihr Code in neuen Versionen kaputt gehen könnte
Dies ist bereits geschehen: In sehr frühen Unicode-Versionen gab es eine Zeit, in der
„\p{Hebräisch}“ hätte mit dem gepasst Schutzmassnahmen bei Hebräisch; jetzt ist es nicht mehr so.

Durch die Verwendung des Präfixes „In“ wird diese Mehrdeutigkeit bisher vermieden. Aber es gibt weiterhin neue Versionen von Unicode
um neue Eigenschaften hinzuzufügen, deren Namen mit „In“ beginnen. Es besteht die Möglichkeit, dass einer von
Sie werden eines Tages mit Ihrer Nutzung in Konflikt geraten. Da dies nur eine Perl-Erweiterung ist,
Der Name von Unicode hat Vorrang und Ihr Code wird fehlerhaft. Auch Unicode ist
Es steht Ihnen frei, ein Skript hinzuzufügen, dessen Name mit „In“ beginnt. das würde Probleme machen.

Daher ist es klarer und am besten, bei der Angabe von Blöcken die zusammengesetzte Form zu verwenden. Und seien Sie sicher
Das ist es, was du wirklich wirklich tun willst. In den meisten Fällen sind Skripte das, was Sie wollen
stattdessen.

Eine vollständige Liste der Blöcke und ihrer Verknüpfungen finden Sie in perluniprops.

Andere Ferienhäuser

Es gibt viel mehr Eigenschaften als die hier beschriebenen sehr grundlegenden. Eine vollständige Liste
ist in Perluniprops.

Unicode definiert alle seine Eigenschaften in zusammengesetzter Form, also auch alle Eigenschaften in Einzelform
Perl-Erweiterungen. Die meisten davon sind nur Synonyme für die Unicode-Namen, einige jedoch auch
echte Erweiterungen, darunter mehrere, die in zusammengesetzter Form vorliegen. Und einige davon
Diese werden tatsächlich von Unicode empfohlen (inhttp://www.unicode.org/reports/tr18>).

Dieser Abschnitt enthält einige Details zu allen Erweiterungen, die nicht nur Synonyme für zusammengesetzt sind.
bilden Unicode-Eigenschaften (für diese Eigenschaften müssen Sie sich auf Unicode beziehen
Standardhttp://www.unicode.org/reports/tr44>.

"\Leichentuch}"
Dies entspricht jedem möglichen Codepunkt. Es entspricht „qr/./s“. Im Gegensatz zu allen
Wenn andere nicht benutzerdefinierte „\p{}“-Eigenschaften übereinstimmen, wird in diesem Fall nie eine Warnung generiert
Diese Eigenschaft wird mit einem Nicht-Unicode-Codepunkt abgeglichen (siehe „Über Unicode-Code hinaus“)
Punkte" weiter unten).

"\p{Alnum}"
Dies entspricht jedem „\p{Alphabetic}“- oder „\p{Decimal_Number}“-Zeichen.

"\p{Beliebig}"
Dies entspricht einem der Unicode-Codepunkte 1_114_112. Es ist ein Synonym für
„\p{Unicode}“.

"\p{ASCII}"
Dies entspricht einem der 128 Zeichen im US-ASCII-Zeichensatz, also einem
Teilmenge von Unicode.

"\p{Zugewiesen}"
Dies entspricht jedem zugewiesenen Codepunkt; das heißt, jeder Codepunkt, dessen allgemeine Kategorie
ist nicht „Nicht zugewiesen“ (oder entsprechend nicht „Cn“).

"\p{Leerzeichen}"
Dies ist dasselbe wie „\h“ und „\p{HorizSpace}“: Ein Zeichen, das den Abstand ändert
horizontal.

"\p{Decomposition_Type: Nicht-kanonisch}" (Kurzform: „\p{Dt=NonCanon}“)
Entspricht einem Zeichen, das eine nicht-kanonische Zerlegung aufweist.

Im Abschnitt „Erweiterte Graphemcluster (logische Zeichen)“ oben wurde darüber gesprochen
kanonische Zerlegungen. Allerdings haben viele weitere Charaktere einen anderen Typ
Zerlegung, eine „kompatible“ oder „nicht-kanonische“ Zerlegung. Die Sequenzen, die
In dieser Form gelten diese Zerlegungen nicht als kanonisch äquivalent zu den vorläufigen Zerlegungen.
komponierter Charakter. Ein Beispiel ist das „SUPERSCRIPT ONE“. Es ist so etwas wie ein
reguläre Ziffer 1, aber nicht genau; seine Zerlegung in die Ziffer 1 heißt a
„kompatible“ Zerlegung, insbesondere eine „Super“-Zerlegung. Es gibt einige
solche Kompatibilitätszerlegungen (vglhttp://www.unicode.org/reports/tr44>),
einschließlich eines namens „compat“, was eine andere Art der Zerlegung bedeutet
das passt nicht in die anderen Zerlegungskategorien, die Unicode ausgewählt hat.

Beachten Sie, dass die meisten Unicode-Zeichen keine Zerlegung haben, also ihre Zerlegung
Typ ist „Keine“.

Der Einfachheit halber hat Perl den Zerlegungstyp „Non_Canonical“ zu „mean“ hinzugefügt
eine der verschiedenen Kompatibilitätszerlegungen.

"\p{Grafik}"
Entspricht jedem grafischen Zeichen. Theoretisch bedeutet dies einen Charakter, der auf
Ein Drucker würde dazu führen, dass Tinte verbraucht wird.

"\p{HorizSpace}"
Dies ist dasselbe wie „\h“ und „\p{Blank}“: ein Zeichen, das den Abstand ändert
horizontal.

"\p{In=*}"
Dies ist ein Synonym für „\p{Present_In=*}“

"\p{PerlSpace}"
Dies ist dasselbe wie „\s“, beschränkt auf ASCII, nämlich „[ \f\n\r\t]“ und beginnt in
Perl v5.18, eine vertikale Registerkarte.

Mnemonik: Perls (ursprünglicher) Raum

"\p{PerlWord}"
Dies ist dasselbe wie „\w“, beschränkt auf ASCII, nämlich „[A-Za-z0-9_]“.

Mnemonik: Perls (ursprüngliches) Wort.

"\p{Posix...}"
Es gibt mehrere davon, die Äquivalente sind und die Notation „\p{}“ verwenden, z
Posix-Klassen und werden unter „POSIX-Zeichenklassen“ in perlrecharclass beschrieben.

"\p{Present_In: *}" (Kurzform: „\p{In=*}“)
Diese Eigenschaft wird verwendet, wenn Sie wissen müssen, welche Unicode-Version(en) ein Zeichen hat.

Das „*“ oben steht für eine zweistellige Unicode-Versionsnummer, z. B. 1.1 oder 4.0; oder
das „*“ kann auch „Nicht zugewiesen“ sein. Diese Eigenschaft stimmt mit den Codepunkten überein, deren
Die endgültige Entscheidung wurde ab der von der Version angegebenen Unicode-Freigabe getroffen
Nummer; „\p{Present_In: Unassigned}“ stimmt mit den Codepunkten überein, deren Bedeutung hat
noch zu vergeben.

Beispielsweise war „U+0041“ „lateinischer Großbuchstabe A“ im allerersten Unicode vorhanden
Die verfügbare Version ist 1.1, daher gilt diese Eigenschaft für alle gültigen „*“-Versionen.
Andererseits wurde „U+1EFF“ erst in Version 5.1 zugewiesen, als es zu „LATIN“ wurde
KLEINBUCHSTABE Y MIT SCHLEIFE“, also sind die einzigen „*“, die dazu passen würden, 5.1, 5.2 und
später.

Unicode stellt die Eigenschaft „Alter“ bereit, von der dies abgeleitet wird. Das Problem mit dem Alter
ist, dass eine strenge Interpretation davon (die Perl annimmt) dazu führt, dass es mit dem Präzisen übereinstimmt
Mit „Release“ wird die Bedeutung eines Codepunkts eingeführt. Somit würde „U+0041“ nur mit 1.1 übereinstimmen;
und „U+1EFF“ nur 5.1. Das ist normalerweise nicht das, was Sie wollen.

Einige Nicht-Perl-Implementierungen der Age-Eigenschaft ändern möglicherweise ihre Bedeutung in die
Identisch mit der Perl-Eigenschaft „Present_In“; Sei dir dessen einfach bewusst.

Eine weitere Verwirrung bei diesen beiden Eigenschaften besteht darin, dass die Definition nicht so lautet
Codepunkt war zugewiesen, aber die Bedeutung des Codepunkts war
entschlossen. Dies liegt daran, dass 66 Codepunkte immer nicht zugewiesen sind und daher
„Alter“ ist für sie die Unicode-Version, in der die Entscheidung getroffen wurde, sie so zu gestalten.
Beispielsweise soll „U+FDD0“ einem Charakter und der Entscheidung dauerhaft nicht mehr zugewiesen werden
Dies wurde in Version 3.1 vorgenommen, sodass „\p{Age=3.1}“ auch mit diesem Zeichen übereinstimmt
macht „\p{Present_In: 3.1}“ und höher.

"\p{Drucken}"
Dies entspricht jedem grafischen oder leeren Zeichen, mit Ausnahme von Steuerelementen.

"\p{SpacePerl}"
Dies ist dasselbe wie „\s“, auch außerhalb von ASCII.

Mnemonik: Leerzeichen, wie von Perl modifiziert. (Die vertikale Registerkarte ist erst enthalten
v5.18, den sowohl der Posix-Standard als auch Unicode als Leerzeichen betrachten.)

"\p{Titel}" und "\p{Titelfall}"
Beim Abgleich unter Berücksichtigung der Groß- und Kleinschreibung stimmen beide mit denselben Codepunkten überein wie „\p{General
Category=Titlecase_Letter}“ („\p{gc=lt}“). Der Unterschied besteht darin, dass unter „/i“ die Groß-/Kleinschreibung nicht berücksichtigt wird
Bei der Übereinstimmung stimmen diese mit „\p{Cased}“ überein, während „\p{gc=lt}“ mit „\p{gc=lt}“ übereinstimmt
„\p{Cased_Letter“).

"\p{Unicode}"
Dies entspricht einem der Unicode-Codepunkte 1_114_112. „\p{Any}“.

"\p{VertSpace}"
Dies ist dasselbe wie „\v“: Ein Zeichen, das den Abstand vertikal ändert.

"\p{Wort}"
Dies ist dasselbe wie „\w“, einschließlich über 100_000 Zeichen außerhalb von ASCII.

"\p{XPosix...}"
Es gibt mehrere davon, bei denen es sich um die vollständig erweiterten Standard-Posix-Klassen handelt
Unicode-Bereich. Sie werden unter „POSIX-Zeichenklassen“ in perlrecharclass beschrieben.

Benutzerdefinierte Charakter Ferienhäuser
Sie können Ihre eigenen Binärzeicheneigenschaften definieren, indem Sie Unterprogramme mit Namen definieren
beginnen mit „In“ oder „Is“. (Die experimentelle Funktion „(?[ ])“ in Perle bietet eine
Alternative, die komplexere Definitionen ermöglicht.) Die Unterprogramme können in beliebiger Form definiert werden
Paket. Die benutzerdefinierten Eigenschaften können im regulären Ausdruck „\p{}“ und verwendet werden
„\P{}“ konstruiert; wenn Sie eine benutzerdefinierte Eigenschaft aus einem anderen Paket als dem verwenden
eines, in dem Sie sich befinden, müssen Sie dessen Paket im Konstrukt „\p{}“ oder „\P{}“ angeben.

# vorausgesetzt, dass die Eigenschaft Is_Foreign in Lang: definiert ist:
Paket main; # Eigenschaftspaketname erforderlich
if ($txt =~ /\p{Lang::IsForeign}+/) { ... }

Paket Lang; # Name des Eigenschaftspakets nicht erforderlich
if ($txt =~ /\p{IsForeign}+/) { ... }

Beachten Sie, dass der Effekt zur Kompilierungszeit gilt und unveränderlich ist, sobald er definiert ist. Allerdings sind die Unterprogramme
wird ein einzelner Parameter übergeben, der 0 ist, wenn die Groß-/Kleinschreibung berücksichtigt wird und nicht
Null, wenn caseless Matching aktiv ist. Das Unterprogramm kann unterschiedliche Werte zurückgeben
Abhängig vom Wert des Flags ist ein Satz von Werten unveränderlich gültig
alle Übereinstimmungen, bei denen die Groß-/Kleinschreibung beachtet wird, und der andere Satz gilt für alle Übereinstimmungen, bei denen die Groß-/Kleinschreibung nicht beachtet wird.

Beachten Sie, dass Perl stirbt, wenn der reguläre Ausdruck fehlerhaft ist, anstatt den aufzurufen
Unterprogramm, wenn der Name des Unterprogramms durch die fehlerhaften Daten bestimmt wird.

Die Unterprogramme müssen eine speziell formatierte Zeichenfolge mit einem oder mehreren Zeilenumbrüchen zurückgeben.
getrennte Zeilen. Jede Zeile muss eine der folgenden sein:

· Eine einzelne Hexadezimalzahl, die einen einzuschließenden Codepunkt angibt.

· Zwei hexadezimale Zahlen, getrennt durch horizontales Leerzeichen (Leerzeichen oder tabellarisch).
Zeichen), die einen Bereich von einzuschließenden Codepunkten bezeichnen.

· Etwas, das eingefügt werden soll, mit dem Präfix „+“: eine integrierte Zeicheneigenschaft (mit dem Präfix „
„utf8::“) oder ein vollständig qualifiziertes (einschließlich Paketname) benutzerdefiniertes Zeichen
Eigenschaft, um alle Zeichen in dieser Eigenschaft darzustellen; zwei Hexadezimalcodes
Punkte für einen Bereich; oder ein einzelner hexadezimaler Codepunkt.

· Etwas, das ausgeschlossen werden soll, mit dem Präfix „-“: eine vorhandene Zeicheneigenschaft (mit dem Präfix „.“)
„utf8::“) oder ein vollständig qualifiziertes (einschließlich Paketname) benutzerdefiniertes Zeichen
Eigenschaft, um alle Zeichen in dieser Eigenschaft darzustellen; zwei Hexadezimalcodes
Punkte für einen Bereich; oder ein einzelner hexadezimaler Codepunkt.

· Etwas, das negiert werden soll, mit dem Präfix „!“: eine vorhandene Zeicheneigenschaft (mit dem Präfix „!“)
„utf8::“) oder ein vollständig qualifiziertes (einschließlich Paketname) benutzerdefiniertes Zeichen
Eigenschaft, um alle Zeichen in dieser Eigenschaft darzustellen; zwei Hexadezimalcodes
Punkte für einen Bereich; oder ein einzelner hexadezimaler Codepunkt.

· Etwas, mit dem man sich überschneiden kann, mit dem Präfix „&“: eine vorhandene Zeicheneigenschaft (mit dem Präfix „&“)
durch „utf8::“) oder ein vollständig qualifiziertes (einschließlich Paketname) benutzerdefiniertes Zeichen
Eigenschaft, für alle Zeichen außer den Zeichen in der Eigenschaft; zwei
Hexadezimale Codepunkte für einen Bereich; oder ein einzelner hexadezimaler Codepunkt.

Um beispielsweise eine Eigenschaft zu definieren, die beide japanischen Silben (Hiragana und
Katakana), können Sie definieren

sub InKana {
Rückkehr <
3040\t309F
30A0\t30FF
ENDE
}

Stellen Sie sich vor, dass sich die Endmarkierung „here-doc“ am Anfang der Zeile befindet. Jetzt können Sie es verwenden
„\p{InKana}“ und „\P{InKana}“.

Sie hätten auch die vorhandenen Blockeigenschaftsnamen verwenden können:

sub InKana {
return <<'END';
+utf8::InHiragana
+utf8::InKatakana
ENDE
}

Angenommen, Sie möchten nur die zugewiesenen Zeichen abgleichen, nicht die Rohblockbereiche: in
Mit anderen Worten, Sie möchten die nicht zugewiesenen Zeichen entfernen:

sub InKana {
return <<'END';
+utf8::InHiragana
+utf8::InKatakana
-utf8::IsCn
ENDE
}

Die Negation ist nützlich, um (Überraschung!) negierte Klassen zu definieren.

sub InNotKana {
return <<'END';
!utf8::InHiragana
-utf8::InKatakana
+utf8::IsCn
ENDE
}

Dadurch werden alle Nicht-Unicode-Codepunkte abgeglichen, da sich nicht alle davon in Kana befinden. Du
Sie können diese bei Bedarf mit der Schnittmenge ausschließen, wie dieses modifizierte Beispiel zeigt:

sub InNotKana {
return <<'END';
!utf8::InHiragana
-utf8::InKatakana
+utf8::IsCn
&utf8::Any
ENDE
}

&utf8::Any muss die letzte Zeile in der Definition sein.

Schnittmenge wird im Allgemeinen verwendet, um die gemeinsamen Zeichen zu erhalten, die mit zwei (oder mehr) übereinstimmen.
Klassen. Es ist wichtig, daran zu denken, für den ersten Satz nicht „&“ zu verwenden; das wäre
schneidet sich mit nichts, was zu einer leeren Menge führt.

Im Gegensatz zu nicht benutzerdefinierten „\p{}“-Eigenschaftsübereinstimmungen wird in diesem Fall nie eine Warnung generiert
Eigenschaften werden mit einem Nicht-Unicode-Codepunkt abgeglichen (siehe „Über Unicode-Codepunkte hinaus“)
unten).

Benutzerdefinierte Referenzen Mappings (Für ernst Hacker nur)
Dieses -Funktion hat war entfernt as of Perl 5.16 Das CPAN-Modul „Unicode::Casing“ bietet
bessere Funktionalität ohne die Nachteile, die diese Funktion hatte. Wenn Sie ein Perl verwenden
Vor 5.16 wurde diese Funktion am ausführlichsten in der 5.14-Version dieses Pods dokumentiert:
<http://perldoc.perl.org/5.14.0/perlunicode.html#User-Defined-Case-Mappings-%28for-serious-hackers-only%29>

Charakter Codierungen für Eingang und Ausgang
Siehe Kodieren.

Unicode Normale Ausdruck Unterstützung Niveau
Die folgende Liste der von Unicode unterstützten Funktionen für reguläre Ausdrücke beschreibt alle
Funktionen, die derzeit direkt vom Perl-Kern unterstützt werden. Die Verweise auf „Level N“ und die
Abschnittsnummern beziehen sich auf den Unicode Technical Standard Nr. 18, „Unicode Regular“.
Expressions“, Version 13, vom August 2008.

· Level 1 – Grundlegende Unicode-Unterstützung

RL1.1 Hex-Notation – erledigt [1]
RL1.2-Eigenschaften – erledigt [2][3]
RL1.2a-Kompatibilitätseigenschaften – erledigt [4]
RL1.3 Subtraktion und Schnittmenge – experimentell [5]
RL1.4 Einfache Wortgrenzen – erledigt [6]
RL1.5 Einfache lose Übereinstimmungen – erledigt [7]
RL1.6 Liniengrenzen – FEHLEND [8][9]
RL1.7 Ergänzende Codepunkte – erledigt [10]

[1] „\N{U+...}“ und „\x{...}“
[2] "\p{...}" "\P{...}"
[3] unterstützt nicht nur die Minimalliste, sondern alle Unicode-Zeicheneigenschaften (siehe Unicode
Zeicheneigenschaften oben)
[4] "\d" "\D" "\s" "\S" "\w" "\W" "\X" "[:Stütze:]" „[:^prop:]“
[5] Die experimentelle Funktion ab Version 5.18 „(?[...])“ erreicht dies.
Siehe „(?[ ])“ in Perle. Wenn Sie keine experimentelle Funktion verwenden möchten, können Sie dies tun
Verwenden Sie eines der folgenden:

· Vorausschau auf reguläre Ausdrücke

Sie können die Klassensubtraktion mithilfe von Lookahead nachahmen. Zum Beispiel was UTS#18
könnte schreiben als

[{Block=Griechisch}-[{UNASSIGNED}]]

kann in Perl wie folgt geschrieben werden:

(?!\p{Nicht zugewiesen})\p{Block=Griechisch}
(?=\p{Zugewiesen})\p{Block=Griechisch}

Aber in diesem speziellen Beispiel möchten Sie es wahrscheinlich wirklich

\p{Griechisch}

Dies entspricht den zugewiesenen Zeichen, von denen bekannt ist, dass sie Teil der griechischen Schrift sind.

· CPAN-Modul „Unicode::Regex::Set“

Es implementiert die vollständige UTS#18-Gruppierung, Schnittmenge, Vereinigung und Entfernung
(Subtraktions-)Syntax.

· „Benutzerdefinierte Zeicheneigenschaften“

„+“ für Vereinigung, „-“ für Entfernung (Satzdifferenz), „&“ für Schnittmenge

[6] „\b“ „\B“
[7] Beachten Sie, dass Perl beim Matching eine vollständige Fallfaltung durchführt, nicht Simple:
Beispielsweise entspricht „U+1F88“ „U+1F00 U+03B9“ und nicht nur „U+1F80“.
Dieser Unterschied ist hauptsächlich für bestimmte griechische Großbuchstaben mit bestimmten wichtig
Modifikatoren: Die vollständige Groß-/Kleinschreibung zerlegt den Buchstaben, während die einfache Groß-/Kleinschreibung den Buchstaben zerlegt.
Falten würde es einem einzelnen Zeichen zuordnen.

[8] Perl behandelt „\n“ als Start- und Endzeilentrennzeichen. Unicode spezifiziert mehr
Zeichen, die so interpretiert werden sollten.
Diese sind:

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

„^“ und „$“ in regulären Ausdrucksmustern sollen mit all diesen übereinstimmen, aber
nicht. Diese Zeichen haben auch keinen Einfluss auf „<>“ $. und die Skriptzeile, sollten dies aber tun
Zahlen.

Außerdem sollten Zeilen innerhalb von „CRLF“ nicht geteilt werden (d. h. es darf keine Leerzeile dazwischen sein).
„\r“ und „\n“). Versuchen Sie für „CRLF“ die Ebene „:crlf“ (siehe PerlIO).

[9] Aber „Unicode::LineBreak“ ist verfügbar.
Dieses Modul liefert Zeilenumbrüche gemäß UAX#14 „Unicode Line Breaking“.
Algorithmus"http://www.unicode.org/reports/tr14>.

[10] UTF-8/UTF-EBDDIC, das in Perl verwendet wird, erlaubt nicht nur „U+10000“ bis „U+10FFFF“, sondern auch
jenseits von „U+10FFFF“
· Level 2 – Erweiterte Unicode-Unterstützung

RL2.1 Kanonische Äquivalente – FEHLT [10][11]
RL2.2 Standard-Graphem-Cluster – FEHLT [12]
RL2.3 Standard-Wortgrenzen – FERTIG [14]
RL2.4 Standardlose Übereinstimmungen – FEHLT [15]
RL2.5-Namenseigenschaften – FERTIG
RL2.6-Platzhaltereigenschaften – FEHLT

[10] siehe UAX#15 „Unicode-Normalisierungsformen“
[11] haben Unicode::Normalize, sind aber nicht in reguläre Ausdrücke integriert
[12] haben \X und \b{gcb}, aber wir haben keinen „Grapheme-Cluster“.
Modus"
[14] siehe UAX#29, Wortgrenzen
[15] Dies wird in Kapitel 3.13 (in Unicode 6.0) behandelt.

· Level 3 – Maßgeschneiderte Unterstützung

RL3.1 Maßgeschneiderte Zeichensetzung – FEHLT
RL3.2 Maßgeschneiderte Graphemcluster – FEHLT [17][18]
RL3.3 Maßgeschneiderte Wortgrenzen – FEHLT
RL3.4 Maßgeschneiderte lose Streichhölzer – FEHLT
RL3.5 Maßgeschneiderte Sortimente – FEHLT
RL3.6 Kontextabgleich – FEHLT [19]
RL3.7 Inkrementelle Übereinstimmungen – FEHLT
(RL3.8 Unicode-Set-Freigabe)
RL3.9 Mögliche Match-Sets – FEHLT
RL3.10 Gefaltete Zuordnung – FEHLT [20]
RL3.11 Submatcher – FEHLT

[17] siehe UAX#10 „Unicode Collation Algorithms“
[18] haben Unicode::Collate, sind aber nicht in reguläre Ausdrücke integriert
[19] haben (?<=x) und (?=x), aber Look-Aheads oder Look-Behinds
sollte außerhalb der Zielteilzeichenfolge angezeigt werden
[20] benötigen einen unempfindlichen Abgleich für andere sprachliche Merkmale
als Fall; zum Beispiel Hiragana bis Katakana, breit und
schmales, vereinfachtes Han zu traditionellem Han (siehe UTR#30).
„Charakterfaltungen“)

Unicode Codierungen
Unicode-Zeichen werden zugewiesen Code Punkte, das sind abstrakte Zahlen. Um diese zu nutzen
Für Zahlen sind verschiedene Kodierungen erforderlich.

· UTF-8

UTF-8 ist eine Codierung mit variabler Länge (1 bis 4 Bytes) und unabhängiger Bytereihenfolge. In den meisten
In der Perl-Dokumentation, auch an anderer Stelle in diesem Dokument, bedeutet der Begriff „UTF-8“.
auch „UTF-EBCDIC“. In diesem Abschnitt bezieht sich „UTF-8“ jedoch nur auf die verwendete Kodierung
ASCII-Plattformen. Es ist eine Obermenge des 7-Bit-US-ASCII, also alles, was in ASCII codiert ist
die identische Darstellung bei Codierung in UTF-8.

Die folgende Tabelle stammt aus Unicode 3.2.

Codepunkte 1. Byte 2. Byte 3. Byte 4. Byte

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 +++++ utf16-Ersatzzeichen, nicht zulässiges 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

Beachten Sie die mit „*“ gekennzeichneten Lücken vor mehreren der oben genannten Byteeinträge. Diese sind
verursacht durch legales UTF-8, das nichtkürzeste Kodierungen vermeidet: Dies ist technisch möglich
UTF-8-kodieren Sie einen einzelnen Codepunkt auf unterschiedliche Weise, aber das ist ausdrücklich verboten.
und es sollte immer die kürzestmögliche Codierung verwendet werden (und genau das tut Perl).

Eine andere Möglichkeit, es zu betrachten, sind Bits:

Codepunkte 1. Byte 2. Byte 3. Byte 4. Byte

0aaaaaaa 0aaaaaaa
00000bbbbbaaaaaa 110bbbbb 10aaaaaa
ccccbbbbbbaaaaaa 1110cccc 10bbbbbb 10aaaaaa
00000dddccccccbbbbbbaaaaaa 11110ddd 10cccccc 10bbbbbb 10aaaaaa

Wie Sie sehen können, beginnen die Fortsetzungsbytes alle mit „10“ und die führenden Bits von
Das Startbyte gibt an, wie viele Bytes das codierte Zeichen enthält.

Die ursprüngliche UTF-8-Spezifikation erlaubte bis zu 6 Bytes, um die Kodierung von Zahlen zu ermöglichen
bis zu „0x7FFF_FFFF“. Perl lässt diese weiterhin zu und hat sie auf bis zu 13 erweitert
Bytes zum Codieren von Codepunkten bis zu dem, was in ein 64-Bit-Wort passt. Perl wird es jedoch tun
warnen Sie, wenn Sie eines davon als nicht portierbar ausgeben; und unter strikter UTF-8-Eingabe
Protokolle, sie sind verboten.

· UTF-EBCDIC

Wie UTF-8, aber EBCDIC-sicher, so wie UTF-8 ASCII-sicher ist. Das bedeutet, dass alle
die Grundzeichen (einschließlich aller Zeichen, die ASCII-Äquivalente haben (wie „A“,
„0“, „%“, usw.) sind in EBCDIC und UTF-EBCDIC gleich.)

UTF-EBCDIC wird auf EBCDIC-Plattformen verwendet. Die größten Unicode-Codepunkte benötigen 5 Bytes
darzustellen (anstelle von 4 in UTF-8), und Perl erweitert es auf maximal 7 Bytes
encode zeigt bis zu dem an, was in ein 32-Bit-Wort passen kann (anstelle von 13 Bytes und a
64-Bit-Wort in UTF-8).

· UTF-16, UTF-16BE, UTF-16LE, Surrogate und „BOM“s (Byte Order Marks)

Die folgenden Elemente dienen hauptsächlich als Referenz und allgemeine Unicode-Kenntnisse, Perl
verwendet diese Konstrukte nicht intern.

Wie UTF-8 ist UTF-16 eine Codierung mit variabler Breite, wobei UTF-8 jedoch 8-Bit-Code verwendet
UTF-16 verwendet 16-Bit-Codeeinheiten. Alle Codepunkte belegen entweder 2 oder 4 Bytes
UTF-16: Codepunkte „U+0000..U+FFFF“ werden in einer einzigen 16-Bit-Einheit und Code gespeichert
Punkte „U+10000..U+10FFFF“ in zwei 16-Bit-Einheiten. Der letztere Fall ist die Verwendung Leihmütterchen,
Die erste 16-Bit-Einheit ist die Highs Surrogat, und das zweite ist das niedrig
Surrogat.

Surrogate sind Codepunkte, die für die Codierung des Bereichs „U+10000..U+10FFFF“ reserviert sind
Unicode-Codepunkte in Paaren von 16-Bit-Einheiten. Der Highs Leihmütterchen sind die Reichweite
„U+D800..U+DBFF“ und die niedrig Leihmütterchen sind der Bereich „U+DC00..U+DFFF“. Der Ersatz
Kodierung ist

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

und die Dekodierung ist

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

Aufgrund der 16-Bit-Größe ist UTF-16 von der Bytereihenfolge abhängig. UTF-16 selbst kann verwendet werden
für In-Memory-Berechnungen, aber wenn Speicherung oder Übertragung erforderlich ist, entweder UTF-16BE
Es müssen die Kodierungen UTF-16LE (Big-Endian) oder UTF-XNUMXLE (Little-Endian) gewählt werden.

Dies führt zu einem weiteren Problem: Was ist, wenn Sie nur wissen, dass Ihre Daten UTF-16 sind, aber
Sie wissen nicht, welche Endianness? Byte Order Marks oder „BOM“s sind eine Lösung dafür
Das. In Unicode wurde ein Sonderzeichen reserviert, das als Bytereihenfolge fungiert
Marker: Das Zeichen mit dem Codepunkt „U+FEFF“ ist das „BOM“.

Der Trick besteht darin, dass Sie beim Lesen einer „BOM“ die Byte-Reihenfolge kennen, denn wenn dies der Fall wäre
Auf einer Big-Endian-Plattform geschrieben, lesen Sie die Bytes „0xFE 0xFF“, aber wenn ja
Auf einer Little-Endian-Plattform geschrieben, lesen Sie die Bytes „0xFF 0xFE“. (Und wenn die
Da die ursprüngliche Plattform in der ASCII-Plattform UTF-8 schrieb, lesen Sie die Bytes
„0xEF 0xBB 0xBF“.)

Dieser Trick funktioniert so, dass das Zeichen mit dem Codepunkt „U+FFFE“ keinen hat
sollte in Eingabeströmen enthalten sein, daher ist die Bytefolge „0xFF 0xFE“ eindeutig
„„Stückliste“, dargestellt im Little-Endian-Format“ und kann nicht „U+FFFE“ sein, dargestellt in
Big-Endian-Format".

Ersatzzeichen haben in Unicode keine Bedeutung außer ihrer paarweisen Verwendung zur Darstellung anderer
Codepunkte. Perl erlaubt jedoch, dass sie intern einzeln dargestellt werden, z
Beispiel mit den Worten „chr(0xD801)“, so dass alle Codepunkte, nicht nur die gültigen für
offener Austausch, darstellbar sind. Unicode definiert die Semantik für sie, z
ihre „General_Category“ ist „Cs“. Aber weil ihre Verwendung etwas gefährlich ist, Perl
wird warnen (unter Verwendung der Warnkategorie „surrogate“, die eine Unterkategorie von „utf8“ ist)
wenn versucht wird, beispielsweise die Kleinschreibung von Eins zu übernehmen oder die Groß-/Kleinschreibung abzugleichen-
unempfindlich zu machen oder auszugeben. (Versuchen Sie dies jedoch nicht mit Perls vor 5.14.)

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

Die UTF-32-Familie ähnelt im Großen und Ganzen der UTF-16-Familie, außer dass die Einheiten es sind
32-Bit, daher ist das Ersatzschema nicht erforderlich. UTF-32 ist eine feste Breite
Codierung. Die „BOM“-Signaturen lauten „0x00 0x00 0xFE 0xFF“ für BE und „0xFF 0xFE 0x00“.
0x00" für LE.

· UCS-2, UCS-4

Ältere Kodierungen mit fester Breite, die durch den ISO 10646-Standard definiert sind. UCS-2 ist ein 16-Bit
Codierung. Im Gegensatz zu UTF-16 ist UCS-2 nicht über „U+FFFF“ hinaus erweiterbar, da dies nicht der Fall ist
Verwenden Sie Ersatzzeichen. UCS-4 ist eine 32-Bit-Kodierung, die funktional mit UTF-32 (dem
Der Unterschied besteht darin, dass UCS-4 weder Ersatzzeichen noch Codepunkte größer als verbietet
„0x10_FFFF“).

· UTF-7

Eine sichere XNUMX-Bit-Kodierung (nicht XNUMX-Bit), die beim Transport oder bei der Speicherung nützlich ist
ist nicht 2152-Bit-sicher. Definiert durch RFC XNUMX.

Nichtcharakter Code Punkte
66 Codepunkte werden in Unicode als „Nicht-Zeichen-Codepunkte“ reserviert. Diese haben alle das
„Nicht zugewiesen“ („Cn“) „General_Category“, und es wird niemals ein Zeichen einer dieser Kategorien zugewiesen
ihnen. Dies sind die 32 Codepunkte zwischen „U+FDD0“ und „U+FDEF“ einschließlich und die 34
Codepunkte:

U+FFFE U+FFFF
U+1FFFE U+1FFFF
U+2FFFE U+2FFFF
...
U+EFFFE U+EFFFF
U+FFFFE U+FFFFF
U+10FFFE U+10FFFF

Bis Unicode 7.0 waren die Nichtzeichen „verboten zur Verwendung im offenen Austausch von
Unicode-Textdaten“, sodass Code, der diese Streams verarbeitet, diese Codepunkte verwenden kann
als Wächter, die mit Charakterdaten vermischt werden könnten und dies auch immer tun würden
von diesen Daten unterscheidbar. (Hervorhebungen oben und im nächsten Absatz werden hinzugefügt
dieses Dokument.)

Unicode 7.0 hat den Wortlaut geändert, so dass sie „nicht empfohlen für den Einsatz im Freien
Austausch von Unicode-Textdaten". Im 7.0-Standard heißt es weiter:

„Wenn ein Nichtcharakter im offenen Austausch empfangen wird, ist kein Antrag erforderlich
interpretieren Sie es in irgendeiner Weise. Es empfiehlt sich jedoch, es als zu erkennen
Nichtzeichen und entsprechende Maßnahmen zu ergreifen, z. B. durch „U+FFFD“ zu ersetzen.
Ersatzzeichen, um das Problem im Text anzuzeigen. Es wird nicht empfohlen
Löschen Sie aufgrund des Potenzials einfach Codepunkte, die keine Zeichen sind, aus einem solchen Text
Sicherheitsprobleme, die durch das Löschen nicht interpretierter Zeichen verursacht werden. (Siehe Konformitätsklausel
C7 in Abschnitt 3.2, Konformitätsanforderungen, und Unicode Technical Report #36,
"Überlegungen zur Unicode-Sicherheit"
<http://www.unicode.org/reports/tr36/#Substituting_for_Ill_Formed_Subsequences>).“

Diese Änderung wurde vorgenommen, weil festgestellt wurde, dass verschiedene kommerzielle Tools wie Editoren oder
für Dinge wie die Quellcodeverwaltung, wurden so geschrieben, dass sie nicht funktionieren würden
Programmdateien, die diese Codepunkte verwendeten, wodurch ihre Verwendung praktisch ausgeschlossen wird
vollständig! Und das war nie die Absicht. Sie waren schon immer dazu gedacht, im Inneren verwendbar zu sein
eine Anwendung oder einen kooperierenden Satz von Anwendungen nach Belieben.

Wenn Sie Code schreiben, z. B. einen Editor, sollte dieser mit allem umgehen können
Wenn Sie Unicode-Textdaten verwenden, sollten Sie diese Codepunkte nicht selbst verwenden, sondern stattdessen
Erlauben Sie sie in der Eingabe. Wenn Sie Wächter benötigen, sollten diese stattdessen etwas sein
ist kein legaler Unicode. Für UTF-8-Daten können Sie die Bytes 0xC1 und 0xC2 als Sentinels verwenden
Sie erscheinen nie in wohlgeformtem UTF-8. (Es gibt Äquivalente für UTF-EBCDIC). Du kannst
Speichern Sie Ihre Unicode-Codepunkte auch in ganzzahligen Variablen und verwenden Sie negative Werte als
Wächter.

Wenn Sie kein solches Tool schreiben, bleibt es Ihnen überlassen, ob Sie Nichtzeichen als Eingabe akzeptieren
Sie (obwohl der Standard empfiehlt, dies nicht zu tun). Wenn Sie eine strenge Überprüfung des Eingabestreams durchführen
Bei Perl sind diese Codepunkte weiterhin verboten. Dies dient dazu, rückwärts zu bleiben
Kompatibilität (andernfalls könnten sich potenzielle Sicherheitslücken auftun, wie ein ahnungsloser
Anwendung, die unter der Annahme geschrieben wurde, dass die Nichtzeichen zuvor herausgefiltert wurden
Wenn ich dazu komme, könnte ich jetzt ohne Vorwarnung damit beginnen, sie zu bekommen). Um eine strenge Kontrolle durchzuführen,
Sie können die Ebene „:encoding('UTF-8')“ verwenden.

Perl warnt weiterhin (unter Verwendung der Warnkategorie „nonchar“, die eine Unterkategorie von ist
„utf8“), wenn versucht wird, Nichtzeichen auszugeben.

Darüber Hinaus Unicode Code Punkte
Der maximale Unicode-Codepunkt ist „U+10FFFF“, und Unicode definiert nur Operationen für Code
weist darauf hin. Aber Perl arbeitet mit Codepunkten bis zum maximal zulässigen Wert
unsignierte Nummer auf der Plattform verfügbar. Perl akzeptiert diese jedoch nicht von der Eingabe
Streams, sofern nicht laxe Regeln verwendet werden, und warnt (unter Verwendung der Warnungskategorie).
„non_unicode“, eine Unterkategorie von „utf8“), falls vorhanden, werden ausgegeben.

Da für diese Codepunkte keine Unicode-Regeln definiert sind, handelt es sich um eine durch Unicode definierte Operation
wird mit ihnen gemacht, Perl verwendet, was wir für sinnvoll halten, während es im Allgemeinen warnt:
Verwendung der Kategorie „non_unicode“. Beispielsweise generiert „uc(“\x{11_0000}“)“ so etwas
Warnung, die den Eingabeparameter als Ergebnis zurückgibt, da Perl den Großbuchstaben von definiert
Jeder Nicht-Unicode-Codepunkt soll der Codepunkt selbst sein. (Alle Fälle ändern sich
Operationen, nicht nur Großbuchstaben, funktionieren auf diese Weise.)

Die Situation mit übereinstimmenden Unicode-Eigenschaften in regulären Ausdrücken, den „\p{}“ und
„\P{}“-Konstrukte, gegen diese Codepunkte ist nicht so eindeutig, und wie diese sind
Die Handhabung hat sich mit der gesammelten Erfahrung verändert.

Eine Möglichkeit besteht darin, jede Übereinstimmung mit diesen Codepunkten als undefiniert zu behandeln. Aber seit
Perl kennt das Konzept einer undefinierten Übereinstimmung nicht, es wandelt dies in fehlschlagen oder um
"FALSCH". Dies ist fast, aber nicht ganz, was Perl ab Version 5.14 getan hat (bei Verwendung dieses Codes).
Punkte wurden allgemein zuverlässig) bis v5.18. Der Unterschied besteht darin, dass Perl alles behandelt hat
„\p{}“ gilt als fehlgeschlagen, aber alle „\P{}“ gelten als erfolgreich.

Ein Problem dabei ist, dass es zu unerwarteten und in manchen Fällen verwirrenden Ergebnissen führt
Fälle:

chr(0x110000) =~ \p{ASCII_Hex_Digit=True} # Fehlgeschlagen auf <= v5.18
chr(0x110000) =~ \p{ASCII_Hex_Digit=False} # Fehlgeschlagen! auf <= v5.18

Das heißt, beide Übereinstimmungen wurden als undefiniert behandelt und in „false“ konvertiert (was einen Fehler auslöste).
Warnung auf jedem). Der erste Fall ist das erwartete Ergebnis, der zweite Fall ist wahrscheinlich
kontraintuitiv: „Wie könnten beide falsch sein, wenn sie Komplemente sind?“ Ein weiteres Problem
war, dass die Implementierung viele Unicode-Eigenschaftsübereinstimmungen bereits optimiert hat
vorhandene einfachere und schnellere Vorgänge, die die Warnung nicht auslösen. Wir haben uns entschieden, nicht darauf zu verzichten
Diese Optimierungen, die bei der überwiegenden Mehrheit der Übereinstimmungen hilfreich sind, dienen lediglich dazu, eine Warnung zu generieren
für den unwahrscheinlichen Fall, dass ein Codepunkt oberhalb von Unicode abgeglichen wird.

Aufgrund dieser Probleme behandelt Perl ab Version 5.20 Nicht-Unicode
Codepunkte werden nur als typische nicht zugewiesene Unicode-Zeichen dargestellt und entsprechend abgeglichen.
(Hinweis: Unicode verfügt über atypische nicht zugewiesene Codepunkte. Beispielsweise verfügt es über Code, der kein Zeichen ist
Punkte, und solche, die, wenn sie tatsächlich vergeben werden, dazu bestimmt sind, direkt geschrieben zu werden.
links, wie Arabisch und Hebräisch. Perl geht davon aus, dass kein Nicht-Unicode-Codepunkt welche hat
atypische Eigenschaften.)

Perl gibt in den meisten Fällen eine Warnung aus, wenn ein Codepunkt oberhalb von Unicode gefunden wird
gegen eine Unicode-Eigenschaft, wenn das Ergebnis „TRUE“ für „\p{}“ und „FALSE“ für „\P{}“ ist.
Beispielsweise:

chr(0x110000) =~ \p{ASCII_Hex_Digit=True} # Schlägt fehl, keine Warnung
chr(0x110000) =~ \p{ASCII_Hex_Digit=False} # Erfolgreich, mit Warnung

In beiden Beispielen handelt es sich bei dem abgeglichenen Zeichen um kein Unicode-Zeichen, daher ist dies bei Unicode nicht der Fall
Definieren Sie, wie es zusammenpassen soll. Es handelt sich eindeutig nicht um eine ASCII-Hexadezimalzahl, also das erste Beispiel
sollte offensichtlich scheitern, und das passiert auch, ohne Vorwarnung. Aber es ist fraglich, ob das zweite
Beispiel sollte ein undefiniertes, daher „FALSE“ Ergebnis haben. Daher wird eine Warnung ausgesprochen.

Daher wird die Warnung in viel weniger Fällen als in früheren Perls ausgegeben und nur dann, wenn was
Das Ergebnis ist fraglich. Es stellt sich heraus, dass keine der von Perl vorgenommenen Optimierungen vorliegt
(oder werden wahrscheinlich jemals gemacht) führen dazu, dass die Warnung übersprungen wird, sodass beide Probleme behoben werden
Probleme von Perls früherem Ansatz. Die am häufigsten genutzte Eigenschaft, die davon betroffen ist
Diese Änderung ist „\p{Unassigned}“, was eine Kurzform für ist
„\p{General_Category=Nicht zugewiesen}“. Ab v5.20 gilt dies für alle Nicht-Unicode-Codepunkte
als „Nicht zugewiesen“ betrachtet. In früheren Versionen schlugen die Übereinstimmungen fehl, da das Ergebnis falsch war
als undefiniert angesehen.

Die einzige Stelle, an der die Warnung nicht ausgesprochen wird, obwohl sie hätte sein sollen, ist, wenn
Optimierungen führen dazu, dass der gesamte Mustervergleich gar nicht erst versucht wird. Zum Beispiel Perl
kann herausfinden, dass eine Zeichenfolge mit einem bestimmten regulären Ausdrucksmuster übereinstimmt
muss den Teilstring „foobar“ enthalten. Bevor Perl das Match versucht, sucht er möglicherweise nach
dieser Teilstring, und wenn er nicht gefunden wird, schlägt die Übereinstimmung sofort fehl, ohne es tatsächlich zu versuchen;
Daher wird keine Warnung generiert, selbst wenn die Zeichenfolge einen Codepunkt oberhalb von Unicode enthält.

Dieses Verhalten ist für die meisten Anwendungen eher „Tue, was ich meine“ als in früheren Perls. Aber
Bei Code, der strikt Unicode-kompatibel sein muss, treten weniger Probleme auf. Deshalb
Für diesen Code steht ein zusätzlicher Betriebsmodus zur Verfügung. Dieser Modus ist
aktiviert, wenn ein reguläres Ausdrucksmuster innerhalb des lexikalischen Bereichs kompiliert wird, in dem die
Die Warnklasse „non_unicode“ wurde schwerwiegend gemacht, beispielsweise durch:

Warnungen verwenden FATAL => "non_unicode"

(siehe Warnungen). In diesem Betriebsmodus löst Perl die Warnung für alle Übereinstimmungen aus
gegen einen Nicht-Unicode-Codepunkt (nicht nur die umstrittenen) und überspringt den
Optimierungen, die dazu führen können, dass die Warnung nicht ausgegeben wird. (Aktuell ist das immer noch nicht der Fall
warnt, wenn die Übereinstimmung noch nicht einmal versucht wird, wie im „foobar“-Beispiel oben.)

Zusammenfassend lässt sich sagen, dass Perl Nicht-Unicode-Codepunkte jetzt normalerweise als typische, nicht zugewiesene Unicode-Codepunkte behandelt
Codepunkte für Übereinstimmungen mit regulären Ausdrücken, die nur dann eine Warnung auslösen, wenn sie vertretbar sind
was das Ergebnis sein soll. Wenn diese Warnung jedoch schwerwiegend war, ist sie es nicht
übersprungen.

Von all dem gibt es eine Ausnahme. „\p{All}“ sieht aus wie eine Unicode-Eigenschaft, ist aber eine
Perl-Erweiterung, die für alle möglichen Codepunkte, Unicode oder nicht, als wahr definiert ist
Es wird nie eine Warnung generiert, wenn dies mit einem Nicht-Unicode-Codepunkt abgeglichen wird. (Frühere
bis Version 5.20 war es ein genaues Synonym für „\p{Any}“ und entsprach den Codepunkten 0 bis 0x10FFFF.)

Sicherheit Folgen of Unicode
Lesen Sie zunächst Überlegungen zur Unicode-Sicherheithttp://www.unicode.org/reports/tr36>.

Beachten Sie außerdem Folgendes:

· Fehlerhaftes UTF-8

Leider lässt die ursprüngliche Spezifikation von UTF-8 einiges an Interpretationsspielraum
wie viele Bytes codierter Ausgabe man aus einer Unicode-Eingabe generieren sollte
Charakter. Streng genommen sollte die kürzestmögliche Folge von UTF-8-Bytes sein
generiert, da andernfalls die Gefahr eines Eingangspufferüberlaufs besteht
Empfangsende einer UTF-8-Verbindung. Perl generiert immer UTF-8 mit der kürzesten Länge.
und wenn Warnungen aktiviert sind, warnt Perl unter anderem vor UTF-8 mit nicht kürzester Länge
Fehlbildungen, wie z. B. die Surrogate, für die es sich nicht um gültige Unicode-Codepunkte handelt
Austausch.

· Der Mustervergleich mit regulären Ausdrücken kann Sie überraschen, wenn Sie nicht damit vertraut sind
Unicode. Ab Perl 5.14 stehen mehrere Mustermodifikatoren zur Steuerung zur Verfügung
Dies wird als Zeichensatzmodifikator bezeichnet. Einzelheiten finden Sie im Abschnitt „Zeichensatz“.
Modifikatoren" in Perle.

Wie an anderer Stelle besprochen, hat Perl jeweils einen Fuß (zwei Hufe?) in zwei Welten gepflanzt: der
alte Welt der ASCII- und Einzelbyte-Gebietsschemas und die neue Welt von Unicode, Upgrade wann
notwendig. Wenn Ihr Legacy-Code Unicode nicht explizit verwendet, erfolgt keine automatische Umstellung
auf Unicode sollte passieren.

Unicode in Perl on EBCDIC
Unicode wird auf EBCDIC-Plattformen unterstützt. Siehe perlebcdic.

Sofern ASCII vs. EBCDIC-Probleme nicht ausdrücklich diskutiert werden, beziehen sich Verweise auf UTF-8
Die Kodierung in diesem Dokument und anderswo sollte als UTF-EBCDIC auf EBCDIC verstanden werden
Plattformen. Siehe „Unicode und UTF“ in perlebcdic.

Da UTF-EBCDIC UTF-8 so ähnlich ist, bleiben Ihnen die Unterschiede größtenteils verborgen.
„Use utf8“ (und NICHT so etwas wie „Use utfebcdic“) deklariert, dass sich das Skript im befindet
Die „native“ 8-Bit-Codierung von Unicode der Plattform. (Ähnliches gilt für die Ebene „:utf8“.)

Lokal
Siehe „Unicode und UTF-8“ in perllocale

Wann Unicode Beeinflusst die Sie hilft nicht nur Passieren
Es gibt immer noch viele Stellen, an denen Unicode (in der einen oder anderen Codierung) als angegeben werden könnte
Argumente oder als Ergebnisse empfangen, oder beides in Perl, ist es aber nicht, obwohl Perl es hat
umfangreiche Möglichkeiten zur Ein- und Ausgabe in Unicode und einige andere „Einstiegspunkte“ wie die
@ARGV-Array (das manchmal als UTF-8 interpretiert werden kann).

Im Folgenden sind solche Schnittstellen aufgeführt. Siehe auch „Der „Unicode-Fehler““. Für all das
Schnittstellen Perl übernimmt derzeit (ab v5.16.0) einfach beide Byte-Strings als Argumente
und Ergebnisse oder UTF-8-Strings, wenn das (veraltete) „encoding“-Pragma verwendet wurde.

Ein Grund dafür, dass Perl in diesen Situationen nicht versucht, die Rolle von Unicode aufzuklären
ist, dass die Antworten stark vom Betriebssystem und den Dateisystemen abhängen.
Beispielsweise, ob Dateinamen in Unicode vorliegen können und in welcher Kodierung genau
nicht gerade ein tragbares Konzept. Ähnliches gilt für „qx“ und „system“: Wie gut wird das?
„Befehlszeilenschnittstelle“ (und welche davon?) verarbeiten Unicode?

· „chdir“, „chmod“, „chown“, „chroot“, „exec“, „link“, „lstat“, „mkdir“, „rename“,
„rmdir“, „stat“, „symlink“, „truncate“, „unlink“, „utime“, „-X“

· %ENV

· „glob“ (auch bekannt als „<*>“)

· „open“, „opendir“, „sysopen“

· „qx“ (auch bekannt als Backtick-Operator), „system“

· „readdir“, „readlink“

Die „Unicode Insekt"
Der Begriff „Unicode-Fehler“ wurde für eine Inkonsistenz mit den Codepunkten in verwendet
„Latin-1 Supplement“-Block, also zwischen 128 und 255. Ohne Angabe eines Gebietsschemas,
Im Gegensatz zu allen anderen Zeichen oder Codepunkten können diese Zeichen sehr unterschiedlich sein
Semantik abhängig von den geltenden Regeln. (Zeichen, deren Codepunkte über 255 liegen
Unicode-Regeln erzwingen; wohingegen die Regeln für ASCII-Zeichen unter beiden ASCII-Zeichen gleich sind
und Unicode-Regeln.)

Nach den Unicode-Regeln werden diese Großlatein1-Zeichen als Unicode-Codepunkte interpretiert.
Das bedeutet, dass sie dieselbe Semantik wie Latin-1- (ISO-8859-1) und C1-Steuerelemente haben.

Wie in „ASCII-Regeln im Vergleich zu Unicode-Regeln“ erläutert, werden sie unter ASCII-Regeln berücksichtigt
um nicht zugewiesene Zeichen zu sein.

Dies kann zu unerwarteten Ergebnissen führen. Beispielsweise kann die Semantik einer Zeichenfolge plötzlich auftreten
ändern, wenn ein Codepunkt über 255 daran angehängt wird, wodurch die Regeln von ASCII in geändert werden
Unicode. Betrachten Sie als Beispiel das folgende Programm und seine Ausgabe:

$ perl -le'
keine Funktion 'unicode_strings';
$s1 = "\xC2";
$s2 = "\x{2660}";
für ($s1, $s2, $s1.$s2) {
print /\w/ || 0;
}
'
0
0
1

Wenn es weder in „s1“ noch in „s2“ ein „\w“ gibt, warum hat ihre Verkettung dann eines?

Diese Anomalie rührt von Perls Versuch her, ältere Programme, die nicht verwendet wurden, nicht zu stören
Unicode, zusammen mit Perls Wunsch, die Unicode-Unterstützung nahtlos hinzuzufügen. Aber das Ergebnis
Es stellte sich heraus, dass es nicht nahtlos war. (Übrigens können Sie festlegen, dass Sie in solchen Fällen gewarnt werden möchten
Dies geschieht. Siehe „encoding::warnings“.)

„Use feature ‚unicode_strings‘“ wurde ab Perl v5.12 hinzugefügt, um dieses Problem zu beheben
Problem. Es betrifft diese Dinge:

· Ändern der Groß-/Kleinschreibung eines Skalars, d. h. Verwendung von „uc()“, „ucfirst()“, „lc()“ und
„lcfirst()“ oder „\L“, „\U“, „\u“ und „\l“ in Kontexten mit doppelten Anführungszeichen, wie z. B. „regular“.
Ausdrucksersetzungen.

Unter „unicode_strings“ werden ab Perl 5.12.0 im Allgemeinen Unicode-Regeln verwendet.
Einzelheiten dazu, wie dies in Kombination mit verschiedenen anderen funktioniert, finden Sie unter „lc“ in perlfunc
Pragmen.

· Verwendung des Vergleichs regulärer Ausdrücke ohne Groß-/Kleinschreibung („/i“).

Ab Perl 5.14.0 werden reguläre Ausdrücke im Rahmen von kompiliert
„unicode_strings“ verwenden Unicode-Regeln, auch wenn sie ausgeführt oder zu größeren regulären Strings kompiliert werden
Ausdrücke außerhalb des Gültigkeitsbereichs.

· Übereinstimmung mit einer von mehreren Eigenschaften in regulären Ausdrücken.

Diese Eigenschaften sind „\b“ (ohne geschweifte Klammern), „\B“ (ohne geschweifte Klammern), „\s“, „\S“, „\w“,
„\W“ und alle Posix-Zeichenklassen ausgeschlossen "[[:ASCII:]]".

Ab Perl 5.14.0 werden reguläre Ausdrücke im Rahmen von kompiliert
„unicode_strings“ verwenden Unicode-Regeln, auch wenn sie ausgeführt oder zu größeren regulären Strings kompiliert werden
Ausdrücke außerhalb des Gültigkeitsbereichs.

· In „quotemeta“ oder seinem Inline-Äquivalent „\Q“.

Ab Perl 5.16.0 werden im Rahmen von konsistente Anführungszeichenregeln verwendet
„unicode_strings“, wie in „quotemeta“ in perlfunc beschrieben. Davor oder draußen
In seinem Umfang werden keine Codepunkte über 127 in UTF-8-codierten Zeichenfolgen angegeben, sondern in Byte
Bei codierten Zeichenfolgen werden Codepunkte zwischen 128 und 255 immer in Anführungszeichen gesetzt.

Aus dem Obigen können Sie ersehen, dass die Wirkung von „unicode_strings“ über mehrere Jahre zugenommen hat
Perl-Veröffentlichungen. (Und Perls Unterstützung für Unicode verbessert sich weiter; am besten verwenden Sie die
neueste verfügbare Version, um möglichst vollständige und genaue Ergebnisse zu erhalten.)
Beachten Sie, dass „unicode_strings“ automatisch ausgewählt wird, wenn Sie „5.012“ oder höher verwenden.

Für frühere Perls als die oben beschriebenen oder wenn eine Zeichenfolge an eine Funktion übergeben wird
außerhalb des Geltungsbereichs von „unicode_strings“, siehe nächster Abschnitt.

Zwingen Unicode in Perl (Oder Entzwingend Unicode in Perl)
Manchmal (siehe „Wenn Unicode nicht auftritt“ oder „Der „Unicode-Fehler“) gibt es Situationen
Hier müssen Sie lediglich eine Bytezeichenfolge in UTF-8 erzwingen oder umgekehrt. Der Standard
Hierzu kann das Modul Encode verwendet werden, oder die Low-Level-Aufrufe „utf8::upgrade($bytestring)“
und „utf8::downgrade($utf8string[, FAIL_OK])“.

Beachten Sie, dass „utf8::downgrade()“ fehlschlagen kann, wenn die Zeichenfolge Zeichen enthält, die nicht passen
in ein Byte.

Das Aufrufen einer Funktion für eine Zeichenfolge, die sich bereits im gewünschten Zustand befindet, ist ein No-Op.

„ASCII-Regeln im Vergleich zu Unicode-Regeln“ zeigt alle Möglichkeiten, wie eine Zeichenfolge zur Verwendung von Unicode erstellt wird
Regeln.

Die richtigen Unicode in XS
Eine Einführung in Unicode auf XS-Ebene finden Sie unter „Unicode-Unterstützung“ in perlguts
„Unicode-Unterstützung“ in Perlapi für die API-Details.

Hacking Perl zu Arbeit on früher Unicode Versionen (Für sehr ernst Hacker nur)
Perl ist standardmäßig mit der neuesten unterstützten Unicode-Version ausgestattet, aber das Ziel ist es
damit Sie auf eine frühere Version umsteigen können. In Perls v5.20 und v5.22 jedoch
Die früheste verwendbare Version ist Unicode 5.1. Perl v5.18 kann alles früher verarbeiten
Versionen.

Laden Sie die Dateien in der gewünschten Unicode-Version von der Unicode-Website herunter
<http://www.unicode.org>). Diese sollten die vorhandenen Dateien in ersetzen lib/unicore begann
Perl-Quellbaum. Befolgen Sie die Anweisungen in README.perl in diesem Verzeichnis, um einige zu ändern
ihrer Namen, und bauen Sie dann Perl (siehe INSTALL).

Portierung Code für perl-5.6.X
Perls ab 5.8 haben ein anderes Unicode-Modell als 5.6. In 5.6 war der Programmierer
Es ist erforderlich, das Pragma „utf8“ zu verwenden, um zu deklarieren, dass ein bestimmter Bereich voraussichtlich damit umgehen soll
Unicode-Daten und musste sicherstellen, dass nur Unicode-Daten diesen Bereich erreichten. Wenn du
Wenn Sie Code haben, der mit 5.6 funktioniert, müssen Sie einige der folgenden Anpassungen vornehmen
dein Code. Die Beispiele sind so geschrieben, dass der Code auch unter 5.6 weiterhin funktioniert
Sie sollten sicher sein, sie auszuprobieren.

· Ein Dateihandle, das UTF-8 lesen oder schreiben sollte

if ($] > 5.008) {
binmode $fh, „:encoding(utf8)“;
}

· Ein Skalar, der an eine Erweiterung übergeben wird

Sei es „Compress::Zlib“, „Apache::Request“ oder eine beliebige Erweiterung, die nicht erwähnt wird
Wenn Sie in der Manpage Unicode verwenden, müssen Sie sicherstellen, dass das UTF8-Flag entfernt ist. Notiz
dass die genannten Module zum Zeitpunkt des Verfassens dieses Artikels (Januar 2012) nicht vorhanden sind
UTF-8-fähig. Bitte überprüfen Sie die Dokumentation, um zu überprüfen, ob dies immer noch der Fall ist.

if ($] > 5.008) {
codieren erforderlich;
$val = Encode::encode_utf8($val); # Oktette erstellen
}

· Ein Skalar, den wir von einer Erweiterung zurückbekommen haben

Wenn Sie glauben, dass der Skalar als UTF-8 zurückkommt, möchten Sie höchstwahrscheinlich die UTF8-Flagge
restauriert:

if ($] > 5.008) {
codieren erforderlich;
$val = Encode::decode_utf8($val);
}

· Das Gleiche gilt, wenn Sie wirklich sicher sind, dass es sich um UTF-8 handelt

if ($] > 5.008) {
codieren erforderlich;
Encode::_utf8_on($val);
}

· Ein Wrapper für DBI „fetchrow_array“ und „fetchrow_hashref“

Wenn die Datenbank nur UTF-8 enthält, ist eine Wrapper-Funktion oder -Methode eine praktische Möglichkeit
um alle Ihre „fetchrow_array“- und „fetchrow_hashref“-Aufrufe zu ersetzen. Eine Wrapper-Funktion
erleichtert auch die Anpassung an zukünftige Erweiterungen Ihres Datenbanktreibers. Notiz
dass das DBI zum Zeitpunkt des Schreibens dieses Artikels (Januar 2012) über keine standardisierte Methode verfügt
Umgang mit UTF-8-Daten. Bitte überprüfen Sie die DBI-Dokumentation, um zu überprüfen, ob dies weiterhin der Fall ist
wahr.

sub fetchrow {
# $was ist eines von fetchrow_{array,hashref}
my($self, $sth, $what) = @_;
if ($] < 5.008) {
return $sth->$what;
} Else {
codieren erforderlich;
if (wantarray) {
my @arr = $sth->$what;
für (@arr) {
definiert && /[^\000-\177]/ && Encode::_utf8_on($_);
}
return @arr;
} Else {
my $ret = $sth->$what;
if (ref $ret) {
für meine $k (Tasten %$ret) {
definiert
&& /[^\000-\177]/
&& Encode::_utf8_on($_) for $ret->{$k};
}
return $ret;
} Else {
definiert && /[^\000-\177]/ && Encode::_utf8_on($_) für $ret;
return $ret;
}
}
}
}

· Ein großer Skalar, von dem Sie wissen, dass er nur ASCII enthalten kann

Skalare, die nur ASCII enthalten und als UTF-8 gekennzeichnet sind, sind manchmal eine Belastung für Sie
Programm. Wenn Sie eine solche Situation erkennen, entfernen Sie einfach das UTF8-Flag:

utf8::downgrade($val) wenn $] > 5.008;

Verwenden Sie Perlunicode online über die Dienste von onworks.net