Expresión regular para un identificador JIRA

Estoy tratando de extraer un identificador JIRA de una línea de texto.

Los identificadores JIRA tienen la forma [AZ] + – [0-9] – Tengo el siguiente patrón:

foreach my $line ( @textBlock ) { my ( $id ) = ( $line =~ /[\s|]?([AZ]+-[0-9]+)[\s:|]?/ ); push @jiraIDs, $id if ( defined $id && $id !~ /^$/ ); } 

Esto no funciona si alguien especifica algún texto que contenga el patrón dentro de otra cadena, por ejemplo, blah_blah_ABC-123 coincidiría con ABC-123. No quiero imponer que debe haber un espacio u otro delimitador delante de la partida ya que eso fallaría si el identificador estuviera al comienzo de la línea.

¿Alguien puede sugerir las runas necesarias?

Gracias.

Puedes asegurarte de que ese carácter antes de tu patrón sea un espacio en blanco o el comienzo de la cadena usando alternancia. Del mismo modo, asegúrese de que va seguido de un espacio en blanco o al final de la cadena.

Puedes usar esta expresión regular:

 my ( $id ) = ( $line =~ /(?:\s|^)([AZ]+-[0-9]+)(?=\s|$)/ ); 

ID oficial de JIRA Regex (Java):

Los mismos Atlassian tienen un par de páginas web flotando alrededor que sugieren que una buena expresión regular (java) es la siguiente:

 ((? 

(Fuente: https://confluence.atlassian.com/display/STASHKB/Integrating+with+custom+JIRA+issue+key )

 Test String: "BF-18 abc-123 X-88 ABCDEFGHIJKL-999 abc XY-Z-333 abcDEF-33 ABC-1" Matches: BF-18, X-88, ABCDEFGHIJKL-999, DEF-33, ABC-1 

ID de JIRA mejorado Regex (Java):

Pero, realmente no me gusta porque coincidirá con el "DEF-33" de "abcDEF-33", mientras que prefiero ignorar "abcDEF-33" por completo. Así que en mi propio código estoy usando:

 ((? 

Observe cómo "DEF-33" ya no coincide:

 Test String: "BF-18 abc-123 X-88 ABCDEFGHIJKL-999 abc XY-Z-333 abcDEF-33 ABC-1" Matches: BF-18, X-88, ABCDEFGHIJKL-999, ABC-1 

Mejora de la expresión regular de JIRA (JavaScript):

También necesitaba esta expresión regular en JavaScript. Desafortunadamente, JavaScript no es compatible con LookBehind (? , por lo que tuve que portarlo a LookAhead a(?!b) y revertir todo:

 var jira_matcher = /\d+-[AZ]+(?!-?[a-zA-Z]{1,10})/g 

Esto significa que la cadena que debe coincidir también debe revertirse antes de tiempo:

 var s = "BF-18 abc-123 X-88 ABCDEFGHIJKL-999 abc XY-Z-333 abcDEF-33 ABC-1" s = reverse(s) var m = s.match(jira_matcher); // Also need to reverse all the results! for (var i = 0; i < m.length; i++) { m[i] = reverse(m[i]) } m.reverse() console.log(m) // Output: [ 'BF-18', 'X-88', 'ABCDEFGHIJKL-999', 'ABC-1' ] 

Si incluye datos de muestra con su pregunta, tendrá la mejor oportunidad de obtener respuestas de aquellos que podrían no tener a Jira, etc.

Aquí hay otra toma en ello-

 my $matcher = qr/ (?: (?<=\A) | (?<=\s) ) ([AZ]{1,4}-[1-9][0-9]{0,6}) (?=\z|\s|[[:punct:]]) /x; while (  ) { chomp; my @matches = /$matcher/g; printf "line: %s\n\tmatches: %s\n", $_, @matches ? join(", ", @matches) : "none"; } __DATA__ JIRA-001 is not valid but JIRA-1 is and so is BIN-10000, A-1, and TACO-7133 but why look for BIN-10000000 or BINGO-1? 

Recuerde que [0-9] coincidirá con 0001 y amigos que probablemente no desee. Creo que, pero no se puede verificar, Jira trunca los prefijos de emisión a 4 caracteres como máximo. Así que el regex que hice solo permite 1-4 letras mayúsculas; Fácil de cambiar si está mal. 10 millones de boletos parece ser un extremo superior razonablemente alto para números de emisión. También permití la puntuación final. Es posible que tenga que condimentar ese tipo de cosas para degustar, datos salvajes. Necesita la g y la captura en una matriz en lugar de un escalar si está combinando cadenas que podrían tener más de un ID de problema.

 line: JIRA-001 is not valid but JIRA-1 is and so is BIN-10000, matches: JIRA-1, BIN-10000 line: A-1, and TACO-7133 but why look for BIN-10000000 or BINGO-1? matches: A-1, TACO-7133