ASCII85

Ascii85

Ascii85는 Base85라고도 불리며 Paul E에 의해 개발된 바이너리-to-text 인코딩의 한 형태입니다.Btoa 유틸리티의 Rutter.5개의 ASCII 문자를 사용하여 4바이트의 바이너리 데이터를 나타냅니다(부호화 크기 작성).원본보다 1⁄4 큰 (ASCII 문자당8비트라고 가정할 경우), 4개의 문자를 사용하여 3바이트의 데이터를 나타내는 uuencode 또는 Base64보다 효율적입니다(ASCII 문자당8비트 증가, 1⁄3 증가).

그 주된 현대적 용도는 Adobe의 PostScript와 Portable Document Format 파일 형식과 [1]Git에서 사용되는 바이너리 파일의 패치 인코딩이다.

개요

바이너리-to-text 인코딩의 기본적인 필요성은 인간이 읽을 수 있는 영어 텍스트만 전송하도록 설계된 기존 통신 프로토콜을 통해 임의의 바이너리 데이터를 통신해야 하는 필요성에서 비롯됩니다.이러한 통신 프로토콜은 7비트만 안전할 수 있고(그리고 그 안에서 특정 ASCII 제어 코드를 피함), 특정 최대 간격으로 줄 바꿈이 필요할 수 있으며 공백을 유지할 수 없습니다.따라서 인쇄 가능한 94개의 ASCII 문자만 데이터 전송에 "안전"합니다.

85는 n 2564 256인5 n의 최소 적분값입니다.따라서 4바이트의 시퀀스는 적어도85개의 다른 기호를 사용할 수 있는 한 5개의 기호로 부호화할 수 있습니다.(5개의 기수 85자리는 0 ~437 053[2][3] 124의 정수를 나타낼 수 있으며, 4바이트 시퀀스를 모두 나타낼 수 있습니다.)

부호화

부호화에서는 4바이트의 각 그룹이 32비트 바이너리 수치로 간주됩니다.이것은 가장 중요한 바이트입니다(ASCII85는 빅엔디안 규칙을 사용합니다).이 값은 85로 나누어 나머지를 5 기수-85 자리수로 반복하여 변환됩니다.그 후, 각 자리수(가장 중요한 자리수)는, ASCII 문자 33(가장 중요한 자리수)에 33을 더하는 것으로, ASCII 인쇄 가능 문자로서 부호화됩니다.!) ~ 117 (u).

올제로 데이터는 매우 일반적이기 때문에 데이터 압축을 위해 예외가 발생하며 올제로 그룹은 단일 문자로 인코딩됩니다.z대신!!!!!.

2 - 1보다32 큰 값으로 디코딩하는 문자 그룹(로 인코딩됨)s8W-!)는 디코딩 에러를 발생시킵니다.z그룹 중간에 있는 캐릭터들.문자 사이의 공백은 무시되며 행 길이 제한을 수용하기 위해 어디에서나 발생할 수 있습니다.

제한 사항

원래 사양에서는 4바이트의 배수인 스트림만 부호화할 수 있습니다.

인코딩된 데이터에는 많은 프로그래밍 언어 및 일부 텍스트 기반 프로토콜(예: 좌각 브래킷)에서 특별한 의미를 갖는 문자가 포함될 수 있습니다.<, 백슬래시\, 및 작은따옴표와 큰따옴표'&"Z85와 같은 기타 base-85 부호화 RFC1924는 소스 [4]코드에서 안전하도록 설계되어 있습니다.

역사

btoa 버전

원래의 btoa 프로그램은 항상 "xbtoa Begin" 프리픽스 행과 "xbtoa End" 서픽스 행으로 완전한 그룹(필요에 따라 소스 패딩)을 인코딩하고, 그 뒤에 원래 파일 길이(10진수 및 16진수)와 3개의 32비트 체크섬을 이어집니다.디코더는 그룹의 패딩 양을 확인하기 위해 파일 길이를 사용해야 합니다.btoa 인코딩의 초기 제안에서는 "t"부터 "u"까지의 ASCII 공백 문자로 시작하는 인코딩 알파벳을 사용했지만 "일부 메일러 문제(후행 공백 삭제)"[5]를 방지하기 위해 "!"에서 "u"까지의 인코딩 알파벳으로 대체되었습니다.이 프로그램에서는, 「스페셜」도 소개했습니다.zall-zero 그룹의 단축형식.버전 4.2에서는y모든 ASCII 공백 문자 그룹에 대한 예외(0x2020).

