본문 바로가기
프로그래밍/etc. (Language)

문자 인코딩(Encoding)의 변화를 정리해보자. [아스키코드(ASCII) / ANSI 코드 / MBCS / 유니코드 / UTF]

by _BlankSpace 2020. 3. 2.

이번 포스팅은 문자 인코딩의 변화를 정리해보려 합니다. 그러므로, 여러 자료에서 정보를 가져와 정리하는 것이므로 문제가 된다면 말씀해주시면 감사하겠습니다.


컴퓨터를 오래 전부터 사용해본 사람 혹은 윈도우와 리눅스 및 다른 OS를 번갈아 사용하는 사람, 나아가서 개발 업무를 하는 사람들은 문자열이 깨지는 현상을 종종 보았을 것입니다. 이러한 현상은 문자 인코딩이 맞지 않는 경우에 종종 문자가 외계어(?)처럼 깨지는 현상이 나타납니다.
사실, 초기의 컴퓨터에는 문자가 깨지는 현상이 나타나지는 않았을 것입니다. 그 이유는 알파벳 또는 숫자만 필요한 지역에서 컴퓨터 연구가 활발하였기 때문입니다. 초기의 컴퓨터를 찾아보면 알겠지만, 굉장히 크고 비싸며 일반적인 사용자가 이용하기에는 무리가 있었습니다.

 

아스키코드(ASCII)란 무엇인가?

그래서 최초에는 우리가 잘 아는 아스키(ASCII)와 EBCDIC과 같은 문자열 세트를 사용하였습니다. 아스키코드는 영문 알파벳 및 숫자만으로도 영어권에서 주로 사용하였으니 상관이 없었을 것입니다.(일단은)

 

 

아스키코드는 굉장히 유명해서 다들 알겠지만 , 1 바이트로 7bits 를 문자 구성으로 사용합니다. 즉, 2의 7승 = 128 개의 문자를 표현할 수 있다는 뜻입니다.

그럼, 나머지 1비트는 어디에서 사용할까요? 바로, 통신 에러 검출을 위해서 사용하였습니다. 흔히, 패리티 비트(Parity Bit)라고 하는데, 7개의 비트 중에서 1의 개후가 홀수면 1, 짝수면 0을 붙이는 방식으로 전송 도중에 데이터가 변경되는 문제를 검출하기 위해서 사용하였다고 합니다.

이것은 초기에는 텔레프린터나 전신기에 사용하기 위해 디자인되었는데, 따로 메모리가 없어서 한번에 1문자만 보낼 수 있어서 초기에는 잘 사용되었을 것입니다. 하지만, 시간이 갈수록 문제가 발생하였습니다.

 

점점 아스키코드의 문자 구성은 한계가 있었기 때문입니다. 기본적인 알파벳 정도는 커버가 가능하지만, 상징적인 문자를 표현하기에는 부족하였습니다. 예를 들면, 기호나 수학에서 사용하는 상징들을 표현할 수 없었습니다. 가장 와닿는 것은 아스키코드에서는 나누기 표현이 없었습니다. 그래서 프로그래밍 언어에서도 흔히들 “÷” 로 대신하고 있다고 합니다.

하지만 가장 큰 문제는 컴퓨터의 글로벌화에 있었습니다. 점점 알파벳을 사용하지 않는 나라에서는 자신들의 나라 언어들도 포함되기를 원했기 때문입니다. 예를 들면, 돈을 나타낼 때의 상징도 나라마다 다른데.. 달러는 "$", 우리나라는 "\" 등등이 있습니다.

 

 

# 확장아스키코드(Extended ASCII) 또는 ANSI 코드란 무엇인가?

이처럼 기존의 아스키코드에는 대중화 또는 글로벌화되면서 문제가 발생하였습니다. 이 문제를 해결하기 위해서 기존에 1bit를 문자 표현에 사용하기로 하는데, 이것이 확장 아스키코드입니다. 또 다른 말로는 ANSI 코드라고도 합니다.

즉, 8bits로 2의 8승 = 256  개의 문자를 표현할 수 있다는 뜻입니다. 추가된 128개의 문자에는 일부 나라마다의 언어로 채워졌습니다. 

 

 

이것을 흔히들 ISO 8859로 표준을 정해 놓기도 하였습니다. 그래서 보통, 지역 별로 ISO/IEC 8859-x 로 정의되어 있습니다. x에는 숫자가 들어갑니다. 이에 대한 정리를 아래 표로 정리하면 다음과 같습니다.

 

이름

지역

언어

ISO/IEC 8859-1

서유럽

