Base62는 일반적으로 숫자와 대문자 및 소문자를 사용합니다. 이는 구두점이 없는 간결한 식별자에 매력적입니다. Base64은 64개 기호를 사용하고 비트 그룹을 직접 팩합니다. 이름은 비슷하지만 Base62 구현에서는 입력을 숫자로 모델링하는 경우가 많으며 이로 인해 서로 다른 상호 운용성 문제가 발생합니다.
알파벳 순서는 형식의 일부입니다.
두 개의 Base62 라이브러리는 숫자, 대문자, 소문자에 대해 서로 다른 순서를 선택할 수 있습니다. 그러면 동일한 표시 문자열이 다른 숫자를 나타냅니다. 사용하는 시스템 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz 소문자를 먼저 배치하는 것에 동의하지 않습니다. 프로토콜에 알파벳과 테스트 벡터를 기록합니다. "Base62"만으로는 충분하지 않습니다.
대소문자 구분도 중요합니다. 소문자 프록시, 대소문자를 구분하지 않는 데이터베이스 조합 또는 수동으로 정규화된 식별자는 해당 값을 변경할 수 있습니다. 스토리지 계층에서 대소문자를 무시하는 경우 일반 Base62나 Base64은 추가 설계 결정 없이는 안전한 표현이 아닙니다.
바이트를 인코딩할 때 길이 보존
16진수를 포함하는 두 개의 파일을 고려해보세요. 01 그리고 0001. 부호 없는 정수로 해석되면 둘 다 값이 1입니다. 순수한 정수에서 Base62로의 변환은 구별을 잃습니다. 바이트 지향 Base62 형식에는 명시적인 선행 0 처리 또는 길이 필드가 필요합니다. 이는 특히 무작위 토큰 및 고정 길이 암호화 값과 관련이 있습니다.
const a = BigInt('0x01');
const b = BigInt('0x0001');
console.log(a === b); // true: numeric equality loses byte length값이 의미하는 바에 따라 선택하세요.
하나의 애플리케이션 제어 하에 데이터베이스 정수를 단축하는 경우 문서화된 Base62 알파벳이 편리할 수 있습니다. 독립 시스템 간에 임의의 바이트를 전송하는 경우 Base64URL은 일반적으로 더 명확하고 표준화된 계약을 제공합니다. 동일한 6비트 그룹을 유지하면서 표준 Base64 구두점을 대시와 밑줄로 대체합니다.
인코딩은 무작위화가 아닙니다. Base62 변환 후에도 순차적 정수는 예측 가능한 상태로 유지됩니다. 식별자가 추측에 저항해야 하는 경우 암호화 무작위 소스를 사용하여 예측할 수 없는 엔트로피를 충분히 생성한 다음 길이 손실 없이 결과 바이트를 인코딩합니다. 작게 보이는 토큰을 생성이 안전하다는 증거로 취급하지 마십시오.
출력 크기를 비교할 때 접두사, 패딩 규칙 및 모든 길이의 메타데이터를 포함하세요. 최소한 빈 입력, 0바이트, 여러 개의 선행 0 및 높은 값 바이트를 왕복합니다. Base64URL 알파벳은 다음에서 표준화되었습니다. RFC 4648; Base62 애플리케이션은 추가 세부정보 자체를 지정해야 합니다.