ZMODEM 버전

「ZMODEM Pack-7 인코딩」은, 4 옥텟의 그룹을, 인쇄 가능한 ASCII 문자 5 문자의 그룹으로 인코딩 합니다.이것은, ASCII 85 와 같은, 또는 같은 방식일 가능성이 있습니다.ZMODEM 프로그램이 7비트 데이터 채널을 통해 사전 압축된 8비트 데이터 파일을 전송할 때 "ZMODEM Pack-7 인코딩"[6]을 사용합니다.

Adobe 버전

Adobe는 기본 btoa 인코딩을 채택했지만 약간의 변경을 가하여 Ascii85라는 이름을 붙였습니다.사용되는 문자는 ASCII 문자 33 입니다(!) ~ 117 (u) 포함(기본 85자리 0 ~84를 나타냄), 문자와 함께 지정합니다.z(32비트 0 값을 나타내는 특수한 경우) 및 공백은 무시됩니다.Adobe는 구분 기호를 사용합니다.~>ASCII85로 인코딩된 문자열의 끝을 표시하고 마지막 그룹을 잘라 길이를 나타냅니다.소스 바이트의 마지막 블록이 4바이트 미만일 경우 부호화 전에 블록에 최대 3개의 늘바이트가 채워집니다.부호화 후 패딩으로 추가된 바이트 수가 출력 끝에서 삭제됩니다.

디코딩할 때는 그 반대가 적용됩니다.마지막 블록은 Ascii85 문자로 5바이트로 패딩됩니다.upadding으로 추가된 바이트 수는 출력의 끝에서 생략됩니다(예 참조).

메모: 패딩은 임의적이지 않습니다.2진수에서 64진수로 변환하면 비트만 다시 그룹화되며 비트 또는 비트 순서는 변경되지 않습니다(2진수에서 높은 비트는 64진수 표현에서 낮은 비트에 영향을 주지 않습니다).2진수를 base85(85는 2의 거듭제곱이 아님)로 변환할 때 하이비트는 하위 base85 자리수에 영향을 줍니다.base85 값을 높게 인코딩 및 채우는 동안 바이너리 낮음(0비트) 패딩us) 디코딩에서는 상위 비트가 유지되도록 보장합니다(바이너리의 제로 패딩은 작은 추가가 트랩되고 상위 비트에 대한 "캐리"가 발생하지 않도록 충분한 공간을 제공합니다).

ASCII85로 인코딩된 블록에서는 공백 및 줄 바꿈 문자는 5자 블록의 중간을 포함하여 어디에나 존재할 수 있지만 무시해야 합니다.

Adobe의 사양은y예외.

ASCII85의 예

토마스 홉스의 '리바이어던'에서 인용한 내용:

인간은 이성뿐만 아니라 다른 동물과의 이 특이한 열정, 즉 마음의 욕망으로 구분된다. 지속적이고 끈질긴 지식의 세대에 대한 기쁨의 끈기는 어떤 육체적 쾌락의 짧은 열망을 능가한다.

처음에 US-ASCII 를 사용해 부호화된 경우는, 다음과 같이 ASCII 85 로 재인코딩 할 수 있습니다.

