빈헥스

BinHex
빈헥스 4
파일 이름 확장명
.hqx
인터넷 미디어 유형
애플리케이션/mac-binhex40
응용 프로그램/맥 빈헥스
애플리케이션/빈 헥스
동일 유형 식별자(UTI)com.apple빈헥스로 만든

BinHex는 원래 "binary-to-hexadechimal"의 줄임말로, 전자우편을 통해 이진 파일을 전송하기 위해 고전적인 Mac OS에서 사용되었던 바이너리-to-text 인코딩 시스템이다.원래 16진수 인코딩인 BinHex의 후속 버전은 uuencode와 더 유사하지만 확장 파일 정보와 함께 Mac 파일 시스템의 "fork"를 모두 결합했다.BinHexed 파일은 원본 파일보다 더 많은 공간을 차지하지만"8비트 정리" 소프트웨어가 아닌 소프트웨어로 인해 손상되지는 않는다.

역사

TRS-80 BinHex(.헥스)

BinHex는 원래 TRS-80을 위해 Tim Mann이 1981년에 쓴 것으로, 원래 인기 있는 터미널 에뮬레이터인 ST80-III에 내장된 독립형 버전의 인코딩 방식으로 랜스 미클루스에 의해 쓰여졌다.빈헥스는 컴푸서브 등 주요 온라인 서비스를 통해 파일을 전송하는 데 사용됐는데, '8비트 클린'이 아니었고, 살아남기 위해 ASCII 아머링이 필요했다.그러나 모든 사람이 ST-80을 사용한 것은 아니어서 Mann은 BinHex를 써서 다른 에뮬레이터 사용자들이 이 형식을 사용할 수 있도록 했다.[1]

원래의 ST-80 시스템은 바이너리 파일 내용을 16진수 숫자로 변환하여 작동했는데, 이 숫자 자체가 ASCII 숫자와 문자로 인코딩되었다.그리고 60자마다 새로운 줄을 추가했다.이 시스템은 Mann이 Compuserve의 TRS-80 파일 영역에 업로드한 후 큰 인기를 끌었다.시스템은 모든 행의 끝에 체크섬을 추가하여 오류를 점검했다.빌 스톡웰은 그 버전을 BASIC/S 컴파일러로 전환했는데, 이것은 만이 해석한 버전보다 훨씬 빨리 실행되었다.[1]

그 시대의 BinHex 파일에는 일반적으로 .hex라는 파일 확장자가 주어졌다.곧 애플 II를 포함한 그 시대의 다른 인기 있는 플랫폼을 위한 항구가 등장했다.CompuServe는 이후 8비트 전송에 대한 지원을 추가했고 포맷은 빠르게 사라졌다.[1]

Mac BinHex(.hex)

1984년 Mac이 처음 출시되었을 때 CompuServe에는 여전히 파일 업로드 문제가 있었다.1984년 4월, 윌리엄 데이비스는 같은 시대의 TRS-80 버전과 대체로 동일한 버전을 생산하기 위해 Microsoft BASIC을 사용하여 BinHex를 Mac에 포팅했다.[1]이 버전은 리소스 포크는 무시한 채 "데이터 포크"의 인코딩만 지원했는데, 이는 데이터 파일에만 사용될 수 있음을 의미했다.인터넷 전자우편의 사용 증가가 매킨토시 출시와 대략 맞아떨어졌고, 1984년 6월 조엘 헬러가 데이비스의 버전을 인포맥 메일링 리스트에 올렸다.1984년 동안 몇 가지 새로운 버전이 발표되었고, 그 결과 두 포크를 모두 인코딩할 수 있는 BinHex 3이 나왔다.

MacASM의 첫 번째 조립자의 저자 이브 렘페루르는 CompuServe에 파일을 업로드하기 위해서는 BinHex를 사용해야 한다는 것을 발견했다.BASIC 버전은 매우 느려서 렘페뢰르는 빈헥스3를 조립자로 포팅해 빈헥스 1.0으로 출시했다.그 프로그램은 BASIC 버전에 비해 대략 백 배나 빨랐고, 곧 업그레이드 요청이 쇄도하고 있었다.[2]

