Codificador porcentaje RFC 3986
Con la regla estricta de RFC 3986, hello world!'()* queda como hello%20world%21%27%28%29%2A: solo letras, dígitos, guion, punto, guion bajo y tilde se conservan tal cual. Al decodificar, una secuencia de porcentaje incompleta detiene el proceso en lugar de inventar caracteres. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- Texto
- hello world!'()*
- Modo de cálculo
- Encode
- Resultado
- hello%20world%21%27%28%29%2A
- Longitud
- 28
- Forma estándar
- RFC 3986
- Sin reservar
- A-Z a-z 0-9 - . _ ~
RFC 3986 define la gramática moderna de URI y el conjunto exacto de caracteres sin reserva que pueden aparecer sin codificación de porcentaje: letras, dígitos, guion, punto, guion bajo y tilde. Esta capacidad aplica el mapa estricto de RFC 3986 en ambos sentidos: codificar convierte cada byte UTF-8 no sin reserva en %HH en mayúsculas, y decodificar restaura el texto plano fallando de inmediato ante secuencias de porcentaje incompletas o no hexadecimales.
En qué se diferencia la codificación RFC 3986 de encodeURIComponent
La codificación de porcentaje sustituye octetos no permitidos por un signo de porcentaje y dos dígitos hexadecimales para que una cadena viaje con seguridad dentro de un componente URI. La sección 2.3 de RFC 3986 nombra el conjunto sin reserva—ALPHA, DIGIT, guion, punto, guion bajo y tilde—y establece que esos caracteres no deben codificarse en porcentaje al producir datos.
Cualquier otro octeto, incluidos gen-delims y sub-delims reservados y todos los bytes UTF-8 no ASCII, debe codificarse cuando el valor se trate como dato opaco. encodeURIComponent de JavaScript usa un conjunto sin escapar más laxo que también deja literales la exclamación, el apóstrofo, los paréntesis de apertura y cierre y el asterisco.
Esa elección encaja con el comportamiento histórico de formularios del navegador, pero se aparta de la codificación estricta de componentes de RFC 3986 y de muchas bibliotecas de servidor en Python, Go, Java o Rust que solo dejan solas las seis marcas sin reserva. El fallo práctico es sutil: una firma o clave de caché construida a partir de «hello! world» puede hacer hash distinto si un lado emite hello!
world y el otro hello%21world. Esta herramienta aplica siempre el mapa RFC al codificar, con hex en mayúsculas (preferencia %21 en mayúsculas), de modo que caracteres multibyte como café se convierten en caf%C3%A9 y un espacio en %20, mientras ! ' ( ) * pasan a %21 %27 %28 %29 %2A.
La decodificación acepta dígitos hex en mayúsculas o minúsculas, comprueba que cada porcentaje vaya seguido de exactamente dos dígitos hex y reconstruye texto UTF-8.
Dónde aparece la codificación estricta RFC 3986 en el trabajo real
Los servicios de backend que construyen URL de redirección firmadas, cadenas de parámetros OAuth 1.0 o peticiones canónicas HMAC suelen exigir codificación de porcentaje acorde a RFC 3986 y no a encodeURIComponent del navegador, porque las cadenas base de firma tratan ! ' ( ) * como caracteres que deben escaparse.
Los clientes móviles y de escritorio fuera del ecosistema JavaScript suelen llevar bibliotecas que ya siguen la regla de solo sin reserva; un middleware Node que usara encodeURIComponent para los mismos valores produciría fallos de firma intermitentes solo cuando un título de producto o nombre visible contenga un apóstrofo o un paréntesis. Los ingenieros de soporte pegan cadenas a medio codificar de tickets y registros y necesitan una ruta de decodificación que falle con claridad ante escapes truncados en lugar de inventar caracteres.
Los autores de currículos de fundamentos web quieren una página dedicada a la codificación de porcentaje RFC 3986 con el conjunto sin reserva explícito, no enterrada bajo un codificador URL genérico o una herramienta Base64, porque la intención de búsqueda y la diferencia !'() * es lo que buscan estudiantes e integradores. Los ingenieros de localización verifican que idiomas multibyte hagan ida y vuelta sin mojibake.
Si necesita semántica encodeURIComponent, codificación ligera de URI completa que preserve delimitadores estructurales, Base64 o generación de slugs, trátelos como intenciones de búsqueda y aterrizajes distintos en lugar de sobrecargar esta página del codificador RFC 3986.
Qué puede hacer con ella
OAuth y cadenas de consulta firmadas
Codifique en porcentaje los valores de parámetro con el conjunto estricto sin reserva de RFC 3986 para que las cadenas base HMAC y OAuth coincidan con pares no JavaScript que escapan ! ' ( ) *.
Decodificar fragmentos URI de registros o pegados
Decodifique fragmentos codificados en porcentaje de registros y tickets a UTF-8 legible, con fallos duros ante secuencias de porcentaje incompletas o no hexadecimales.
Preguntas frecuentes
¿En qué se diferencia de encodeURIComponent?
encodeURIComponent deja sin escapar ! ' ( ) *. Esta herramienta sigue solo los caracteres sin reserva de RFC 3986 (A–Z a–z 0–9 - . _ ~) y codifica en porcentaje esos cuatro sub-delims como %21 %27 %28 %29 %2A.
¿Puedo codificar y decodificar?
Sí. Ponga mode en encode (predeterminado) para escapar en porcentaje texto plano según RFC 3986, o mode en decode para recuperar texto UTF-8 desde una cadena codificada en porcentaje.
¿Qué ocurre si una secuencia de porcentaje está mal formada?
No se cobra nada por fallos de validación.
¿Los dígitos hex van en mayúsculas o minúsculas al codificar?
La codificación emite dígitos hexadecimales en mayúsculas (%2A no %2a), forma preferida en RFC 3986. La decodificación acepta hex en mayúsculas y minúsculas.
¿Cuánto cuesta el codificador de porcentaje RFC 3986?
La herramienta del navegador es gratuita y se ejecuta en local.
Herramientas relacionadas
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, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/enc/url-rfc3986 \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"hello world!'\''()"}'const res = await fetch("https://api.kit.forhosting.com/enc/url-rfc3986", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "hello world!'()"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/url-rfc3986",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "hello world!'()"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/url-rfc3986", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"hello world!\'()"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"hello world!'()"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/url-rfc3986", 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
{
"text": "hello world!'()"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.url_rfc3986",
"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. |
Notas técnicas
Muchas herramientas cotidianas siguen encodeURIComponent de JavaScript, que deja sin escapar deliberadamente signos de exclamación, apóstrofos, paréntesis y asteriscos—caracteres que RFC 3986 clasifica como sub-delims y que pasarelas estrictas, firmantes OAuth y clientes HTTP multiidioma suelen esperar como %21 %27 %28 %29 %2A. Úsela cuando su contrato diga «codificar en porcentaje según RFC 3986», cuando deba coincidir con un par no JavaScript que solo conserva las seis marcas de puntuación sin reserva, o cuando necesite una sola herramienta gratuita en el navegador y una API de pago que coincidan byte a byte con la misma función pura. El precio de las llamadas API correctas es la base publicada de $0.002 por elemento; los fallos de validación no se facturan.
En qué se diferencia la codificación RFC 3986 de encodeURIComponent
Un porcentaje final suelto, una secuencia como %G1 o UTF-8 inválido tras expandir provocan invalid_input con mensaje de posición en lugar de basura a medio decodificar. La ruta es trabajo puro de cadenas sin red, sin semillas aleatorias y sin reloj de pared, de modo que entradas idénticas siempre producen JSON idéntico. El precio API exitoso es la base publicada de $0.002 por elemento.
Qué envía usted y qué recibe de vuelta
Envíe un campo de cadena obligatorio llamado text y un campo mode opcional. El modo encode escapa el texto en porcentaje según la regla sin reserva de RFC 3986 y devuelve la cadena transformada en result. El modo decode valida cada secuencia de porcentaje, invierte la codificación y devuelve texto UTF-8 plano en result. Comprobaciones clásicas: codificar una frase con espacios y signos de admiración para ver %20 y %21 juntos, decodificar caf%C3%A9%21 de vuelta a café!, y rechazar una cadena que termina en un porcentaje suelto o contiene %ZZ. Si omite mode, encode es el valor predeterminado y un solo payload sigue siendo útil. La respuesta repite mode y el text original, incluye result y la longitud de result, y etiqueta el contrato con standard en RFC 3986, un resumen breve de unreserved y also_escaped con los cuatro caracteres sub-delim que distinguen este mapa de encodeURIComponent. Falta de text, objetos no cadena, valores de mode no admitidos, cadenas más largas que el máximo documentado, escapes de porcentaje incompletos, dígitos no hex tras un porcentaje y errores de host con UTF-8 decodificado inválido fallan con invalid_input y un mensaje claro en inglés. Los fallos de validación no consumen saldo prepago. El precio API exitoso es la base publicada de $0.002 por elemento, alineada con otros codificadores de nivel parse del catálogo.
Dónde aparece la codificación estricta RFC 3986 en el trabajo real
Como esta capacidad es un motor parse puro, el precio API es la base publicada de $0.002 por elemento exitoso y la validación fallida no consume saldo.
Casos de integración
Fixtures golden multiidioma
Genere vectores de codificación y decodificación en los que coincidan bibliotecas URL de Python, Go, Java y Rust, incluidos los caracteres sub-delim que los navegadores suelen dejar literales.