Base64 값에는 +, /, =가 들어갈 수 있습니다. 쿼리 문자열 파서는 그대로 들어온 +를 공백으로 해석할 수 있습니다. 문자를 무작위로 바꾸면 원래 실수가 가려질 수 있습니다.
실제 비밀번호, 토큰, 개인정보 대신 무해한 예제를 사용하세요. UTF-8 텍스트 a?b는 YT9i로 인코딩됩니다. 이 첫 예제는 왕복 변환을 확인하지만 문제를 일으키는 문자를 포함하지 않습니다. 별도의 리터럴 테스트 값 a+b/c=는 URL 구성요소 이스케이프 확인에 유용하며, 올바른 Base64 값으로 제시하는 것은 아닙니다.
URL Encoder & Decoder에서 매개변수의 값만 인코딩하세요. 리터럴 a+b/c=는 a%2Bb%2Fc%3D가 됩니다. 인코딩된 값을 선택한 키 뒤에 넣으세요. 예: ?value=a%2Bb%2Fc%3D. https://... 주소 전체를 구성요소 인코더에 넣고 URL 구분자가 그대로 남기를 기대하지 마세요.
받는 쪽에서는 URL 구성요소를 한 번 디코딩하세요. 결과는 여전히 a+b/c=여야 합니다. 수신기가 application/x-www-form-urlencoded 데이터를 파싱한다면 원시 + 처리 규칙은 decodeURIComponent와 다릅니다. FrAIFlow 구성요소 디코더는 리터럴 +를 유지하며 폼 디코딩 규칙을 자동 적용하지 않습니다. 이 차이는 진단의 일부이지 도구가 고장 났다는 증거가 아닙니다.
실제로 유효한 Base64 값을 복원한 뒤에만 Base64 디코딩하세요. 패딩 오류나 UTF-8 오류가 나면 중단하고 원래 표현과 선택한 형식을 확인하세요. 읽을 만한 문자열이 될 때까지 반복 디코딩하는 것은 안전한 복구 방법이 아닙니다. 예상하지 못한 %252B는 인코딩 계층이 하나 더 있음을 나타낼 수 있지만, 그것만으로 어느 시스템이 추가했는지는 알 수 없습니다.
인코딩은 암호화가 아닙니다. URL은 방문 기록과 서버 로그에 저장될 수 있으므로, 전송을 위해 인코딩하기보다는 쿼리 문자열에 비밀을 넣지 않는 편이 안전합니다.
관련 도구 사용
입력과 결과는 이 브라우저 안에 남습니다. 계정이나 업로드가 필요하지 않습니다.