인코딩과 디코딩

좋아하는 그림을 떠올려보자. 사람이라면 무엇이든 떠오르겠지만 컴퓨터라면 그냥 비트덩어리가 입력될 것이다. 

img 는 MIME 타입의 한 종류이다. 또한 비트 덩어리이기도 하다.

우리가 img를 통신상에서 보낼때 이 덩어리에서 국수를 뽑듯 비트를 조각내어 문자열과 같은 한 스트링으로 보낸다.

그리고 이처럼 한 스트링으로 변환하는 과정이 직렬화이다.

그래, 직렬화가 되었다 해보자. 그런데 통신상에서의 전기신호 역시 비트로 이루어져 있지 않은가.

그럼 국수가 된 이미지의 비트는 어떻게 될까

 

인코딩 -- start비트와 stop비트

통신을 할때는 어디서 부터 어디까지 보낸다는 start비트와 stop 비트가 생긴다. 근데 바이너리 파일의 경우에는 이 두 종류의 비트와 겹치는 패턴을 가지고 있는 경우가 많다.

때문에 인코딩은 이 두 종류의 비트를 직렬화된 비트와 구별 할 수 있도록 두 종류를 제외한 비트를 이스케이프 시켜 제어를 하는 과정이다.

이미지와 같은 바이너리 파일에는 확장자의 정보, 메타데이터, 순수 데이터 등이 있다. 이것들은 다 비트로 구성되어 있고 이것들이 단순한 전기 신호가 아니며, 전체가 한 덩어리에서 파생되었다는 것을 알리기 위해 인코딩을 시키는 것이다.

인코딩된 데이터를 읽기 위해선 디코딩이 필요하다. 디코딩은 단순하다. 인코딩을 할 때 비트 제어를 위한 비트와 이스케이프를 제거하는 것이다.

 

그럼 텍스트는?

텍스트는 인코딩할 필요가 없다. 텍스트는 ascii값으로 이루어져 있다. 근데 아스키 값의 비트 구조는 start와 stop 비트와 겹치는 경우가 없다. 때문에 인코딩을 하지 않아도 한 덩어리의 범위를 알 수 있는 것이다.

 

확장자에 따른 건가?

확장자는 말하자면 파일의 비트 구조이다. 어디서 부터 어디까지가 실제 데이터고,  메타데이터인지를 운영체제 혹은 프로토콜에게 알려주는 설계도 역할이다.

 

타입의 결정

타입의 결정은 파일의 처음부분의 비트에서 결정된다. base64와 같은 타입 역시 파일의 앞부분의 비트에 선언되어 있.