Lección 2
Reglas de codificación porcentual
Cómo `%XX` representa bytes y qué caracteres deben codificarse.
La codificación porcentual escribe un % seguido de exactamente dos dígitos hexadecimales por cada octeto escapado:
byte 32 (space) → %20
byte 38 (&) → %26
byte 231 (decimal) → hex E7 → %E7 (meaning depends on decoding context!)
Las letras A–F pueden aparecer en mayúsculas o minúsculas (%e7 ≡ %E7). La interoperabilidad mejora cuando las herramientas son consistentes, pero los parsers deben aceptar mayúsculas y minúsculas mezcladas.
Un escape = un byte (no «una unidad de código UTF-16»)
Cuando codifiques cadenas Unicode, codifica los octetos de UTF-8 salvo que un esquema indique lo contrario explícitamente:
π (U+03C0)
UTF-8 bytes: CF 80 → %CF%80
Misleading mental model (wrong): encode the code point digits “03C0” in hex
Correct model: serialize to bytes first, escape each problematic byte as %HH
¿Qué bytes necesitan escape?
Lista orientativa a nivel de aprendizaje:
- Bytes cuyo carácter gráfico interactuaría con separadores URI (
?,&,#,/,:,@,[,]) cuando esos bytes pertenecen a datos opacos y no a puntuación. - Bytes fuera del ASCII para rutas de compatibilidad amplia.
- Bytes de control, espacios, DEL y espacios en blanco ambiguos cuando son dato literal dentro de parámetros.
RFC 3986 define reglas genéricas más comportamientos normalizados; los frameworks pueden endurecerlas (por ejemplo, rechazando % sueltos al final).
Escapes inválidos
Las secuencias incompletas confunden a los parsers:
% → malformed (no digits)
%AB → malformed (needs two hex nibbles)
%GG → invalid hex digits
Las buenas bibliotecas validan o rechazan entradas malformadas en lugar de «adivinar» en silencio.
Sobre-codificación y doble codificación
Aplicar codificación porcentual dos veces es un bug recurrente:
literal value: 100%
first pass: 100%25 (literal percent becomes %25)
mistaken pass: 100%2525 (oops—encoded already-safe % again)
Si tu servidor recibe %2525, a menudo decodifica dos veces hasta un solo % — no lo que pretendías para datos de visualización. Decide una vez si un subsistema espera texto codificado o decodificado y mantén claro ese invariante.
Consejos de normalización
La canonicalización incluye decisiones como:
- Hexadecimal en mayúsculas o minúsculas (ambos válidos).
- Elegir entre codificar un carácter de puntuación o dejarlo literal cuando sea legalmente inequívoco dentro de un componente.
- Normalizar Unicode a NFC antes de codificar UTF-8 (opcional, pero evita que grafías duplicadas diverjan entre servidores).
La consistencia entre tus gateways (CDN frente a app frente a base de datos) evita desajustes sutiles durante la validación de firmas o el almacenamiento en caché.