바이너리, 인코딩, 디코딩, ASCII, MIME, base64를 쉽게 이해하자!

바이너리

 

 컴퓨터는 0과 1로 이루어진 이진수만 이해할 수 있다. 바이너리라는 단어의 뜻은 이진수라는 의미이다.

즉 컴퓨터는 바이너리만을 이해할 수 있다.

 따라서 컴퓨터에서 ㄱㄴㄷ, abcd등의 문자를 표시하려면 각각의 문자를 숫자로 지정해줄 필요가 있다.
즉,  a는 10진수로 97이다. z는 10진수로 122이다. 그 값을 이진수로 변환해주면 컴퓨터가 이를 보고 문자를 식별할 수 있게 된 것이다.

 

'a' -> 10진수 97 -> 2진수 01100001

우리에게는 a라는 글자가 컴퓨터에게는 01100001인 것이다.

ASCII

 초창기 컴퓨터의 제조사마다 각자 지정방식이 다르니까 컴퓨터끼리 데이터 교환을 할 때 어려움을 겪었다.

어떤 컴퓨터에서는 abc로 인식이되는 데이터를 다른 컴퓨터에서 열면 !#F 이런식으로 열려버리는 문제가 발생하는 것이다. 따라서 이를 해결 하기 위해 American Standard Code for Information Interchange의 약자인 ASCII라는 표준이 이때 만들어 졌다. 단어 뜻대로 정보교환을 위한 미국표준코드 였다.

 

 컴퓨터가 정보를 처리할 때 사용하는 기본 단위는 바이트이다. 바이트는 8비트를 줄인말이다.
0000000 이렇게 비트가 8개, 8자리의 이진수를 1바이트라고 한다. 1바이트는 십진수로 고치면 최소0(00000000)부터 255(11111111) 사이의 값이 된다.
따라서 정보를 처리할 때의 최소 단위인 바이트안에 0부터 255까지의 숫자를 알파벳과 특수문자에 하나하나 대응시켰다.

 a는 97, W는 87 이런식.. 근데 a를 1로하면 편한데 왜 굳이 97로 했을까??
왜냐하면 조절문자라는 것이 필요했기 때문이다. 당시 컴퓨터의 단말기에서는 조절문자를 위해서 앞에 0~32를 남겨두어야했다. 조절문자는 폰트가 바뀐다든지 전송의 끝을 알리는 문자같은 특수한 작업, 기능, 이벤트를 알려주는 특수문자이다.

그 다음값인 33부터 화면상에 보이는 보통의 문자를 짝지었다. 33은 !이고 34는 " 35는 #..... 이렇게하면 0부터 127까지사용해서 '모든문자'를 다 표시할 수 있다.
따라서 8비트중 128부터 255까지는 사용할 필요가 없었다. 이것을 이진수로 바꿔보면 1바이트 이진수의 맨 첫번째 자리는 사용할 필요가 없다는 것이 된다.
01111111이 127 10000000이가 128이기 때문이다. 따라서 아스키 문자의 이진수 값의 첫 숫자는 0이다.
7비트 아스키 문자라는 용어는 이런 원리로 등장한 것이다. 

이제 아스키가 뭔지, 왜 7비트인지 왜 첫문자를 33부터 설정했는지 이해가 되었다.

 

인코딩, 디코딩

 

문제는 컴퓨터사이에서 이동되는 파일이 모두 다 아스키 문자로 이루어진 '텍스트 파일'은 아니었다는 것에서 출발한다.
보통의 텍스트 파일을 보내고 받는데는 ascii의 표준만따르면 아무 문제가 없었는데

아스키 파일이 아닌, 즉 '바이너리' 파일을 보낼 필요가 생겨버렸다. 이 바이너리 파일은 음악파일이나 그래픽파일, 무비파일, 워드파일 등 이들은 모두 8자리 이진수의 첫 번째 자리가 0으로 한정된 것이 아닌 8비트를 모두 사용한 다는 특징을 가지고 있다. 즉, 8비트 데이터이다.

앞서 아스키는 7비트 데이터라고 했다.  아스키코드로는 이 바이너리 파일을 텍스트화 불가능하다.

이메일등 데이터를 교환하는 시스템은 처음에 아스키 문자로 이뤄진 파일만을 전송하는 것을 전제로 제작되었기에
첫번째 숫자가 1인 데이타가 섞인 8비트 바이너리 데이터를 제대로 전달할 수가 없었다. 

바이너리 파일을 기존의 시스템 상에서 문제 없이 전달하기 위해서는 이들을 다시 아스키 문자 파일로 바꾸어(데이터 교환 시스템은 아스키 코드이어야 하기 때문) 전달할 필요가 있었다.

초기 인코딩 방식의 대표적 표준인 uuencode방식의 원리를 통해 인코딩 원리를 살펴보자. 
어떤 바이너리 파일 데이터 중 3개의 바이트를 가져 왔을 때 다음과 같다면

10011100 00110011 11110000 (8자리씩 총 24개의 비트) 24개이므로 이걸 다시 6개짜리 4개로 바꿀 수 있다.

100111 000011 001111 110000 그 다음 첫 두자리에 0을 붙이자.

00100111 00000011 00001111 00110000 이제 전부 첫 번째 숫자가 0이 되어서 조금 더 아스키 코드에 가까워졌다.

그 다음 각각에 10진수 32를(이진수 100000)더한다. 조절문자가 아닌 화면에 보이는 보통의 문자값으로 보이기 위해서이다. 그렇게 하면 위 데이터는
01100111 01000011 01001111 01110000이 된다. 이제 이들은 모두 알파벳이나 기타 기호 등의 보통의 아스키 문자로 바꿀 수 있게 되었다.(조절문자 제외)

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

 

