Herramientas de desarrollo · Codificador y decodificador de URL
Cómo funciona la codificación porcentual: desde caracteres hasta UTF-8 bytes y secuencias %XX
· Cómo funciona
codificación de URL utf-8 codificación porcentual desarrollador
La codificación porcentual no codifica caracteres; codifica bytes. Esta publicación muestra cómo un carácter se convierte en UTF-8 bytes y luego en pares hexadecimales, y por qué una letra acentuada ocupa dos grupos %XX mientras que un emoji ocupa cuatro.
Por qué 'é' se convierte en %C3%A9 en lugar de %E9: la observación que revela la capa de bytes que se encuentra debajo
Cuando un desarrollador junior ve %C3%A9 en una URL, la codificación porcentual opera en bytes, no en caracteres. El carácter é no es un byte; UTF-8 lo codifica como dos: C3 A9. La regla de codificación porcentual del RFC 3986 es simple: codifica cada byte como un signo de porcentaje seguido de dos dígitos hexadecimales. Esa distinción transforma la explicación de misteriosa a lógica.
Para comprender la codificación porcentual es necesario comprender UTF-8. El texto debe convertirse a bytes mediante codificación de caracteres. UTF-8 es el estándar para URL y sitios web. Expresa caracteres como secuencias de bytes de longitud variable: ASCII usa un byte, las letras acentuadas usan dos, los emoji usan cuatro. Cada etapa es distinta: carácter, punto de código Unicode, UTF-8 bytes y luego %XX pares. Saltar a hexadecimal sin comprender los bytes no tiene sentido.
La regla de codificación porcentual de RFC 3986: un % seguido de dos dígitos hexadecimales por byte, preferiblemente mayúsculas.
RFC 3986 define una regla: codificar cada byte como porcentaje seguido de dos dígitos hexadecimales en mayúscula. Los caracteres no reservados que no necesitan codificación son letras, dígitos, guión, guión bajo, punto y tilde. Todo lo demás debe estar codificado. Los espacios se convierten en %20, las barras diagonales se convierten en %2F y el signo de porcentaje se convierte en %25. Esto evita que los caracteres especiales en los valores de consulta rompan la estructura de la URL.
Un espacio se codifica como byte 0x20 y se convierte en %20. Una barra diagonal es 0x2F y se convierte en %2F. Estos son caracteres ASCII que necesitan un byte. Las letras acentuadas y los emoji difieren. El signo de porcentaje se convierte en %25. Los delimitadores reservados, como los dos puntos, se codifican para preservar la estructura. Esto evita que un signo comercial o igual incrustado en un parámetro de consulta interrumpa el análisis. Cada byte se convierte en %HH.
UTF-8 como conjunto de caracteres asumido: por qué las URL modernas son UTF-8 y dónde están las excepciones heredadas
UTF-8 utiliza codificación de longitud variable. ASCII desde los puntos de código 0 a 127 es un byte. Los caracteres desde 128 hasta 2047, incluidas las letras latinas acentuadas, son dos bytes. Los caracteres de 2048 a 65535, comunes en las escrituras de Asia oriental, tienen tres bytes. Los caracteres por encima de 65535, incluida la mayoría de los emoji, tienen cuatro bytes. Cada byte tiene el prefijo de bits que indican cuántos bytes siguen.
La letra é acentuada es el punto de código Unicode U+00E9. UTF-8 lo codifica como dos bytes: 0xC3 y 0xA9. La codificación porcentual produce %C3%A9. La ü alemana (U+00FC) se codifica como 0xC3 0xBC y se convierte en %C3%BC. La ñ española (U+00F1) se codifica como 0xC3 0xB1, convirtiéndose en %C3%B1. El patrón es consistente: el primer byte señala una secuencia de dos bytes. Una letra acentuada se expande en seis caracteres en la codificación.
Ejemplo resuelto: codificación de 'café 😀' byte a byte: los puntos de código, los UTF-8 bytes y la cadena resultante
Emoji hace que la capa de bytes sea obvia. El emoji del pulgar hacia arriba 👍 es el punto de código U+1F44D. UTF-8 lo codifica como cuatro bytes: F0 9F 91 8D. La codificación porcentual produce %F0%9F%918D: doce caracteres para un símbolo. El emoticón 😀 (U+1F600) se codifica como F0 9F 98 80, convirtiéndose en %F0%9F%9880. Las secuencias de cuatro bytes se convierten en caracteres codificados al doce por ciento.
El texto mixto muestra por qué es importante comprender los bytes. La frase "café 😀" contiene ASCII simple, un acento y un emoji. Las letras c, a, f se codifican como 63, 61, 66. La é codifica como C3 A9. El espacio codifica como 20. El emoji se codifica como F0 9F 98 80. El resultado es "caf%C3%A9%20%F0%9F%9880". Comprender qué bytes necesitan codificación hace que la salida sea predecible.
Decodificación a la inversa: recopila %XX grupos en bytes y solo luego los interpreta como UTF-8
La decodificación invierte el proceso. Un decodificador busca %XX pares y los recopila en valores de bytes. Al ver %C3%A9, extrae los bytes C3 y A9. La decodificación UTF-8 los interpreta como el carácter é. Si una secuencia está incompleta, como solo %C3, el resultado es un error. El decodificador sabe por los bits de prefijo UTF-8 que C3 requiere un segundo byte.
El caso no importa en dígitos hexadecimales; %C3%A9 y %c3%a9 se decodifican de forma idéntica. RFC permite mayúsculas o minúsculas, aunque se prefiere mayúsculas. Pero las mayúsculas y minúsculas importan para los caracteres: é (como %C3%A9) no es lo mismo que É (como %C3%89). La comparación de URL debe normalizar el porcentaje de codificación o correr el riesgo de tratar recursos idénticos como diferentes. Los marcos se normalizan antes del almacenamiento en caché.
Por qué las mayúsculas y minúsculas no importan en dígitos hexadecimales pero sí en otros lugares: reglas de normalización y comparación de URL
RFC 3986 menciona punycode para nombres de dominio y codificación de formularios para envíos como reglas separadas. Punycode codifica nombres de dominio que no son ASCII sin signos de porcentaje para compatibilidad con DNS. El dominio 😀.example se convierte en "xn--js8h.example". La codificación de formulario modifica la codificación porcentual con una excepción: los espacios se convierten en signos más en lugar de %20. Los formularios enviados como application/x-www-form-urlencoded usan más para los espacios.
La herramienta de codificación de URL muestra los tres modos: codificación de componentes, codificación de URL completa y codificación de formularios. Codificación de componentes con encodeURIComponent codifica cada carácter especial, incluidos los delimitadores, adecuados para valores de consulta. La codificación de URL completa con encodeURI conserva los caracteres estructurales de las URL completas. La codificación de formulario es para cuerpos POST. Cada uno usa UTF-8; sólo difieren en qué bytes quedan sin codificar.
Punycode y codificación de formularios: estándares hermanos, no extensiones de codificación porcentual
La perspectiva de bytes resuelve misterios de URL. ¿Por qué un emoji necesita doce caracteres? Porque UTF-8 usa cuatro bytes, cada uno de los cuales se convierte en %HH. ¿Por qué algunas URL tienen %2F para barras mientras que otras tienen barras simples? Porque el modo de codificación decide: una barra diagonal en un segmento de ruta permanece sin codificar, pero dentro de un valor de consulta debe ser %2F para evitar lecturas erróneas.
Piense en bytes para una codificación porcentual predecible. Un carácter es un punto de código Unicode. UTF-8 es su representación en bytes. La codificación porcentual es el formato de transmisión. La expansión del carácter ocurre en la capa UTF-8. Las mayúsculas y minúsculas no afectan la decodificación, pero las mayúsculas y minúsculas sí. Las secuencias de bytes no válidas fallan en UTF-8 debido a reglas estrictas de prefijo. La herramienta de codificación de URL muestra esta progresión.
Conclusión: piense en bytes: cómo el codificador y decodificador de URL muestra el %XX exacto de salida para cualquier texto que pegue, en el navegador
Ejemplo resuelto: codificación "café 😀". La palabra café tiene letras c, a, f como bytes individuales ASCII: 63, 61, 66. La é es UTF-8 dos bytes: C3 A9. El espacio es 20. Emoji 😀 tiene cuatro bytes: F0 9F 98 80. Las letras ASCII no reservadas permanecen visibles. Resultado: "caf%C3%A9%20%F0%9F%9880". Esto muestra por qué un emoji se expande a doce caracteres.
Conclusión: piense en bytes, no en caracteres. La codificación porcentual se aplica después de la codificación UTF-8. Cada byte se convierte en %HH. La longitud variable UTF-8 significa que los caracteres se expanden de manera diferente: ASCII se convierte en %XX (dos caracteres), los acentos de dos bytes se convierten en %XX%XX (seis caracteres), los emoji de cuatro bytes se convierten en %XX%XX%XX%XX (doce caracteres). Pegue el texto en la herramienta de codificación de URL y observe la progresión.