표준 Base64
A-Z, a-z, 0-9, +, / 64개 문자와 패딩용 =로 구성됩니다. 가장 널리 쓰이는 형태로, 이메일 첨부(MIME)나 일반적인 데이터 인코딩에 사용됩니다. -와 _가 보이면 URL 세이프 변형, 공백이나 줄바꿈이 섞여 있으면 MIME 형식의 개행이라고 판단할 수 있습니다. 문자만 봐도 형식을 추측하는 눈이 생깁니다.
CubTools Base64 도구가 출력하는 것도 이 표준 형식입니다. 길이는 항상 4의 배수가 됩니다. JWT처럼 패딩을 생략하는 규격도 있습니다. 토큰을 디코딩할 때는 패딩을 직접 채워주는 습관이 필요합니다. 확장자와 실제 형식은 다를 수 있습니다. 이름만 jpg로 바꾼 png 파일이 있습니다. 확장자는 껍데기일 뿐입니다. 도구가 안 읽으면 실제 형식을 의심하세요. 제대로 변환하면 해결됩니다. 껍데기에 속지 마세요.
표준 Base64의 문자 집합을 외울 필요는 없지만, 구성을 알면 오류 파악이 쉽습니다. 대문자 26자, 소문자 26자, 숫자 10자, 그리고 +와 /로 64자를 채웁니다. 이 외의 문자가 보이면 그건 Base64가 아니거나 변형된 것입니다.
URL 세이프 Base64
URL이나 파일명에 넣기 위해 +를 -, /를 _로 바꾼 변형입니다. JWT 토큰에서 볼 수 있는 형태가 대표적입니다. 표준 Base64를 URL에 그대로 넣으면 +와 /가 문제를 일으키므로, 이런 용도에서는 URL 세이프 형태로 변환해야 합니다.
패딩 =의 개수는 원본 길이에 따라 0~2개입니다. =이 3개 이상 붙어 있다면 뭔가 잘못된 것입니다. 일부 시스템은 패딩을 생략하기도 하는데, 그럴 때는 길이를 4의 배수로 맞춰주는 처리가 필요합니다. 변환 손실을 이해하세요. 손실 형식끼리 오가면 품질이 떨어집니다. 원본에서 최종 형식으로 한 번에 가는 게 정답입니다. 중간 단계를 줄이세요. 손실은 누적됩니다. 한 번의 선택이 품질을 정합니다.
data:[MIME 타입];base64,[데이터] 형태의 문자열로, 파일 내용을 URL 자리에 직접 넣을 수 있게 합니다. 작은 이미지를 HTML에 삽입할 때 쓰입니다. 일반적인 변환·전달에는 표준 Base64를 쓰세요. URL·토큰처럼 웹 주소에 들어간다면 URL 세이프를, HTML 삽입이라면 data URI 형태를 선택하면 됩니다.
data URI
파일을 인코딩한 뒤 앞에 data:image/png;base64, 같은 접두사를 붙이면 브라우저에서 바로 표시되는 URI가 됩니다. charset 지정도 신경 쓸 부분입니다. 텍스트를 data URI로 넣을 때는 charset=utf-8을 명시하면 한글 깨짐을 방지할 수 있습니다.
data URI의 MIME 타입은 실제 파일과 일치해야 합니다. PNG 파일을 인코딩해 놓고 image/jpeg라고 적으면 브라우저가 해석을 거부할 수 있습니다. 파일 확장자가 아니라 실제 내용 기준으로 MIME을 정하세요.
Base64URL을 표준으로 되돌릴 때는 -를 +, _를 /로 바꾸고, 길이가 4의 배수가 되도록 =을 채웁니다. 이 변환을 손으로 하면 실수하기 쉬우니, 자주 다룬다면 작은 스크립트로 만들어 두는 것이 좋습니다.
형식 선택 기준
인코딩을 알아두세요. 글자가 깨지는 이유의 대부분은 인코딩입니다. UTF-8이 표준입니다. 구형 문서에서는 다른 인코딩이 쓰였습니다. 깨지면 인코딩을 의심하세요. 변환하면 해결됩니다. 인코딩이 글자의 언어입니다. 확장자는 껍데기일 뿐입니다. 제대로 변환하면 해결됩니다. 껍데기에 속지 마세요.
호환성 표를 만들어보세요. 어떤 형식이 어디서 열리는지 적은 표입니다. 표가 있으면 선택이 빠릅니다. 팀과 공유하면 모두가 같은 기준으로 고릅니다. 표는 한 번 만들면 오래 씁니다. 호환성이 곧 선택 기준입니다.
표준을 따르세요. 널리 쓰이는 형식이 가장 안전합니다. 특이한 형식은 나중에 골칫거리가 됩니다. 표준은 호환성을 보장합니다. 유행보다 표준을 믿으세요. 표준이 오래 갑니다. 미래를 대비하세요. 새 형식이 표준이 되는 흐름을 주시하세요. 미리 익혀두면 전환이 쉽습니다. 다만 성급한 전환은 금물입니다. 주류가 된 뒤에 옮기세요. 흐름을 읽는 눈이 필요합니다.
자주 묻는 질문
JWT 토큰의 인코딩은 표준과 다른가요?
네. JWT는 Base64URL(URL 세이프) 변형을 쓰고 패딩 =을 생략하는 경우가 많습니다. 표준 디코더에 넣으면 오류가 날 수 있습니다.
data URI는 언제 쓰나요?
수 KB 이하의 작은 이미지를 HTML·CSS에 직접 넣을 때 씁니다. HTTP 요청을 줄일 수 있지만 큰 파일에는 부적합합니다.
패딩 =은 꼭 필요한가요?
표준 디코딩에서는 길이를 맞추는 역할을 합니다. 일부 변형에서는 생략하지만, 표준 형식에서는 유지하는 것이 안전합니다.