code Base64 인코딩 / 디코딩 star

작동 방식

Base64는 64개의 출력 가능한 문자로 이루어진 알파벳을 사용해 이진 데이터를 일반 텍스트로 바꿉니다: A–Z, a–z, 0–9, 그리고 +와 /입니다(64개의 기호는 정확히 2⁶이며, 이것이 Base64라는 이름의 유래입니다). 인코더는 입력을 한 번에 3바이트(24비트)씩 읽어 이 24비트를 6비트씩 네 조각으로 나누고, 각 6비트 조각을 알파벳의 한 문자에 대응시킵니다 — 그래서 이진 데이터 3바이트는 항상 정확히 텍스트 4문자가 됩니다. 입력 길이가 3의 배수가 아니면, 출력 길이를 4의 배수로 유지하기 위해 마지막 그룹에 = 문자 하나 또는 두 개가 채워집니다.

구체적으로 살펴보면: "Man"을 이루는 세 바이트(77, 97, 110 — 이진수로 01001101 01100001 01101110)는 6비트씩 네 조각(010011, 010110, 000101, 101110)으로 재구성되고, 각 조각은 하나의 문자에 대응되어 TWFu가 만들어집니다. 입력 3바이트가 항상 출력 4문자로 확장되므로, Base64로 인코딩된 데이터는 원본보다 항상 약 33% 커집니다 — 300 KB 이미지는 대략 400 KB의 Base64 문자열이 되며, 이는 이미지를 data: URI로 삽입하거나 JSON이나 이메일 안에 이진 파일을 첨부할 때 중요하게 작용합니다.

이 도구는 먼저 텍스트를 UTF-8로 올바르게 인코딩하여 유니코드를 정확히 처리하므로, 다중 바이트 문자와 이모지("çğü 😀")도 손상 없이 왕복합니다 — 단순한 자바스크립트 btoa() 호출은 문자당 1바이트를 가정하기 때문에 이런 경우 오류를 일으킵니다. 모든 처리는 브라우저에서 로컬로 실행되며, 입력한 어떤 내용도 어디로도 전송되지 않습니다.

Base64는 대부분의 사람들이 눈치채지 못하는 곳에서 끊임없이 등장합니다: HTML의 <img src="data:image/png;base64,..."> 태그는 파일을 링크하는 대신 이미지 전체를 페이지 안에 직접 삽입하고, Authorization: Basic HTTP 헤더는 Base64로 인코딩된 "사용자이름:비밀번호" 문자열을 담습니다(이는 형식일 뿐 보호 수단이 아니며, 전송 중 실제 기밀성을 지키는 것은 TLS입니다); 이메일 첨부 파일은 원래의 MIME 표준 이후로 줄곧 Base64로 인코딩되어 왔는데, SMTP가 원시 이진 데이터가 아니라 7비트 텍스트를 전송하도록 설계되었기 때문입니다; 그리고 JSON 웹 토큰(JWT)은 URL 안전 변형을 사용해 서명된 이진 구조를 점으로 구분된 세 개의 텍스트 조각에 담습니다.

알아두어야 할 사항

• Base64는 암호화가 아닙니다 — 기밀성이 전혀 없는, 공개적으로 알려진 가역적 표현 방식입니다. 누구나 동일한 알파벳으로 즉시 디코딩할 수 있으며, 이는 순전히 이진 데이터를 텍스트 전용 채널(이메일 MIME 첨부, data URI, JSON 필드, HTTP 기본 인증 헤더)로 안전하게 전달하기 위해 존재할 뿐, 내용을 숨기기 위한 것이 아닙니다.
• URL 안전 변형: +와 /는 URL에서 특별한 의미를 가지므로, "URL 안전" Base64 알파벳은 이를 -와 _로 바꾸고 흔히 = 패딩을 생략합니다. 이 도구는 두 변형을 모두 자동으로 디코딩합니다.
• 크기 비용은 고정적이고 예측 가능합니다: 약 33%의 증가(4/3 비율)는 페이로드 자체에 대해 정확한 값입니다 — 원시 이진 업로드를 받는 API가 Base64로 감싼 JSON 본문을 요구하는 API보다 대개 대역폭 효율이 더 좋은 이유이기도 합니다.
• 패딩은 나머지를 알려줍니다: = 하나는 원본 데이터 길이가 3의 배수보다 2바이트 많다는 뜻이고, = 두 개는 1바이트 많다는 뜻입니다. 패딩이 전혀 없으면 입력이 정확히 3의 배수 바이트였다는 뜻입니다.