바이너리-텍스트 부호화

Binary-to-text encoding

바이너리-to-text 인코딩은 데이터를 일반 텍스트로 인코딩하는 것입니다.보다 정확하게는, 인쇄 가능한 문자의 시퀀스에 있어서의 바이너리 데이터의 부호화입니다.이러한 인코딩은 채널이 바이너리 데이터(이메일이나 NNTP 등)를 허용하지 않거나 8비트가 클린하지 않은 경우 데이터 전송에 필요합니다.PGP 매뉴얼( RFC4880)에서는 Base64를 참조할 때 바이너리-to-text 인코딩에 "ASCII armor"라는 용어를 사용합니다.

개요

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

묘사

ASCII 텍스트 부호화 표준에서는 영어에서 일반적으로 사용되는 영문자, 숫자 및 구두점 문자를 나타내기 위해 128개의 고유 값(0~127)과 인쇄 가능한 문자를 나타내지 않는 제어 코드 선택을 사용합니다.예를 들어 대문자 A는 ASCII 문자 65, 숫자 2는 ASC입니다.II 50, 문자 }은 ASCII 125, 메타 문자 캐리지 리턴은 ASCII 13입니다.ASCII 기반의 시스템에서는 7비트를 사용하여 이러한 값을 디지털로 나타냅니다.

반면 대부분의 컴퓨터는 8비트 바이트로 구성된 메모리에 데이터를 저장합니다.기계 실행 가능한 코드와 텍스트 이외의 데이터가 포함된 파일에는 일반적으로 256개의 가능한 8비트 바이트 값이 모두 포함됩니다.많은 컴퓨터 프로그램이 7비트 텍스트와 8비트 바이너리 데이터의 이 구분에 의존하게 되어 ASC가 아닌 경우 제대로 작동하지 않게 되었습니다.ASCII 텍스트만 포함할 것으로 예상되는 데이터에 II 문자가 표시되었습니다.예를 들어, 8번째 비트의 값이 유지되지 않으면 프로그램은 127을 초과하는 바이트 값을 플래그로 해석하여 어떤 기능을 수행하도록 지시할 수 있습니다.

