2004년 04월 19일
yEnc 1.3 스펙 번역
yEncode - A quick and dirty encoding for binaries
---------------------------------------------------------------------------
Version 1.2 - 28-Feb-2002 - by Juergen Helbing
Revisions:
v1.0, 31-Jul-2001 - Juergen Helbing (juergen@helbing.de)
v1.1, 17-Feb-2002 - Steve Blinch (yenc32@esitemedia.com)
v1.2, 28-Feb-2002 - Juergen Helbing (juergen@helbing.de)
v1.3, 05-Mar-2002 - Juergen Helbing (juergen@helbing.de)
원문 : http://www.yenc.org/yenc-draft.1.3.txt
번역 : 손권남 (kwon37xi__aT__yahoo.co.kr)
소개
---------------------------------------------------------------------------
이 문서는 이메일과 뉴스그룹에서 임의의 바이너리 정보를 전송을 위한
인코딩의 메카니즘을 기술한다. 다른 비슷한 인코딩 체계와는 달리 yEncode는
8비트 문자셋 전체의 장점을 취해서, 원래 바이너리 자료의 1-2%의 크기
증가만 있을 뿐이다.
동기
---------------------------------------------------------------------------
기존의 이메일과 뉴스그룹에 쓰이는 바이너리 정보 전달 메카니즘은 오직
7비트 아스키 텍스트만을 사용한다. 그 결과 인코딩된 자료의 양이 원래
바이너리 자료에 비해 40% 까지 증가하기도 한다.
yEncode는 인터넷 뉴스그룹에서 광범위하게 사용되게 된 8비트 문자셋의
장점을 취해 기존의 인코딩 방식의 추가적인 오버헤드를 줄여주기 위해서
만들어졌다.
기존에 존재하는 메시지 전송 프로토콜에 저촉되는 것을 피하기 위해 특수하게
예약된 아스키 제어 문자들에 대해 특별한 처리를 한다.
yEnc로 인코딩 된 이진 자료의 오버헤드는 1-2% 정도 밖에 안된다.
인코딩 원리
---------------------------------------------------------------------------
The encoding process represents each octet of input data with a single
corresponding encoded output character. 각 출력 문자의 아스키 값은 아래의
단순한 수식에 의해 결정된다.
O = (I+42) % 256
출력값은 "각 입력 문자의 아스키 값 + 42를 256으로 나눈 나머지"와 같다.
많은 바이너리 자료들이 불균형적으로 많이 포함하고 있는 널 문자들을
인코딩하기 위해 이스케이프 작업이 필요한데, 위 수식으로
널문자(아스키 값 0)의 개수를 줄임으로서 오버헤드를 줄여준다.
특별한 환경에서는 한개의 이스케이프 문자(아스키 3Dh, "=")가 다음의 출력문자가
크리티컬(critical)하고 특별한 처리를 필요로 함을 표시하기 위해 사용된다.
크리티컬한 문자는 다음과 같다 :
ASCII 00h (NULL)
ASCII 0Ah (LF)
ASCII 0Dh (CR)
ASCII 3Dh (=)
> ASCII 09h (TAB) -- 1.2 버전에서 제거됨
이 문자들은 언제나 이스케이프되어야 한다. 추가적으로, 크리티컬 문자를
인코드하는 기법(다음 섹션에 설졍)은 어떤 문자라도 이스케이프할 수 있다.
yDecoder는 이스케이프 문자 다음에 오는 어떤 문자라도 디코딩 할 수 있어야 한다.
이 4문자가 바이너리 자료에서 나타날 확률은 대략 0.4%이다. 평균적으로
이 4 문자만 이스케이프 될 때 이스케이프 처리는 약 1.6%의 오버헤드를 가져온다.
각 줄의 캐리지 리턴(CR)과 라인피드(LF)의 오버헤드는 개발자가 정의한 줄 길이에
달려있다. 헤더(앞부분 정보)와 트레일러(뒷부분 정보)는 상대적으로 매우 작아,
무시해도 될 만하다.
> (1.2) 주위깊은 인코더 제작자는 TAB(09h)와 SPACES(20h)가 줄의 첫번째 컬럼이나
> 마지막 컬럼에 나타나면 그것들을 인코드 할 것이다.
> TCP 스트림에 직접 쓰는 구현자는 첫번째 컬럼의 점을 두개로 만들거나 아니면
> 인코드 해야만 한다.
인코딩 기법
---------------------------------------------------------------------------
전형적인 인코딩 과정은 다음과 같이 보일 것이다 :
1. 입력 스트림에서 문자를 가져온다.
2. 문자의 아스키 값에 42를 더하고 256으로 나눈 나머지를 구한다.
3. 결과값이 크리티컬 문자 (이전 섹션에서 정의 된 것들)이라면, 출력 스트림에
이스케이프 문자를 쓰고 문자의 아스키값에 64를 더하고 256으로 나눈 나머지를
구한다. (모호함 : 최초의 입력 문자(1번)에 대한 처리인가, 아니면 일단 42를
더하고 256으로 나눈 나머지(2번)에 대한 처리인가?)
4. 문자를 출력 스트림에 써 준다.
5. 처음부터 반복한다.
현존하는 표준 프로토콜(주로 NNTP)을 통한 전송을 용이하게 하기 위해 CR/LF 쌍이
매 n 문자 뒤에서 출력 스트림에 쓰여져야 한다. n은 줄의 길이이며 주로 128이나
256이다.
>(1.2) 추가적인 경험 정보를 보라.
크리티컬 문자가 줄의 n 위치(즉, 맨 마지막 컬럼)에 나타날 경우, 이스케이프
문자와 인코딩된 크리티컬 문자는 항상 CR/LF이전의 같은 줄에 있어야한다.
이럴때에, 실제 이 줄의 문자 개수는 n + 1 이 된다. 간단히 말해 이것은 한 줄은
이스케이프 문자로 끝 날 수 없으며, n+1 줄은 인코딩된 크리티컬 문자로 끝나야만
한다.
헤더(인코딩 시작부분에 정보를 둔 것)와 트레일러(인코딩 끝에 정보를 둔것)
---------------------------------------------------------------------------
다른 인코딩 방식과 비슷하게, yEnc는 데이타 블록의 처음과 끝에 특별한 표시를
하는 예약된 줄이 있다. 이 이 블록들은 어떤 8비트 아스키 텍스트 파일에라도
포함될 수 있다. yDecoder 구현체는 헤더와 트레일러 블록 외부의 어떤 것도 다
무시해야 한다.
모든 예약어 줄은 이스케이프 문자('=')로 시작해야하며, 그 바로 뒤에
아스키코드 97h ('y')가 온다. y가 올바르게 인코딩된 크리티컬
문자가 아니기 때문에, 이 '=y' 로 이것이
헤더와 트레일러 예약어 줄들은 항상 이크케이프 문자로 시작해야만 하며,
그 뒤에는 줄의 타입을 지정하는 예약어가, 또 그 뒤에는 특정한 줄 타입에
적합한 예약어가 온다.
전형적인 헤더 줄은 다음과 같이 보일것이다 :
=ybegin line=128 size=123456 name=mybinary.dat
>(1.2)yEnc의 앞으로 나올 버전은 (있다면..) =ybegin 대신에 "=ybegin2"
>를 예약어로 쓸 수도 있다. 디코더는 꼭 =ybegin 다음에 공백이 붙은
> "=ybegin "으로 헤더 줄을 검사해야만 한다.
>(1.2) "line=" "size=" "name=" 파라미터가 =ybegin 다음에 나타나지 않는다면
>이것은 yEnd 헤더 줄이 아니라 yEnc에 관해 언급하는 텍스트 메시지의 일부일
>것이다. 이럴 경우 디코더는 그 메시지에 바이너리가 없다고 인식해야한다.
헤더 줄은 항상 "ybegin" 예약어로 시작해야만 하며, 한 줄의 길이, 원래
바이너리의 크기(byte 로) 그리고 바이너리 파일의 이름을 포함해야 한다.
파일 이름은 항상 헤더 줄의 마지막 항목으로 와야 한다. 이렇게 해야
다른 키워드 들의 방해 없이 파일 이름의 모든 문자들이 정확하게 인식된다.
비록 큰 따옴표(아스키 22h, '"')가 기술적으로는 허락 되지만, 파일이름에
큰 따옴표를 쓰는 것은 좋지 않다.
> (1.2): 예약어 앞 뒤의 공백은 디코더에 의해 무시된다!
> (1.2): 추가적인 경험 정보를 보라.
> 디코더를 구현할 때는 파일이름에 주의해야한다.
> 그것은 US-ASCII 이외의 문자(80h-FFh), 제어 문자들(01h..1Fh) 그리고 현재
> 플랫폼에서 충돌을 일으키는 문자(/ < | > : ? * @)를 포함 할 수 있다.
> 이것은 또 한 매우 긴 문자열 파라미터(최고 영어 256자) 일 수 있다.
전형적인 트레일러는 다음과 같다 :
=yend size=123456
트레일러 줄은 항상 "yend" 예약어로 시작하며, 원래 바이너리의 크기를 byte로
갖고 있어야 한다.
원래 바이너리의 사이즈는 트레일러에서 다시 한번 검사된다. yDecoder 구현은
헤더의 크기 값과 트레일러의 크기값, 그리고 실제로 디코드된 바이너리의 크기값을
비교해야만 한다. 만약 한개라도 다르다면 첨부 내용이 깨진것이고 경고를 내보내야만
한다. 결과적으로 나온 바이너리는 버려져야 한다. (1.2) 추가적인 경험 정보를
보라.
완전성 검사
---------------------------------------------------------------------------
yEnc로 인코딩된 문서는 인코딩된 이진 자료의 완전성을 검사하기 위해 32-bit
Cyclic Redunduncy Check(CRC)값도 포함 할 수 있다.
CRC32 값이 있다면, 그것은 트레일러 줄에 "crc32" 예약어로 추가된 것이다. 그런
트레일러 줄은 다음과 같이 보일 것이다 :
=yend size=123456 crc32=abcdef12
CRC32 값은 필수적인 것은 아니나, 존재한다면 꼭 처리해야 한다.
>(1.2) 추가적인 경험 정보를 보라.
yEnc로 인코딩된 간단한 파일
---------------------------------------------------------------------------
다음은 실제로 yEnc로 인코딩된 파일 븍록에서 발취된 것이다 :
=ybegin line=128 size=111401 name=al_larsonbw030_ball.jpg
)_)=J*:tpsp*++++V+V**)_*m*0./0/.00/011024:44334>896:A>....
....
....
....R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄
쨈R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R繼)_
=yend size=111401
www.yenc.org에서 완전하게 인코딩된 샘플을 볼 수 있다.
멀티 파트로 인코딩된 바이너리
---------------------------------------------------------------------------
인터넷으로 전송하기위해 큰 바이너리 파일을 여러 부분으로 나누는 경우가 자주
있다. 그런 바이너리들은 종종 몇몇 부분을 잃거나 데이타가 깨져 사용할 수 없게
되는 경우가 있다.
이런 문제를 처리하기 위해 yEncode 는 "ypart"와 멀티파트 바이너리를 처리하기 위한
몇몇 추가적인 예약어들을 정의한다.
각 개별적인 파일의 부분은 표준 "ybegin" 헤더 줄로 시작하지만 추가적인 예약어
"part"가 각 부분의 번호와 멀티파트 바이너리 파일임을 인식하기 위해 추가된다.
"part"예약어가 헤더에 추가되면, 그 다음 줄은 그 부분에 대한 정보를 가진 "ypart"
예약어 줄이 와야 한다.
"ypart" 예약어 줄은 "begin"과 "end" 예약어를 필요로 하며, 이것은 바이트 단위로
원래 파일의 블록에서 시작점과 끝점을 의미한다.
(즉, "이 부분은 원래 파일의 xx byte 에서 yy byte 까지이다" 라는 의미)
파일의 부분은 살짝 수정된 "ypart" 트레일러 줄로 끝나야한다. 추가적인 예약어
"part"가 부분 번호를 지정하기 위해 추가 된다. 이 부분 번호는 헤더 줄의 부분
번호와 일치해야한다.
> (1.2) "total" 예약어도 함께 추가 되어야만 한다.
> 이 total의 번호는 헤더에서 발견되는 부분의 모든 개수와 일치해야한다.
> yEnc 의 첫번째 구현은 이 파라미터를 포함하지 않는다.
트레일러 줄은 또한 "pcrc32" 예약어도 포함해야한다. 이것은 바로 전의 인코딩된
부분의 CRC32를 의미한다. 늘 그렇듯, 전체 인코딩된 바이너리의 CRC32를 나타내는
"crc32"예약어는 필수사항은 아니다
단일 인코딩 yEnc 문서와는 달리, 멀티 파트로 인코딩된 문서에서 트레일러의 "size"
예약어는 전체 파일의 크기를 의미하는게 아니라 현재 부분의 크기를 의미한다.
완전성 검사를 위해 디코더 구현은 "ypart"줄의 "begin"과 "end" 예약어에 있는
각 부분의 예상 크기를 다시 계산해야한다. 예상 크기가 "yend" 줄에 있는 부분
크기와 다르다면 그 파일은 깨진것이다.
멀티파트로 인코딩된 바이너리는 다음과 같이 보인다 :
> (1.1) =ybegin part=1 line=128 size=500000 name=mybinary.dat
> (1.2) =ybegin part=1 total=10 line=128 size=500000 name=mybinary.dat
=ypart begin=1 end=100000
.... data
=yend size=100000 part=1 pcrc32=abcdef12
=ybegin part=5 line=128 size=500000 name=mybinary.dat
=ypart begin=400001 end=500000
.... data
=yend size=100000 part=10 pcrc32=12a45c78 crc32=abcdef12
만약 디코더가 멀티파트 지원을 구현하지 않았거나 멀티파트 인코딩된 바이너리를
인식하는데 실패한다면, 이것은 "ybegin" 줄의 "size" 예약어의 값과 "yend"줄의
"size" 예약어의 값이 다르기 때문에 각 파일의 부분을 성공적으로 디코드 할 수
없다.
멀티파트 바이너리들은 일반적으로 깨지기 쉽다. 단지 제대로 인식되지 않는
깨진 부분 때문에 헛된 수백 메가 바이트의 전송이 소중한 대역폭의 낭비가 된다.
yEnc는 "begin"과 "end" 예약어의 사용으로 디코더가 큰 파일에서 각 개별 부분의
위치를 식별할 수 있게 한다. 이로인해 서로 다른 소스에서 온 각 부분들이 부분들의
크기에 상관없이 하나로 합쳐질 수 있게 된다.
이 기능은 yEnc만의 것이며, 인코더를 구현할 때 쉽게 추가할 수 있다.
제목 줄 관행
---------------------------------------------------------------------------
표준 단일 yEnc 인코딩된 바이너리는 제목 줄에 특별한 관행이 필요 없다. 그러나
yEnc 인코딩된 바이너리는 yEnc 포맷이 널리 구현 될 때까지는 명확하게 yEnc로
인코딩 되었다고 명시하는것이 좋다.
단일 yEnc 인코딩된 바이너리를 위한 제목 줄을 제안하자면 :
[Comment1] "파일이름" 12345 yEnc bytes [Comment2]
[Comment1]과 [Comment2]는 선택적이다. 파일 이름은 항상 큰 따옴표로 묶여 있어야
하는데 이것은 파일 이름이 공백이라든가 특수 문자를 포함할 때도 쉽게 인식되기
때문이다. "yEnc"라는 단어는 파일 크기와 bytes 라는 단어 사이에 와야 한다.
>(1.2) 추가적인 경험 정보를 보라.
> "yEnc"라는 단어를 파일이름 + bytes 혹은 bytes+comment2 사이에 오게 해도 된다.
멀티파트 자료는 항상 멀티파트로 인식되어야만 한다. 단일 yEnc 인코딩된 바이너리와
마찬가지로 멀티파트 자료들도 yEnc가 주류가 될때까지는 yEnc로 인식 될 수 있는
표시를 해야한다.
멀티파트 바이너리를 위해 (강력하게) 권하는 제목 줄은 다음과 같다 :
[Comment1] "파일이름" yEnc (부분번호/전체부분개수) [크기] [Comment2]
다시말하지만, [Comment1]과 [Comment2]는 선택적이다. [크기]도 여기서는
선택적이다. 파일 이름은 큰 따옴표로 둘러싸야만 한다. "yEnc" 예약어는 필수이며
꼭 파일 이름과 크기(혹은 크기가 생략되었다면 Comment2)사이에 와야 한다.
다음 수정판에서는 "yEnc"와 부분번호의 열기 괄호('(') 사이에 추가적인 정보를
명시할 수 도 있다.
>(1.2) 추가적인 경험 정보를 보라.
> "yEnc" 를 (#/#)+size 혹은 size+comment2 사이에 두어도 된다.
>(1.2) 깨진 메시지 다루기
>(1.2) -------------------------------------------------------------------
디코더는 가능하면 오류검사를 해야만 한다.
사용자는 깨진 메시지에 대한 경고를 봐야만한다.
경고기능을 꺼두었다면 바이너리를 저장할 때 오류 메시지도 파일이름에 함께
저장하기를 권한다. 예:
picture(size-error).jpg
homemovie(crc32-error).avi
document(line-error).rtf
longmusic(missing-parts).mp3
깨진 바이너리를 저장해도 상관없다. (부분적으로 사용가능할 수 있으니)
하지만 감지된 오류를 사용자가 전혀 못보게 하는것은 안된다!
yEnc는 자료가 깨지는 것을 감지할 수 있게 설계되었다.
유능한 유즈넷 사용자들은 깨진 부분을 다른 곳에서 가져올 수도 있다.
저작권
---------------------------------------------------------------------------
yEnc 인코딩 기법은 공개(public domain)되어있다. 누구나 복사하고 사용하고 구현 할
수 있다.
이 문서와 yEnc 인코딩 기법은 어떤 법에 의해서도 보호 받거나 제한될 수 없으며
특허권을 얻을 수도 없다.
이 문서는 원작자를 표기하는한 자유롭게 배포될 수 있다.
이것은 당신만이 한 일이라고 주장하지 말라!
공개된 예제 프로그램들을 www.yenc.org에서 구할 수 있다.
---------------------------------------------------------------------------
Version 1.2 - 28-Feb-2002 - by Juergen Helbing
Revisions:
v1.0, 31-Jul-2001 - Juergen Helbing (juergen@helbing.de)
v1.1, 17-Feb-2002 - Steve Blinch (yenc32@esitemedia.com)
v1.2, 28-Feb-2002 - Juergen Helbing (juergen@helbing.de)
v1.3, 05-Mar-2002 - Juergen Helbing (juergen@helbing.de)
원문 : http://www.yenc.org/yenc-draft.1.3.txt
번역 : 손권남 (kwon37xi__aT__yahoo.co.kr)
소개
---------------------------------------------------------------------------
이 문서는 이메일과 뉴스그룹에서 임의의 바이너리 정보를 전송을 위한
인코딩의 메카니즘을 기술한다. 다른 비슷한 인코딩 체계와는 달리 yEncode는
8비트 문자셋 전체의 장점을 취해서, 원래 바이너리 자료의 1-2%의 크기
증가만 있을 뿐이다.
동기
---------------------------------------------------------------------------
기존의 이메일과 뉴스그룹에 쓰이는 바이너리 정보 전달 메카니즘은 오직
7비트 아스키 텍스트만을 사용한다. 그 결과 인코딩된 자료의 양이 원래
바이너리 자료에 비해 40% 까지 증가하기도 한다.
yEncode는 인터넷 뉴스그룹에서 광범위하게 사용되게 된 8비트 문자셋의
장점을 취해 기존의 인코딩 방식의 추가적인 오버헤드를 줄여주기 위해서
만들어졌다.
기존에 존재하는 메시지 전송 프로토콜에 저촉되는 것을 피하기 위해 특수하게
예약된 아스키 제어 문자들에 대해 특별한 처리를 한다.
yEnc로 인코딩 된 이진 자료의 오버헤드는 1-2% 정도 밖에 안된다.
인코딩 원리
---------------------------------------------------------------------------
The encoding process represents each octet of input data with a single
corresponding encoded output character. 각 출력 문자의 아스키 값은 아래의
단순한 수식에 의해 결정된다.
O = (I+42) % 256
출력값은 "각 입력 문자의 아스키 값 + 42를 256으로 나눈 나머지"와 같다.
많은 바이너리 자료들이 불균형적으로 많이 포함하고 있는 널 문자들을
인코딩하기 위해 이스케이프 작업이 필요한데, 위 수식으로
널문자(아스키 값 0)의 개수를 줄임으로서 오버헤드를 줄여준다.
특별한 환경에서는 한개의 이스케이프 문자(아스키 3Dh, "=")가 다음의 출력문자가
크리티컬(critical)하고 특별한 처리를 필요로 함을 표시하기 위해 사용된다.
크리티컬한 문자는 다음과 같다 :
ASCII 00h (NULL)
ASCII 0Ah (LF)
ASCII 0Dh (CR)
ASCII 3Dh (=)
> ASCII 09h (TAB) -- 1.2 버전에서 제거됨
이 문자들은 언제나 이스케이프되어야 한다. 추가적으로, 크리티컬 문자를
인코드하는 기법(다음 섹션에 설졍)은 어떤 문자라도 이스케이프할 수 있다.
yDecoder는 이스케이프 문자 다음에 오는 어떤 문자라도 디코딩 할 수 있어야 한다.
이 4문자가 바이너리 자료에서 나타날 확률은 대략 0.4%이다. 평균적으로
이 4 문자만 이스케이프 될 때 이스케이프 처리는 약 1.6%의 오버헤드를 가져온다.
각 줄의 캐리지 리턴(CR)과 라인피드(LF)의 오버헤드는 개발자가 정의한 줄 길이에
달려있다. 헤더(앞부분 정보)와 트레일러(뒷부분 정보)는 상대적으로 매우 작아,
무시해도 될 만하다.
> (1.2) 주위깊은 인코더 제작자는 TAB(09h)와 SPACES(20h)가 줄의 첫번째 컬럼이나
> 마지막 컬럼에 나타나면 그것들을 인코드 할 것이다.
> TCP 스트림에 직접 쓰는 구현자는 첫번째 컬럼의 점을 두개로 만들거나 아니면
> 인코드 해야만 한다.
인코딩 기법
---------------------------------------------------------------------------
전형적인 인코딩 과정은 다음과 같이 보일 것이다 :
1. 입력 스트림에서 문자를 가져온다.
2. 문자의 아스키 값에 42를 더하고 256으로 나눈 나머지를 구한다.
3. 결과값이 크리티컬 문자 (이전 섹션에서 정의 된 것들)이라면, 출력 스트림에
이스케이프 문자를 쓰고 문자의 아스키값에 64를 더하고 256으로 나눈 나머지를
구한다. (모호함 : 최초의 입력 문자(1번)에 대한 처리인가, 아니면 일단 42를
더하고 256으로 나눈 나머지(2번)에 대한 처리인가?)
4. 문자를 출력 스트림에 써 준다.
5. 처음부터 반복한다.
현존하는 표준 프로토콜(주로 NNTP)을 통한 전송을 용이하게 하기 위해 CR/LF 쌍이
매 n 문자 뒤에서 출력 스트림에 쓰여져야 한다. n은 줄의 길이이며 주로 128이나
256이다.
>(1.2) 추가적인 경험 정보를 보라.
크리티컬 문자가 줄의 n 위치(즉, 맨 마지막 컬럼)에 나타날 경우, 이스케이프
문자와 인코딩된 크리티컬 문자는 항상 CR/LF이전의 같은 줄에 있어야한다.
이럴때에, 실제 이 줄의 문자 개수는 n + 1 이 된다. 간단히 말해 이것은 한 줄은
이스케이프 문자로 끝 날 수 없으며, n+1 줄은 인코딩된 크리티컬 문자로 끝나야만
한다.
헤더(인코딩 시작부분에 정보를 둔 것)와 트레일러(인코딩 끝에 정보를 둔것)
---------------------------------------------------------------------------
다른 인코딩 방식과 비슷하게, yEnc는 데이타 블록의 처음과 끝에 특별한 표시를
하는 예약된 줄이 있다. 이 이 블록들은 어떤 8비트 아스키 텍스트 파일에라도
포함될 수 있다. yDecoder 구현체는 헤더와 트레일러 블록 외부의 어떤 것도 다
무시해야 한다.
모든 예약어 줄은 이스케이프 문자('=')로 시작해야하며, 그 바로 뒤에
아스키코드 97h ('y')가 온다. y가 올바르게 인코딩된 크리티컬
문자가 아니기 때문에, 이 '=y' 로 이것이
헤더와 트레일러 예약어 줄들은 항상 이크케이프 문자로 시작해야만 하며,
그 뒤에는 줄의 타입을 지정하는 예약어가, 또 그 뒤에는 특정한 줄 타입에
적합한 예약어가 온다.
전형적인 헤더 줄은 다음과 같이 보일것이다 :
=ybegin line=128 size=123456 name=mybinary.dat
>(1.2)yEnc의 앞으로 나올 버전은 (있다면..) =ybegin 대신에 "=ybegin2"
>를 예약어로 쓸 수도 있다. 디코더는 꼭 =ybegin 다음에 공백이 붙은
> "=ybegin "으로 헤더 줄을 검사해야만 한다.
>(1.2) "line=" "size=" "name=" 파라미터가 =ybegin 다음에 나타나지 않는다면
>이것은 yEnd 헤더 줄이 아니라 yEnc에 관해 언급하는 텍스트 메시지의 일부일
>것이다. 이럴 경우 디코더는 그 메시지에 바이너리가 없다고 인식해야한다.
헤더 줄은 항상 "ybegin" 예약어로 시작해야만 하며, 한 줄의 길이, 원래
바이너리의 크기(byte 로) 그리고 바이너리 파일의 이름을 포함해야 한다.
파일 이름은 항상 헤더 줄의 마지막 항목으로 와야 한다. 이렇게 해야
다른 키워드 들의 방해 없이 파일 이름의 모든 문자들이 정확하게 인식된다.
비록 큰 따옴표(아스키 22h, '"')가 기술적으로는 허락 되지만, 파일이름에
큰 따옴표를 쓰는 것은 좋지 않다.
> (1.2): 예약어 앞 뒤의 공백은 디코더에 의해 무시된다!
> (1.2): 추가적인 경험 정보를 보라.
> 디코더를 구현할 때는 파일이름에 주의해야한다.
> 그것은 US-ASCII 이외의 문자(80h-FFh), 제어 문자들(01h..1Fh) 그리고 현재
> 플랫폼에서 충돌을 일으키는 문자(/ < | > : ? * @)를 포함 할 수 있다.
> 이것은 또 한 매우 긴 문자열 파라미터(최고 영어 256자) 일 수 있다.
전형적인 트레일러는 다음과 같다 :
=yend size=123456
트레일러 줄은 항상 "yend" 예약어로 시작하며, 원래 바이너리의 크기를 byte로
갖고 있어야 한다.
원래 바이너리의 사이즈는 트레일러에서 다시 한번 검사된다. yDecoder 구현은
헤더의 크기 값과 트레일러의 크기값, 그리고 실제로 디코드된 바이너리의 크기값을
비교해야만 한다. 만약 한개라도 다르다면 첨부 내용이 깨진것이고 경고를 내보내야만
한다. 결과적으로 나온 바이너리는 버려져야 한다. (1.2) 추가적인 경험 정보를
보라.
완전성 검사
---------------------------------------------------------------------------
yEnc로 인코딩된 문서는 인코딩된 이진 자료의 완전성을 검사하기 위해 32-bit
Cyclic Redunduncy Check(CRC)값도 포함 할 수 있다.
CRC32 값이 있다면, 그것은 트레일러 줄에 "crc32" 예약어로 추가된 것이다. 그런
트레일러 줄은 다음과 같이 보일 것이다 :
=yend size=123456 crc32=abcdef12
CRC32 값은 필수적인 것은 아니나, 존재한다면 꼭 처리해야 한다.
>(1.2) 추가적인 경험 정보를 보라.
yEnc로 인코딩된 간단한 파일
---------------------------------------------------------------------------
다음은 실제로 yEnc로 인코딩된 파일 븍록에서 발취된 것이다 :
=ybegin line=128 size=111401 name=al_larsonbw030_ball.jpg
)_)=J*:tpsp*++++V+V**)_*m*0./0/.00/011024:44334>896:A>....
....
....
....R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄
쨈R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R甄R繼)_
=yend size=111401
www.yenc.org에서 완전하게 인코딩된 샘플을 볼 수 있다.
멀티 파트로 인코딩된 바이너리
---------------------------------------------------------------------------
인터넷으로 전송하기위해 큰 바이너리 파일을 여러 부분으로 나누는 경우가 자주
있다. 그런 바이너리들은 종종 몇몇 부분을 잃거나 데이타가 깨져 사용할 수 없게
되는 경우가 있다.
이런 문제를 처리하기 위해 yEncode 는 "ypart"와 멀티파트 바이너리를 처리하기 위한
몇몇 추가적인 예약어들을 정의한다.
각 개별적인 파일의 부분은 표준 "ybegin" 헤더 줄로 시작하지만 추가적인 예약어
"part"가 각 부분의 번호와 멀티파트 바이너리 파일임을 인식하기 위해 추가된다.
"part"예약어가 헤더에 추가되면, 그 다음 줄은 그 부분에 대한 정보를 가진 "ypart"
예약어 줄이 와야 한다.
"ypart" 예약어 줄은 "begin"과 "end" 예약어를 필요로 하며, 이것은 바이트 단위로
원래 파일의 블록에서 시작점과 끝점을 의미한다.
(즉, "이 부분은 원래 파일의 xx byte 에서 yy byte 까지이다" 라는 의미)
파일의 부분은 살짝 수정된 "ypart" 트레일러 줄로 끝나야한다. 추가적인 예약어
"part"가 부분 번호를 지정하기 위해 추가 된다. 이 부분 번호는 헤더 줄의 부분
번호와 일치해야한다.
> (1.2) "total" 예약어도 함께 추가 되어야만 한다.
> 이 total의 번호는 헤더에서 발견되는 부분의 모든 개수와 일치해야한다.
> yEnc 의 첫번째 구현은 이 파라미터를 포함하지 않는다.
트레일러 줄은 또한 "pcrc32" 예약어도 포함해야한다. 이것은 바로 전의 인코딩된
부분의 CRC32를 의미한다. 늘 그렇듯, 전체 인코딩된 바이너리의 CRC32를 나타내는
"crc32"예약어는 필수사항은 아니다
단일 인코딩 yEnc 문서와는 달리, 멀티 파트로 인코딩된 문서에서 트레일러의 "size"
예약어는 전체 파일의 크기를 의미하는게 아니라 현재 부분의 크기를 의미한다.
완전성 검사를 위해 디코더 구현은 "ypart"줄의 "begin"과 "end" 예약어에 있는
각 부분의 예상 크기를 다시 계산해야한다. 예상 크기가 "yend" 줄에 있는 부분
크기와 다르다면 그 파일은 깨진것이다.
멀티파트로 인코딩된 바이너리는 다음과 같이 보인다 :
> (1.1) =ybegin part=1 line=128 size=500000 name=mybinary.dat
> (1.2) =ybegin part=1 total=10 line=128 size=500000 name=mybinary.dat
=ypart begin=1 end=100000
.... data
=yend size=100000 part=1 pcrc32=abcdef12
=ybegin part=5 line=128 size=500000 name=mybinary.dat
=ypart begin=400001 end=500000
.... data
=yend size=100000 part=10 pcrc32=12a45c78 crc32=abcdef12
만약 디코더가 멀티파트 지원을 구현하지 않았거나 멀티파트 인코딩된 바이너리를
인식하는데 실패한다면, 이것은 "ybegin" 줄의 "size" 예약어의 값과 "yend"줄의
"size" 예약어의 값이 다르기 때문에 각 파일의 부분을 성공적으로 디코드 할 수
없다.
멀티파트 바이너리들은 일반적으로 깨지기 쉽다. 단지 제대로 인식되지 않는
깨진 부분 때문에 헛된 수백 메가 바이트의 전송이 소중한 대역폭의 낭비가 된다.
yEnc는 "begin"과 "end" 예약어의 사용으로 디코더가 큰 파일에서 각 개별 부분의
위치를 식별할 수 있게 한다. 이로인해 서로 다른 소스에서 온 각 부분들이 부분들의
크기에 상관없이 하나로 합쳐질 수 있게 된다.
이 기능은 yEnc만의 것이며, 인코더를 구현할 때 쉽게 추가할 수 있다.
제목 줄 관행
---------------------------------------------------------------------------
표준 단일 yEnc 인코딩된 바이너리는 제목 줄에 특별한 관행이 필요 없다. 그러나
yEnc 인코딩된 바이너리는 yEnc 포맷이 널리 구현 될 때까지는 명확하게 yEnc로
인코딩 되었다고 명시하는것이 좋다.
단일 yEnc 인코딩된 바이너리를 위한 제목 줄을 제안하자면 :
[Comment1] "파일이름" 12345 yEnc bytes [Comment2]
[Comment1]과 [Comment2]는 선택적이다. 파일 이름은 항상 큰 따옴표로 묶여 있어야
하는데 이것은 파일 이름이 공백이라든가 특수 문자를 포함할 때도 쉽게 인식되기
때문이다. "yEnc"라는 단어는 파일 크기와 bytes 라는 단어 사이에 와야 한다.
>(1.2) 추가적인 경험 정보를 보라.
> "yEnc"라는 단어를 파일이름 + bytes 혹은 bytes+comment2 사이에 오게 해도 된다.
멀티파트 자료는 항상 멀티파트로 인식되어야만 한다. 단일 yEnc 인코딩된 바이너리와
마찬가지로 멀티파트 자료들도 yEnc가 주류가 될때까지는 yEnc로 인식 될 수 있는
표시를 해야한다.
멀티파트 바이너리를 위해 (강력하게) 권하는 제목 줄은 다음과 같다 :
[Comment1] "파일이름" yEnc (부분번호/전체부분개수) [크기] [Comment2]
다시말하지만, [Comment1]과 [Comment2]는 선택적이다. [크기]도 여기서는
선택적이다. 파일 이름은 큰 따옴표로 둘러싸야만 한다. "yEnc" 예약어는 필수이며
꼭 파일 이름과 크기(혹은 크기가 생략되었다면 Comment2)사이에 와야 한다.
다음 수정판에서는 "yEnc"와 부분번호의 열기 괄호('(') 사이에 추가적인 정보를
명시할 수 도 있다.
>(1.2) 추가적인 경험 정보를 보라.
> "yEnc" 를 (#/#)+size 혹은 size+comment2 사이에 두어도 된다.
>(1.2) 깨진 메시지 다루기
>(1.2) -------------------------------------------------------------------
디코더는 가능하면 오류검사를 해야만 한다.
사용자는 깨진 메시지에 대한 경고를 봐야만한다.
경고기능을 꺼두었다면 바이너리를 저장할 때 오류 메시지도 파일이름에 함께
저장하기를 권한다. 예:
picture(size-error).jpg
homemovie(crc32-error).avi
document(line-error).rtf
longmusic(missing-parts).mp3
깨진 바이너리를 저장해도 상관없다. (부분적으로 사용가능할 수 있으니)
하지만 감지된 오류를 사용자가 전혀 못보게 하는것은 안된다!
yEnc는 자료가 깨지는 것을 감지할 수 있게 설계되었다.
유능한 유즈넷 사용자들은 깨진 부분을 다른 곳에서 가져올 수도 있다.
저작권
---------------------------------------------------------------------------
yEnc 인코딩 기법은 공개(public domain)되어있다. 누구나 복사하고 사용하고 구현 할
수 있다.
이 문서와 yEnc 인코딩 기법은 어떤 법에 의해서도 보호 받거나 제한될 수 없으며
특허권을 얻을 수도 없다.
이 문서는 원작자를 표기하는한 자유롭게 배포될 수 있다.
이것은 당신만이 한 일이라고 주장하지 말라!
공개된 예제 프로그램들을 www.yenc.org에서 구할 수 있다.
# by | 2004/04/19 22:41 | 프로그래밍 | 트랙백 | 덧글(0)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]