Base64 설명: 어떻게 작동하는지, 언제 사용해야 하는지, 언제 사용하지 말아야 하는지

Base64는 이메일 첨부 파일, JSON 웹 토큰, 데이터 URL, 쿠버네티스 비밀, HTTP 기본 인증 및 텍스트 채널을 통해 바이너리 데이터를 이동해야 하는 수많은 API에서 나타납니다. 어떻게 작동하는지 보면 간단하지만, 종종 악용되기도 합니다. 특히 암호화처럼 말이죠. 이 문서에서는 알고리즘 단계별로 설명하고, 일반적인 변종과, Base64가 올바른 도구가 될 때 실용적인 지침을 제공합니다.

Base64가 해결하는 문제

많은 시스템은 임의의 바이트가 아닌 텍스트를 전송하도록 설계되었습니다. 이메일 (SMTP) 는 역사적으로 7비트 ASCII만을 지원했습니다. JSON 문자열은 RAW 바이너리를 포함할 수 없습니다. URL 및 HTTP 헤더에는 제한된 문자 집합이 있습니다. 이 중 어느 하나에 이미지 원자 바이트를 넣으면, 일부 바이트는 제어 문자, 줄 끝 또는 경계로 해석되며, 데이터는 손상됩니다.

Base64는 임의의 바이트를 64개의 안전한 인쇄 가능한 문자로 매핑합니다. A–Z, a–z, 0–9, + 및 /. 일반 텍스트를 전송할 수 있는 모든 시스템은 데이터를 그대로 전송할 수 있습니다.

코딩 방식

베이스64는 3바이트 (24비트) 그룹으로 입력값을 처리하고 6비트의 4개의 문자를 출력한다. 2^6 = 64이기 때문에 6비트 값마다 알파벳에서 한 문자를 선택합니다.

Man이라는 단어를 들어보세요.

1. ASCII 바이트: M = 77, a = 97, n = 110.
2. 바이너리: 01001101 01100001 01101110.
3. 4개의 6비트 그룹으로 나뉘어 있습니다. 010011 010110 000101 101110.
4. 숫자로: 19, 22, 5, 46.
5. 알파벳을 보세요: T, W, F, u.

그래서 Man은 TWFu가 됩니다 해독은 과정을 뒤집어 놓습니다.

을 채우면

입력 길이가 3의 배수가 아니면 마지막 그룹은 불완전합니다. 베이스64가 붙여놨어

• 1개의 남은 바이트는 2개의 문자 더하기 ==을 생성합니다.
• 2개의 남은 바이트는 3개의 문자 더하기 =을 생성합니다.

Ma은 TWE=로, M는 TQ==로 코딩된다. 패딩은 출력 길이를 4의 배수로 만듭니다. 일부 디코더가 필요로 하는 것입니다. 다른, 특히 URL-안전 구현, 길이가 이미 얼마나 바이트가 빠졌는지 암시하기 때문에 그것을 생략합니다.

크기 부과

3 바이트마다 4개의 문자가 나오기 때문에 Base64 출력은 입력보다 약 33% 더 크며, 패딩과 때로는 라인 브레이크 (MIME 이메일은 76개의 문자로 라인을 감싸고 있다) 를 더한다. 1 MB의 이미지는 대략 1.37 MB의 텍스트가 됩니다. JSON 또는 HTML로 큰 파일을 임베디드할 때 그 오버헤드는 중요합니다.

URL-safe Base64

표준 알파벳에는 URL에서 특별한 의미를 갖는 +과 /와 쿼리 문자열에서 사용되는 =가 포함되어 있습니다. RFC 4648에서 정의된 Base64URL는 +를 -와 /를 _로 대체하며 일반적으로 패딩을 삭제합니다. JWT, 많은 API 토큰 및 웹 푸시 키는 이 변형을 사용합니다. 예를 들어 [JWT 작동 방식] (/blog/how-jwt-works) 를 참조하십시오.

