통신비 많이 나오면 엄마한테 혼나요, 컨텐츠 전송 인코딩

김재만·2022년 2월 16일
0

CS

목록 보기
7/13

계산기를 탈피한 우리의 전자노트 사용자들은 커다란 컴퓨터로 정리한 방대한 자료를 가지고 큰 고민에 빠졌다. 보통 World Wide Web의 탄생을 이야기 할 때 많이 나오는 일화처럼, 중앙서버에서 일괄적으로 군사정보를 관리하고 회선방식을 통해 작업 컴퓨터에게 전송하는 방식이었다. 적국에서 핵 미사일로 서버를 날려버리면, 손쉽게 무력화 할 수 있는 시스템이다. 이를 탈피하기 위해, 패킷방식을 활용한 알파넷 프로젝트가 진행되었으며 연결할 컴퓨터에 서버를 분산 설치하여 연결하는 방식이 고안되었다. 이는 인터넷과 이메일의 시초가 되었다. 그리고, 컨텐츠 전송 인코딩 이야기가 펼쳐지는데...

통신프로토콜 표준

미국과 영국의 주도로 발전하던 컴퓨터 표준은 문자 표현에서도 영어를 우선 표현하는 ASKII와 그 외를 포함하는 유니코드로 점진적으로 발전하는 모습을 보인다. 통신프로토콜 역시 마찬가지이다. 전자우편의 표준 메커니즘인 SMTP의 초기 통신 프로토콜 표준인 RFC821은 ASKII를 겨냥하여 데이터 전송 비용의 절약을 위해 7비트 데이터까지만 지원하도록 설계되었다. 유니코드의 주요 인코딩 방식인 UTF-8은 8비트로 문자를 표현, 저장하는 것과 차이가 생긴 것이다. 때문에 이 간극을 해결할 수 있는 새로운 인코딩 과정이 필요하게 되었다.
https://namu.wiki/w/%EC%9D%B8%ED%84%B0%EB%84%B7#s-1.2

인용 인쇄가능 인코딩(Quoted-Printable Encoding, QP Encoding)

인용 인쇄가능 인코딩은 8비트 데이터를 7비트 데이터만 지원하는 통신 경로를 통해 주고 받기 위한 초기 인코딩 방식이다. 8비트 짜리를 둘로 나누어 16진법으로 표기한 후 = 뒤에 표기하는 방식으로 작성한다. 해당 표기를 아스키로서 송신-수신한 후, =XX 표기된 문자를 다시 각각의 16진 수를 해석하여 원래의 8비트를 복원하는 방식이다.

(예) Mu(움라이트)nchen => M=FCnchen =>

0x4D / 0x3D / 0x46 / 0x43 / 0x6E / 0x63 / 0x68 / 0x65 / 0x6E =>

0100 1101 / 0011 1101 / 0100 0110 / 0100 0011 / 0110 1110 / 0110 0011 / 0110 1000 / 0110 0101 / 0110 1110 =>

1001101 / 0111101 / 1000110 / 1000011 / 1101110/ 1100011 / 1101000 / 1100101 / 1101110

(예) "가나 다" => =B0=A1=B3=AA =B4=D9 =>
http://egloos.zum.com/shadowxx/v/2333475

규칙

  1. 공백 : 탭과 공백 뒤에 인쇄가능한 문자가 없으면, 탭은 =09 공백은 =20으로 표현해야 한다.
  2. 줄바꿈 : 텍스트의 개행이 있는 경우 줄바꿈 표기를 해야한다. ex)=OA
  3. 자동 줄 바꿈 : 인코딩 된 줄의 길이가 76자를 넘지 않아야 한다. 76자를 넘어 내용이 더 이어지는 경우 자동 줄 바꿈 처리를 의미하는 =로 앞 줄 데이터를 마무리하며, 디코딩 할 때 =을 제외하여 해석한다.
    https://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html

베이스64 인코딩

QP인코딩은 작동이 원활하고 꽤 직관적인 방법이다. 하지만 경험상, 직관에 가까운 표기법은 저효율을 갖기 마련이다. QP인코딩의 경우 한 개의 문자를 =, X, X 의 3개의 바이트로 변환하여 전송하기 때문에 전송하는 데이터의 세 배를 전송해야한다.

이를 해결하고자 등장한 것이 베이스64 인코딩이다. 우선 효율먼저 얘기하자면 3바이트를 전송하기 위해 4개의 바이트로 변환하여 전송한다. 24비트짜리 데이터를 6비트짜리 비트그룹 4개로 쪼개는 방법이다. 8비트 세 바이트가 모여야 온전히 변환되므로, 전송할 데이터의 나머지가 1바이트 남으면 ==, 2바이트 남으면 =을 붙여서 발송한다.

https://ko.wikipedia.org/wiki/%EB%B2%A0%EC%9D%B4%EC%8A%A464

이 인코딩 방식은 현재도 이메일 첨부파일 전송에 많이 사용된다.

URL 인코딩

URL인코딩은 아스키코드 안에 있는 문자는 그대로 전송하고, 그 이외의 문자는 QP인코딩처럼 %XX의 형태로 기호와 두 개의 바이트를 통해 데이터를 전송하는 방식이다. 특이한 것은 URL에 활용되는 예약어의 경우(/, &, = 등) 데이터로서 전달하려고 할 때, 그대로 작성하면 각각의 역할을 수행하기 때문에, %XX의 형태로 전달해야한다. 또한, 공백문자가 허용되지 않으므로 + 혹은 %20으로 표기해야한다.

/는 URL 레벨을 구분한다.
&는 쿼리 파라미터를 구분한다.
= 는 쿼리 파라미터의 값을 지정한다.

URL 인코딩/디코딩 온라인 툴 : https://meyerweb.com/eric/tools/dencoder/

마무리

전기신호(bit)를 숫자로 표현한 것(0b > 0x)으로 가리킨 문자(ASKII or UNICODE)를 다시 숫자로 만들기 위해서(Byte) 문자로(= or % + 0,1,2,...,A,B,C,D,E,F) 표현하는 방법

profile
듣는 것을 좋아하는 개발자입니다

0개의 댓글