Unicode-Eigenschaften

Die Unicode-Eigenschaften werden mit den kurzen Namen wie \p{Lu} benannt (siehe dazu die Tabelle Grundlegende Unter-Eigenschaften in Unicode). Bei einbuchstabigen Namen von Unicode-Eigenschaften kann man die geschweiften Klammern weglassen: \pL ist das Gleiche wie \p{L}. Die langen Namen wie beispielsweise \p{Lowercase_Letter} werden nicht unterstützt.

In Java 1.5 und davor wurden die Eigenschaften Pi und Pf nicht unterstützt, konsequenterweise wurden Zeichen mit diesen Eigenschaften durch \p{P} nicht erkannt. Seit Java 1.6 werden sie unterstützt.

Die Eigenschaft »Andere Zeichen«, \p{C}, erkennt nicht Codepunkte aus der Klasse »unassigned«, \p{Cn}.

Die zusammengesetzte Eigenschaft \p{L&} wird nicht unterstützt.

Die Eigenschaft \p{all} wird unterstützt und entspricht (?s:.). Dagegen werden weder \p{assigned} noch \p{unassigned} unterstützt, man kann dafür \P{Cn} und \p{Cn} verwenden.

Unicode-Blockbereiche

Bei den Blockbereich-Namen muss das Präfix ›In‹ angegeben werden. Bei Unterschiede bezüglich Unicode zwischen Java 1.4.2 und 1.5.0 wird genauer auf die Unterschiede von Blocknamen innerhalb von \p{...} und \P{...} in verschiedenen Java-Versionen eingegangen.

Zwei Unicode-Blöcke haben zwischen den Unicode-Versionen 3.0 und 4.0 den Namen gewechselt: Aus Combining Marks for Symbols wurde Combining Diacritical Marks for Symbols und Greek wurde zu Greek and Coptic. In Java 1.5 können sowohl die alten als auch die neuen Namen benutzt werden.

In Java 1.4.2 gab es einen Bug mit den Unicode-Blocknamen Arabic Presentation Forms-B und Latin Extended-B; in Java 1.5 ist er behoben (siehe dazu ebenfalls Unterschiede bezüglich Unicode zwischen Java 1.4.2 und 1.5.0).

Besondere »Java«-Eigenschaften

Ab Java 1.5 kann man die Konstrukte \p{...} und \P{...} auch zusammen mit den isIrgendwas-Methoden aus java.lang.Character benutzen (die veralteten Namen werden allerdings nicht rückwirkend unterstützt). Zum Gebrauch in einer Regex ersetzt man dazu das Präfix ›is‹ im Methodennamen durch ›java‹ und verwendet diesen Namen in ˹\p{...}˼ oder ˹\P{...}˼. Zum Beispiel erkennt die Regex ˹\{javaJavaIdentifierStart dieselben Zeichen wie die Java-Methode java.lang.Character.isJavaIdentifierStart (in der Dokumentation zur Klasse java.lang.Character werden die entsprechenden Methoden aufgeführt).

Zeilenendezeichen in Unicode

Vor der Einführung von Unicode haben die meisten Regex-Dialekte das Newline in Bezug auf ˹.˼, ˹^˼ , ˹$˼ und ˹\Z˼ speziell behandelt. In Unicode gibt es aber eine größere Anzahl von möglichen Zeilenendezeichen (siehe Das Zeilenende in Unicode).

In Java werden normalerweise die folgenden Zeichen als Zeilenendezeichen interpretiert:

Zeichencode Namen Beschreibung
U+000A LF \n ASCII Line Feed, Zeilenvorschub
U+000D CR \r ASCII Carriage Return, Wagenrücklauf
U+000D U+000A CR/LF \r\n ASCII Carriage Return / Line Feed, CRLF
U+0085 NEL Unicode NEXT LINE
U+2028 LS Unicode LINE SEPARATOR
U+2029 PS Unicode PARAGRAPH SEPARATOR

Je nach Regex-Modus (siehe Die Regex-Modi bei java.util.regex) werden ˹.˼, ˹^˼, ˹$˼ und ˹\Z˼ unterschiedlich interpretiert:

Regex-Modus betrifft Beschreibung
UNIX_LINES ^ . $ \Z Traditionelles Verhalten: Nur Newline (LF) ist ein Zeilenende.
MULTILINE ^ $ ^ und $ passen auch auf Zeilenendezeichen mitten im Suchstring.
DOTALL . Zeilenende spielt für . keine Rolle; . passt auf jedes Zeichen.

Die Sequenz CR/LF verdient besondere Beachtung. Normalerweise (d.h. wenn UNIX_LINES nicht verwendet wird) wird die CR/LF-Sequenz von den Zeilenende-Metazeichen als Einheit betrachtet, sie können also nie auf die Position zwischen CR und LF passen.

Zum Beispiel erkennen $ und \Z normalerweise die Position direkt vor einem Zeilenendezeichen. LF ist ein solches, aber die Stelle davor wird nur erkannt, wenn es nicht Teil einer CR/LF-Sequenz ist (wenn also das Zeichen vor dem LF kein CR ist).

Das betrifft auch ^ und $ im MULTILINE-Modus; hier erkennt ^ auch die Position direkt nach einem CR mitten im Suchstring, aber nur, wenn darauf kein LF folgt. Entsprechend passt $ auf die Position direkt vor einem LF mitten im Suchstring, sofern davor kein CR steht.

DOTALL dagegen hat keine Auswirkungen auf die Art, wie CR/LF-Sequenzen behandelt werden (DOTALL betrifft nur den Punkt ›dot‹, und dabei werden die Zeichen einer solchen Sequenz als Einzelzeichen betrachtet). Wenn UNIX_LINES verwendet wird, ist das ohnehin kein Thema mehr, weil dann alle Zeilenendezeichen bezüglich des Punktes genau wie alle anderen Zeichen behandelt werden.

  

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema Reguläre Ausdrücke bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:
   

Copyright der deutschen Ausgabe © 2008 by O’Reilly Verlag GmbH & Co. KG
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "Reguläre Ausdrücke" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

O’Reilly Verlag GmbH & Co. KG, Balthasarstr. 81, 50670 Köln