Você tem que lidar com o formato codificado em URL? Então esse site é perfeito para você! Use o nosso ferramenta online super útil para codificar ou decodificar os seus dados.

Codificar "conhecimento" no formato codificado em URL

Para codificar binários (como imagens, documentos, etc.), use o formulário de carregar arquivo um pouco mais abaixo nessa página.

Codificar arquivos no formato codificado em URL

0 Clique (ou toque) aqui para selecionar um arquivo
O tamanho máximo do arquivo é 192MB.
Trabalhando...
Espere até que o processo da codificação for acabado, por favor.
Sucesso!
{{ output }} baixar o arquivo codificado.
Observe que esse arquivo será deletado do nosso sistema logo depois da primeira tentativa de download ou 15 minutos de inatividade.
Erro!Algo deu errado:{{ error }}

Sobre

Conheça o Decodificar e Codificar URL, uma ferramenta online simples que faz exatamente o que diz: decodifica da codificação de URL assim como codifica para ela de maneira rápida e fácil. O URL codifica os seus dados sem aborrecimento ou decodifica-os em um formato legível por humanos.

A codificação de URL, também conhecida como "codificação por cento", é um mecanismo para codificar informações em um identificador de recurso uniforme (URI). Se bem que seja conhecida como codificação de URL, ela é, na verdade, usada de forma mais geral dentro do conjunto principal de Identificadores Uniformes de Recursos (URI), que inclui o Localizador Uniforme de Recursos (URL) e o Nome Uniforme de Recursos (URN). Por isso, também é usada na preparação de dados do tipo de mídia "application/x-www-form-urlencoded", como é frequentemente empregado no envio de dados da forma HTML em solicitações HTTP.

Opções avançadas
  • Conjunto de caracteres: O nosso site usa o conjunto UTF-8, então os seus dados de entrada são transmitidos nesse formato. Altere essa opção caso queira converter os dados em outro conjunto antes da codificação. Observe que, no caso de dados textuais, o esquema de codificação não contém o conjunto de caracteres, então você tem que especificar o conjunto apropriado durante o processo de decodificação. Quanto aos arquivos, a opção binária é o padrão, o que vai omitir qualquer conversão; essa opção é requerida para tudo, exceto documentos textuais simples.
  • Separador de nova linha: Os sistemas Unix e Windows usam diferentes caracteres de quebra de linha, então antes da codificação, ambas as variantes serão substituídas nos seus dados pela opção escolhida. Para a seção de arquivos, isso é parcialmente irrelevante porque os arquivos já contêm os separadores correspondentes, mas você pode definir qual é que deveria ser usado para as funções "Codificar cada linha separadamente" e "Dividir linhas em blocos".
  • Codificar cada linha separadamente: Mesmo os caracteres de nova linha são convertidos em seus formatos codificados por cento. Utilize essa opção se quiser codificar várias entradas de dados independentes separadas por quebras de linha. (*)
  • Dividir linhas em blocos: Os dados codificados vão se tornar em um texto contínuo sem espaços em branco, então marque essa opção caso queira dividi-lo em várias linhas. O limite de caracteres aplicados é definido na especificação MIME (RFC 2045), que declara que as linhas codificadas não devem ter mais de 76 caracteres. (*)
  • Modo ao vivo: Ao ativar essa opção, os dados inseridos serão codificados imediatamente com as funções JavaScript integradas no seu navegador, sem enviar nenhuma informação para os nossos servidores. Atualmente, este modo suporta apenas o conjunto de caracteres UTF-8.
(*) Essas opções não podem ser habilitadas simultaneamente porque a saída resultante não seria válida para a maioria das aplicações.

Seguro e protegido

Todas as comunicações com os nossos servidores são feitas por meio de conexões criptografadas SSL seguras (https). Apagamos os arquivos carregados de nossos servidores imediatamente depois de serem processados e o arquivo para download resultante é apagado logo depois da primeira tentativa de download ou 15 minutos de inatividade (o que for menos tempo). Não mantemos ou inspecionamos o conteúdo dos dados enviados ou arquivos carregados de forma nenhuma. Leia nossa política de privacidade abaixo por mais detalhes.

