인코딩과 디코딩

보통의 텍스트 파일을 보내고 받는데는 위와 같이 ASCII 라는 공통된 표준에 따르기만 하면 아무 문제가 없었다. 그런데 네트웍을 통해 ASCII 파일이 아닌, 즉 바이너리 파일을 보낼 필요가 자주 발생하게 되었다.

 

바이너리 파일이라 함은 음악 파일이나 그래픽 파일, 무비 파일, 또는 워드프로세서로 만든 (포매팅 정보가 담긴) 문서 파일등을 의미한다. 이들은 모두 8 자리 이진수의 첫번째 자리가 '0'으로 한정된 것이 아닌, 8 비트 모두를 다 사용한다는 특징을 있다. 즉 8 비트 데이터이다. (아스키문자-->7비트 데이터)

 

그런데, 이메일이나 기타 네트웍상에 데이터를 교환하는 시스템은 애초 아스키 문자로 이뤄진 파일만을 전송하는 것을 전제로 제작되었기 때문에 첫번째 숫자가 1인 이들 바이너리 데이터를 제대로 전달할 수가 없었다.

 

따라서 이들 바이너리 파일(음악, 그래픽, 무비, 엑셀파일) 등을 기존의 시스템 상에서 문제없이 전달하기 위해서는 이들을 '아스키 문자 파일' 로 전달해야 했다. 즉. '텍스트' 형태로 변환해야만 했다. 이러한 작업을 일컬어 인코딩 (encoding) 이라고 한다.

 

디코딩은 당연히 인코딩된 텍스트 파일을 다시 바이너리 파일로 변환하는 해독과정을 의미한다. 그러면 초창기에 인코딩을 어떻게 했는지 초기 인코딩 방식의 대표적 표준인 UUEncode (Unix-to-Unix Encode) 방식의 원리를 통해 간단히 알아보자.

 

바이너리 파일에서 3 개의 바이트를 불러내 보면.
10011100, 00110011, 11110000

 

이러면 2진수 8자리씩 총 24개가 된다. 이들을 다시 6개짜리 4개로 재구성한다.
100111, 000011, 001111, 110000

그 다음 첫 두자리에 0을 붙입니다.
00100111, 00000011, 00001111, 00110000

 

이제 전부 첫번째 숫자가 0 이 되어서 조금 더 아스키코드와 유사한 형태로 재구성되었다. 그 다음엔 각각에 십진수 32 (이진수 100000)를 더한다. 왜? 그렇게 하면 조절문자가 아닌, '화면에 보이는' 보통의 문자값이 되기 때문이다.

 

그 결과는 아래와 같다.
01100111, 01000011, 01001111, 01110000

 

이제 이들은 모두 알파벳이나 기타 기호등의 보통의 아스키 문자로 바꿀 수가 있다. 따라서 이런 과정을 거친 파일은 하나의 '아스키문자 파일' 이 되어서, 종래의 이메일 시스템 등을 통해 아무 문제없이 전달될 수가 있다.