도구스개발

Ascii85(Base85) 인코딩 변환기

4바이트를 5문자로 담는 Base85를 서로 변환합니다. btoa·Adobe·Z85·RFC 1924의 서로 다른 문자표와 z 축약, 자투리 처리 규칙을 변종별로 정확히 지킵니다.

입력한 내용은 서버로 전송되지 않습니다.

인코딩 결과
9jqo^BlbD-BleB1DJ+*+F(f,q
원본20 바이트
Base8525 자
팽창률25 %
Base64로 적으면28자 (3자 더 김)
z 축약 (0 네 바이트)0 번
y 축약 (공백 네 개)0 번
계산 근거 — 4바이트를 32비트 정수로 읽고 85진법 다섯 자리로 적습니다.85⁵ = 4,437,053,125 ≥ 2³² = 4,294,967,296하필 85진법인 이유가 이 부등식입니다. 84진법이면 84⁵ = 4,182,119,424로 2³²에 모자라 다섯 자리에 다 담기지 않습니다. Base64는 3바이트를 4문자로 담아 33% 늘어나지만, Base85는 4바이트를 5문자로 담아 25%만 늘어납니다.
«Base85»라고만 하면 어느 것인지 알 수 없습니다. 변종마다 문자표와 규칙이 달라 서로 호환되지 않습니다.btoa / Ascii85는 !부터 u까지(33~117)를 차례로 쓰고, 0 네 바이트를 z 한 글자로 줄입니다.Adobe는 같은 문자표를 쓰되 <~로 시작해 ~>로 끝냅니다. PostScript와 PDF 안에서 만나는 형태입니다.Z85와 RFC 1924는 문자표에서 " ' \ ,를 뺐습니다. 소스 코드 문자열이나 JSON 안에 그대로 넣어도 이스케이프가 필요 없게 하려는 것입니다. btoa 계열에는 이 글자들이 다 들어 있어 그런 곳에 쓰기 나쁩니다.
자투리 처리가 구현의 단골 실수입니다. 입력이 4의 배수가 아닐 때, 인코딩은 0으로 채워 5글자를 만든 뒤 (바이트 수 + 1)글자만 남기고, 디코딩은 u(84)로 채워 4바이트를 만든 뒤 (글자 수 − 1)바이트만 남깁니다. 채우는 값이 서로 반대 방향이어야 원래 바이트가 그대로 돌아옵니다. 둘 다 0으로 채우면 마지막 바이트가 내림되어 값이 작아집니다.같은 이유로 마지막 자투리에는 z 축약을 쓰지 않습니다. 자투리는 길이 정보를 글자 수로 담고 있어서, 축약해 버리면 몇 바이트였는지 알 수 없게 됩니다.Z85는 아예 입력이 4의 배수여야 한다고 정해 자투리 문제를 없앴습니다. 그래서 텍스트를 넣으면 길이가 맞지 않는 일이 잦습니다 — 위에서 «16진수 바이트»로 바꿔 넣어 보세요.
y 축약은 상대가 알아야 쓸 수 있습니다. 공백 네 개를 y 한 글자로 줄이는 규칙은 btoa 원본에는 있었지만 Adobe는 쓰지 않습니다. 모르는 쪽이 받으면 문자표에 없는 글자로 보여 디코딩이 깨지므로, 상대 구현이 지원하는지 확인하고 켜세요.

사용 방법

  1. 1변종을 고릅니다. PDF·PostScript 안에서 가져왔다면 Adobe, ZeroMQ라면 Z85입니다.
  2. 2인코딩과 디코딩 중 무엇을 할지 고릅니다.
  3. 3입력이 텍스트인지 16진수 바이트인지 고릅니다. Z85는 길이가 4의 배수여야 해서 16진수 쪽이 편합니다.
  4. 4아래 표에서 팽창률을 확인하고 같은 데이터를 Base64로 적었을 때와 비교합니다.

자주 묻는 질문

팽창률이 33%가 아니라 25%입니다. Base64는 3바이트를 4문자로 담고 Ascii85는 4바이트를 5문자로 담기 때문입니다. 400바이트를 예로 들면 Base64는 536자, Ascii85는 500자가 됩니다. 대신 쓸 수 있는 문자의 종류가 많아 그대로 넣을 수 없는 곳이 생깁니다.

85⁵ = 4,437,053,125가 2³² = 4,294,967,296보다 크기 때문입니다. 4바이트를 다섯 자리에 담으려면 밑이 85 이상이어야 하는데, 84진법이면 84⁵ = 4,182,119,424로 모자랍니다. 인쇄 가능한 ASCII로 만들 수 있는 가장 조밀한 조합이 4바이트 대 5문자입니다.

문자표와 규칙이 다릅니다. btoa·Adobe 계열은 !(33)부터 u(117)까지를 차례로 쓰고 0 네 바이트를 z 한 글자로 줄이지만, Z85(ZeroMQ RFC 32)는 별도의 85자 문자표를 쓰고 축약이 없으며 입력 길이가 4의 배수여야 합니다. 서로 호환되지 않으니 어느 쪽인지 확인하고 골라야 합니다.

따옴표, 역슬래시, 쉼표를 빼기 위해서입니다. 이 글자들이 없으면 소스 코드의 문자열이나 JSON, CSV 안에 결과를 그대로 넣어도 이스케이프가 필요 없습니다. btoa 계열은 33~117을 연속으로 쓰다 보니 " ' \ , 가 모두 들어 있어 그런 곳에 쓰기 나쁩니다.

Adobe 변종이 데이터의 시작과 끝을 표시하는 구분자입니다. PostScript와 PDF 안에서는 어디까지가 인코딩된 데이터인지 알아야 하기 때문에 붙입니다. 이 도구는 btoa로 골라도 붙어 있으면 떼고 읽습니다.

0 네 바이트를 줄여 쓴 것으로, !!!!! 다섯 자 대신 z 한 자만 씁니다. 0이 길게 이어지는 이미지나 바이너리에서 꽤 줄어듭니다. 다만 마지막 자투리 덩어리에는 쓰지 않습니다. 자투리는 몇 바이트였는지를 글자 수로 담고 있어서, 축약해 버리면 길이를 알 수 없게 되기 때문입니다.

인코딩은 0으로 4바이트를 채워 다섯 글자를 만든 뒤 (바이트 수 + 1)글자만 남기고, 디코딩은 반대로 u(85진법의 84)로 다섯 글자를 채워 네 바이트를 만든 뒤 (글자 수 − 1)바이트만 남깁니다. 채우는 값이 서로 반대 방향이어야 원래 바이트가 그대로 돌아옵니다. Z85는 이 문제를 피하려고 입력 길이를 4의 배수로 못박았습니다.

전송되지 않습니다. 변환은 모두 브라우저 안에서 이루어지며 입력값은 이 기기에만 남습니다.

알아두면 좋은 점

  • btoa·Adobe·foldspaces 결과는 파이썬 base64.a85encode, RFC 1924는 base64.b85encode를 정답지로 삼아 값을 그대로 대조했습니다.
  • Z85는 파이썬 표준 라이브러리에 없어 ZeroMQ RFC 32의 시험값(86 4F D2 6F B5 59 F7 5B → HelloWorld)으로 확인했습니다.
  • y 축약(공백 네 개 → y)은 btoa 원본의 확장이며 Adobe는 쓰지 않습니다. 상대 구현이 지원하는지 확인하고 켜세요.
  • 텍스트 입력은 UTF-8로 읽습니다. 디코딩 결과가 UTF-8로 읽히지 않으면 16진수로 보여 줍니다.
  • 입력한 값은 브라우저 안에서만 계산되며 서버로 전송되지 않습니다.

함께 보면 좋은 도구

Base64 변환텍스트를 Base64로 바꾸거나 되돌립니다.Base58텍스트나 16진수를 Base58로 인코딩하고 되돌립니다.Base32 변환텍스트를 Base32(RFC 4648)로 바꾸거나 되돌립니다.문자 인코딩 변환텍스트를 UTF-8 바이트로 바꾸거나, 16진수 바이트를 EUC-KR 등 다양한 인코딩으로 해석해 깨진 글자를 확인합니다.gitignore 판정.gitignore 규칙과 경로를 넣으면 그 파일이 무시되는지, 어느 줄이 마지막으로 이겼는지 알려줍니다.

마지막 검증: 2026년 8월 31일 · 결과는 참고용 추정치입니다.