인코딩 편집하기

이동: 둘러보기, 검색

경고: 로그인하지 않았습니다. 편집을 하면 IP 주소가 공개되게 됩니다. 로그인하거나 계정을 생성하면 편집자가 아이디(ID)으로 기록되고, 다른 장점도 있습니다.

편집을 되돌릴 수 있습니다. 이 편집을 되돌리려면 아래의 바뀐 내용을 확인한 후 저장해주세요.
최신판 당신의 편집
7번째 줄: 7번째 줄:
 
== 역사 ==
 
== 역사 ==
 
초창기 컴퓨터는 사람과 기계어로만 소통을 했다. 당연 사용 과정에 많은 문제점이 발생하였고 그러하여 어셈블리어 등의 사람이 쓰는 문자를 사용할 필요성이 생겨 라틴 문자와 숫자, 몇몇 특수문자를 128개의 코드 값에 1:1 대응시키는 법을 고려했고 이것이 바로 최초의 문자 코드인 ASCII이다. 아스키는 <math> 2^{7} \ </math> 곧 7비트로 이루어졌고 1바이트 단위로 통신할 때 나머지 1비트는 패리티 코드로 쓰였다. 아스키는 근본적으로 정보교환을 위한 규격이었고, 통신 에러를 감지하기 위한 체크섬이 필요했다. 그러나 회피 가능한 에러들이 발생했고, 패리티 코드는 곧 쓰이지 않게 된다. 그러자 컴퓨터 업체들은 아스키코드의 7비트 맨 앞에 0비트를 사용하여 8비트를 채운 인코딩을 쓰게 된다. 아스키는 미국에서 만들어졌고 자국어인 영어를 쓰기 적합한 형태로 만들어졌다. 하지만 당장 라틴 문자를 공유하는 유럽쪽과 동아시아어 아랍어 등 나머지 언어는 사용할 수 없었다. 그래서 8비트 아스키 인코딩에서 비어있는 127 이후의 빈 공간을 다양한 문자로 채워넣은 인코딩들이 등장했고 각국의 자국어 표기를 위해 표준화가 시작되었다. 영어 이외의 언어를 위해서는 국가별로 인코딩 표준을 만들어야 했고 때문에 모든 문자 체계를 한데 몰아넣은 인코딩, 유니코드가 탄생했다. <ref name="나무위키"></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>
 
부호화(encoding)와 복호화(decoding) 은 정보의 형태나 형식을 표준화, 보안, 처리 속도 향상, 저장 공간 절약 등을 위해 다른 형태나 형식으로 변환하는 처리 혹은 처리방식을 말하며, 두 과정을 처리하는 방법을 합쳐서 부호화 방식이라고 한다. 그리고 부호기(符號機) 또는 인코더(encoder)는 부호화를 수행하는 장치나 회로, 컴퓨터 소프트웨어, 알고리즘을 말하며, 인코더는 부호화를 수행하는 사람을 뜻하기도 한다. 인코더와 디코더란 말의 식제 적용에서 혼돈을 피하기 위해선 우선 목적을 생각해야 한다. 그리고 목적을 위한 대상이 중요하다. 즉, 어떤 대상을 가지고 처리하기 위하여 처리를 위한 방식으로 변환하는 것을 인코더라 한다. 그리고 인코더 된 대상으로 부터 원래의 형태로 변환하는 것을 디코더라 한다. 예를 들어 영화의 장면의 자료수가 많아 압축을 해야 한다면 대상은 영화의 픽셀 데이터이고 목적은 압축이라 할 수 있다. 따라서 원래의 압축되지 않은 장면의 픽셀 데이터가 원본이 되고 이것을 압축 알고리즘을 동원하여 압축하면 우리가 흔히 보는 [[MPEG]]파일이 된다. 이때 부호화란 압축을 말한다. 그리고 압축된 파일을 풀어 원래의 픽셀 데이터로 변환한 것은 복호화(디코딩, decoding)라고 한다. 이 경우 부호화를 위한 압축 알고리즘은 프로그램화 되어 실현된다. 인코딩과 디코딩을 처리하는 하드웨어나 소프트웨어를 코덱(CODEC, coder and Decoder)라고 한다. 부호화는 사용목적에 따라서 원천부호화방식과 채널부호화방식으로 나눈다.<ref name="부호화방식">구루, 〈[http://blog.daum.net/question0921/132 부호화 방식]〉, 《다음 블로그》, 2009-03-24</ref> , <ref name="인코딩 위키백과"></ref>
 +
  
 
=== 원천부호화 ===
 
=== 원천부호화 ===
39번째 줄: 41번째 줄:
 
* [[유니코드]](Unicode/UTF-8)
 
* [[유니코드]](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>  
 
: 확장 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
 
:{|class=wikitable width=900
107번째 줄: 110번째 줄:
 
* [[HTML]]
 
* [[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>  
 
문제가 있을만한 문자들을 인코딩하여 안전하게 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>  
 +
  
 
{{각주}}
 
{{각주}}
119번째 줄: 123번째 줄:
 
*〈[https://ofcourse.kr/html-course/%EC%9D%B8%EC%BD%94%EB%94%A9 인코딩]〉, 《ofcourse》
 
*〈[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
 
* 덕's IT Story, 〈[http://www.kidd.co.kr/news/206668 인코딩이란? (ASCII, URL, HTML, Base64, MS Script 인코딩)]〉,《itstory》, 2014-04-15
 +
  
 
== 같이 보기 ==
 
== 같이 보기 ==

해시넷에서의 모든 기여는 다른 기여자가 편집, 수정, 삭제할 수 있다는 점을 유의해 주세요. 만약 여기에 동의하지 않는다면, 문서를 저장하지 말아 주세요.
또한, 직접 작성했거나 퍼블릭 도메인과 같은 자유 문서에서 가져왔다는 것을 보증해야 합니다 (자세한 사항은 해시넷:저작권 문서를 보세요). 저작권이 있는 내용을 허가 없이 저장하지 마세요!

취소 | 편집 도움말 (새 창에서 열림)