9jqo^BlbD-BleB1DJ+*+F(f,q/0JhKF<Cj@.4Gp$d7F!,L7@<6@/0JDEF<G%><+EV:2F!,O< 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<G:8+EV:+Cf>-FD5W8AROLDIAL(DID <j@<?3r@:F%a+D58')ATD4$Bl@l3De:-DJ'8ARoFb/0JMK@qB4^F!,R <AKZ&-DfTqBG%G>u D.RTPAKYO'+CT/5+CEI#DII?(E,9)oF*2M7/c
텍스트 내용 M a n ... s u r e
ASCII 77 97 110 32 ... 115 117 114 101
비트 패턴 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 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
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
베이스 85(+33) 24 (57) 73 (106) 80 (113) 78 (111) 61 (94) ... 37 (70) 9 (42) 17 (50) 44 (77) 22 (55)
ASCII 9 j q o ^ ... F * 2 M 7

마지막 4개의 태플은 완전하지 않기 때문에 3개의 제로 바이트로 패딩해야 합니다.

텍스트 내용 . \0 \0 \0
ASCII 46 0 0 0
비트 패턴 0 0 1 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
32비트 값 771,751,936 = 14 × 854 + 66 × 853 + 56 × 852 + 74 × 85 + 46
베이스 85(+33) 14 (47) 66 (99) 56 (89) 74 (107) 46 (79)
ASCII / c Y k O

3바이트의 패딩을 추가해야 했기 때문에 출력에서 3개의 최종 문자 'YkO'가 생략됩니다.

마지막 5개의 태플이 'u'자로 채워진 것을 제외하고 디코딩은 반대로 이루어집니다.

ASCII / c u u u
베이스 85(+33) 14 (47) 66 (99) 84 (117) 84 (117) 84 (117)
32비트 값 771,955,190 = 14 × 854 + 66 × 853 + 84 × 852 + 84 × 85 + 84
비트 패턴 0 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
ASCII 46 3 25 180
텍스트 내용 . [ETX] [EM] 」(확장 ASCII)

입력은 3개의 'u' 바이트로 패딩되어야 했기 때문에 출력의 마지막 3바이트는 무시되고 원래 주기가 됩니다.

입력문에는 연속되는 4개의 0바이트가 포함되어 있지 않기 때문에 이 예에서는 'z'의 약어를 사용하지 않습니다.

호환성.

ASCII85 인코딩은 Base64보다 오버헤드가 적으면서7비트 및 8비트 MIME과 호환성이 있습니다.

ASCII85의 잠재적인 호환성 문제 중 하나는 XML이나 SGML 등의 마크업 언어에서 사용되는 문자 중 일부가 중요한 것입니다.이러한 문서에 ASCII85 데이터를 포함하려면 따옴표, 꺾쇠 괄호 및 앰퍼샌드를 이스케이프해야 합니다.

RFC 1924 버전

1996년 4월 1일에 발행된 정보 RFC 1924: Robert Elz의 "A Compact Representation of IPv6 Addresses"는 IPv6 주소의 base-85 인코딩을 제안하고 있습니다.이것은, 상기의 스킴과는 다른 85 문자의 ASCII 문자 세트를 제안해, 128 비트 번호에 대해서 모든 연산을 실시하는 것을 제안해, 그것을 4개의 32 비트 그룹으로 분할하는 것이 아니라, 20 자리수의 base-85 번호(내부 공백은 사용할 수 없습니다)로 변환하는 것을 제안하고 있는 점에서 다릅니다.

제안된 문자 집합은 순서대로 다음과 같습니다.0–9,A–Z,a–z, 그리고 23글자!#$%&()*+-;<=>?@^_`{ }~가능한 가장 높은 대표 주소인 2-1128 = 74×8519 + 53×8518 + 5×8517 + ...는 다음과 같이 인코딩됩니다.=r54lj&NUUO~Hi%c2ym0.

이 문자 집합은 문자를 제외합니다."',./:[\] JSON 문자열에서 사용하기에 적합합니다(여기서)."그리고.\탈출이 필요합니다.)그러나, 특히 XML을 포함한 SGML 기반 프로토콜의 경우, 문자열 이스케이프는 여전히 필요할 수 있습니다.<,>그리고.&).

「 」를 참조해 주세요.

레퍼런스

  1. ^ Junio Hamano (May 5, 2006). "binary patch". Archived from the original on 2020-07-26.
  2. ^ 437 053 124 = 855 - 1
  3. ^ 4 294 967 296 = 2564 = 232
  4. ^ "Z85 - ZeroMQ Base-85 인코딩 알고리즘"
  5. ^ Orost, Joe. "Re: COMPRESSING of binary data into mailable ASCII Re: Encoding of binary data into mailable ASCII". Google Groups. Retrieved 11 April 2015.
  6. ^ Chuck Forsberg. "ZMODEM Pack-7은 4바이트를 5개의 인쇄 문자로 묶습니다."

외부 링크