Python-Semantik für Unicode-Bereiche mit astralen Ebenen

Question

Was genau ist die beabsichtigte Semantik für Zeichenbereiche in regulären Ausdrücken, wenn einer oder beide Endpunkte des Bereichs außerhalb des BMP liegen? Ich habe beobachtet, dass die folgende Eingabe in Python 2.7 und 3.5 anders verhält:

import re 
bool(re.match(u"[\u1000-\U00021111]", "\u1234")) 

In meinem 2.7 ich False, in 3.5 ich True. Letzteres macht für mich Sinn. Ersteres ist vielleicht auf \U00021111 zurückzuführen, das durch ein Ersatzpaar \ud844\udd11 dargestellt wird, aber selbst dann verstehe ich es nicht, da \u1234 gerade in Ordnung sein sollte.

• Ist das irgendwo angegeben?
• Ist das beabsichtigte Verhalten?
• Hängt dies nur von der Python-Version ab, oder auch von Kompilierzeit-Flags bezüglich UTF-16 vs. UTF-32?
• Gibt es eine Möglichkeit, konsistentes Verhalten ohne Fallunterscheidungen zu erhalten?
• Wenn Fallunterscheidungen unvermeidlich sind, was genau sind die Bedingungen?

Answer 1

Verwenden Sie einfach den u Präfix mit dem Eingabestring Python zu sagen, es ist ein Unicode-String:

>>> bool(re.match(u"[\u1000-\U00021111]", u"\u1234")) # <= See u"\u1234" 
True 

In Python 2.7, müssen Sie die Zeichenfolge in Unicode jedes Mal, wenn sie verarbeiten entschlüsseln. In Python 3 sind alle Zeichenfolgen standardmäßig Unicode und in der docs angegeben.

Answer 2

Hier ist, was ich bisher herausgefunden habe.

PEP 261 die für Python 2.2 akzeptiert wurde eingeführt ein Kompilierzeit-Flag zum Erstellen von Unicode-Unterstützung entweder mit einer schmalen UTF-16-Darstellung oder eine breite UTF-32-Darstellung von Zeichen. Überprüfen Sie hex(sys.maxunicode) oder len(u'\U00'), um diese zur Laufzeit zu unterscheiden: schmale Builds melden maximal 0xffff und eine Länge von 2, breite bildet ein Maximum von 0x10ffff und eine Länge von 1. für Python 3.3 verbirgt die Implementierungsdetails einer Unicode-Zeichenkette, wodurch alle Zeichenketten wie UTF-32 erscheinen (ohne wirklich viel Platz zu verschwenden, wenn es nicht notwendig ist). So werden schmale Builds vor 3.3 Codepunkte auf Astralebenen in Surrogatpaare zerlegen und die einzelnen Surrogate unabhängig sowohl für die Konstruktion des regulären Ausdrucks als auch für die zu vergleichende Zeichenkette behandeln. Zumindest konnte ich keinen Hinweis auf das Gegenteil finden.

Wie Wiktor darauf hinwies, war mein Beispiel einfach dumm, da ich das u Präfix für das zweite String-Literal vergessen hatte. Daher wird Python 2 dies nicht als Escape-Sequenz sondern als Byte-String analysieren. Dies erklärt, warum es so aussah, als ob der Codepunkt selbst nach der Berücksichtigung von Ersatzpaaren nicht in diesem Bereich enthalten wäre.

Wie für das beabsichtigte Verhalten: Seit Python 3.3 sollte die Unterscheidung nach Build-Typ obsolet werden. Das Behandeln jedes Codepunkts als Einheit, unabhängig von der Ebene, sollte für Python 3 der richtige Weg sein. Die Abwärtskompatibilität bei Narrow-Builds stellt jedoch ein Konfliktziel für ältere Versionen dar.