# \[AF\] RegEx im Feld Tracknummer anders als erwartet
**URL:** https://community.mp3tag.de/t/af-regex-im-feld-tracknummer-anders-als-erwartet/17621
**Category:** Fehlermeldungen
**Created:** [February 4, 2016, 9:46pm UTC](https://community.mp3tag.de/t/af-regex-im-feld-tracknummer-anders-als-erwartet/17621 "2016-02-04T21:46:43Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@peilung](https://community.mp3tag.de/u/peilung)
#### Post date: [February 4, 2016, 9:46pm UTC](https://community.mp3tag.de/t/af-regex-im-feld-tracknummer-anders-als-erwartet/17621/1 "2016-02-04T21:46:43Z")
Hallo,
im Thread
[/t/17620/1](https://community.mp3tag.de/t/17620/1)
hatte ich um Rat gebeten, weil sich im Track-Feld die Einzelteile "Tracknummer" und "Gesamtzahl" nicht wie zu erwarten greifen lassen (ist dort beschrieben).
Ist das tatsächlich ein unübliches Verhalten? Oder steckt dahinter eine besondere Programmlogik?
Besten Dank für Aufklärung.
peilung
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [February 5, 2016, 5:46am UTC](https://community.mp3tag.de/t/af-regex-im-feld-tracknummer-anders-als-erwartet/17621/2 "2016-02-05T05:46:48Z")
> [@peilung](#):
>
> ...Track-Feld die Einzelteile "Tracknummer" und "Gesamtzahl" nicht wie zu erwarten greifen lassen (ist dort beschrieben).
> ...
Ich habe mal ein bisschen rumgespielt mit Feldern, die Zahlen enthalten, jeweils mit dem Ausdruck:
1: $regexp(%feldname%,(\d\*),$1)
und dann auch noch mit
2: $regexp(%feldname%,\d\*,$1)
Da jedesmal das Suchen einer Zahl angegeben ist, zeigt das erste Beispiel, was MP3tag denkt, wie die Zahl aussieht und das zweite zeigt, was übrig bleibt.
Für %releasetime% mit den Inhalt "2016-01-20T04:38:00Z"
bleibt für 1 "2016-01-20T04:38:00Z" übrig und für
2: "--T::Z"
Ein vergleichbares Ergebnis kriegt man für den geänderten Inhalt von YEAR mit 2014/11:
1: 2014/11
2: /
also scheint \d+ nicht beim ersten Nicht-Zahl-Zeichen zu stoppen. Tja ... vielleicht wirklich ein Bug.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [February 5, 2016, 8:58am UTC](https://community.mp3tag.de/t/af-regex-im-feld-tracknummer-anders-als-erwartet/17621/3 "2016-02-05T08:58:39Z")
Könnt ihr mal schauen, wie sich das ganze ändert, wenn ihr davon ausgeht, dass der reguläre Ausdruck den gesamten String matchen muss?
```
$regexp(%track%,^(\d+).*,$1)
```
Hier werden erst alle Zahlen am Anfang des String gematched und in der ersten Gruppe hinterlegt. Danach werden alle anderen beliebigen Zeichen gematched.
```
$regexp(%track%,.*?(\d+)$,$1)
```
Hier werden erstmal alle beliebigen Zeichen gematched, allerdings auf "nicht-gierige" (non-greedy) Art und Weise, sodass am Ende die letzte zusammenhängende Gruppe von Zahlen gematched wird.
Viele Grüße
Florian
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [February 5, 2016, 9:22am UTC](https://community.mp3tag.de/t/af-regex-im-feld-tracknummer-anders-als-erwartet/17621/4 "2016-02-05T09:22:16Z")
Ja, die Beispiele funktionieren zwar, sind aber anders als das Verhalten z.B. bei \_FILENAME.
Die Lösung aus diesem Thread
[/t/17095/1](https://community.mp3tag.de/t/17095/1)
Zum Löschen der führenden Zahl funktioniert weiterhin, ohne den String nach der führenden Zahl extra zu nennen.
So wird mit
$regexp(%\_Filename%,\d+,)
aus 003 \_ Baggi Begovic \_ Good God [Baggi Begovic & Soul Conspiracy Remix].mp3
-\>
" \_ Baggi Begovic \_ Good God [Baggi Begovic & Soul Conspiracy Remix]"
wie zuvor und auch für TRACK oder YEAR oder RELEASETIME erwartet.
Oder auch ein Feld wie BPM, das z.B. 128.09 enthalten kann, wird mit
$regexp(%bpm%,.[0-9][0-9]$,)
zu 128, ohne den ganzen String zu matchen.
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [February 5, 2016, 9:37am UTC](https://community.mp3tag.de/t/af-regex-im-feld-tracknummer-anders-als-erwartet/17621/5 "2016-02-05T09:37:15Z")
> [@ohrenkino](#):
>
> Ich habe mal ein bisschen rumgespielt mit Feldern, die Zahlen enthalten ...
**$regexp('2016-01-20T04:38:00Z','\d\*',$1) ==\> --T::Z $regexp('2016-01-20T04:38:00Z','\d\*',)==\> --T::Z**
Beide Ergebnisse sind in Ordnung, wenn bzw. weil $1 nicht definiert ist und leer ist.
Was ich nicht nachvollziehen kann, das ist der Fall, der mit ??? gekennzeichnet ist ...
**$regexp('abc 123','(\d)$','$1')-\> abc 123 ok kein Treffer $regexp('abc 123','.\*(\d)','$1')-\> 3 ok Treffer $regexp('abc 123','.\*?(\d)$','$1')-\> 3 ok Treffer $regexp('abc 123','.\*?(\d)','$1')-\> 123 ???**
DD.20160205.1145.CET
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [February 5, 2016, 9:44am UTC](https://community.mp3tag.de/t/af-regex-im-feld-tracknummer-anders-als-erwartet/17621/6 "2016-02-05T09:44:32Z")
> [@](#):
>
> ...
>
> Beide Ergebnisse sind in Ordnung, wenn bzw. weil $1 nicht definiert ist und leer ist.
>
> DD.20160205.1139.CET
Nur war das nicht der ganze Testfall:
Der Test 1 für Releasetime liefert nämlich mit
$regexp(%releasetime%,(\d\*),$1)
(hier ist $1 definiert)
mit dem Inhalt "2016-02-04T04:41:00Z"
das Ergebnis "2016-02-04T04:41:00Z"
Erwartet hätte ich "2016", weil dann die Zahl aufhört und ein Minus/Bindestrich kommt.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [February 5, 2016, 9:49am UTC](https://community.mp3tag.de/t/af-regex-im-feld-tracknummer-anders-als-erwartet/17621/7 "2016-02-05T09:49:20Z")
Noch ein Test:
eine bearbeitete RELASETIME mit
"2016\_02-03T04:41:00Z"
bearbeitet mit
$regexp(%releasetime%,(\d\*)\_,$1)
wird zu
"201602-03T04:41:00Z"
...als ob gar keine Zahl erkannt würde, sondern nur der Untrstrich aus dem Such-String.
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [February 5, 2016, 9:49am UTC](https://community.mp3tag.de/t/af-regex-im-feld-tracknummer-anders-als-erwartet/17621/8 "2016-02-05T09:49:57Z")
> [@ohrenkino](#):
>
> ... mit dem Inhalt "2016-02-04T04:41:00Z" das Ergebnis "2016-02-04T04:41:00Z" ...
Die Rückgabe der vollständigen Eingabe ergibt in Mp3tag die Aussage "kein Treffer".
DD.20160205.1149.CET
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [February 5, 2016, 9:57am UTC](https://community.mp3tag.de/t/af-regex-im-feld-tracknummer-anders-als-erwartet/17621/9 "2016-02-05T09:57:52Z")
> [@DetlevD](#):
>
> Die Rückgabe der vollständigen Eingabe ergibt in Mp3tag die Aussage "kein Treffer".
>
> DD.20160205.1149.CET
Ja, das ist zu beobachten - nur ist das auch richtig?
Schließlich lieferte ein \_FILENAME mit führender Zahl diese Zahl als Treffer, ebenso wie im Feld BPM ...
Der oben gezeigte Link zum Löschen von Zahlen hat ja mal ohne Angabe des Rest-Strings funktioniert.
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [February 5, 2016, 9:59am UTC](https://community.mp3tag.de/t/af-regex-im-feld-tracknummer-anders-als-erwartet/17621/10 "2016-02-05T09:59:57Z")
> [@ohrenkino](#):
>
> ... als ob gar keine Zahl erkannt würde, sondern nur der Untrstrich aus dem Such-String.
**$regexp('2016\_02-03T04:41:00Z','(\d\*)\_','$1') -\> '201602-03T04:41:00Z'**
Die Zahl '2016' ist ein Teil des Treffers '2016\_'.
Anschließend soll der Unterstrich verschwinden.
Das ist ok.
DD.20160205.1202.CET
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [February 5, 2016, 10:10am UTC](https://community.mp3tag.de/t/af-regex-im-feld-tracknummer-anders-als-erwartet/17621/11 "2016-02-05T10:10:34Z")
> [@ohrenkino](#):
>
> ... hier ist $1 definiert ...
Zwar ist $1 durch den Klammerausdruck definiert, ist aber leer, weil der reguläre Ausdruck keinen Treffer liefert für diese Eingabestring.
Das ist ok.
DD.20160205.1210.CET
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [February 5, 2016, 1:34pm UTC](https://community.mp3tag.de/t/af-regex-im-feld-tracknummer-anders-als-erwartet/17621/12 "2016-02-05T13:34:31Z")
> [@DetlevD](#):
>
> Zwar ist $1 durch den Klammerausdruck definiert, ist aber leer, weil der reguläre Ausdruck keinen Treffer liefert für diese Eingabestring.
> Das ist ok.
>
> DD.20160205.1210.CET
Vielleicht kann ja jemand meinen Denkfehler auflösen:
$regexp('003 \_ Baggi Begovic \_ Good God [Baggi Begovic & Soul Conspiracy Remix]',\d+,$1)
erzeugt ja
" \_ Baggi Begovic \_ Good God [Baggi Begovic & Soul Conspiracy Remix]"
also ohne die führende Nummer.
Allerdings gibt
$regexp('003 \_ Baggi Begovic \_ Good God [Baggi Begovic & Soul Conspiracy Remix]',(\d+),$1)
jetzt nicht "003"
sondern den vollständigen String - das deutet darauf hin, dass es für \d+ eigentlich keinen Treffer gegeben hat und deshalb der Ausgangsstring ausgegeben wird.
Nur: warum wird dann im Beispiel ohne gefülltes $1 die führende Zahl weggeschnitten?
Und warum passiert das auch für diesen Ausdruck:
$regexp('003 \_ Baggi Begovic \_ Good God [Baggi Begovic & Soul Conspiracy Remix]',\d+,)
Irgendwie erkennt der Parser doch die Nummer am Anfang.