BEARBEITEN - Regex erklärt

BEARBEITEN - Regex erklärt

Ich habe Mühe, in Notepad++ einen regulären Ausdruck zu finden, der x Bytes findet und durch nichts ersetzt. Wagenrücklauf (0D) zählt, Zeilenvorschub zählt (0A).

Dies ist der reguläre Ausdruck, den ich versuche: (0C ist mein Anfang, ich entferne 318 Bytes nach 0C zusammen mit 0C)

\x0C(.{318})

Dieser reguläre Ausdruck findet nichts, es heißt, es wurde keine Übereinstimmung gefunden. Ich kann finden \x0C, und ich kann finden ., aber ich kann nicht finden, überspringt .{318}auch 0x0A und 0x0D.

-Wraparound ist aktiviert.

-regulärer Ausdruck wird überprüft.

Hier ist ein Teil der Datei im Hex-Format mit ASCII:

0C 30 31 32 27 34 35 36 0D 0A 30 61 32 0D 33 34 0A [snip] 0C 32 0A 0D 35 [etc..]
<ff>0  1  2  '  4  5  6<cr><lf>0  a  2<cr> 3  4<lf>[snip]<ff> 2<lf><cr>5 [etc..]

Antwort1

Da Sie erwähnt haben, dass die Kodierung US-ASCII ist, können wir davon ausgehen, dass jedes Zeichen ein Byte ist. In regulären Ausdrücken entspricht der '.' jedem Zeichen außer Zeilenumbrüchen, und Sie möchten, dass jeder einzelne Teil eines CR/LF-Zeilenumbruchs separat abgeglichen wird, da es sich um zwei Bytes handelt.

Ich gehe außerdem davon aus, dass Sie tatsächliche Textdaten verarbeiten und keine Binärdatei, die Bytes außerhalb der US-ASCII-Zeichenzuordnung enthalten kann.

Wenn alles oben genannte zutrifft, können Sie den folgenden regulären Ausdruck verwenden:

\x0C[^\xFF]{318}

Der Grund, warum der '.' bei Ihrem Versuch nicht funktioniert hat, ist, dass der '.' nicht mit Zeilenumbrüchen übereinstimmt. Sie können auch nicht verwenden \x0C[.\r\n]{318}, da der Platzhalter '.' innerhalb einer Zeichenklasse (Gruppe aus eckigen Klammern) nicht verfügbar ist. Der Hex-Wert FF lässt sich keinem gültigen Codepunkt innerhalb des US-ASCII-Zeichensatzes zuordnen. Wenn Sie also nach „einem beliebigen Zeichen suchen, das nicht das FF-Zeichen ist“, erhalten SieBytesin Betracht.

Beachten Sie, dass diese Methode Zeilenumbrüche unter Windows/Mac als zwei Zeichen/Bytes zählt (gemäß Ihrer Anforderung).

Ich hoffe, das ist, wonach Sie gesucht haben …

BEARBEITEN - Regex erklärt

Voller Ausdruck

\x0C[^\xFF]{318}

Lassen Sie uns das aufschlüsseln.

\x0C

Dies entspricht einem einzelnen Unicode-Graphem. Weitere Informationen hierzu finden Siehier drübenZusammenfassend kann man sagen, dass \x die Unicode-Version des Punktes ist, mit der Ausnahme, dasses kann auch Zeilenumbrüche abgleichen(das ist wichtig, dazu später mehr).

Da Sie dies aber auch verwendet haben, gehe ich davon aus, dass Sie damit bereits teilweise vertraut sind.

[^\xFF]

Alles zwischen [] wird alsZeichensatz(nicht zu verwechseln mit dem gleichen Konzept in der Zeichenkodierung). Sie können mehr darüber im Regexp-Tutorial lesen, aber kurz gesagt dient es als „ODER“-Anweisung. [ab] bedeutet einfach „a oder b“. Wenn ^ innerhalb eines Zeichensatzes verwendet wird, dient es als Negation. Also bedeutet [^a] „nicht a“. In unserem Anwendungsfall suchen wir nach jedem Zeichen, das nicht den HEX-Wert FF hat.

{318}

Und wir suchen 318 Mal nach diesem Zeichentyp. Die {}-Syntax gilt immer für das Regex-Element direkt davor, in diesem Fall also für den Zeichensatz [^\xFF].

Warum \xFF?

In der hexadezimalen Notation lautet der us-ascii-Zeichensatzvon 00 bis 7E. Höhere Werte können nicht auf einen US-ASCII-Codepunkt abgebildet werden. Das bedeutet, dass jede (korrekt) in US-ASCII codierte Datei nur HEX-Werte zwischen 00 und 7E enthalten kann. Sie kann daher kein FF enthalten.

Wir können dies also geschickt nutzen, um nach jedem beliebigen Zeichen zu suchen, einschließlich Zeilenumbruchzeichen, da \x.. auch Zeilenumbrüche wie \x0A und \x0C findet. Wenn wir nach einem beliebigen Zeichen suchen, dasnichtFF, wir finden am EndejedenCharakter.

Bedenken Sie, dass diese Lösung davon abhängt, dass Ihre Datei in US-ASCII und nicht in UTF-8 codiert ist.

verwandte Informationen