컴팩트 빈헥스(.hcx)

원래의 BinHex는 상당히 단순한 형식이었는데, 그 형식은 16진수 표현인 8-4비트 부호화에서 요구하는 대로 입력의 모든 바이트를 둘로 확장했기 때문에 매우 효율적이지 못했다.BinHex 2.0의 경우 Lempeerur는 파일 크기를 50% 줄인 새로운 8~6 인코딩을 사용했다.체크섬을 8비트에서 16비트까지 확대하는 기회도 잡았다.[2]

이 새로운 인코딩은 우엔코드와 [3]유사하게 데이터를 나타내기 위해 공간을 포함한 최초의 64개의 ASCII 인쇄 문자를 사용했다.비록 새로운 인코딩은 더 이상 본질적으로 16진법이 아니었지만, 프로그램의 확립된 이름은 그대로 유지되었다.더 작은 파일들은 더 오래된 파일들과 호환이 되지 않아서 확장자는 컴팩트하게 .hcx, c가 되었다.새로운 버전은 이전의 "오버나이트"[2]를 대체했다.

BinHex 4(.hqx)

렘페루어는 빈헥스의 일부 특징, 특히 사이클 중복 검사(CRC) 대신 체크섬을 사용한 점, 헤더에 있는 메타데이터 정보가 일반 텍스트로 되어 있어 데이터와 같은 방식으로 손상될 수 있다는 점 등에 대해 우려했다.[2]

렘페뢰르는 이러한 모든 문제를 해결하기 위해 현재 오래전에 죽은 BASIC 버전과의 혼동을 피하기 위해 1985년 3.0을 건너뛰며 BinHex 4.0을 출시했다.4.0은 먼저 데이터 포크, 리소스 포크 및 파일 메타데이터를 공통 8비트 형식으로 결합하고, 그 결과에서 RLE(실행 길이 인코딩)을 실행하여 압축을 어느 정도 제공한 다음, 그 결과에서 8->6 변환을 실행하고 여러 개의 CRC로 모든 것을 보호했다.결과.hqx파일은 대략 의 크기와 같았다..hcx의, 하지만 훨씬 더 강력하다.[2]

빈헥스 5

BinHex 4가 출시될 무렵, 대부분의 온라인 서비스는 ZMODEM과 같은 강력한 8비트 파일 전송 프로토콜을 지원하기 시작했고, ASCII 아머링의 필요성은 사라졌다.그러나 이 두 포크를 하나의 포크로 인코딩해야 할 필요성이 여전히 있었기 때문에 이것은 맥에 문제를 남겼다.

Lempeerur를 포함한 Macintosh 통신 프로그래머들의 팀워크는 MacBinary를 만들었다.이것은 포크의 내용을 원래의 8비트 형식으로 남겨두고 수신 시 포크를 결합하기 위한 간단한 헤더를 추가했다.MacBinary 파일은 BinHex보다 훨씬 작았다.렘페뢰르는 8~6 인코딩을 실행하기 전에 MacBinary를 사용하여 포크를 결합한 것을 제외하고는 4.0과 거의 동일한 BinHex 5.0을 출시했지만, 예상대로 별 소용이 없었다.[2]

인터넷에서는 이메일이 여전히 파일을 옮기는 주요 방법이었다.당시에는 비교적 소수의 사람들만이 인터넷에 완전히 접속할 수 있었고, FTPmail과 같은 서비스는 많은 사용자들이 파일을 다운로드 할 수 있는 유일한 방법이었다.몇 년 후, 렘페뢰르는 빈헥스 4.0이 여전히 매우 인기가 있다는 것을 발견하고 놀랐다.[2]

