PowerShell RegEx

[sikarr]

Hi Leute,

irgendwie hab ich nen Knoten im Kopf.

Ich will/muss/darf/soll einen Wert prüfen der von einer OCR kommt, ist eigentlich total simple und funktioniert super bis auf eine Ausnahme.

Der Wert den ich prüfe ist eine 7 stellige Zahl, hier soll einfach nur geprüft werden ob der String auch wirklich nur diese 7 stellige Zahl enthält. Funktioniert, ganz Simpel.

Jetzt ist heute durch Zufall aufgefallen das wenn am Ende dieses Strings ein Leerzeichen ist die Prüfung die Zahl durch winkt.
Probiert habe ich "\d{7}" und auch "[0-9]{7}" mit und ohne "\b" und "^$". in einer einfachen IF ELSE Schleife, hilft alles nix wenn am Ende ein Leerzeichen steht.

Weis jemand Rat? ist bestimmt total banal aber ich sehs einfach nicht.

 

[teufelernie]

Erm keine Ahnung von powershell, aber regex ist eigentlich überall gleich.
Nutze er das cheat-sheet hier und teste er dort seinen Code: https://pythex.org

 

[Yuuri]

Mach doch vorher ein .Trim() oder was hält dich davon ab? Das entfernt jeglichen Whitespace am Anfang und Ende.

if( $string.ToString().Trim() -match "^\d{7}$" )
{
  # ...
}

Ansonsten: ^\s*\d{7}\s*$ - [<Whitespace>]<Zahl mit 7 Ziffern>[<Whitespace>]

PS: Es gibt keine If-Schleifen!!!

 

[sikarr]

Trim wäre eine Möglichkeit, aber ich möchte ja wissen wenn die Prüfung negativ ausfällt, durchlaufen tut es auch so, es generiert dann halt bloss einen Hinweis für weitere arbeiten.

PS: Du hast natürlich Recht!!!

 

[Exterior]

Zeig doch einfach mal den genauen RegEx, den du verwendest. Denn eigentlich sollte "/^\d{7}$/" funktionieren.

Oder poste mal das Script dafür.

 

[sikarr]

Kann ich erst morgen, ist auf Arbeit, aber ich habe eigentlich alle Kombinationen oben aufgelistet.

Ich möchte eigentlich nur einen Treffer wenn mehr oder weniger als diese 7 stellige Zahl drinn steht.
Die Zahl ändert sich auch laufend, sind Sendungsnummern einer Spedition, da gibts kein Schema.

Manchmal kann der Wert der drinn steht ja sogar stimmen, deswegen nur der Hinweis und kein Abbruch oder Trim, damit man nachschauen kann.

 

[BeBur]

/^\d{7}$/ sollte eigentlich funktionieren, kleiner Test ergibt das auch.
Beim nächsten mal direkt schreiben, welche regexp ganz genau du ausprobiert hast.

 

[pizza4ever]

Kannst du den Code mal Posten und ein Beispiel? Dann schaue ichs mir morgen an.

Empfehle dir allgemein den Absprung an der Stelle ins .net Framework, da du dort bessere RegEx Pattern Tester hast.

 

[sikarr]

Moin, an alle erstmal ein Danke.

@Exterior und @BeBur hatten Recht mit "^\d{7}$" obwohl ich dachte dieses auch probiert zu haben. Gerade nachgeschaut hatte ich noch "([0-9]{7})" drin stehen, warum das damit nicht klappte ist mir klar.

Gerade noch einen anderen anderen Fehler gefunden der meine Hinweismeldung unterdrückte.

switch ($niederlassung){
Mochau    {$lspattern = '^\d{7}$'; $rkpattern = '^\d{6}$'; BREAK}
DD        {$lspattern = '^\d{7}$'; $rkpattern = '^\d{6}$'; BREAK}
Erfurt    {$lspattern = '^\d{6}$'; $rkpattern = '^\d{5}$'; BREAK}
Fern    {$lspattern = '^\d{6}$'; $rkpattern = '^\d{5}$'; BREAK}
}

$lsliste = Get-ChildItem -Path $ilspfad -Recurse -Include "*.txt"

$lsfehler = @()

foreach ($lsls in $lsliste){
    $lsls = Import-Csv -Path $lsls -Delimiter ";" -Header "sendungsnummer","platzhalter"
    IF ($lsls.sendungsnummer -notmatch $lspattern) {
        $lsfehler += $lsls.sendungsnummer
        }
}

Damit klappts nun.

 

[pizza4ever]

Gut, empfehle dir wie gesagt bei sowas das .net Framework, damit kannst du im powershell z.b. hier

http://regexstorm.net/tester

deine expressions testen.

