사용 방법
- 검사할 문자열을 입력란에 붙여넣습니다.
- 판정 결과를 확인합니다. ‘유효한 Base64’인지 ‘유효하지 않은 Base64’인지와 함께 감지된 ‘변형’(표준 또는 URL 안전), ‘디코딩 후 크기’가 표시됩니다.
- ‘문제’ 항목이 표시되면 보고된 위치를 참고해 잘못된 문자, 공백 문자, 잘못된 위치의 패딩을 찾습니다.
- 감지된 ‘내용’ 유형을 보고 데이터가 텍스트인지, PNG, PDF, ZIP 같은 파일인지 확인합니다.
유효한 Base64의 조건
- 알파벳.
A-Z,a-z,0-9와 두 문자만 허용됩니다. 표준 Base64에서는+,/문자이고, Base64URL에서는-,_문자입니다. 두 쌍이 섞인 문자열은 대개 손상되었거나 서로 다른 두 출처에서 가져와 이어 붙인 것입니다. - 패딩.
=기호는 맨 끝에만, 최대 두 번까지 나올 수 있습니다. 중간에 패딩이 있다면 대개 인코딩된 값 두 개가 연결된 것입니다. - 길이. 패딩이 있으면 길이는 4의 배수입니다. 패딩이 없으면 4n + 1을 제외한 모든 길이가 가능합니다. 남은 문자 하나에는 6비트만 담겨 1바이트를 만들 수 없기 때문입니다.
엄격한 디코더는 규칙을 하나 더 적용합니다. 마지막 문자에서 사용되지 않는 하위 비트가 0이어야 한다는 것입니다. 많은 디코더는 이 비트를 무시하지만, Go의 base64.StdEncoding.Strict()처럼 이런 문자열을 거부하는 디코더도 있습니다.
흔한 오류와 해결 방법
| 문제 | 주요 원인 | 해결 방법 |
|---|---|---|
| 잘못된 문자 | 값과 함께 복사된 따옴표, 백슬래시, %2B, %3D 같은 이스케이프 | 불필요한 문자를 지우거나 먼저 URL 디코딩 |
| 중간의 공백 | 값이 URL이나 폼을 거치면서 +가 공백으로 바뀜 | +를 되돌려 놓거나, URL에는 Base64URL 사용 |
| 4n + 1 길이 | 열 너비 제한, 로그 줄, 부분 복사로 값이 잘림 | 전체 값을 다시 복사 |
| 중간의 패딩 | Base64 문자열 두 개가 이어 붙음 | 나눈 뒤 각 부분을 따로 디코딩 |
| 줄 바꿈 | MIME 또는 PEM 줄 바꿈 | 대개 문제없음. 한 줄이 필요한 곳에서는 제거 |
유효하다고 해서 의미 있는 데이터는 아닙니다
Base64에는 헤더도 체크섬도 없으므로, 유효하다는 것은 문자열을 디코딩할 수 있다는 뜻일 뿐입니다. 평범한 영어 단어도 상당수 검사를 통과합니다. 영문자 네 개는 무엇이든 유효한 묶음이 되기 때문입니다. 그래서 이 검사기는 데이터를 실제로 디코딩해 크기와 내용 유형도 함께 보고합니다. 읽을 수 있는 텍스트나 PNG, PDF, ZIP 같은 알려진 파일 시그니처가 나온다면 그 문자열이 실제로 Base64라는 좋은 증거입니다. 무작위 바이트 몇 개만 나온다면 그렇지 않습니다. 다른 인코딩도 함께 확인하려면 인코딩 감지기를 사용해 보십시오.
코드에서 Base64 유효성 검사하기
// JavaScript: 패딩이 있는 표준 Base64(빈 문자열도 일치)
/^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$/
# Python: 잘못된 문자를 건너뛰지 않고 오류 발생
import base64, binascii
try:
base64.b64decode(s, validate=True)
except binascii.Error:
print('invalid')자주 묻는 질문
평범한 단어가 유효한 Base64로 판정되는 이유는 무엇입니까?
실제로 유효하기 때문입니다. 알파벳 문자로만 이루어지고 길이가 적절하다면 어떤 문자열이든 몇 바이트로 디코딩됩니다. 예를 들어
test라는 단어는 3바이트로 디코딩됩니다. 감지된 내용 유형을 확인하십시오. 결과가 읽을 수 있는 텍스트도 아니고 알려진 파일 형식도 아니라면, 입력은 애초에 Base64가 아니었을 가능성이 높습니다.공백이나 줄 바꿈이 있는 Base64도 유효합니까?
MIME과 PEM은 Base64를 여러 줄로 나누며, 대부분의 디코더는 공백 문자를 건너뜁니다. 하지만 JSON 필드, HTTP 헤더, JWT, data URI에는 끊김 없는 한 줄 문자열이 필요합니다. 검사기는 공백 문자를 별도로 표시하므로, 문자열이 사용될 곳에서 문제가 되는지 직접 판단할 수 있습니다.
= 패딩이 없는 Base64도 유효합니까?
대개는 유효합니다. Base64URL은 보통 패딩을 생략하며, RFC 4648도 문맥상 길이를 알 수 있을 때는 패딩 생략을 허용합니다. 다만 일부 엄격한 디코더는 여전히 패딩을 요구하므로, 시스템이 문자열을 거부한다면 길이가 4의 배수가 될 때까지
= 기호를 붙이십시오. 패딩 없는 문자열의 길이가 4n + 1자라면 결코 유효하지 않습니다.JavaScript에서 문자열이 Base64인지 확인하려면 어떻게 합니까?
패딩이 있는 엄격한 Base64라면, 알파벳 문자 4개로 된 묶음 뒤에 선택적인 패딩이 오는 형태를 허용하는 정규식으로 검사하십시오. 더 간단한 방법은
try/catch 안에서 atob()를 호출하는 것입니다. 단, atob()는 잘못된 입력에 InvalidCharacterError를 발생시키지만 공백 문자와 누락된 패딩은 아무 경고 없이 받아들이고, URL 안전 문자는 받아들이지 않는다는 점에 유의하십시오.