맨위로가기

Ascii85

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

Ascii85는 이진 데이터를 텍스트로 인코딩하는 데 사용되는 방식이다. btoa, ZMODEM, Adobe, IETF RFC 1924 등 여러 버전이 존재하며, 각기 다른 문자 집합과 인코딩 규칙을 가진다. Ascii85는 4바이트를 5개의 ASCII 문자로 변환하며, 0으로 채워진 데이터를 "z"로 표현하는 압축 기능을 제공한다. 인코딩된 데이터는 이스케이프 문자를 포함할 수 있으며, XML과 같은 마크업 언어에서 호환성 문제가 발생할 수 있다. Base64보다 오버헤드가 적지만, 마크업 언어와의 호환성 문제로 인해 사용에 주의가 필요하다.

더 읽어볼만한 페이지

  • 문자 인코딩 - 유니코드
    유니코드는 세계의 모든 문자를 하나의 컴퓨터 인코딩 표준으로 통합하기 위해 설계되었으며, 유니코드 컨소시엄에 의해 관리되고 UTF-8, UTF-16, UTF-32 등의 부호화 형식을 제공하지만, 일부 문자 표현 문제, 버전 간 비호환성, 레거시 인코딩과의 호환성 문제 등의 과제를 안고 있다.
  • 문자 인코딩 - UTF-8
    UTF-8은 유니코드 문자를 표현하는 가변 길이 문자 인코딩 방식으로, ASCII 코드와 호환성을 유지하며 다양한 언어의 문자를 표현할 수 있도록 설계되었지만, 보안 문제점과 공간 효율성 측면에서 단점을 가진다.

2. 역사

btoa는 전체 그룹을 인코딩하고 (필요에 따라 소스를 패딩), "xbtoa Begin" 접두사 줄과 "xbtoa End" 접미사 줄, 원래 파일 길이(10진수 및 16진법)와 세 개의 32비트 체크섬을 사용했다. 디코더는 그룹의 어느 부분이 패딩인지 확인하기 위해 파일 길이를 사용해야 했다. btoa 인코딩에 대한 초기 제안은 ASCII 공백 문자부터 "t"까지를 포함하는 인코딩 알파벳을 사용했지만, "일부 메일러의 문제(후행 공백 제거)"를 피하기 위해 "!"부터 "u"까지의 인코딩 알파벳으로 대체되었다.[3] 이 프로그램은 또한 모든 0 그룹에 대한 특수 "z" 단축형을 도입했고, 버전 4.2는 모든 ASCII 공백 문자(0x20202020) 그룹에 대한 "y" 예외를 추가했다.

ZMODEM은 미리 압축된 8비트 데이터 파일을 7비트 데이터 채널을 통해 전송할 때 "ZMODEM Pack-7 인코딩"을 사용하는데, 이는 4개의 옥텟 그룹을 Ascii85와 유사하거나 동일한 방식으로 5개의 인쇄 가능한 ASCII 문자의 그룹으로 인코딩한다.[4]

Adobe는 btoa 인코딩을 채택했지만 약간의 변경을 가하여 Ascii85라는 이름을 부여했다. 사용된 문자는 ASCII 문자 33(`!`)부터 117(`u`)까지(기수 0부터 84까지를 나타냄)이며, 문자 `z`(32비트 0 값을 나타내는 특수 경우)와 공백은 무시된다. Adobe는 Ascii85로 인코딩된 문자열의 끝을 표시하기 위해 구분자 "~>"를 사용하며, 마지막 그룹을 잘라내어 길이를 나타낸다. 소스 바이트의 마지막 블록에 4바이트 미만이 포함된 경우, 인코딩 전에 최대 3개의 널 바이트로 블록을 채운 후, 인코딩이 끝나면 패딩으로 추가된 바이트 수만큼 출력의 끝에서 제거한다. 디코딩 시에는 반대가 적용된다. 마지막 블록은 Ascii85 문자 `u`로 5바이트까지 채워지고, 패딩으로 추가된 바이트 수만큼 출력의 끝에서 생략된다.

