한국어

인코더·디코더

텍스트를 여러 형식으로 인코딩하고 디코딩하는 도구 모음입니다. 모든 처리가 브라우저에서 이루어지므로 데이터가 전송되지 않습니다.

인코딩 도구 고르기

텍스트 경로로 바이트를 옮길 때는 Base64를, 주소 안에 값을 안전하게 넣을 때는 URL 인코딩을 사용하세요. 체크섬과, 공유 비밀 키로 누가 만든 메시지인지 증명하는 HMAC 서명에는 해시 생성기를 사용합니다.

JWT 디코더는 토큰의 클레임을 읽고, 비밀 키가 있다면 서명까지 확인할 때, JWT 생성기는 테스트용 토큰을 만들 때, CSR 디코더는 인증 기관에 보내기 전에 그 인증서 요청이 실제로 어떤 이름과 키를 요청하는지 확인할 때 사용합니다.

비슷해 보이지만 다른 네 가지 일

인코딩은 데이터를 더 안전한 문자 집합으로 다시 쓰는 일이며 누구나 완전히 되돌릴 수 있습니다. Base64와 퍼센트 인코딩이 여기에 속합니다. 해싱은 단방향이고 키가 없어서, 어느 쪽도 드러내지 않고 두 입력이 같은지 증명합니다. 서명은 비밀 키를 더하는 것이며, 이로써 메시지가 누가 보냈는지에 대한 증거가 됩니다. 마지막으로 확인은 이미 공개된 구조를 디코딩할 뿐이며, JWT와 CSR 리더가 하는 일이 그것입니다.

첫 번째와 세 번째를 혼동하는 것이 비싼 실수입니다. Base64 페이로드는 뒤섞인 것처럼 보이지만 아무것도 보호하지 않습니다. 가진 사람은 누구나 순식간에 읽을 수 있고, 여기 디코더에 붙여 넣어 보면 쉽게 확인할 수 있습니다.

되풀이되는 실패는 겹겹의 층

인코딩은 멱등하지 않습니다. 값을 두 번 이스케이프하면 %20이 %2520이 되고, 따옴표는 백슬래시가 두 번 붙은 따옴표가 되며, 객체를 담아야 할 페이로드에 JSON 문자열이 들어갑니다. 프레임워크가 어차피 인코딩할 값을 애플리케이션 코드가 먼저 인코딩할 때마다 벌어지는 일입니다.

해결책은 받는 쪽에서 두 번 디코딩하는 것이 아니라 두 단계 중 하나를 없애는 것입니다. 두 번 디코딩하면 버그의 위치만 옮겨집니다. 이 도구들로 한 겹씩 디코딩해 보면 실제로 몇 겹이었는지 알 수 있고, 어느 구성 요소가 겹을 더했는지 찾는 가장 빠른 길이 됩니다.

무엇을 붙여 넣는지 생각하기

여기의 모든 처리는 브라우저에서 이루어지므로 붙여 넣은 내용이 업로드되거나 기록되지 않습니다. 알아 둘 만한 사실입니다. 이 도구들에 들어오는 자료는 좀처럼 무해하지 않기 때문입니다. CSR에는 내부 호스트 이름과 조직이, JWT에는 사용자 식별자와 권한이 들어 있고, 해시의 입력 자체가 비밀 정보일 수도 있습니다.

그래도 지킬 만한 습관이 둘 있습니다. 가능하면 운영용이 아니라 테스트용 비밀 키로 서명을 확인하는 것, 그리고 이 페이지를 포함해 어떤 웹 페이지에도 개인 키를 붙여 넣지 않는 것입니다. CSR은 공유해도 안전하지만, 그것에 서명한 키는 그렇지 않습니다.