Base64에서 « encoder »와 « decoder »는 무엇을 뜻하나요?
Base64 인코딩 (« encode base64 »)는 바이트 — 주로 UTF-8로 인코딩된 텍스트의 바이트 — 를 허용된 64자로 바꿉니다 : 대문자 26자, 소문자 26자, 숫자 10자, 그리고 + 그리고 /. Base64 디코딩 (« decode base64 »)는 정확히 그 반대입니다 : 문자열을 네 문자씩 읽고, 각 문자가 6비트를 가리키며, 24비트에서 3바이트가 나옵니다. 대부분의 사람이 « encode and decode base64 »를 검색할 때 찾는 것이 바로 이 왕복입니다.
Base64는 압축도 암호도 아닙니다 : 텍스트는 약 3분의 1 길어지고, 누구나 1초 만에 읽을 수 있습니다. 그 목적은 안전한 ASCII 문자만 허용하는 채널 — URL, HTTP 헤더, 설정 파일, JSON, 인라인 SVG, 이메일, 텍스트 데이터베이스 — 에서 바이트를 나르는 데 있습니다.
텍스트를 Base64로 인코딩하는 방법
1단계 : 텍스트는 먼저 선택한 문자셋에 따라 바이트로 인코딩됩니다 — 기본은 UTF-8이지만 레거시 데이터에는 Latin-1, Windows-1252, ASCII, UTF-16도 여전히 쓸모 있습니다. 2단계 : 바이트는 세 개씩, 즉 24비트씩 읽습니다. 3단계 : 그 24비트는 6비트 블록 넷으로 나뉘고, 각 블록은 알파벳의 해당 위치 문자로 바뀝니다. 4단계 : 마지막 그룹이 불완전하면 0비트로 채우고 문자열은 하나 또는 둘의 = (패딩)으로 닫습니다.
단계별 예시 : « AB »는 10진수로 65, 이어서 66이며 이는 01000001 01000010에 해당합니다. 세 바이트에 패딩을 채우면 : 01000001 01000010 00000000이 나옵니다. 6비트 그룹 넷은 010000 010100 001000 000000 → 위치 16, 20, 8, 0 → QUI=입니다. 인코더에 « AB »만 입력하면 키를 떼기도 전에 결과가 표시됩니다.
Base64를 텍스트로 디코딩하는 방법
디코딩은 줄바꿈과 남은 공백을 제거한 뒤 문자열을 네 문자씩 읽습니다. 각 문자를 6비트 값으로 바꾸고, 네 값을 24비트로 이어붙인 뒤 24비트를 3바이트로 나눕니다. 맨 뒤의 = 는 마지막 그룹에 실제로 쓸 바이트가 몇 개인지 알려줍니다 : 하나의 = 는 2바이트, 두 개의 = 는 1바이트를 뜻합니다.
문자열에 - 또는 _가 있으면 URL-safe 변형입니다 : 도구가 자동으로 + 그리고 / 로 바꾸고 디코딩합니다. 패딩이 없으면 « 패딩 수정 » 버튼이 복원합니다. 알파벳 밖의 문자나 잘못된 탭, 4의 배수가 아닌 길이일 때는 단순한 « 무효 » 대신 정확한 이유가 오류로 표시됩니다.
URL-safe 변형 (RFC 4648 §5)
표준 Base64는 + 그리고 /, URL에서 문제를 일으키는 두 문자입니다 : + 는 대부분의 서버에서 공백으로 해석되며, / 는 경로 구분자로 오인될 수 있습니다. URL-safe 변형은 이를 - 그리고 _로 바꿉니다. 이스케이프가 필요 없으며, 다음에서는 필수입니다 : JWT (토큰의 세 세그먼트는 패딩 없이 인코딩됩니다), 그리고 쿠키, 이어서 식별자 그리고 URL 매개변수에서도 사용됩니다.
패딩 « = » : 무엇에 쓰이나
Base64는 네 문자 단위로 작업하지만, 파일 크기가 3바이트의 배수인 경우는 거의 없습니다. 패딩은 기대되는 길이를 복원합니다 : 바이트가 1개 남으면 ==, 바이트가 2개 남으면 =. 일부 시스템은 이를 제거하고(특정 API, Base64URL), 다른 시스템은 요구합니다(PHP, 레거시 디코더). 인코더의 « 패딩 없음 » 옵션과 디코더의 « 패딩 수정 » 버튼이 두 경우를 모두 처리합니다.
문자 인코딩 : UTF-8, Latin-1, UTF-16
Base64는 문자를 모르고 바이트만 압니다. 그래서 결정적인 질문은 다음과 같습니다 : 텍스트를 Base64로 만들기 전에 무엇으로 인코딩하는가 하는 것입니다. UTF-8에서는 « é »가 2바이트고 « 日 »는 3바이트이며, Latin-1에서는 « é »가 1바이트로 들어가지만 « 日 »는 불가능합니다. Latin-1로 인코딩한 문자열을 UTF-8로 디코딩하면 이상한 문자(« mojibake »)가 나옵니다. 온라인 도구에서 결과가 이해할 수 없다면 거의 항상 시작할 때의 인코딩이 다르기 때문입니다 — 그래서 여기에 여섯 가지 옵션이 있습니다.
파일, data URI, 그리고 Base64 이미지
이런 data URI 다음 형태입니다 : data:<MIME 유형>;base64,<데이터>. 이렇게 하면 이미지를 CSS·HTML·JSON에 바로 삽입할 수 있습니다 : background-image:url(data:image/png;base64,iVBOR…). 디코딩할 때는 문자열 전체를 « 파일 ⇄ Base64 » 탭에 붙여넣으세요 : MIME 유형이 추출되고 파일 이름이 제안된 뒤 파일이 다시 만들어져 내려받을 수 있습니다. 크기 주의 : Base64는 약 33 %를 추가하며, data URI는 별도로 캐시되지 않습니다.
Base64와 URL-encoding, 그리고 둘을 섞지 말아야 하는 이유
이 percent-encoding (%20, %C3%A9)는 허용되지 않는 모든 바이트를 퍼센트 표기로 바꿉니다 : Base64보다 두세 배 길지만 눈으로는 원래 텍스트가 그대로 보입니다. Base64는 조밀하고 균일한 문자열을 만들어 블롭에 안성맞춤이지만 사람이 읽을 수 없습니다. « URL & data URI » 탭은 두 변환을 나란히 제시해서, 이스케이프해야 할 URL을 Base64로 인코딩하는 흔한 실수 — 혹은 그 반대 — 를 막아줍니다.
일상의 포맷 속 Base64
Base64는 어디에나 있습니다 : JWT의 세 세그먼트, 인라인 SVG 이미지의 src 속성, PDF의 cert 필드, 이메일의 MIME 첨부 (RFC 2045), 그리고 Authorization: Basic API의 헤더 (utilisateur:motdepasse), 그리고 .pem 파일과 SSH 키, 다음 파일의 내용 : .docx 그리고 .xlsx (ZIP), 클라이언트 저장소의 아바타, 그리고 data- 속성(자동 테스트용). 인코딩과 디코딩을 빠르게 할 줄 알면 하나의 문자열 때문에 터미널을 열 필요가 없습니다.
Base64가 아닌 것
Base64는 아무것도 암호화하지 않습니다 : 인코딩된 문자열은 한 줄의 코드로 풀립니다. 비밀번호, API 키, 개인 데이터의 보호 수단으로 절대 사용하지 마세요. 압축도 아닙니다 : 항상 33 %의 추가 용량을 감안하세요. 마지막으로 Base64는 이미 조밀하게 압축된 바이트(PNG, ZIP)에는 몇 MB를 넘으면 적합하지 않으며, 그 이상에서는 메모리 비용이 부담이 됩니다.
성능과 모범 사례
브라우저에서는 TextEncoder 그리고 TextDecoder 가 초당 수 MB를 처리합니다. Base64 알고리즘 자체는 선형이며 재귀도 문자별 할당도 없습니다. 5 MB가 넘는 파일은 인터페이스를 느리게 할 수 있습니다 : 더 큰 배치에는 Web Worker나 서버 측 처리를 권장합니다. 항상 원래 인코딩을 문자열 옆에 기록해 두고, 결과를 데이터베이스에 넣기 전에 라운드트립(인코딩 후 디코딩)을 테스트하세요.
추천 대상
백엔드·프런트엔드 개발자(tokens, data URI, HTTP 헤더), 통합 및 기술 문서 작성자(인라인 SVG, 배경 이미지), 시스템 관리자와 DevOps(인증서, 키, 덤프), 테스터와 펜테스터(Authorization Basic, 매개변수 퍼징), 학생(바이트, ASCII, UTF-8 이해), 그리고 온라인 Base64 인코더 디코더 가 필요한 모든 사람에게.