패딩은 임의적인 것이 아니다. 이진수를 64진수로 변환하는 것은 비트를 재그룹화할 뿐 변경하거나 순서를 바꾸지 않는다. 이진수를 85진수로 변환할 때(85는 2의 거듭제곱이 아님) 높은 비트는 낮은 순서의 85진수 숫자에 영향을 미치며 그 반대도 마찬가지다. 인코딩 시 이진수 로우를 (0 비트로) 채우고, 디코딩 시 85진수 값을 하이로 (`u`로) 채우는 것은 높은 순서의 비트가 보존되도록 보장한다. Ascii85로 인코딩된 블록에서는 5자 블록 중간을 포함하여 어디에서나 공백 및 줄 바꿈 문자가 있을 수 있지만, 자동으로 무시되어야 한다. Adobe의 사양은 `y` 예외를 지원하지 않는다.

1996년 4월 1일에 게시된 정보 RFC 1924는 로버트 엘즈가 작성한 "IPv6 주소의 간결한 표현"으로, 만우절 농담으로 IPv6 주소를 85진법으로 인코딩하는 것을 제안한다. 이는 128비트 숫자에 대한 모든 산술 연산을 수행하여 4개의 32비트 그룹으로 나누는 대신 단일 20자리 85진법 숫자(내부 공백은 허용되지 않음)로 변환하는 방식을 제안한다.[1] 제안된 문자 집합은 순서대로 0–9, A–Z, a–z이며, 그 다음 23개의 문자 !#$%&()*+-;<=>?@^_`

~이다. 표현 가능한 가장 높은 주소인 2128−1 = 74×8519 + 53×8518 + 5×8517 + ... 는 =r54lj&NUUO~Hi%c2ym0로 인코딩된다.[1] 이 문자 집합은 "',./:[\]  문자를 제외하므로 JSON 문자열에서 사용하기에 적합하다(여기서 " 및 \는 이스케이프가 필요함). 그러나 SGML 기반 프로토콜, 특히 XML의 경우 문자열 이스케이프가 여전히 필요할 수 있다(<, > 및 &를 수용하기 위해).[1]

2. 1. btoa 버전

btoa는 원래 전체 그룹을 인코딩(필요에 따라 소스를 패딩)했으며, "xbtoa Begin" 접두사 줄과 "xbtoa End" 접미사 줄, 그리고 원래 파일 길이(10진수 및 16진법)와 세 개의 32비트 체크섬이 있었다. 디코더는 그룹의 어느 부분이 패딩인지 확인하기 위해 파일 길이를 사용해야 했다. btoa 인코딩에 대한 초기 제안은 ASCII 공백 문자부터 "t"까지를 포함하는 인코딩 알파벳을 사용했지만, "일부 메일러의 문제(후행 공백 제거)"를 피하기 위해 "!"부터 "u"까지의 인코딩 알파벳으로 대체되었다.[3] 이 프로그램은 또한 모든 0 그룹에 대한 특수 "z" 단축형을 도입했다. 버전 4.2는 모든 ASCII 공백 문자(0x20202020) 그룹에 대한 "y" 예외를 추가했다.

2. 2. ZMODEM 버전

ZMODEM 프로그램이 미리 압축된 8비트 데이터 파일을 7비트 데이터 채널을 통해 전송할 때 "ZMODEM Pack-7 인코딩"을 사용한다. "ZMODEM Pack-7 인코딩"은 4개의 옥텟 그룹을 Ascii85와 유사하거나 동일한 방식으로 5개의 인쇄 가능한 ASCII 문자의 그룹으로 인코딩한다.[4]

2. 3. Adobe 버전

