파일 Base64 변환기

파일을 Base64로 인코딩하는 이유

시스템 사이에서 데이터를 주고받는 형식 중에는 텍스트만 담을 수 있는 것이 많습니다. JSON, XML, YAML, HTML, 이메일 헤더는 임의의 바이트를 담을 수 없습니다. 파일에는 값이 0인 바이트, 잘못된 문자 시퀀스, 텍스트 파서가 바꿔 버릴 수 있는 줄 끝 문자가 들어 있을 수 있기 때문입니다. Base64는 파일의 3바이트를 영문자, 숫자, +, /로 이루어진 64개 문자 중 4개로 바꿉니다. 그래서 어떤 파일이든 일반 문자열로 전달한 뒤 정확히 같은 바이트로 다시 디코딩할 수 있습니다.

대신 크기가 늘어납니다. 인코딩된 텍스트는 원본 파일보다 약 33% 크고, 줄 바꿈을 넣으면 조금 더 커집니다. 3MB 파일은 약 4MB의 Base64가 됩니다.

주요 활용 사례

• JSON 및 XML API: multipart 폼 업로드를 받지 않는 엔드포인트는 흔히 파일을 한 필드에 Base64 문자열로 받고, 파일 이름과 유형은 다른 필드로 받습니다.
• 이메일 첨부 파일: MIME은 첨부 파일을 한 줄에 최대 76자인 Base64로 인코딩합니다(RFC 2045). ‘76자마다 줄 바꿈’을 켜면 같은 형태가 만들어집니다.
• 설정과 시크릿: Kubernetes Secret의 data 아래 값은 Base64이므로 TLS 인증서, 키스토어, 라이선스 파일은 매니페스트에 넣기 전에 인코딩해야 합니다. CI 시스템도 바이너리 시크릿을 같은 방식으로 환경 변수에 저장하는 경우가 많습니다.
• 데이터베이스와 소스 코드: 글꼴, 효과음, 테스트 픽스처처럼 작은 바이너리는 별도 파일 대신 텍스트 열이나 문자열 상수에 저장할 수 있습니다.

사진이라면 크기 조절 기능과 바로 쓸 수 있는 HTML 및 CSS 코드 조각을 제공하는 이미지 Base64 변환 도구가 더 편리합니다. Base64를 다시 파일로 되돌리려면 Base64 파일 변환 도구를 사용하십시오.

순수 Base64와 data URI 중 무엇을 쓸까

순수 Base64에는 인코딩된 바이트만 들어 있습니다. API, Kubernetes, 데이터베이스, 대부분의 프로그래밍 라이브러리가 기대하는 형식이며, 보통 파일 이름이나 콘텐츠 유형을 담는 별도 필드와 함께 사용합니다.

data URI는 data:application/pdf;base64,처럼 MIME 유형을 담은 접두사를 덧붙입니다. 그래서 브라우저는 문자열 전체를 src, href, CSS url()의 URL로 사용할 수 있습니다. 순수 Base64를 요구하는 API에는 이 접두사를 보내지 마십시오. 접두사가 붙은 값을 거부하는 디코더가 많습니다. MIME 유형을 직접 지정하거나 퍼센트 인코딩을 사용하려면 Data URI 생성기를 이용해 보십시오.

JSON, YAML, 소스 코드에 쓸 때는 ‘76자마다 줄 바꿈’을 끄십시오. JSON 문자열에는 실제 줄 바꿈 문자를 넣을 수 없고, YAML에서는 여러 줄로 나뉜 값이 쉽게 깨집니다.

명령줄에서 파일 인코딩하기

# Linux(GNU coreutils): -w 0으로 기본 76자 줄 바꿈을 끕니다
base64 -w 0 report.docx > report.txt

# macOS
base64 -i report.docx -o report.txt

# Windows PowerShell
[Convert]::ToBase64String([IO.File]::ReadAllBytes("C:\files\report.docx"))

# Kubernetes가 파일을 대신 인코딩합니다
kubectl create secret generic app-cert --from-file=tls.crt