¿Tiene que ocuparse del formato de URL codificada? Entonces esta página es perfecta para Ud. Utilice nuestra práctica herramienta en línea para codificar o decodificar sus datos.

Codifique "duda" en formato codificado en URL

Para codificar binarios (como imágenes, documentos, etc.) utilice el formulario de carga de archivos que encontrará un poco más abajo en esta página.

Codifique archivos al formato codificado en URL

Haga clic (o pulse) aquí para seleccionar un archivo
El tamaño máximo del archivo es de 192MB.

Sobre

Conozca URL Decode and Encode, una herramienta sencilla en línea que hace exactamente lo que dice: decodifica a partir de la codificación URL, así como codifica en ella de forma rápida y sencilla. URL codifica sus datos sin problemas o los decodifica en un formato legible por humanos.

La codificación URL, también conocida como "codificación porcentual", es un mecanismo para codificar información en un Identificador Uniforme de Recursos (URI). Aunque es conocida como codificación URL, en realidad se utiliza de forma más general dentro del conjunto principal de Identificadores Uniformes de Recursos (URI), que incluye tanto el Localizador Uniforme de Recursos (URL) como el Nombre Uniforme de Recursos (URN). Como tal, también se utiliza en la preparación de datos del tipo de medio "application/x-www-form-urlencoded", ya que se emplea a menudo en el envío de datos de formularios HTML en peticiones HTTP.

Opciones avanzadas
  • Conjunto de caracteres: Nuestro sitio web utiliza el conjunto de caracteres UTF-8 por tanto sus datos de entrada se transmiten en este formato. Cambie esta opción si Ud. quiere convertir los datos en otro conjunto de caracteres antes de la codificación. No olvide que en caso de datos textuales el esquema de codificación no contiene el conjunto de caracteres, por lo que Ud. tiene que especificar el conjunto adecuado durante el proceso de decodificación. En cuanto a los archivos, la opción binaria es la predeterminada que omitirá cualquier conversión; esta opción se requiere para todo excepto los documentos de texto sin formato.
  • Separador de nueva línea: Los sistemas Unix y Windows utilizan caracteres de salto de línea diferentes, así antes de codificar cualquiera de las dos variantes será sustituida dentro de sus datos por la opción seleccionada. Para la sección de archivos, esto es parcialmente irrelevante ya que los archivos ya contienen los separadores correspondientes, pero Ud puede definir cuál desea usar para las funciones "codifique cada línea por separado" y "divida las líneas en trozos".
  • Codifique cada línea por separado: Incluso los caracteres de nueva línea se convierten a sus formas codificadas en porcentaje. Utilice esta opción si desea codificar varias entradas de datos independientes separadas por saltos de línea. (*)
  • Divida las líneas en trozos: Los datos codificados se convertirán en un texto continuo sin espacios, entonces active esta opción si desea dividirlos en varias líneas. El límite de caracteres aplicado está definido en la especificación MIME (RFC 2045), que establece que las líneas codificadas no deben superar los 76 caracteres. (*)
  • Modo en directo: Al activar esta opción, los datos introducidos se decodifican inmediatamente con las funciones JavaScript integradas en su navegador sin enviar información alguna a nuestros servidores. Actualmente, este modo sólo admite el conjunto de caracteres UTF-8.
(*) No se puede activar estas opciones paralelamente ya que el resultado no sería válido para la mayoría de las aplicaciones.

Seguro y protegido

Todas las comunicaciones con nuestros servidores se realizan a través de conexiones seguras SSL encriptadas (https). Borramos los archivos cargados de nuestros servidores inmediatamente después de que ellos hayan sido procesados y el archivo descargable resultante se elimina justo después del primer intento de descarga o de 15 minutos de inactividad (lo que sea más corto). En ningún caso guardamos o revisamos el contenido de los datos o archivos cargados. Para más información véase nuestra política de privacidad a continuación.

Uso gratuito