Adobe는 기본적인 btoa 인코딩을 채택했지만 약간의 변경을 가하여 Ascii85라는 이름을 부여했다. 사용된 문자는 ASCII 문자 33(`!`)부터 117(`u`)까지(기수 0부터 84까지를 나타냄)이며, 문자 `z`(32비트 0 값을 나타내는 특수 경우)와 공백은 무시된다. Adobe는 Ascii85로 인코딩된 문자열의 끝을 표시하기 위해 구분자 "~>"를 사용하며, 마지막 그룹을 잘라내어 길이를 나타낸다. 소스 바이트의 마지막 블록에 4바이트 미만이 포함된 경우, 인코딩 전에 최대 3개의 널 바이트로 블록을 채운다. 인코딩 후, 패딩으로 추가된 바이트 수만큼 출력의 끝에서 제거한다.

디코딩 시에는 반대가 적용된다. 마지막 블록은 Ascii85 문자 `u`로 5바이트까지 채워지고, 패딩으로 추가된 바이트 수만큼 출력의 끝에서 생략된다(예시 참조).

패딩은 임의적인 것이 아니다. 이진수를 64진수로 변환하는 것은 비트를 재그룹화할 뿐 변경하거나 순서를 바꾸지 않는다(이진수의 높은 비트는 64진수 표현의 낮은 비트에 영향을 미치지 않음). 이진수를 85진수로 변환할 때(85는 2의 거듭제곱이 아님) 높은 비트는 낮은 순서의 85진수 숫자에 영향을 미치며 그 반대도 마찬가지다. 인코딩 시 이진수 로우를 (0 비트로) 채우고, 디코딩 시 85진수 값을 하이로 (`u`로) 채우는 것은 높은 순서의 비트가 보존되도록 보장한다(이진수의 0 패딩은 작은 추가가 포착되고 높은 비트로 "캐리"가 없도록 충분한 공간을 제공한다).

Ascii85로 인코딩된 블록에서는 5자 블록 중간을 포함하여 어디에서나 공백 및 줄 바꿈 문자가 있을 수 있지만, 자동으로 무시되어야 한다.

Adobe의 사양은 `y` 예외를 지원하지 않는다.

2. 4. IETF RFC 1924 버전

1996년 4월 1일에 게시된 정보 RFC 1924는 로버트 엘즈가 작성한 "IPv6 주소의 간결한 표현"으로, 만우절 농담으로 IPv6 주소를 85진법으로 인코딩하는 것을 제안한다. 이는 위에서 사용된 방식과 달리 85개의 다른 ASCII 문자를 제안하고, 128비트 숫자에 대한 모든 산술 연산을 수행하여 4개의 32비트 그룹으로 나누는 대신 단일 20자리 85진법 숫자(내부 공백은 허용되지 않음)로 변환하는 방식을 제안한다.[1]

제안된 문자 집합은 순서대로 0–9, A–Z, a–z이며, 그 다음 23개의 문자 !#$%&()*+-;<=>?@^_`

~이다. 표현 가능한 가장 높은 주소인 2128−1 = 74×8519 + 53×8518 + 5×8517 + ... 는 =r54lj&NUUO~Hi%c2ym0로 인코딩된다.[1]

이 문자 집합은 "',./:[\]  문자를 제외하므로 JSON 문자열에서 사용하기에 적합하다(여기서 " 및 \는 이스케이프가 필요함). 그러나 SGML 기반 프로토콜, 특히 XML의 경우 문자열 이스케이프가 여전히 필요할 수 있다(<, > 및 &를 수용하기 위해).[1]

3. 기본 원리

이진 데이터를 텍스트로 인코딩해야 하는 이유는, 사람이 읽을 수 있는 텍스트만 전송하도록 설계된 기존의 통신 프로토콜을 통해 임의의 이진 데이터를 통신해야 할 필요성이 있기 때문이다. 이러한 통신 프로토콜은 7비트만 사용하고, ASCII 제어 코드를 제외하면 95종류의 ASCII 인쇄 가능 문자만이 안전하게 통신에 사용될 수 있다.

4바이트(32비트)는 232 = 4,294,967,296 가지의 값을 표현할 수 있다. 85진법을 사용하면 5자리 숫자(855 = 4,437,053,125)로 이 값을 모두 표현할 수 있는데, 이는 84진법이 5자리로 표현할 수 있는 값(4,182,119,424)보다 크기 때문이다. 따라서 85는 4바이트를 5자리로 표현할 수 있는 최소값이 된다.

