개발자 도구 · Base64 인코더 및 디코더
Base64 vs hex vs base32: 바이트를 텍스트로 쓰는 세 가지 방법 비교
· 배경
베이스64 인코딩
Hex, base32 및 Base64는 크기, 가독성 및 안전성 측면에서 서로 다른 절충안을 적용하여 동일한 문제를 해결합니다. 이 게시물에서는 밀도, 대소문자 구분, URL 안전 및 인적 오류를 비교합니다.
l, 1, I 및 O로 인해 잘못 입력된 API 키 — 16진수에서는 발생하지 않았을 구체적인 가독성 오류
바이트를 텍스트로 표현하는 세 가지 일반적인 방법은 hex, base32 및 base64입니다. 이들은 모두 동일한 문제(인쇄 가능한 ASCII로 임의의 바이트 표현)를 해결하지만 크기, 가독성 및 오류 복원력이 서로 다릅니다. 16진수는 바이트당 2 문자이므로(F3 A2 B1 ...) 16 바이트는 32 문자가 됩니다. Base32는 바이트당 1.6자(3바이트당 약 5자)이므로 16바이트는 26자가 됩니다.
Base64는 바이트당 1.33자(정확히 3바이트당 4자)이므로 16바이트는 24자 이하가 됩니다. 파일 크기가 중요하다면 base64가 가장 컴팩트합니다. 인간 전사가 중요하다면 hex와 base32가 더 안전합니다. 값을 입력하거나 복사하거나 말할 때 가독성 차이는 매우 중요합니다. 16진수는 0-9 및 a-f(대부분의 상황에서 대소문자를 구분하지 않음)를 사용합니다. 기계에 최적화된 표현이 사람에게는 어색할 수 있으므로 전사 채널은 결정을 바꿉니다. Base64는 대소문자를 구분하며 두 개의 구두점 기호를 사용합니다. 16진수는 더 작은 시각적 어휘를 사용합니다. 여기서 구현은 인적 오류율이 아닌 정확한 문자열을 테스트하므로 인위적인 확률이 첨부되지 않습니다.
밀도: 2×, 1.6× 및 1.33× — 각 인코딩에 바이트당 필요한 문자 수와 그 이유
Base32는 A-Z 및 2-7을 사용하여 종이에서 쉽게 혼동되는 0, 1, O 및 I를 피합니다. Base64는 대문자와 소문자를 모두 포함하는 A-Z, a-z, 0-9, + 및 /,를 사용하여 대소문자를 구분하고 유사해 보이는 숫자를 혼합합니다(0 대 O, 1 대 I 대 소문자 l). 16진수로 된 API 키는 f3a2b1e4일 수 있습니다. base64의 동일한 바이트는 86KrvE==(패딩 포함)이거나 base32 6VEV7FI=(패딩 포함)일 수 있습니다.
사용자가 값을 직접 입력해야 하는 경우 16진수 또는 base32가 base64보다 안전합니다. URL의 예약된 문자가 중요합니다. Hex와 base32는 URL에 안전합니다. 둘 다 영숫자 문자만 사용합니다(16진수는 0-9도 사용하고, base32는 2-7도 사용함). Base64는 URL 예약된 더하기 및 슬래시를 사용합니다(더하기는 양식으로 인코딩된 데이터의 공백을 나타내고 슬래시는 경로 구분 기호입니다). Base64 밀도는 출력 기호당 유용한 6비트와 패딩부터 4문자 블록까지 직접 따릅니다. 16진수는 기호당 4비트를 전달하여 바이트당 2문자를 만듭니다. Base32는 이 저장소가 출력을 확인하기 위한 알파벳이나 인코더를 제공하지 않기 때문에 비교 컨텍스트로만 논의됩니다.
비트 너비의 밀도 — 정확한 Base64 및 16진수 산술, Base32가 비교 컨텍스트로 처리됨
URL 매개변수의 base64 문자열은 백분율로 인코딩되어야 하며(더하기는 %2B, 슬래시는 %2F가 됨) 각 발생에 대해 4 추가 문자를 추가해야 합니다. Base64url(RFC 4648 섹션 5)은 더하기를 대시로 바꾸고 슬래시를 밑줄로 대체하여 백분율 인코딩 없이 URL을 안전하게 만듭니다. URL에서 base64를 사용하는 대부분의 API는 실제로 base64url을 사용하지만 문서에서는 그 구별이 명시적이지 않은 경우가 많습니다.
TOTP 비밀(인증 앱에서 사용하는 코드)은 일반적으로 base32로 배포됩니다. TOTP 등록 화면에는 base64 또는 16진수의 동일한 바이트보다 입력하고 복사하는 것이 더 쉽기 때문에 base32 비밀이 표시됩니다. SHA 해시 다이제스트는 전통적인 형식이고 16진수가 대소문자를 구분하지 않아 오타가 발생할 가능성이 적기 때문에 16진수로 표시되는 경우가 많습니다. 대소문자 구분은 누군가가 값을 큰 소리로 읽거나 다시 입력할 때 중요합니다. 한 문자의 대소문자를 변경하면 색인도 변경되기 때문입니다. ToolAcre는 대소문자를 정확하게 유지하고 사람이 전사 오류를 범했다는 사실을 알지 못한 채 결과적으로 다른 바이트를 디코딩합니다. 표현 자체에는 체크섬이 없습니다.
예약 문자 및 URL 안전 — + 및 / 바이트 위치, base32 및 hex가 문제를 방지하는 방법
JWT는 base64url을 사용합니다. 파일 체크섬은 16진수 또는 base64일 수 있습니다. 둘 다 공통적입니다. 선택은 기술적 필요성이 아니라 역사적 관습에 따른 것입니다. 오류 복원력은 미묘하지만 중요한 차이점입니다. Base32는 숫자 0, 1, 8 및 9(문자처럼 보임)을 방지하여 전사 오류를 줄입니다. Base64에는 모든 숫자가 포함되어 1를 모호하게 만듭니다(문자 I, 소문자 l 또는 숫자 1입니까?).
16진수는 훨씬 더 오류가 발생하기 쉽습니다. 0은 O처럼 보이고, 나는 1처럼 보입니다. 입력하거나 인쇄물에서 읽어야 하는 체크섬은 base32에서 더 안전합니다. 컴퓨터에서 직접 붙여넣은 API 키는 어떤 형식에서도 안전합니다. 가독성은 사람의 눈이 관련될 때만 중요합니다. 바이트는 동일하지만 인코딩은 다릅니다. 16바이트 시퀀스 [0xf3, 0xa2, 0xb1, ...]는 f3a2b1이 됩니다... 표준 Base64의 더하기 및 슬래시는 채널 인식 처리가 필요합니다. URL 안전 모드는 이를 하이픈과 밑줄로 대체합니다. 16진수는 숫자와 문자만 사용하여 구분 기호를 피합니다. Base32 규칙은 다양하므로 이 문서에서는 저장소가 구현하거나 테스트하지 않는 유망한 안전 속성을 피합니다.
작업 예: 세 가지 인코딩 모두에서 동일한 16 바이트 — 길이 비교 및 육안 검사
(16진수), 6VEV7FI=...(base32), 86KrvE==(base64). 이 문자열 중 어느 것도 서로 바꿔서 사용할 수 없습니다. f3a2b1...을 수신하는 애플리케이션은 16진수를 예상하고 이를 16진수로 구문 분석하려고 시도합니다. 애플리케이션이 16진수를 요구하면 86KrvE== 수신은 실패합니다. 인코딩 형식은 데이터 계약의 일부입니다. 송신자와 수신자는 어떤 인코딩이 사용되는지에 동의해야 합니다. 패딩은 또 다른 차이점입니다.
16진수는 패딩을 사용하지 않습니다(4 바이트는 항상 8 16진수 문자이며 예외 없음). Base32와 base64는 모두 등호 패딩을 사용하여 출력을 여러 문자로 정렬합니다(base32의 경우 8, base64의 경우 4). 패딩은 수학적으로 필요합니다. 이는 모든 n바이트 입력이 결정적인 문자 수를 생성하도록 보장합니다. 패딩 규칙은 다양합니다. 일부 애플리케이션에는 패딩이 필요하고 다른 애플리케이션에서는 생략이 허용됩니다. 작업된 비교에서는 고정 바이트 시퀀스를 사용하고 Base64 및 16진수를 기계적으로 계산합니다. Base32 길이는 5비트 그룹화를 통해 논의할 수 있지만 검토된 구현에서 생성된 정확한 Base32 텍스트 값은 생략되었습니다. 길이 산술 및 출력 확인은 별개로 유지됩니다.
각각이 일반적인 경우 — 16진수 해시, base32의 TOTP 비밀, JWT 및 데이터: Base64의 URI
패딩 없이 base32 또는 base64 값을 붙여넣는 경우 디코더는 구현에 따라 이를 수락하거나 거부할 수 있습니다. 암호화 키와 토큰은 인코딩 차이를 보여줍니다.
HMAC 키는 32바이트이며 64 16진수 문자, 52 base32 문자(패딩 포함) 또는 44 base64 문자(패딩 포함)가 됩니다. 키를 배포할 때 인코딩을 문서화해야 합니다. 문서에 키가 44 base64 문자라고 되어 있는데 52 문자가 표시되면 뭔가 잘못된 것입니다. 컨벤션은 독자에게 지침이 될 수 있지만 적합성을 입증하지는 않습니다. 해시 다이제스트는 일반적으로 16진수로 표시되는 반면 JWT 세그먼트는 Base64url을 사용합니다. 올바른 선택은 여전히 채널 규칙, 사람들이 값을 복사하는지 여부, 다른 프로토콜이 이미 표현을 수정했는지 여부에 따라 달라집니다.
여기서 다루지 않는 내용 — base58, base85 및 체크섬 인코딩
더 짧은 base64 인코딩을 사용하면 문자 제한(예: QR 코드 또는 URL)이 있는 시스템에 토큰을 맞추기가 약간 더 쉬워집니다. 값에 대한 인코딩 선택은 해당 값이 나온 생태계에 따라 설정됩니다. 웹 API는 종종 base64url을 사용합니다. 암호화 문서에서는 종종 16진수를 사용합니다. 인증 앱은 base32를 사용합니다. 시스템을 구축할 때 하나의 인코딩을 선택하고 명확하게 문서화한 후 이를 고수하세요.
인코딩(base64 또는 base32)을 혼합하면 혼란이 발생합니다. 디버깅할 때 첫 번째 단계는 값이 사용하는 인코딩을 식별하는 것입니다. Base64 인코더 및 디코더 도구는 여러 가지 방법으로 디코딩을 시도하고 어떤 방법이 합리적인 출력을 생성하는지 확인함으로써 도움을 줄 수 있습니다. 보편적으로 더 나은 인코딩은 없습니다. Base64는 원시 스토리지에 가장 컴팩트합니다. Hex는 암호 작성자에게 가장 친숙하며 작은 시퀀스의 경우 사람이 가장 쉽게 읽을 수 있습니다. Base58, Base85 및 체크섬 인코딩은 서로 다른 절충안을 가지며 ToolAcre의 Base64 패널에는 없습니다. 알파벳, 모호성 규칙 및 체크섬은 이 도구의 테스트된 동작에서 추정하기보다는 전용 소스 및 구현을 통해 평가되어야 합니다.
요약: 채널 및 리더에 대한 인코딩 선택 — 동일한 제품의 SHA 해시 계산기와 함께 Base64 인코더 및 디코더가 브라우저의 Base64 케이스를 처리하는 방법
Base32는 전사 오류에 대한 복원력이 가장 뛰어납니다. 선택은 가치가 존재하는 위치, 공유 방법, 가치를 소비할 시스템 등 상황에 따라 달라집니다.
장단점을 이해하면 API 또는 시스템을 설계할 때 현명한 선택을 하는 데 도움이 됩니다. Base64 인코더 및 디코더 도구는 base64 인코딩을 보여줍니다. 16진수 또는 base32 도구와 함께 사용하면 세 가지 형식 모두에서 동일한 바이트를 확인하고 크기와 가독성의 차이를 이해할 수 있습니다. Base64 사례의 경우 샘플을 인코딩하고 정확한 UTF-8바이트 및 출력 문자 수를 기록하고 표준과 URL 안전 구두점을 테스트합니다. 다이제스트 작업을 위해서는 별도의 SHA 패널을 사용하세요. 이러한 작업을 구별되게 유지하면 인코딩 선택이 해싱 또는 무결성 보호로 오인되는 것을 방지할 수 있습니다.