아스키와 바이너리 (ASCII, Binary)

마임을 이해하기 위해서는 아스키와 바이너리에 대해 알고 있어야 합니다. 컴퓨터는 0 과 1로 이뤄진 이진수만 이해할 수 있습니다. "바이너리(binary)"라는 단어가 "이진의", "이진수의"라는 의미입니다.

컴퓨터에서 'ㄱ,ㄴ,ㄷ' 이나 'a, b, Z, T,..' 등의 문자를 표시하려면 각각의 문자를 숫자로 지정해줄 필요가 있습니다. 즉 'a는 십진수로 97이다', 'z는 122다' ... 이런 식으로 규정을 해야 했습니다. 이렇게 규정을 하면 그 값을 이진수로 변환해서 컴퓨터가 각 문자를 식별할 수 있기 때문입니다.

컴퓨터 등장 초기에는 오늘날의 피씨처럼 공통된 표준이 정립되어 있지 않았습니다. 각자 자기 식으로 하드웨어를 제작했고 거기에 맞게 소프트웨어를 만들었습니다. 각 문자에 해당하는 값 역시 컴퓨터마다 달랐습니다. 이렇다 보니 서로 다른 메이커에서 만든 컴퓨터 간에 데이타를 교환해야 할 필요가 생긴 경우 굉장히 곤란한 상황이 발생합니다. A 컴퓨터에서는 'abc'라고 저장한 것인데 B 컴퓨터에서 열어보면 '!#F'라고 열린다든지 하는 일이 생겼습니다.

이에 "ANSI"라는 표준을 정하는 곳에서 각 문자에 해당하는 숫자값을 하나로 통일하자는 목적 아래 "ASCII"라는 표준을 만듭니다. "ASCII"는 "American Standard Code for Information Interchange"의 약자입니다. 단어 뜻대로 정보 교환을 위한 미국 표준 코드입니다.

컴퓨터가 정보 처리를 할 때 사용하는 기본 단위는 바이트(byte)입니다. 바이트는 8비트를 줄인 말입니다. 이런 것이 1바이트입니다.

11001101

8자리의 이진수를 1바이트라고 하는 것입니다. 1바이트는 십진수로 고치면 최소 0(00000000)부터 최대 255(11111111) 사이의 값이 됩니다. ANSI는 0부터 255까지의 숫자를 알파벳과 특수문자에 하나하나 대응시켰습니다. a는 97, W는 87 ,... 이런 식으로 문자 마다 값을 지정을 했습니다. 그런데 왜 'a'를 1이나 2처럼 앞의 숫자로 할당하지 32라는 큰 숫자로 지정했을까요? 그것은 제어 문자(control character)라는 것이 필요했기 때문입니다. 당시 컴퓨터 단말기의 표준격인 TTY에 쓰이던 제어 문자를 위해 앞의 0-32를 남겨둬야 했습니다. 제어 문자는 폰트가 바뀐다든지, 전송의 끝을 알리는 문자 같은 특수한 작업, 기능, 이벤트를 알려주는 특수 문자입니다.

제어 문자에 할당한 0-32 다음 값인 33부터 화면상에 보여지는 보통의 문자를 짝지운 것입니다. 아스키 33은 !이고, 34는 ", 35는 #, ... 이렇게 하면 0부터 127까지 사용해서 모든 '문자'를 다 표시할 수 있습니다.[1] 따라서 8비트 중 128 부터 255까지는 사용할 필요가 없었습니다. 이것을 이진수로 바꿔보면 1바이트 이진수의 맨 첫 번째 자리는 사용할 필요가 없다는 것이 됩니다. 1111111가 127이니까요. 그래서 아스키 문자의 이진수 값은 첫 숫자가 0입니다. 이것을 잘 기억해 두세요."7비트 아스키 문자"라는 용어는 그런 원리로 등장한 것입니다.

이제 아스키가 뭔지, 왜 아스키 문자는 7비트인지, 그리고 첫 문자 값을 33으로 설정했는지 등이 이해되시죠? 이것이 도대체 마임과 무슨 상관이 있는가.

문제는 컴퓨터 사이에서 이동되는 파일이 모두 다 아스키 문자로 이뤄진 텍스트 파일은 아니였다는 데서 출발합니다.

인코딩과 디코딩

