Um valor Base64 pode conter +, / e =. Um analisador de query string pode interpretar um + sem escape como espaço. Substituir caracteres aleatoriamente pode esconder o erro original.
Use um exemplo inofensivo, nunca uma senha, token ou registro pessoal real. O texto UTF-8 a?b é codificado como YT9i. Este primeiro exemplo verifica a conversão de ida e volta, mas não contém os caracteres problemáticos. Outro valor literal de teste, a+b/c=, é útil para verificar o escape de componentes de URL; ele não é apresentado como Base64 válido.
No URL Encoder & Decoder, codifique somente o VALOR do parâmetro. O literal a+b/c= torna-se a%2Bb%2Fc%3D. Coloque o valor codificado após uma chave escolhida, por exemplo ?value=a%2Bb%2Fc%3D. Não passe o endereço https://... inteiro a um codificador de componentes esperando que os separadores da URL permaneçam intactos.
No destino, decodifique o componente da URL uma vez. O resultado ainda deve ser a+b/c=. Se o destinatário analisar dados application/x-www-form-urlencoded, as regras para um + sem escape diferem de decodeURIComponent. O decodificador de componentes do FrAIFlow mantém um + literal; não aplica automaticamente as regras de decodificação de formulários. Essa diferença faz parte do diagnóstico e não comprova defeito em uma ferramenta.
Decodifique Base64 somente após recuperar um valor Base64 realmente válido. Se surgir um erro de preenchimento inválido ou de UTF-8, pare e verifique a representação original e o formato selecionado. Decodificar repetidamente até uma string parecer legível não é um método seguro de reparo. Um %252B inesperado pode indicar outra camada de codificação, mas sozinho não prova qual sistema a adicionou.
Codificação não é criptografia. URLs podem ser armazenadas no histórico e nos logs do servidor; manter um segredo fora da query string é mais seguro do que codificá-lo para transporte.
Use as ferramentas relacionadas
Entradas e resultados ficam neste navegador. Sem conta ou uploads.