Nuestra herramienta es de uso gratuito. A partir de ahora Ud. no necesitará descargar ningún software para realizar tareas tan sencillas.

Detalles de la codificación URL

Tipos de caracteres URI

Los caracteres permitidos en URI son reservados o no reservados (o un carácter de porcentaje como parte de codificación porcentual) Los caracteres reservados son caracteres con significado especial. Por ejemplo, los caracteres de barra diagonal se utilizan para separar diferentes partes de una URL (o más generalmente una URI). Los caracteres no reservados no tienen tales significados. Mediante codificación porcentual los caracteres reservados se representan mediante secuencias de caracteres especiales. Los conjuntos de caracteres reservados y no reservados y las circunstancias en las que ciertos caracteres reservados tienen un significado especial han cambiado ligeramente con cada revisión de las especificaciones que gobiernan los URI y los esquemas de URI.

Sección RFC 3986, 2.2 Caracteres Reservados (enero de 2005)
! * ' ( ) ; : @ & = + $ , / ? # [ ]

Sección RFC 3986, 2.3 Caracteres No Reservados (enero de 2005)
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 - _ . ~

Otros caracteres en un URI deben ser codificados en porcentaje.

Codificación porcentual de caracteres reservados

Cuando un carácter del conjunto reservado (un carácter reservado) tiene un significado especial (un propósito reservado) en un contexto determinado, y un esquema de URI dice que es necesario usar ese carácter para algún otro propósito, entonces el carácter debe ser codificado en porcentaje. La codificación porcentual de un carácter reservado implica convertir el carácter en su valor de byte correspondiente en ASCII y luego representar este valor como un par de dígitos hexadecimales. Los dígitos precedidos por un signo de porcentaje (%) se usan en el URI en lugar del carácter reservado. (Para un carácter no ASCII normalmente se convierte en su secuencia de bytes en UTF-8 y luego cada valor de byte se representa como se indica arriba.)

El carácter reservado "/", por ejemplo, si se utiliza en el componente "ruta" de un URI, tiene el significado especial de ser un delimitador entre segmentos de ruta. Si de acuerdo con un esquema dado de URI "/" necesita estar en un segmento de ruta, entonces los tres caracteres "%2F" (or "%2f") deben ser usados en el segmento en lugar de "/".

Caracteres reservados después de la codificación porcentual
! # $ & ' ( ) * + , / : ; = ? @ [ ]
%21 %23 %24 %26 %27 %28 %29 %2A %2B %2C %2F %3A %3B %3D %3F %40 %5B %5D

Los caracteres reservados que no tienen un propósito reservado en un contexto particular también pueden ser codificados en porcentaje, pero no son semánticamente diferentes de otros caracteres.

En el componente "consulta" de un URI (la parte después del caracter "?") por ejemplo "/" aún se considera un carácter reservado aunque no tiene un propósito reservado (a menos que un esquema de URI concreto indique lo contrario). El caracter no tiene que ser codificado en porcentaje cuando no tiene un propósito reservado.

Los URI que sólo se diferencian en que si un carácter reservado está codificado en porcentaje o no, normalmente no se consideran equivalentes (que denotan el mismo recurso), a menos que los caracteres reservados en cuestión no tengan un propósito reservado. Esta determinación depende de las reglas establecidas para caracteres reservados por esquemas de URI individuales.

Codificación porcentual de caracteres no reservados

Los caracteres del conjunto no reservado nunca requieren codificación porcentual.

Los URI que sólo se diferencian en que si un carácter no reservado está codificado en porcentaje o no, son equivalentes por definición, pero los procesadores de URI no siempre reconocen esta equivalencia en la práctica. Por ejemplo, los consumidores de URI no deberían tratar "%41" de forma diferente a "A" ("%41" es la codificación porcentual de "A") o "%7E" de forma diferente a "~", aunque unos lo hacen. Para lograr la máxima interoperabilidad, se desaconseja a los productores de URI codificar porcentualmente los caracteres no reservados.

