인코더 / 디코더

Base64, Base64URL, URL 인코딩, HTML 엔티티, Hex를 양방향으로 변환합니다. 로그나 쿼리스트링에서 깨져 보이는 값을 해석할 때 쓰는 일상적인 도구입니다.

Base64와 URL 인코딩은 데이터를 감추는 방법으로 설명되는 일이 많지만 그렇지 않습니다. 둘 다 키 없이 누구나 되돌릴 수 있습니다. 이들이 하는 일은 특정 문자만 허용하는 통로 — 메일 헤더, 쿼리 문자열, HTML 속성 — 를 임의의 바이트가 무사히 통과하게 만드는 것입니다.

실제로 버그를 만드는 구분은 여기서 명시적으로 다룹니다. Base64와 base64url은 두 글자와 패딩이 다르므로 JWT 조각은 표준 알파벳으로 디코딩되지 않습니다. encodeURIComponent는 &, =, ? 같은 구분자를 이스케이프하고 encodeURI는 일부러 남겨 둡니다. 그래서 하나는 파라미터 값에, 다른 하나는 URL 전체에 맞습니다. 처리는 전부 UTF-8 기준이라 한글이 물음표로 바뀌지 않고 그대로 왕복합니다.

Base64는 3바이트를 4문자로 바꾸므로, 패딩을 세기 전에 이미 3분의 1만큼 커집니다. 사진을 data URI로 인라인하면 스타일시트가 부풀어 오르는 이유이고, JSON 페이로드로 큰 파일을 옮길 때 base64 필드가 나쁜 선택인 이유입니다. 끝의 등호는 4의 배수로 맞추기 위한 패딩입니다. 어떤 디코더는 이것을 요구하고 어떤 디코더는 없어도 넘어가는데, 뒤쪽 패딩이 빠진 채 복사된 토큰이 어떤 곳에서는 실패하고 어떤 곳에서는 동작하는 이유가 정확히 이것입니다. JWT와 URL 파라미터가 쓰는 base64url은 알파벳 중 두 글자를 바꾸고 관례적으로 패딩을 생략하므로, 표준 알파벳으로 디코딩되지 않는 조각은 대개 손상된 것이 아닙니다.

인코딩 결과가 항상 한 줄인 것은 아니고, 그 줄바꿈은 의미를 갖습니다. MIME은 base64를 76자에서 접고, 인증서와 개인키가 담겨 오는 형식인 PEM은 64자에서 접습니다. 둘 다 데이터 안에 실제 줄바꿈 문자가 들어갑니다. 한 줄을 전제로 작성된 디코더는 그것을 거부하므로, 인증서 파일에서 그대로 복사한 값은 보통 줄바꿈을 먼저 없애야 합니다. 반대 방향의 실수도 있습니다. 목적지가 기대하지 않는 곳에 줄바꿈을 넣는 인코더는 화면에서는 보이지 않는 이유로 검증에 실패하는 값을 만듭니다. 동작하는 문자열과 깨진 문자열의 차이가 아무것도 그리지 않는 문자이기 때문입니다.

퍼센트 인코딩과 HTML 엔티티 인코딩은 서로 다른 문제를 풀고, 자주 동시에 필요합니다. href 속성 안에 들어간 쿼리 문자열은 URL 파서와 HTML 파서를 둘 다 통과해야 하므로, 앰퍼샌드는 값의 일부일 때 %26 이 되고 두 파라미터를 구분할 때는 & 가 됩니다. 잘못된 계층에 맞춰 인코딩하면 그 지점 뒤가 조용히 잘려 나갑니다. 공백은 또 하나의 흔한 함정입니다. %20 은 언제나 옳지만 더하기 기호가 공백을 뜻하는 것은 application/x-www-form-urlencoded 안에서뿐입니다. 경로에서 더하기는 글자 그대로의 더하기이고, 더하기가 들어간 파일 이름이 브라우저와 서버 사이에서 사라지는 경로가 바로 이것입니다.

사람들이 가장 먼저 떠올리는 자바스크립트 함수는 한국어를 아예 인코딩하지 못합니다. btoa 는 Latin-1을 다루므로 U+00FF를 넘는 문자가 하나라도 있으면 예외를 던집니다. 한글이든 이모지든 둥근 따옴표든 마찬가지이고, 틀린 답이 아니라 오류가 납니다. 오래된 답변에 자주 나오는 우회법, 즉 문자열을 먼저 escape 하는 방법은 여러 바이트로 된 문자를 망가뜨리는데 그 사실이 한참 뒤에야 드러납니다. 올바른 경로는 텍스트를 UTF-8 바이트로 인코딩한 뒤 그것을 base64로 바꾸는 것이고, 이 페이지가 하는 일이 그것입니다. 비 ASCII 텍스트가 이 페이지를 왕복해도 넣은 그대로 돌아오는 이유입니다.