Base64URL 인코더 및 디코더

Q: Base64URL은 Base64 문자열을 URL 인코딩한 것과 같습니까?

아니요. 표준 Base64를 퍼센트 인코딩하면 +, /, =가 각각 %2B, %2F, %3D로 바뀌어 문자열이 길어집니다. Base64URL은 처음부터 다른 알파벳을 사용하므로 이스케이프가 전혀 필요 없습니다. 두 형식은 변환하지 않고는 서로 바꿔 쓸 수 없습니다.

Q: 표준 Base64 디코더가 Base64URL 문자열을 거부하는 이유는 무엇입니까?

엄격한 표준 디코더는 -, _ 문자를 받아들이지 않으며, 일부는 패딩도 요구합니다. 문자를 바꾸고 길이가 4의 배수가 되도록 = 기호를 붙이거나, 이 페이지에서 디코딩하십시오.

Q: PKCE code challenge를 확인하려면 어떻게 합니까?

challenge 값은 패딩 없는 BASE64URL(SHA256(code_verifier))입니다. 출력을 ‘16진수’로 설정하고 이 페이지에서 디코딩하십시오. 올바른 값이라면 정확히 32바이트가 나오며, 이를 verifier의 SHA-256 해시와 비교할 수 있습니다.

텍스트, 16진수 바이트, 파일을 URL 안전 Base64로 변환하고 되돌립니다. 알파벳은 +와 / 대신 -와 _를 사용하며, JSON Web Token과 OAuth PKCE에서처럼 패딩은 기본적으로 꺼져 있습니다.

변형 패딩 줄 바꿈 문자 인코딩

입력

파일 열기

출력

실시간

브라우저에서만 실행되며 어떤 데이터도 업로드되지 않습니다.

사용 방법

‘인코딩’ 또는 ‘디코딩’을 선택합니다. ‘변형’은 ‘URL 안전(RFC 4648 §5)’으로 미리 선택되어 있고 ‘패딩’은 꺼져 있습니다.
텍스트를 입력하거나 붙여넣고, 16진수 바이트를 입력하거나, 파일을 엽니다. 결과는 입력하는 즉시 갱신됩니다.
수신 시스템이 끝에 = 기호를 요구하는 경우에만 ‘패딩’을 켭니다.
결과를 복사하거나 다운로드합니다.

Base64URL이란?

Base64URL은 RFC 4648 5절에 "Base 64 Encoding with URL and Filename Safe Alphabet"(URL과 파일 이름에 안전한 알파벳을 사용하는 Base 64 인코딩)으로 정의되어 있습니다. 문자 하나가 6비트를 표현한다는 점은 표준 Base64와 똑같지만, URL과 파일 경로에서 문제를 일으키는 두 문자를 다른 문자로 바꿉니다.

	표준 Base64	Base64URL
값 62	`+`	`-`
값 63	`/`	`_`
패딩	`=`, 필수	대개 생략

URL에서 +는 공백으로 해석될 수 있고, /는 경로 세그먼트를 구분하며, =는 쿼리의 키와 값을 구분합니다. 그래서 표준 Base64는 링크에 넣기 전에 퍼센트 인코딩을 거쳐야 합니다. Base64URL은 이스케이프가 필요 없습니다. RFC 4648은 문맥상 길이를 알 수 있을 때 패딩을 생략하도록 허용하며, Base64URL을 기반으로 하는 대부분의 사양이 실제로 패딩을 생략합니다.

Base64URL이 사용되는 곳

JSON Web Token. JWT의 헤더, 페이로드, 서명은 각각 패딩 없는 Base64URL입니다(RFC 7515). JWT 디코더로 내용을 확인할 수 있습니다.
OAuth 2.0 PKCE. code_challenge는 code verifier의 SHA-256 해시를 패딩 없는 Base64URL로 표현한 값이므로(RFC 7636) 길이가 항상 43자입니다.
JSON Web Key와 WebAuthn. n, e, x, y 같은 키 매개변수와 WebAuthn 챌린지, 자격 증명 ID는 Base64URL로 주고받습니다.
토큰, ID, 파일 이름. 비밀번호 재설정 링크, 서명된 URL, 캐시 키는 이스케이프 없이 Base64URL 값을 담습니다. 16바이트 난수 ID는 22자가 됩니다. Base64URL은 대소문자를 구분하므로, 대소문자를 구분하지 않는 파일 시스템에서는 Base32를 사용하는 편이 좋습니다.

Base64와 Base64URL 간 변환

두 변형은 같은 바이트를 인코딩하므로 문자만 바꾸면 변환됩니다. + 문자는 - 문자로, / 문자는 _ 문자로 바꾼 다음 끝의 = 기호를 제거합니다. 반대로 변환하려면 문자를 다시 바꾸고 길이가 4의 배수가 될 때까지 = 기호를 붙입니다. 이 페이지의 디코더는 패딩 유무와 관계없이 두 알파벳을 모두 받아들입니다.

// Node.js 16+
Buffer.from(data).toString('base64url')
Buffer.from(str, 'base64url')

# Python(urlsafe_b64encode는 패딩을 유지함)
base64.urlsafe_b64encode(data).rstrip(b'=')

// Go
base64.RawURLEncoding.EncodeToString(data)

// Java
Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)

사양

알파벳	`A-Z a-z 0-9 - _`
출력 크기	3바이트당 4문자(약 133%)
패딩	선택 사항, 보통 생략
표준	RFC 4648 5절
대소문자 구분	예

예시

입력 (UTF-8)	출력
`Hello, World!`	`SGVsbG8sIFdvcmxkIQ`
`Base64.is`	`QmFzZTY0Lmlz`
`你好`	`5L2g5aW9`

자주 묻는 질문

Base64URL은 Base64 문자열을 URL 인코딩한 것과 같습니까?

아니요. 표준 Base64를 퍼센트 인코딩하면 +, /, =가 각각 %2B, %2F, %3D로 바뀌어 문자열이 길어집니다. Base64URL은 처음부터 다른 알파벳을 사용하므로 이스케이프가 전혀 필요 없습니다. 두 형식은 변환하지 않고는 서로 바꿔 쓸 수 없습니다.

Base64URL에 패딩을 붙여야 합니까?

사용하는 쪽에 따라 다릅니다. JWT, JSON Web Key, PKCE는 패딩을 생략해야 하지만, Python의 urlsafe_b64encode와 Java의 기본 URL 인코더는 패딩을 붙입니다. 확실하지 않다면 생략하십시오. 이 디코더는 두 형식을 모두 받아들입니다.

표준 Base64 디코더가 Base64URL 문자열을 거부하는 이유는 무엇입니까?

엄격한 표준 디코더는 -, _ 문자를 받아들이지 않으며, 일부는 패딩도 요구합니다. 문자를 바꾸고 길이가 4의 배수가 되도록 = 기호를 붙이거나, 이 페이지에서 디코딩하십시오.

PKCE code challenge를 확인하려면 어떻게 합니까?

challenge 값은 패딩 없는 BASE64URL(SHA256(code_verifier))입니다. 출력을 ‘16진수’로 설정하고 이 페이지에서 디코딩하십시오. 올바른 값이라면 정확히 32바이트가 나오며, 이를 verifier의 SHA-256 해시와 비교할 수 있습니다.