보통의 텍스트 파일을 보내고 받는 데는 ASCII라는 공통된 표준에 따르기만 하면 아무 문제가 없었습니다. 그런데 네트웍을 통해 아스키 파일이 아닌, 즉 '바이너리' 파일을 보낼 필요가 생깁니다. 바이너리 파일은 음악 파일이나 그래픽 파일, 무비 파일, 또는 (포매팅 정보가 담긴) 워드 프로세서로 만든 문서 파일 등입니다. 이들은 모두 8자리 이진수의 첫 번째 자리가 0으로 한정된 것이 아닌, 8비트 모두를 사용한다는 특징을 갖습니다. "8비트 데이타"입니다. (아스키 문자는 "7비트 데이타.")

이메일이나 기타 네트웍 상에서 데이타를 교환하는 시스템은 최초 아스키 문자로 이뤄진 파일만을 전송하는 것을 전제로 제작되었기 때문에 첫 번째 숫자가 1인 데이타가 섞여 있는 이들 8비트 바이너리 데이타를 제대로 전달할 수가 없었습니다. 바이너리 파일을 기존의 시스템 상에서 문제 없이 전달하기 위해서는 이들을 다시 "아스키 문자 파일" 바꾸어서 전달할 필요가 있었습니다. 즉, '바이너리'를 '텍스트'로 변환해야만 했습니다.

그것을 인코딩(encoding)이라 합니다. 바이너리 파일을 텍스트 파일로 바꾸는 것입니다. 디코딩(decoding)은 인코딩 된 텍스트 파일을 다시 바이너리 파일로 변환하는 해독 과정을 의미합니다.

그러면 초기 인코딩 방식의 대표적 표준인 "UUEncode(Unix-to-Unix Encode)" 방식의 원리를 통해 인코딩의 원리를 간단하게 살펴 봅시다. 어떤 바이너리 파일 데이타 중 3개의 바이트를 가져 왔을 때 다음과 같았다면,

10011100  00110011  11110000

8자리씩 총 24개의 비트입니다. 24개이므로 이것을 다시 6개짜리 4개로 바꿀 수 있습니다.

100111 000011  001111 110000

그 다음, 첫 두 자리에 0을 붙입니다.

00100111  00000011  00001111  00110000

이제 전부 첫 번째 숫자가 0이 되어서 조금더 아스키 코드에 가까와졌습니다.

그 다음, 각각에 십진수 32를 (이진수 100000) 더합니다. 조절 문자가 아닌, 화면에 보이는 보통의 문자 값으로 바꾸기 위해서입니다. 그렇게 하면 위 데이타는,

01100111  01000011  01001111  01110000

이 됩니다. 이제 이들은 모두 알파벳이나 기타 기호 등의 보통의 아스키 문자로 바꿀 수가 있게 됩니다.

이 과정을 거친 바이너리 파일은 아스키문자 파일이 되어서 종래의 이메일 시스템 등을 타고 아무 탈없이 전달될 수가 있습니다. 인코딩 된 바이너리 파일을 열어보면 이상한 문자가 가득 뜨는데 그런 이유입니다.

그러면 마임(MIME)이란?

MIME은 Multipurpose?Internet?Mail?Extensions?의 약자로 일종의 인코딩 방식입니다. MIME은 이메일과 함께 동봉할 첨부 파일(attachment file)을 텍스트 문자로 전환해서 이메일 시스템을 통해 전달 하기 위해 개발되었기 때문에 이름이 "Internet Mail Extension"입니다. 이제는 웹을 통해서 여러 형태의 파일을 전달하는 데 두루 쓰이고 있습니다.

왜 UUEncode 방식이 있는데 MIME이란 인코딩이 또 나타나게 되었을까요? UUEncode 방식에는 단점이 있었습니다. 문서 끝 부분의 공백이 사실은 공백이 아니라 변환되어야 할 값인데 공백을 무시하는 시스템의 경우엔 UUEncode 파일을 원형 그대로 전달 받을 수 없었다는 것 등의 단점이 있었습니다. 그래서 UUEncode 방식을 대폭 보강한 새로운 인코딩 방식이 등장하게 되었고 그것이 MIME입니다. MIME은 특히 기존의 UUEncode 방식에서는 없었던 파일 포맷(또는 Content-type) 정보도 함께 담을 수 있습니다. '지금 전달하는 이 파일은 GIF 파일이다.', 'MOV 파일이다.'처럼 그 파일의 종류를 나타내는 딱지를 붙일 수 있었습니다. 이렇게 MIME 에서 사용하는 인코딩 방식을 "base64"라고 합니다. 방식은 위에서 본 것과 유사합니다. 8비트 3개를 6비트 4개로 바꿔서 적절한 변형을 합니다.

