맨위로가기

Uuencoding

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

1. 개요

Uuencoding은 바이너리 데이터를 ASCII 텍스트로 인코딩하는 데 사용되는 오래된 방식이다. 이 방식은 주로 텍스트 기반 전송 환경에서 바이너리 파일을 전송하기 위해 개발되었으며, 3바이트의 데이터를 4개의 ASCII 문자로 변환하여 33% 이상의 데이터 오버헤드가 발생한다. Uuencode는 헤더, 데이터, 그리고 파일의 끝을 나타내는 방식으로 구성된다. 인코딩 과정에서 3개의 8비트 값을 4개의 6비트 값으로 변환하여 ASCII 문자에 할당한다. 초기 버전에서는 공백 문자 처리, 전송 오류 감지, 그리고 ASCII 이외의 문자 코드 지원에 문제가 있었지만, 이러한 문제점을 해결하기 위해 체크섬 추가, xxencode 방식 개발 등의 다양한 시도가 이루어졌다. 현재는 MIME에서 Base64 방식을 채택하면서 사용 빈도가 줄었지만, 일부 시스템이나 프로그래밍 언어에서는 여전히 지원하고 있다.

2. 역사

초기 유닉스 계열 운영 체제에서는 UUCP라고 불리는 프로토콜로 전자 메일과 넷 뉴스의 배송이 이루어졌다. 이들은 텍스트 데이터만 처리할 수 있었기 때문에, 바이너리 파일을 텍스트 데이터로 변환하여 전송하는 방법으로 '''uuencode'''가 제공되었다. uuencode는 '''Unix to Unix ENCODE'''의 약자이다.

이후 인터넷 환경이 정비되고, UUCP보다 TCP/IP가 일반적이 되었지만, 전자 메일과 넷 뉴스는 SMTP, NNTP와 같은 텍스트 기반의 정보 교환이었기 때문에, uuencode는 여전히 널리 사용되었다.

uuencode에는 몇 가지 파생 형식이 있기 때문에, MIME에서는 의도적으로 uuencode를 채택하지 않고, 새롭게 Base64를 정의했다. 현재는 이 Base64가 널리 사용되고 있다.

3. 인코딩 형식

uuencode 파일은 `begin ` 형식의 헤더 라인으로 시작한다. 여기서 ``는 3개의 8진수로 표현되는 파일의 유닉스 파일 권한(예: 644, 744)을 나타내며, ``은 바이너리 데이터를 다시 생성할 때 사용할 파일 이름이다.

각 데이터 라인은 `` 형식을 사용한다. ``는 해당 라인에서 인코딩된 데이터 바이트 수를 나타내는 문자이다. 이는 실제 바이트 수에 32를 더한 ASCII 문자이며, 예외적으로 그레이브 악센트 "`" (ASCII 코드 96)는 0바이트를 의미한다. 마지막 줄을 제외하고, 대부분의 데이터 라인은 45바이트의 인코딩된 데이터(인코딩 후 60자)를 가지므로, 대부분의 길이 값은 'M'(32 + 45 = ASCII 코드 77)이다.

``는 인코딩된 문자이다. 3옥텟(24비트)을 4개의 6비트 값으로 변환하여 ASCII 문자에 할당한다. 6비트 값에 0x20을 더한 값의 하위 6비트를 ASCII 값으로 한다. 원래 "000000"은 스페이스 문자였지만, 과거에 행의 끝 스페이스를 제거하는 전송 시스템이 있었기 때문에 "`"로 대체되었다.

파일은 다음 두 줄로 끝난다.

`

end

`

두 번째 줄은 줄 길이를 나타내는 문자이며, 그레이브 악센트는 0바이트를 나타낸다.

"Cat"이라는 3옥텟 데이터를 ASCII의 4문자로 변환하는 예시는 다음과 같다.

원본 데이터Cat
옥텟 값010000110110000101110100
인코딩 후의 ASCII 문자0V%T



6비트 데이터와 ASCII 문자의 변환표는 다음과 같다.

