En Perl, el análisis léxico (lexing) y el parsing de cadenas se utilizan a menudo para manejar plantillas de texto complejas. Muchas tareas (por ejemplo, el análisis de paréntesis anidados, comillas, consultas SQL) no pueden resolverse con simples expresiones regulares debido a su naturaleza lineal. En tales casos, se utilizan módulos que implementan las bases del parsing, como Text::Balanced.
Text::Balanced está diseñado para extraer paréntesis balanceados, comillas pareadas y otras estructuras anidadas. Funciona donde las expresiones regulares son impotentes (por ejemplo, el parsing de construcciones anidadas { ... { ... } ... }). Entre las alternativas se encuentran los módulos Parse::RecDescent, código propio basado en pilas y recursión, así como parsers externos.
Ejemplo de uso de Text::Balanced y comparación con regexp:
use Text::Balanced 'extract_bracketed'; my $data = 'foo({bar(baz)},qux)'; my ($extracted, $remainder) = extract_bracketed($data, '()'); print $extracted; # Imprimirá: ({bar(baz)},qux)
Una expresión regular no podrá analizar correctamente paréntesis anidados:
$data =~ /(\(.*\))/; # solo capturará el primer y el último paréntesis, ignorando la anidación
¿Es posible en expresiones regulares de Perl normales aislar correctamente paréntesis balanceados en cadenas de anidamiento arbitrario?
Respuesta: No, las expresiones regulares de Perl no pueden trabajar con plantillas recursivas (excepto PCRE, pero no las expresiones regulares estándar de Perl). Para este tipo de problema es necesario usar un parser (Text::Balanced, parser basado en pilas, Parse::RecDescent). Intentar resolver el problema con una expresión regular dará lugar a errores en la sintaxis anidada.
Ejemplo:
# NO funcionará para foo({bar(baz)},qux) my ($br) = $data =~ /(\(.*\))/;
Historia
En el proyecto, hubo intentos de analizar JSON manualmente con expresiones regulares. El desarrollador asumió que la expresión
(\{.*\})encontraría el fragmento necesario, pero con datos reales que contenían objetos anidados, el parser seleccionó un límite incorrecto, lo que llevó a la pérdida de datos y errores en el manejo de parámetros de entrada.
Historia
En el registro XML de eventos, fue necesario extraer el contenido de una etiqueta con etiquetas potencialmente anidadas. La comprensión insuficiente de los principios de recursión en lexing llevó a un análisis incorrecto de los eventos y a la ignorancia de los elementos anidados, lo que causó la pérdida de parte de la información.
Historia
Error al analizar una consulta SQL con un script de migración: no fue posible analizar casos excepcionales como subconsultas entre paréntesis. Las expresiones regulares "se rompieron" ya en el nivel de cadenas anidadas simples, lo que resultó en la formación de consultas SQL incorrectas.