네덜란드어, 노르웨이어, 덴마크어, 독일어, 스웨덴어, 영어, 이탈리아어 등등..

ISO/IEC 8859-2

중앙유럽

보스니앙, 슬로바키아어, 체코어, 폴란드어, 헝가리어 등등

ISO/IEC 8859-3

남유럽

몰타어, 터키어, 에스페란토

ISO/IEC 8859-4

북유럽

에스토니아어, 라트비아어, 리투아니아어 등등

ISO/IEC 8859-5

라틴/키릴

러시아어, 벨라루스어, 우크라이나어 등등

ISO/IEC 8859-6

라틴/아랍

아랍어

ISO/IEC 8859-7

라틴/그리스

그리스어

ISO/IEC 8859-8

라틴/히브리

히브리어

ISO/IEC 8859-9

터키

터키어

ISO/IEC 8859-10

노르딕

노르딕어

ISO/IEC 8859-11

라틴/타이

타이어

ISO/IEC 8859-12

라틴/데바나가리

데바나가리 문자를 위한 ISO 작업이나 공식적으로 폐기.

ISO/IEC 8859-13

발트 해 연안

ISO/IEC 8859-4와 ISO/IEC 8859-6에 빠진 발트 언어 문자를 보강함.

ISO/IEC 8859-14

켈트

스코틀란드게일어, 브르타뉴어

ISO/IEC 8859-15

 

유로 기호 문자

ISO/IEC 8859-16

남동유럽

루마니아어, 슬로베니아어, 알바니아어 등등

[https://ko.wikipedia.org/wiki/ISO/IEC_8859 참고]

 

결국에는 모든 나라의 문자를 커버하지는 못합니다. 예를 들면, 한국어나 중국어의 경우에는 굉장히 많은 문자가 있기 때문입니다.

 

# MBCS란 무엇인가?

MBCS는 Multi-Byte Character Set의 약자입니다. 위에서 주구장창 설명했던 아스키 코드는 1Byte로 이루어진 것이라고 한다면, MBCS는 나중에 설명할 유니코드를 제외한 두 개 이상의 바이트를 사용하여 문자를 표시하는 방식을 말합니다. 2바이트 이상의 문자 표시 방식도 이론상 가능하겠지만, 그런 사례가 그리 많지는 않으므로 2바이트라고 생각하면 좋을 듯 합니다.

 

보통, 영문은 1바이트로 표현하며, 그 외에 언어는 2바이트로 표현한다고 생각하면 됩니다. 자세한 것은 언어별로 코드 페이지가 존재하므로, 해당 코드 페이지를 참고하는 것이 가장 좋은 방법입니다. 

아시아권 주요 나라 코드 페이지는 아래와 같습니다.

- 한글(완성형) : EUC-KR, CP949

- 중국어(간체자) : GB2312, GB18030 등.

- 중국어(번체자) : Big5

- 일본어 : Shift-JSI 등

 

이로써, 나라 별로 코드 페이지를 통하여 문자를 표시할 수 있게 되었습니다. 하지만, 이 방법도 문제가 발생하였습니다.

첫번째로는 기존의 아스키 코드와 호환이 불가능 합니다. 기존의 아스키 코드로 작성된 시스템 또는 프로그램들이 존재하는데 호환이 불가능하니 문자가 깨지는 문제가 발생합니다.

두번째로는 나라 간의 호환도 불가능합니다. 시스템이 서로 다른 코드 페이지를 사용하다보니, 문서를 받게 되면 글자는 깨지게 됩니다. 즉, 문서를 읽을 때에도 어떠한 코드 페이지로 작성되었는지 확인을 일일히 해야한다는 귀찮음이 발생하였습니다.

 

이러한 문제는 어떻게 해결하였을까요? 이 다음 인코딩 시스템에서 확인할 수 있습니다.

 

 

****** 아래는 추가 작성이 필요합니다. *****

 

# 유니코드란 무엇인가?
유니코드..* 멀티바이트 문자 등장 ( ex) ucs

# UCS란 무엇인가?

 

# UTF란 무엇인가?
* utf-8 / utf-16

 

참고 사이트

https://namu.wiki/w/MBCS

https://namu.wiki/w/%EC%95%84%EC%8A%A4%ED%82%A4%20%EC%BD%94%EB%93%9C

https://en.wikipedia.org/wiki/Extended_ASCII

https://ko.wikipedia.org/wiki/%EB%AC%B8%EC%9E%90_%EC%9D%B8%EC%BD%94%EB%94%A9

https://en.wikipedia.org/wiki/Variable-width_encoding#MBCS

댓글