Codificación porcentual del carácter de porcentaje

Debido a que el carácter de porcentaje ("%") sirve como indicador para octeos codificados en porcentaje, esto debe ser codificado en porcentaje como "%25" para que ese octeo sea utilizado como un dato dentro de un URI.

Codificación porcentual de datos arbitrarios

La mayoría de los esquemas de URI incluyen la representación de datos arbitrarios como, por ejemplo, una dirección IP o una ruta de sistema de archivos como componentes de un URI. Las especificaciones de esquemas de URI deberían proporcionar - aunque no siempre lo hacen - un mapeo explícito entre los caracteres URI y todos los posibles valores de datos representados por dichos caracteres.

Datos binarios

Desde la publicación de RFC 1738 en 1994, se ha especificado que esquemas que proporcionan la representación de los datos binarios en un URI, tienen que dividir los datos en bytes de 8 bits y codificar cada byte en porcentaje de la misma manera que antes. El valor de byte 0F (hexadecimal), por ejemplo, debe ser representado por "%0F", pero el valor de byte 41 (hexadecimal) puede ser representado por "A" o "%41" Por lo general, se prefiere el uso de caracteres no codificados para caracteres alfanuméricos y otros caracteres no reservados ya que resulta en URL más cortos.

Datos de carácter

El procedimiento de codificación porcentual de los datos binarios se ha extrapolado a menudo, a veces de forma inadecuada o sin especificarlo completamente, para aplicarlo a los datos basados en caracteres. En los años de formación de la World Wide Web, cuando se trataba con caracteres de datos del repertorio ASCII y se usaban sus bytes correspondientes en ASCII como base para determinar las secuencias codificadas en porcentaje, esta práctica era relativamente inofensiva; mucha gente asumía que los caracteres y los bytes se correspondían uno a uno y eran intercambiables. Sin embargo, la necesidad de representar caracteres fuera de la gama de ASCII creció rápidamente, y los esquemas y protocolos de URI a menudo no ofrecían reglas estándar para preparar datos de caracteres para su inclusión en un URI. Como consecuencia, las aplicaciones web comenzaron a utilizar diferentes codificaciones multibyte, de estado y otras no compatibles con ASCII como base para la codificación porcentual, lo que provocó ambigüedades y dificultades para interpretar los URI de forma fiable.

Por ejemplo, muchos esquemas y protocolos de URI basados en las RFC 1738 y 2396 suponen que los caracteres de los datos se convertirán a bytes según alguna codificación de caracteres no especificada antes de ser representados en un URI mediante caracteres no reservados o bytes codificados porcentualmente. Si el esquema no permite que el URI dé una pista sobre la codificación utilizada, o si la codificación entra en conflicto con el uso de ASCII para codificar porcentualmente los caracteres reservados y no reservados, el URI no podrá interpretarse de forma fiable. Algunos sistemas no tienen en cuenta la codificación y se limitan a sugerir que los caracteres de datos se correspondan directamente con los caracteres URI, lo que deja en manos de cada usuario la decisión de codificar porcentualmente los caracteres de datos que no están ni en el conjunto reservado ni en el no reservado.

Caracteres comunes tras la codificación porcentual (basada en ASCII o UTF-8)
nueva línea espacio " % - . < > \ ^ _ ` { | } ~
%0A or %0D or %0D%0A %20 %22 %25 %2D %2E %3C %3E %5C %5E %5F %60 %7B %7C %7D %7E

Los datos de caracter arbitrario a veces se codifican en porcentaje y se utilizan en situaciones de no URI, como para programas de ofuscación de contraseñas u otros protocolos de traducción específicos del sistema.
Cambiar a la versión de sobremesa
2012-2024 urlencoder.org
Política de privacidad Contacto
Este sitio web utiliza cookies. Las utilizamos para personalizar contenidos y anuncios, y para analizar nuestro tráfico.