MIME

그렇다면 MIME이란 무엇인가??
MIME은 Multipurpose Internet Main Extesions의 약자로 일종의 인코딩 방식이다.
MIME은 이메일과 함께 동봉할 첨부파일을 텍스트 문자로 전환해서 이메일 시스템을 통해 전달하기 위해 개발이 되었기 때문에 이름이 internet mail extension이다. 이제는 웹을 통해서 여러 형태의 파일을 전달하는데 두루 쓰이고 있다.

왜 UUEncode 방식이 있는데 MIME이란 인코딩이 또 나타나게 되었을까?? UUEncode 방식에는 하나의 단점이 있기 때문이다. 문서 끝 부분의 공백이 사실은 공백이 아니라 변환되어야할 '값'인데 공백을 무시하는 시스템의 경엔 UUEncode 파일을 원형 그대로 전달 받을 수 없기때문이다.

 

그래서 UUEncode 방식을 대폭 보강한 새로운 인코딩 방식이 MIME이다. 
MIME은 특히 기존의 UUEncode방식에는 없었던 파일 포맷(Content-type)정보도 함께 담을 수 있다.
'지금 전달하는 이 파일은 GIF 파일이다.' 'MOV파일이다' 처럼 그 파일의 종류를 나타내는 딱지를 붙일 수 있었다.

 

base64

이렇게 MIME에서 사용하는 인코딩 방식을 base64라고 한다 방식은 위에서 본 것과 유사하다.
8비트 3개를 6비트 4개로 바꿔서 적절한 변형을 한다. 이렇게 해서 텍스트만 전달될 수 있는 기존의 이메일 시스템에서도 바이너리 파일들을 자유롭게 주고 받을 수 있게 되었다. 8비트 바이너리 파일을 7비트의 아스키문자로 바꿔주는 것이다.

 

다시 정리하자면 문자를 전송하기 위해 설계된 Media(Email, HTML)를 이용해 플랫폼 독립적으로 Binary Data(이미지나 오디오)를 전송 할 필요가 있을 때, ASCII로 Encoding하여 전송하게 되면 여러가지 문제가 발생할 수 있다. 대표적인 문제는 ASCII는 7 bits Encoding인데 나머지 1bit를 처리하는 방식이 시스템 별로 상이하다. 일부 제어문자 (e.g. Line ending)의 경우 시스템 별로 다른 코드값을 갖는다.

 

위와 같은 문제로 ASCII는 시스템간 데이터를 전달하기에 안전하지가 않다. Base64는 ASCII 중 제어문자와 일부 특수문자를 제외한 64개의 안전한 출력 문자만 사용한다.

MIME의 타입

마임으로 인코딩 한 파일은 'content-type'정보를 파일의 앞 부분에 담고 있다. 콘텐츠 타입에는 여러가지가 있다.
웹 브라우저가 웹 서버에 접속해서 html문서를 요청하면서 html문서 내에 담긴 이미지 태그내에 지정된 경로로 부터 '이미지 파일'도 가져온다.

이 때 그 경로에 있는 파일이 웹 브라우저에서 지원되는 마임 타입이라면 웹 브라우저 내에서 열 수 있다.
따라서 .jpg, .gif파일 등은 브라우저 내에서 바로 뜨는 것 이다. 

엄청 예전의 웹 브라우저에는 .jpg, .gif 마임 타입을 지원하지 않았기 때문에 외부 그래픽 프로그램이 브라우저와 별도로 구동되는 형식으로 이미지를 보여주었다고 한다.

시간이 지나고 초기 웹 브라우져는 표준적인 마임들 (.gif, .jpg, .mov...)은 무리없이 열렸지만 그렇지 않은 유형은 그 파일을 열어줄 프로그램을 '손수' 지정해야 했다. 웹 브라우저 셋팅에 파일 포맷 별(지원하지 않는 파일 포맷)로 외부 프로그램(앞서 말한 외부 그래픽 프로그램으로 따로 실행시켜 보여줌)을 연결하는 부분이 있었다.

그런데 마이크로소프트가 웹 브라우저를 불공정하게 운영체계에 통합하면서 마임 타입 지정이 OS 차원으로 넘어간다.
윈도우의 파일형식에 파일 확장자나 마임 타입 별로 구동될 프로그램을 설정하게 되어있다.
.gif의 경우는 image/gif라고 설정이 되어 있다. 이렇게 마임타입은 '파일종류/파일포맷' 형태로 정의한다.
.css -> text/css  .doc -> application/msword .json -> application/json 이런식으로 말이다.

마임 타입 밑에 연결 프로그램으로 인터넷 익스프로러가 설정되어있다(윈도우의 기본설정) 
따라서 컴퓨터 내의 gif파일은 기본적으로 익스플로러에서 열린다. 또는 웹 문서에 포함된 gif파일은
바로 웹브라우저 내에서 열린다.

 

image/gif 마임 타입을 다른 그래픽 프로그램과 연결하면 gif파일이 포함된 웹 문서가 열릴 때마다
이걸 보여주기 위해서 다른 프로그램이 같이 뜨면서 열린다.

 

어떤 MIME타입이 웹브라우져에서 지원된다, 안된다라는 말은

특정 content-type의 파일을 웹 서버로 부터 전달받아서 웹브라우저가 열 수 있다. 아니다의 의미이다.