Codebeispiel:

$regex_pattern = '["][@][@][T][R][M][M][@][@][0]*'
$regex_replace = '"'

$line = [regex]::Replace($line,$regex_pattern,$regex_replace)

 

[BeBur]

Ich checke grad den Zusammenhang nicht.
Regexp ist doch Regexp (abgesehen von den 5 Flavours ).
Wieso sollte er ohne .net sein regexp mit dem verlinkten Tester nicht testen können? Und warum nicht ggf. einen anderen Tester verwenden?

Und wtf ist das da:

$regex_pattern = '["][@][@][T][R][M][M][@][@][0]*'

 

[pizza4ever]

Naja, ein Regex was den Ausdruck

"@@TRIMM@@0 (das I wurde wohl irgendwo geschluckt) sucht und ihn abschneidet

1.) Finde ich regex in powershell deutlich müßiger als im nativen .net, es gibt einfach viel mehr doku und Codebeispiele. Ich hatte muir das vor 2 Jahren mal intensiver angeschaut und damals Probleme mit dem (nativen) Regex Powershell gehabt, und habs damals alles auf die .net Komponente umgeschrieben und seitdem keine Probleme gehabt.
2.) (aber das ist nun was allgemeines) macht es durchaus Sinn sich mal anzuschauen wie man das .net Framework im Powershell anspricht. Es bietet ungleich mehr Möglichkeiten bei teilweise deutlich höherer Performance. Wenn man schnell mal was machen will ist Powershell super, aber es hat halt auch grenzen.

 

[Yuuri]

Was ist am PowerShell Regex anders? Ist nichts Anderes als das, was im .NET Framework Verwendung findet, von den sprachlichen Konstrukten einer Scriptsprache mal abgesehen... Ich weiß aber auch nicht so recht was dein TRIMM Beispiel darstellen soll, vor allem nicht die zu tausenden, überflüssigen Klammern.

 

[pizza4ever]

Nein, es ist nicht gleich

"Book" -match "BOok" ist true

"Book" -match "[B][O][o][k]" ist true

$match = "[B][O][o][k]" 
bzw $match = BOok"

und danach [regex]::Match("Book",$match) ist aber false

.. das ist Verbindung mit einem Tester kann natürlich zu unerwarteten Ergebnissen führen.

 

[sikarr]

"Book" -cmatch "BOok" ist false

In dem fall würde ich -cmatch nehmen oder -eq

 

[pizza4ever]

Ja, gibt sicher Möglichkeiten das zu handeln. Ich bin damals einfach besser mit der Kombi .net Regex und dem .net Tester gefahen, weil man alles schön testen kann (und ich eben Probleme hatten weil die Ausdrücke [teilweise] [minimal] abweichen).

 

[BeBur]

"-match" macht dann anscheinend schlicht kein regexp matching, sondern irgendwas anderes. Falls das so wie du es angibst korrekt ist. Muss man dann in der Doku nachschlagen, wenn man es verwenden will.

"[regex]::Match("Book",$match)" weist vom Namen her darauf hin, dass es übliches regexp matching ist und korrekterweise wird da auch false ausgegeben.

Siehe hier:
https://kevinmarquette.github.io/2017-07-31-Powershell-regex-regular-expression/#-match

-imatch makes it explicit that you are doing a case insensitive operation (the default)

Zugegebenermaßen schon ziemlicher Blödsinn mit dem man ggf. nicht rechnet. Vor allem wenn Menschen irreführenderweise Dinge schreiben wie:

The -match opperator takes a regular expression and returns $true if the pattern matches.

 

[pizza4ever]

Ahja...

https://docs.microsoft.com/en-us/po...t/about_regular_expressions?view=powershell-6

Character literals
A regular expression can be a literal character or a string. This causes the engine to match the text specified exactly.

PowerShell

Copy
# This statement returns true because book contains the string "oo"
"book" -match "oo"

 

[BeBur]

Was willst du mit dem letzten Beitrag ausdrücken?
Aus deinem Link:

PowerShell regular expressions are case-insensitive by default.

Finde ich nun auch sehr irreführend, weil eigentlich ist es anders herum.
Aber jetzt auch kein Grund gleich zu .net zu wechseln ;-).

 

[pizza4ever]

Es war vor deinem Edit

Mal Bezug auf deinen Beitrag:

"Zugegebenermaßen schon ziemlicher Blödsinn mit dem man ggf. nicht rechnet. Vor allem wenn Menschen irreführenderweise Dinge schreiben wie[...]"

Ich hatte damals ein paar so Fallstricke und daher kommt meien Empfehlung. Ob man dieser folgt, blebt ja jedem selbst überlassen.