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 (231 Bytes)
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.
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.