Acerca de este problema HTML
Los corchetes ([ y ]) son caracteres reservados bajo RFC 3986, el estándar que define la sintaxis URI. Solo están permitidos en el componente host de una URL (específicamente para direcciones IPv6) y son ilegales en cualquier otro lugar, incluyendo la cadena de consulta. Aunque la mayoría de navegadores son permisivos y cargarán un <iframe> incluso cuando el src contiene corchetes sin codificar, el Validador HTML de W3C correctamente marca esto como un valor de URL inválido.
Este patrón aparece frecuentemente cuando trabajas con frameworks o APIs que usan notación de corchetes para representar arrays u objetos anidados en parámetros de consulta — por ejemplo, filters[category]=news o items[0]=apple. Estas URLs funcionan en la barra de direcciones de un navegador porque los navegadores arreglan silenciosamente las URLs mal formadas, pero el HTML crudo en sí mismo es técnicamente no conforme.
Por qué es importante
- Cumplimiento de estándares: Un documento HTML válido requiere que todos los valores de atributos que esperan URLs contengan URIs codificadas correctamente. Los corchetes sin codificar violan este requisito.
- Interoperabilidad: Aunque los navegadores principales manejan esto con elegancia, otros consumidores de HTML — como lectores de pantalla, web scrapers, componentes webview embebidos, o clientes de email — pueden no ser tan tolerantes.
- Mantenibilidad: Las URLs codificadas correctamente son inequívocas y reducen el riesgo de errores sutiles de parsing, especialmente cuando las URLs se construyen dinámicamente o se pasan a través de múltiples capas de procesamiento.
Cómo solucionarlo
Hay dos enfoques principales:
-
Codificar por porcentaje los corchetes. Reemplaza cada
[con%5By cada]con%5Den la URL. El servidor los decodificará de vuelta a corchetes automáticamente, así que la funcionalidad se preserva. -
Usar nomenclatura de parámetros alternativa. Si controlas el servidor, cambia a una convención de nomenclatura que evite los corchetes por completo, como notación de puntos (
filters.category) o guiones bajos (filters_category). Esto mantiene la URL válida sin necesidad de codificación.
Si estás generando la URL dinámicamente en JavaScript, puedes usar encodeURIComponent() en claves y valores de parámetros individuales, o usar las APIs URL y URLSearchParams, que manejan la codificación automáticamente.
Ejemplos
Incorrecto — corchetes sin codificar en la cadena de consulta
<iframe src="https://example.com/embed?filters[category]=news&filters[tags]=web"></iframe>
Los caracteres [ y ] en la cadena de consulta hacen que este sea un valor de URL inválido, desencadenando el error del validador.
Corregido — corchetes codificados por porcentaje
<iframe src="https://example.com/embed?filters%5Bcategory%5D=news&filters%5Btags%5D=web"></iframe>
Reemplazar [ con %5B y ] con %5D produce una URL válida. El servidor recibe los mismos nombres de parámetros después de la decodificación.
Corregido — nomenclatura de parámetros alternativa
<iframe src="https://example.com/embed?filters.category=news&filters.tags=web"></iframe>
Si el servidor lo soporta, usar notación de puntos elimina la necesidad de corchetes por completo, manteniendo la URL limpia y válida.
Generando URLs codificadas en JavaScript
<iframe id="content-frame"></iframe>
<script>
const url = new URL("https://example.com/embed");
url.searchParams.set("filters[category]", "news");
url.searchParams.set("filters[tags]", "web");
document.getElementById("content-frame").src = url.href;
// Resultado: https://example.com/embed?filters%5Bcategory%5D=news&filters%5Btags%5D=web
</script>
La API URLSearchParams codifica automáticamente por porcentaje los caracteres reservados, así que puedes escribir los nombres de parámetros de forma natural y dejar que el navegador produzca una URL válida.
Encuentra problemas como este automáticamente
Rocket Validator escanea miles de páginas en segundos, detectando problemas de HTML en todo tu sitio web.