Base64URL은 두 개의 알파벳 문자를 변경합니다. 표준 Base64의 플러스는 대시가 되고 슬래시는 밑줄이 됩니다. 인코딩된 정보는 변경되지 않습니다. 변형은 주변 프로토콜이 더하기 또는 슬래시에 특별한 의미를 부여할 때 도움이 되지만 모든 URL 또는 애플리케이션 규칙에서 값을 면제하지는 않습니다.
차이를 드러내는 벡터를 사용하세요
바이트 FB FF는 다음과 같이 인코딩됩니다. +/8= 표준 Base64 및 -_8= Base64URL에 있습니다. Hello와 같은 테스트는 공유 알파벳 문자만 생성하므로 URL-safe 변환이 작동하는지 여부를 확인할 수 없습니다.
const standard = btoa(String.fromCharCode(251, 255));
const urlSafe = standard.replace(/\+/g, '-').replace(/\//g, '_');
console.log(standard); // +/8=
console.log(urlSafe); // -_8=패딩은 별도의 계약입니다
많은 토큰 형식은 끝의 등호를 생략하지만 일부 시스템은 이를 유지합니다. 알파벳 변경과 패딩 제거는 별개의 선택입니다. 패딩 없는 입력의 길이를 4로 나눈 나머지가 2이면 등호 두 개를 추가하고, 나머지가 3이면 등호 한 개를 추가해야 합니다. 나머지가 1인 입력은 패딩만 추가해서 복구할 수 없습니다. 6비트 문자 하나로는 완전한 1바이트를 나타낼 수 없기 때문입니다.
유효성을 검사할 때 마지막 문자에서 사용되지 않은 비트도 확인하세요. 이를 무시하는 디코더는 동일한 바이트 시퀀스에 대해 여러 문자열을 허용할 수 있습니다. 이러한 모호성은 애플리케이션이 디코딩된 바이트 대신 인코딩된 문자열을 비교할 때 중요할 수 있습니다. 정식 생산자는 하나의 합의된 표현을 발행해야 합니다.
쿼리 구문 분석과 Base64 디코딩을 혼동하지 마세요.
양식 스타일 쿼리 구문 분석은 리터럴 더하기를 공백으로 해석합니다. 따라서 쿼리에 이스케이프되지 않은 상태로 붙여넣은 표준 Base64 값은 디코더가 보기 전에 손상될 수 있습니다. 다음을 사용하여 쿼리를 구성합니다. URLSearchParams, 또는 수신 프로토콜이 지정하는 경우 Base64URL 변형을 사용합니다.
const query = new URLSearchParams({ payload: '+/8=' });
console.log(query.toString()); // payload=%2B%2F8%3D
console.log(query.get('payload')); // +/8=모든 공백을 자동으로 플러스로 바꾸지 마십시오. 공백은 실제 형식이거나 다른 오류의 증거일 수 있습니다. 소스를 보존하고 소스를 변경한 전송 계층을 식별하고 의도적인 수정을 적용합니다. JWT 세그먼트의 경우 일반 수리 정책을 만드는 대신 토큰 형식의 Base64URL 규칙을 사용합니다.
표준 및 URL-안전 알파벳은 다음에 설명되어 있습니다. RFC 4648. 통합에는 여전히 패딩, 공백 허용 및 최대 길이에 대한 명시적인 선택이 필요합니다.