# \[F\] sayregexp: zweites Parmeter beeinflußt Treffer
**URL:** https://community.mp3tag.de/t/f-sayregexp-zweites-parmeter-beeinflusst-treffer/13142
**Category:** Fehlermeldungen
**Created:** [February 26, 2012, 11:06am UTC](https://community.mp3tag.de/t/f-sayregexp-zweites-parmeter-beeinflusst-treffer/13142 "2012-02-26T11:06:47Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@pone](https://community.mp3tag.de/u/pone)
#### Post date: [February 26, 2012, 11:06am UTC](https://community.mp3tag.de/t/f-sayregexp-zweites-parmeter-beeinflusst-treffer/13142/1 "2012-02-26T11:06:47Z")
Wenn bei sayregexp im zweiten Paramter, also im Seperator String, Zeichen vorkommen, die die letzten Zeichen im letzten Treffer sind, wird der letzte Treffer ohne diese Zeichen dargestellt.
Beispiel:
zu parsender Text:
\_1-\_\_2+\__3-_ END
sayregexp "(?\<=_)[^_]+(?=\_)" " - " "END"
zu erwartendes Ergebnis:
1- - 2+ - 3-
tatsächliches Ergebnis:
1- - 2+ - 3
Abgeschnitten wird hier nur das Minus hinter 3, nicht das hinter 1 beim ersten Treffer.
Darüber gestolpert bin ich beim Schreiben eines neuen Discogs Script für die JSON API.
Dort wollte ich die Katalog Nummer mit
sayregexp "(?\<="catno": ").+?(?=")" "\\u005c\\u005c" "}],"
erhalten, also "\\u005c\\u005c" anstelle von \\, um die momentanen Probleme beim Schreiben dieses Zeichen zu umgehen. Das Erebnis war, das bei allen Katlognummern die Zahlen 5 und 0 am Schluss abgeschnitten wurden. Und zwar in beliebiger Länge und Kombination, solange sie die letzten Zeichen des letzten Treffers bilden. Also
5 =\>
15 =\> 1
10 =\> 1
100055500 =\> 1
Wenn man "\\u005c\\u005c" durch "\\" ersetzt ist das Problem erstmal gelöst, zumindest wenn kein Match mit "" endet. Aber eigentlich sollte diese Verwechslung von Seperator String und Rexgex Match ja gar nicht vorkommen
Hier ein Skript das den Fehler anhand dieser Seite demonstriert:
[sayregex\_bug.src](https://community.mp3tag.de/uploads/default/original/1X/d5212630c8fc2782dac265152212c1c01a84496c.src) (231 Bytes)
[sayregex\_bug.src](https://community.mp3tag.de/uploads/default/original/1X/d5212630c8fc2782dac265152212c1c01a84496c.src) (231 Bytes)
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [February 26, 2012, 12:27pm UTC](https://community.mp3tag.de/t/f-sayregexp-zweites-parmeter-beeinflusst-treffer/13142/2 "2012-02-26T12:27:00Z")
> [@pone](#):
>
> ... sayregexp "(?\<="catno": ").+?(?=")" "\\u005c\\u005c" "}],"
> erhalten, also "\\u005c\\u005c" anstelle von \\ ...
Kontrolliere die Anzahl der Backslashes im RegEx, vielleicht stimmt dabei etwas nicht?
DD.20120226.1428.CET
---
### Author:  [@pone](https://community.mp3tag.de/u/pone)
#### Post date: [February 26, 2012, 12:53pm UTC](https://community.mp3tag.de/t/f-sayregexp-zweites-parmeter-beeinflusst-treffer/13142/3 "2012-02-26T12:53:35Z")
> [@DetlevD](#):
>
> Kontrolliere die Anzahl der Backslashes im RegEx, vielleicht stimmt dabei etwas nicht?
>
> DD.20120226.1428.CET
Die Anzahl der Backslashes habe ich kontrolliert und auch mit verschiedenen Mp3tag Versionen getestet. Dies führt auch durchaus zu unterschiedlichen Ergebnissen in der Darstellung von "\\", hat aber mit dem beschriebenen Bug nichts zu tun. Deshalb hab ich ja auch ein Beispiel ohne Backslash genommen. Mit mit dem beigefügten Skript kann der Fehler auch einfach reproduziert werden.
---
### Author:  [@pone](https://community.mp3tag.de/u/pone)
#### Post date: [March 2, 2012, 3:14pm UTC](https://community.mp3tag.de/t/f-sayregexp-zweites-parmeter-beeinflusst-treffer/13142/4 "2012-03-02T15:14:02Z")
Wird das ausgebessert werden?
Habe ein fast fertiges Discogs JSON API Script das jetzt wirklich so gut wie alle Daten von Discogs holen kann und aufgrund der API Basis wohl auch stabiler sein wird als das Alte.
Wäre schade, wenn es aufgrund diese Bugs unbrauchbar bleiben würde. sayregexp ist unverzichtbar, da do...while loops nicht inneinander verschachelbar sind (wieso eigentlich nicht?). And vielen Stellen (Credits, Notes, Companies, Identifiers) verwende ich auch Zeilenumbrüche im im zweiter Parameter bei sayregexp. Also \r\n, da hilft auch der Workaround nicht mehr, nur Satzzeichen als Trennzeichen zu verwenden.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [March 2, 2012, 6:44pm UTC](https://community.mp3tag.de/t/f-sayregexp-zweites-parmeter-beeinflusst-treffer/13142/5 "2012-03-02T18:44:47Z")
Ja, wird zeitnah ausgebessert werden.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [March 14, 2012, 6:20am UTC](https://community.mp3tag.de/t/f-sayregexp-zweites-parmeter-beeinflusst-treffer/13142/6 "2012-03-14T06:20:51Z")
Der Fehler ist in Mp3tag v2.50 behoben.
---
### Author:  [@anon40879270](https://community.mp3tag.de/u/anon40879270)
#### Post date: [March 15, 2012, 3:12pm UTC](https://community.mp3tag.de/t/f-sayregexp-zweites-parmeter-beeinflusst-treffer/13142/7 "2012-03-15T15:12:21Z")
Dann wird es bald ein Discogs JSON API Script geben?
---
### Author:  [@pone](https://community.mp3tag.de/u/pone)
#### Post date: [March 15, 2012, 3:31pm UTC](https://community.mp3tag.de/t/f-sayregexp-zweites-parmeter-beeinflusst-treffer/13142/8 "2012-03-15T15:31:54Z")
> [@mbaa3](#):
>
> Dann wird es bald ein Discogs JSON API Script geben?
Ja, wird es.