Codificador y Decodificador URL

Arquitectura de URI según RFC 3986: Caracteres Reservados vs. No Reservados

La especificación del Identificador Uniforme de Recursos (URI, RFC 3986) establece una sintaxis inequívoca para identificar recursos a través de protocolos de red. Dado que los URIs deben transitar a través de sistemas de transporte heterogéneos —incluyendo routers legados, pasarelas de correo electrónico y servidores proxy HTTP—, solo un subconjunto restringido del conjunto de caracteres US-ASCII está autorizado para emplearse directamente dentro de una cadena de URI.

Los caracteres se dividen estrictamente en dos clases principales:

Un carácter reservado solo está permitido en forma literal cuando cumple su rol como delimitador entre componentes sintácticos. Cuando un carácter reservado forma parte de los datos dentro de un componente (como un signo et (&) dentro del valor de un parámetro de consulta), debe codificarse obligatoriamente en porcentaje para evitar que los analizadores lo interpreten erróneamente como un delimitador.

Mecanismo de Codificación en Porcentaje y Serialización Multibyte UTF-8

La codificación en porcentaje representa octetos arbitrarios mediante una secuencia de tres caracteres: un signo de porcentaje (%) seguido de dos dígitos hexadecimales que denotan el valor numérico del byte. Al procesar caracteres fuera del rango US-ASCII de 7 bits (puntos de código superiores a U+007F), la sección 2.5 de la norma RFC 3986 estipula un procedimiento de dos fases:

1. Transformación a Bytes UTF-8: El carácter Unicode se transforma en su secuencia canónica de octetos UTF-8 (de 1 a 4 bytes).
2. Formato en Tripletes de Octetos: Cada byte individual resultante se formatea como %HH empleando dígitos hexadecimales en mayúsculas.

Comparativa de APIs Estándar: encodeURI() vs. encodeURIComponent()

El entorno de ejecución de JavaScript ofrece dos funciones integradas con ámbitos de aplicación fundamentalmente distintos. Elegir la función inapropiada es una de las causas más frecuentes de corrupción de rutas y parámetros en aplicaciones web:

La Discrepancia del Espacio: %20 Frente al Signo Más (+)

Un motivo habitual de confusión en ingeniería es si los espacios en blanco deben codificarse como %20 o como +:

• Estándar RFC 3986: Exige %20 en todos los componentes del URI. El signo más está catalogado como subdelimitador reservado y representa un carácter más literal a menos que se escape como %2B.
• Especificación de Formularios HTML (application/x-www-form-urlencoded): Estándar histórico donde los campos de formularios enviados mediante HTTP GET o POST sustituyen los espacios por +.
• Firmas Criptográficas en APIs: Especificaciones modernas —incluidas OAuth 1.0a, AWS Signature Version 4 y OpenAPI— imponen de forma estricta la codificación en porcentaje RFC 3986. Utilizar + en lugar de %20 genera discrepancias en el cálculo de hashes y fallos de autenticación.

Errores Habituales en la Codificación de URLs y Técnicas de Depuración

Los incidentes en entornos de producción suelen originarse por interpretaciones incorrectas de los límites de los URIs y decodificaciones multicapa:

Guía de Implementación en Bibliotecas Estándar por Lenguaje

Las implementaciones nativas en los principales entornos backend gestionan la codificación RFC 3986 mediante utilidades estándar:

// Construcción segura de URLs con URLSearchParams
const params = new URLSearchParams();
params.set('search', 'hola mundo');
params.set('filter', 'categoria&etiqueta');
const url = 'https://api.example.com/items?' + params.toString();
// Salida: https://api.example.com/items?search=hola+mundo&filter=categoria%26etiqueta

// Codificación estricta RFC 3986 (garantizando %20 para espacios)
const strictEncode = (str) => encodeURIComponent(str).replace(/[!'()*]/g, c => '%' + c.charCodeAt(0).toString(16).toUpperCase());

import urllib.parse

# Codificación en porcentaje según RFC 3986 (%20 para espacios)
encoded_component = urllib.parse.quote("hola mundo & datos", safe="")
# Salida: 'hola%20mundo%20%26%20datos'

# Decodificación de cadena codificada
decoded = urllib.parse.unquote(encoded_component)

# Codificación de formulario (application/x-www-form-urlencoded con + para espacios)
form_encoded = urllib.parse.quote_plus("hola mundo & datos")
# Salida: 'hola+mundo+%26+datos'

package main

import (
    "fmt"
    "net/url"
)

func main() {
    // QueryEscape codifica para parámetros de consulta (+ para espacios)
    query := url.QueryEscape("hola mundo & clave")
    
    // PathEscape codifica para segmentos de ruta (%20 para espacios)
    path := url.PathEscape("usuario carpeta/hola mundo")
    
    // Decodificación
    unescaped, _ := url.QueryUnescape(query)
    fmt.Println(query, path, unescaped)
}

import java.net.URLEncoder;
import java.net.URLDecoder;
import java.nio.charset.StandardCharsets;

public class UrlCodec {
    public static void main(String[] args) throws Exception {
        String raw = "hola mundo & usuario";
        // Codifica con + para espacios; sustituir por %20 para RFC 3986 estricto
        String encoded = URLEncoder.encode(raw, StandardCharsets.UTF_8.toString())
                                   .replace("+", "%20");
        String decoded = URLDecoder.decode(encoded, StandardCharsets.UTF_8.toString());
    }
}

<?php
$input = "hola mundo & datos";

// Codificación conforme a RFC 3986 (%20 para espacios)
$rfc3986 = rawurlencode($input);
// Salida: hola%20mundo%20%26%20datos

// Codificación tradicional de formulario (+ para espacios)
$formEncoded = urlencode($input);
// Salida: hola+mundo+%26+datos

// Decodificación
$decoded = rawurldecode($rfc3986);
?>