개발자 도구 · Base64 인코더 및 디코더
Base64 패딩 설명: = 기호의 의미와 필요한 경우
· 작동 방식
베이스64 인코딩 개발자 워크플로
Base64 문자열 끝에 있는 =는 장식이 아닙니다. 마지막 그룹이 짧은 바이트 수를 기록합니다. 이 게시물에서는 산술, 일부 문자열에 문자열이 없는 이유, 패딩 누락에 대해 디코더가 동의하지 않는 이유를 설명합니다.
괜찮아 보이는 토큰의 '잘못된 패딩' 예외 — 실패한 디코드와 그 뒤에 누락된 문자 1~2개
Base64 디코더가 잘못된 패딩을 보고하면 문자열은 완전한 것처럼 보이지만 구조적 오류가 있습니다. 등호는 겉모습이 아닙니다. 각 기호는 최종 그룹이 얼마나 짧은 바이트 수를 인코딩하므로 디코더가 실제 데이터가 언제 종료되었는지 정확히 알 수 있습니다. 이러한 = 기호를 이해하고 엄격한 디코더가 이 기호가 없는 문자열을 거부하는 이유를 이해하면 신비한 오류가 예측 가능한 산술로 변환됩니다. JWT 세그먼트에는 =가 1개, 없음 또는 2개가 있을 수 있습니다. API 응답은 패딩 없이 깔끔하게 끝날 수 있습니다.
이는 구현 변형이 아닌 의도적인 선택을 나타냅니다. 디코딩 프로세스에는 기계적으로 패딩이 필요하지 않습니다. 출력을 명확하게 하기 위해 패딩이 존재합니다. 길이에 대한 메타데이터가 없는 Base64 문자열만 주어지면 디코더는 패딩을 읽고 데이터가 끝난 위치를 정확히 알고 있습니다. Base64는 3바이트 그룹을 4개 문자로 인코딩합니다. 3바이트는 24 비트이며 4개의 6비트 인덱스로 완벽하게 재그룹화됩니다. 각각은 64 Base64 기호 중 하나를 선택합니다. 입력이 3의 배수가 아닌 경우 인코더는 남은 부분을 직면합니다. 즉, 1바이트 또는 2바이트는 3으로 균등하게 나눌 수 없습니다.
3바이트 그룹, 4개 문자 블록 - 입력 길이 모듈로 3가 0, 1 또는 2개의 = 기호 표시 여부를 결정하는 이유
인코더는 비트를 첫 번째 인덱스로 이동하여 해당 그룹을 채우고 최종 인덱스는 0으로 둡니다. 이를 의도적인 것으로 표시하기 위해 = 기호를 추가합니다. 완전한 그룹의 경우 0, 2바이트 최종의 경우 1개, 1바이트 최종의 경우 2개입니다. 산술은 결정적입니다. 입력 길이를 바이트 단위로 알면 패딩을 즉시 계산할 수 있습니다. 1바이트는 Base64 문자 2개와 = 2개를 생성합니다. 2바이트는 3개의 문자와 1개의 =를 생성합니다. 3바이트는 패딩 없이 4바이트를 생성합니다.
3바이트의 배수가 아닌 모든 입력에는 패딩이 포함됩니다. 배수인 것은 그렇지 않습니다. 이것은 선택이 아니라 산술입니다. 패딩이 없는 문자열은 3바이트를 나타내야 합니다. 1이 동일한 문자열은 2를 나타내야 합니다. 패딩은 입력 길이를 모듈로 3으로 인코딩합니다. 세 가지 입력(단일 a, 쌍 ab, 삼중 abc)의 변환을 조사합니다. ASCII a는 바이트 0x61입니다. Base64는 이를 0x61 00 00로 인코딩하여 6비트 그룹으로 재그룹화합니다.
패딩 비트에 포함된 내용과 엄격한 디코더가 이를 확인하는 이유 — 0이어야 하는 비트와 표준 인코딩의 의미
인덱스 24, 4, 0, 0는 Y, E, A, A에 매핑됩니다. 두 그룹이 패딩되었으므로 인코더는 두 개의 = 기호를 추가하여 YQ==를 생성합니다. ab의 경우 바이트 0x61 0x62는 0x61 0x62 00가 됩니다. 비트는 인덱스 24, 22, 8, 0, 출력 YWI=로 재그룹화됩니다. abc의 경우 바이트는 인덱스 24, 22, 9, 35로 재그룹화되고 패딩 없이 YWJj를 출력합니다. 패딩은 임의적이지 않습니다. 비트 레이아웃에서 벗어납니다. Base64 문자열을 디코딩하면 디코더는 각 문자를 읽고 6비트 인덱스를 조회한 다음 비트를 바이트로 압축합니다.
YQ==의 경우 문자 Y, E, A, A가 비트로 압축 해제됩니다. 8비트 바이트로 재그룹화하면 1바이트, 0x61이 제공됩니다. 디코더는 패딩 비트(후행 0)를 버리고 1바이트를 보고합니다. 엄격한 디코더는 패딩 비트가 실제로 0인지 확인합니다. 그렇지 않은 경우 입력은 표준이 아니었습니다. 즉, 다른 비트 레이아웃과 디코딩을 사용하여 인코딩된 사람이 모호하다는 의미입니다. 패딩을 완전히 생략하는 시스템은 의도적인 절충안을 만듭니다. JWT 세그먼트는 예상 출력 길이를 알고 있거나 이를 추론하는 소비자에 의존하여 패딩 없이 Base64url을 사용합니다.
작업된 예: 'a', 'ab' 및 'abc'를 직접 인코딩 — 3개의 입력, 3개의 패딩 결과, 비트별로 표시됨
RFC 4648는 패딩이 없는 것을 허용하지만 디코더가 있는 경우 이를 수락하도록 지시합니다. 코드 라이브러리는 다릅니다. 일부는 누락된 패딩을 복원하고 진행합니다. 다른 사람들은 실패할 것이다. 디코딩에 실패한 토큰이 발견되면 올바른 개수의 = 기호를 추가하면 문제가 해결되는 경우가 많습니다. 필수 = 기호는 문자열 길이 모듈로 4에 따라 항상 0, 1 또는 2입니다. Base64 문자열 길이가 4의 배수가 아닌 경우 패딩이 누락되었거나 손상된 것입니다.
5 길이는 유효할 수 없습니다. Base64: 각 완전한 문자는 6비트를 인코딩하므로 4개 문자는 24 비트(3바이트)를 인코딩하고 5개 문자는 30 비트를 인코딩합니다. 이는 8의 배수가 아니며 바이트가 될 수 없습니다. 디코더는 이를 거부하거나 패딩을 추가해야 합니다. 길이가 2 모듈로 4인 경우 두 개의 =를 추가합니다. 3 모듈로 4인 경우 =를 하나 추가합니다. 0 모듈로 4인 경우 없음을 추가하세요. 길이가 3인 문자열에는 필요한 것이 부족합니다. 하나를 추가하면 디코딩 전에 유효해집니다.
일부 시스템에서 패딩을 완전히 삭제하는 이유 — JWT 세그먼트 및 =를 생략한 URL 안전 토큰 및 길이에서 이를 복원하는 방법
패딩이 제자리에 남아 있는 경우 패딩된 두 개의 Base64 문자열을 연결하면 끊어집니다. 직접 결합된 두 개의 개별 인코딩은 디코딩 알파벳을 깨뜨리는 스트레이 패딩 문자를 생성합니다. 이것이 일부 시스템이 연결하기 전에 패딩을 제거하는 이유입니다. 점으로 연결된 3개의 Base64url 세그먼트로 구성된 토큰은 세그먼트 내에 패딩이 없으므로 연결이 간단해집니다. 부품에서 Base64 값을 구축하는 경우 각 부품이 패딩되었는지 확인하고 작업 전에 일관되게 패딩을 제거하거나 추가합니다.
Base64 인코더 및 디코더는 기본적으로 패딩이 필요한 RFC 4648를 적용합니다. 텍스트를 입력하고 base64 출력을 요청하면 도구는 패딩된 결과인 표준 형식을 생성합니다. 패딩이 없는 Base64가 표시되고 이를 디코딩하려면 디코더가 누락된 패딩을 허용하는지 확인하세요. 이 도구는 패딩된 입력과 패딩되지 않은 입력을 모두 허용하고 원본 바이트를 올바르게 복구합니다. 디버깅의 경우 길이를 모듈로 4로 계산하면 패딩이 제거되었는지 여부를 알 수 있으며 수식은 어떤 패딩이 있어야 하는지 알려줍니다.
일반적인 실수: 다듬기 = 마치 공백인 것처럼 처리하거나 두 개의 패딩된 문자열을 연결 — 각각이 어떻게 디코드를 손상시키는가
Base32 및 Base16(16진수)에는 RFC 4648 섹션 6 및 7에 정의된 서로 다른 패딩 규칙이 있습니다. Base32는 =를 사용하지만 최종 그룹은 입력 길이 모듈로 5에 따라 2, 4, 5, 7 또는 8 문자가 될 수 있습니다. 16진수에는 패딩이 필요하지 않습니다. 항상 1바이트를 나머지 없이 2문자로 매핑합니다. MIME Base64 래핑은 패딩에 닿습니다. 76 열로 래핑된 문자열은 몇 줄 뒤에도 여전히 맨 끝에 패딩이 있습니다.
Base64의 패딩을 이해하는 것은 비트 레이아웃과 모듈로 3 입력 길이를 이해하는 것입니다. 산수를 보면 패딩은 암기해야 할 규칙이 아니라 직접적인 결과가 됩니다. 패딩은 마법이 아닌 파생 가능합니다.
여기서 다루지 않는 내용 — base32 및 base16 패딩 규칙 및 MIME 줄 길이 규칙
임의의 길이의 Base64 문자열이 주어지면 문자 수를 4로 나누고 나머지를 취하고 해당 수의 = 기호를 추가하여 표준 패딩 형식을 복원할 수 있습니다. 이것이 누락이 수정 가능한 이유이고 엄격한 디코더가 용서될 수 있는 이유입니다. 패딩은 정보(입력이 세 가지 경우에 속하는 분기)를 전달하지만 해당 정보는 길이만으로 계산할 수 있습니다.
Base64 인코더 및 디코더는 패딩된 출력을 즉시 표시하므로 디코딩된 바이트를 원본 텍스트와 비교하고 왕복이 작동했는지 확인할 수 있습니다. Base64 및 관련 인코딩은 비트를 다른 문자 너비로 재그룹화하는 원리를 확장합니다. RFC 4648은 세 가지를 모두 지정하며, 하나를 이해하면 다른 것들은 개념적으로 단순해집니다. 핵심 통찰력은 인코딩이 순수한 비트 조작이라는 것입니다. 즉, 알파벳 크기를 선택하고 그에 따라 비트를 그룹화하고 테이블에서 각 그룹을 찾습니다.
요점: 패딩은 파생 가능하므로 누락된 =는 수정 가능합니다. Base64 인코더 및 디코더가 인코딩한 텍스트의 패딩된 표준 형식을 표시하는 방법
역방향 디코딩: 각 문자를 찾아 비트를 추출하고 다시 그룹화하고 바이트를 씁니다. 이러한 결정적 양방향 매핑 덕분에 Base64는 모든 플랫폼과 언어에서 안정적으로 작동합니다. 인코딩 및 디코딩 오류는 패딩이나 알파벳 차이에 대한 오해로 인해 발생하는 경우가 많습니다. 패딩 오류로 인해 디코딩이 실패하는 경우 디코더가 표준 Base64(엄격하게 패딩됨)를 예상하는지 아니면 변형을 허용하는지 확인하세요. 문자 오류로 인해 실패하는 경우 입력이 base64url이고 디코더에서 표준 Base64를 예상하는지 확인하세요.
Base64 인코더 및 디코더는 알파벳을 모두 허용하고 패딩을 일관되게 검증하므로 직접 계산한 모든 예제를 즉시 확인할 수 있습니다. 인코딩을 다시 디코딩하여 테스트하는 것은 생산 문제가 발생하기 전에 실수를 잡아내는 가장 확실한 방법입니다.