인코딩·문자셋
Base64 문자열에 어떤 내용이 들어 있나요?
사용할 도구
API 응답이나 설정 파일에서 뜻을 알 수 없는 긴 문자열을 본 적이 있나요? 암호화된 것이라 생각하고 조사를 멈추기 쉽지만, 단지 Base64로 표현된 데이터일 수도 있습니다.
공개된 짧은 예제를 복원한 뒤 조건을 하나씩 바꿉니다. 연습에 실제 인증 정보는 필요하지 않습니다. 원본 데이터, 인코딩된 표현, 출력 방식을 구분하면 긴 문자열도 순서대로 조사할 수 있습니다.
YWJj를 복원하면 무엇이 나올까요?
Base64 도구에서 디코드, 표준 Base64, UTF-8 출력을 선택합니다. 아래 네 글자만 입력하고 실행하세요. 따옴표나 설명 문장은 넣지 않습니다.
YWJj결과는 abc입니다. 인코드로 바꿔 abc를 입력하면 YWJj로 돌아옵니다. 원본과 표현 사이를 왕복한 것이며, 비밀 키나 복호화 비밀번호는 사용하지 않았습니다.
인코딩은 규칙에 따라 표현을 바꾸고, 디코딩은 그 표현에서 데이터를 꺼냅니다. 읽기 어려워 보인다고 다른 사람이 복원할 수 없는 것은 아닙니다. 실제 데이터를 조사할 때도 이 차이를 기억하세요.
왜 일부러 읽기 어렵게 만들까요?
abc는 그대로 보내는 편이 간단해 보입니다. 하지만 텍스트 형식으로 이미지나 임의의 파일을 전달하려면 사정이 달라집니다. 모든 바이트를 그 형식에 그대로 넣을 수 있는 것은 아닙니다.
Base64는 제한된 문자 집합으로 원래 바이트를 표현합니다. 목적은 비밀 보호가 아니라 표현 방식입니다. API의 Base64 필드는 바이트를 문자 형태로 운반한다고 이해하면 좋습니다.
같은 abc인데 결과가 다를까요?
인코드 상태에서 abc와 끝에 LF 줄바꿈 하나를 붙인 abc를 비교하세요. 후자는 YWJj가 아니라 YWJjCg==입니다. 글자 뒤의 보이지 않는 바이트도 데이터이므로 결과가 달라집니다.
YWJj
YWJjCg==복원된 글자가 같아 보이면 Hex 출력을 선택합니다. 줄바꿈 없이는 616263, LF가 있으면 6162630a입니다. 다른 환경에서는 CRLF를 쓸 수도 있습니다. 화면이 비슷해도 바이트가 같은지는 따로 확인해야 합니다.
한글도 복원할 수 있지만 인코딩이 중요합니다
日本語라는 세 글자를 시험해 보세요. SheepDev는 텍스트를 UTF-8 바이트로 바꾼 뒤 Base64로 인코딩하므로 5pel5pys6Kqe가 됩니다. UTF-8 출력으로 디코드하면 원래 세 글자로 돌아오며, 화면 언어는 이 결과를 바꾸지 않습니다.
Base64가 일본어나 한글을 이해하는 것은 아닙니다. 문자를 바이트로 바꾸는 단계와 바이트를 Base64로 바꾸는 단계는 별개입니다. 원본이 Shift_JIS 같은 다른 인코딩이면 올바른 Base64라도 UTF-8 글자로 읽히지 않을 수 있습니다.
이때는 Hex를 확인하고 생성 측에서 확인한 문자 인코딩으로 조사합니다. 오류가 없어질 때까지 인코딩을 무작정 바꾸지 마세요. 읽을 만한 글자가 나와도 원문을 정확히 복원했다는 증거는 아니므로 알려진 내용과 대조해야 합니다.
길어지는 것은 정상입니다: Base64는 압축이 아닙니다
abc는 UTF-8로 3바이트이고 YWJj는 ASCII 4글자입니다. Base64는 보통 3바이트를 4글자로 표현하므로 긴 데이터는 약 1.33배가 됩니다. 이미지를 Base64로 바꾸기만 해서는 전송량이 줄지 않습니다.
| 원문 | 표준 Base64 |
|---|---|
| a | YQ== |
| ab | YWI= |
| abc | YWJj |
짧은 입력은 패딩 때문에 증가 비율이 더 커 보일 수 있습니다. a, ab, abc를 차례로 시험하면 끝의 등호 수가 바뀝니다. 등호는 길이에 따른 패딩이지 잘못된 문자나 복사 찌꺼기가 아닙니다. 생략 가능 여부는 사용하는 형식의 규칙을 따라야 합니다.
Base64url은 무엇이 다를까요?
표준 Base64는 +와 /를 사용하고 Base64url은 해당 위치에 -와 _를 사용합니다. SheepDev의 Base64url 인코드는 끝의 패딩도 생략합니다. 웹에서 쓴다는 이유만으로 고르지 말고 받는 형식의 규칙을 확인하세요.
abc는 두 방식에서 같아 차이를 보여 주지 못합니다. 대신 ????를 인코딩하면 표준은 Pz8/Pw==, Base64url은 Pz8_Pw입니다. 디코드할 때도 맞는 방식을 고르고, 문자를 직접 바꾸기 전에 설정부터 확인하세요.
복원된 데이터가 항상 글은 아닙니다
Base64에는 이미지, 압축 데이터, 암호문도 담길 수 있습니다. 이들은 디코드 후 올바른 UTF-8이 아닐 수 있습니다. Base64 형식 오류와 복원 바이트를 UTF-8로 읽을 수 없는 오류는 다른 문제입니다.
/w==로 연습해 보세요. 표준 Base64를 Hex로 디코드하면 ff이지만, FF 한 바이트는 유효한 UTF-8 텍스트가 아닙니다. UTF-8 오류가 Base64 자체의 오류를 뜻하지는 않습니다. Hex는 바이트 관찰용이지 원본 이미지를 표시하는 기능이 아닙니다.
복원되지 않을 때의 확인 순서
- 생성 측에서 Base64로 지정했는지 확인합니다. 긴 영숫자라는 모양만으로 ID나 해시와 구분할 수는 없습니다.
- 값 전체를 복사했는지 확인합니다. 따옴표·설명·data: URL 헤더를 포함하지 않았는지, 중간에 잘리지 않았는지도 봅니다.
- 표준/Base64url 선택을 확인합니다. SheepDev는 중간의 모든 공백과 줄바꿈을 자동 제거하지 않습니다. 원본 형식에서 줄을 접는지도 알아보세요.
- 형식이 디코드되면 내용 종류를 확인합니다. 텍스트는 문자 인코딩, 나머지는 원래 파일 형식을 확인하고, 의미 없는 출력을 올바른 복원으로 받아들이지 마세요.
읽기 어려워 보여도 비밀은 아닙니다
키 없이 YWJj에서 abc를 꺼냈던 것을 떠올리세요. 비밀번호나 개인정보도 인코딩했다고 이 성질이 바뀌지 않습니다. 문제 보고에서 인코딩된 값을 가린 정보로 취급하면 원문이 노출될 수 있습니다.
해시는 목적이 다르며 Base64처럼 디코드해 원문을 복원하는 값이 아닙니다. JWT를 읽는 것 역시 서명이나 신뢰성을 확인한 것은 아닙니다. 각 전용 가이드에서 무엇을 확인할 수 있는지에 따라 도구를 선택하세요.
실제 조사에 적용한다면
유용한 조사 기록은 '디코드 성공'보다 구체적입니다. 생성 측 형식, 출력 모드, 예상과 실제 차이를 기록하세요. '표준 Base64가 Hex FF로 복원되지만 UTF-8은 아니다'라고 쓰면 다음 조사를 데이터 종류나 문자 인코딩으로 이어갈 수 있습니다.
형식을 확인하고 값을 분리한 뒤 원래 데이터 종류를 파악하세요. 이 순서를 익히면 변환기는 문자열 변환뿐 아니라 문제 범위를 좁히는 도구가 됩니다. 내용을 읽을 수 있다는 사실은 실행하거나 공개해도 안전하다는 판정이 아닙니다.