Explicar una regex
Todo desarrollador se ha quedado mirando una expresión regular dejada por alguien que ya no trabaja ahí, sin saber si es seguro tocarla. Este endpoint toma esa expresión y devuelve una explicación en lenguaje simple de qué hace realmente cada grupo, ancla y cuantificador.
Ejecútela online
Ejecute esto en nuestros servidores con su cuenta. Las herramientas gratuitas corren en su navegador; esta cobra de su saldo del KIT según el precio de arriba.
El comentario que nunca se escribió
Una expresión regular es una de las pocas piezas de código que puede ser correcta, crítica para el sistema y completamente opaca para la siguiente persona que la lea, todo al mismo tiempo. Rara vez trae un comentario que explique por qué el patrón excluye cierto carácter o por qué hay un lookahead escondido en medio, porque quien lo escribió lo entendía perfectamente en su momento y nunca esperó necesitar esa explicación después. dev.regex_explain existe para ese momento, seis meses más tarde, en que otra persona (o la misma) necesita saber exactamente qué hace ese patrón antes de modificarlo.
De símbolos a oraciones
Envíe POST a /dev/regex-explain con la expresión que quiere que se desglose, y la llamada devuelve un task_id mientras el patrón se analiza y se traduce a lenguaje simple. El resultado llega por webhook firmado o mediante un enlace firmado válido por 24 horas, y recorre la expresión pieza por pieza (qué captura cada grupo, qué exige cada ancla, qué permite cada cuantificador) en lugar de entregar un solo resumen vago de todo el conjunto.
Por qué los mismos doce caracteres pueden significar cosas distintas
Buena parte de lo que hace difícil leer un regex en frío es que sus símbolos están muy sobrecargados y dependen del contexto: un signo de interrogación significa cero-o-uno después de un token, pero cambia a no-codicioso después de un cuantificador, y un par de paréntesis puede ser un grupo con captura, un grupo sin captura o un lookahead según los dos caracteres justo después del paréntesis de apertura. Motores distintos (PCRE, POSIX, las variantes integradas en Python, JavaScript y Java) también soportan extensiones ligeramente diferentes, así que un patrón que se ve desconocido puede simplemente estar usando sintaxis de un motor con el que usted no trabaja seguido. Explicar un patrón con precisión implica identificar en qué variante está escrito, tanto como analizar los símbolos en sí.
Dónde rinde en el trabajo del día a día
La revisión de código es el uso más evidente: un revisor puede pegar un patrón desconocido de un pull request y obtener una descripción clara de su comportamiento en el tiempo que toma leer una frase, en vez de rastrear mentalmente grupos anidados. También aporta valor en la incorporación de nuevo personal, cuando un ingeniero recién llegado hereda un repositorio lleno de patrones de validación sin documentar, y en auditorías de seguridad, donde entender exactamente qué bloquea y qué no bloquea un regex de sanitización de entrada importa más que saber escribir uno desde cero. Cobrado por solicitud más por cada ítem de patrón, y sin cargo si la explicación falla, es lo bastante económico como para correrlo contra cada regex que un linter marque como sospechoso, no solo contra los pocos que alguien finalmente decide investigar.
Qué puede hacer con ella
Revisión de código de un patrón desconocido
Un revisor pega un regex de un pull request para obtener una descripción clara de su comportamiento antes de aprobar un cambio en la lógica de validación.
Incorporación a un repositorio heredado
Un nuevo ingeniero explica cada regex sin documentar en un módulo de validación heredado para entender qué reglas de entrada se están aplicando realmente.
Auditoría de seguridad de sanitización de entrada
Una revisión de seguridad explica un patrón de sanitización para confirmar exactamente qué caracteres y secuencias bloquea antes de aprobar un formulario.
Generación de documentación
Una herramienta de documentación explica cada regex usado en la validación de parámetros de una API pública para que la documentación describa los formatos aceptados en lenguaje simple.
Preguntas frecuentes
¿Cómo obtengo la explicación de un regex con la API?
Envíe la expresión por POST a /dev/regex-explain, guarde el task_id devuelto y reciba el desglose en lenguaje simple por webhook o mediante un enlace firmado válido por 24 horas.
¿Es gratis la API para explicar regex?
No, no hay plan gratuito ni prueba; cuesta $0.003 por solicitud más $0.0135 por ítem, y una explicación fallida nunca se cobra.
¿Soporta todas las variantes de regex?
Maneja las variantes comunes, incluyendo PCRE y las integradas en los lenguajes principales; indique el lenguaje de origen si el patrón usa extensiones menos comunes.
¿Explica toda la expresión o solo partes de ella?
Descompone la expresión en sus componentes (grupos, anclas, cuantificadores, clases de caracteres) y explica cada uno, en vez de dar un solo resumen vago.
¿Puedo explicar varios patrones en una sola solicitud?
Sí, envíe varios ítems en una sola tarea y cada uno se cobra individualmente a la tarifa por ítem, útil al auditar un archivo completo de patrones de validación.
¿Me dice si un regex es ineficiente o riesgoso?
La explicación describe lo que el patrón hace coincidir; si una construcción es propensa a retroceso catastrófico o a coincidencias inusualmente amplias, eso se menciona dentro de la descripción en lenguaje simple.
¿Ya está disponible este endpoint?
Sí, /dev/regex-explain está activo y aceptando solicitudes ahora mismo.
¿Se guarda el patrón que envío?
No, los patrones enviados y sus explicaciones se eliminan después del período de retención y nunca se usan para entrenamiento.
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, y pronto desde nuestra app, el email y Telegram.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/dev/regex-explain \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"items":["valor-1","valor-2"]}'const res = await fetch("https://api.kit.forhosting.com/dev/regex-explain", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"items": [
"valor-1",
"valor-2"
]
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/regex-explain",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"items": [
"valor-1",
"valor-2"
]
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/regex-explain", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"items":["valor-1","valor-2"]}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"items":["valor-1","valor-2"]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/regex-explain", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"items": [
"valor-1",
"valor-2"
]
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.regex_explain",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
422 | task_failed | La tarea falló tras 3 reintentos. No se cobra. |