개발자 도구 · Base64 인코더 및 디코더
Base64의 간략한 역사: uuencode와 PEM부터 오늘날의 알파벳까지
· 배경
베이스64 인코딩
Base64의 알파벳은 1980년대 전송 문제의 화석 기록입니다. 이 게시물은 uuencode에서 Privacy-Enhanced Mail to MIME 및 RFC 4648까지의 계보를 따르고 각 디자인 선택에 대해 설명합니다.
알파벳이 명백한 순서로 단순히 0–63이 아닌 이유 — 40년 전으로 거슬러 올라가는 질문
Base64는 표준으로 완전히 형성되지 않은 것으로 나타났습니다. 알파벳(A-Z, a-z, 0-9, +, /))은 동일한 문제, 즉 1970년대와 1980년대 이메일, USENET 및 Unix 도구에서 바이너리 데이터를 텍스트로 표현하는 방법을 해결하기 위해 수십 년간의 인코딩 실험에 대한 화석 기록입니다. 이야기는 Unix의 uuencode, Privacy-Enhanced Mail(RFC)에 걸쳐 있습니다. 1421)(1993), MIME(RFC 2045)(1996), 마지막으로 2006의 RFC 4648(모든 변형)을 통합합니다.
이 기록을 이해하면 특정 문자가 알파벳에 포함된 이유와 RFC가 구현자에게 특정 선택 사항을 남긴 이유가 설명됩니다. Unix-to-Unix 인코딩의 약자인 uuencode는 Unix의 7비트 전송 문제를 해결한 최초의 도구였습니다. 1980에서 생성되었으며 각 3 바이트(24 비트)를 64 문자 알파벳의 4 문자로 인코딩했습니다. uuencode 알파벳은 ASCII 32(공백)부터 ASCII 95(밑줄 및 기타 구두점)까지였으며 해당 문자는 모든 터미널에서 인쇄 가능하기 때문에 선택되었습니다. 저장소에는 현재 구현된 알파벳이 표시되지만 누가 해당 순서를 선택했는지 또는 모든 캐릭터가 승리한 이유에 대한 보관 증거는 포함되어 있지 않습니다. 따라서 제목이 좁아졌습니다. 현재 레이아웃을 정확하게 검사할 수 있으며 동기와 날짜에는 여기에 포함되지 않은 기본 역사적 문서가 필요합니다.
알파벳이 역사적으로 보이는 이유 — 이 저장소가 문서화하지 않은 경계
그러나 인코딩 문자로서의 공백은 문제가 있습니다. 텍스트 편집기와 메일 시스템은 후행 공백을 잘라내어 출력을 손상시킵니다. 알파벳은 이상적이지는 않았지만 Unix에서 Unix로의 파일 전송에는 충분히 잘 작동했습니다. 개인 정보 보호 강화 메일(RFC 1421, 1992)은 암호화된 이메일을 표준화하려는 초기 시도였습니다. 여기에는 자체 Base64 인코딩(RFC 1341, MIME용, RFC 1421이 사양보다 앞서 있지만 채택이 뒤쳐짐)이 포함되어 있습니다.
RFC 1421 Base64는 알파벳 A-Z, a-z, 0-9, +, /(최신 base64 알파벳)를 사용하고 64 문자에 래핑된 줄을 사용했습니다. 이 알파벳은 공백과 기타 문제가 있는 문자를 피했습니다. 모든 문자는 명확하게 인쇄 가능하며 제어 코드나 국가별 문자 집합 변형과 혼동되지 않습니다. 64 문자 줄 길이는 1980년대 종이 터미널의 너비와 일치했으며 가독성을 위한 실질적인 절충안이었습니다. Uuencode는 주변 기록에 속하지만 도구는 알파벳을 읽거나 쓰지 않습니다. 이를 교환 가능한 Base64로 취급하면 형식 오류가 됩니다. 여기서 유용한 비교는 인쇄 가능한 문자로 바이트를 표시하는 공유 문제로 제한됩니다.
구현 증거가 아닌 컨텍스트로서의 이전 인코딩
RFC 1421는 암호화된 이메일에 널리 채택되지 않았지만 Base64 알파벳은 살아 남았습니다. MIME(다용도 인터넷 메일 확장, RFC 2045, 1996)은 RFC 1421 Base64 알파벳을 채택했지만 줄 바꿈을 64에서 76 문자로 변경했습니다. 그 이유는 기술적인 것이 아니라 역사적이었습니다. PEM(Privacy-Enhanced Mail) 블록은 64 문자였으며 MIME은 자동 구문 분석에서 PEM과의 혼동을 피하기 위해 약간 다른 제한을 선택했습니다.
MIME Base64는 이메일 첨부 파일의 표준이 되었으며 오늘날 가장 널리 사용되는 Base64 변형입니다. RFC 2045는 또한 콘텐츠 유형에 따라 메일 시스템 옵션을 제공하는 다른 콘텐츠 전송 인코딩 값(7비트, 8비트, 인용 인쇄 가능)을 정의했습니다. 알파벳을 선택하면 ASCII와 EBCDIC(IBM 메인프레임 문자 인코딩)이 다른 문자를 피할 수 있습니다. A-Z, a-z, 0-9, + 및 / 문자는 두 인코딩 모두에서 동일합니다. PEM 스타일 블록은 레이블이 래핑된 인코딩된 자료를 둘러싸므로 인식 가능합니다. ToolAcre는 해당 레이블이 제거된 후 추출된 Base64 본문을 처리할 수 있습니다. 어떤 아카이브 사양이 주어진 규칙을 먼저 사용했는지 확인할 수 없으며 이 기사에서는 소스 트리가 해당 질문에 대답하는 척하지 않습니다.
기원 이야기를 주장하지 않고 현대적으로 관찰 가능한 형식의 PEM 스타일 갑옷
여는 괄호, 닫는 괄호 등의 문자는 ASCII와 EBCDIC 간에 다르기 때문에 제외되었습니다. 이는 메인프레임에서 Unix로의 데이터 전송이 흔했던 1980년대와 1990년대 초에 중요했습니다. 또한 알파벳은 C 문자열 및 셸 구문에서 특별한 의미를 갖는 백슬래시, 작은따옴표 및 큰따옴표를 방지합니다. Base64 문자열은 거의 모든 문자를 이스케이프 처리하지 않고도 C 프로그램이나 셸 스크립트에 포함될 수 있습니다.
RFC 3548(2006) 통합 Base64, base32 및 base16 인코딩. MIME, PEM 및 기타 애플리케이션은 모두 유사한 개념을 사용했지만 패딩 규칙과 알파벳이 다르다는 점에 주목했습니다. RFC 4648(2006, RFC 3548와 함께 게시됨)는 현재 표준이며 각각에 대한 테스트 벡터가 있는 5개의 인코딩 제품군을 정의합니다. RFC는 또한 어떤 문서가 어떤 인코딩을 정의했는지, 버전 간에 무엇이 변경되었는지, 왜 선택했는지 등의 기록을 기록합니다. 인코더의 76 문자 래핑 옵션과 디코더의 공백 제거를 통해 MIME 형식 샘플을 테스트할 수 있습니다. 이러한 구현 사실은 메일 표준의 완전한 역사를 증명하지 않습니다. 이는 독자가 패널에서 직접 재현하고 테스트할 수 있는 최신 호환성 동작을 보여줍니다.
표준 기록을 재구성하지 않고 인코더 옵션으로 MIME 스타일 래핑
대부분의 개발자는 RFC 4648에서 base64 및 base64url만 접합니다. 이전 변형을 구현해야 하는 사람들을 위해 기록이 문서화되어 있습니다. Base64url(RFC 4648 섹션 5)은 URL 예약 문자를 피하기 위해 더하기를 대시로 바꾸고 슬래시를 밑줄로 바꿉니다. + 및 /가 포함된 base64 문자열은 URL(%2B 및 %2F)에서 백분율로 인코딩되어야 합니다. base64url은 이를 방지합니다.
JWT(JSON 웹 토큰)은 패딩 없이 base64url을 사용합니다. 일부 애플리케이션은 패딩과 함께 base64url을 사용합니다. RFC는 두 변형을 모두 정의합니다. 선택할 것은 응용 프로그램에 달려 있습니다. 이러한 차이로 인해 JWT 디코더와 이메일 Base64 디코더가 동일한 입력 문자열에 대해 서로 다른 출력을 생성할 수 있습니다(하나는 base64url을 예상하고 다른 하나는 base64를 예상함). 알파벳, 패딩 규칙, 줄바꿈 등은 모두 실제 시스템의 실질적인 제약에서 비롯되었습니다. 이식성은 각 기호의 검증된 전기보다는 전송 알파벳에 대한 제약으로 가장 잘 처리됩니다. 문자와 숫자는 일반적인 텍스트 시스템에서 시각적으로 친숙하게 유지되지만 URL 안전 모드에서는 마지막 구두점이 다릅니다. 정확한 역사적 선택 근거는 주요 증거 없이 생략됩니다.
개별 캐릭터 선택에 대한 검증된 설명이 아닌 디자인 제약으로서의 이식성
64 문자 세트는 인코딩 전반에 걸친 표현성을 위해 선택되었습니다. 알파벳은 RFC 1341 및 1421 및 MIME에 의해 수정되었습니다. 패딩 규칙은 3바이트 정렬에서 나왔습니다. 줄 바꿈은 이메일 전송 제한으로 인해 발생했습니다. 이 기록을 무시하는 구현은 새로운 인코딩을 고안하거나 극단적인 경우를 잊어버릴 수 있습니다. RFC 4648 테스트 벡터(foobar는 Zm9vYmFy를 생성함)는 구현이 표준을 준수하는지 확인하는 방법입니다.
base85(일부 상황에서 사용됨)와 같은 최신 대안이 존재하지만, 역사적 모멘텀과 충분히 우수하기 때문에 base64가 여전히 지배적입니다. Base64는 가장 컴팩트한 인코딩은 아니지만(base85 및 base91은 밀도가 더 높음) 간단하고 보편적이며 입증되었습니다. 확실하게 말할 수 있는 것은 현재의 알파벳 쌍입니다. 표준은 더하기와 슬래시로 끝납니다. URL 안전 대체 하이픈과 밑줄. 패딩과 래핑은 별도의 옵션입니다. 테스트는 모드와 누락된 패딩을 모두 다루며, 추론된 연대기보다는 현재 동작에 대한 재현 가능한 증거를 제공합니다.
현재 표준 및 URL 안전 알파벳에 대해 저장소가 증명하는 것
33 퍼센트 크기 오버헤드는 대부분의 용도에 허용됩니다. 알파벳은 구현 전반에 걸쳐 안정적입니다. RFC는 실수로 인한 오해보다는 일반적으로 편차가 의도적인 것(예: 패딩 누락 또는 공백 처리)일 정도로 충분히 명확합니다.
Base64 기록을 이해하면 그것이 왜 그렇게 보이는지 설명됩니다. 더하기 및 슬래시 문자는 다양한 문자 인코딩에서 모호함을 피하기 위해 의도적으로 선택한 것입니다. 패딩 규칙은 3바이트 그룹화에서 나왔습니다. Base85 및 Ascii85는 서로 다른 그룹 크기와 알파벳을 사용하며 구현 범위를 벗어납니다. 그들을 언급한다고 해서 이 페이지가 그들을 위한 변환기가 되는 것은 아닙니다. 밀도나 기록을 비교하려면 이 모듈에서 검토한 Base64 파일 이상의 소스와 테스트 벡터가 필요합니다.
요약: 모든 문자는 이유 때문에 선택되었습니다. Base64 인코더 및 디코더가 결과로 나온 표준 알파벳을 구현하는 방법
줄 바꿈은 이메일에서 왔습니다. 각 결정은 실제 시스템의 실제 문제를 해결하기 위해 이루어졌습니다. 오늘날 Base64는 기록이 중요하지 않은 컨텍스트(JWT, API, 데이터 URI)에서 주로 사용되지만 알파벳 및 패딩 규칙은 RFC 4648을 통해 MIME 및 PEM에서 상속됩니다.
RFC를 한 번 읽고 Base64 인코더 및 디코더 도구에서 테스트 문자열을 인코딩하면 현재 표준이 역사적 뿌리에 연결됩니다. 결과 표준 알파벳은 입력이 인덱스 62 또는 63에 도달할 때마다 표시됩니다. 해당 위치를 생성하는 샘플을 사용하고, URL 안전 모드를 전환하고, 변경된 구두점만 비교하세요. 그 실험은 발명에 대한 뒷받침되지 않는 이야기에 의존하지 않고 오늘날의 형식을 보여줍니다.