Base64 용어집

A~C

Alphabet (알파벳)

인코딩이 쓰는 문자 집합을 인덱스 순서로 나열한 것입니다. 표준 Base64는 A-Z, a-z, 0-9, +, /를 사용하므로 A는 0, /는 63을 뜻합니다. 알파벳 표를 참고하세요.

ASN.1

Abstract Syntax Notation One. 데이터 구조를 기술하는 언어로, X.509 인증서, 키, 여러 통신 프로토콜에서 쓰입니다. ASN.1은 구조를 정의하고, DER 같은 인코딩 규칙이 바이트를 정의합니다.

Base16

RFC 4648에서 hex를 부르는 이름입니다. 각 바이트가 0-9 A-F 중 두 문자가 되며 크기는 두 배가 됩니다. Base16 도구에서 해 보세요.

Base32

32개 문자(RFC 4648에서는 A-Z와 2-7)를 쓰는 인코딩으로, 5바이트를 8문자로 바꾸며 입력보다 60% 커집니다. 대소문자를 구분하지 않는 알파벳이라 TOTP 시크릿과 DNS 이름에 잘 맞습니다. Base32 인코더에서 해 보세요.

Base45

RFC 9285에서 정의했으며, 2바이트를 QR 코드의 영숫자 모드가 저장하는 45개 문자 집합의 3문자로 바꿉니다. EU 디지털 코로나19 증명서(EU Digital COVID Certificate)가 이 방식을 썼습니다. Base45 인코더에서 해 보세요.

Base58

비트코인의 58개 문자 알파벳으로, Base64에서 0, O, I, l, +, /를 뺀 것입니다. 입력 전체를 하나의 큰 수로 보고 변환하며, 앞쪽의 0 바이트는 하나당 1이 됩니다. Base58 인코더에서 해 보세요.

Base58Check

앞에 버전 바이트를, 끝에 4바이트 체크섬을 붙인 Base58입니다. 체크섬은 SHA-256을 두 번 적용한 결과의 처음 4바이트입니다. 레거시 비트코인 주소와 WIF 개인 키가 이 방식을 씁니다. Base58Check 도구를 참고하세요.

Base64

3바이트마다 64개 문자 알파벳의 4문자로 기록하고 끝을 =로 채우는 바이너리-텍스트 인코딩입니다. 출력은 입력보다 약 33% 큽니다. 인코더와 디코더로 시작하거나 Base64의 작동 원리를 읽어 보세요.

Base64URL

RFC 4648 5절에 정의된, +와 / 대신 -와 _를 쓰는 Base64입니다. 패딩은 생략하는 경우가 많습니다. JWT와 URL에서 쓰입니다. Base64와 Base64URL 비교와 Base64URL 인코더를 참고하세요.

Base85

4바이트를 5문자로 기록하는 인코딩 계열로, 오버헤드는 25%입니다. 흔한 변형으로는 Ascii85(Adobe, PDF와 PostScript에서 사용), Z85(ZeroMQ), git이 쓰는 RFC 1924 알파벳이 있습니다. Base85 도구에서 해 보세요.

Base91

Joachim Henke가 만든 basE91은 출력 가능한 ASCII 문자 91개를 쓰며, 문자 두 개마다 13비트 또는 14비트를 담습니다. 그래서 오버헤드가 약 14%에서 23% 사이로 여기서 가장 낮지만, 그 대가로 알파벳에 큰따옴표와 다른 구두점이 많이 들어갑니다. Base91 도구에서 해 보세요.

Basic Auth (Basic 인증)

HTTP Basic 인증(RFC 7617)은 user:password를 Base64로 바꿔 Authorization 헤더에 담아 보냅니다. Aladdin:open sesame은 Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==가 됩니다. 헤더를 본 사람은 누구나 이를 디코딩할 수 있으므로 HTTPS가 필요합니다. Basic Auth 생성기와 디코더로 만들거나 읽을 수 있습니다.

Binary-to-text encoding (바이너리-텍스트 인코딩)

임의의 바이트를 출력 가능한 문자만으로 표현하는 방식을 통틀어 이르는 말로, 이메일, JSON, URL처럼 텍스트용으로 만든 시스템에서도 데이터가 온전히 전달되게 합니다. Hex, Base32, Base64, Base85, uuencode, quoted-printable이 모두 바이너리-텍스트 인코딩입니다. Base64와 hex, Base32, Base58, Base85 비교에서 비교해 보세요.

BOM

바이트 순서 표시(byte order mark)로, 텍스트 파일 맨 앞에 놓이는 문자 U+FEFF입니다. UTF-8에서는 EF BB BF(Base64 77u/), UTF-16LE에서는 FF FE입니다. BOM을 예상하지 않는 디코더는 이를 나 엉뚱한 보이지 않는 문자로 표시합니다.