Ascii85 인코딩은 4바이트 데이터를 빅 엔디안 방식으로 묶어 32비트 정수로 해석하고, 이를 85진법으로 변환한다. 각 자리는 33을 더해 ASCII 인쇄 가능 문자 '!' (33)부터 'u' (117)까지의 문자로 표현된다. 모든 비트가 0인 블록은 "!!!!!" 대신 'z'로 압축된다.

복호화 과정에서 Ascii85로 표현된 "s8W-!"보다 큰 값은 오류로 처리되며, 'z' 문자가 블록 중간에 있는 경우도 오류이다. 공백 문자는 무시된다.

Ascii85는 백슬래시나 아포스트로피 같은 이스케이프 문자를 포함할 수 있어, 프로그래밍 언어나 통신 프로토콜에서 문제가 될 수 있다.[5] Z85와 같이 이러한 문제를 해결하기 위해 설계된 다른 인코딩 방식도 존재한다.

3. 1. 인코딩 과정

Ascii85 인코딩은 4바이트의 이진 데이터를 5개의 ASCII 문자로 변환하는 과정이다. 이 과정은 다음과 같이 진행된다.

1. 32비트 값 얻기: 4바이트 데이터를 빅 엔디안 방식으로 묶어 32비트 부호 없는 정수로 변환한다.

2. 85진법 변환: 32비트 값을 85진법으로 변환한다. 85로 반복해서 나누고 나머지를 취하는 방식이다.

3. ASCII 문자로 변환: 85진법으로 표현된 각 자리(0~84)에 33을 더하여 ASCII 인쇄 가능 문자 '!' (33)부터 'u' (117)까지의 문자로 변환한다.

4. 특수 처리 ('z'): 모든 비트가 0인 블록은 "!!!!!" 대신 'z' 문자 하나로 압축하여 표현한다.

예를 들어, "Man i"라는 문자열을 Ascii85로 변환하는 과정은 다음과 같다.

텍스트 내용Man i
ASCII779711032105
비트 패턴0|1|0|0|1|1|0|1|0|1|1|0|0|0|0|1|0|1|1|0|1|1|1|0|0|0|1|0|0|0|0|00|1|1|0|1|0|0|1
32비트 값1,298,230,816 = 24×854 + 73×853 + 80×852 + 78×85 + 611701604969
85진수 (+33)24 (57)73 (106)80 (113)78 (111)61 (94)...
ASCII9jqo^...



마지막 4바이트가 4바이트 미만일 경우 0으로 채운 후 인코딩을 수행하고, 인코딩된 결과에서 채워진 0의 개수만큼 문자를 제거한다.

복호화는 위 과정을 역순으로 수행한다. 단, 마지막 5문자는 'u'로 채워서 계산하고, 추가된 'u'의 개수만큼 출력 결과에서 마지막 바이트를 제거한다.

Ascii85 인코딩은 백슬래시나 아포스트로피와 같은 이스케이프 문자를 포함할 수 있다는 단점이 있다. 이러한 이스케이프 문자는 프로그래밍 언어나 통신 프로토콜에서 특별한 의미를 가지기 때문에 문제가 될 수 있다.[5]

3. 2. 디코딩 과정

디코딩 시에는 인코딩 과정의 반대가 적용된다. 마지막 블록은 Ascii85 문자 `u`로 5바이트까지 채워지고, 패딩으로 추가된 바이트 수만큼 출력의 끝에서 생략된다.

예를 들어, 인코딩된 텍스트의 마지막 부분은 다음과 같다.

```

...F*2M7/c~>

```

이것을 디코딩하는 과정은 다음과 같다.

1. 마지막 블록 채우기: 마지막 블록 `"/c"`는 2개의 문자만 가지고 있으므로, 5개의 문자가 되도록 `u` 3개를 추가하여 `"/cuuu"`로 만든다.

