인코딩은 양쪽 끝이 동의하는 경우에만 유용합니다. 수신자에게 친숙한 알파벳이 필요하거나 페이로드를 사람이 입력해야 하거나 주변 구문이 특정 문자를 특별하게 처리하는 경우 가장 작은 표현이 반드시 최선의 선택은 아닙니다. 수신 프로토콜로 시작합니다.
16진수는 장황하지만 검사하기 쉽습니다.
16진수는 각 바이트를 두 자리 숫자로 씁니다. 바이트 시퀀스 FF 00 41은 다음과 같습니다. ff0041. 모든 쌍에는 가시적인 바이트 경계가 있어 파일 서명, 체크섬 및 프로토콜 패킷을 검사할 때 도움이 됩니다. 문자 수는 두 배로 늘어나지만 작은 알파벳은 일반적으로 로그 및 디버깅 도구에 쉽게 맞습니다.
Base64은 크기와 상호 운용성의 균형을 유지합니다.
Base64은 4자로 구성된 3바이트를 나타냅니다. 이는 텍스트 기반 형식 내의 이진 필드에 일반적으로 적합합니다. 표준 Base64에는 더하기 및 슬래시가 포함됩니다. Base64URL는 프로토콜에 다른 알파벳이 필요할 때 해당 문자를 대체합니다. 패딩 및 공백 규칙은 여전히 합의가 필요합니다. 두 형식 모두 수신자에게 디코딩된 바이트가 텍스트인지, 이미지인지, 압축된 콘텐츠인지 알려주지 않습니다.
백분율 인코딩은 URL 구성 요소에 속합니다.
백분율 인코딩은 이스케이프된 바이트를 다음과 같이 씁니다. %HH. 이는 단순히 Base64을 대량으로 대체하는 것이 아닙니다. 구성 요소는 이스케이프해야 하는 문자를 결정하며, 텍스트는 먼저 UTF-8로 인코딩되어야 합니다. 물음표가 쿼리를 시작하는 동안 슬래시는 경로 세그먼트를 구분할 수 있습니다. 전체 URL을 하나의 불투명 구성 요소로 처리하면 의미가 변경됩니다.
console.log(encodeURIComponent('a+b / 中文'));
// a%2Bb%20%2F%20%E4%B8%AD%E6%96%87Base85에는 정확한 변형이 필요합니다.
많은 Base85 구성표는 5개의 문자로 4바이트를 나타내지만 알파벳, 구분 기호 및 특수 사례는 다릅니다. ASCII85와 Z85는 서로 바꿔 사용할 수 없다고 가정할 수 있습니다. Z85는 또한 블록 크기 요구 사항을 부과합니다. 고밀도 알파벳에는 주변 형식에서 다시 이스케이프해야 하는 구두점이 포함될 수 있으므로 명백한 이점이 줄어듭니다.
이러한 바이트 인코딩을 숫자 베이스 사이의 정수 255 변환과 혼동하지 마십시오. 파일은 0바이트로 시작할 수 있지만 정수 표현은 앞에 오는 0을 삭제할 수 있습니다. 가역적 파일 코덱은 길이와 선행 0이 유지되는 방식을 정의해야 합니다.
바이트 검사를 위한 16진수, 상호 운용 가능한 바이너리 전송을 위한 지정된 Base64 변형, URL에 대한 URL 구성 요소 인코딩 및 양 당사자가 동일한 계약을 구현하는 경우에만 특수 체계를 사용합니다. 이스케이프 및 압축 후 엔드투엔드 크기를 비교합니다. RFC 4648 고유한 알파벳을 포함하여 표준 Base16, Base32 및 Base64 제품군을 정의합니다.