두 인코딩 사이를 변환하는 방법
- 입력란에 문자열을 붙여넣으세요. 변환 전이 자동 감지로 되어 있으면 상태 표시줄에 도구가 판단한 형식이 나옵니다. 예: “감지됨: Base58 · 틀렸나요? 다른 형식으로 읽기 [Base64] …”.
- 추측이 틀렸다면 다른 형식으로 읽기 버튼 중 하나를 누르거나 변환 전을 직접 설정하세요.
- 변환 후에서 대상 형식을 고르세요. 형식은 텍스트, Base64, 바이트와 숫자, Base32, 큰 수 기반 진법, Base85/Base91/Base45, 그리고 이메일, URL 및 레거시 인코딩으로 묶여 있습니다.
- 형식별 옵션은 해당 창 아래에 나타납니다. 예를 들어 Base58과 Base62에는 알파벳, Base32와 Base64에는 패딩 (=) 옵션이 있습니다.
- ⇄ 바꾸기는 출력을 입력으로 옮기고 두 형식을 맞바꿉니다. 출력 복사와 다운로드는 결과를 가져가고, 바이트 저장은 디코딩된 바이트를 파일로 내려받습니다.
모든 변환은 원시 바이트를 거칩니다. 입력을 디코딩한 다음 그 바이트를 다시 인코딩합니다. 도구 아래의 바이트 카운터가 바이트 수를 보여 주는데, 키나 해시가 온전한지 확인하는 가장 빠른 방법인 경우가 많습니다. 위에 나열된 단일 용도 페이지들은 형식이 미리 설정된 이 변환기를 엽니다.
인코딩 비교
| 인코딩 | 알파벳 | 출력 크기 | 오버헤드 | 대표적인 용도 |
|---|---|---|---|---|
| Hex / Base16 | 16 | 바이트당 2문자 | 100% | 해시, 디버깅, 바이트 덤프 |
| Base32 | 32 | 5바이트당 8문자 | 60% | TOTP 시크릿, 어니언 주소, 대소문자 무관 ID |
| Base36 | 36 | 바이트당 ≈ 1.55문자 | ≈ 55% | 대소문자 무관한 짧은 ID와 숫자 |
| Base45 | 45 | 2바이트당 3문자 | 50% | QR 코드(EU 디지털 건강 증명서) |
| Base58 | 58 | 바이트당 ≈ 1.37문자 | ≈ 37% | 비트코인, 솔라나, IPFS |
| Base62 | 62 | 바이트당 ≈ 1.34문자 | ≈ 34% | 단축 URL과 ID |
| Base64 | 64 | 3바이트당 4문자 | 33% | 이메일, JSON, data URI, JWT 등 거의 모든 곳 |
| Ascii85 / Z85 | 85 | 4바이트당 5문자 | 25% | PDF, PostScript, Git, ZeroMQ 키 |
| basE91 | 91 | 바이트당 ≈ 1.23문자 | 14–23% | 출력 가능한 ASCII에 데이터를 최대한 압축해 담기 |
| Uuencode / xxencode | 64 | 3바이트당 4문자 + 줄 구조 | ≈ 38% | 옛날 이메일과 유즈넷 첨부 파일 |
오버헤드는 랜덤 데이터 기준이며, 큰 수 기반 진법은 값에 따라 한두 문자씩 달라집니다. Base45는 여기서 낭비가 심해 보이지만, QR 코드의 영숫자 모드에서는 45개 문자가 각각 5.5비트로 표현되어 오버헤드가 3% 가까이로 줄어듭니다.
같은 입력, 5바이트 문자열 Hello를 각 인코딩으로 나타내면 다음과 같습니다.
| Hex | Base32 | Base36 | Base45 | Base58 | Base62 | Base64 | Ascii85 | basE91 |
|---|---|---|---|---|---|---|---|---|
48656c6c6f | JBSWY3DP | 3yud78mn | %69 VDL2 | 9Ajdvzr | 5TP3P3v | SGVsbG8= | 87cURDZ | >OwJh>A |
진법을 만드는 세 가지 방식
인코딩은 세 그룹으로 나뉘며, 어느 그룹인지가 동작 대부분을 설명해 줍니다.
비트 그룹: hex, Base32, Base64, uuencode, xxencode. 알파벳 크기가 2의 거듭제곱이므로 각 문자가 고정된 비트 수(4, 5, 6비트)를 담습니다. 인코딩이 빠르고 스트림으로 처리할 수 있으며, 출력 길이는 입력 길이에만 좌우됩니다.
고정 블록: Base45(2바이트를 3문자로)와 Base85 계열(4바이트를 5문자로). 알파벳 크기가 2의 거듭제곱이 아니므로 작은 블록 단위로 수로 바꿉니다. 여전히 빠르고 스트림 처리가 가능하며, 길이도 입력 크기로 정해집니다.
큰 수: Base36, Base58, Base62. 입력 전체를 하나의 수로 보고 새 진법으로 씁니다. 알파벳 크기에 제한이 없고 출력에 패딩이 없지만, 모든 바이트가 모든 문자에 영향을 주고, 앞쪽의 0 바이트는 따로 처리해야 하며, 비용이 크기의 제곱으로 늘어납니다. 이 변환기는 앞쪽의 0 바이트를 앞쪽의 0 자리로 유지하고, 이 진법들의 입력은 64 KB로 제한합니다.
basE91은 그룹 사이에 걸쳐 있습니다. 한 번에 13비트나 14비트를 읽으므로 길이가 내용에 따라 조금 달라집니다.
어떤 인코딩을 골라야 하나
- 프로그램끼리 주고받을 때: Base64, URL과 토큰 안에서는 Base64URL. 모든 언어에 내장되어 있고, 이만큼 널리 통하는 것이 없습니다.
- 사람이 값을 읽거나 입력하거나 불러 줄 때: Base32(가능하면 Crockford 변형) 또는 Base36. 둘 다 대소문자를 구분하지 않고, Crockford는 비슷하게 생긴 글자도 피합니다.
- URL 속 짧은 불투명 ID: 영문자와 숫자만으로 가장 짧은 문자열을 원하면 Base62, 사람이 손으로 옮겨 적을 수 있다면
0,O,I,l을 뺀 Base58. - QR 코드: QR 영숫자 모드와 함께 Base45.
- 바이트 하나하나가 중요하고 채널이 일반 ASCII일 때: 고정 블록이 필요하면 Ascii85나 Z85, 몇 퍼센트 더 줄이려면 basE91.
- 바이트를 살펴볼 때: hex. 크기는 두 배지만 모든 바이트가 읽을 수 있는 두 문자로 나타납니다.
- 레거시 시스템이 요구할 때: uuencode나 xxencode. 새로운 용도로는 쓰지 마세요.
hex, Base32, Base58, Base85 비교에서 Base64와 비교한 장단점을 더 깊이 다룹니다.
자주 묻는 질문
바이너리 데이터를 가장 짧게 담는 텍스트 인코딩은 무엇인가요?
흔히 쓰는 것 중에서는 basE91(랜덤 데이터 기준 오버헤드 약 23%), 다음이 Base85 계열(25%), 그다음이 Base64(33%)입니다. 더 짧은 인코딩은 JSON, HTML, 셸에서 이스케이프가 필요한 문장 부호를 쓰기 때문에, 결국 Base64가 더 나은 선택인 경우가 많습니다.
URL에는 어떤 인코딩이 가장 좋나요?
기계가 생성하는 토큰에는 짧고 표준화된 Base64URL이 좋습니다. 값에 영문자와 숫자만 있어야 하면 Base62나 Base58, 대소문자가 바뀌어도 살아남아야 하면 Base32나 Base36을 쓰세요. Base45와 Base85에는 퍼센트 인코딩이 필요한 문자가 들어 있습니다.
Base58, Base62, Base36 출력의 길이가 들쭉날쭉한 이유는 무엇인가요?
입력을 하나의 큰 수로 다루기 때문에 길이가 바이트 수뿐 아니라 그 값에도 좌우됩니다. Base64, Base32, hex는 고정된 비트 그룹을 대응시키므로 바이트 수가 같으면 항상 길이도 같습니다.
자동 감지는 문자열의 형식을 어떻게 판단하나요?
가장 특징적인 것(<~나 begin 644 같은 구분자)부터 가장 일반적인 것까지 순서대로 각 형식의 규칙에 입력을 대어 보고, 처음 맞는 형식으로 디코딩합니다. 짧은 문자열은 여러 형식에서 유효할 수 있으므로 다른 형식으로 읽기 버튼으로 다른 해석을 고를 수 있습니다.
이런 인코딩이 데이터를 보호해 주나요?
아니요. 모두 키 없이 누구나 되돌릴 수 있습니다. 바이트를 출력 가능한 문자로 바꿀 뿐입니다. 인코딩과 암호화의 차이를 참고하세요.