2. 베이스 85로 변환: 각 문자를 베이스 85 값으로 변환한다 (ASCII 값에서 33을 뺌).

3. 32비트 값 계산: 베이스 85 값들을 사용하여 32비트 정수 값을 계산한다.

4. 바이너리 변환: 32비트 정수 값을 바이너리 비트 패턴으로 변환한다.

5. ASCII 변환: 바이너리 비트 패턴을 8비트씩 묶어 ASCII 코드로 변환하고, 해당 ASCII 코드에 해당하는 문자를 얻는다.

6. 패딩 제거: 원래 인코딩 과정에서 3바이트가 추가되었으므로, 디코딩 결과의 마지막 3바이트를 제거한다.

이 과정을 표로 나타내면 다음과 같다.

ASCII/cuuu
베이스 85 (+33)14 (47)66 (99)84 (117)84 (117)84 (117)
32비트 값771,955,124 = 14×854 + 66×853 + 84×852 + 84×85 + 84
비트 패턴00101110000000110001100110110100
ASCII46325180
텍스트 내용.ETXEM´ (확장 ASCII)



패딩으로 추가되었던 3바이트 (''ETX'', ''EM'', ''´'')를 제거하면, 최종 디코딩 결과는 마침표('''.''')가 된다.

Ascii85로 인코딩된 블록에서는 5자 블록 중간을 포함하여 어디에서나 공백 및 줄 바꿈 문자가 있을 수 있지만, 디코딩 과정에서 자동으로 무시된다. Adobe의 사양은 `y` 예외를 지원하지 않는다.

4. 한계 및 문제점

Ascii85는 4바이트를 5개의 ASCII 문자로 표현하여 이진 데이터를 텍스트 형식으로 인코딩하는 방식이다. 이 방식은 95개의 인쇄 가능한 ASCII 문자만을 사용할 수 있는 환경에서 이진 데이터를 전송하기 위해 고안되었다. 85진법을 사용하면 5자리로 32비트 값을 충분히 표현할 수 있어 85가 기수로 선택되었다.

