Base64란 무엇인가?
Base64는 바이트를 64개의 읽을 수 있는 문자로 다시 써서, 텍스트용으로 만들어진 통로를 통해 데이터가 살아남게 합니다. 이메일 본문, JSON 문자열, XML 속성, URL이 그 통로입니다. 세 바이트마다 네 문자가 되는데, 이름이 여기서 옵니다 — 알파벳이 64개 기호를 담고 각 기호가 정확히 6비트를 실습니다.
이것은 전송 인코딩이지 보안 수단도 압축 단계도 아닙니다. 출력은 입력보다 대략 3분의 1 크고, 문자열을 가진 사람은 누구나 바로 되돌릴 수 있습니다. 데이터가 변경되었는지 알고 싶다면 그것은 해시입니다(해시 생성기). 비밀로 유지하고 싶다면 그것은 암호화입니다. Base64는 둘 중 어느 것도 아닙니다.
기억할 단 하나의 숫자: 입력 세 바이트가 출력 네 문자가 됩니다. 이 페이지의 다른 모든 것이 여기서 따라 나옵니다. 네 문자는 24비트를 실고, 24비트는 정확히 세 바이트이므로 데이터가 사라지거나 만들어지지 않습니다 — 마지막에 입력이 마지막 세 바이트 그룹을 채우지 못할 때만 예외입니다.
이 페이지가 사용할 수 있는 다섯 가지 알파벳
첫 두 행은 표준이고 마지막 세 행은 Unix 주변에서 자라난 관례입니다. 다섯 모두 문자당 같은 6비트를 실으며 어느 64문자가 실을지만 다르므로, 같은 바이트가 다섯 개의 다른 문자열이 됩니다. 문자열 안 어디에도 어느 알파벳의 산물인지 말하는 것이 없어서, 알파벳 선택기는 표준이 기본값이고 URL 안전 체크박스가 둘째 행의 지름길입니다.
페이지가 후보를 고르는 법: 선택기가 양방향의 기본값입니다. 디코딩할 때는 오른쪽 패널이 문자열 자체도 읽습니다 — -와 _는 URL 안전 알파벳에서만, +나 /는 표준에서만 올 수 있고, 시작 부근의 /나 .는 두 Unix 알파벳을 가리킵니다. 현재 입력을 읽을 수 있는 모든 알파벳이 후보인 이유와 아닌 이유와 함께 그곳에 나열됩니다.
줄 바꿈: 76자와 64자
MIME은 어느 줄도 지나치게 길어지지 않고 이메일에 들어가는 Base64를 원했고, 줄당 76자에 CRLF로 구분하기로 했습니다. 인증서와 키를 감싸는 PEM 파일은 64자를 씁니다. 줄바꿈은 데이터의 일부가 아닙니다. 디코더는 다른 일을 하기 전에 줄바꿈을 제거하고 줄을 다시 이어 붙이므로, 랩된 문자열과 랩되지 않은 문자열은 정확히 같은 바이트로 디코딩됩니다. 마지막 줄을 제외한 모든 줄은 네 문자 그룹의 정수배를 담아서, 다시 이어 붙이는 것이 안전합니다.
이 페이지는 너비를 고르지 않는 한 출력을 한 줄에 두며, 디코더는 줄바꿈 유무와 무관하게 입력을 받아들입니다. 이 페이지가 쓰는 줄바꿈은 텍스트 상자가 담을 수 있는 일반 라인 피드입니다. MIME 메일 본문은 전통적으로 각 라인 피드 앞에 캐리지 리턴을 쓰며, 사용 중인 모든 디코더가 둘 다 받아들입니다.
패딩, 그리고 왜 생략할 수 있는가
입력이 세 바이트의 배수가 아니면 마지막 네 문자 그룹이 불완전하고, 한 개 또는 두 개의 =가 그것을 채웁니다. 이들은 아무 데이터도 담지 않습니다. 네 문자 중 몇 개가 진짜인지만 말합니다. 디코더는 대신 길이에서 그것을 계산할 수 있어서, URL 안전 Base64는 전통적으로 패딩을 뗍니다 — =는 URL이나 파일 이름에서 불편하고 일부 시스템은 퍼센트 인코딩합니다.
옵션 행의 체크박스는 URL 안전 알파벳이 선택되었을 때 패딩을 유지합니다. 그 외에는 아무것도 바뀌지 않습니다. 데이터를 실는 문자는 어느 쪽이든 동일합니다.
흔한 오해
- "Base64는 데이터를 숨긴다." 숨기지 않습니다. 키 없는 치환이며, 모든 독자가 되돌릴 수 있다는 것이 핵심입니다. 비밀번호나 토큰을 Base64로 감싸도 누가 읽을 수 있는지는 조금도 달라지지 않습니다.
- "Base64는 압축한다." 정반대입니다. 입력 세 바이트마다 출력 네 문자가 되므로 텍스트는 실은 데이터보다 3분의 1 큽니다.
- "줄바꿈이 값의 일부다." 표현일 뿐입니다. 더하거나 빼도 나오는 바이트는 결코 달라지지 않습니다.
- "URL 안전은 다른 인코딩이다." 두 문자를 바꾼 같은 인코딩입니다.
+가 -가 되고 /가 _가 되어, 문자열이 이스케이프 없이 URL 경로나 쿼리 값에 앉을 수 있습니다.
- "디코딩되는 문자열은 유효한 Base64여야 한다." 알파벳 문자의 어떤 문자열이든 유효한 Base64입니다. 6비트 값의 모든 조합이 유효한 바이트 시퀀스이기 때문입니다. 문자열은 다음 단계에서, 그 바이트가 본래이어야 했던 형식과 대조될 때 비로소 틀린 것으로 밝혀집니다.
- "패딩이 어느 알파벳인지 말해 준다." 말해 주지 않으며, 대부분의 경우 문자들도 말해 주지 않습니다. 표준과 URL 안전 알파벳은 64기호 중 62개가 같아서, 짧은 문자열은 흔히 양쪽에서 같게 읽힙니다.
자주 나오는 질문
Base64 문자열이 왜 어떤 때는 = 하나로, 어떤 때는 둘로 끝나나요? 하나는 마지막 그룹이 진짜 문자 세 개(입력 두 바이트)를 담는다는 뜻이고, 둘은 두 개(입력 한 바이트)를 담는다는 뜻입니다. =가 없으면 입력 길이가 3의 배수였다는 뜻입니다.
Base64는 임의의 바이너리 파일을 나타낼 수 있나요? 네, 그것이 주 용도입니다. 이 페이지는 입력을 UTF-8 텍스트로 취급합니다. 텍스트가 아닌 것을 인코딩할 때는 전용 도구 파일 ↔ Base64가 원시 바이트를 읽습니다.
API에서는 어느 알파벳을 써야 하나요? 수신 측이 문서화한 것이면 무엇이든. URL 안전이라면 그것을 쓰고, 아무 말도 없고 값이 URL 안을 이동한다면, 패딩을 뗀 URL 안전이 안전한 선택입니다.
출력은 대소문자를 구분하나요? 완전히 구분합니다. a와 A는 다른 값이라, Base64는 잘못 입력된 문자를 Base32나 Crockford Base32보다 훨씬 우아하게 견디지 못합니다.