Completamente gratuito

A nossa ferramenta é gratuito de usar. A partir de agora, você não precisa de baixar nenhum software para tarefas tão simples.

Detalhes da codificação URL

Tipos de caracteres URIs

Os caracteres permitidos em um URI são ou reservados ou não-reservados (ou um carácter por cento como parte de uma codificação por cento). Os caracteres reservados são os que às vezes têm um significado especial. Por exemplo, os caracteres de barra são usados para separar diferentes partes de um URL (ou mais geralmente, uma URI). Os caracteres não-reservados não possuem esses significados especiais. Usando a codificação por cento, os caracteres reservados são representados como sequências de caracteres especiais. Os conjuntos de caracteres reservados e não-reservados e as circunstâncias sob as quais certos caracteres reservados têm significado especial mudaram um pouco a cada nova revisão das especificações que regem os URIs e os esquemas de URI.

RFC 3986 seção 2.2 Caracteres Reservados (Janeiro de 2005)
! * ' ( ) ; : @ & = + $ , / ? # [ ]

RFC 3986 seção 2.3 Caracteres Não-Reservados (Janeiro 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 - _ . ~

Outros caracteres em um URI têm que ser codificados por cento.

Caracteres reservados na codificação por cento

Quando um carácter do conjunto reservado (um "carácter reservado") tem um significado especial (um "propósito reservado") em um contexto específico e um esquema URI diz que é necessário utilizar esse carácter para algum outro propósito, o carácter deve ser codificado por cento. A codificação por cento de um carácter reservado significa converter o carácter em seu valor de byte correspondente em ASCII e, em seguida, representar esse valor como um par de dígitos hexadecimais. Os dígitos, precedidos por um sinal de porcentagem ("%"), são usados no URI no lugar do carácter reservado. (Quanto a um carácter não ASCII, ele normalmente é convertido na sua sequência de bytes em UTF-8 e, em seguida, cada valor de byte é representado como pode ser visto acima.)

O carácter reservado "/", por exemplo, se for utilizado no componente "caminho" de um URI, tem o significado especial de ser um delimitador entre os segmentos do caminho. Se, de acordo com um determinado esquema de URI, "/" necessitar de estar em um segmento de caminho, os três caracteres "%2F" (ou "%2f") têm que ser usados no segmento em vez de "/".

Caracteres reservados depois da codificação por cento
! # $ & ' ( ) * + , / : ; = ? @ [ ]
%21 %23 %24 %26 %27 %28 %29 %2A %2B %2C %2F %3A %3B %3D %3F %40 %5B %5D

Os caracteres reservados que não têm propósito reservado em um determinado contexto também podem ser codificados por cento, mas não são semanticamente diferentes de outros caracteres.

No componente "pergunta" de um URI (a parte após um carácter "?"), por exemplo, "/" ainda é considerado um carácter reservado, mas normalmente não tem propósito reservado (a não ser que um esquema de URI específico diga o contrário). O carácter não precisa ser codificado por cento quando não tem propósito reservado.

Os URIs que diferem apenas em se um carácter reservado é codificado por cento ou não, são normalmente considerados não equivalentes (denotando o mesmo recurso), a menos que os caracteres reservados em questão não tenham propósito reservado. Essa determinação depende das regras estabelecidas para caracteres reservados por esquemas individuais de URI.

Caracteres não-reservados na codificação por cento

Os caracteres do conjunto não-reservado nunca precisam de ser codificados por cento.

Os URIs que diferem apenas em se um carácter não reservado é codificado por cento ou não, são equivalentes por definição, mas os processadores URI, na prática, nem sempre podem tratá-los de forma equivalente. Por exemplo, os consumidores de URI não devem tratar "%41" de maneira diferente de "A" ("%41" é a codificação por cento de "A") ou "%7E" de maneira diferente de "~", mas alguns fazem-no. Para obter o máximo de interoperabilidade, os produtores de URI são, consequentemente, desencorajados a codificar por cento caracteres não-reservados.

Codificação por cento do carácter de porcentagem

Como o carácter de porcentagem ("%") serve como indicador para octetos codificados por cento, ele deve ser codificado por cento como "%25" a fim de que esse octeto seja usado como dados em um URI.

Dados arbitrários na codificação por cento

A maioria dos esquemas de URI envolve a representação de dados arbitrários, como um endereço IP ou caminho do sistema de arquivos, como componentes de um URI. As especificações do esquema de URI devem, mas geralmente não fornecem, um mapeamento explícito entre os caracteres de URI e todos os valores de dados possíveis representados por esses caracteres.

Dados binários

Desde a publicação do RFC 1738 em 1994, foi especificado que os esquemas que fornecem a representação de dados binários em um URI devem dividir os dados em bytes de 8 bits e codificar por cento cada byte da maneira acima mencionada. O valor do byte 0F (hexadecimal), por exemplo, deveria ser representado por "%0F", mas o valor do byte 41 (hexadecimal) pode ser representado por "A" ou "%41". O uso de caracteres não codificados para caracteres alfanuméricos e outros não-reservados é normalmente preferido porque resulta em URLs reduzidos.

Dados dos caracteres

O procedimento para dados binários na codificação por cento geralmente foi extrapolado, às vezes de forma errada ou sem ser totalmente especificado, para se aplicar a dados baseados em caracteres. Nos anos de formação da World Wide Web, ao lidar com caracteres de dados no repertório ASCII e usar seus bytes correspondentes em ASCII como base para determinar sequências codificadas por porcentagem, essa prática era relativamente inofensiva; muitas pessoas supuseram que os caracteres e bytes são mapeados um a um e são intercambiáveis. Contudo, a necessidade de representar caracteres fora do intervalo de ASCII cresceu depressa e os esquemas e protocolos de URI muitas vezes falharam em fornecer regras padrão para preparar dados de caracteres para inclusão em um URI. As aplicações da Web, consequentemente, começaram a usar diferentes codificações multibytes, dinâmicas e outras codificações não-compatíveis com ASCII como base para a codificação por cento, levando a ambiguidades, assim como dificuldade em interpretar URIs de maneira confiável.

Por exemplo, muitos esquemas e protocolos de URI baseados em RFCs 1738 e 2396 supõem que os caracteres de dados serão convertidos em bytes de acordo com alguma codificação de caracteres não-especificada antes de serem representados em um URI por caracteres não-reservados ou bytes codificados por cento. Caso o esquema não permita que o URI forneça uma dica sobre qual codificação foi usada, ou se a codificação entrar em conflito com o uso de ASCII para codificar por cento caracteres reservados e não-reservados, o URI não poderá ser interpretado de forma confiável. Alguns esquemas falham em levar em conta a codificação e, em vez disso, apenas sugerem que os caracteres de dados sejam mapeados diretamente para os caracteres URI, o que deixa isso para os usuários individuais decidirem se e como codificar por cento os caracteres de dados que não estão nos conjuntos reservados ou não-reservados.

Caracteres comuns depois da codificação (baseado no ASCII ou UTF-8)
nova linha barra de espaço " % - . < > \ ^ _ ` { | } ~
%0A ou %0D ou %0D%0A %20 %22 %25 %2D %2E %3C %3E %5C %5E %5F %60 %7B %7C %7D %7E

Dados de caracteres arbitrários às vezes são codificados por cento e usados em situações não URI, como para programas de ofuscação de senha ou outros protocolos de tradução específicos do sistema.
Alternar para a versão móvel
2012-2024 urlencoder.org
Política de privacidade Contatos
Esse website utiliza cookies. Usamos cookies para personalizar conteúdo/anúncios e para analisar nosso tráfego.