인코딩 과정에서 모든 데이터가 0인 경우는 예외적으로 "z" 한 문자로 압축한다. Ascii85는 백슬래시(\\)나 아포스트로피(')와 같은 이스케이프 문자를 포함할 수 있어, 일부 프로그래밍 언어나 프로토콜에서 문제를 일으킬 수 있다. 이러한 문자는 해당 환경에서 특별한 의미를 가지기 때문이다. 반면, Z85와 같은 다른 base-85 인코딩은 소스 코드에서도 안전하도록 설계되었다.[5]

4. 1. 호환성 문제

Ascii85 인코딩은 7비트 및 8비트 MIME와 호환되며, Base64보다 오버헤드가 적다.[2]

Ascii85의 잠재적인 호환성 문제 중 하나는 사용되는 일부 문자가 XML 또는 SGML과 같은 마크업 언어에서 중요한 의미를 갖는다는 것이다. 이러한 문서에 Ascii85 데이터를 포함하려면 따옴표, 꺾쇠 괄호, 앰퍼샌드를 이스케이프해야 할 수 있다.

5. 활용 예시

Ascii85는 주로 포스트스크립트와 PDF 파일 형식에서 사용된다.

5. 1. 인코딩 예시

Ascii85 인코딩은 4바이트의 데이터를 5개의 ASCII 문자로 표현하는 방식이다. 빅 엔디안 방식을 사용하여 32비트 이진수를 85로 반복적으로 나누어 나머지를 취하는 방식으로 5개의 기수-85 숫자로 변환한다. 각 숫자는 33을 더하여 ASCII 인쇄 가능 문자로 인코딩된다. (ASCII 문자 33(!)에서 117(u)까지).

데이터 압축을 위해 모두 0인 데이터 그룹은 `!!!!!` 대신 단일 문자 `z`로 인코딩하는 예외가 적용된다.

다음은 토마스 홉스의 저서 ''리바이어던''의 인용구를 Ascii85로 인코딩하는 예시이다.

'''인용구:'''

''인간은 이성뿐만 아니라 다른 동물들과는 다른 독특한 열정, 즉 마음의 욕망으로 구별된다. 이는 끊임없이 지식을 생성하는 기쁨을 통해 어떤 육체적인 쾌락보다 짧은 격정을 뛰어넘는다.''

'''Ascii85 인코딩 결과:'''

```text

9jqo^BlbD-BleB1DJ+*+F(f,q/0JhKFCj@.4Gp$d7F!,L7@<6@)/0JDEF
DJ+*.@<*K0@<6L(Df-\0Ec5e;DffZ(EZee.Bl.9pF"AGXBPCsi+DGm>@3BB/F*&OCAfu2/AKYi(

DIb:@FD,*)+C]U=@3BN#EcYf8ATD3s@q?d$AftVqCh[NqF-FD5W8ARlolDIal(

DIdu

D.RTpAKYo'+CT/5+Cei#DII?(E,9)oF*2M7/c

```

'''변환 과정:'''

텍스트 내용Man ...sure
ASCII779711032...115117114101
비트 패턴01001101011000010110111000100000...01110011011101010111001001100101
32비트 값1,298,230,816 = 24×854 + 73×853 + 80×852 + 78×85 + 61...1,937,076,837 = 37×854 + 9×853 + 17×852 + 44×85 + 22
Base 85 (+33)24 (57)73 (106)80 (113)78 (111)61 (94)...37 (70)9 (42)17 (50)44 (77)22 (55)
ASCII9jqo^...F*2M7



마지막 4바이트 튜플이 완전하지 않은 경우, 최대 3개의 0 바이트를 추가하여 채운다. 인코딩 후에는 추가된 0 바이트의 수만큼 출력에서 제거한다.

텍스트 내용.\0\0\0
ASCII46000
비트 패턴00101110000000000000000000000000
32비트 값771,751,936 = 14×854 + 66×853 + 56×852 + 74×85 + 46
Base 85 (+33)14 (47)66 (99)56 (89)74 (107)46 (79)
ASCII/cYkO



위 예시에서는 3바이트의 패딩이 추가되었으므로, 마지막 세 문자 'YkO'는 출력에서 생략된다.

디코딩은 인코딩의 역순으로 수행된다. 마지막 5튜플은 Ascii85 문자 `u`로 채워지고, 패딩으로 추가된 바이트 수만큼 출력의 끝에서 생략된다.

ASCII/cuuu
Base 85 (+33)14 (47)66 (99)84 (117)84 (117)84 (117)
32비트 값771,955,124 = 14×854 + 66×853 + 84×852 + 84×85 + 84
비트 패턴00101110000000110001100110110100
ASCII46325180
텍스트 내용.ETXEM´ (확장 ASCII)



위 예시에서는 입력이 세 개의 'u' 바이트로 채워졌으므로, 출력의 마지막 세 바이트는 무시되고 원래 마침표로 끝나게 된다.

이 예시에서는 입력 문장에 4개의 연속된 0 바이트가 없으므로 'z' 약어는 사용되지 않았다.

5. 2. 디코딩 예시

Ascii85 디코딩은 인코딩 과정의 역순으로 진행된다. Adobe의 Ascii85는 인코딩된 문자열의 끝을 "~>" 구분자로 표시하고, 마지막 그룹의 길이를 나타내기 위해 잘라내기를 사용한다. 디코딩 시에는 마지막 블록에 Ascii85 문자 'u'를 최대 5바이트까지 채우고, 패딩으로 추가된 바이트 수만큼 출력의 끝에서 생략한다.[1]

토마스 홉스의 ''리바이어던'' 인용문을 예시로 디코딩 과정을 살펴보자.

```text

<~9jqo^BlbD-BleB1DJ+*+F(f,q/0JhKFCj@.4Gp$d7F!,L7@<6@)/0JDEF
O@3BB/F*&OCAfu2/AKY

i(DIb:@FD,*)+C]U=@3BN#EcYf8ATD3s@q?d$AftVqCh[NqF-FD5W8ARlolDIa

l(DId
>uD.RTpAKYo'+CT/5+Cei#DII?(E,9)oF*2M7/c~>

```

위 텍스트는 "<~" 와 "~>" 로 둘러싸여 있으므로 Ascii85로 인코딩된 텍스트임을 알 수 있다.

인코딩된 텍스트를 디코딩하는 과정은 다음과 같다.[1]

ASCII9jqo^...F*2M7
베이스 85 (+33)24 (57)73 (106)80 (113)78 (111)61 (94)...37 (70)9 (42)17 (50)44 (77)22 (55)
32비트 값1,298,230,816 = 24×854 + 73×853 + 80×852 + 78×85 + 61...1,937,076,837 = 37×854 + 9×853 + 17×852 + 44×85 + 22
비트 패턴1|0|0|1|1|0|1|0|1|1|0|0|0|0|1|0|1|1|0|1|1|1|0|0|0|1|0|0|0|0|0|0...1|1|1|0|0|1|1|0|1|1|1|0|1|0|1|0|1|1|1|0|0|1|0|0|1|1|0|0|1|0|1
ASCII779711032...115117114101
텍스트 내용Man ...sure



마지막 블록은 5개의 Ascii85 문자 'u'로 채워 계산한다.[1]

ASCII/cuuu
베이스 85 (+33)14 (47)66 (99)84 (117)84 (117)84 (117)
32비트 값771,955,124 = 14×854 + 66×853 + 84×852 + 84×85 + 84
비트 패턴0|1|0|1|1|1|0|0|0|0|0|0|0|1|1|0|0|0|1|1|0|0|1|1|0|1|1|0|1|0|0
ASCII46325180
텍스트 내용.[ ETX ][ EM ]´ (확장 ASCII)



입력의 마지막이 'u'로 채워졌기 때문에, 출력의 마지막 3바이트는 무시하고 원문의 마침표까지만 복호화 결과로 사용한다.

6. 다른 인코딩 방식과의 비교

이진-텍스트 인코딩은 사람이 읽을 수 있는(human-readable) 문자만을 전송할 수 있는 기존 통신 프로토콜 위에서 이진 데이터를 다루기 위해 필요했다. 이러한 환경에서 문자는 7비트만을 사용하고 그마저도 일부 제어 문자를 빼야 하므로 데이터 전송에 사용할 수 있는 문자는 95개뿐이다.

4바이트는 232 = 4,294,967,296가지의 값을 가지고, 5자리 85진수(:en:radix)는 855 = 4,437,053,125가지의 값이 가능하므로 이걸로 32비트 값을 충분히 표현할 수 있다. 5자리의 84진수는 845 = 4,182,119,424가지 값만을 가지기 때문에 85가 5자리로 4바이트를 표현해 낼 수 있는 최소값이라 이것이 선택되었다.

Ascii85의 한 가지 단점은 인코딩 데이터가 백슬래시나 아포스트로피 같은 이스케이프 문자를 포함할 수 있다는 것인데, 이것들은 많은 프로그래밍 언어나 일부 문자 기반의 프로토콜에서 특별한 의미를 가지므로 문제가 될 수 있다. Z85는 소스 코드에서도 안전하도록 설계된 것이다.[6]

참조

[1] 웹사이트 "[PATCH] binary patch." http://www.gelato.un[...] 2006-05-05
[2] 문서 "32/Z85" http://rfc.zeromq.or[...] ZeroMQ RFC
[3] 웹사이트 Re: COMPRESSING of binary data into mailable ASCII Re: Encoding of binary data into mailable ASCII https://groups.googl[...] 2015-04-11
[4] 웹사이트 Recent Developments in ZMODEM http://www.omen.com/[...] 2013-05-14
[5] 웹사이트 32-Z85 · ZeroMQ RFC http://rfc.zeromq.or[...] the ZeroMQ RFC project 2016-12-23
[6] 문서 Z85 - ZeroMQ Base-85 Encoding Algorithm http://rfc.zeromq.or[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com