Canonical encoding (정규 인코딩)

어떤 데이터의 유일한 “올바른” 인코딩 형태입니다. Base64에서는 패딩 앞의 사용되지 않는 비트가 0이어야 합니다(RFC 4648 3.5절). SGk/Pg==는 정규 인코딩이고, SGk/Ph==는 관대한 디코더에서 같은 바이트로 디코딩되지만 정규 인코딩이 아닙니다.

Charset (문자 인코딩)

UTF-8, UTF-16LE, Windows-1252, EUC-KR처럼 텍스트를 바이트에 대응시키는 문자 인코딩입니다. Base64는 바이트를 저장하므로, Base64를 텍스트로 디코딩하려면 텍스트가 저장될 때 쓰인 문자 인코딩을 알아야 합니다. 잘못 짐작하면 Café처럼 글자가 깨집니다. Base64 텍스트 변환 도구에서 문자 인코딩을 바꿔 볼 수 있습니다.

CRLF

캐리지 리턴과 라인 피드, 즉 바이트 0D 0A입니다. MIME은 Base64 줄 사이에 CRLF를 요구하지만 Unix 도구는 보통 LF(0A)만 씁니다. 관대한 디코더는 둘 다 무시하고, 엄격한 디코더는 둘 다 거부합니다.

CSP nonce

Content-Security-Policy 헤더(script-src 'nonce-…')에 들어가는 무작위 값으로, 같은 nonce 속성을 가진 인라인 스크립트만 허용합니다. Base64로 쓰며, 응답마다 새로 만들어야 하고 최소 128비트의 무작위성을 담아야 합니다. CSP nonce 생성기로 만들 수 있습니다.

D~J

Data URI

데이터를 가리키는 대신 데이터 자체를 담는 URL로, RFC 2397에서 정의했습니다. 예: data:image/png;base64,iVBORw0KGgo…. HTML과 CSS에 넣는 작은 이미지와 아이콘에 유용합니다. Data URI 생성기, 파서, Data URI 성능을 참고하세요.

Deflate

ZIP, gzip, zlib, PNG 안에 들어 있는 압축 알고리즘(RFC 1951)입니다. “raw deflate"는 헤더나 체크섬으로 감싸지 않은 압축 스트림을 뜻합니다. zlib·deflate 도구로 압축하고 인코딩할 수 있습니다.

DER

Distinguished Encoding Rules. ITU-T X.690에서 정의한, ASN.1 구조의 엄격한 바이너리 인코딩입니다. 인증서와 키는 DER 바이트입니다. DER 구조는 보통 30(SEQUENCE)으로 시작하므로 PEM 본문은 M, 흔히 MII로 시작합니다.

gzip

deflate로 압축한 데이터를 10바이트 헤더와 CRC-32 체크섬으로 감싸는 파일 형식(RFC 1952)입니다. 바이트 1F 8B로 시작하므로 gzip을 Base64로 바꾸면 H4sI로 시작합니다. 압축하려면 gzip과 Base64를, 되돌리려면 gzip Base64 디코딩을 사용하세요.

Hex (16진수)

각 바이트를 0-9와 a-f 중 두 자리로 쓰는 16진수 표기입니다. 예를 들어 Hello는 48 65 6c 6c 6f입니다. 바이트 단위로 읽기 쉽고, 크기는 입력의 두 배입니다. Base64를 hex로 변환과 hex를 Base64로 변환에서 바꿀 수 있습니다.

JWE

JSON Web Encryption(RFC 7516). 암호화된 토큰으로, compact 형식은 헤더, 암호화된 키, 초기화 벡터, 암호문, 인증 태그의 다섯 Base64URL 부분으로 이루어집니다. JWS와 달리 키 없이는 내용을 읽을 수 없습니다.

JWS

JSON Web Signature(RFC 7515). 헤더, 페이로드, 서명의 세 Base64URL 부분으로 이루어진 서명된 메시지입니다. 페이로드는 누구나 읽을 수 있습니다. 서명은 내용이 바뀌지 않았다는 것만 증명합니다.

JWT

JSON Web Token(RFC 7519). JWS나 JWE 안에 담긴 JSON 형식의 클레임 집합입니다. 흔히 보는 JWT는 대부분 eyJ로 시작하는 JWS 토큰입니다. JWT 디코더로 디코딩하고 JWT 인코더로 만들 수 있으며, JWT 속의 Base64도 읽어 보세요.

L~Q

Line wrapping (줄 바꿈)

긴 Base64 출력에 줄 바꿈을 넣는 것입니다. MIME은 76자 이하에서, PEM은 정확히 64자에서 줄을 바꿉니다. GNU base64는 기본적으로 76자에서 줄을 바꾸고(-w 0으로 끔), openssl base64는 64자에서 바꿉니다(-A로 끔). MIME 인코더가 줄 바꿈을 대신 처리해 줍니다.