데이터문자데이터문자데이터문자데이터문자
0000000스페이스 또는 `16010000032100000@48110000P
1000001!17010001133100001A49110001Q
2000010"18010010234100010B50110010R
3000011#19010011335100011C51110011S
4000100$20010100436100100D52110100T
5000101%21010101537100101E53110101U
6000110&22010110638100110F54110110V
7000111'23010111739100111G55110111W
8001000(24011000840101000H56111000X
9001001)25011001941101001I57111001Y
10001010*26011010:42101010J58111010Z
11001011+27011011;43101011K59111011[
12001100,28011100<44101100L60111100\\
13001101-29011101=45101101M61111101]
14001110.30011110>46101110N62111110^
15001111/31011111?47101111O63111111_


4. 인코딩/디코딩 메커니즘

Uuencoding은 3바이트(24비트)를 4개의 6비트 그룹으로 나누어 인코딩한다. 각 6비트 그룹은 0에서 63 사이의 값을 가지며, 여기에 32를 더하여 ASCII 문자로 변환한다. 이 과정을 통해 3바이트 데이터는 4개의 출력 문자로 표현된다.[2]
인코딩 과정:1. 원본 데이터에서 3바이트(24비트)를 가져온다.

2. 24비트를 6비트씩 4개의 그룹으로 나눈다. 각 그룹은 0~63 사이의 값을 가진다.

3. 각 6비트 값에 32(0x20)를 더한다. 이로써 32(" " 스페이스)에서 95("_" 밑줄) 사이의 ASCII 코드값을 얻게 된다.

4. 96("`" 억음 부호)는 "특수 문자"로, 이 범위의 논리적 확장이다.

5. 각 ASCII 코드값에 해당하는 문자를 출력한다.
디코딩 과정:1. 인코딩된 문자열에서 각 문자의 ASCII 코드값을 얻는다.

2. ASCII 코드값에서 32(0x20)를 뺀다.

3. 4개의 6비트 값을 연결하여 24비트(3바이트)를 복원한다.
"Cat" 인코딩 예시:

원본 문자Cat
원본 ASCII, 십진법6797116
ASCII, 이진법010000110110000101110100
새로운 십진법 값1654552
+3248863784
Uuencoded 문자0V%T


