<< < w00t! > <>

Beachten Sie, dass das Muster auf mehr als nur auf Tags passt. Schlimmer noch ist, dass es nicht das gesamte Tag in den Texten oder findet. Stattdessen geht die Übereinstimmung nur bis zum ersten >, das innerhalb des Attributwerts steht. Ähnliche Probleme gibt es bei Kommentaren, CDATA-Abschnitten in XML, DOCTYPEs, Code in <script>-Elementen und allem anderen, das >-Zeichen eingebettet hat. Wenn Sie mehr als nur ganz einfache Auszeichnungen verarbeiten wollen, insbesondere wenn der Ausgangstext aus unbekannter Quelle kommt, fahren Sie mit einer der robusteren Lösungen deutlich besser.

Zulassen von > in Attributwerten Wie die Quick-and-dirty-Regex dient diese vor allem dazu, sie den noch folgenden, robusteren Lösungen gegenüberzustellen. Trotzdem deckt sie die Grundbedürfnisse zum Finden von Tags im XML-Stil ab und kann für Ihre Bedürfnisse durchaus ausreichend sein, wenn Sie damit nur bereits als gültig erkannte Textabschnitte verarbeiten wollen, die nur Elemente und Text enthalten. Der Unterschied zur letzten Regex ist, dass sie >-Zeichen innerhalb von Attributwerten übergeht. So wird sie zum Beispiel die vollständigen -Tags aus den schon gezeigten Beispieltexten korrekt finden: und . Wie zuvor nutzt die Regex literale spitze Klammern am Anfang und am Ende der Regex, um den Anfang und das Ende eines Tags zu finden. Dazwischen wiederholt sie eine nicht-einfangende Gruppe mit drei Alternativen, die jeweils durch das Alternationsmetazeichen ‹|› getrennt sind. Die erste Alternative ist die negierte Zeichenklasse ‹[^>"']›, die alle Zeichen findet außer einer rechten spitzen Klammer (mit der das Tag geschlossen wird), dem doppelten Anführungszeichen oder dem einfachen Anführungszeichen (beide stehen für den Anfang eines Attributwerts). Die erste Alternative dient dazu, die Namen des Tags und der Attribute zu finden, aber auch alle anderen Zeichen außerhalb von Anführungszeichen. Die Reihenfolge der Alternativen ist mit Bedacht gewählt, um eine möglichst gute Performance zu erzielen. Regex-Engines nutzen alternative Wege durch eine Regex von links nach rechts. Unsere erste Alternative wird sehr wahrscheinlich am häufigsten gefunden werden.

8.1 Tags im XML-Stil finden | 447

Als Nächstes kommen die Alternativen für Attributwerte in doppelten und einfachen Anführungszeichen (‹"[^"]*"› und ‹'[^']*'›). Durch die Verwendung negierter Zeichenklassen überspringen sie eingebettete >-Zeichen, Zeilenumbrüche und alles andere, das keine schließende spitze Klammer ist. Beachten Sie, dass bei dieser Lösung Kommentare und andere spezielle Knoten in Ihrem Dokument nicht ausgeschlossen werden. Stellen Sie sicher, dass Sie wissen, mit was für Texten Sie arbeiten, bevor Sie diese Regex einsetzen.

Eine (gefahrlose) Effizienzoptimierung Nach dem Lesen dieses Abschnitts werden Sie vielleicht denken, dass Sie die Regex ein bisschen schneller machen könnten, indem Sie nach der ersten negierten Zeichenklasse (‹[^>"']›) einen der Quantoren ‹*› oder ‹+› einsetzen. Dort, wo die Regex Übereinstimmungen findet, haben Sie recht. Wenn mehr als ein Zeichen gleichzeitig gefunden wird, würde die Regex-Engine eine Reihe überflüssiger Schritte auf dem Weg zu einer erfolgreichen Übereinstimmung überspringen können. Was aber vielleicht nicht gleich ins Auge springt, sind die negativen Konsequenzen, die sich ergeben können, wenn die Regex-Engine keine vollständige Übereinstimmung findet. Trifft die Regex auf ein öffnendes <, ohne dass ein dazugehöriges schließendes > vorhanden ist, mit dem die Übereinstimmung abgeschlossen werden könnte, führt das zum „katastrophalen Backtracking“ (siehe 2.15). Das liegt daran, dass es so viele Möglichkeiten gibt, den neuen, inneren Quantor mit dem äußeren Quantor (nach der nicht-einfangenden Gruppe) zu kombinieren. All diese Wege muss die Engine ausprobieren, bevor sie feststellt, dass es keine Übereinstimmung gibt. Passen Sie also auf! Bei Regex-Varianten, die possessive Quantoren oder atomare Gruppen unterstützen (JavaScript und Python gehören nicht dazu), kann man dieses Problem vermeiden und trotzdem den Performance-Gewinn durch den zusätzlichen Quantor erhalten. Wir können sogar noch weiter gehen und das potenzielle Backtracking auch an anderen Stellen in der Regex verringern. Unterstützt die von Ihnen genutzte Regex-Variante beide Features, sollten Sie eher die possessiven Quantoren (hier in der zweiten Regex) nutzen, da der reguläre Ausdruck damit kürzer und lesbarer wird. Mit atomaren Gruppen: <(?>(?:(?>[^>"']+)|"[^"]*"|'[^']*')*)>

Regex-Optionen: Keine Regex-Varianten: .NET, Java, PCRE, Perl, Ruby Mit possessiven Quantoren: <(?:[^>"']++|"[^"]*"|'[^']*')*+>

Regex-Optionen: Keine Regex-Varianten: Java, PCRE, Perl 5.10, Ruby 1.9

448 | Kapitel 8: Markup und Datenaustausch

(X)HTML-Tags (nicht streng) Durch eine einfache Ergänzung kann diese Regex viel näher an das nicht so strenge Verhalten gerückt werden, das Webbrowser zum Erkennen von (X)HTML-Tags im Quellcode nutzen. Damit wird diese Version zu einer guten Wahl, wenn Sie versuchen, das Verhalten der Browser nachzuahmen und sich nicht darum scheren, ob die so gefundenen Tags wirklich allen Markup-Regeln folgen. Denken Sie daran, dass es immer noch möglich ist, fürchterlich falsches HTML zu erzeugen, das diese Regex nicht so behandeln wird wie der eine oder andere Browser. Denn die Browser interpretieren Grenzfälle falschen Markups auf ihre eigenen Art und Weise. Der wichtigste Unterschied dieser Regex zur vorherigen ist, dass das Zeichen nach der öffnenden spitzen Klammer (<) einer der Buchstaben A–Z oder a–z sein muss, wobei optional erst noch ein / (für schließende Tags) stehen darf. Damit werden einzeln stehende, nicht kodierte <-Zeichen im Text übergangen, aber auch Kommentare, DOCTYPEs, XML-Deklarationen und Verarbeitungsanweisungen, CDATA-Abschnitte und so weiter. Dadurch wird leider aber immer noch nicht verhindert, dass Sie Textabschnitte finden, die wie ein Tag aussehen und die innerhalb von Kommentaren, SkriptsprachenCode, dem Inhalt von -Elementen und so weiter liegen. Der folgende Abschnitt „Schwierige (X)HTML- und XML-Abschnitte überspringen“ auf Seite 453 zeigt, wie man das umgehen kann. Aber zunächst wollen wir uns anschauen, wie diese Regex arbeitet. ‹<› findet zunächst einmal eine literale, öffnende spitze Klammer. Das folgende ‹/?›<br /> <br /> ermöglicht einen optionalen Schrägstrich für schließende Tags. Dann kommt die einfangende Gruppe ‹([A-Za-z][^?\s>/]*)›, die den Tag-Namen findet und ihn sich als Rückwärtsreferenz 1 merkt. Wenn Sie sich nicht auf den Tag-Namen beziehen müssen (weil Sie zum Beispiel einfach alle Tags löschen wollen), können Sie die Klammern der einfangenden Gruppe entfernen (aber nicht den Inhalt!). Innerhalb der Gruppe gibt es zwei Zeichenklassen. Die erste ‹[A-Za-z]› definiert die Regel für das erste Zeichen des Tag-Namens. Die zweite ‹[^\s>/]› erlaubt für den Rest des Namens so gut wie jedes Zeichen. Die einzige Ausnahme bilden Whitespaces (‹\s›, damit wird der Tag-Name von folgenden Attributen getrennt), > (durch das das Tag beendet wird) und / (vor dem schließenden > für SingletonTags im XHTML-Stil). Alle anderen Zeichen (sogar Anführungszeichen) werden als Teil des Tag-Namens behandelt. Das mag ein bisschen zu großzügig sein, aber die meisten Browser arbeiten so. Falsche Tags haben zwar keinen Einfluss darauf, wie eine Seite gerendert wird, aber man kann trotzdem über den DOM-Baum auf sie zugreifen, und ihr Inhalt wird ebenfalls gerendert. Nach dem Tag-Namen kommen die Attribute. Die Regex dafür wird direkt aus der vorigen übernommen: ‹(?:[^>"']|"[^"]*"|'[^']*')*›. Wir fügen eine schließende spitze Klammer hinzu und sind fertig. Die folgenden Regexes zeigen, wie dieses Muster so angepasst werden kann, dass es nur öffnende, nur schließende oder nur (selbstschließende) Singleton-Tags findet:<br /> <br /> 8.1 Tags im XML-Stil finden | 449<br /> <br /> Öffnende Tags <([A-Za-z][^\s>/]*)(?:[^>"'/]|"[^"]*"|'[^']*')*><br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby In dieser Version ergänzen wir die erste negierte Zeichenklasse um einen Schrägstrich (/), damit diese höchstens in mit Anführungszeichen versehenen Attributwerten auftauchen dürfen. Singleton-Tags <([A-Za-z][^\s>/]*)(?:[^>"']|"[^"]*"|'[^']*')*/><br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Hier haben wir einen Schrägstrich direkt vor der schließenden eckigen Klammer ergänzt. Öffnende Tags und Singleton-Tags <([A-Za-z][^\s>/]*)(?:[^>"']|"[^"]*"|'[^']*')*><br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Hier gibt es keine Ergänzung. Stattdessen wurde das ‹/?› nach dem öffnenden ‹<› in der ursprünglichen Regex entfernt. Schließende Tags </([A-Za-z][^\s>/]*)(?:[^>"']|"[^"]*"|'[^']*')*><br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Der Schrägstrich nach der öffnenden spitzen Klammer ist jetzt nicht mehr optional, sondern notwendig. Beachten Sie, dass wir auch Attribute innerhalb schließender Tags zulassen, da dies ein Teil der „großzügigen“ Lösung ist. Browser berücksichtigen keine Attribute in schließenden Tags, aber immerhin stören sie sich auch nicht daran. Der Kasten „Eine (gefahrlose) Effizienzoptimierung“ auf Seite 448 hat gezeigt, wie man die Performance verbessern kann, wenn man Tags mithilfe von atomaren Gruppen oder possessiven Quantoren sucht. Hier ist der Performance-Gewinn sogar noch größer, da die Zeichen, die durch die Zeichenklasse ‹[^\s>/]› gefunden werden können, zum Teil denen entsprechen, die im weiter hinten liegenden Teil der Regex vorkommen. Damit gibt es eine ganze Menge Musterkombinationen, die auszuprobieren sind, bevor die Regex-Engine doch aufgeben muss. Wenn atomare Gruppen oder possessive Quantoren in Ihrer Regex-Variante zur Verfügung stehen, erhalten Sie durch ihren Einsatz eventuell eine deutlich bessere Performance. Die folgenden Änderungen können auch in den oben vorgestellten Regexes eingesetzt werden, die speziell für öffnende/schließende/Singleton-Tags gedacht sind:<br /> <br /> 450 | Kapitel 8: Markup und Datenaustausch<br /> <br /> </?([A-Za-z](?>[^\s>/]*))(?>(?:(?>[^>"']+)|"[^"]*"|'[^']*')*)><br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, PCRE, Perl, Ruby </?([A-Za-z][^\s>/]*+)(?:[^>"']++|"[^"]*"|'[^']*')*+><br /> <br /> Regex-Optionen: Keine Regex-Varianten: Java, PCRE, Perl 5.10, Ruby 1.9<br /> <br /> (X)HTML-Tags (streng) Diese Lösung ist „streng“, weil sie versucht, sich an den HTML- und XHTML-Syntaxregeln zu orientieren, die am Anfang dieses Kapitels vorgestellt wurden. Die Browser hingegen, die wir mit der vorherigen Lösung emuliert haben, sind deutlich weniger streng. Diese Strenge sorgt für ein paar zusätzliche Regeln: • Sowohl Tag- als auch Attributnamen müssen mit einem der Buchstaben A–Z oder a–z beginnen, und in den Namen dürfen nur die Zeichen A–Z, a–z, 0–9, der Bindestrich und der Doppelpunkt vorkommen (als Regex ist das ‹^[-:A-Za-z0-9]+$›). • Unpassende einzelne Zeichen sind nach dem Tag-Namen nicht erlaubt. Es dürfen nur Whitespace, Attribute (mit oder ohne zugehörigen Wert) und optional ein abschließender Schrägstrich (/) auftauchen. • Nicht mit Anführungszeichen versehene Attributwerte dürfen nur die Zeichen A–Z, a–z, 0–9, den Unterstrich, den Bindestrich, den Punkt und den Doppelpunkt enthalten (als Regex ‹^[-.:A-Za-z0-9_]+$›). • Schließende Tags dürfen keine Attribute enthalten. Da das Muster in zwei Zweige aufgeteilt ist (den ersten für öffnende und Singleton-Tags, den zweiten für schließende Tags), wird der Tag-Name in einer der beiden Rückwärtsreferenzen 1 oder 2 eingefangen – je nachdem, welche Art von Tag gefunden wurde. Beide Klammerngruppen können entfernt werden (der Inhalt muss aber bestehen bleiben), wenn Sie die Tag-Namen nicht weiterverwenden wollen. In den folgenden Beispielen sind die beiden Zweige des Musters in ihre eigenen Regexes ausgelagert. Beide fangen den Tag-Namen in der Rückwärtsreferenz 1 ein: Öffnende und Singleton-Tags <([A-Z][-:A-Z0-9]*)(?:\s+[A-Z][-:A-Z0-9]*(?:\s*=\s* (?:"[^"]*"|'[^']*'|[-.:\w]+))?)*\s*/?><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Das ‹/?› direkt vor dem schließenden ‹>› ermöglicht der Regex, sowohl öffnende als auch Singleton-Tags zu finden. Wenn Sie nur öffnende Tags finden wollen, entfernen sie die beiden Zeichen. Entfernen Sie nur den Fragezeichen-Quantor (womit das ‹/› nicht mehr optional ist), finden Sie nur Singleton-Tags.<br /> <br /> 8.1 Tags im XML-Stil finden | 451<br /> <br /> Schließende Tags </([A-Z][-:A-Z0-9]*)\s*><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby In den letzten Abschnitten haben wir gezeigt, wie man einen eventuellen PerformanceGewinn erreichen kann, indem man atomare Gruppen oder possessive Quantoren einsetzt. Bei den strikt definierten Pfaden durch diese Regex gibt es keine Möglichkeit, die gleichen Strings auf unterschiedlichen Wegen zu finden, daher ist auch Backtracking kein Thema. Diese Regex verlässt sich nicht auf Backtracking, daher könnten Sie jeden letzten Quantor vom Typ ‹*›, ‹+› und ‹?› possessiv machen (oder den gleichen Effekt durch atomare Gruppen erreichen). Auch wenn das nicht groß helfen wird, werden wir solche Variationen für diese (und die nächste) Regex weglassen, um die etwas aus dem Ruder laufende Menge an Optionen in diesem Rezept wieder unter Kontrolle zu bekommen. In „Schwierige (X)HTML- und XML-Abschnitte überspringen“ auf Seite 453 ist beschrieben, wie Sie es vermeiden können, Tags innerhalb von Kommentaren, <script>-Tags und so weiter zu finden.<br /> <br /> XML-Tags (streng) Bei XML gibt es keinen Bedarf für nicht so strenge Lösungen, weil es eine präzise Spezifikation gibt und regelkonforme Parser kein Markup verarbeiten, das nicht wohlgeformt ist. Auch wenn Sie eine der weiter oben vorgestellten Regexes nutzen könnten, um XMLDokumente zu verarbeiten, würde Ihnen deren Einfachheit keinen Vorteil gegenüber einer zuverlässigeren Suche bringen, da es keine XML verarbeitenden Programme mit „großzügiger“ Regelauslegung gibt, die zu emulieren wären. Diese Regex ist im Prinzip eine einfachere Version der Regex für (X)HTML-Tags (streng), bei der wir die Unterstützung für zwei HTML-Features entfernen konnten, die in XML nicht erlaubt sind: Attributwerte ohne Anführungszeichen und minimierte Attribute (also ohne zugehörigen Wert). Der einzige weitere Unterschied sind die zulässigen Zeichen für die Namen der Tags und Attribute. Die Regeln für XML-Namen (die die Anforderungen für Tag- und Attributnamen bestimmen) sind eigentlich großzügiger als die hier genutzten, da Hunderttausende weiterer Unicode-Zeichen zulässig sind. Wenn Sie diese Zeichen in Ihrer Suche berücksichtigen müssen, können Sie die Vorkommen von ‹[_:A-Z][-.:\w]*› durch eines der Muster ersetzen, die Sie in Rezept 8.4 finden. Beachten Sie, dass die Liste der zulässigen Zeichen von der verwendeten XML-Version abhängt. Wie bei den (X)HTML-Regexes wird der Tag-Name in den Rückwärtsreferenzen 1 oder 2 eingefangen. Das hängt davon ab, ob ein öffnendes beziehungsweise Singleton-Tag oder ein schließendes Tag gefunden wird. Und auch hier können Sie die Klammern der einfangenden Gruppen entfernen, wenn Sie die Tag-Namen später nicht brauchen.<br /> <br /> 452 | Kapitel 8: Markup und Datenaustausch<br /> <br /> In den folgenden Beispielen sind die beiden Zweige des Musters in ihre eigenen Regexes ausgelagert. Beide fangen den Tag-Namen in der Rückwärtsreferenz 1 ein: Öffnende und Singleton-Tags <([_:A-Z][-.:\w]*)(?:\s+[_:A-Z][-.:\w]*\s*=\s* (?:"[^"]*"|'[^']*'))*\s*/?><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Das ‹/?› direkt vor dem schließenden ‹>› ermöglicht der Regex, sowohl öffnende als auch Singleton-Tags zu finden. Wenn Sie nur öffnende Tags finden wollen, entfernen Sie die beiden Zeichen. Entfernen Sie lediglich den Fragezeichen-Quantor (womit das ‹/› nicht mehr optional ist), finden Sie nur Singleton-Tags. Schließende Tags </([_:A-Z][-.:\w]*)\s*><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby In „Schwierige (X)HTML- und XML-Abschnitte überspringen“ auf Seite 453 ist beschrieben, wie Sie es vermeiden können, Tags innerhalb von Kommentaren, CDATAAbschnitten und DOCTYPEs zu finden.<br /> <br /> Schwierige (X)HTML- und XML-Abschnitte überspringen Wenn Sie versuchen, Tags im XML-Stil in einer Quelldatei oder in einem String zu finden, müssen Sie einiges an Aufwand betreiben, um nicht fälschlicherweise Texte zu finden, die wie Tags aussehen, aber aufgrund ihrer Position im Text oder aus anderen Gründen gar keine Tags sind. Die (X)HTML- und XML-spezifischen Regexes, die wir in diesem Rezept gezeigt haben, vermeiden einige der problematischen Texte dadurch, dass der erste Buchstabe eines Element-Namens eingeschränkt wird. Einige gehen noch weiter, indem das Tag die (X)HTML- oder XML-Syntaxregeln erfüllen muss. Trotzdem müssen wir bei einer robusten Lösung vermeiden, jegliche Texte zu finden, die innerhalb von Kommentaren, Skriptsprachen-Code (der zum Beispiel Größer- und Kleiner-Zeichen in mathematischen Operationen verwendet), XML-CDATA-Abschnitten und einigen weiteren Konstrukten stehen. Das können wir lösen, indem wir zunächst nach diesen kritischen Abschnitten suchen und dann die Tags nur außerhalb dieser gefundenen Abschnitte suchen. In Rezept 3.18 ist beschrieben, wie man Code schreibt, der die Übereinstimmungen einer anderen Regex durchsucht. Er benötigt zwei Muster: eine innere und eine äußere Regex. Die schon vorgestellten Lösungen dienen als innere Regex. Die äußere Regex stellen wir gleich vor. Dabei nutzen wir unterschiedliche Muster für (X)HTML und XML. Durch dieses Vorgehen werden die kritischen Abschnitte vor dem Durchsuchen mit der inneren Regex verborgen. Das macht alles deutlich einfacher.<br /> <br /> 8.1 Tags im XML-Stil finden | 453<br /> <br /> Äußere Regex für (X)HTML. Die folgende Regex findet Kommentare, aber auch die Elemente <script>, <style>, <textarea> und <xmp>1 (einschließlich ihres Inhalts): <!--.*?--\s*>|<(script|style|textarea|xmp)\b(?:[^>"']|"[^"]*"| '[^']*')*?(?:/>|>.*?</\1\s*>)<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Punkt passt auf Zeilenumbruch Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Sollte das jetzt nicht der lesbarste Code sein, der Ihnen je untergekommen ist, gibt es die Regex hier nochmals im Freiform-Modus mit ein paar Kommentaren: # Kommentar <!-- .*? --\s*> | # Spezielle Elemente und ihr Inhalt <( script | style | textarea | xmp )\b (?: [^>"'] # Zeichen außer >, " oder ' | "[^"]*" # Werte in doppelten Anführungszeichen | '[^']*' # Werte in einfachen Anführungszeichen )*? (?: # Singleton-Tag /> | # Ansonsten den Inhalt des Elements und das schließende Tag mit aufnehmen. > .*? </\1\s*> )<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Punkt passt auf Zeilenumbruch, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Keine der oben angegebenen Regexes funktioniert in JavaScript korrekt, da es dort weder die Option Punkt passt auf Zeilenumbruch noch den Freiform-Modus gibt. Die folgende Regex versucht wieder, unlesbar zu werden, und ersetzt die Punkte durch ‹[\s\S]›, um in JavaScript eingesetzt werden zu können: <!--[\s\S]*?--\s*>|<(script|style|textarea|xmp)\b(?:[^>"']|"[^"]*"| '[^']*')*?(?:/>|>[\s\S]*?</\1\s*>)<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Variante: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Diese Regexes stellen uns vor ein Dilemma: Da sie die Tags <script>, <style>, <textarea> und <xmp> finden, werden diese Tags nie durch die zweite (innere) Regex gefunden, auch wenn wir doch eigentlich nach allen Tags suchen wollen. Aber es sollte jetzt nicht mehr so schwer sein, mit etwas Code diese Tags gesondert zu behandeln. Die (äußeren) Rege1 <xmp> ist ein Element, das wenig bekannt ist, aber weitgehend unterstützt wird. Es ähnelt <pre>, da es jeglichen Whitespace beibehält und eine Schrift mit fester Breite verwendet. Aber es geht noch einen Schritt weiter als <pre>. Es zeigt seinen gesamten Inhalt (einschließlich HTML-Tags) als reinen Text an. <xmp> wurde in HTML 3.2 als veraltet markiert und in HTML 4 komplett entfernt.<br /> <br /> 454 | Kapitel 8: Markup und Datenaustausch<br /> <br /> xes fangen schon den Namen des Tags in der Rückwärtsreferenz 1 ein. Damit können wir dann bequem prüfen, ob es sich um einen Kommentar oder ein Tag handelt (und wenn es eines war, wissen wir auch, welches). Äußere Regex für XML Diese Regex findet Kommentare, CDATA-Abschnitte und DOCTYPEs. Jeder dieser Fälle wird über ein eigenes Muster abgedeckt, die alle mithilfe des Alternations-Metazeichens ‹|› kombiniert werden: <!--.*?--\s*>|<!\[CDATA\[.*?]]>|<!DOCTYPE\s(?:[^<>"']|"[^"]*"| '[^']*'|<!(?:[^>"']|"[^"]*"|'[^']*')*>)*><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Punkt passt auf Zeilenumbruch Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Erneut im Freiform-Modus: # Kommentar <!-- .*? --\s*> | # CDATA-Abschnitt <!\[CDATA\[ .*? ]]> | # Document Type Declaration <!DOCTYPE\s (?: [^<>"'] # Normale Zeichen | "[^"]*" # Werte in doppelten Anführungszeichen | '[^']*' # Werte in einfachen Anführungszeichen | <!(?:[^>"']|"[^"]*"|'[^']*')*> # Markup-Deklaration )* ><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Punkt passt auf Zeilenumbruch, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Und hier eine Version, die in JavaScript funktioniert (in der es die Option Punkt passt auf Zeilenumbruch und den Freiform-Modus nicht gibt): <!--[\s\S]*?--\s*>|<!\[CDATA\[[\s\S]*?]]>|<!DOCTYPE\s(?:[^<>"']|"[^"]*"| '[^']*'|<!(?:[^>"']|"[^"]*"|'[^']*')*>)*><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Variante: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby<br /> <br /> 8.1 Tags im XML-Stil finden | 455<br /> <br /> Variationen Gültige HTML 4-Tags finden Gelegentlich wollen Sie Ihre Suche auf die gültigen HTML-Elemente beschränken, insbesondere wenn Sie in Nicht-HTML-Dokumenten nach Tags suchen und falsch positive Ergebnisse vermeiden wollen. Die folgende Regex passt nur auf die 91 gültigen Tags in HTML 4. Die Liste enthält keine HTML-Tags, die nicht zum offiziellen Standard gehören, wie zum Beispiel <blink>, <bgsound>, <embed> und <nobr>. Auch sind keine Elemente enthalten, die es nur in XHTML 1.1 gibt (in XHTML 1.0 gab es keine neuen Elemente) oder die für HTML 5 geplant sind: </?(a|abbr|acronym|address|applet|area|b|base|basefont|bdo|big|blockquote| body|br|button|caption|center|cite|code|col|colgroup|dd|del|dfn|dir|div| dl|dt|em|fieldset|font|form|frame|frameset|h1|h2|h3|h4|h5|h6|head|hr|html| i|iframe|img|input|ins|isindex|kbd|label|legend|li|link|map|menu|meta| noframes|noscript|object|ol|optgroup|option|p|param|pre|q|s|samp|script| select|small|span|strike|strong|style|sub|sup|table|tbody|td|textarea| tfoot|th|thead|title|tr|tt|u|ul|var)\b(?:[^>"']|"[^"]*"|'[^']*')*><br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Wir können diese Regex schneller machen, indem wir die Anzahl der Alternativen verringern, die durch das Metazeichen ‹|› getrennt sind. Stattdessen verwenden wir wann immer möglich Zeichenklassen und optionale Suffixe. Damit reduziert sich das nötige Backtracking dramatisch. Schauen Sie sich an, was passiert, wenn die Engine auf den Text <0 stößt. Das kann kein Tag-Anfang sein, weil keiner der Tag-Namen mit der Ziffer 0 beginnt, aber bevor die Regex-Engine diese Position wieder verwerfen kann, muss sie alle 91 Alternativen darauf prüfen, ob sie nicht mit einer literalen 0 beginnen. Indem wir die Anzahl an Alternativen auf ein Minimum reduzieren (eine für jeden Buchstaben, mit dem ein Tag beginnen kann), verringern wir die Anzahl an Schritten, die nach einer öffnenden spitzen Klammer ausprobiert werden müssen, von 91 auf 19. So sieht eine solche Regex aus: </?(a(?:bbr|cronym|ddress|pplet|rea)?|b(?:ase(?:font)?|do|ig|lockquote| ody|r|utton)?|c(?:aption|enter|ite|o(?:de|l(?:group)?))|d(?:[dlt]|el|fn| i[rv])|em|f(?:ieldset|o(?:nt|rm)|rame(?:set)?)|h(?:[1-6r]|ead|tml)| i(?:frame|mg|n(?:put|s)|sindex)?|kbd|l(?:abel|egend|i(?:nk)?)|m(?:ap| e(?:nu|ta))|no(?:frames|script)|o(?:bject|l|p(?:tgroup|tion))|p(?:aram| re)?|q|s(?:amp|cript|elect|mall|pan|t(?:rike|rong|yle)|u[bp])?|t(?:able| body|[dhrt]|extarea|foot|head|itle)|ul?|var)\b(?:[^>"']|"[^"]*"|'[^']*')*><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby<br /> <br /> 456 | Kapitel 8: Markup und Datenaustausch<br /> <br /> Das lässt sich sicherlich schlechter lesen, aber der Freiform-Modus kann ein bisschen helfen: < /? (<br /> <br /> # Schließende Tags zulassen # Den Tag-Namen in Rückwärtsreferenz 1 einfangen a(?:bbr|cronym|ddress|pplet|rea)?| b(?:ase(?:font)?|do|ig|lockquote|ody|r|utton)?| c(?:aption|enter|ite|o(?:de|l(?:group)?))| d(?:[dlt]|el|fn|i[rv])| em| f(?:ieldset|o(?:nt|rm)|rame(?:set)?)| h(?:[1-6r]|ead|tml)| i(?:frame|mg|n(?:put|s)|sindex)?| kbd| l(?:abel|egend|i(?:nk)?)| m(?:ap|e(?:nu|ta))| no(?:frames|script)| o(?:bject|l|p(?:tgroup|tion))| p(?:aram|re)?| q| s(?:amp|cript|elect|mall|pan|t(?:rike|rong|yle)|u[bp])?| t(?:able|body|[dhrt]|extarea|foot|head|itle)| ul?| var<br /> <br /> ) \b (?: [^>"'] | "[^"]*" | '[^']*' )* ><br /> <br /> # # # #<br /> <br /> Tag-Name muss vollständig sein Alle Zeichen außer >, " oder ' Attributwert in doppelten Anführungszeichen Attributwert in einfachen Anführungszeichen<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Wenn Sie mal so richtig in die Vollen greifen und sich mit Whitespace austoben wollen, können Sie die gleiche Regex im Freiform-Modus auch so schreiben: < /? (<br /> <br /> # Schließende Tags zulassen # Den Tag-Namen in Rückwärtsreferenz 1 einfangen a (?: | | | | )?| b (?: | | | |<br /> <br /> bbr cronym ddress pplet rea ase (?:font)? do ig lockquote ody<br /> <br /> # # # # # # Optionale Gruppe (ermöglicht <a>) # <base>, <basefont> # # # #<br /> <br /> 8.1 Tags im XML-Stil finden | 457<br /> <br /> | r | utton )?| c (?: aption | enter | ite | o (?:de|l(?:group)?) ) | d (?: [dlt] | el | fn | i[rv] ) | em | f (?: ieldset | o (?:nt|rm) | rame (?:set)? ) | h (?: [1-6r] | ead | tml ) | i (?: frame | mg | n (?:put|s) | sindex )?| kbd | l (?: abel | egend | i (?:nk)? ) | m (?: ap | e (?:nu|ta) ) | no (?: frames | script ) | o (?: bject | l | p (?:tgroup|tion) ) | p (?: aram | re )?| q | s (?: amp | cript | elect | mall | pan | t (?:rike|rong|yle) | u[bp] )?|<br /> <br /> # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #<br /> <br /> 458 | Kapitel 8: Markup und Datenaustausch<br /> <br /> Optionale Gruppe (ermöglicht <b>)<br /> <br /> <code>, <col>, <colgroup> <dd>, <dl>, <dt><br /> <br /> <dir>, <div><br /> <br /> <font>, <form> <frame>, <frameset> <h1>, <h2>, <h3>, <h4>, <h5>, <h6>, <hr><br /> <br /> <input>, <ins> optionale Gruppe (ermöglicht <i>)<br /> <br /> <li>, <link><br /> <br /> <menu>, <meta><br /> <br /> <optgroup>, <option><br /> <br /> Optionale Gruppe (ermöglicht <p>)<br /> <br /> <strike>, <strong>, <style> <sub>, <sup> Optionale Gruppe (ermöglicht <s>)<br /> <br /> t (?: | | | | | | ) | ul? | var<br /> <br /> able body [dhrt] extarea foot head itle<br /> <br /> ) \b (?: [^>"'] | "[^"]*" | '[^']*' )* ><br /> <br /> # # # #<br /> <br /> # # # <td>, <th>, <tr>, <tt> # # # # # # <u>, <ul> #<br /> <br /> Tag-Name muss vollständig sein Alle Zeichen außer >, " oder ' Attributwert in doppelten Anführungszeichen Attributwert in einfachen Anführungszeichen<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Wenn Sie mit XHTML arbeiten, können Sie berücksichtigen, dass XHTML 1.0 zwar keine Tags ergänzt, aber immerhin 14 davon entfernt: <applet rel="nofollow">, <basefont>, <center>, <dir>, <font>, <frame>, <frameset>, <iframe>, <isindex>, <menu>, <noframes>, <s>, <strike> und <u>. XHTML 1.1 behält alle Elemente aus XHTML 1.0 und fügt sechs weitere hinzu (alle für Ruby-Text für asiatische Sprachen): <rb>, <rbc>, <rp>, <rt>, <rtc> und <ruby>. Regexes, die nur die gültigen Elemente aus XHTML 1.0 oder 1.1 finden, überlassen wir als Aufgabe dem geneigten Leser.<br /> <br /> Siehe auch Manchmal muss man alle Tags finden, aber manchmal soll es auch nur ein bestimmtes Tag sein (oder eines aus einer kleineren Liste). In Rezept 8.2 ist beschrieben, wie man dies bewerkstelligen kann. In Rezept 8.4 sind die Zeichen aufgeführt, die für XML-Elementnamen und Attributnamen zulässig sind.<br /> <br /> 8.2<br /> <br /> <b>-Tags durch <strong> ersetzen<br /> <br /> Problem Sie wollen in einem String alle öffnenden und schließenden <b>-Tags durch entsprechende <strong>-Tags ersetzen, dabei aber vorhandene Attribute beibehalten.<br /> <br /> 8.2 <b>-Tags durch <strong> ersetzen |<br /> <br /> 459<br /> <br /> Lösung Diese Regex passt auf öffnende und schließende <b>-Tags mit oder ohne Attribute: <(/?)b\b((?:[^>"']|"[^"]*"|'[^']*')*)><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Im Freiform-Modus: < (/?) b \b ( (?: [^>"'] | "[^"]*" | '[^']*' )* ) ><br /> <br /> # # Den optionalen führenden Schrägstrich in Rückwärtsreferenz 1 fangen # Vollständiger Tag-Name mit Wortgrenze # Attribute usw. in Rückwärtsreferenz 2 einfangen # Alle Zeichen außer >, " oder ' # Attributwert in doppelten Anführungszeichen # Attributwert in einfachen Anführungszeichen # # #<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Um alle Attribute beim Ändern des Tag-Namens beizubehalten, nutzen Sie den folgenden Ersetzungstext: <$1strong$2><br /> <br /> Ersetzungstextvarianten: .NET, Java, JavaScript, Perl, PHP <\1strong\2><br /> <br /> Ersetzungstextvarianten: Python, Ruby Wenn Sie dabei alle Attribute entfernen wollen, lassen Sie im Ersetzungstext die Rückwärtsreferenz 2 weg: <$1strong><br /> <br /> Ersetzungstextvarianten: .NET, Java, JavaScript, Perl, PHP <\1strong><br /> <br /> Ersetzungstextvarianten: Python, Ruby In Rezept 3.15 finden Sie Beispiele für Code, mit dem dies implementiert werden kann.<br /> <br /> Diskussion Im vorhergehenden Rezept wurde detailliert auf die vielen Wege eingegangen, ein beliebiges Tag im XML-Stil zu finden. Dieses Rezept konzentriert sich hingegen auf einen direkten Weg, nach einer bestimmten Art von Tag zu suchen. Als Beispiel wird <b> durch <strong> ersetzt, aber Sie können diese Tag-Namen mit beliebigen anderen tauschen.<br /> <br /> 460 | Kapitel 8: Markup und Datenaustausch<br /> <br /> Die Regex sucht zunächst nach einem literalen ‹<› – dem ersten Zeichen jedes Tags. Dann findet sie durch ‹/?› optional den Schrägstrich von schließenden Tags, der dabei in einer einfangenden Gruppe abgelegt wird. Indem wir das Ergebnis dieses Musters speichern (was entweder ein leerer String oder ein Schrägstrich sein wird), können wir den Schrägstrich im Ersetzungstext bequem wieder einfügen, ohne irgendwelchen Bedingungen prüfen zu müssen. Als nächstes finden wir den Tag-Namen ‹b› selbst. Sie können hier auch einen beliebigen anderen Tag-Namen nutzen. Wir verwenden die Option zum Ignorieren von Groß- und Kleinschreibung, um sicherzustellen, dass wir auch ein großes B finden. Die Wortgrenze (‹\b›), die auf den Tag-Namen folgt, wird gern vergessen, aber es ist eines der wichtigsten Elemente dieser Regex. Durch die Wortgrenze finden wir nur <b>Tags, nicht aber <br>, <body>, <blockquote> oder irgendein anderes Tag, das auch mit dem Buchstaben „b“ beginnt. Wir könnten alternativ nach einem Whitespace-Token (‹\s›) suchen, um dieses Problem zu umgehen, aber wenn das Tag kein Attribut besitzt, würde auf den Tag-Namen kein Whitespace folgen. Die Wortgrenze löst dieses Problem einfach und elegant. Wenn Sie mit XML und XHTML arbeiten, achten Sie darauf, dass der Doppelpunkt, der für Namensräume genutzt wird, aber auch Bindestriche und ein paar weitere Zeichen, die als Teil von XML-Namen zulässig sind, ebenfalls für eine Wortgrenze sorgen. So könnte die Regex zum Beispiel so etwas wie <b-sharp> finden. Sollte Ihnen das Probleme bereiten, können Sie statt einer Wortgrenze den Lookahead ‹(?=[\s/>])› verwenden. Damit verhindern Sie, nur Teile des Tag-Namens zu finden.<br /> <br /> Nach dem Tag-Namen wird das Muster ‹((?:[^>"']|"[^"]*"|'[^']*')*)› genutzt, um alles innerhalb des Tags bis zur schließenden spitzen Klammer zu finden. Indem wir dieses Muster in eine einfangende Gruppe stecken, können wir die Attribute und andere Zeichen (wie zum Beispiel den abschließenden Schrägstrich bei Singleton-Tags) in unseren Ersetzungstext übernehmen. Innerhalb der einfangenden Klammern wiederholt das Muster eine nicht-einfangende Gruppe mit drei Alternativen. Die erste ‹[^>"']› passt auf ein einzelnes Zeichen, außer auf >, " oder '. Die beiden anderen Alternativen passen auf einen vollständigen String in doppelten oder einfachen Anführungszeichen, wodurch Sie auch Attributwerte mit schließenden spitzen Klammern finden, ohne dass die Regex denkt, sie sei schon am Ende des Tags angelangt.<br /> <br /> Variationen Eine Liste mit Tags ersetzen Wenn Sie Tags aus einer Liste mit Tag-Namen ersetzen wollen, müssen Sie nur eine kleine Änderung vornehmen. Stecken Sie alle gewünschten Tag-Namen in eine Gruppe mit einer Alternation. Durch die Gruppe wird die Reichweite des Alternations-Metazeichens (‹|›) begrenzt.<br /> <br /> 8.2 <b>-Tags durch <strong> ersetzen |<br /> <br /> 461<br /> <br /> Die folgende Regex passt auf öffnende und schließende Tags mit den Namen <b>, <i>, <em> und <big>. Der danach gezeigte Ersetzungstext tauscht alle Tags durch <strong> oder </strong> aus, behält aber die Attribute bei: <(/?)([bi]|em|big)\b((?:[^>"']|"[^"]*"|'[^']*')*)><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Hier die gleiche Regex im Freiform-Modus: < (/?) ([bi]|em|big) \b ( (?: [^>"'] | "[^"]*" | '[^']*' )* ) ><br /> <br /> # # Den optionalen führenden Schrägstrich in Rückwärtsreferenz 1 fangen # Tag-Namen in in Rückwärtsreferenz einfangen # Attribute usw. in Rückwärtsreferenz 3 einfangen # Alle Zeichen außer >, " oder ' # Attributwert in doppelten Anführungszeichen # Attributwert in einfachen Anführungszeichen # # #<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Mit der Zeichenklasse ‹[bi]› finden wir die beiden Tags <b> und <i>, statt sie als eigene Alternativen mit dem vertikalen Balken zu trennen. Zeichenklassen werden schneller verarbeitet als Alternationen, da sie kein Backtracking benötigen. Wenn der Unterschied zwischen zwei Optionen nur ein einzelnes Zeichen ist, verwenden Sie besser eine Zeichenklasse. Dazu haben wir eine einfangende Gruppe für den Tag-Namen hinzugefügt, durch den sich die Gruppe für die Attribute und den ganzen Rest an Position 3 verschiebt. Auch wenn wir den Tag-Namen nicht brauchen, weil wir sowieso alle Fundstellen durch <strong>-Tags ersetzen wollen, kann der Tag-Name dennoch hilfreich sein, wenn man prüfen muss, was da gerade ersetzt wird. Um alle Attribute beim Ersetzen des Tag-Namens beizubehalten, nutzen Sie den folgenden Ersetzungstext: <$1strong$3><br /> <br /> Ersetzungstextvarianten: .NET, Java, JavaScript, Perl, PHP <\1strong\3><br /> <br /> Ersetzungstextvarianten: Python, Ruby Wenn Sie die Attribute für die gefundenen Tags beim Ersetzen verwerfen wollen, lassen Sie die Rückwärtsreferenz 3 weg: <$1strong><br /> <br /> Ersetzungstextvarianten: .NET, Java, JavaScript, Perl, PHP <\1strong><br /> <br /> Ersetzungstextvarianten: Python, Ruby<br /> <br /> 462 | Kapitel 8: Markup und Datenaustausch<br /> <br /> Siehe auch In Rezept 8.1 wird gezeigt, wie Sie alle Tags im XML-Stil finden können, wobei unterschiedliche Lösungen für verschiedene Gewichtungen auf Fehlertoleranz, Genauigkeit und so weiter präsentiert werden. In Rezept 8.3 finden Sie das Gegenstück zu diesem Rezept – wie Sie alle Tags finden können, außer denen in einer Liste.<br /> <br /> 8.3<br /> <br /> Alle Tags im XML-Stil außer <em> und <strong> entfernen<br /> <br /> Problem Sie wollen alle Tags außer <em> und <strong> aus einem String entfernen. In einem anderen Fall wollen Sie nicht nur alle Tags außer <em> und <strong> entfernen, sondern auch noch <em>- und <strong>-Tags, die Attribute enthalten.<br /> <br /> Lösung Dies ist eine perfekte Einsatzmöglichkeit für negative Lookaheads (beschrieben in Rezept 2.16). Somit können Sie wie üblich alles finden, was wie ein Tag aussieht, außer wenn bestimmte Wörter direkt auf das öffnende < oder </ folgen. Ersetzen Sie dann alle Übereinstimmungen durch einen leeren String (Rezept 3.14 hilft Ihnen da weiter), bleiben nur die gewünschten Tags stehen.<br /> <br /> Lösung 1: Tags außer <em> und <strong> finden </?(?!(?:em|strong)\b)[a-z](?:[^>"']|"[^"]*"|'[^']*')*><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Im Freiform-Modus: < /? (?! (?: em | strong ) \b ) [a-z] (?: [^>"'] | "[^"]*" | '[^']*' )* ><br /> <br /> # Schließende Tags zulassen # Negativer Lookahead # Liste mit Tags, die nicht gefunden werden sollen # Wortgrenze vermeidet Teilübereinstimmung von Tag-Namen # # Das erste Zeichen eines Tag-Namen muss a-z sein # Jedes Zeichen außer >, " oder ' # Attributwert mit doppelten Anführungszeichen # Attributwert mit einfachen Anführungszeichen # #<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby<br /> <br /> 8.3 Alle Tags im XML-Stil außer <em> und <strong> entfernen | 463<br /> <br /> Lösung 2: Tags außer <em> und <strong> finden, sofern die beiden Tags keine Attribute enthalten Mit einer Änderung (ersetzen von ‹\b› durch ‹\s*>›) können Sie mit der Regex auch <em>- und <strong>-Tags mit Attributen finden: </?(?!(?:em|strong)\s*>)[a-z](?:[^>"']|"[^"]*"|'[^']*')*><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Auch hier wieder die gleiche Regex im Freiform-Modus: < /? (?! (?: em | strong ) \s* > ) [a-z] (?: [^>"'] | "[^"]*" | '[^']*' )* ><br /> <br /> # Schließende Tags zulassen # Negativer Lookahead # Liste mit Tags, die nicht gefunden werden sollen # Nur Tags ausschließen, die keine Attribute enthalten # # Das erste Zeichen eines Tag-Namen muss a-z sein # Jedes Zeichen außer >, " oder ' # Attributwert mit doppelten Anführungszeichen # Attributwert mit einfachen Anführungszeichen # #<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby<br /> <br /> Diskussion Die regulären Ausdrücke in diesem Rezept haben viel mit den Regexes gemeinsam, die wir weiter oben in diesem Kapitel für das Finden von Tags im XML-Stil genutzt haben. Abgesehen vom negativen Lookahead, das wir ergänzt haben, um ein paar Tags aus dem Suchergebnis auszuschließen, entsprechen diese Regexes näherungsweise denen aus „(X)HTML-Tags (nicht streng)“ in Rezept 8.1. Der andere größere Unterschied ist, dass wir den Tag-Namen nicht in der Rückwärtsreferenz 1 einfangen. Lassen Sie uns die Neuheiten in diesem Rezept also genauer anschauen. Lösung 1 findet nie <em>- oder <strong>-Tags, unabhängig davon, ob sie Attribute enthalten oder nicht. Lösung 2 findet die gleichen Tags wie Lösung 1, aber zusätzlich noch <em>- und <strong>Tags mit einem oder mehreren Attributen. In Tabelle 8-2 werden ein paar Beispiele gezeigt, die das illustrieren. Tabelle 8-2: Ein paar Beispieltexte Ausgangstext<br /> <br /> Lösung 1<br /> <br /> Lösung 2<br /> <br /> <i><br /> <br /> Übereinstimmung<br /> <br /> Übereinstimmung<br /> <br /> </i><br /> <br /> Übereinstimmung<br /> <br /> Übereinstimmung<br /> <br /> <i style="font-size:500%; color:red;"><br /> <br /> Übereinstimmung<br /> <br /> Übereinstimmung<br /> <br /> 464 | Kapitel 8: Markup und Datenaustausch<br /> <br /> Tabelle 8-2: Ein paar Beispieltexte (Fortsetzung) Ausgangstext<br /> <br /> Lösung 1<br /> <br /> Lösung 2<br /> <br /> <em><br /> <br /> Keine Übereinstimmung<br /> <br /> Keine Übereinstimmung<br /> <br /> </em><br /> <br /> Keine Übereinstimmung<br /> <br /> Keine Übereinstimmung<br /> <br /> <em style="font-size:500%; color:red;"><br /> <br /> Keine Übereinstimmung<br /> <br /> Übereinstimmung<br /> <br /> Da diese Regexes dazu dienen sollen, Übereinstimmungen durch leeren Text zu ersetzen (also die Tags zu entfernen), ist Lösung 2 weniger anfällig für den Missbrauch der zulässigen Tags <em> und <strong>, um unerwartete Formatierungsergebnisse auszulösen. Dieses Rezept hat (bisher) bewusst das Wort „Whitelist“ vermieden, wenn es darum ging, nur ein paar Tags stehen zu lassen. Denn dieses Wort beinhaltet auch Sicherheitsaspekte. Es gibt eine ganze Reihe von Möglichkeiten, mit speziell entworfenen, böswilligen HTML-Strings die Regexes zu umgehen. Wenn Sie sich um böswilligen HTML-Code und Cross-Site Scripting (XSS) sorgen, ist es am besten, alle <, > und & in ihre Zeichenreferenzen umzuwandeln (<, > und &) und dann die Tags wieder zurückzuwandeln, die als sicher bekannt sind (solange sie keine Attribute oder nur als sicher bestätigte Attribute enthalten). style ist ein Beispiel für ein nicht sicheres Attribut, da Sie bei einigen Browsern SkriptsprachenCode in Ihr CSS einbinden können. Um zum Beispiel nach dem Ersetzen von <, > und & durch die Entitätsreferenzen die Tags wieder zurückzuholen, können Sie mit der Regex ‹<(/?)em>› suchen und die Übereinstimmungen durch «<$1em>» (oder in Python und Ruby «<\1em>») ersetzen.<br /> <br /> Variationen Attribute auf einer Whitelist Schauen Sie sich diese neuen Anforderungen an: Sie müssen alle Tags außer <a>, <em> und <strong> finden, jedoch mit zwei Ausnahmen. Jedes <a>-Tag, das neben href oder title noch weitere Attribute besitzt, soll ebenso gefunden werden wie <em>- oder <strong>-Tags, die überhaupt Attribute besitzen. Alle gefundenen Strings werden dann entfernt. Sie wollen also alle Tags entfernen, außer denen auf einer Whitelist (<a>, <em> und <strong>). Die einzigen zulässigen Attribute sind href und title, die auch nur in <a>-Tags erlaubt sind. Findet sich ein nicht zugelassenes Attribut in einem Tag, wird das gesamte Tag entfernt. Diese Regex kann die Aufgabe erledigen. Sie wird im normalen und im Freiform-Modus vorgestellt: <(?!(?:em|strong|a(?:\s+(?:href|title)\s*=\s*(?:"[^"]*"|'[^']*'))*)\s*>) [a-z](?:[^>"']|"[^"]*"|'[^']*')*><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby<br /> <br /> 8.3 Alle Tags im XML-Stil außer <em> und <strong> entfernen | 465<br /> <br /> < /? (?!<br /> <br /> # Schließende Tags zulassen # Negativer Lookahead # <em> oder ... # <strong> oder... # <a> oder ... # <a> nur mit href oder title nicht finden<br /> <br /> (?: em | strong | a (?: \s+ (?:href|title) \s*=\s* (?:"[^"]*"|'[^']*') # Attributwerte in einfachen )* # oder doppelten Anführunsgzeichen ) \s* > # Tags nur dann nicht finden, wenn sie zur obigen Liste ) # gehören [a-z] # Tag-Name muss mit a-z beginnen (?: [^>"'] # Jedes Zeichen außer >, " oder ' | "[^"]*" # Attributwerte in doppelten Anführungszeichen | '[^']*' # Attributwerte in einfachen Anführungszeichen )* ><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Damit stellt sich wieder die Frage, wo es noch sinnvoll ist, solch komplizierte Regexes zu verwenden. Wenn Ihre Regeln noch komplexer werden, wird es vermutlich besser sein, Code auf Basis der Rezepte 3.11 oder 3.16 zu schreiben, der den Wert jedes gefundenen Tags prüft, um zu entscheiden, was mit ihm geschehen soll (basierend auf dem TagNamen, den Attributen und was sonst noch so zur Entscheidungsfindung benötigt wird).<br /> <br /> Siehe auch In Rezept 8.1 wird gezeigt, wie Sie alle Tags im XML-Stil finden können, wobei unterschiedliche Lösungen für verschiedene Gewichtungen auf Fehlertoleranz, Genauigkeit und so weiter präsentiert werden. In Rezept 8.2 finden Sie das Gegenstück zu diesem Rezept – nämlich wie Sie alle Tags finden können, die sich auf einer Liste befinden.<br /> <br /> 8.4<br /> <br /> XML-Namen finden<br /> <br /> Problem Sie wollen prüfen, ob ein String ein gültiger XML-Name ist (ein häufig genutztes syntaktisches Konstrukt). XML besitzt exakte Regeln für die Zeichen, die in einem Namen vorkommen können, und nutzt diese Regeln für die Namen von Elementen, Attributen und Entitäten, von Zielen für Verarbeitungsanweisungen und so weiter. Namen müssen mit einem Buchstaben, einem Unterstrich oder einem Doppelpunkt beginnen, gefolgt von<br /> <br /> 466 | Kapitel 8: Markup und Datenaustausch<br /> <br /> einer beliebigen Kombination aus Buchstaben, Ziffern, Unterstrichen, Doppelpunkten, Bindestrichen und Punkten. Das ist nicht ganz exakt, aber schon recht nahe dran. Die genaue Liste an zugelassenen Zeichen hängt auch von der verwendeten XML-Version ab. Alternativ wollen Sie ein Muster aufbauen, mit dem gültige Namen in anderen Regexes für XML-Text gefunden werden können, wenn die verbesserte Genauigkeit die zusätzliche Komplexität wert ist. Dies sind ein paar Beispiele für gültige Namen: • • • • •<br /> <br /> thing _thing_2_ :Российские-Вещь fantastic4:the.thing<br /> <br /> Beachten Sie, dass durchaus Buchstaben aus anderen Schriftsystemen zugelassen sind, selbst die ideografischen Zeichen aus dem letzten Beispiel. Zudem ist nach dem ersten Zeichen jede Unicode-Ziffer erlaubt, nicht nur die arabischen Ziffern 0–9. Zu Vergleichszwecken finden Sie hier ein paar Beispiele für ungültige Namen, die von der Regex nicht gefunden werden sollten: • • • • •<br /> <br /> thing! thing with spaces .thing.with.a.dot.in.front -thingamajig 2nd_thing<br /> <br /> Lösung Wie bei Bezeichnern in vielen Programmiersprachen gibt es eine definierte Menge von Zeichen, die in einem XML-Namen auftauchen dürfen, und davon eine Untermenge, die als erstes Zeichen genutzt werden können. Diese Zeichenlisten unterscheiden sich zwischen XML 1.0 Fourth Edition (und früher) und XML 1.1 und 1.0 Fifth Edition dramatisch. Im Prinzip können in XML 1.1 für Namen alle Zeichen genutzt werden, die schon in der 1.0 Fourth Edition gültig waren, plus nahezu eine Million Zeichen mehr. Allerdings handelt es sich bei der Mehrzahl der zusätzlichen Zeichen nur um Positionen in der Unicode-Tabelle. Für die meisten dieser Positionen gibt es noch gar keine zugewiesenen Zeichen, sondern sie sind für zukünftige Erweiterungen der Unicode-Zeichendatenbank gedacht. Aus Gründen der Einfachheit beziehen wir uns in diesem Rezept bei einem Verweis auf XML 1.0 auf die erste bis vierte Edition von XML 1.0. Reden wir über Namen in XML 1.1, meinen wir auch die Regeln für XML 1.0 Fifth Edition. Die fünfte Edition wurde erst im November 2008 zu einer offiziellen W3C-Empfehlung – nahezu fünf Jahre nach XML 1.1.<br /> <br /> 8.4 XML-Namen finden | 467<br /> <br /> Die Regexes werden in diesem Rezept mit Ankern für den Anfang und das Ende des Strings präsentiert (wobei entweder ‹^...$› oder ‹\A...\Z› genutzt wird), damit Ihr Ausgangstext nur vollständig oder gar nicht gefunden wird. Wenn Sie diese Muster in einen längeren regulären Ausdruck einfügen wollen, der zum Beispiel mit XML-Elementen arbeitet, dürfen Sie nicht vergessen, die Anker am Anfang und Ende des Musters zu entfernen. Anker werden in Rezept 2.5 erläutert.<br /> <br /> Namen in XML 1.0 (Näherung) \A[:_\p{Ll}\p{Lu}\p{Lt}\p{Lo}\p{Nl}][:_\-.\p{L}\p{M}\p{Nd}\p{Nl}]*\Z<br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, PCRE, Perl, Ruby 1.9 Die PCRE muss mit UTF-8-Unterstützung kompiliert werden, damit man die UnicodeEigenschaften (‹\p{...}›) verwenden kann. In PHP schalten Sie die UTF-8-Unterstützung mit dem Muster-Modifikator /u ein. JavaScript, Python und Ruby 1.8 unterstützen keine Unicode-Eigenschaften. Die gleich folgende Regex für Namen in XML 1.1 nutzt keine Unicode-Eigenschaften und ist daher eine gute Alternative, wenn Sie eine dieser Programmiersprachen verwenden. In „Diskussion“ auf Seite 469 in diesem Rezept wird genauer erläutert, warum Sie sowieso besser die XML 1.1-Lösung nutzen sollten, auch wenn Ihre Regex-Variante Unicode-Eigenschaften unterstützt.<br /> <br /> Namen in XML 1.1 (exakt) Hier finden Sie drei Versionen des gleichen regulären Ausdrucks für verschiedene RegexVarianten. Der einzige Unterschied zwischen den ersten beiden sind die verwendeten Anker am Anfang und Ende der Muster. Die dritte Version nutzt ‹\x{...}› statt ‹\u›, um Unicode-Codepoints zu definieren, die größer als (hexadezimal) FF sind (das entspricht einer dezimalen 255). \A[:_A-Za-z\xC0-\xD6\xD8-\xF6\xF8-\u02FF\u0370-\u037D\u037F-\u1FFF\u200C \u200D\u2070-\u218F\u2C00-\u2FEF\u3001-\uD7FF\uF900-\uFDCF\uFDF0-\uFFFD] [:_\-.A-Za-z0-9\xB7\xC0-\xD6\xD8-\xF6\xF8-\u036F\u0370-\u037D\u037F-\u1FFF \u200C\u200D\u203F\u2040\u2070-\u218F\u2C00-\u2FEF\u3001-\uD7FF\uF900\uFDCF\uFDF0-\uFFFD]*\Z<br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, Python, Ruby 1.9 ^[:_A-Za-z\xC0-\xD6\xD8-\xF6\xF8-\u02FF\u0370-\u037D\u037F-\u1FFF\u200C \u200D\u2070-\u218F\u2C00-\u2FEF\u3001-\uD7FF\uF900-\uFDCF\uFDF0-\uFFFD] [:_\-.A-Za-z0-9\xB7\xC0-\xD6\xD8-\xF6\xF8-\u036F\u0370-\u037D\u037F-\u1FFF \u200C\u200D\u203F\u2040\u2070-\u218F\u2C00-\u2FEF\u3001-\uD7FF\uF900\uFDCF\uFDF0-\uFFFD]*$<br /> <br /> Regex-Optionen: Keine (^ und $ passen auf Zeilenumbrüche darf nicht aktiv sein) Regex-Varianten: .NET, Java, JavaScript, Python<br /> <br /> 468 | Kapitel 8: Markup und Datenaustausch<br /> <br /> \A[:_A-Za-z\xC0-\xD6\xD8-\xF6\xF8-\x{2FF}\x{370}-\x{37D}\x{37F}-\x{1FFF} \x{200C}\x{200D}\x{2070}-\x{218F}\x{2C00}-\x{2FEF}\x{3001}-\x{D7FF} \x{F900}-\x{FDCF}\x{FDF0}-\x{FFFD}][:_\-.A-Za-z0-9\xB7\xC0-\xD6\xD8-\xF6 \xF8-\x{36F}\x{370}-\x{37D}\x{37F}-\x{1FFF}\x{200C}\x{200D}\x{203F} \x{2040}\x{2070}-\x{218F}\x{2C00}-\x{2FEF}\x{3001}-\x{D7FF}\x{F900}\x{FDCF}\x{FDF0}-\x{FFFD}]*\Z<br /> <br /> Regex-Optionen: Keine Regex-Varianten: PCRE, Perl Die PCRE muss mit UTF-8-Unterstützung kompiliert werden, um die Metafolgen ‹\x{...}› zu unterstützen, die für Werte größer als FF (hexadezimal) benötigt werden. In PHP schalten Sie die UTF-8-Unterstützung mit dem Muster-Modifikator /u ein. Ruby 1.8 unterstützt überhaupt keine Unicode-Regexes, aber im Abschnitt „Variationen“ auf Seite 472 dieses Rezepts finden Sie eine mögliche alternative Lösung, die etwas weniger genau ist. Auch wenn wir behauptet haben, diese regulären Ausdrücke würden die Regeln für XML 1.1-Namen exakt abbilden, gilt das tatsächlich nur für Zeichen, die sich mit 16 Bit abbilden lassen (Positionen 0x0 bis 0xFFFF). XML 1.1 erlaubt aber auch noch die 917.503 Codepoints zwischen den Positionen 0x10000 und 0xEFFFF als Zeichen nach dem ersten Zeichen. Allerdings sind überhaupt nur die PCRE, Perl und Python dazu in der Lage, Codepoints über 0xFFFF anzusprechen, und Sie werden solche Zeichen normalerweise gar nicht zu Gesicht bekommen (was auch daran liegen mag, dass ein Großteil der Positionen in diesem Bereich noch gar kein Zeichen hat). Wenn Sie diese zusätzlichen Codepoints ebenfalls berücksichtigen müssen, können Sie in der PCRE und Perl am Ende der zweiten Zeichenklasse die Regex ‹\x{10000}-\x{EFFFF}› sowie in Python die Regex ‹\U00010000-\U000EFFFF› ergänzen (beachten Sie das große U, auf das acht hexadezimale Ziffern folgen müssen). Aber selbst ohne diesen riesigen zusätzlichen Bereich ist die Liste der erlaubten Zeichen in XML 1.1 deutlich größer als in XML 1.0.<br /> <br /> Diskussion Da sich viele der regulären Ausdrücke in diesem Kapitel um das Finden von XML-Elementen drehen, geht es in diesem Rezept vor allem darum, genauere Muster vorzustellen und zu erläutern, die zum Finden von Tag-Namen und Attributnamen genutzt werden können. Ansonsten verwenden wir aus Gründen der Lesbarkeit und Effizienz meist einfachere Muster, die weniger genau sind. Lassen Sie uns also ein bisschen tiefer in die Regeln hinter diesen Mustern einsteigen.<br /> <br /> Namen in XML 1.0 Die Spezifikation von XML 1.0 nutzt eine Whitelist für ihre Namensregeln und führt explizit alle Zeichen auf, die zulässig sind. Das erste Zeichen eines Namens kann ein Doppelpunkt (:), ein Unterstrich (_) oder (annähernd) jedes Zeichen aus einer der folgenden Unicode-Kategorien sein:<br /> <br /> 8.4 XML-Namen finden | 469<br /> <br /> • Kleinbuchstaben (Ll) • Großbuchstaben (Lu) • Wortanfangs-Buchstaben (Lt) • Buchstaben ohne Möglichkeit der Groß-/Kleinschreibung (Lo) • Buchstabe und Zahl (Nl) Nach dem ersten Zeichen sind zusätzlich der Bindestrich (-), der Punkt (.) und jedes Zeichen aus den folgenden Kategorien erlaubt: • Kombinationszeichen (M), zu denen die Unterkategorien Kombinationszeichen ohne eigene Breite (Mn), Kombinationszeichen mit eigener Breite (Mc) und umschließende Kombinationszeichen (Me) gehören • Sonderzeichen als Buchstaben (Lm) • Dezimalziffern (Nd) Diese Regeln führen uns zu dem regulären Ausdruck aus „Lösung“ auf Seite 467 in diesem Rezept. Hier eine Freiform-Version: \A [:_\p{Ll}\p{Lu}\p{Lt}\p{Lo}\p{Nl}] [:_\-.\p{L}\p{M}\p{Nd}\p{Nl}]* \Z<br /> <br /> # # # #<br /> <br /> String-Anfang Erstes Zeichen Weitere Zeichen (null oder mehr) String-Ende<br /> <br /> Regex-Optionen: Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Ruby 1.9 Auch hier muss die PCRE wieder mit UTF-8-Unterstützung kompiliert werden. In PHP schalten Sie die UTF-8-Unterstützung mit dem Muster-Modifikator /u ein. Beachten Sie, dass in der zweiten Zeichenklasse alle Buchstaben-Unterkategorien (Ll, Lu, Lt, Lo und Lm) mit ‹\p{L}› in ihrer übergeordneten Kategorie zusammengefasst wurden. Weiter oben haben wir erwähnt, dass die hier beschriebenen Regeln nicht ganz exakt sind. Dafür gibt es ein paar Gründe. Erstens führt die XML 1.0-Spezifikation (denken Sie daran, dass wir hier nicht über die fünfte Edition reden) eine Reihe von Ausnahmen zu diesen Regeln auf. Und zweitens entstanden die Zeichenlisten von XML 1.0 auf Basis von Unicode 2.0, das 1996 veröffentlicht wurde. Neuere Versionen des Unicode-Standards haben neue Schriftsysteme aufgenommen, deren Zeichen nach den Regeln in XML 1.0 nicht erlaubt sind. Aber wenn man die Regex unabhängig von der in Ihrer Engine genutzten Unicode-Version machen will, um Übereinstimmungen auf Zeichen aus Unicode 2.0 zu begrenzen, erhält man riesige Monster-Regexes mit Hunderten von Bereichen und Codepoints. Wollen Sie diese Monster wirklich erstellen, lesen Sie im Artikel des World Wide Web Consortium (W3C): XML 1.0, Fourth Edition (http://www.w3.org/TR/2006/ REC-xml-20060816) den Abschnitt 2.3, „Common Syntactic Constructs”, und den Anhang B, „Character Classes“. Im Folgenden finden Sie eine Reihe von Möglichkeiten für bestimmte Varianten, die oben gezeigten Regexes zu verkürzen.<br /> <br /> 470 | Kapitel 8: Markup und Datenaustausch<br /> <br /> In Perl und der PCRE können Sie die Kleinbuchstaben (Ll), Großbuchstaben (Lu) und Titelbuchstaben (Lt) gemeinsam über die Spezialkategorie „Buchstaben mit Groß-/Kleinschreibung“ (L&) nutzen. Bei diesen Regex-Varianten können Sie auch die geschweiften Klammern in der Maskierungsfolge ‹\p{...}› weglassen, wenn nur ein Buchstaben darin steht. Wir nutzen dies in der folgenden Regex aus, indem wir ‹\pL\pM› statt ‹\p{L}\p{M}› verwenden: \A[:_\p{L&}\p{Lo}\p{Nl}][:_\-.\pL\pM\p{Nd}\p{Nl}]*\Z<br /> <br /> Regex-Optionen: Keine Regex-Varianten: PCRE, Perl .NET unterstützt die Subtraktion von Zeichenklassen, die hier in der ersten Zeichenklasse genutzt wird, um die Unterkategorie Lm von L abzuziehen, statt explizit alle anderen Zeichen-Unterkategorien aufzuführen: \A[:_\p{L}\p{Nl}-[\p{Lm}]][:_\-.\p{L}\p{M}\p{Nd}\p{Nl}]*\Z<br /> <br /> Regex-Optionen: Keine Regex-Variante: .NET In Java können Sie wie bei der PCRE und in Perl die geschweiften Klammern weglassen, wenn Sie Unicode-Kategorien mit nur einem Zeichen verwenden. Die folgende Regex nutzt zudem den etwas komplizierteren Weg der Zeichenklassensubtraktion (über die Schnittmenge mit einer negierten Klasse), um die Unterkategorie Lm von L abzuziehen: \A[:_\pL\p{Nl}&&[^\p{Lm}]][:_\-.\pL\pM\p{Nd}\p{Nl}]*\Z<br /> <br /> Regex-Optionen: Keine Regex-Variante: Java JavaScript, Python und Ruby 1.8 unterstützen keine Unicode-Kategorien. Ruby 1.9 weist keines der hier beschriebenen schicken Features auf, aber Sie können dort die portablere Version dieser Regexes aus „Lösung“ auf Seite 467 nutzen.<br /> <br /> Namen in XML 1.1 Bei XML 1.0 wurde der Fehler gemacht, es explizit mit Unicode 2.0 zu verknüpfen. Neuere Versionen des Unicode-Standards bieten viel mehr Zeichen, von denen manche aus Schriftsystemen stammen, die vorher noch gar nicht berücksichtigt wurden (zum Beispiel Cherokee, Äthiopisch und Mongolisch). Da XML als universelles Format gesehen werden will, wurde versucht, das Problem mit XML 1.1 und XML 1.0 Fifth Edition zu beheben. Diese neueren Versionen wechselten für die Zeichen in Namen von einer Whitelist zu einer Blacklist, um nicht nur die seit Unicode 2.0 hinzugekommenen Zeichen zu unterstützen, sondern auch alle, die noch in Zukunft ergänzt werden. Diese neue Strategie, alles zu erlauben, was nicht explizit verboten ist, verbessert die zukünftige Kompatibilität und macht es leichter und weniger aufwendig, den Regeln exakt zu folgen. Das ist der Grund dafür, dass Regexes für XML 1.1-Namen als „exakt“ bezeichnet werden, während die Regex für XML 1.0 nur eine Näherung ist.<br /> <br /> 8.4 XML-Namen finden | 471<br /> <br /> Variationen In manchen der Rezepte aus diesem Kapitel (zum Beispiel Rezept 8.1) sorgen die Musterabschnitte für XML-Namen entweder für gar keine Einschränkungen, oder sie verbieten fremde Schriftsysteme und andere Zeichen, die eigentlich gültig wären. Das wurde gemacht, damit es nicht zu kompliziert wird. Aber wenn Sie fremde Schriftsysteme zulassen und zugleich grundlegende Einschränkungen beibehalten wollen (und Sie die deutlich genauere Validierung von Namen aus den vorherigen Regexes in diesem Rezept nicht benötigen), können die folgenden Regexes vielleicht genau das Richtige für Sie sein. Wir haben bei diesen Regexes die Anker für String-Anfang und -Ende weggelassen, da sie nicht dafür gedacht sind, allein genutzt zu werden, sondern Teil eines längeren Musters sein sollen.<br /> <br /> Bei dieser ersten Regex wird einfach vermieden, Zeichen zu finden, die in XML-Tags als Trennzeichen oder Begrenzungszeichen dienen. Zudem ist eine Ziffer als erstes Zeichen nicht erlaubt: [^\d\s"'/<=>][^\s"'/<=>]*<br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Hier eine andere, noch kürzere Version. Statt zwei getrennte Zeichenklassen zu verwenden, wird ein negatives Lookahead genutzt, um eine Ziffer als erstes Zeichen zu verbieten. Diese Einschränkung gilt nur für das erste gefundene Zeichen, auch wenn durch den Quantor ‹+› nach der Zeichenklasse die Regex unbegrenzt viele Zeichen finden kann: (?!\d)[^\s"'/<=>]+<br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby<br /> <br /> Siehe auch John Cowan, einer der Autoren der XML 1.1-Spezifikation, erläutert in einem BlogArtikel, welche Zeichen in XML 1.1-Namen verboten sind und warum das so ist: http:// recycledknowledge.blogspot.com/2008/02/which-characters-are-excluded-in-xml.html. Das Dokument „Background to Changes in XML 1.0, 5th Edition“ unter http://www. w3.org/XML/2008/02/xml10_5th_edition_background.html behandelt die Gründe für das Herunterportieren der Namensregeln aus XML 1.1 nach XML 1.0 Fifth Edition.<br /> <br /> 472 | Kapitel 8: Markup und Datenaustausch<br /> <br /> 8.5<br /> <br /> Einfachen Text durch Ergänzen von <p>- und <br>- Tags nach HTML konvertieren<br /> <br /> Problem Sie haben einfachen Text, zum Beispiel einen mehrzeiligen Text, der über ein TextareaFeld in einem Formular eingegeben wurde. Diesen wollen Sie in einen HTML-Text umwandeln, um ihn auf einer Webseite anzuzeigen. Absätze, die durch zwei aufeinanderfolgende Zeilenumbrüche getrennt sind, sollen durch <p>...</p> umschlossen werden. Zusätzliche Zeilenumbrüche sollen durch <br>-Tags ersetzt werden.<br /> <br /> Lösung Dieses Problem kann in vier einfachen Schritten gelöst werden. In den meisten Programmiersprachen profitieren nur die mittleren beiden Schritte von regulären Ausdrücken.<br /> <br /> Schritt 1: HTML-Sonderzeichen durch Zeichenreferenzen ersetzen Wenn wir einfachen Text nach HTML konvertieren, müssen wir zunächst die drei speziellen HTML-Zeichen &, < und > in Zeichenreferenzen umwandeln (siehe Tabelle 8-3). Ansonsten kann das Markup zu ungewollten Ergebnissen führen, wenn es in einem Webbrowser angezeigt wird. Tabelle 8-3: Spezielle Zeichen in HTML und ihr Ersatz Suchen nach<br /> <br /> Ersetzen durch<br /> <br /> ‹&›<br /> <br /> «&»<br /> <br /> ‹<›<br /> <br /> «<»<br /> <br /> ‹>›<br /> <br /> «>»<br /> <br /> Das Kaufmanns-Und (&) muss zuerst ersetzt werden, da Sie dem Ausgangstext zusätzliche Kaufmanns-Und-Zeichen als Teil der Zeichenreferenzen hinzufügen.<br /> <br /> Schritt 2: Alle Zeilenumbrüche durch <br> ersetzen Suchen nach: \r\n?|\n<br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby \R<br /> <br /> Regex-Optionen: Keine Regex-Varianten: PCRE 7, Perl 5.10<br /> <br /> 8.5 Einfachen Text durch Ergänzen von <p>- und <br>- Tags nach HTML konvertieren |<br /> <br /> 473<br /> <br /> Ersetzen durch: <br><br /> <br /> Ersetzungstextvarianten: .NET, Java, JavaScript, Perl, PHP, Python, Ruby<br /> <br /> Schritt 3: Doppelte <br>-Tags durch </p><p> ersetzen Suchen nach: <br>\s*<br><br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Ersetzen durch: </p><p><br /> <br /> Ersetzungstextvarianten: .NET, Java, JavaScript, Perl, PHP, Python, Ruby<br /> <br /> Schritt 4: Kompletten String mit <p>...</p> umschließen Dieser Schritt ist eine einfache String-Verkettung und erfordert keine regulären Ausdrücke.<br /> <br /> JavaScript-Beispiel Um alle vier Schritte zu kombinieren, erstellen wir eine JavaScript-Funktion namens html_from_plaintext. Diese Funktion erwartet einen String, den sie in den eben beschriebenen Schritten verarbeitet. Dann gibt sie den neuen HTML-String zurück: function html_from_plaintext (subject) { // Schritt 1 (Suche im Ausgangstext) subject = subject.replace(/&/g, "&"). replace(/</g, "<"). replace(/>/g, ">"); // Schritt 2 subject = subject.replace(/\r\n?|\n/g, "<br>"); // Schritt 3 subject = subject.replace(/<br>\s*<br>/g, "</p><p>"); // Schritt 4 subject = "<p>" + subject + "</p>"; return subject; } /* html_from_plaintext("Test.") html_from_plaintext("Test.\n") html_from_plaintext("Test.\n\n") html_from_plaintext("Test1.\nTest2.") html_from_plaintext("Test1.\n\nTest2.") html_from_plaintext("< AT&T >") */<br /> <br /> 474 | Kapitel 8: Markup und Datenaustausch<br /> <br /> -> -> -> -> -> -><br /> <br /> "<p>Test.</p>" "<p>Test.<br></p>" "<p>Test.</p><p></p>" "<p>Test1.<br>Test2.</p>" "<p>Test1.</p><p>Test2.</p>" "<p>< AT&T ></p>"<br /> <br /> Am Ende des Codes sind eine Reihe von Beispielen aufgeführt, die zeigen, was diese Funktion mit den verschiedenen Ausgangstexten anstellt. Falls Sie mit JavaScript nicht vertraut sind, sollten Sie darauf achten, dass der Modifikator /g am Ende jedes RegexLiterals die replace-Methode dazu bringt, nicht nur das erste, sondern alle Vorkommen des Musters zu ersetzen. Die Metafolge \n im Beispiel-String fügt in einen JavaScriptString einen literalen Zeilenumbruch (ASCII-Zeichen 0x0A) ein.<br /> <br /> Diskussion Schritt 1: HTML-Sonderzeichen durch Zeichenreferenzen ersetzen Dieser Schritt lässt sich am einfachsten umsetzen, indem man drei aufeinanderfolgende Ersetzungsvorgänge durchführt (in Tabelle 8-3 weiter oben sind die auszutauschenden Texte aufgeführt). In JavaScript werden immer reguläre Ausdrücke für globale Ersetzungsvorgänge genutzt, aber in anderen Programmiersprachen werden Sie meist eine bessere Performance erzielen, wenn Sie normale Strings verwenden.<br /> <br /> Step 2: Alle Zeilenumbrüche durch <br> ersetzen In diesem Schritt verwenden wir den regulären Ausdruck ‹\r\n?|\n›, um Zeilenumbrüche zu finden, die den Konventionen von Windows/MS-DOS (CRLF), Unix/Linux/OS X (LF) und dem alten Mac OS (CR) folgen. Benutzer von Perl 5.10 und der PCRE 7 können das Token ‹\R› verwenden (beachten Sie das große R), um diese und andere Zeilenumbruchfolgen zu finden. Ersetzt man alle Zeilenumbrüche durch <br>, bevor man im nächsten Schritt Absatz-Tags hinzufügt, wird der gesamte Vorgang einfacher, da Sie damit in folgenden Ersetzungen zwischen Ihren </p><p>-Tags zusätzlichen Whitespace einfügen können. Damit bleibt ihr HTML-Code lesbar, weil nicht alles direkt aneinandergefügt ist. Wenn Sie lieber die Singleton-Tags im XHTML-Stil nutzen wollen, verwenden Sie «<brz/>» statt «<br>» als Ersetzungstext. Sie werden dann auch den regulären Ausdruck aus Schritt 3 anpassen müssen.<br /> <br /> Schritt 3: Doppelte <br>-Tags durch </p><p> ersetzen Zwei direkt aufeinanderfolgende Zeilenumbrüche zeigen, dass ein Absatz endet und ein neuer beginnt, daher ist unser Ersetzungstext für diesen Schritt ein schließendes </p>Tag, auf das ein öffnendes <p> folgt. Enthält der Ausgangstext nur einen Absatz (das heißt, es gibt keine zwei Zeilenumbrüche hintereinander), wird keine Ersetzung vorgenommen. In Schritt 2 wurden bereits diverse Zeilenumbruchszeichen ersetzt (und nur <br>-Tags zurückgelassen), sodass dieser Schritt durch eine einfache Textersetzung durchgeführt werden kann. Aber mithilfe einer Regex können wir noch einen Schritt weitergehen und Whitespace ignorieren, der zwischen Zeilenumbrüchen steht. Alle zusätzlichen Leerzeichen würden in einem HTML-Dokument sowieso nicht gerendert werden.<br /> <br /> 8.5 Einfachen Text durch Ergänzen von <p>- und <br>- Tags nach HTML konvertieren |<br /> <br /> 475<br /> <br /> Wenn Sie XHTML generieren und daher die Zeilenumbrüche durch «<brz/>» statt durch «<br>» ersetzt haben, müssen Sie als Regex in diesem Schritt ‹<brz/>\s*<brz/>› verwenden.<br /> <br /> Schritt 4: Kompletten String mit <p>...</p> umschließen In Schritt 3 wurden nur Tags zwischen den Absätzen eingefügt. Jetzt brauchen wir noch ein <p>-Tag ganz am Anfang des Texts und ein schließendes </p> ganz am Ende. Damit ist die Verarbeitung abgeschlossen – egal ob es einen oder hundert Absätze im Text gab.<br /> <br /> Siehe auch In Rezept 4.10 finden Sie mehr Informationen über das Token ‹\R› in Perl und der PCRE. Zudem wird dort beschrieben, wie Sie die zusätzlichen esoterischen Zeilentrenner per Hand ergänzen können, die durch ‹\R› automatisch gefunden werden.<br /> <br /> 8.6<br /> <br /> Ein bestimmtes Attribut in Tags im XML-Stil finden<br /> <br /> Problem Sie wollen Tags in einer (X)HTML- oder XML-Datei finden, die ein bestimmtes Attribut enthalten, zum Beispiel id. Dieses Rezept behandelt verschiedene Versionen des gleichen Problems. Wir wollen hier mithilfe regulärer Ausdrücke jeden der folgenden Strings finden: • Tags mit einem Attribut id. • <div>-Tags mit einem Attribut id. • Tags mit einem Attribut id, das den Wert my-id hat. • Tags mit dem Attribut class, in dem my-class enthalten ist (Klassen werden durch Whitespace getrennt).<br /> <br /> Lösung Tags mit einem Attribut id (quick and dirty) Wenn Sie nur schnell in einem Texteditor suchen wollen, in dem Sie die Ergebnisse begutachten können, kann die folgende (deutlich zu sehr vereinfachte) Regex helfen: <[^>]+\sid\b[^>]*><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby<br /> <br /> 476 | Kapitel 8: Markup und Datenaustausch<br /> <br /> Hier die Regex noch mal im Freiform-Modus: < [^>]+ \s id \b [^>]* ><br /> <br /> # # # # #<br /> <br /> Anfang des Tags Tag-Name, Attribute usw. Der gewünschte Attributname als ganzes Wort Der Rest des Tags, einschließlich des Werts von id Ende des Tags<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby<br /> <br /> Tags mit einem Attribut id (zuverlässiger) Anders als die eben gezeigte Regex berücksichtigt die nächste für das gleiche Problem auch literale >-Zeichen in Anführungszeichen. Zudem vermeidet sie Tags, die das Wort id in einem der Attributwerte enthalten: <(?:[^>"']|"[^"]*"|'[^']*')+?\sid\s*=\s*("[^"]*"|'[^']*') (?:[^>"']|"[^"]*"|'[^']*')*><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Im Freiform-Modus: < (?: [^>"'] | "[^"]*" | '[^']*' )+? \s id \s* = \s* ( "[^"]*" | '[^']*' ) (?: [^>"'] | "[^"]*" | '[^']*' )* ><br /> <br /> # # # # # # # # # # # # #<br /> <br /> Tag- und Attributnamen usw. ...und Attributwerte in Anführungszeichen<br /> <br /> Der gewünschte Attributname als ganzes Wort Trennzeichen zwischen Name und Wert Attributwert in Rückwärtsreferenz 1 einfangen Restliche Zeichen ... und Attributwerte in Anführungszeichen<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Diese Regex fängt den Wert des Attributs id und die umschließenden Anführungszeichen in der Rückwärtsreferenz 1 ein. Damit können Sie diesen Wert in Code außerhalb der Regex oder in einem Ersetzungstext verwenden. Wenn Sie den Wert nicht benötigen, können Sie die Gruppe in eine nicht-einfangende Gruppe umwandeln oder die gesamte Folge ‹\s*=\s*("[^"]*"|'[^']*')› durch ‹\b› ersetzen. Die restlichen Teile der Regex kümmern sich dann auch um den Wert des Attributs id.<br /> <br /> <div>-Tags mit einem Attribut id Um nach einem bestimmten Tag zu suchen, müssen Sie dessen Namen am Anfang der Regex unterbringen und ein paar weitere kleinere Änderungen vornehmen. Im folgenden<br /> <br /> 8.6 Ein bestimmtes Attribut in Tags im XML-Stil finden |<br /> <br /> 477<br /> <br /> Beispiel haben wir nach dem öffnenden ‹<› die Regex um ‹div\s› ergänzt. Das Token ‹\s› (Whitespace) stellt sicher, dass wir keine anderen Tags finden, deren Namen mit den drei Buchstaben „div“ beginnen. Wir wissen, dass nach dem Tag-Namen ein Whitespace-Zeichen folgen muss, da die Tags, nach denen wir suchen, mindestens ein Attribut (id) besitzen. Zudem wurde die Folge ‹+?\sid› nach ‹*?\bid› geändert, sodass die Regex auch dann funktioniert, wenn id das erste Attribut im Tag ist und es (neben dem ersten Leerzeichen) keine zusätzlichen Trennzeichen nach dem Tag-Namen gibt: <div\s(?:[^>"']|"[^"]*"|'[^']*')*?\bid\s*=\s*("[^"]*"|'[^']*') (?:[^>"']|"[^"]*"|'[^']*')*><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Im Freiform-Modus: <div \s (?: [^>"'] | "[^"]*" | '[^']*' )*? \b id \s* = \s* ( "[^"]*" | '[^']*' ) (?: [^>"'] | "[^"]*" | '[^']*' )* ><br /> <br /> # # # # # # # # # # # # #<br /> <br /> Tag-Name und folgendes Whitespace-Zeichen Attributnamen usw. ... und Attributwerte in Anführungszeichen<br /> <br /> Der gesuchte Attributname als ganzes Wort Trennzeichen zwischen Name und Wert Einfangen des Werts in Rückwärtsreferenz 1 Restliche Zeichen ... und Attributwerte in Anführungszeichen<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby<br /> <br /> Tags mit einem Attribut id, das den Wert „my-id“ hat Im Unterschied zur Regex aus „Tags mit einem Attribut id (zuverlässiger)“ auf Seite 477 entfernen wir hier die einfangende Gruppe um den Wert des Attributs id, da wir ihn ja schon im Voraus kennen. Insbesondere wurde das Untermuster ‹("[^"]*"|'[^']*')› ersetzt durch ‹(?:"my-id"|'my-id')›: <(?:[^>"']|"[^"]*"|'[^']*')+?\sid\s*=\s*(?:"my-id"|'my-id') (?:[^>"']|"[^"]*"|'[^']*')*><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Im Freiform-Modus: < (?: [^>"'] | "[^"]*" | '[^']*' )+?<br /> <br /> # # Tag- und Attributnamen usw. # ... und Attributwerte in Anführungszeichen # #<br /> <br /> 478 | Kapitel 8: Markup und Datenaustausch<br /> <br /> \s id \s* = \s* (?: "my-id" | 'my-id' ) (?: [^>"'] | "[^"]*" | '[^']*' )* ><br /> <br /> # # # # # # # # #<br /> <br /> Gesuchter Attributname als ganzes Wort Trennzeichen zwischen Name und Wert Gesuchter Attributwert ... in einfachen oder doppelten Anführungszeichen Restliche Zeichen ... und Attributwerte in Anführungszeichen<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Schauen wir uns kurz noch mal das Untermuster ‹(?:"my-id"|'my-id')› an. Sie können (mit etwas geringerer Effizienz) die Wiederholung von „my-id“ verhindern, indem Sie ‹(["'])my-id\1› nutzen. Dabei werden eine einfangende Gruppe und eine Rückwärtsreferenz genutzt, um sicherzustellen, dass der Wert mit der gleichen Art von Anführungszeichen beginnt und endet.<br /> <br /> Tags mit dem Attribut „class”, in dem „my-class“ enthalten ist Wenn die vorherigen regulären Ausdrücke nicht schon diese Grenze überschritten haben, so ist es spätestens hier der Fall – es ist nicht mehr sinnvoll, dieses Problem mit nur einer Regex zu lösen. Nutzt man mehrere Regexes, wird es ein bisschen einfacher, daher teilen wir diese Suche in drei Teile auf. Die erste Regex wird Tags finden, die nächste das Attribut class im Tag suchen (und dessen Wert in einer Rückwärtsreferenz speichern), und mit dem dritten werden wir schließlich nach dem Wert my-class suchen. Tags finden: <(?:[^>"']|"[^"]*"|'[^']*')+><br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby In Rezept 8.1 dreht sich alles darum, Tags im XML-Stil zu finden. Dort wird beschrieben, wie die gerade gezeigte Regex arbeitet. Zudem finden Sie dort eine Reihe von Alternativen mit unterschiedlichen Komplexitätsgraden und Genauigkeitsanforderungen.<br /> <br /> Als Nächstes folgt der Code aus Rezept 3.13, um innerhalb jeder Übereinstimmung nach einem Attribut class zu suchen, und zwar mit folgender Regex: ^(?:[^>"']|"[^"]*"|'[^']*')+?\sclass\s*=\s*(?:"([^"]*)"|'([^']*)')<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Damit wird der gesamte Wert von class zusammen mit seinen umgebenden Anführungszeichen in einer der Rückwärtsreferenzen 1 oder 2 gespeichert – abhängig davon, ob sie in doppelten oder einfachen Anführungszeichen geschrieben war. Alles vor dem Attribut<br /> <br /> 8.6 Ein bestimmtes Attribut in Tags im XML-Stil finden |<br /> <br /> 479<br /> <br /> class wird durch ‹^(?:[^>"']|"[^"]*"|'[^']*')+?› gefunden. Dabei werden Werte in<br /> <br /> Anführungszeichen in einem Schritt gefunden, damit nicht unabsichtlich das Wort „class“ im Wert eines anderen Attributs berücksichtigt wird. Auf der rechten Seite des Musters endet die Übereinstimmung, sobald das Ende des Attributwerts von class gefunden ist. Was danach kommt, ist für unsere Suche irrelevant, daher gibt es keinen Grund, bis zum Ende des Tags noch nach irgendetwas zu suchen. Der Zirkumflex am Anfang der Regex verankert diese mit dem Anfang des Ausgangstexts. Dadurch verändert sich zwar nicht das Suchergebnis, aber wenn die Regex kein Ergebnis am Anfang des Strings findet, versucht sie es nicht noch an den folgenden Positionen (wo sie keinen Erfolg haben würde). Wenn schließlich beide vorigen Regexes etwas gefunden haben, werden Sie in den beiden Rückwärtsreferenzen 1 und 2 der zweiten Regex-Übereinstimmung mithilfe des folgenden Musters suchen wollen: (?:^|\s)my-class(?:\s|$)<br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Da Klassen durch Whitespaces getrennt sind, muss my-class auf beiden Seiten entweder durch Whitespace begrenzt sein, oder es befindet sich am Anfang oder Ende des Texts. Dürften Klassennamen keine Bindestriche enthalten, könnten wir statt der beiden nichteinfangenden Gruppen einfach Wortgrenzen nutzen. Aber da Bindestriche auch für Wortgrenzen sorgen, würde ‹\bmy-class\b› auch auf not-my-class passen.<br /> <br /> Diskussion Die „Lösung“ in diesem Rezept beschreibt schon, wie die Regexes arbeiten, daher werden wir hier nicht alles noch einmal wiederholen. Denken Sie daran, dass regulären Ausdrücke oft nicht die ideale Lösung für Suchen in Markup-Texten sind, insbesondere wenn man eine Komplexität wie in diesem Rezept erreicht. Bevor Sie diese regulären Ausdrücke nutzen, sollten Sie sich überlegen, ob Sie nicht mit einer anderen Lösung besser bedient sind. Denn es gibt XPath, einen SAX-Parser oder ein DOM. Wir haben diese Regexes hier mit aufgenommen, weil durchaus auch immer wieder versucht wird, auf diesem Weg vorzugehen. Aber sagen Sie danach nicht, wir hätten Sie nicht gewarnt. Hoffentlich wurde Ihnen damit zumindest deutlich, was für Fallstricke es bei der Suche in Markup-Dateien geben kann und dass man nicht zu naiv an diese Suche herangehen sollte.<br /> <br /> Siehe auch In Rezept 8.7 wird beschrieben, wie man das Gegenteil von dem erreicht, was hier getan wurde – Tags finden, die ein bestimmtes Attribut nicht enthalten.<br /> <br /> 480 | Kapitel 8: Markup und Datenaustausch<br /> <br /> 8.7<br /> <br /> Tags vom Typ <table> ein Attribut „cellspacing“ hinzufügen, die es noch nicht haben<br /> <br /> Problem Sie wollen eine (X)HTML-Datei durchsuchen und alle Tabellen um cellspacing="0" ergänzen, wenn sie noch kein Attribut cellspacing besitzen. Dieses Rezept dient als Beispiel dafür, wie man Tags im XML-Stil ein Attribut hinzufügen kann, das sie noch nicht haben. Sie können sowohl das Tag als auch Attributnamen und -werte beliebig austauschen.<br /> <br /> Lösung Regex 1: Stark vereinfachte Lösung Mit einem negativen Lookahead können Sie <table>-Tags finden, die das Wort cellspacing nicht enthalten: <table\b(?![^>]*?\scellspacing\b)([^>]*)><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Im Freiform-Modus: <table \b (?! [^>] *? \s cellspacing \b ) ( [^>] * ) ><br /> <br /> # # # # # # # # # # #<br /> <br /> Finden von "<table", gefolgt von einer Wortgrenze Sicherstellen, dass die folgende Regex nicht gefunden werden kann Alle Zeichen außer ">" finden ... null Mal oder häufiger, aber so wenig wie möglich (genügsam) "cellspacing" als vollständiges Wort finden Die folgende Regex als Rückwärtsreferenz 1 einfangen Alle Zeichen außer ">" finden ... null Mal oder häufiger, aber so oft wie möglich (gierig) Ein literales ">" als Tag-Ende finden<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby<br /> <br /> Regex 2: Zuverlässigere Lösung Die folgende Regex ersetzt die beiden Instanzen der negierten Zeichenklasse ‹[^>]› aus der vereinfachten Lösung durch ‹(?:[^>"']|"[^"]*"|'[^']*')›. Damit wird die Zuverlässigkeit der Regex doppelt verbessert. Erstens werden jetzt auch Attributwerte in Anführungszeichen korrekt übersprungen, die ein literales „>“ enthalten. Und zweitens wird sichergestellt, dass keine Tags gefunden werden, die das Wort „cellspacing“ in einem ihrer Attributwerte enthalten.<br /> <br /> 8.7 Tags vom Typ <table> ein Attribut „cellspacing“ hinzufügen, die es noch nicht haben | 481<br /> <br /> So sieht die Regex mit den eben beschriebenen Änderungen aus: <table\b(?!(?:[^>"']|"[^"]*"|'[^']*')*?\scellspacing\b) ((?:[^>"']|"[^"]*"|'[^']*')*)><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Und hier im Freiform-Modus: <table \b (?! (?: [^>"'] | "[^"]*" | '[^']*' )*? \s cellspacing \b ) ( (?: [^>"'] | "[^"]*" | '[^']*' )* ) ><br /> <br /> # Finden von "<table", gefolgt von einer Wortgrenze # Sicherstellen, dass die folgende Regex nicht gefunden werden kann # Alle Zeichen außer >, " oder ' finden ... # oder einen Wert in doppelten Anführungszeichen # oder einen Wert in einfachen Anführungszeichen # null Mal oder häufiger, aber so wenig wie möglich (genügsam) # "cellspacing" als vollständiges Wort finden # # Die folgende Regex als Rückwärtsreferenz 1 einfangen # Alle Zeichen außer >, " oder ' finden ... # oder einen Wert in doppelten Anführungszeichen # oder einen Wert in einfachen Anführungszeichen # null Mal oder häufiger, aber so oft wie möglich (gierig) # #<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby<br /> <br /> Das neue Attribut einfügen Alle in diesem Rezept gezeigten Regexes können die gleichen Ersetzungstexte verwenden, da alle die Attribute innerhalb der gefundenen <table>-Tags (wenn denn vorhanden) in der Rückwärtsreferenz 1 speichern. Damit können Sie diese Attribute als Teil Ihres Ersetzungstextwerts wieder hinzunehmen, wenn Sie das neue Attribut cellspacing einfügen. Das sind die notwendigen Ersetzungstexte: <tablezcellspacing="0"$1><br /> <br /> Ersetzungstextvarianten: .NET, Java, JavaScript, Perl, PHP <tablezcellspacing="0"\1><br /> <br /> Ersetzungstextvarianten: Python, Ruby In Rezept 3.15 wird gezeigt, wie Sie die Ersetzungen mit einer Rückwärtsreferenz im Ersetzungstext vornehmen können.<br /> <br /> Diskussion Um zu sehen, wie diese Regexes arbeiten, wollen wir zunächst die vereinfachte Lösung unter die Lupe nehmen. Wie Sie sehen werden, besteht sie aus vier Abschnitten.<br /> <br /> 482 | Kapitel 8: Markup und Datenaustausch<br /> <br /> Der erste Teil ‹<table\b› passt auf die literalen Zeichen <table, gefolgt von einer Wortgrenze (‹\b›). Die Wortgrenze verhindert, dass Tag-Namen gefunden werden, die nur mit „table“ beginnen. Auch wenn es hier unnötig erscheint, wenn wir mit (X)HTML arbeiten (wo es zum Beispiel keine gültigen Elemente namens „tablet“, „tableau“ oder „tablespoon“ gibt), ist dies dennoch ein sinnvolles Vorgehen. Denn so vermeiden Sie Fehler, wenn Sie die Regex für andere Tags anpassen. Der zweite Teil der Regex, ‹(?![^>]*?\scellspacing\b)›, ist ein negatives Lookahead. Es konsumiert keinen Text, stellt aber sicher, dass es keine Übereinstimmung gibt, wenn irgendwo im öffnenden Tag das Wort cellspacing vorkommt. Da wir alle Übereinstimmungen um das Attribut cellspacing ergänzen wollen, soll natürlich kein Tag ergänzt werden, das schon dieses Attribut besitzt. Da der Lookahead von der aktuellen Position aus vorwärts schaut, nutzt er zunächst ‹[^>]*?›, um so weit wie nötig zu suchen – notfalls bis zum Ende des Tags (dem ersten Vorkommen von >). Der Rest des Lookahead-Submusters (‹\scellspacing\b›) passt dann<br /> <br /> einfach auf die literalen Zeichen „cellspacing“ als vollständiges Wort. Wir finden davor auch noch ein Whitespace-Zeichen (‹\s›), da diese Zeichen immer einen Attributnamen vom davorstehenden Tag-Namen oder einem anderen Attribut trennen. Am Ende suchen wir nach einer Wortgrenze statt nach einem weiteren Whitespace-Zeichen, da eine Wortgrenze ausreicht, um cellspacing als ganzes Wort zu finden, und weil sie auch dann passt, wenn das Attribut keinen Wert besitzt oder direkt danach ein Gleichheitszeichen folgt. Jetzt kommen wir zum dritten Teil der Regex: ‹([^>]*)›. Das ist eine negierte Zeichenklasse, gefolgt von einem Stern-Quantor (null oder mehr Übereinstimmungen) und umgeben von einer einfangenden Gruppe. Indem wir diesen Teil einfangen, können wir die Attribute von jedem gefundenen Tag als Teil des Ersetzungs-Strings problemlos wieder einfügen. Und anders als beim negativen Lookahead werden durch diesen Teil die Attribute innerhalb des Tags zur Übereinstimmung hinzugefügt. Schließlich passt als vierter Teil das literale Zeichen ‹>› auf das Ende des Tags. Regex 2, die „zuverlässigere“ Version, arbeitet genau so wie die eben beschriebene Regex, nur dass die beiden Vorkommen der negierten Zeichenklasse ‹[^>]› durch ‹(?:[^>"']|"[^"]*"|'[^']*')› ersetzt werden. Dieses längere Muster überspringt in einem Rutsch Attributwerte in einfachen oder doppelten Anführungszeichen. Der Ersetzungstext funktioniert mit beiden Regexes. Er ersetzt jedes gefundene <table>Tag durch ein neues Tag mit cellspacing als erstem Attribut, gefolgt von allen weiteren Attributen aus dem ursprünglichen Tag (Rückwärtsreferenz 1).<br /> <br /> Siehe auch Rezept 8.6 ist das konzeptionelle Gegenteil zu diesem Rezept. Dort wird beschrieben, wie man Tags mit einem bestimmten Attribut findet.<br /> <br /> 8.7 Tags vom Typ <table> ein Attribut „cellspacing“ hinzufügen, die es noch nicht haben | 483<br /> <br /> 8.8<br /> <br /> Kommentare im XML-Stil entfernen<br /> <br /> Problem Sie wollen Kommentare aus einem (X)HTML- oder XML-Dokument entfernen. So wollen Sie zum Beispiel die Kommentare auf einer Webseite löschen, bevor sie an den Webbrowser geschickt wird, um die Dateigröße und damit die Ladezeit für diejenigen mit einer langsamen Internetverbindung zu reduzieren.<br /> <br /> Lösung Dank der Verfügbarkeit genügsamer Kommentare ist es nicht schwierig, Kommentare zu finden. So sieht der reguläre Ausdruck dafür aus: <!--.*?--><br /> <br /> Regex-Optionen: Punkt passt auf Zeilenumbruch Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Das ist ziemlich einfach. Wie üblich muss man in JavaScript anders vorgehen. Da dort die Option Punkt passt auf Zeilenumbruch nicht vorhanden ist, müssen Sie den Punkt durch eine Zeichenklasse ersetzen, die wirklich alles findet. Denn sonst finden Sie keine Kommentare, die über mehr als eine Zeile laufen. Folgende Version funktioniert mit JavaScript: <!--[\s\S]*?--><br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Um die Kommentare zu entfernen, ersetzen Sie alle Übereinstimmungen durch den leeren String (also nichts). In Rezept 3.14 wird beschrieben, wie Sie alle Übereinstimmungen einer Regex ersetzen können.<br /> <br /> Diskussion Funktionsweise Am Anfang und Ende dieses regulären Ausdrucks befinden sich die literalen Zeichenfolgen ‹<!--› und ‹-->›. Da keines dieser Zeichen in der Regex-Syntax eine besondere Bedeutung hat (außer innerhalb von Zeichenklassen, in denen Bindestriche Bereiche beschreiben), müssen sie nicht maskiert werden. Damit bleibt nur ‹.*?› oder ‹[\s\S]*?› in der Mitte der Regex für eine genauere Untersuchung übrig. Dank der Option Punkt passt auf Zeilenumbruch passt der Punkt in der Regex auf jedes einzelne Zeichen. In der JavaScript-Version wird dafür die Zeichenklasse ‹[\s\S]›<br /> <br /> 484 | Kapitel 8: Markup und Datenaustausch<br /> <br /> genutzt. Aber die beiden Regexes erledigen genau die gleiche Aufgabe. ‹\s› passt auf jedes Whitespace-Zeichen, während ‹\S› auf alles andere passt. Zusammen wird damit jedes Zeichen gefunden. Der genügsame Quantor ‹*?› wiederholt das vorherige Element „jedes Zeichen“ null Mal oder häufiger, aber so wenig wie möglich. Daher wird dieses Token nur bis zum ersten Auftauchen von --> wiederholt. Ohne Fragezeichen würde das Token bis zum Ende des Ausgangstexts laufen, um dann per Backtracking bis zum letzten --> zurückzugehen. (In Rezept 2.13 erfahren Sie mehr über Backtracking mit genügsamen und gierigen Quantoren.) Diese einfache Strategie funktioniert gut, da Kommentare im XML-Stil nicht verschachtelt werden dürfen. Sie enden also immer nach dem ersten Auftreten von -->.<br /> <br /> Wann Kommentare nicht entfernt werden dürfen Die meisten Webentwickler sind mit HTML-Kommentaren vertraut, die innerhalb von <script>- und <style>-Elementen stehen, um eine Abwärtskompatibilität zu antiken Browsern herzustellen. Heutzutage sind das größtenteils ziemlich überflüssige Elemente, aber dank des gerne genutzten Copy-and-Paste leben sie weiter. Wir gehen davon aus, dass Sie beim Entfernen von Kommentaren das eingebettete JavaScript und CSS beibehalten wollen. Vermutlich wollen Sie auch die Inhalte von <textarea>-Elementen, CDATA-Abschnitten und Attributwerten innerhalb von Tags am Leben lassen. Weiter oben haben wir gesagt, dass es nicht schwierig ist, Kommentare zu entfernen. Das stimmt aber nur, solange Sie einige der kritischeren Bereiche von (X)HTML oder XML auslassen, in denen die Syntaxregeln anders aussehen. Mit anderen Worten: Wenn Sie die schwierigen Teile des Problems ignorieren, ist es einfach. Natürlich kann es Situationen geben, in denen Sie den Markup-Text begutachten und entscheiden, dass es durchaus in Ordnung ist, diese problematischen Fälle zu ignorieren – vielleicht weil Sie den zu durchsuchenden Text selbst geschrieben haben und wissen, was Sie erwartet. Es kann auch in Ordnung sein, wenn Sie das Ersetzen in einem Texteditor vornehmen, in dem Sie vorher sehen, was Sie austauschen wollen. Aber wie können wir das ansonsten umgehen? In „Schwierige (X)HTML- und XMLAbschnitte überspringen“ auf Seite 453 haben wir ähnliche Probleme besprochen, als es um das Finden von Tags im XML-Stil ging. Wir können hier ähnlich vorgehen, wenn wir nach Kommentaren suchen. Mit dem Code in Rezept 3.18 suchen wir zunächst mit der folgenden Regex nach den kritischen Abschnitten und ersetzen dann die Kommentare durch den leeren String nur in den Bereichen zwischen den vorher gefundenen Übereinstimmungen: <(script|style|textarea|xmp)\b(?:[^>"']|"[^"]*"|'[^']*')*? (?:/>|>.*?</\1\s*>)|<[a-z](?:[^>"']|"[^"]*"|'[^']*')*>|<!\[CDATA\[.*?]]><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Punkt passt auf Zeilenumbruch Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby<br /> <br /> 8.8 Kommentare im XML-Stil entfernen |<br /> <br /> 485<br /> <br /> Mit etwas Whitespace und ein paar Kommentaren in der Regex lässt sich das im Freiform-Modus viel besser überblicken: # Besonderes Element: Tag und Inhalt <( script | style | textarea | xmp )\b (?: [^>"'] # Attributnamen ... | "[^"]*" # ... und Werte finden | '[^']*' # )*? (?: # Singleton-Tag /> | # Ansonsten den Inhalt des Elements und das schließende Tag mit aufnehmen > .*? </\1\s*> ) | # Standard-Element: nur Tag <[a-z] # erstes Zeichen des Tag-Namen (?: [^>"'] # den Rest des Tag-Namen finden | "[^"]*" # ... zusammen mit Attributnamen | '[^']*' # ... und Werten )* > | # CDATA-Abschnitt <!\[CDATA\[ .*? ]]><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Punkt passt auf Zeilenumbruch, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Hier eine äquivalente Version für JavaScript, in dem es die Optionen Punkt passt auf Zeilenumbruch und Freiform nicht gibt: <(script|style|textarea|xmp)\b(?:[^>"']|"[^"]*"|'[^']*')*? (?:/>|>[\s\S]*?</\1\s*>)|<[a-z](?:[^>"']|"[^"]*"|'[^']*')*>|<!\[CDATA\[ [\s\S]*?]]><br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Variante: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby<br /> <br /> Variationen Gültige Kommentare im XML-Stil finden Es gibt ein paar wenige Syntaxregeln für (X)HTML- und XML-Kommentare, die über die Regel „Beginnt mit einem <!-- und endet mit dem nächsten -->“ hinausgehen:<br /> <br /> 486 | Kapitel 8: Markup und Datenaustausch<br /> <br /> • In einem Kommentar dürfen keine zwei Bindestriche direkt hintereinander vorkommen. So ist zum Beispiel <!-- Kom--mentar --> aufgrund der beiden Bindestriche in der Mitte ungültig. • Vor dem schließenden Element darf kein Bindestrich als Teil des Kommentars stehen. So ist zum Beispiel <!-- Kommentar ---> ungültig, der vollständig leere Kommentar <!----> aber erlaubt. • Zwischen dem schließenden -- und > darf Whitespace stehen. So ist zum Beispiel <!-- Kommentar -- > ein gültiger, vollständiger Kommentar. Es ist nicht schwer, diese Regeln in eine Regex einzuarbeiten: <!--[^-]*(?:-[^-]+)*--\s*><br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Beachten Sie, dass alles zwischen den öffnenden und schließenden Kommentarbegrenzern immer noch optional ist, daher wird damit auch der komplett leere Kommentar <!---> gefunden. Aber wenn ein Bindestrich zwischen den Begrenzern steht, muss darauf mindestens ein Nicht-Bindestrich folgen. Und da der innere Teil der Regex nicht mehr länger zwei aufeinanderfolgende Bindestriche findet, wurden die vorher verwendeten genügsamen Quantoren durch gierige Quantoren ersetzt. Genügsame Quantoren würden auch wunderbar funktionieren, jedoch würde man für unnötiges Backtracking sorgen (siehe Rezept 2.13). Manche Leser werden sich diese neue Regex anschauen und sich fragen, warum die negierte Zeichenklasse ‹[^-]› doppelt verwendet wird, statt den Bindestrich in der nichteinfangenden Gruppe einfach optional zu machen (also ‹<!--(?:-?[^-]+)*--\s*>› zu verwenden). Es gibt einen guten Grund, der uns zurück zur Diskussion über „katastrophales Backtracking“ aus Rezept 2.15 führt. Sogenannte verschachtelte Quantoren bedürfen immer einer besonderen Aufmerksamkeit, um sicherzustellen, dass Sie keine Grundlage für ein katastrophales Backtracking legen. Ein Quantor ist dann verschachtelt, wenn er innerhalb einer Gruppe auftaucht, die selbst durch einen Quantor wiederholt wird. So enthält zum Beispiel das Muster ‹(?:?[^-]+)*› zwei verschachtelte Quantoren: das Fragezeichen nach dem Bindestrich und das Pluszeichen nach der negierten Zeichenklasse. Das Verschachteln von Quantoren ist nicht der eigentliche Grund für eine mögliche Performance-Katastrophe. Vielmehr liegt das darin, dass es eine riesige Anzahl an Möglichkeiten gibt, wie der äußere Quantor ‹*› mit den inneren Quantoren kombiniert werden kann, wenn versucht wird, einen String zu finden. Hat die Regex-Engine es nicht geschafft, am Ende einer teilweisen Übereinstimmung --> zu finden (wie dies notwendig ist, wenn Sie diesen Musterabschnitt in die Regex zum Finden von Kommentaren einfügen), muss die Engine alle möglichen Wiederholungskombinationen ausprobieren, bevor sie merkt, dass es wirklich keine Übereinstimmung gibt, und fortfährt. Diese Anzahl an Möglichkeiten wächst mit jedem zu prüfenden Zeichen extrem stark. Verschachtelte<br /> <br /> 8.8 Kommentare im XML-Stil entfernen |<br /> <br /> 487<br /> <br /> Quantoren sind aber nicht kritisch, wenn man diese Situation vermeidet. So stellt zum Beispiel das Muster ‹(?:-[^-]+)*› keine Gefahr dar, obwohl es einen verschachtelten Quantor ‹+› enthält. Denn die potenzielle Zahl an Backtracking-Punkten wächst linear mit der Länge des Ausgangstexts, da nun genau ein Bindestrich pro Gruppenwiederholung gefunden werden muss. Eine andere Möglichkeit, potenzielle Backtracking-Probleme zu vermeiden, ist die Verwendung einer atomaren Gruppe. Die folgende Regex entspricht der ersten Regex aus diesem Abschnitt, sie ist aber ein paar Zeichen kürzer und kann nicht in JavaScript und Python genutzt werden: <!--(?>-?[^-]+)*--\s*><br /> <br /> Regex-Optionen: Keine Regex-Varianten: .NET, Java, PCRE, Perl, Ruby In Rezept 2.14 erfahren Sie mehr über atomare Gruppen (und ihre Gegenstücke, die possessiven Quantoren).<br /> <br /> Kommentare im C-Stil finden Die gleiche Art von Muster für Kommentare im XML-Stil funktioniert auch sehr gut bei anderen mehrzeiligen Kommentaren, die nicht verschachtelt sind. Kommentare im C-Stil beginnen entweder mit einem /* und enden mit dem ersten */, oder sie beginnen mit // und enden mit dem Zeilenende. Die folgende Regex passt auf beide Kommentartypen, indem sie ein Muster für jeden Typ durch einen vertikalen Balken verbindet: /\*[\s\S]*?\*/|//.*<br /> <br /> Regex-Optionen: Keine (Punkt passt auf Zeilenumbruch darf nicht gesetzt sein) Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby<br /> <br /> Siehe auch In Rezept 8.9 wird gezeigt, wie man bestimmte Wörter in Kommentaren im XML-Stil findet.<br /> <br /> 8.9<br /> <br /> Wörter in Kommentaren im XML-Stil finden<br /> <br /> Problem Sie wollen alle Vorkommen des Worts TODO in (X)HTML- oder XML-Kommentaren finden. So soll im folgenden String nur der unterstrichene Text gefunden werden: Dieses "TODO" befindet sich nicht in einem Kommentar, aber das nächste. <!-- TODO: Einen cooleren Kommentar für dieses Beispiel haben. --><br /> <br /> 488 | Kapitel 8: Markup und Datenaustausch<br /> <br /> Lösung Es gibt mindestens zwei Lösungswege für dieses Problem, die jeweils ihre Vorteile besitzen. Die erste Taktik, beschrieben in „Zweistufiges Vorgehen“ auf Seite 489, besteht darin, Kommentare mit einer äußeren Regex zu finden und dann in jeder Übereinstimmung mit einer eigenen Regex oder einer normalen Textsuche weiterzusuchen. Das funktioniert am besten, wenn Sie für diese Aufgabe Code schreiben, da das Aufteilen der Aufgabe in zwei Schritte die ganze Sache einfach und schnell macht. Aber wenn Sie Dateien mit einem Texteditor oder grep-Tool durchsuchen, werden Sie die Aufgabe nicht in zwei Schritte unterteilen können, sofern Ihr Tool nicht die Option anbietet, nur innerhalb von Übereinstimmungen einer anderen Regex zu suchen.2 Wenn Sie Wörter mithilfe einer einzigen Regex in Kommentaren finden müssen, können Sie dazu ein Lookaround nutzen. Diese zweite Methode wird im Abschnitt „Einstufiges Vorgehen“ auf Seite 490 beschrieben.<br /> <br /> Zweistufiges Vorgehen Wenn es machbar ist, sollte man die Aufgabe in zwei Schritte unterteilen: Erst suchen Sie nach Kommentaren und dann in den Kommentaren nach TODO. So finden Sie Kommentare: <!--.*?--><br /> <br /> Regex-Optionen: Punkt passt auf Zeilenumbruch Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby In JavaScript gibt es keine Option Punkt passt auf Zeilenumbruch, aber Sie können statt des Punkts eine Zeichenklasse verwenden, die alle Zeichen enthält: <!--[\s\S]*?--><br /> <br /> Regex-Optionen: Keine Regex-Variante: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby In jedem Kommentar, den Sie mit einer dieser Regexes finden, können Sie dann nach den literalen Zeichen ‹TODO› suchen. Wenn Sie möchten, können Sie eine Regex mit Wortgrenzen verwenden, die zudem nicht auf Groß- und Kleinschreibung achtet. Damit stellen Sie sicher, dass TODO nur als ganzes Wort gefunden wird: \bTODO\b<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby In Rezept 3.13 wird gezeigt, wie Sie innerhalb der Übereinstimmungen einer äußeren Regex suchen können.<br /> <br /> 2<br /> <br /> PowerGREP – beschrieben in „Tools für das Arbeiten mit regulären Ausdrücken“ in Kapitel 1 – ist ein Tool, mit dem Sie in Übereinstimmungen suchen können.<br /> <br /> 8.9 Wörter in Kommentaren im XML-Stil finden | 489<br /> <br /> Einstufiges Vorgehen Lookaheads (beschrieben in Rezept 2.16) ermöglichen es Ihnen, dieses Problem mit einer einzelnen Regex zu lösen, auch wenn das weniger effizient ist. In der folgenden Regex wird ein positives Lookahead verwendet, um sicherzustellen, dass auf das Wort TODO ein schließender Kommentarbegrenzer --> folgt. Für sich allein ist damit nicht sichergestellt, dass das Wort auch wirklich in einem Kommentar steht, da es sich so auch einfach vor einem Kommentar befinden kann. Daher wird ein verschachteltes negatives Lookahead genutzt, um sicherzustellen, dass der öffnende Kommentarbegrenzer <!-- nicht vor --> auftaucht: \bTODO\b(?=(?:(?!<!--).)*?-->)<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Punkt passt auf Zeilenumbruch Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Da JavaScript keine Option Punkt passt auf Zeilenumbruch besitzt, verwenden Sie dort statt des Punkts die Zeichenklasse ‹[\s\S]›: \bTODO\b(?=(?:(?!<!--)[\s\S])*?-->)<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren Regex-Variante: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby<br /> <br /> Diskussion Zweistufiges Vorgehen In Rezept 3.13 finden Sie den Code, den Sie benötigen, um innerhalb von Übereinstimmungen einer anderen Regex zu suchen. Man benötigt dafür eine innere und eine äußere Regex. Die Kommentar-Regex dient als äußere Regex, während ‹\bTODO\b› die innere Regex bildet. Am wichtigsten ist hier der genügsame Quantor ‹*?›, der auf den Punkt oder die Zeichenklasse in der Kommentar-Regex folgt. Wie in Rezept 2.13 beschrieben, geht die Übereinstimmung damit nur bis zum ersten --> (demjenigen, das den Kommentar beendet), statt bis zum letzten Vorkommen von --> in Ihrem Ausgangstext.<br /> <br /> Einstufiges Vorgehen Diese Lösung ist komplexer und langsamer. Der Vorteil ist aber, dass sie die beiden Schritte des vorigen Ansatzes in einer Regex kombiniert. Damit kann sie auch dann genutzt werden, wenn man mit einem Texteditor, einer IDE oder einem anderen Tool arbeitet, mit dem man nicht innerhalb der Übereinstimmungen einer anderen Regex suchen kann. Lassen Sie uns diese Regex im Freiform-Modus anschauen und jeden Teil genauer betrachten:<br /> <br /> 490 | Kapitel 8: Markup und Datenaustausch<br /> <br /> \b TODO \b (?= (?: (?! <!-- ) . )*? --> )<br /> <br /> # Die Zeichen "TODO" als ganzes Wort finden # Sicherstellen, dass die folgende Regex passt # Gruppieren, aber nicht einfangen ... # Sicherstellen, dass "<!--" hier nicht passt # Ein beliebiges Zeichen finden # Null Mal oder häufiger wiederholen, aber so wenig wie möglich # Die Zeichen "-->" finden #<br /> <br /> Regex-Optionen: Punkt passt auf Zeilenumbruch, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Diese kommentierte Version der Regex funktioniert nicht in JavaScript, da es dort die Optionen Freiform und Punkt passt auf Zeilenumbruch nicht gibt. Beachten Sie, dass die Regex ein negatives Lookahead enthält, das in einem äußeren, positiven Lookahead verschachtelt ist. Damit ist sichergestellt, dass auf jede Übereinstimmung von TODO ein --> folgt und dass <!-- nicht dazwischen auftaucht. Wenn Ihnen klar ist, wie all das zusammenarbeitet, ist das klasse. Dann können Sie den Rest dieses Abschnitts überspringen. Aber falls das alles doch noch etwas unklar ist, lassen Sie uns tiefer einsteigen und das äußere, positive Lookahead in dieser Regex Schritt für Schritt aufbauen. Gehen wir kurz davon aus, dass wir das Wort TODO nur dann finden wollen, wenn irgendwo dahinter im String ein --> zu finden ist. Damit erhalten wir die Regex ‹\bTODO\b(?=.*?-->)› (mit aktiver Option Punkt passt auf Zeilenumbruch). Dadurch wird der unterstrichene Text in <!--TODO--> gefunden. Wir brauchen das ‹.*?› am Anfang des Lookaheads, da die Regex ansonsten nur dann etwas finden würde, wenn auf TODO direkt --> folgt, also ohne weitere Zeichen dazwischen. Der Quantor ‹*?› wiederholt den Punkt null Mal oder häufiger, aber so wenig wie möglich. Das ist genau das, was wir brauchen, um das erste folgende --> zu finden. Die Regex könnte übrigens bisher auch als ‹\bTODO(?=.*?-->)\b› geschrieben werden, indem das zweite ‹\b› hinter das Lookahead verschoben wird. Das hätte keinen Effekt auf den Text, der damit gefunden werden könnte, da sowohl die Wortgrenze als auch das Lookahead Zusicherungen der Länge null sind (siehe „Lookaround“ auf Seite 81). Aber trotzdem ist es besser, aus Gründen der Effizienz und Lesbarkeit die Wortgrenze als Erstes zu nutzen. In der Mitte einer teilweisen Übereinstimmung kann die Regex-Engine schneller eine Wortgrenze testen und muss sich nicht mit dem Prüfen eines längeren Lookahead befassen, falls TODO an der Stelle kein vollständiges Wort ist. Okay, die Regex ‹\bTODO\b(?=.*?-->)› scheint soweit zu funktionieren. Aber was passiert, wenn wir sie auf den Ausgangstext TODO <!-- anderer Kommentar --> anwenden? Die Regex findet TODO immer noch, da es von --> gefolgt wird, obwohl TODO gar nicht innerhalb eines Kommentars steht. Also müssen wir dafür sorgen, dass der Punkt innerhalb des Lookahead nicht alle Zeichen findet, sondern nur solche, die nicht Teil des Strings <!-- sind. Denn damit würde der Beginn eines neuen Strings gekennzeichnet wer-<br /> <br /> 8.9 Wörter in Kommentaren im XML-Stil finden | 491<br /> <br /> den. Wir können keine negierte Zeichenklasse wie ‹[^<!-]› verwenden, weil wir die Zeichen <, ! und - durchaus zulassen wollen, wenn sie nicht in der Folge <!-- vorkommen. Hier kommt das negative Lookahead ins Spiel. ‹(?!<!--).› passt auf ein einzelnes Zeichen, das nicht Teil des öffnenden Kommentarbegrenzers ist. Setzen wir dieses Muster in eine nicht-einfangende Gruppe, wie zum Beispiel ‹(?:(?!<!--).)›, können wir die gesamte Folge mit dem genügsamen Quantor ‹*?› wiederholen, den wir zuvor nur auf den Punkt angewendet haben. Fügen wir alles zusammen, erhalten wir die gesamte Regex, die als Lösung für dieses Problem vorgestellt wurde: ‹\bTODO\b(?=(?:(?!<!--).)*?-->)›. In JavaScript, in dem die notwendige Option Punkt passt auf Zeilenumbruch fehlt, können wir ‹\bTODO\b(?=(?: (?!<!--)[\s\S])*?-->)› verwenden.<br /> <br /> Variationen Auch wenn die Ein-Schritt-Regex sicherstellt, dass jede Übereinstimmung von TODO von --> gefolgt wird, ohne dass <!-- dazwischen auftaucht, wird das Umgekehrte nicht geprüft – dass vor dem Zielwort ein <!-- steht, ohne dass ein --> dazwischen vorkommt. Es gibt ein paar Gründe, warum wir das nicht geprüft haben: • Sie erreichen normalerweise auch ohne diese doppelte Prüfung Ihr Ziel, insbesondere, da die Ein-Schritt-Regex dafür gedacht ist, in Texteditoren und ähnlichen Tools verwendet zu werden, in denen Sie Ihre Ergebnisse noch überprüfen können. • Muss man weniger überprüfen, kostet das auch weniger Zeit (das heißt, es ist schneller). • Am wichtigsten ist aber, dass Sie nicht wissen, wie weit Sie rückwärts schauen müssten. Damit wird ein Lookbehind mit unbegrenzter Länge benötigt, was nur von der .NET-Variante unterstützt wird. Wenn Sie mit .NET arbeiten und diese zusätzliche Prüfung einbauen wollen, nutzen Sie die folgende Regex: (?<=<!--(?:(?!-->).)*?)\bTODO\b(?=(?:(?!<!--).)*?-->)<br /> <br /> Regex-Optionen: Groß-/Kleinschreibung ignorieren, Punkt passt auf Zeilenumbruch Regex-Variante: .NET Diese strengere Regex, die nur in .NET funktioniert, hat ein positives Lookbehind am Anfang, das genauso arbeitet wie das Lookahead am Ende, nur umgekehrt. Da das Lookbehind von der Stelle aus, an der es <!-- findet, wieder vorwärts fortfährt, enthält es ein negatives Lookahead, mit dem jedes Zeichen gefunden wird, das nicht Teil der Folge --> ist. Da das führende Lookahead und das abschließende Lookbehind beide Zusicherungen der Länge null sind, ist die abschließende Übereinstimmung immer noch nur das Wort TODO. Die in den Lookarounds gefundenen Strings werden nicht Teil des Suchergebnisses.<br /> <br /> 492 | Kapitel 8: Markup und Datenaustausch<br /> <br /> Siehe auch In Rezept 8.8 finden Sie Informationen dazu, wie Sie Kommentare im XML-Stil finden.<br /> <br /> 8.10 Ändern der Feldbegrenzer in CSV-Dateien Problem Sie wollen in einer CSV-Datei alle Kommata als Feldbegrenzer durch Tabs austauschen. Kommata innerhalb von Werten in doppelten Anführungszeichen sollen bestehen bleiben.<br /> <br /> Lösung Der folgende reguläre Ausdruck findet ein einzelnes CSV-Feld zusammen mit seinem davorstehenden Begrenzungszeichen. Dieses Zeichen ist normalerweise ein Komma, es kann sich aber auch um einen leeren String handeln, wenn das erste Feld des ersten Datensatzes gefunden wird, oder um einen Zeilenumbruch, wenn man das erste Feld eines der folgenden Datensätze erreicht. Jedes Mal, wenn eine Übereinstimmung gefunden wurde, wird das Feld selbst, zusammen mit den doppelten Anführungszeichen, die es eventuell umgeben, in Rückwärtsreferenz 2 gespeichert, der davorstehende Begrenzer in Rückwärtsreferenz 1. Die regulären Ausdrücke in diesem Rezept sind so entworfen, dass sie mit gültigen CSV-Dateien arbeiten können, die sich an die Formatregeln in „Kommaseparierte Daten (CSV)“ halten. (,|\r?\n|^)([^",\r\n]+|"(?:[^"]|"")*")?<br /> <br /> Regex-Optionen: Keine (^ und $ passen auf Zeilenumbrüche darf nicht gesetzt sein) Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Der gleiche reguläre Ausdruck im Freiform-Modus: ( , | \r?\n | ^ ) ( [^",\r\n]+ | " (?:[^"]|"")* " )?<br /> <br /> # Einfangende Gruppe 1 für die Feldbegrenzer # oder den Anfang des Strings # Einfangende Gruppe 2 für ein einzelnes Feld: # ein Feld ohne Anführungszeichen # oder ... # ein Feld in Anführungszeichen # (evtl. mit maskierten Anführungszeichen) # Die Gruppe ist optional, weil Felder leer sein können<br /> <br /> Regex-Optionen: Freiform (^ und $ passen auf Zeilenumbruch darf nicht gesetzt sein) Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby<br /> <br /> 8.10 Ändern der Feldbegrenzer in CSV-Dateien | 493<br /> <br /> Mit dieser Regex und dem Code aus Rezept 3.11 können Sie über Ihre CSV-Datei iterieren und nach jeder Übereinstimmung den Wert der Rückwärtsreferenz 1 prüfen. Der für jede Übereinstimmung notwendige Ersetzungstext ist vom Wert dieser Rückwärtsreferenz abhängig. Handelt es sich um ein Komma, ersetzen Sie es durch ein Tab-Zeichen. Ist die Rückwärtsreferenz leer oder enthält sie einen Zeilenumbruch, lassen Sie den Inhalt bestehen (Sie tun also entweder nichts oder Sie fügen den Wert wiederum als Ersetzungstext ein). Da CSV-Felder in Rückwärtsreferenz 2 eingefangen werden, müssen Sie auch diese zurück in den Ersetzungstext stecken. Das Einzige, was Sie wirklich ersetzen, sind die Kommata aus Rückwärtsreferenz 1.<br /> <br /> JavaScript-Beispiel Der folgende Code ist der komplette Inhalt einer Webseite mit zwei mehrzeiligen Eingabefeldern und einem Button Ersetzen zwischen ihnen. Klickt man auf den Button, wird der String aus der ersten Textbox (mit dem Titel Eingabe) genommen, mithilfe des gerade gezeigten regulären Ausdrucks werden alle Kommatrennzeichen in Tabs umgewandelt, und dann der neue String in die zweite Textbox kopiert (mit dem Titel Ausgabe). Wenn Ihre Eingabe gültige CSV-Daten sind, sollten Sie sie in der zweiten Textbox wiederfinden, wobei alle Kommata durch Tabs ersetzt sind. Um das zu testen, sichern Sie diesen Code in einer Datei mit der Endung .html und öffnen sie in Ihrem Webbrowser: <html> <head> <title>CSV-Trennzeichen von Komma nach Tab ändern</title> </head> <body> <p>Eingabe:</p> <textarea id="input" rows="5" cols="75">

Ausgabe:

<script> function commas_to_tabs () { var input = document.getElementById('input'), output = document.getElementById('output'), regex = /(,|\r?\n|^)([^",\r\n]+|"(?:[^"]|"")*")?/g, result = '', match; while (match = regex.exec(input.value)) { // Wert der Rückwärtsreferenz 1 prüfen if (match[1] == ',') { // Dem Ersetzungstext einen Tab (für ein Komma) // und Rückwärtsreferenz 2 hinzufügen. // Ist Rückwärtsreferenz 2 undefined (weil die optionale, // zweite einfangende Gruppe nicht beteiligt war),

494 | Kapitel 8: Markup und Datenaustausch

// wird ein leerer String dafür genutzt. result += '\t' + (match[2] || ''); } else { // Die gesamte Übereinstimmung hinzufügen result += match[0]; } // Verhindern, dass manche Browser in einer Endlosschleife hängen bleiben if (match.index == regex.lastIndex) regex.lastIndex++; } output.value = result; }

Diskussion Der in diesem Rezept beschriebene Ansatz erlaubt es Ihnen, immer ein vollständiges CSV-Feld (mit eingebetteten Zeilenumbrüchen, maskierten Anführungszeichen und Kommata) auf einmal zu verarbeiten. Jede Übereinstimmung beginnt dabei direkt vor dem nächsten Feldtrennzeichen. Die erste einfangende Gruppe in der Regex, ‹(,|\r?\n|^)›, passt auf ein Komma, einen Zeilenumbruch oder auf die Position am Anfang des Ausgangstexts. Da die Regex-Engine die Alternativen von links nach rechts ausprobiert, sind die Optionen in der Reihenfolge aufgeführt, in der sie in einer normalen CSV-Datei am häufigsten vorkommen. Diese einfangende Gruppe ist der einzige Teil der Regex, der gefunden werden muss. Daher ist es durchaus möglich, dass die gesamte Regex einen leeren String findet, denn der Anker ‹^› passt immer einmal. Der von dieser ersten einfangenden Gruppe gefundene Wert muss außerhalb der Regex geprüft werden, um die Kommata durch den von Ihnen gewünschten Begrenzer zu ersetzen (zum Beispiel ein Tab). Wir haben noch gar nicht die gesamte Regex beschrieben, aber der bisherige Teil ist schon irgendwie verwirrend. Sie fragen sich vielleicht, warum die Regex nicht so geschrieben ist, dass sie nur die Kommata findet, die durch Tabs ersetzt werden sollen. Wenn Sie das tun könnten, würde eine einfache Substitution des gefundenen Texts den zusätzlichen Code um die Regex herum überflüssig machen, der prüft, ob die einfangende Gruppe 1 ein Komma oder etwas anderes gefunden hat. Es sollte doch schließlich möglich sein, per Lookahead und Lookbehind herauszufinden, ob sich ein Komma innerhalb oder außerhalb eines CSV-Felds in Anführungszeichen befindet, oder? Leider bräuchten Sie für dieses Vorgehen Lookbehinds mit unbegrenzter Länge, die nur in der .NET-Regex-Variante vorhanden sind (in „Unterschiedliche Lookbehind-Ebenen“ auf Seite 83 sind die unterschiedlichen Einschränkungen der Lookbehinds in den verschiedenen Regex-Varianten beschrieben). Selbst .NET-Entwickler sollten solch ein Vorgehen vermeiden, da die Komplexität dadurch stark steigen und die Regex langsamer werden würde. 8.10 Ändern der Feldbegrenzer in CSV-Dateien | 495

Aber zurück zur vorgestellten Regex. Die meisten Muster finden sich im nächsten Abschnitt – der einfangenden Gruppe 2. Diese zweite Gruppe passt auf ein einzelnes CSV-Feld, einschließlich der es umgebenden doppelten Anführungszeichen. Anders als die vorige Gruppe ist diese optional, um auch leere Felder zu finden. Beachten Sie, dass diese zweite Gruppe in der Regex zwei alternative Muster enthält, die durch das Metazeichen ‹|› getrennt sind. Die erste Alternative ‹[^",\r\n]+› ist eine negierte Zeichenklasse, gefolgt von einem Quantor (‹+›), der die Klasse ein Mal oder häufiger findet und damit auf ein vollständiges Feld ohne Anführungszeichen passt. Für diese Übereinstimmung darf das Feld keine doppelten Anführungszeichen, Kommata oder Zeilenumbrüche enthalten. Die zweite Alternative in der Gruppe 2, ‹"(?:[^"]|"")*"›, passt auf ein Feld, das von doppelten Anführungszeichen umgeben ist. Genauer gesagt, passt es auf ein doppeltes Anführungszeichen, gefolgt von null oder mehr Zeichen, die keine doppelten Anführungszeichen oder gerade zwei aufeinanderfolgende doppelte Anführungszeichen sind, und schließlich dem schließenden doppelten Anführungszeichen. Der Quantor ‹*› am Ende der inneren, nicht-einfangenden Gruppe wiederholt die beiden inneren Optionen so häufig wie möglich, bis Sie zu einem doppelten Anführungszeichen gelangen, das nicht maskiert ist und damit das Feld beendet. Wenn Sie mit einer gültigen CSV-Datei arbeiten, sollte sich die erste Übereinstimmung dieser Regex am Anfang des Ausgangstexts befinden und jede nächste Übereinstimmung direkt nach dem Ende der letzten Übereinstimmung folgen.

Siehe auch In Rezept 8.11 wird beschrieben, wie Sie die Regex aus diesem Rezept nutzen können, um CSV-Dateien aus einer bestimmten Spalte zu extrahieren.

8.11 CSV-Felder aus einer bestimmten Spalte extrahieren Problem Sie wollen jedes Feld aus der dritten Spalte einer CSV-Datei extrahieren.

Lösung Der reguläre Ausdruck aus Rezept 8.10 kann hier erneut verwendet werden, um über jedes Feld eines Strings mit CSV-Daten zu iterieren. Mit ein bisschen zusätzlichem Code können Sie in jeder Zeile die Anzahl der Felder von links nach rechts mitzählen und die Felder an der Position extrahieren, die Sie haben wollen. Der folgende reguläre Ausdruck (in normaler Schreibweise und im Freiform-Modus) passt auf ein einzelnes CSV-Feld und sein davor stehendes Trennzeichen in zwei einfan-

496 | Kapitel 8: Markup und Datenaustausch

genden Gruppen. Da in mit doppelten Anführungszeichen umgebenen Feldern auch Zeilenumbrüche vorkommen können, wäre es nicht korrekt, in Ihrem CSV-String einfach vom Anfang jeder Zeile aus zu suchen. Indem Sie einzelne Felder suchen und Feld für Feld weitergehen, können Sie leicht herausfinden, welche Zeilenumbrüche außerhalb von Feldern mit doppelten Anführungszeichen stehen, und damit einen neuen Datensatz beginnen. Die regulären Ausdrücke in diesem Rezept sind so entworfen, dass sie mit gültigen CSV-Dateien arbeiten können, die sich an die Formatregeln in „Kommaseparierte Daten (CSV)“ auf Seite 440 halten. (,|\r?\n|^)([^",\r\n]+|"(?:[^"]|"")*")?

Regex-Optionen: Keine (^ und $ passen auf Zeilenumbruch darf nicht gesetzt sein) Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby ( , | \r?\n | ^ ) ( [^",\r\n]+ | " (?:[^"]|"")* " )?

# Einfangende Gruppe 1 für die Feldbegrenzer # oder den Anfang des Strings # Einfangende Gruppe 2 für ein einzelnes Feld: # ein Feld ohne Anführungszeichen # oder ... # ein Feld in Anführungszeichen # (evtl. mit maskierten Anführungszeichen) # Die Gruppe ist optional, weil Felder leer sein können

Regex-Optionen: Freiform (^ und $ passen auf Zeilenumbruch darf nicht gesetzt sein) Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby Bei diesen regulären Ausdrücken handelt es sich um die aus Rezept 8.10. Sie lassen sich auch für viele andere Aufgaben im CSV-Umfeld verwenden. Der folgende Beispielcode zeigt, wie Sie die Version ohne Freiform-Modus nutzen können, um eine CSV-Spalte zu extrahieren.

JavaScript-Beispiel Der folgende Code ist eine komplette Webseite mit zwei mehrzeiligen Eingabefeldern und einem Button Spalte 3 extrahieren dazwischen. Klickt man auf den Button, wird der Text genommen, den Sie in die Textbox Eingabe eingegeben haben. Mithilfe des regulären Ausdrucks wird der Wert des dritten Feldes aus jedem Datensatz kopiert und dann die gesamte Spalte in das Feld Ausgabe (wobei jeder Wert durch einen Zeilenumbruch getrennt ist). Um das zu testen, sichern Sie diesen Code in einer Datei mit der Endung .html und öffnen sie in Ihrem Webbrowser:

8.11 CSV-Felder aus einer bestimmten Spalte extrahieren | 497

Eingabe:

Ausgabe:

<script> function display_csv_column (index) { var input = document.getElementById('input'), output = document.getElementById('output'), column_fields = get_csv_column(input.value, index); if (column_fields.length > 0) { // Jeden Datensatz auf einer Zeile ausgeben output.value = column_fields.join('\n'); } else { output.value = '[Keine Daten gefunden]'; } } // Array mit CSV-Feldern für die angegebene Spalte (bei 0 beginnend) ausgeben function get_csv_column (csv, index) { var regex = /(,|\r?\n|^)([^",\r\n]+|"(?:[^"]|"")*")?/g, result = [], column_index = 0, match; while (match = regex.exec(csv)) { // Prüfen des Wertes der Rückwärtsreferenz 1. Ist es ein Komma, // erhöhe column_index. Sonst setzte den Wert auf 0. if (match[1] == ',') { column_index++; } else { column_index = 0; } if (column_index == index) { // Feld an das Ende des result-Arrays anhängen result.push(match[2]); } // Verhindern, dass manche Browser in einer Endlosschleife hängen bleiben if (match.index == regex.lastIndex) regex.lastIndex++; } return result; }

498 | Kapitel 8: Markup und Datenaustausch

Diskussion Da die hier genutzten regulären Ausdrücke aus Rezept 8.10 übernommen wurden, werden wir nicht noch einmal beschreiben, wie sie arbeiten. Aber in diesem Rezept gibt es ein neues JavaScript-Beispiel, das die Regex verwendet, um Felder aus einer bestimmten Spalte im CSV-Text zu extrahieren. Im vorgestellten Code iteriert die Funktion get_csv_column Feld für Feld über den Ausgangstext. Nach jeder Übereinstimmung wird die Rückwärtsreferenz 1 untersucht. Enthält sie ein Komma, haben Sie nicht das erste Feld eines Datensatzes erreicht, und die Variable column_index wird erhöht, um mitzuzählen, beim wievielten Komma Sie jetzt sind. Enthält die Rückwärtsreferenz 1 etwas anderes als ein Komma (also einen leeren String oder einen Zeilenumbruch), haben Sie das erste Feld einer neuen Zeile erreicht, und column_index wird auf null zurückgesetzt. Im nächsten Schritt wird im Code geprüft, ob die Variable column_index den Index erreicht hat, der extrahiert werden soll. Wenn das der Fall ist, wird der Wert der Rückwärtsreferenz 2 (alles nach dem führenden Trennzeichen) an das Array result angehängt. Nachdem Sie den gesamten Ausgangstext durchlaufen haben, gibt die Funktion get_csv_column ein Array mit den Werten aus der angegebenen Spalte zurück (in diesem Beispiel ist das die dritte Spalte). Die Liste der Übereinstimmungen wird dann in die zweite Textbox auf der Seite ausgegeben, wobei jeder Wert durch einen Zeilenumbruch (\n) getrennt wird. Man könnte das Ganze leicht verbessern, indem man den Benutzer angeben lässt, welcher Spaltenindex genutzt werden soll. Das kann man über ein Prompt oder ein zusätzliches Textfeld erreichen. Die hier besprochene Funktion get_csv_column ist schon so geschrieben, dass sie dieses Feature berücksichtigen kann – sie erwartet den gewünschten Spaltenindex als zweiten Parameter index (der bei null beginnt).

Variationen Wenn Sie den Code nutzen, um „Feld für Feld“ über einen String zu iterieren, gewinnen Sie viel Flexibilität. Aber wenn Sie in einen Texteditor unterwegs sind, sind Sie eventuell auf ein „normales“ Suchen und Ersetzen beschränkt. In dieser Situation können Sie ein ähnliches Ergebnis erzielen, indem Sie immer einen vollständigen Datensatz finden und ihn durch den Wert des Felds an der gewünschten Position ersetzen (mithilfe einer Rückwärtsreferenz). Die folgenden Regexes zeigen, wie dies für bestimmte Spaltenindexe funktioniert. Bei all diesen Regexes gilt: Wenn ein Datensatz nicht so viele Felder enthält, wie Sie eigentlich benötigen würden, wird dieser Datensatz nicht gefunden und stehen gelassen.

8.11 CSV-Felder aus einer bestimmten Spalte extrahieren | 499

Einen CSV-Datensatz finden und das Feld in Spalte 1 in der Rückwärtsreferenz 1 einfangen ^([^",\r\n]+|"(?:[^"]|"")*")?(?:,(?:[^",\r\n]+|"(?:[^"]|"")*")?)*

Regex-Optionen: ^ und $ passen auf Zeilenumbruch Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby

Einen CSV-Datensatz finden und das Feld in Spalte 2 in der Rückwärtsreferenz 1 einfangen ^(?:[^",\r\n]+|"(?:[^"]|"")*")?,([^",\r\n]+|"(?:[^"]|"")*")? (?:,(?:[^",\r\n]+|"(?:[^"]|"")*")?)*

Regex-Optionen: ^ und $ passen auf Zeilenumbruch Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby

Einen CSV-Datensatz finden und das Feld in Spalte 3 oder größer in der Rückwärtsreferenz 1 einfangen ^(?:[^",\r\n]+|"(?:[^"]|"")*")?(?:,(?:[^",\r\n]+|"(?:[^"]|"")*")?){1}, ([^",\r\n]+|"(?:[^"]|"")*")?(?:,(?:[^",\r\n]+|"(?:[^"]|"")*")?)*

Regex-Optionen: ^ und $ passen auf Zeilenumbruch Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Erhöhen Sie die Zahl im Quantor ‹{1}›, um mit dieser letzten Regex auch Spalten einzufangen, die an einer höheren Position als 3 stehen. Ändern Sie sie zum Beispiel auf ‹{2}›, fangen Sie die Felder aus Spalte 4, mit ‹{3}› fangen Sie die Felder aus für Spalte 5 und so weiter. Wenn Sie mit Spalte 3 arbeiten, können Sie die ‹{1}› auch einfach entfernen, da sie dann keine Auswirkungen hat.

Ersetzungstext Es wird für alle diese Regexes der gleiche Ersetzungstext (Rückwärtsreferenz 1) verwendet. Ersetzen Sie jede Übereinstimmung durch die Rückwärtsreferenz 1, sollten Sie nur die Felder erhalten, nach denen Sie suchen. $1

Ersetzungstextvarianten: .NET, Java, JavaScript, Perl, PHP \1

Ersetzungstextvarianten: Python, Ruby

8.12 Sektionsüberschriften in INI-Dateien finden Problem Sie wollen alle Sektionsüberschriften in einer INI-Datei finden.

500 | Kapitel 8: Markup und Datenaustausch

Lösung Das ist einfach. INI-Sektionsüberschriften stehen am Anfang einer Zeile und zeichnen sich dadurch aus, dass ein Name in eckigen Klammern steht (zum Beispiel [Sektion1]). Diese Regeln lassen sich schnell in eine Regex übertragen: ^\[[^\]\r\n]+]

Regex-Optionen: ^ und $ passen auf Zeilenumbruch Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby

Diskussion Diese Regex ist nicht so furchtbar lang, daher lässt sie sich schnell beschreiben: • Der erste ‹^› passt auf den Anfang einer Zeile, da die Option ^ und $ passen auf Zeilenumbruch aktiv ist. • ‹\[› passt auf einen literales [. Die eckige Klammer ist durch einen Backslash maskiert, damit [ nicht als Anfang einer Zeichenklasse angesehen wird. • ‹[^\]\r\n]› ist eine negierte Zeichenklasse, die ein beliebiges Zeichen findet, solange es sich nicht um eine schließende eckige Klammer ], ein Carriage Return (\r) oder ein Line Feed (\n) handelt. Der darauffolgende Quantor ‹+› sorgt dafür, dass die Klasse einmal oder häufiger gefunden werden kann. • Das letzte ‹]› passt auf ein literales ], mit dem die Sektionsüberschrift beendet wird. Dieses Zeichen muss nicht durch einen Backslash maskiert werden, da es nicht innerhalb einer Zeichenklasse steht. Wenn Sie nur eine bestimmte Sektionsüberschrift finden wollen, ist das noch einfacher. Die folgende Regex passt auf die Überschrift für eine Sektion mit dem Namen Sektion1: ^\[Sektion1]

Regex-Optionen: ^ und $ passen auf Zeilenumbruch Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby In diesem Fall ist der einzige Unterschied zu einer normalen Textsuche nach „[Sektion1]”, dass das Suchergebnis am Anfang einer Zeile stehen muss. Damit wird verhindert, dass auskommentierte Sektionsüberschriften gefunden werden (vor denen ein Semikolon steht) oder etwas, das wie eine Überschrift aussieht, aber in Wirklichkeit Teil eines Parameterwerts (zum Beispiel Item1=[Value1]) ist.

Siehe auch In Rezept 8.13 wird beschrieben, wie man Sektionsblöcke in INI-Dateien findet. In Rezept 8.14 wird beschrieben, wie man Name/Wert-Paare in INI-Dateien findet.

8.12 Sektionsüberschriften in INI-Dateien finden | 501

8.13 Sektionsblöcke in INI-Dateien finden Problem Sie müssen jeden vollständigen INI-Sektionsblock finden (also eine Sektionsüberschrift und alle Name/Wert-Paare der Sektion), um eine INI-Datei aufzuteilen oder jeden Block getrennt zu verarbeiten.

Lösung In Rezept 8.12 wurde gezeigt, wie man die Sektions-Überschrift in einer INI-Datei findet. Um eine gesamte Sektion zu finden, beginnen wir mit dem gleichen Muster aus dem Rezept, suchen aber weiter, bis wir das Ende des Strings oder ein Zeichen [ finden, das am Anfang einer Zeile steht (da damit der Anfang einer neuen Sektion beginnt): ^\[[^\]\r\n]+](?:\r?\n(?:[^[\r\n].*)?)*

Regex-Optionen: ^ und $ passen auf Zeilenumbruch (Punkt passt auf Zeilenumbruch darf nicht gesetzt sein) Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby Oder im Freiform-Modus: ^ \[ [^\]\r\n]+ ] (?: \r?\n (?: [^[\r\n] .* )? )*

# Sekitonsüberschrift finden # Rest der Sektion ... # Finden einer Zeilenumbruchfolge # Nach jedem Zeilenumbruch ... # ein beliebiges Zeichen finden, außer "[" oder einen # Zeilenumbruch # Den Rest der Zeile finden # Die Gruppe ist optional, damit auch leere Zeilen gefunden werden # Bis zum Ende des Abschnitts weitermachen

Regex-Optionen: ^ und $ passen auf Zeilenumbruch, Freiform (Punkt passt auf Zeilenumbruch darf nicht aktiv sein) Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby

Diskussion Dieser reguläre Ausdruck findet zunächst mithilfe des Musters ‹^\[[^\]\r\n]+]› eine Sektionsüberschrift in einer INI-Datei. Dann sucht er Zeile für Zeile weiter, sofern sie nicht mit [ beginnt. Schauen Sie sich den folgenden Ausgangstext an: [Sektion1] Item1=Value1 Item2=[Value2] ; [SektionA] ; Die Überschrift von SektionA wurde auskommentiert

502 | Kapitel 8: Markup und Datenaustausch

ItemA=ValueA ; ItemA ist nicht auskommentiert und Teil von Sektion1 [Section2] Item3=Value3 Item4 = Value4

In diesem String findet die Regex zwei Übereinstimmungen. Die erste reicht vom Anfang des Strings bis zu der leeren Zeile vor „[Sektion2]“. Die zweite Übereinstimmung reicht vom Anfang der Überschrift von Sektion2 bis zum Ende des Strings.

Siehe auch In Rezept 8.12 wird gezeigt, wie man die Sektionsüberschriften in INI-Dateien findet. In Rezept 8.14 wird gezeigt, wie man Name/Wert-Paare in INI-Dateien findet.

8.14 Name/Wert-Paare in INI-Dateien finden Problem Sie wollen die Name/Wert-Paare eines Parameters in einer INI-Datei finden (zum Beispiel Item1=Value1), wobei beide Teile mit einfangenden Gruppen getrennt werden sollen. Die Rückwärtsreferenz 1 soll den Parameternamen (Item1) enthalten, Rückwärtsreferenz 2 den Wert (Value1).

Lösung So sieht der reguläre Ausdruck aus, mit dem man diese Aufgabe erledigen kann: ^([^=;\r\n]+)=([^;\r\n]*)

Regex-Optionen: ^ und $ passen auf Zeilenumbruch Regex-Varianten: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby ^ ( [^=;\r\n]+ ) = ( [^;\r\n]* )

# # # #

Zeilenanfang Einfangen des Namens als Rückwärtsreferenz 1 Trennzeichen zwischen Name und Wert Einfangen des Werts als Rückwärtsreferenz 2

Regex-Optionen: ^ und $ passen auf Zeilenumbruch, Freiform Regex-Varianten: .NET, Java, PCRE, Perl, Python, Ruby

Diskussion Wie bei den anderen INI-Rezepten in diesem Kapitel arbeiten wir auch hier mit ziemlich einfachen Zutaten. Die Regex beginnt mit einem ‹^›, um die Position am Anfang einer Zeile zu finden (stellen Sie sicher, dass die Option ^ und $ passen auf Zeilenumbruch aktiv ist). Das ist wichtig, denn ohne die Zusicherung, dass die Übereinstimmung am Anfang einer Zeile beginnt, könnten Sie einen Teil einer auskommentierten Zeile erwischen.

8.14 Name/Wert-Paare in INI-Dateien finden |

503

Als Nächstes verwendet die Regex eine einfangende Gruppe mit einer negierten Zeichenklasse (‹[^=;\r\n]›), gefolgt von dem Quantor (‹+›), der die Klasse einmal oder mehrfach findet, um den Namen des Parameters zu erhalten und ihn als Rückwärtsreferenz 1 zu speichern. Die negierte Zeichenklasse passt auf jedes Zeichen außer auf das Gleichheitszeichen, das Semikolon, den Carriage Return (‹\r›) und den Line Feed (‹\n›). Die Zeichen Carriage Return und Line Feed werden beide genutzt, um einen INI-Parameter zu beenden. Ein Semikolon zeigt den Anfang eines Kommentars an, und ein Gleichheitszeichen trennt Namen und Wert eines Parameters. Nachdem der Parametername gefunden wurde, sucht die Regex nach einem literalen Gleichheitszeichen (dem Trennzeichen zwischen Name und Wert) und dann nach dem Parameterwert. Der Wert wird mit einer zweiten einfangenden Gruppe gefangen, die dem Muster aus der ersten Gruppe ähnelt, aber nicht so viele Einschränkungen besitzt. So dürfen hier auch Gleichheitszeichen vorkommen (es gibt also ein Zeichen weniger in der negierten Zeichenklasse). Und es wird der Quantor ‹*› verwendet, um nicht mindestens ein Zeichen finden zu müssen (da Werte, anders als Namen, leer sein dürfen). Und schon sind wir fertig.

Siehe auch In Rezept 8.12 wird beschrieben, wie man die Sektionsüberschriften in INI-Dateien findet. In Rezept 8.13 wird beschrieben, wie man an die Details von Sektionsblöcken in INIDateien gelangt.

504 | Kapitel 8: Markup und Datenaustausch

Index

Symbole - (Bindestrich) als Metazeichen 28 aus Kreditkarten-Nummern entfernen 288, 291 für Bereiche in Zeichenklassen 34 Maskieren 340 !~ (Operator) 136 # (Rautezeichen) für Kommentare 90 Maskieren 340 $ (Dollarzeichen) als Anker 40, 41, 42, 113, 232 als Metazeichen 28 Maskieren 339 Maskieren in Ersetzungstext 92 $& (Variable) 95, 100, 148, 153 $' (Variable) 100, 207 $+ (Hash) 161, 193 $_ (Variable) 100 $` (Variable) 100, 207 $~ (Variable) in Ruby 148 einfangende Gruppen 159 $~[0] (Variable) 148 ( ) (Klammern) als Metazeichen 28, 235 atomare Gruppen 76, 80, 265 einfangende Gruppen 61 Lookbehind nachbauen 86 schon gefundenen Text erneut finden 64 Maskieren 339 * (Stern) als Anker (Zusicherung) 235 als Metazeichen 28 für possessive Quantoren 231 gierig 73 Maskieren 339

+ (Plus-Zeichen) als Metazeichen 28 für possessive Quantoren 76, 231 Maskieren 339 , (Komma) als Tausender-Separator 363 im Intervall-Quantor 263 Maskieren 340 . (Punkt) als Metazeichen 28 ein beliebiges Zeichen finden 38 Finden 231 Maskieren 339 Missbrauch 38 =~ (Operator) in Perl 136, 153 =~ (Operator) in Ruby 134, 137 ? (Fragezeichen) als Metazeichen 28 für genügsame Quantoren 74 Maskieren 339 zum optionalen Finden 71 @ (At-Zeichen) Finden 231 Kodieren in Perl 113 [] (eckige Klammern) als Metazeichen 28 Maskieren 339 zum Definieren von Zeichenklassen 33 \ (Backslash) als Metazeichen 28 im Quellcode 110 Maskieren 339 im Ersetzungstext 92 zum Maskieren von Zeichen 28, 337 innerhalb von Zeichenklassen 34 ^ (Zirkumflex) als Anker 40, 42, 232, 235 als Metazeichen 28

Index | 505

Maskieren 339 Negieren in Zeichenklassen 34 { } (geschweifte Klammern) als Metazeichen 28 Maskieren 339 zur Wiederholung 70 | (vertikaler Balken) als Alternations-Operator 60, 251, 304 Maskieren 339

A \a (Bell-Zeichen) 30 \A Anker 40, 41, 232 abschließenden Whitespace entfernen 333 ActionScript-Sprache 106 ähnliche Wörter finden 306 akzentuierte Zeichen 56 alphanumerische Zeichen, Eingabe begrenzen 257 Alternation 60 Wörter aus einer Liste finden 304 Zahlen in einem Bereich finden 354 Zeitformate validieren 251 Anker 40, 41 ANSI-Zeichen, Einschränken auf 258 appendReplacement() (Methode) 198 appendTail() (Methode) 198 ASCII-Steuerzeichen (siehe Steuerzeichen) atomare Gruppen 76, 80, 265 atomares Lookaround und Lookbehind 85 Attribute (Markup-Sprachen) 436 bestimmte finden 476 Whitelist 465 At-Zeichen (@) Finden 231 Kodieren in Perl 113

B \B Nicht-Wortgrenzen 45 -Tags ersetzen durch <strong> 459 \b Wortgrenze 35, 44, 233, 237, 251, 302 (siehe auch Wörter) Backslash (\) als Metazeichen 28 im Quellcode 110 Maskieren 339 im Ersetzungstext 92

506 | Index

zum Maskieren von Zeichen 28, 337 in Zeichenklassen 34 Backtracking 73 katastrophales 79 unnötiges vermeiden 75 balanciertes Finden 180 bedingte Ausdrücke 318 Bedingungen beim Finden 87 begin() (Methode) in Ruby (MatchData-Klasse) 154 Begrenzer in CSV-Dateien ändern 493 Bell-Zeichen (\a) 30 benannte Bedingungen 88 benannte Captures 66, 99, 160 Gruppen mit gleichen Namen (.NET) 248 benannte einfangende Gruppen 192 benannte Rückwärtsreferenzen 69 Benutzer aus URLs extrahieren 386 Bereiche in Zeichenklassen 34 Binärzahlen finden 348 Bindestrich (-) als Metazeichen 28 aus Kreditkarten-Nummern entfernen 288, 291 für Bereiche in Zeichenklassen 34 Maskieren 340 Blöcke, Unicode 52 alle Zeichen aufführen 57 Block-Maskierungen 29, 340 Buchstaben, Unicode-Kategorie 49

C \cA bis \cZ Werte 31 C (Sprache) 106 C# (Sprache) 104 literale Regexes 110 Regex-Bibliothek importieren 116 Regex-Objekte erstellen 119 C++ (Sprache) 106 CacheSize (Eigenschaft) in .NET 119 CANON_EQ (Konstante) in Java 128 Carriage Return (\r) 30 CASE_INSENSITIVE (Konstante) in Java 125 CDATA-Abschnitte, XML 439 cellspacing-Attribut, zu