인코딩 편집하기

'''인코딩'''<!--encoding, 부호화-->(encoding)이란 파일에 저장된 정보의 형태를 다른 것으로 변경하는 것을 말한다. '''부호화'''(符號化)라고도 한다. 사람이 인지할 수 있는 형태의 데이터를 약속된 규칙에 의하여 컴퓨터가 사용하는 0과 1로 변환하는 과정을 통틀어 말하며 파일 압축이나 암호화 등의 목적으로 인코딩을 한다. 반대말은 [[디코딩]](decoding)이다.

== 개요 ==
인코딩은 컴퓨터 정보의 형태나 형식을 표준화, 보안, 처리 속도 향상, 저장 공간 절약 등을 위해서 다른 형태나 형식으로 변환하는 것을 말한다. [[인코더]](encoder) 또는 [[부호기]]는 인코딩을 수행하는 장치나 [[컴퓨터]] [[소프트웨어]]를 말한다. 보통 인코딩을 생각하면 컴퓨터에서 동영상이나 문자 인코딩을 생각하는데, 이 외에도 사람이 인지할 수 있는 형태의 [[데이터]]는 전부 인코딩할 수 있다. <ref name="나무위키">〈[https://namu.wiki/w/%EC%9D%B8%EC%BD%94%EB%94%A9 인코딩]〉, 《나무위키》</ref>
그리고 부호화를 언급함에 있어 복호화를 빼놓을 수 없는데, 복호화란 부호화(encoding)된 정보를 부호(code)화되기 전으로 되돌리는 처리 혹은 처리 방식을 말하는 것이다. 즉, 부호화 절차를 역으로 수행하면 복호화가 된다.<ref>〈[https://ko.wikipedia.org/wiki/%EB%B3%B5%ED%98%B8%ED%99%94 복호화]〉, 《위키백과》</ref>

== 역사 ==
초창기 컴퓨터는 사람과 기계어로만 소통을 했다. 당연 사용 과정에 많은 문제점이 발생하였고 그러하여 어셈블리어 등의 사람이 쓰는 문자를 사용할 필요성이 생겨 라틴 문자와 숫자, 몇몇 특수문자를 128개의 코드 값에 1:1 대응시키는 법을 고려했고 이것이 바로 최초의 문자 코드인 ASCII이다. 아스키는 <math> 2^{7} \ </math> 곧 7비트로 이루어졌고 1바이트 단위로 통신할 때 나머지 1비트는 패리티 코드로 쓰였다. 아스키는 근본적으로 정보교환을 위한 규격이었고, 통신 에러를 감지하기 위한 체크섬이 필요했다. 그러나 회피 가능한 에러들이 발생했고, 패리티 코드는 곧 쓰이지 않게 된다. 그러자 컴퓨터 업체들은 아스키코드의 7비트 맨 앞에 0비트를 사용하여 8비트를 채운 인코딩을 쓰게 된다. 아스키는 미국에서 만들어졌고 자국어인 영어를 쓰기 적합한 형태로 만들어졌다. 하지만 당장 라틴 문자를 공유하는 유럽쪽과 동아시아어 아랍어 등 나머지 언어는 사용할 수 없었다. 그래서 8비트 아스키 인코딩에서 비어있는 127 이후의 빈 공간을 다양한 문자로 채워넣은 인코딩들이 등장했고 각국의 자국어 표기를 위해 표준화가 시작되었다. 영어 이외의 언어를 위해서는 국가별로 인코딩 표준을 만들어야 했고 때문에 모든 문자 체계를 한데 몰아넣은 인코딩, 유니코드가 탄생했다. <ref name="나무위키"></ref>

== 방식 ==
부호화(encoding)와 복호화(decoding) 은 정보의 형태나 형식을 표준화, 보안, 처리 속도 향상, 저장 공간 절약 등을 위해 다른 형태나 형식으로 변환하는 처리 혹은 처리방식을 말하며, 두 과정을 처리하는 방법을 합쳐서 부호화 방식이라고 한다. 그리고 부호기(符號機) 또는 인코더(encoder)는 부호화를 수행하는 장치나 회로, 컴퓨터 소프트웨어, 알고리즘을 말하며, 인코더는 부호화를 수행하는 사람을 뜻하기도 한다. 인코더와 디코더란 말의 식제 적용에서 혼돈을 피하기 위해선 우선 목적을 생각해야 한다. 그리고 목적을 위한 대상이 중요하다. 즉, 어떤 대상을 가지고 처리하기 위하여 처리를 위한 방식으로 변환하는 것을 인코더라 한다. 그리고 인코더 된 대상으로 부터 원래의 형태로 변환하는 것을 디코더라 한다. 예를 들어 영화의 장면의 자료수가 많아 압축을 해야 한다면 대상은 영화의 픽셀 데이터이고 목적은 압축이라 할 수 있다. 따라서 원래의 압축되지 않은 장면의 픽셀 데이터가 원본이 되고 이것을 압축 알고리즘을 동원하여 압축하면 우리가 흔히 보는 [[MPEG]]파일이 된다. 이때 부호화란 압축을 말한다. 그리고 압축된 파일을 풀어 원래의 픽셀 데이터로 변환한 것은 복호화(디코딩, decoding)라고 한다. 이 경우 부호화를 위한 압축 알고리즘은 프로그램화 되어 실현된다. 인코딩과 디코딩을 처리하는 하드웨어나 소프트웨어를 코덱(CODEC, coder and Decoder)라고 한다. 부호화는 사용목적에 따라서 원천부호화방식과 채널부호화방식으로 나눈다.<ref name="부호화방식">구루, 〈[http://blog.daum.net/question0921/132 부호화 방식]〉, 《다음 블로그》, 2009-03-24</ref> , <ref name="인코딩 위키백과"></ref>

=== 원천부호화 ===
정보신호를 전송하기에 적합하도록 효율적으로 부호화하는 방식으로 정보신호를 디지털 신호로 바꾸고 데이터를 압축하여 제한된 대역폭에서 고속으로 전송되도록한다. 원천부호화는 에러가 발생했을 때 오류 검출 및 정정 능력이 매우 취약하기 때문에 네트워크에서는 신뢰성 있는 데이터 전송시스템이 필요하다.<ref name="부호화방식"></ref> 원천부호화의 방식으로는 델타변조(DM, Delta Modulation), 펄스부호변조(PCM, pulse Code Modulation), 허프만코딩(Huffman coding)이 있다.

* 델타변조 : 델타변조는 원천부호화 방식 중에서 가장 원시적인 방법이다. 현재 샘플과 이전 샘플을 비교한 차이를 전송하는 방식으로 샘플링 값이 이전 값보다 증가하면 1을 보내고 감소하면 0을 전송한다. 펄스부호변조가 한 샘플링 값으로 여러 비트씩 얻는 것에 비해 텔타변조는 한 비트씩만 얻어서 사용한다.

* 펄스부호변조 : 펄스부호변조로서 '표본화 -> 양자화 -> 부호화' 방식을 거쳐 아날로그신호를 디지털 신호로 변환한다. 표본화(Sampling)란 연속적인 시간신호를 이산적인 시간신호로 표본화하여 PAM신호를 만드는 과정이며, 양자화는 PAM신호를 디지털 전압값으로 변환하는 과정이다. 부호화는 표본값이 펄스부호변조 디지털 코드를 부여하는 과정이다. 연속적인 아날로그 신호를 시간단위로 끊어서 전압값을 얻은 후 그 전압값에 8비트 이상의 디지털 코드를 부여하는 방법이다.

* 허프만코딩 : 기본 이론으로는 발생확률이 높은 심벌에는 짧은 길이의 코드를 할당하고 발생확률이 낮은 심벌에는 긴 길이의 코드를 할당하는 방식이다.<ref name="부호화방식"></ref>

=== 채널부호화 ===
채널부호화는 원천부호화된 원래의 정보에 에러 검출 및 정정을 위한 비트들을 추가하여 전송하는 방법으로 수신측에서 에러를 검사하여 데이터의 재전송을 요청하거나 자체적으로 에러를 검출하여 정정하도록 하는 목적이 있다.<ref name="부호화방식"></ref> 채널부호화의 방식으로는 자동재전송요청(ARQ, Automatic Repeat Request), 전진 오류 수정(FEC, Forward Error Correction)이 있다.

* 자동재전송요청 : 자동재전송요청의 종류는 정지-대기(stop and wait)방식과 연속(continuous)방식이 있다.
:* 정지대기 방식 : 정해진 코드단위를 전송한 후 수신 결과로 돌아오는 정상 수신(ACK, positive Acknowledgement) 및 비정상 수신 확인신호(NAK, Negative Acknowledgement)를 기다려 데이터를 계속 전송할 것인지 아니면 재전송할 것인지를 결정하는 방식이다.
:* 연속 방식 : 송신 도중에 수신측에서 비정상 수신 확인신호를 받았을 때 일정한 개수(N)의 코드단위를 재전송하는 방식이다.

* 전진오류수정 : 수신측에서 스스로 에러를 검출 및 정정하는 방법으로 패리티 비트를 추가하거나 주기중복검사(CRC, yclic Redundancy check)코드를 추가하여 보내는 방식이다.<ref name="부호화방식"></ref>

== 사례 ==
컴퓨터에서 사용되는 오디오, 텍스트, 동영상 [[파일]]의 [[표준화]] 및 [[보안]]을 위한 [[암호화]]에 사용된다. [[코덱]]은 오디오나 동영상 파일의 크기를 줄이거나, 컴퓨터에서 신속하게 자료를 처리하기 위해 사용되고, 오디오 인코딩은 주로 오디오를 다른 표준화된 형식으로 바꾸거나, 위에서 언급한 이유를 위해 사용된다. 동영상 인코딩도 위와 같은 이유로 사용되거나 PPT에서 mp4 파일을 재생하기 위하여 다른 파일로 바꿀 때 필요하다. 무선 인터넷 등에서 사용하는 데이터의 보안을 위해 사용된다.<ref name="인코딩 위키백과"></ref>

문자는 컴퓨터와 사용자가 [[기계어]]로만 소통하던 시기에 많은 애로사항이 있었고 이를 해결하고자 등장하였다. 문자 인코딩의 대표적인 예로는 [[아스키코드]]와 [[유니코드]]가 있다.<ref name="인코딩 위키백과">〈[https://ko.wikipedia.org/wiki/%EB%B6%80%ED%98%B8%ED%99%94 부호화]〉, 《위키백과》</ref>

* [[아스키 코드]](ASCII) 및 한글 KS완성형(euc-kr)
: 아스키(ASCII)는 미국정보표준부호(American Standard Code for Information Interchange)의 약자이며 미국 ANSI에서 표준화한 정보교환용 7비트 부호체계이다. 현재 사용되는 아스키 코드의 더 정확한 이름은 ANSI Code이다. 000(0X00)부터 127(0X7F)까지 총 128개의 문자 집합이 있으며, 처음 32대는 인쇄와 전송 제어용으로 사용되는 제어문자(Control Characters)이다. 이를 제외한 33번째 이후 문자들에 대하여는 숫자 및 영문 대소문자가 배치되어 사용된다. 이는 색깔을 나타내는 앤시 코드가 아닌 문자를 나타내는 규약이다. 일반적으로 데이터는 byte 단위로 다뤄진다. ASCII는 1바이트를 구성하는 8비트 중에서 7비트만 사용하고 나머지 1비트는 통신 에러 검출을 위하여 사용한다. 이 비트는 Parity Bit라고 하며 현재는 사용하지 않는다. 아스키 코드는 영문·숫자 1글자는 1바이트, 한글·한자 1글자는 2바이트이다. 하나의 인코딩당, 영문과 또다른 하나의 언어만 사용할 수 있다. 한국어 아스키 코드인 완성형(euc-kr) 인코딩에서는 영문과 한글 그리고 한국에서 사용되는 한자만 표현할 수 있다. 물론 일본어도 섞여 잇지만, 일본어 인코딩이 아니기 때문에 일본인은 읽을 수 없다. 그래서 하나의 파일에 여러 언어를 동시에 표현하기가 힘들거나 불가능하다. 하지만 이는 컴퓨터 초창기부터 사용되어 왔기에 호환성이 아주 좋다. MS윈도우 2000/XP이상의 운영체제에서는 내부적으로 유니코드를 사용하지만 사용자가 실제로 읽고 쓰는 텍스트 문서는 대부분 아스키 코드이다. 아스키 코드는 매우 단순하고 간단하여 어느 시스템에도 적용이 가능하다는 장점이 있지만 2바이트 이상의 코드를 표현할 수 없다는 단점이 있다. <ref name="문자인코딩 차이">mwultong, 〈[http://mwultong.blogspot.com/2006/10/unicode-ascii-unicode-ascii-difference.html 유니코드(Unicode), 아스키(ASCII; 한글완성형) 차이/차이점; Unicode ASCII Difference]〉, 《블로그스팟》, 2006-10-26</ref>

* [[유니코드]](Unicode/UTF-8)
: 확장 ASCII와 같이 영어 이외 언어를 사용하기 위하여 국가별 인코딩 표준이 만들어져 사용됐지만, 인터넷의 발달로 인한 다른 지역간 다른 언어가 사용된 문서 교환이 활발해지면서 문제점이 발생하게 되었다. 이러한 문제의 해결 대책으로 모든 문자체계를 하나의 문자 집합으로 만든 것이 유니코드이다. 영문, 숫자, 한글, 한자 등 모든 글자는 이론적으로 2바이트로 적용하며 최대 6바이트까지 사용한다. 그리고 파일에 저장될 때도 2바이트로 저장한다. 희귀한 특수문자나 문자들은 2바이트를 초과할 수도 있다. 유니코드는 먼저 포함시키고자 하는 문자 집합을 정의 했는데 이것은 문자 셋 또는 캐릭터 셋(character set)이라고 한다. 또한 이것을 UTF(Unicode Transformation Format)이라고 하며 여기에 번호를 붙인 UTF-8, UTF-16, UTF-32 등을 유니코드 인코딩이라고 한다. 대표적으로는 UTF-8 하나의 문자를 1~4바이트의 가변길이로 표현하고 1바이트 영역은 ASCII코드로 하위 호환되며 ASCII코드의 128개 문자 집합은 UTF-8과 동일하게 호환된다. 현재 인터넷에서 가장 많이 쓰이는 인코딩이고 뛰어난 크로스플랫폼 호환성도 가지고 있다. 단 UTF-8 유니코드가 파일에 저장될 때, 영문·숫자는 아스키 코드와 똑같이 1바이트를 사용하고, 한글 등은 3바이트로 파일에 저장된다. UTF-8 유니티코드는 아스키 코드와 영문 영역에서 100% 호환된다. 만약 UTF-8 유니코드 문서에 한글 등이 전혀 없고, 영문과 숫자로만 이루어져 있다면, 그 파일은 아스키 코드와 동일하게 볼 수 있다. 또한 웹페이지를 유니코드로 작성 할 때는 UTF-8 유니코드를 사용한다. UTF-16은 모든 문자를 2바이트의 고정크기로 표현하고 UTF-8과 마찬가지로 ASCII코드의 128개의 문자 집합에 대하여 호환성을 가졌다. 바이트 순서가 정해지지 않아서 인터넷 상에서의 사용을 권고하지 않는다. Java와 .NET Framework의 기본 인코딩이다. 이처럼 UTF-8과 UTF-16의  특징을 비교하면 UTF-16은 다루기 쉽지만 1바이트로 표현할 수 있는 영문, 숫자가 2바이트로 표현되기 때문에 문서의 크기가 커진다는 단점이 있다. 반면에 UTF-8은 가변길이라 다루기는 어렵지만 영문, 숫자가 1바이트로 표현되고 한글이 3바이트로 표현되어 문서의 크기를 작게 다룰수 있다는 장점이 있다. 인터넷에서는 UTF-8 인코딩을 많이 사용한다. 왜냐하면 전송속도 기준으로 문서의 크기를 작게 변환해주고, 크로스플랫폼 호환성을 통하여 엔디안에 상관없이 사용 가능하기 때문이다. 아스키 코드와 차이점은 전 세계의 모든 언어를 하나의 파일에 쓸 수 있다는 것인데, 물론 각 언어에 해당하는 폰트가 설치되어 있어야 한다. 유니코드의 역사가 그리 길지 않아서 아직도 유니코드를 잘 인식하지 못하는 컴퓨터가 간혹 존재한다. 현재는 사용하지 않지만 예를 들어 윈도우 98이나 오래된 유닉스 시스템의 경우에 그렇다.<ref name="문자인코딩 차이"></ref> 그렇지만 유니코드로 작성된 인터넷 웹페이지는 대부분 잘 인식한다. <ref>freestrokes, 〈[https://freestrokes.tistory.com/71 인코딩과 디코딩 (Encoding & Decoding)]〉, 《티스토리》, 2018-07-07</ref> 

:{|class=wikitable width=900
|+<big>'''인코딩 적용 사례'''</big>
!align=center|목적
!align=center|원본
!align=center|처리방식
!align=center|부호화
!align=center|복호화(디코더)
|-
|align=left|동영상 파일 압축
|align=left|압축되지 않은 파일
|align=left|변환 알고리즘(표준화)
|align=left|압축 알고리즘으로 변환
|align=left|코덱으로 압축 품
|-
|align=left|동영상 파일 압축
|align=left|암호화되지 않은 신호
|align=left|암호화
|align=left|비화기로 암호화
|align=left|암호해제로 원래의 신호로 변환
|-
|align=left|아파트의 층을 숫자화
|align=left|아파트층
|align=left|숫자화
|align=left|각층을 십진수화
|align=left|해당 층을 지목
|-
|}

:{|class=wikitable width=900
|+<big>'''전자공학에서 적용 사례'''</big>
!align=center|목적
!align=center|원본
!align=center|처리방식
!align=center|부호화
!align=center|복호화
|-
|align=left|음성 신호 처리
|align=left|물리적 음성신호
|align=left|전자화
|align=left|마이크로 전기신호로 변환
|align=left|스피커로 물리적 신호로 변환
|-
|align=left|디지털화
|align=left|아날로그 신호
|align=left|디지털 회로
|align=left|양자화(ADC)로 이진화
|align=left|DAC로 아날로그 변환
|-
|align=left|엘리베이터의 스위치를 누르면 LED 표시
|align=left|층 별 스위치
|align=left|디지털 회로
|align=left|2진화
|align=left|2진수를 해당 LED로 불 켜기
|-
|align=left|통신라인의 특성에 맞춤
|align=left|직렬 데이터
|align=left|AC 성분 추가
|align=left|라인코딩 (NRZ, MAnchester, ..)
|align=left|원래 직렬데이터로 변환
|-
|}

* [[URL]] 
URL 인코딩이 필요한 이유는 URL에 사용 가능한 문자가 제한되어 있기 때문이다. URL에 사용할 수 있는 문자는 알파벳, 숫자와 몇 가지의 특수문자뿐이다. 따라서 한글 등의 다양한 문자를 URL에 표시하려면 URL에 허용하는 문자로 변환하여 표현하여야 한다. URL 메타문자들에 대한 인코딩이 필요하며 형식은 기존 문자열의 HEX값 앞에 %를 사용한다. 한글은 UTF-8을 사용한다. 

* [[HTML]]
문제가 있을만한 문자들을 인코딩하여 안전하게 HTML 문서와 함께 사용하기 위해 사용한다. XSS의 대응방안으로 사용되며 현재 한국에서 사용되는 인코딩 방식으로는 크게 euc-kr 과 UTF-8 방식이 있다. euc-kr 방식은 원래 영어만을 고려한 1바이트 길이의 아스키라는 인코딩 방식을 확장하여 한글을 사용할 수 있도록 만든 2바이트 길이의 국가 언어 코드이다. 즉 우리나라에서만 쓸 수 있도록 만든 코드이며다른 나라와 공유할 수 없기에 문제가 발생하였고 이를 해결하기 위해 고안된 새로운 인코딩 방식이 UTF-8이다. 예전에는 용량이 작은 euc-kr 방식을 선호하는 곳들도 많았지만, 현재는 용량 문제보다 표준화를 고려하므로 UTF-8 인코딩 방식을 더 선호한다. <ref>〈[https://ofcourse.kr/html-course/%EC%9D%B8%EC%BD%94%EB%94%A9 인코딩]〉, 《ofcourse》</ref> , <ref>덕's IT Story, 〈[http://www.kidd.co.kr/news/206668 인코딩이란? (ASCII, URL, HTML, Base64, MS Script 인코딩)]〉, 《산업일보》, 2014-04-15</ref> 

== 디지털 회로 ==

{{각주}}

== 참고자료 ==
*〈[https://namu.wiki/w/%EC%9D%B8%EC%BD%94%EB%94%A9 인코딩]〉, 《나무위키》
*〈[https://ko.wikipedia.org/wiki/%EB%B3%B5%ED%98%B8%ED%99%94 복호화]〉, 《위키백과》
*〈[https://ko.wikipedia.org/wiki/%EB%B6%80%ED%98%B8%ED%99%94 부호화]〉, 《위키백과》
* mwultong, 〈[http://mwultong.blogspot.com/2006/10/unicode-ascii-unicode-ascii-difference.html 유니코드(Unicode), 아스키(ASCII; 한글완성형) 차이/차이점; Unicode ASCII Difference]〉, 《블로그스팟》, 2006-10-26
* 구루, 〈[http://blog.daum.net/question0921/132 부호화 방식]〉, 《다음 블로그》, 2009-03-24
* freestrokes, 〈[https://freestrokes.tistory.com/71 인코딩과 디코딩 (Encoding & Decoding)]〉, 《티스토리》, 2018-07-07
*〈[https://ofcourse.kr/html-course/%EC%9D%B8%EC%BD%94%EB%94%A9 인코딩]〉, 《ofcourse》
* 덕's IT Story, 〈[http://www.kidd.co.kr/news/206668 인코딩이란? (ASCII, URL, HTML, Base64, MS Script 인코딩)]〉,《itstory》, 2014-04-15

== 같이 보기 ==
* [[인코더]]
* [[디코딩]]

{{프로그래밍|검토 필요}}