특수 문자 처리:


  • 값 0은 일반적으로 억음 부호(`)(ASCII 코드 96) 문자로 인코딩되지만, GNU sharutils와 같은 일부 구현에서는 스페이스 문자를 사용하기도 한다.[2]
  • 원본 데이터의 길이가 3의 배수가 아닌 경우, 패딩 바이트가 추가된다.

4. 1. Uuencode 테이블

코드ASCII
문자rowspan="17"|비트ASCII
코드ASCII
문자rowspan="17"|비트ASCII
코드ASCII
문자rowspan="17"|비트ASCII
코드ASCII
문자0096`164803264@4880P0133!174913365A4981Q0234"185023466B5082R0335#195133567C5183S0436$205243668D5284T0537%215353769E5385U0638&225463870F5486V0739'235573971G5587W0840(245684072H5688X0941)255794173I5789Y1042*2658:4274J5890Z1143+2759;4375K5991[1244,2860<4476L6092\1345-2961=4577M6193]1446.3062>4678N6294^1547/3163?4779O6395_






위 표는 6비트 값과 해당 ASCII 문자와의 관계를 나타낸다. 원래 '000000'은 스페이스 문자였지만, 과거 일부 전송 시스템에서 행의 끝에 오는 스페이스를 제거하는 문제가 있어 "`" (억음 부호)로 대체되었다.[2] 일부 인코더는 억음 부호 대신 스페이스(코드 32)를 생성할 수 있으며, 일부 디코더는 스페이스가 포함된 데이터를 디코딩하지 못할 수 있다.

5. 파생 형식

초기 형식의 문제점들을 해결하기 위해 다양한 파생 형식들이 등장했다.[1]

공백 문제는 공백을 "`"(그레이브 악센트)로 대체함으로써 해결되었고, 현재 널리 사용되는 TCP/IP 환경에서는 TCP에서 전송 오류를 감지한다.[1] 또한 SMTP나 NNTP와 같이 널리 사용되는 프로토콜들은 ASCII를 전제로 하고 있어, 이러한 환경에서는 문제가 발생하는 경우가 드물다.[1]

5. 1. 문제점

초기 형식에는 다음과 같은 문제가 있었다.

이러한 문제를 해결하기 위해 많은 파생 형식이 탄생했다.[1]

공백 문제는 공백을 "`"로 대체함으로써 해결되었다.[1] 또한 현재 많이 사용되는 TCP/IP에서는 전송 오류가 TCP에서 감지된다.[1] 마찬가지로 많이 사용되는 SMTP나 NNTP도 ASCII를 전제로 하고 있다.[1] 따라서 이러한 환경에서 문제가 발생하는 경우는 드물다.[1]

5. 2. 해결 방안

메일 등에서 행 끝 공백을 삭제하는 시스템으로 인해 발생하는 문제, 전송 오류로 인한 문자 깨짐, ASCII를 전제로 한 EBCDIC 등의 시스템에서의 문제와 같은 초기 형식의 문제점을 해결하기 위해 다양한 파생 형식이 등장했다.

공백 문제는 공백 대신 그레이브 악센트(`)를 사용하는 것으로 해결되었다. MINIX 3.1.2a의 uue 명령 출력 예시는 다음과 같다.[1]

사용 문자
"#$%&'()*+,-./0123456789:;<=>?
begin 644 testimg.png



행 마지막에 1자를 추가하여 공백 문제를 해결하고, 알파벳 소문자 역순으로 추가된 문자를 통해 행 분할 전송 시 복원에 사용한다. 첫 문자는 옥텟 수를 나타내어 디코딩 시 마지막 문자가 무시되어도 정상 디코딩될 가능성을 높인다.[1]

Mark Horton이 작성하고 Alan J. Rosenthatl이 체크섬을 추가한 uuencode.c 5.3-2 (Berkeley) 3/1/88의 출력은 다음과 같다. 원본 데이터의 옥텟 수도 추가되었다.[1]

```text

begin 644 testimg.png

MB5!.1PT*&@H````-24A$4@```"`````@"`8```!S>GKT````!&=!34$``+&/`

M"_QA!0```$=)1$%46$?MUK$-`"`(!$#S-'QR

M^^ZYH9TJ,!H%"!`@0(``@1CMTO<9F$4!`@0($"!`X+?`!I?UJM5MS!;U````!

)`$E%3D2N0F""R

``

end

size 144

```

Richard Marks가 DOS용으로 작성한 uuencode에 -L 옵션을 사용하여 체크섬을 추가한 예시는 다음과 같다. 체크섬 연산 방법이 달라 호환되지 않으며, 행 단위 및 전체 체크섬이 추가되었다.[1]

```text

section 1 of 1 of file testimg.png < uuencode 96 (v50) by R.E.M. >

begin 644 testimg.png

MB5!.1PT*&@H````-24A$4@```"`````@"`8```!S>GKT````!&=!34$``+&/C

M"_QA!0```$=)1$%46$?MUK$-`"`(!$#S-'Q9

M^^ZYH9TJ,!H%"!`@0(``@1CMTO<9F$4!`@0($"!`X+?`!I?UJM5MS!;U````7

)`$E%3D2N0F""?

``

end

sum -r/size 58653/233 section (from "begin" to "end")

sum -r/size 18364/144 entire input file

```

ASCII 문자 대신 다른 문자 집합을 사용하는 xxencode는 다음과 같다. xxencode.c 5.3 (Berkeley) 1/22/85에 의한 출력이다.[1]

```text

begin 644 testimg.png

hWJ-CFko84Uc++++BGIV2IU+++0+++++U0+M+++-nSbfo++++-4R-HI2++94D

h0zlV-E+++2R7F23IK2Thpf2B+0+6-21QTqV2rE+8amDtIjpQUmgWgh8SnB5l

hyyutcNoeA-c30-+UE6++UFXhojQNa2I-+UE620-+s9T+-dTpehJhn-Pp++++

7+2Z3HYGiEa00

+

end

```

"000000"부터 "111111"을 "+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"에 할당한다. uuencode는 ASCII 문자를 사용하지만, EBCDIC 문자 코드를 사용하는 구현에서는 처리할 수 없는 문자가 있어, 사용 문자를 변경한 것이 xxencode이다. 이는 오래된 전송 경로를 위한 기법이며, 인터넷에서는 ASCII를 사용할 수 없는 경우가 드물어 거의 사용되지 않는다. uuencode와는 호환되지 않는다.[1]

POSIX에서는 기존 알고리즘을 "역사적인 알고리즘(uuencode Historical Algorithm)"으로 정의하고, 새로운 알고리즘을 정의했다.[1]

```text

begin-base64 644 testimg.png

iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAABGdBTUEAALGPC/xhBQAAAEdJREFU

WEft1rENACAIBEDcf2hE3QAKmyP5Uv1cgysistKezNHx++65oZ0qMBoFCBAgQIAAgRjt0vcZmEUB

AgQIECBA4LfABpf1qtVtzBb1AAAAAElFTkSuQmCC

6. 다른 인코딩 방식과의 관계

제한된 문자 범위에도 불구하고, uuencode된 데이터는 EBCDIC와 같은 비ASCII 문자 집합을 사용하는 특정 컴퓨터를 통과할 때 손상될 수 있었다. 이 문제를 해결하려는 시도 중 하나는 알파벳, 숫자와 더하기 및 빼기 기호만 사용하는 xxencode 형식이다. 오늘날 더 흔하게 사용되는 것은 ASCII 32-95와 대조적으로 알파벳 숫자만 사용하는 동일한 개념을 기반으로 하는 Base64 형식이다. 세 가지 형식 모두 입력 데이터를 표현하기 위해 6비트(64개의 다른 문자)를 사용한다.

Base64는 uuencode 프로그램에서도 생성될 수 있으며 실제 문자 변환을 제외하고 형식도 유사하다. MIME에서는 의도적으로 uuencode를 채택하지 않고, 새롭게 Base64를 정의했는데, 현재는 이 Base64가 널리 사용되고 있다.[1]

또 다른 대안은 4개의 바이너리 문자를 5개의 ASCII 문자로 인코딩하는 Ascii85이다. Ascii85는 PostScript 및 PDF 형식에서 사용된다.

xxencode는 ASCII 문자를 사용하지만, EBCDIC라고 불리는 문자 코드를 사용하는 구현에서는 처리할 수 없는 문자가 있었기 때문에, 사용 문자를 바꾼 것이다. 극히 오래된 전송 경로를 위한 기법이며, 인터넷에서는 ASCII를 사용할 수 없는 경우는 드물기 때문에, xxencode는 거의 사용되지 않는다. uuencode와의 호환성은 전혀 없다.[2]

다음은 요약된 내용이다.

인코딩 방식사용 문자특징
xxencode알파벳, 숫자, +, '-'EBCDIC 환경을 고려하여 개발됨. 현재는 거의 사용되지 않음.
Base64알파벳, 숫자, +, '/'uuencode와 유사하며, 현재 널리 사용됨.
Ascii855개의 ASCII 문자4개의 바이너리 문자를 5개의 ASCII 문자로 인코딩. PostScript 및 PDF 형식에서 사용됨.


7. 단점

uuencoding은 미리 서식이 지정된 3바이트를 4바이트로 변환하고 시작/종료 태그, 파일 이름 및 구분 기호를 추가한다. 이는 소스 자체와 비교하여 최소 33%의 데이터 오버헤드를 추가하지만, uuencoding 전에 파일을 압축하여 어느 정도 보완할 수 있다.[1]

8. 언어별 지원

파이썬은 "uu" 코덱을 사용하여 `codecs` 모듈을 통해 uuencoding을 지원한다.

파이썬 2 (2020년 1월 1일 지원 중단)에서의 사용 예시는 다음과 같다.

```

$ python -c 'print "Cat".encode("uu")'

begin 666

#0V%T

end

```

파이썬 3 에서는 `codecs` 모듈을 직접 가져와 사용해야 하며, 사용 예시는 다음과 같다.

```

$ python3 -c "from codecs import encode;print(encode(b'Cat', 'uu'))"

b'begin 666 \n#0V%T\n \nend\n'

```

디코딩 예시는 다음과 같다.

```

$ python3 -c "from codecs import decode;print(decode(b'begin 666 \n#0V%T\n \nend\n', 'uu'))"

b'Cat'

```

Perl은 `pack()` 및 `unpack()` 연산자와 "u" 형식 문자열을 사용하여 uuencoding을 기본 지원한다. 사용 예시는 다음과 같다.

```

$ perl -e 'print pack("u","Cat")'

#0V%T

```

`unpack`을 사용한 디코딩 예시는 다음과 같다.

```

$ perl -e 'print unpack("u","#0V%T")'

Cat

```

올바른 uuencoded 파일 생성을 위해서는 모듈을 사용하거나 추가 코드가 필요하다.

```

$ perl -ple 'BEGIN{use File::Basename;$/=undef;$sn=basename($ARGV[0]);} $_= "begin 600 $sn\n".(pack "u", $_)."`\nend" if $_' /some/file/to_encode.gz

9. MIME

MIME에서는 의도적으로 uuencode를 채택하지 않고, 새롭게 Base64를 정의했다. 현재는 이 Base64가 널리 사용되고 있다.

전자 메일이나 인터넷 뉴스에서 Uuencode를 사용하는 경우, 본문 내에 Uuencode 문자열을 직접 붙여넣는 방식이 사용되었다. MIME에서는 의도적으로 Uuencode를 제외했기 때문에, Uuencode를 멀티파트(multipart)로 다루는 방법은 정의되어 있지 않다. 하지만, 멀티파트의 틀 내에서 다루는 구현이 다수 등장했다. 크게 두 가지 방법이 있는데, 하나는 Content-Transfer-Encoding에서 x-uuencode를 나타내는 것이고, 다른 하나는 Content-Type에서 application/x-uuencode를 나타내는 것이다. 전자의 구현이 더 많다.

아래는 Content-Transfer-Encoding에 x-uuencode를 사용하는 예시이다.

```

Content-Type: image/png; name="testimg.png"

Content-Transfer-Encoding: x-uuencode

Content-Disposition: inline; filename="testimg.png"

begin 644 testimg.png

MB5!.1PT*&@H````-24A$4@```"`````@"`8```!S>GKT````!&=!34$``+&/

M"_QA!0```$=)1$%46$?MUK$-`"`(!$#S-'Q

M^^ZYH9TJ,!H%"!`@0(``@1CMTO<9F$4!`@0($"!`X+?`!I?UJM5MS!;U````

)`$E%3D2N0F""

`

end

```

아래는 Content-Type에 application/x-uuencode를 사용하는 예시이다.

```

Content-Type: application/x-uuencode; name="testimg.png"

Content-Disposition: attachment; filename="testimg.png"

Content-Transfer-Encoding: 7bit

begin 644 testimg.png

MB5!.1PT*&@H````-24A$4@```"`````@"`8```!S>GKT````!&=!34$``+&/

M"_QA!0```$=)1$%46$?MUK$-`"`(!$#S-'Q

M^^ZYH9TJ,!H%"!`@0(``@1CMTO<9F$4!`@0($"!`X+?`!I?UJM5MS!;U````

)`$E%3D2N0F""

`

end

참조

[1] 웹사이트 UUENCODE(1C) UNIX Programmer's Manual https://www.tuhs.org[...] 2020-11-10
[2] 웹사이트 uuencode.c source https://fossies.org/[...] 2021-06-05
[3] 웹사이트 PerlPowerTools source https://metacpan.org[...] 2024-02-12
[4] 웹사이트 uuencode.pl source http://main.linuxfoc[...] 2024-02-12
[5] 웹인용 UUENCODE(1C) UNIX Programmer's Manual https://www.tuhs.org[...] 2020-11-10


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

문의하기 : help@durumis.com