처음에는 MacBinary 또는 AppleSingle을 사용하여 포크를 결합한 다음, 그 결과 파일에서 Uuencode 또는 Base64를 사용함으로써 같은 목적을 달성할 수 있었지만, 이러한 솔루션들 중 어느 것도 인기를 끌지 못했고 BinHex 4.0은 1990년대 후반까지 잘 살아남았다.전통적인 Mac OS 소프트웨어의 파일 아카이브는 여전히 BinHexed 파일로 채워져 있다.

BinHex 4 파일 형식

빈헥스 파일의 내용을 보면 보통 첫 줄에 빈헥스로 식별되는 메시지가 있고, 그 뒤에 겉보기에는 임의로 보이는 글자, 숫자, 구두점 등으로 이루어진 64자 많은 줄이 뒤따른다는 것을 알 수 있을 것이다.다음은 BinHex가 실제로 어떻게 생겼는지 보여 주는 샘플이다.

(이 파일은 BinHex 4.0으로 변환해야 함) :$f*TEQKPH#jdCA0d,R0TG!"6594%8dP8)3#3"!&m!*%!EMA6593K!!%!!!&mFNA KG3,r!*!$$BODY$$amp;[rr$3d,BQPZD'9i,R4PFh3!RQ+!!"AV#J#3!i!!N!@QKUjrU!#3'[q 3"&4&@&483N)f!3#Xaj6bV-H8mJ!!!B3!N!0"!*!$[3#3!cR@iY]!*![I%4!!J Fp$X%X3@J!mZE6!GRiKUi$HGKMF0U61S46%i1"AB!TI, fll!d1X3RDE8ALFTCBM 8UP9p4iUqY-0k4krHpk9XK@"rbj2Ti'U@5rGH@+[fr-i4T6-qXpfl26,k!H5$Nml TIKI'(l3GI4)f8mII&01CNEbC2LrNLBeZ1HG@$G8!Z6"k)hh,q9p"r6FC*!!세" (icc,pd(4(b'pflKC'H1&JN5)GVX3mREdH55[l%]Yhp%q092c"A(hPV)!83Dr&f4 $L#I1aM-"VjqV-q$34KQ6$M$f8#,Zc,i)!("*ZN!$K$rS!LA%3cL+dYi"@,K(Z"#3!fKi!!!:

사용자 및 도구가 BinHex 버전을 인식하기 위해 사용하는 텍스트 줄이 있어야 함:(This file must be converted with BinHex 4.0). 이 줄 이전의 모든 텍스트는 무시되어야 한다.[4]

파일의 나머지 부분은 헤더(파일 이름, 크기 등 포함), 데이터 포크(파일 데이터 포함) 및 리소스 포크 등 세 부분으로 구성된다.각각 2바이트 CRC 체크섬이 있다.

다음 항목을 제외한 모든 항목(This file...선은 그 후 ASCII 문자로 인코딩되는 이진 데이터의 영역으로 간주된다.인코딩 알고리즘은 3바이트 입력을 베이스64가 하는 방식과 비슷한 방식으로 4개의 6비트 값으로 나눈다고 말한다.숫자 0~63은 다음 목록에 따라 문자를 부여한다.!"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr

인코딩 시 64자마다 <반환>을 삽입해야 한다.인코딩 후 데이터 앞뒤에 콜론이 배치된다.

참조

  1. ^ a b c d 만.
  2. ^ a b c d e f g 렘페레우르 1997.
  3. ^ 예를 들어, CWI 버전의 소스 코드hexbin마커틸에 포함되어, 에.hecx.c187행, 표현 사용((c)-0x20) & 0x3fASCII 값을 갖는 HCX 자릿수의 숫자 값을 구하다c.
  4. ^ BinHex 인코딩된 파일의 RFC1741 MIME 컨텐츠 유형.팔트스트롬, P. & 크로커, D. & Fair, E. (1994년 12월)

참고 문헌 목록

참고 항목

외부 링크