Web/Html

인코딩 방식

프로호구래머 2020. 7. 30. 13:29

JSP를 공부하다가 page 디렉티브에 인코딩 방식을 명시하는 부분이 있어 조금 정리해 보았다.

인코딩(Encoding)

우선, 인코딩(Encoding)이라는 것은 영어를 직역하자면 코드화, 암호화를 의미한다.

한자 표현으로는 부호화라고도 하고, 인코딩의 반대말은 디코딩(decoding)이다.

사람이 인지할 수 있는 형태의 데이터(JSP에서는 주로 문자가 될 것이다)를 약속된 규칙에 의해 컴퓨터가 사용하는 0과 1로 변환하는 과정을 인코딩이라 한다.

만약 컴퓨터나 휴대폰에서 문자가 깨져서 보인다면 이는 인코딩 방식과 디코딩 방식이 일치하지 않아서 발생하는 경우가 대부분일 것이다. 그렇다면 인코딩 방식에는 어떤 것들이 있을까?

 

ASCII(American Standard Code for Information Interchange)

아스키 코드는 미국 ANSI에서 표준화한 정보교환용 7비트 부호체계이다.

이름에서도 알 수 있듯이 해당 인코딩 방식은 American을 위한 표준 인코딩 방식이었다.

7비트를 사용하므로 총 2^7(128)개의 부호를 사용할 수 있다.

이는 영문 키보드로 입력할 수 있는 모든 기호들이 할당되어 있는 부호 체계이며,

매우 단순하고 간단하기 때문에 어느 시스템에서도 적용가능했다.

하지만, 영어만 표현할 수 있는 단점이 존재했다.

 

ASCII는 1byte로 표현 되기 때문에 7bit를 부호를 구분하는데 사용하면 1bit가 남게되는데

이를 처음에는 오류검출용으로 사용하였다. Parity Bit라고 해서 7개의 비트 중 1의 개수의 홀, 짝수를 확인하는 방식으로 변질된 신호를 검출해낼 확률을 높이는데 사용하였다.

하지만 남게된 1bit를 오류검출용으로 사용하지 않고 부호를 구분하는데 사용하므로써 8bit로 문자표를 구성한 방식이

Extended ASCII이다.

 

Extended ASCII

기존의 ASCII에서 확장된 영역에는 ASCII에서는 정의되지 않은 여러 문자들(주로 테두리 등을 그리기 위한 선문자)을 추가하였고, 남는 영역은 국가마다 다르게 정의하여 사용할 수 있었다. 즉, 자국어를 사용할 수 있게 해주었는데 여전히 문제점이 많았다.

자국어만 추가해서 사용할 수 있기 때문에 다른나라간의 호환이 되지 않았고, 우리나라나 중국 일본 같은 경우에는 표현해야하는 문자의 개수가 제공된 공간에 비해 턱없이 부족했다.

 

MBCS(Multi-Byte Character Set)

이에 1byte로는 동아시아권과 같이 문자의 종류가 많은 경우는 표현할 방법이 없어서 두 개 이상의 byte를 사용하여 문자를 표현하는 방식이 개발되었다. 한글 같은 경우에도 EUC-KR, 한컴 2바이트 코드가 존재하지만 여전히 국가간에 인코딩방식을 다르게 정의하므로 호환성 이슈는 여전히 발생했다.

그래서 자국어 뿐만 아니라 다른나라의 언어도 표현하기위해서 모든 문자 체계를 한데 몰아넣은

Unicode가 제시되었다.

Unicode

Unicode는 전 세계의 모든 문자를 다루도록 설계된 표준 문자 전산 처리 방식이다. Unicode를 이용한 인코딩 방식에 여러 방식이 존재한다.

UTF-8

UTF-8은 현재 가장 많이 사용되는 가변 길이 유니코드 인코딩 방식이다.

UFT-8로 표현 가능한 길이는 최대 6바이트이지만 다른 인코딩과의 호환을 위해 4바이트까지만 사용한다. 그래서 한 글자가 1~4바이트 중 하나로 인코딩될 수 있으며, 아스키 코드와 하위 호환성을 가지기 위해서 1바이트 영역은 아스키 코드와 동일하게 기록한다.

엔디안에 상관없이 똑같이 읽을 수 있으므로 크로스플랫폼 호환성도 뛰어나다.

 

이상 인코딩 방식에는 여러 방식이 존재하지만 모든 방식을 언급하기 보다는 현재의 UTF-8을 왜 선호하게(?) 되었고, 이 방식이 왜 만들어지게 되었는지를 알아보는 시간이 된 것 같다.

 


참고

https://onlywis.tistory.com/2

 

문자열 인코딩 개념 정리(ASCII/ANSI/EUC-KR/CP949/UTF-8/UNICODE)

지금껏 개발을 해오면서 ASCII와 ANSI의 차이에 대해 깊게 생각해 본 적이 없었다. UTF-8 기본으로 하여 개발을 해왔던 이유도 있거니와 ASCII=ANSI로 생각해도 사실 큰 문제는 없어왔다. 점 하나 그냥 �

onlywis.tistory.com

https://medium.com/hoontopia/%EB%AC%B8%EC%9E%90-%EC%9D%B8%EC%BD%94%EB%94%A9-ab3a85f692ec

 

문자 인코딩

아마 우리가 인코딩과 디코딩의 정확한 정의를 몰라도 무엇인지 대충 유추 할 수 있는 이유는 동영상을 다룰 때 자주 접할 수 있는 단어이기 때문일 것이다. 그러나 아쉽게도 이번 포스팅은 동��

medium.com

https://namu.wiki/w/%EC%9D%B8%EC%BD%94%EB%94%A9

 

인코딩 - 나무위키

문자열을 별도의 방식으로 치환하는 인코딩. 엄밀히 말하면 상위의 문자 인코딩과는 다른 개념이며 문장의 코드화에 가깝다. 문자입력/전송시, 읽지 않는 문자나 기존 예약된 문자가 따로 있어

namu.wiki

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

 

아스키 코드 - 나무위키

UTF-8의 경우 ASCII 영역은 그대로 1바이트를 사용하기 때문에 호환이 된다. 반대로 말하자면 UTF-8 문서라도 ASCII 영역에 해당하는 문자만 적혀 있고 BOM까지 없다면 그냥 ASCII 문서와 다를 게 없다. ��

namu.wiki

https://ko.wikipedia.org/wiki/UTF-8

 

UTF-8 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 둘러보기로 가기 검색하러 가기 UTF-8은 유니코드를 위한 가변 길이 문자 인코딩 방식 중 하나로, 켄 톰프슨과 롭 파이크가 만들었다. UTF-8은 Universal Coded Character

ko.wikipedia.org