표준 디코더는 -과 _에서 실패하고 반대로 "무효 문자" 오류의 일반적인 원천입니다. 용인된 [Base64 디코더] ((/tools/base64) 는 두 알파벳을 모두 받아들이고, 부족한 패딩을 자동으로 복원합니다.

텍스트, 바이트 및 유니코드

Base64는 바이트를 암호화합니다. 문자 아닌 거죠. 텍스트를 인코딩하려면 문자 인코딩으로 바이트로 변환해야 합니다. 거의 항상 UTF-8입니다. 여기서 브라우저가 사람들을 속이는 겁니다. 자바스크립트의 btoa()은 라틴-1 범위의 문자를만 받아들이고, 그래서 btoa("héllo")는 실수로 작동하고 btoa("你好")는 오류를 던집니다.

현대 자바스크립트의 올바른 접근법:

const bytes = new TextEncoder().encode("你好 👋");
const b64 = btoa(String.fromCharCode(...bytes));
const back = new TextDecoder().decode(Uint8Array.from(atob(b64), c => c.charCodeAt(0)));

다른 언어들은 이것을 명확하게 합니다. 파이썬의 base64.b64encode은 바이트를 사용합니다. 그래서 base64.b64encode("你好".encode("utf-8"))를 쓰죠.

데이터 URL

데이터 URL은 파일을 직접 HTML 또는 CSS로 삽입합니다.

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." alt="">

이것은 HTTP/1.1 시대에 귀중한 HTTP 요청을 저장합니다. 오늘날, HTTP/2 멀티플렉싱을 통해, 트레이드오프는 일반적으로 별도의 파일을 선호합니다:

• 데이터 URL은 독립적으로 캐시할 수 없습니다. 데이터를 포함하고 있는 모든 페이지나 스타일 시트와 함께 다시 다운로드 됩니다.
• 그들은 HTML과 CSS를 부풀려서 다운로드하고 분석할 때까지 렌더링을 차단합니다.
• 33%의 오버헤드가 적용되지만 gzip는 일부를 복구합니다.

작은 자산을 위한 데이터 URL를 사용하십시오. 1KB 이하의 작은 아이콘, 포지셔럴 이미지 또는 단일 파일 HTML 수출. 더 큰 파일의 경우 일반 파일을 서비스하고 [압축] ((/blog/compress-image-to-100kb) 대신

Base64는 암호화가 아닙니다.

이것이 가장 중요한 점입니다. Base64는 키가 없어요 누구나 즉시 암호를 해독할 수 있고 많은 도구들은 자동으로 해독합니다. 그러나 흔히 발견 되는 것 들 은

• API 키는 프론트엔드 코드에서 Base64에 숨겨져 있습니다.
• 암호는 데이터베이스나 구성파일에 Base64 코딩으로 저장됩니다.
• 쿠버네티스 비밀은 그들의 값이 베이스64이기 때문에 보호된다고 가정합니다.

쿠버네티스는 바이너리 데이터가 YAML에 맞도록 순수하게 Base64에서 비밀 값을 암호화합니다. 보호는 액세스 제어와 휴식 상태의 암호화에서 비롯되며 별도로 구성되어야합니다. 데이터가 기밀해야 한다면 AES-GCM와 같은 실제 알고리즘으로 암호화하고 암호를 확인해야 한다면 암호 해시 함수 (hash function) 를 사용해야 합니다.

일반적인 사용 사례가 제대로 수행되었습니다.

• HTTP 기본 인증은 Authorization: Basic base64(user:password)을 전송합니다. 암호화는 특수 문자와 관련된 문제를 피하는 데만 사용됩니다. 인증서는 HTTPS로만 보호됩니다.
• 메일 첨부 파일는 MIME Base64를 사용하며, 76자마다 줄절을 합니다.
• JSON**에 작은 서명 이미지나 암호 키 같은 바이너리 파일을 삽입하는 것은 합법적인 사용입니다. 큰 파일의 경우 별도로 업로드하고 URL로 참조하십시오.
• ** 텍스트 전용 구성의 바이너리 저장 **, 환경 변수에서 TLS 인증서와 같은.

디코딩 오류 문제 해결

• 무효 문자: 당신은 아마도 표준 디코더로 Base64URL를 디코딩하고 있거나 문자열에 빈 공간이나 라인 브레이크가 포함되어 있습니다.
• 부정한 포딩: 길이가 4의 배가 될 때까지 =을 더합니다.
• ** 디코딩 후 텍스트가 왜곡되었습니다:** 원본은 다른 문자 집합에서 암호화되었거나 데이터가 텍스트가 아닌 바이너리입니다.
• ** 출력은 다시 Base64처럼 보입니다:** 데이터는 두 번 암호화되었습니다; 다시 한 번 해독합니다.

관련 코딩

• Base32는 32개의 문자 (AZ와 27) 를 사용하며 대소문자를 인식하지 못하며 인증 앱의 TOTP 비밀에 사용된다. 전체 비용은 60%입니다.
• ** 헥사데시멀** (Base16) 는 바이트당 2개의 문자를 사용한다. 100% 오버헤드이다.
• Base58는 유사 문자를 제거하고 비트코인 주소에서 사용됩니다.
• 퍼센트 코딩은 URL에서 안전하지 않은 문자만 탈출합니다.

요약

베이스64는 바이트를 64자 문자 알파벳으로 변환합니다. 한 번에 3바이트로, 대략 33%의 추가 크기의 비용으로. 텍스트 채널을 통해 바이너리 데이터를 전송하는 데 사용하십시오. URL 및 토큰에서 URL 안전 변형을 사용하십시오. 항상 텍스트를 먼저 UTF-8 바이트로 변환하십시오. 비밀 보호에 절대 사용하지 마요. 암호가 아니라 잠금입니다.