base32/

Base32는 5바이트를 문자 8개로 쓰며, 문자표는 32개뿐입니다(표준 방식은 A-Z와 2-7). 그래서 원문보다 길이가 약 60% 늘어나는데, Base64는 약 3분의 1만 늘어납니다. 대신 대소문자를 구분하지 않고 숫자 0, 1, 8, 9가 없어서 알파벳 O, I, B와 헷갈릴 일이 적습니다. 손으로 옮겨 적거나 소리 내어 읽을 때, 그리고 2FA 키나 파일 이름처럼 대소문자를 구분하지 않는 곳에 알맞습니다.

평소 만나는 Base32는 2FA 키와 대부분의 라이브러리 기본 출력을 포함해 모두 표준 방식입니다(RFC 4648 6절, 문자표 A-Z와 2-7). Base32Hex(7절, 문자표 0-9와 A-V)는 인코딩 결과의 정렬 순서가 원본 바이트의 정렬 순서와 같아지는 특징이 있어, DNSSEC의 NSEC3처럼 정렬이 필요한 곳에 쓰입니다. 둘은 서로 디코딩할 수 없습니다. 잘못 고르면 "Base32 문자가 아닙니다"라는 오류가 나는 경우가 많고, 깨진 글자만 나올 때도 있습니다.

네. TOTP의 secret(QR 코드 안 otpauth:// 링크의 secret 파라미터, 또는 직접 입력하는 키)은 보통 표준 Base32이며, 대개 대문자에 =가 없고, 4글자씩 공백으로 끊어 보여 주는 경우도 있습니다. 여기서는 그런 형식을 모두 인식해 디코딩합니다. 결과는 글자가 아니라 무작위 바이트이므로 "결과를 hex로 표시"를 체크해야 볼 수 있습니다. 예를 들어 JBSWY3DPEHPK3PXP는 48 65 6c 6c 6f 21 de ad be ef입니다. 인증 코드를 만들려면 이 사이트의 2FA 일회용 비밀번호 도구를 쓰세요.

"길이가 올바르지 않습니다"는 =를 뺀 문자 수를 8로 나눈 나머지가 1, 3, 6이라는 뜻입니다. 올바른 Base32의 나머지는 0, 2, 4, 5, 7뿐이므로 복사하다가 문자가 빠졌을 가능성이 큽니다. "Base32 문자가 아닙니다"는 몇 번째 문자인지 알려 줍니다. 표준 방식에는 0, 1, 8, 9도, 문장 부호도, 전각 문자도 없습니다. 내용에 0-9와 A-V가 있다면 Base32Hex일 수 있으니 변형을 바꿔 보세요. "=는 맨 끝에만 올 수 있습니다"는 = 뒤에 내용이 더 있다는 뜻으로, 여러 문자열이 이어 붙은 경우일 수 있으며 따로 나눠서 디코딩해야 합니다. 공백, 줄바꿈, 소문자, 빠진 =는 오류가 되지 않습니다.

=는 길이를 8의 배수로 맞추는 패딩 문자이며 데이터에 속하지 않습니다. 디코딩할 때는 있든 없든 상관없고, 인코딩할 때 "= 패딩 추가"는 기본으로 체크되어 있으니 필요 없으면 체크를 해제하세요. 생략해도 되는지는 받는 쪽에 따라 다릅니다. Google Authenticator의 otpauth 링크 형식은 secret에 패딩이 필요 없다고 하므로 보통 생략하고, Python의 base64.b32decode는 패딩이 반드시 있어야 하며 없으면 Incorrect padding 오류가 납니다.

디코딩된 바이트가 UTF-8 텍스트가 아니라는 뜻입니다. 2FA 키, 해시 값, 암호화된 데이터는 원래 바이너리이므로 "결과를 hex로 표시"를 체크하면 원본 바이트를 볼 수 있습니다. 이 도구는 텍스트를 UTF-8로만 표시합니다. 원문이 GBK 같은 다른 인코딩이라면 먼저 hex로 표시한 다음, 이 사이트의 텍스트 / 16진수 변환 도구에서 GBK를 골라 바이트를 텍스트로 되돌리세요.

세 가지를 확인하세요. 첫째, 입력 끝에 줄바꿈이나 공백이 더 붙어 있지 않은지 봅니다. 이 도구는 입력한 그대로 UTF-8로 인코딩하며 앞뒤 공백을 지우지 않습니다. 둘째, 변형이 같은지 봅니다. Python에서 표준 방식은 base64.b32encode, Base32Hex는 base64.b32hexencode(3.10부터 제공)입니다. 셋째, = 패딩을 켰는지 봅니다. Crockford, z-base-32처럼 다른 문자표를 쓰는 변형은 지원하지 않으므로 결과가 같지 않습니다.

아니요. 인코딩과 디코딩은 모두 브라우저 안에서 이루어지며 네트워크 요청을 보내지 않고 저장도 하지 않습니다. 2FA 키가 브라우저 밖으로 나가지 않습니다.