이렇게 해서 텍스트만 전달될 수 있는 기존의 이메일 시스템에서도 바이너리 파일들을 자유롭게 주고 받을 수 있게 되었습니다. 8비트 바이너리 파일을 7비트의 아스키문자 파일로 바꿔주는 것입니다.

마임의 타입(Type)

마임으로 인코딩 한 파일은 "Content-type" 정보를 파일의 앞 부분에 담고 있습니다. 컨텐트 타입에는 여러 가지가 있습니다. 이런 얘기를 들어 본 적이 있을 것입니다. '어떤 마임 타입 (MIME type)이 웹브라우져에서 지원된다, 안된다.' 그것은 '특정 컨텐트 타입의 파일을 웹 서버로부터 전달받아서 웹브라우져가 열 수 있다, 아니다.'라는 의미입니다. 웹 브라우져가 웹 서버에 접속해서 html 문서를 요청하면서 html 문서 내에 담긴 이미지 태그내에 지정된 패쓰로부터 이미지 파일도 가져 옵니다. 이 때 그 패쓰에 있는 파일이 웹 브라우져에서 지원되는 마임 타입이라면 웹 브라우져 내에서 열 수 있습니다. .jpg, .gif 파일 등은 브라우져 내에서 바로 뜨는 것입니다.(모자익 웹브라우져 당시만 해도 이것은 획기적인 기능이었습니다. 모자익 이전의 웹브라우져는 .jpg, .gif 마임 타입을 직접 지원하지 않았기 때문에 외부 그래픽 프로그램이 구동되면서 이미지를 보여 줬습니다)

초기 웹 브라우져는 표준적인 마임 타입들(.gif, .jpg, .mov,...)은 무리 없이 열렸지만 그렇지 않은 유형은 그 파일을 열어줄 프로그램을 손수 지정해야 했습니다. 웹 브라우져 셋팅에 파일 포맷 별로 외부 프로그램을 연결하는 부분이 있었습니다. 그런데 마이크로소프트가 웹 브라우져를 불공정하게 운영체계에 통합하면서 마임 타입 지정이 OS 차원으로 넘어 갑니다. 윈도우즈 탐색기를 열어서 [보기 > 폴더옵션] 메뉴에 보면 아래 그림같이 "파일 형식"이라는 탭이 있습니다. 여기에서 파일 확장자나 마임 타입 별로 구동될 프로그램을 설정하게 되어 있습니다. gif 파일의 경우를 한 번 볼까요?

"내용 형식"(="Content-type")이라는 단어 옆에 "MIME"이라고 되어 있죠? MIME 타잎이 어떻게 설정되어 있는지를 자세히 봅시다. 가운데에 슬래쉬가 / 있고 슬래쉬 앞 부분에는 파일의 종류("image") 슬래쉬 뒷 부분은 파일의 포맷을("gif") 나타내고 있습니다. 이렇게 마임 타입은 "파일종류/파일포맷" 형태로 정의합니다.
몇 가지 예를 들어 봅시다.

application/msword
text/html
application/pdf
audio/mpeg

위의 대화상자를 보면, 마임 타입 밑에 연결 프로그램으로 인터넷 익스플로러가 설정되어 있습니다. 따라서 gif 파일을 데스크탑 상에서 더블 클릭할 때도 익스플로러를 통해 열립니다. 또는 웹 문서에 포함된 gif 파일은 바로 웹 브라우져내에서 열립니다. image/gif 마임 타입을 다른 그래픽 프로그램(예컨데 페이트샵 프로)과 연결하면, gif 파일이 포함된 웹 문서가 열릴 때마다 페인트샵 프로가 뜹니다. 데스크탑상에서 더블 클릭할 대도 페인트샵 프로가 뜨면서 엽니다.

#!/usr/bin/perl

foreach (33..127) {
	$letter = chr;
	print qq|$_: $letter\n|;
}