단, 이미지 파일을 전자 메일메시지에 첨부할 수 있는 경우 등 텍스트 기반 시스템을 통해 텍스트 이외의 데이터를 전송할 수 있는 것이 바람직합니다.이를 위해 데이터는 8비트 데이터가 7비트 ASCII 문자(일반적으로 영숫자 및 구두점 문자(ASCII 인쇄 가능 문자)로 인코딩되도록 부호화됩니다.수신처에 안전하게 도착하면 8비트 형식으로 디코딩됩니다.이 프로세스를 바이너리-텍스트 부호화라고 부릅니다.PGP 나 GNU Privacy Guard(GPG)등의 많은 프로그램이, 데이터 전송을 가능하게 하기 위해서 이 변환을 실행합니다.

일반 텍스트 인코딩

다음 항목도 참조하십시오.딜리미터 "ASCII armor" 및 "Return-to-libc" 공격 "Return-to-libc 공격으로부터의 보호

바이너리-to-text 부호화 방식도 플레인텍스트 부호화를 위한 메커니즘으로 사용된다.예를 들어 다음과 같습니다.

  • 시스템에 따라서는 처리할 수 있는 문자 집합이 한정되어 있습니다.또한 8비트가 깔끔하지 않을 뿐만 아니라 인쇄 가능한 ASCII 문자도 모두 처리할 수 없습니다.
  • 다른 시스템에서는 행 구분 사이에 표시되는 문자 수에 제한이 있습니다.예를 들어 일부 SMTP 소프트웨어의 "행당 1000 문자" 제한은 RFC 2821에서 허용됩니다.
  • 또, 헤더나 트레일러를 텍스트에 추가하는 사람도 있습니다.
  • 잘 알려지지 않았지만 여전히 사용되는 일부 프로토콜은 인밴드 시그널링을 사용하기 때문에 메시지에 특정 패턴이 나타나면 혼란을 일으킵니다.가장 잘 알려진 문자열은 mbox 파일 형식의 메일 메시지를 구분하는 데 사용되는 행의 선두에 있는 "From " (후행 공백 포함)"입니다.

이미 플레인 텍스트인 메시지에 바이너리-텍스트 인코딩을 사용한 후 다른 쪽 끝에서 디코딩함으로써 이러한 시스템을 완전히 투과적으로 보이게 할 수 있습니다.이를 'ASCII 아머링'이라고도 합니다.예를 들어 ASP의 ViewState 컴포넌트가 있습니다.NET은 딜리미터의 충돌을 피하기 위해 base64 인코딩을 사용하여 HTTP POST를 통해 텍스트를 안전하게 전송합니다.

부호화 표준

다음 표는 가장 많이 사용되는 바이너리-텍스트 인코딩 형식을 비교한 것입니다.여기에 나타내는 효율은 입력 비트 수와 부호화 출력 비트 수 간의 비율입니다.

부호화 data 타입 효율성. 프로그래밍 언어 구현 평.
ASCII [a] 임의 87.5% 대부분의 언어 이는 8비트 바이너리를 7비트 데이터로 비트 시프트하는 것을 말합니다. 따라서 7바이트의 바이너리 데이터가 8바이트의 7비트 데이터를 차지하게 됩니다.이 데이터는 가능한 모든 제어 코드를 포함한 ASCII를 나타냅니다.이 계획은 실제로 거의 사용되지 않는다.
ASCII85 임의 80% awk, C, C(2), C#, F#, Go, Java Perl, Python, Python(2) 이 부호화에는 Base85, btoa, et cetera 등 여러 종류가 있습니다.
베이스32 임의 62.5% ANSI C, Delphi, Go, Java, Python
베이스36 정수 ~64% bash, C, C++, C#, Java, Perl, PHP, Python, Visual Basic, Swift, 기타 다수 아라비아 숫자 0 ~9 및 라틴 문자 A ~ Z(ISO 기본 라틴 문자)를 사용합니다.Tiny와 같은 URL 리다이렉션 시스템에서 일반적으로 사용됩니다.콤팩트한 영숫자 식별자로서의 URL 또는 Snip URL/Snipr.
베이스45 임의 ~67% 가세요 IETF 사양서[1] 초안
베이스 58 정수 ~73% C++, Python Base64와 비슷하지만 영숫자가 아닌 문자(+ 및 /)와 인쇄 시 모호해 보이는 문자(0 – 0, I – 대문자 i, O – 대문자 o 및 l – 소문자 L)를 모두 피하도록 수정되었습니다.Base58은 bitcoin [2]주소를 나타내기 위해 사용됩니다.일부 메시징 및 소셜 미디어 시스템은 영숫자가 아닌 문자열에서 줄을 끊습니다.이는 +와 같은 URI 예약 문자를 사용하지 않음으로써 방지됩니다.segwit의 경우 Bech32로 대체되었습니다.아래를 참조해 주십시오.
원래 bitcoin 소스 코드의 base58
베이스62 임의 ~74% 녹 Base64와 비슷하지만 영숫자만 포함되어 있습니다.
베이스64 임의 75% awk, C, C(2), Delphi, Go, Python, 기타 다수
베이스85(RFC 1924) 임의 80% C, Python Python (2) ASCII85 개정판.
베이스91[3] 임의 81% C# F# 등폭 변형
베이스E91[4] 임의 81% C, Java, PHP, 8086 어셈블리, AWK C# F# 녹 가변 폭 변형
베이스94[5] 임의 82% 파이썬 C
베이스122[6] 임의 87.5% 자바스크립트 파이썬 자바
베이스[7] XML 임의 83.5% C Python 자바스크립트
벡32 임의 62.5% + 8글자 이상 (라벨, 구분자, 6글자 ECC) C, C++, JavaScript, Go, Python, Haskell, Ruby, Rust 사양.[8]Bitcoin과 [9]Lightning Network에서 사용됩니다.데이터 부분은 Base32와 같이 부호화되어 마지막에 6글자의 BCH 코드를 사용하여 최대 6글자의 오타를 체크 및 수정할 수 있습니다.또, HRP(Human Readable Part)도 체크/수정할 수 있습니다.Bech32m 변종에는 길이 변화에 [10]대한 탄력성이 뛰어난 미묘한 변화가 있습니다.
빈헥스 임의 75% Perl, C, C (2) MacOS 클래식
십진수 정수 ~42% 대부분의 언어 보통 사람으로부터의 입력/출력에 대한 기본 표현입니다.
16진수(Base16) 임의 50% 대부분의 언어 대소문자의 변형으로 존재합니다.
인텔 HEX 임의 ≲50% C 라이브러리, C++ 일반적으로 EPROM, NOR-Flash 메모리 칩 프로그래밍에 사용됩니다.
MIME 임의 "인쇄 가능" 및 "Base64" 참조 "인쇄 가능" 및 "Base64" 참조 전자 메일과 같은 형식을 위한 인코딩 컨테이너
MOS 테크놀로지 파일 형식 임의 일반적으로 EPROM, NOR-Flash 메모리칩 프로그래밍에 사용됩니다.
퍼센트 부호화 텍스트(URI), 임의(RFC1738) 최대 40%([b]33~70%)[c] C, Python, 기타 다수
인용 인쇄 가능 본문 ~33~100%[d] 아마 많을 것이다 줄 바꿈 유지, 줄 바꿈 76자
S 레코드(모토로라 육각) 임의 49.6% C 라이브러리, C++ EPROM, NOR-Flash 메모리 칩 프로그래밍에 일반적으로 사용됩니다. 49.6%는 레코드당 255개의 바이너리 바이트를 가정합니다.
Tektronix 16진수 임의 일반적으로 EPROM, NOR-Flash 메모리칩 프로그래밍에 사용됩니다.
Uuencoding(유인코딩) 임의 최대 60%(최대 70%) Perl, C, Delphi, Java, Python, 기타 다수 주로 MIME 및 yEnc로 대체됨
xx 부호화 임의 최대 75%(Uuencoding과 유사) C, 델파이 ASCII와 EBCD 사이의 문자 집합 변환 문제를 피하기 위해 Uuencoding을 대체하기 위해 제안(및 경우에 따라 사용)Uuencoded 데이터를 손상시킬 수 있는 IC 시스템
yEnc [a] 임의(대부분 텍스트가 아님) ~98% C 자바스크립트 JavaScript (2) CRC 체크섬 포함
RFC 1751 (S/KEY) 임의 33% C,[11] Python, ...

"인간이 읽을 수 있는 128비트 키에 대한 협약"일련의 작은 영어 단어들은 십진법이나 다른 바이너리-to-text 부호화 [12]시스템보다 인간이 읽고, 기억하고, 입력하는 것이 더 쉽다.각 64비트 번호는 공개 2048워드 [11]사전에서 각각 1~4글자의 6개의 짧은 단어로 매핑됩니다.

95 isprint 코드 32~126은 ASCII 인쇄 가능 문자로 알려져 있습니다.

BOU, BTOA 및 USR 인코딩이 오늘날에는 흔치 않은 형식입니다.

이러한 인코딩의 대부분은 모든 ASCII 인쇄 가능 문자의 하위 집합만 포함하는 텍스트를 생성합니다. 예를 들어, base64 인코딩은 대문자 및 소문자, (A~Z, a~z), 숫자(0~9) 및 "+", "/" 및 "=" 기호만 포함하는 텍스트를 생성합니다.

이러한 부호화(인쇄 가능 및 비율 부호화)의 일부는, 허가된 문자 세트와 1 개의 이스케이프 문자에 근거하고 있습니다.허용된 문자는 변경되지 않은 상태로 유지되며 다른 모든 문자는 이스케이프 문자로 시작하는 문자열로 변환됩니다.이러한 변환에 의해, 문자와 숫자가 허가된 문자의 일부이므로, 부호화된 텍스트에 있는 그대로인 채로, 결과 텍스트를 거의 판독할 수 있습니다.이러한 부호화에 의해, 대부분의 인쇄 가능한 ASCII 가 되는 입력용의 최단 플레인 ASCII 출력이 생성됩니다.

그 외의 부호화(base64, uuencoding)는, 6 비트의 가능한 모든 시퀀스를 다른 인쇄 가능한 문자에 매핑 하는 것에 근거하고 있습니다.인쇄 가능한 문자가 2 = 64자를 초과하므로6 가능합니다.주어진 바이트 시퀀스는 비트의 스트림으로 간주하여 이 스트림을 6비트의 청크로 분할하고 대응하는 문자의 시퀀스를 생성함으로써 변환됩니다.인코딩에 따라 비트와 문자의 시퀀스 간의 매핑과 텍스트의 포맷 방법이 달라집니다.

일부 인코딩(BinHex의 원래 버전 및 CipherSaber의 권장 인코딩)에서는 6비트가 아닌 4비트를 사용하여 4비트의 가능한 모든 시퀀스를 16의 표준 16진수에 매핑합니다.부호화 문자당 4비트를 사용하면 base64보다 출력이 50% 길어지지만 부호화 및 복호화가 간소화됩니다.소스 내의 각 바이트를 2개의 부호화 바이트로 독립적으로 확장하는 것은 base64의 3개의 소스 바이트를 4개의 부호화 바이트로 확장하는 것보다 간단합니다.

PETCII의 첫 번째 192개의 코드 중 164개는 인용된 5개(흰색), 17~20개 및 28-31개(색상과 커서 컨트롤), 32~90개(ASCII 등가), 91~127개(그래픽스), 129개(오렌지색), 133~140개(색상과 커서 컨트롤), 160~192개(그래픽스)[13]로 표시된다.이를 통해 이론적으로 PETSCII를 사용하는 머신 간에 base128 등의 인코딩이 허용됩니다.

「 」를 참조해 주세요.

메모들

  1. ^ a b 출력에 인쇄할 수 없는 문자가 포함되어 있기 때문에 텍스트 인코딩은 엄밀하게는 아닙니다.
  2. ^ 임의 데이터의 경우 예약되지 않은 189개의 모든 문자를 3바이트로 인코딩하고 나머지 66개 문자를 1바이트로 인코딩합니다.
  3. ^ 텍스트의 경우 18개의 예약된 문자 각각만 인코딩합니다.
  4. ^ 1바이트는 =XX로 저장됩니다.필요하지 않은 94자를 제외한 모든 문자를 인코딩합니다(스페이스와 탭 포함).

레퍼런스

  1. ^ Fältström, Patrik; Ljunggren, Freik; Gulik, Dirk-Willem van (July 2021). "The Base45 Data Encoding".
  2. ^ "Protocol documentation". Bitcoin Wiki. Retrieved 10 July 2021.
  3. ^ https://www.iiis.org/CDs2010/CD2010SCI/CCCT_2010/PapersPdf/TB100QM.pdf[베어 URL PDF]
  4. ^ http://base91.sourceforge.net/
  5. ^ "Convert binary data to a text with the lowest overhead :: Vorakl's notes".
  6. ^ "Base-122 Encoding".
  7. ^ "BaseXML - for XML1.0+". GitHub. 16 March 2019.
  8. ^ "Bitcoin/Bips". GitHub. 8 December 2021.
  9. ^ Rusty Russell; et al. (2020-10-15). "Payment encoding in the Lightning RFC repo". GitHub.
  10. ^ "Bech32m format for v1+ witness addresses". GitHub. 5 December 2021.
  11. ^ a b RFC 1760 "S/KEY 원타임 패스워드 시스템"
  12. ^ RFC 1751 "인간이 판독할 수 있는 128비트 키에 관한 협약"
  13. ^ http://sta.c64.org/cbm64pet.html 등