Base64는 임의의 바이너리 데이터를 문자, 숫자, +, /, = 기호로만 구성된 텍스트로 표현하는 방식입니다. 데이터를 압축하거나 암호화하지 않으며, 결과물은 원본보다 약 3분의 1 더 커지고, 알고리즘을 아는 사람이라면 누구나 원본 내용을 읽을 수 있습니다.
인코딩 작동 방식
입력 바이트는 3바이트(24비트)씩 그룹으로 묶여 6비트씩 4개 블록으로 나뉩니다. 각 블록은 Base64 알파벳(A–Z, a–z, 0–9, +, /)의 한 문자에 대응합니다. 입력 데이터 길이가 3바이트의 배수가 아니면 끝에 패딩 문자 =가 추가됩니다.
왜 필요한가
이메일(MIME), URL, JSON, XML 같은 많은 프로토콜과 형식은 텍스트를 전제로 설계되어 있어 널 바이트, 제어 문자, 형식 자체의 문법과 충돌하는 시퀀스 같은 "날것의" 바이트를 안정적으로 처리하지 못합니다. Base64는 어떤 바이너리 데이터든 안전한 텍스트로 바꿔 이 문제를 우회합니다.
일반적인 사용 사례
- MIME을 통한 이메일 첨부 파일.
- JSON API에서 이미지나 작은 파일을 전송.
- 데이터베이스나 설정 파일의 텍스트 필드에 바이너리 데이터 저장.
- JWT의 header와 payload 부분 인코딩.
Base64가 아닌 것
암호화도 해싱도 아닙니다. 누구나 키나 비밀번호 없이 Base64 문자열을 원래 데이터로 디코딩할 수 있습니다 — 이는 단지 표현 형식일 뿐, 보안 수단이 아닙니다.
표준 알파벳과 URL-safe 알파벳
기존 Base64 알파벳은 +와 / 문자를 사용하는데, 이 문자들은 URL과 파일 이름에서 특별한 의미를 가집니다. 이런 경우를 위해 Base64URL이라는 변형이 있는데, +는 -로, /는 _로 대체됩니다. 표준 인코딩 결과를 추가 percent-encoding 없이 URL에 그대로 넣으면 +와 /가 주소를 깨뜨리거나 경로 구분자와 충돌할 수 있습니다.
흔한 실수: 잘리거나 "손상된" 패딩
문자열 끝의 = 기호는 불필요한 것이 아니라 마지막 블록에 몇 바이트가 부족한지 나타내는 인코딩의 일부입니다. Base64 문자열을 끝까지 복사하지 않거나 패딩을 수동으로 제거하면 디코더가 오류를 반환하거나 결과가 잘려버립니다. 일부 시스템(예: JWT)은 의도적으로 =를 생략하는데, 이 경우 디코딩 전에 길이를 복원해야 합니다.