Base64

01무엇이고, 어떤 일을 하나

• 바이너리 자료를 텍스트 중심 형식에 넣을 수 있게 한다.
• 메일 MIME·설정·웹 토큰 등의 자료 표현을 지원한다.
• 전송 환경에 맞는 일반 Base64와 Base64url 변형을 구분한다.

02어떤 순서로 동작하나

1. 바이트 준비

   인코딩할 실제 바이트열을 정한다. 텍스트라면 먼저 UTF-8 등 문자 인코딩을 적용한다.

2. 6비트 분할

   세 바이트의 24비트를 여섯 비트씩 네 묶음으로 나눈다.

3. 문자 매핑

   각 값을 64문자 알파벳에 대응시키고 남은 바이트 수에 맞게 규격의 패딩을 처리한다.

4. 역변환 검증

   받은 쪽이 올바른 변형과 패딩 규칙으로 바이트를 복원하고 필요한 경우 그 바이트를 다시 텍스트로 해독한다.

03먼저 알아둘 용어와 구성요소

3바이트·4문자

Base64의 입력은 임의의 바이트열이다. 입력이 글자라면 먼저 UTF-8 등으로 인코딩한다. 연속된 3바이트 = 24비트를 왼쪽부터 6비트씩 네 묶음으로 나누고, 각 묶음의 0~63 값을 정해진 문자표에 대응시킨다. 키나 비밀 규칙을 쓰지 않으므로 누구나 역변환할 수 있다.

6비트 인덱스

BYE의 ASCII/UTF-8 바이트는 42 59 45이다. 이진수 01000010 01011001 01000101을 다시 나누면 010000 / 100101 / 100101 / 000101이다. 십진수로 16 / 37 / 37 / 5이며, Base64 문자표에서 Q / l / l / F가 된다. 올바른 결과는 QllF이다. 소문자 l을 대문자 L로 옮긴 QLLF는 다른 바이트로 해독된다.

= 패딩

입력이 3의 배수 바이트이면 네 글자 묶음을 완전히 채운다. 마지막에 1바이트만 남으면 유효한 8비트를 6+2비트로 나누고 마지막 2비트 뒤에 0을 네 개 채워 두 문자를 만든 뒤 ==를 붙인다. 2바이트가 남으면 6+6+4비트에서 마지막에 0 두 개를 채워 세 문자를 만들고 = 하나를 붙인다. =는 데이터 비트의 암호화 결과나 공백 문자가 아니라, 마지막 묶음의 길이를 표현하는 표식이다.

출력 길이·변형

일반적인 패딩 포함 Base64의 길이는 4×ceil(입력 바이트 수/3)이다. 큰 데이터에서는 대략 4/3배이며 압축 방식이 아니다. URL용 Base64url은 +와 / 자리에 -와 _를 쓰며, 패딩 생략 여부는 사용하는 상위 형식의 규칙을 따라야 한다. “어떤 Base64인지”까지 정해야 상호 운용된다.

인코딩과 신뢰

해독에 성공했다는 사실만으로 내용이 안전하거나 신뢰할 수 있다는 뜻은 아니다. HTTP Basic 인증의 자격 증명도 Base64일 뿐이며 기밀성은 TLS 같은 별도 보호에 의존한다. 로그에서 Base64처럼 보이는 문자열을 찾았다고 곧바로 악성 행위라고 판단하지 않고, 정상 토큰·메일 첨부·인증 데이터인지 사용 맥락과 함께 읽는다.

디코딩 횟수

Base64를 중첩 적용한 자료는 한 번 해독한 결과가 다시 인코딩된 문자열일 수 있다. 프로토콜이 요구하는 변환 층을 기준으로 해독하며 임의로 반복 해독하지 않는다.

04예제로 따라가기

• ASCII BYE의 바이트를 Base64로 바꾸면 QllF가 되며 세 바이트가 네 문자로 늘어난다.
• 패딩을 포함하는 기본 Base64에서 N바이트의 길이는 4×ceil(N/3) 문자이므로 1바이트와 2바이트 입력도 네 문자 단위가 된다.
• 메일 첨부를 Base64로 표현하면 원본보다 크기가 늘어 SMTP 제한에 영향을 주므로 원본 파일 크기와 전송 크기를 같은 값으로 보지 않는다.

05혼동하기 쉬운 점과 확인 기준

• Base64 문자열을 읽기 어렵다는 이유로 암호나 토큰을 공개해도 된다고 판단하지 않는다. 인코딩을 풀면 원본 바이트가 그대로 복원된다.
• Base64url은 URL 등에 맞춘 다른 알파벳을 사용하며 패딩 허용 여부는 사용하는 형식 규약을 따라야 한다. 일반 Base64 처리와 무조건 교환하지 않는다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.