이 세 가지 이름은 관련된 바이너리-텍스트 구성표를 설명하지만 서로 다른 제약 조건을 제공합니다. Base64 및 Base64URL은 6비트 그룹을 사용합니다. 표준 Base32은 5비트 그룹과 더 작은 알파벳을 사용합니다. 올바른 선택은 귀하의 운송, 보관 및 수령 애플리케이션이 정확하게 보존할 수 있는 것입니다.
길이보다 알파벳을 비교하세요
표준 Base64은 대문자와 소문자, 숫자, 더하기 및 슬래시를 사용합니다. Base64URL은 마지막 두 문자를 대시와 밑줄로 대체합니다. 둘 다 대소문자를 구분합니다. 표준 RFC Base32는 대문자 A~Z와 숫자 2~7을 사용합니다. 디코더는 편의상 소문자를 허용할 수 있지만 프로토콜은 그것이 허용되는지 여부를 명시하고 표준 출력을 정의해야 합니다.
대소문자를 구분하지 않는 채널은 올바르게 지정된 Base32 값을 유지하면서 Base64 값을 삭제할 수 있습니다. URL 토큰에는 전화로 소리내어 읽는 코드와는 다른 제약 조건이 있습니다. 순전히 샘플이 얼마나 짧은지 보고 선택하지 마십시오.
크기 균형 이해
마지막 부분 그룹을 무시하면 Base64에는 바이트당 약 1.33자가 필요하고 Base32에는 1.6자가 필요합니다. 표준 패딩 Base32은 5바이트에 대한 8자 그룹을 내보냅니다. 문자 f를 포함하는 1바이트의 경우 공통 벡터는 다음과 같습니다. Zg== Base64 및 MY====== Base32에 있습니다. 작은 입력은 패딩 오버헤드를 과장하므로 실제 페이로드 길이를 비교하십시오.
Payload bytes: 66 (ASCII f)
Base64: Zg==
Base64URL: Zg== (or Zg when the protocol omits padding)
RFC Base32: MY======Base32 변형을 혼합하지 마십시오
Crockford Base32은 사람이 읽을 수 있는 식별자를 중심으로 설계되었으며 RFC Base32과 다른 알파벳 및 모호성 규칙을 사용합니다. Base32hex도 다릅니다. 한 변형에서 생성된 값은 다른 디코더에 맹목적으로 전달될 수 없습니다. 문서의 변형, 알파벳, 패딩 정책 및 체크섬 동작의 이름을 지정하세요.
인코딩은 인증도 제공하지 않습니다. 잘못 입력된 값은 여전히 구문적으로 유효하며 다른 바이트로 디코딩될 수 있습니다. 사용자가 코드를 기록하는 경우 알파벳이 모든 오류를 포착한다고 가정하기보다는 프로토콜 정의 체크섬 또는 확인 단계를 고려하십시오.
완전한 계약서를 작성하세요
관련 있는 경우 입력 바이트 순서, 빈 입력 동작, 선행 0 보존, 최대 길이, 공백 허용 및 유효하지 않은 문자 처리를 지정합니다. 높은 값의 바이트와 부분 그룹이 있는 테스트 벡터를 포함합니다. 선택한 인코더와 디코더를 해당 벡터에 대해 독립적으로 사용하는 것뿐만 아니라 서로에 대해서도 사용합니다. 그렇지 않으면 일치하는 버그가 왕복을 통과한 것처럼 보일 수 있습니다. 표준 형식과 참조 벡터는 다음과 같습니다. RFC 4648.