Magic number (매직 넘버)

파일 맨 앞에서 형식을 식별하는 고정된 바이트 시퀀스입니다. PDF의 %PDF-, PNG의 89 50 4E 47이 그 예입니다. Base64는 3바이트씩 인코딩하므로 매직 넘버는 알아보기 쉬운 Base64 접두사가 됩니다. 흔한 Base64 접두사와 Base64 파일 변환을 참고하세요.

MIME

Multipurpose Internet Mail Extensions(RFC 2045~2049). 이메일에 첨부 파일과 비 ASCII 텍스트를 담을 수 있게 해 주는 표준입니다. base64 Content-Transfer-Encoding은 첨부 파일이 텍스트 전용 메시지 안에 담겨 전달되는 방식입니다. 이메일 속의 Base64와 EML 디코더를 참고하세요.

Padding (패딩)

Base64 끝에서 마지막 4문자 그룹을 채우는 = 문자입니다. 1바이트가 남으면 ==, 2바이트가 남으면 =가 붙습니다. 일부 형식은 패딩을 생략합니다. 패딩 가이드를 읽어 보세요.

PEM

Privacy-Enhanced Mail. 원래는 보안 이메일 표준(RFC 1421)이었습니다. 오늘날 이 이름은 키와 인증서를 위한 그 텍스트 형식을 가리킵니다. DER 바이트의 Base64를 -----BEGIN CERTIFICATE----- 줄과 -----END CERTIFICATE----- 줄 사이에 넣고 64자마다 줄을 바꾼 것입니다(RFC 7468). 인증서 디코더로 살펴볼 수 있습니다.

Quoted-printable

또 하나의 MIME 전송 인코딩입니다. 출력 가능한 ASCII는 그대로 두고 다른 바이트는 =와 16진수 두 자리로 씁니다. 그래서 UTF-8의 Café는 Caf=C3=A9가 됩니다. 대부분 ASCII인 텍스트에는 효율적이지만 바이너리에는 낭비가 큽니다. quoted-printable 도구에서 해 보세요.

R~Z

Radix-64

OpenPGP의 ASCII 아머를 부르는 이름입니다. 표준 Base64에 =로 시작하고 CRC-24를 Base64로 담은 선택적 체크섬 줄을 더한 것입니다. Base64 표준을 참고하세요.

SRI

Subresource Integrity. 다운로드한 스크립트나 스타일시트를 integrity 속성의 해시와 대조하는 브라우저 기능입니다. 해시는 알고리즘 이름과 Base64 다이제스트로 씁니다. 예: sha384-…. 지원하는 알고리즘은 SHA-256, SHA-384, SHA-512입니다. SRI 해시 생성기로 값을 만들 수 있습니다.

uuencode

Unix-to-Unix encoding. MIME보다 오래된 바이너리-텍스트 형식입니다. 각 줄은 길이를 나타내는 문자로 시작하고, 데이터 문자는 ASCII 32~95에서 가져오므로 MIME의 Base64가 피하는 구두점도 들어갑니다. uuencode 도구를 참고하세요.

UTF-8

웹에서 압도적으로 많이 쓰이는 텍스트 인코딩입니다. ASCII 문자는 1바이트, 다른 문자는 2~4바이트를 차지합니다. 도구가 “텍스트를 Base64로"라고 하면 거의 언제나 UTF-8 바이트를 Base64로 바꾼다는 뜻입니다. é는 C3 A9입니다. UTF-8 Base64 변환을 참고하세요.

UTF-16LE

하위 바이트를 먼저 쓰는 UTF-16으로, Windows와 .NET의 내부 문자열 형식입니다. UTF-16LE로 된 ASCII 텍스트는 문자마다 뒤에 0 바이트가 붙으므로 Hello는 A가 가득한 SABlAGwAbABvAA==가 됩니다. PowerShell의 -EncodedCommand가 이 형식을 요구합니다. UTF-16 Base64 변환과 PowerShell 디코더를 참고하세요.

Z85

ZeroMQ의 Base85 변형(ZeroMQ RFC 32)입니다. 4바이트를 5문자로 인코딩하고, 따옴표와 백슬래시를 피하므로 출력을 소스 코드 문자열에 그대로 넣을 수 있습니다. 입력은 4바이트의 배수여야 합니다. Z85 도구에서 해 보세요.

zlib

deflate 데이터를 2바이트 헤더와 Adler-32 체크섬으로 얇게 감싼 형식(RFC 1950)입니다. 헤더는 보통 78로 시작하므로 zlib 데이터를 Base64로 바꾸면 압축 수준에 따라 eJ, eN, eF, eA로 시작합니다. zlib 도구를 사용하세요.

자주 묻는 질문