웹 개발을 하면서 처음에는 까다롭게 다가오다가 어느 순간 의미도 모른채 그냥 그 설정 그대로 유지하는게 바로 언어에 대한 인코딩이 아닌가 합니다. 특히 정형화된 구조에서 크게 문제가 발생하지 않기 때문에 신경을 쓰지 않다가 새로운 환경으로 이전을 하게 된다거나 할 때 한글이 깨지는 등의 문제가 발생하여 고생을 할 때가 종종 있습니다.
그래서 인코딩에 대한 최소한의 내용을 알려드려 크게 당황하지 않도록 도움을 드리고자 합니다.
이 글은 초보자를 위한 글이므로, 인코딩(Encoding) 정도는 우습다는 분은 패스해주길...^^;;;
------------------------------------------------------------------------------------------------------
이번에는 HTML 이 아닌 JSP 의 인코딩 설정에 대해서 먼저 간단하게 집고 넘어가겠습니다.
JSP 는 ASP, PHP 와 같은 웹 언어들과 비슷한 것 같지만, 비교 우위에 있는 큰 장점이 하나 있습니다. 바로 훌륭한 개발툴인 이클립스(Eclipse) 등의 존재입니다.
이클립스와 같은 개발툴은 JSP 을 지원했다기 보다는 Java 와 같은 개발 언어를 지원하는데, 이를 JSP 에서도 도움을 받을 수 있어서 실제 개발을 하다 보면 ASP 나 PHP 는 ultraedit 나 editplus 와 같은 일반 텍스트 에디터로 개발을 많이 하는 반면 JSP 를 개발하는 분들은 십중팔구 이클립스를 이용합니다.
그런데, 이클립스와 같은 개발툴이 JSP 의 인코딩 방식이 무엇인지 알 수 있게 선언할 수 있는 방법이 있습니다. 바로 파일 상단에 이에 대한 선언을 하는 것입니다.
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>
이런 선언을 많이 보셨을 겁니다. 이렇게 선언을 하면 이클립스와 같은 IDE 는 해당 파일이 UTF-8 로 인코딩된 파일이라는 것을 눈치채고 파일을 열어주게 됩니다.
그럼 왜 UTF-8 이 두 번 선언이 되어 있을까요?
JSP 는 먼저 서버에서 Java 로 변환이 된 뒤에 그 결과(=HTML)를 클라이언트에 전송하고, 클라이언트는 HTML 만을 해석하여 사용자에게 제공을 합니다. 그래서 HTML 의 <meta> 는 브라우저를 위한 설정값이라면, 위의 contentType 와 pageEncoding 은 서버를 위한 설정값인데, contentType 은 서버에서 생성될 HTML 의 캐릭터셋, pageEncoding 은 JSP 내의 Java 코드에 대한 캐릭터셋에 대한 정보입니다. 그래서 아래와 같이 두 가지 다른 캐릭터셋으로 정의를 한 뒤 출력할 수도 있습니다.
<%@ page language="java" contentType="text/html; charset=UNICODE" pageEncoding="EUC-KR" %>
예전에는 이렇게 정의를 해서 개발을 했던 적도 실제 있습니다. 실제 HTML 부분에는 한글 등이 없고 DBMS 에서 불러온 값만 출력해주는데, 이 데이터들이 UTF-16 으로 인코딩되어 있을 경우 pageEncoding 까지 UTF-16 으로 선언하면 Java 코드의 크기까지 같이 커지기 때문에 이와 같이 다른 캐릭터셋으로 선언해서 개발하던 적도 있었습니다. 하지만, 요즘은 그렇게 개발을 하지는 않습니다. 바로 디스크의 용량이 비약적으로 커지고 소스 크기는 그렇게 커지지 않았기 때문에 용량에 대한 부담이 거의 없기 때문입니다. 그래서 요즘은 그냥 UTF-8 로 통일해놓고 개발하는 것을 다시 한 번 권해드리는 겁니다.
그런데, HTML 에서 UTF-8 로 인코딩되어 사용자에게 정보가 보여졌는데, 게시글 입력과 같이 사용자가 한글이나 한자 등의 데이터를 입력해서 서버에 전송하게 될 때는 어떤 일이 벌어질까요?
아주 예전에 웹을 설계하던 사람들은 우리의 기대를 저버리지 않고 다국어에 대한 고려를 전혀 하지 않았습니다. 그래서 웹에서 전송되는 문자는 모두 ASCII 을 기준으로 데이터가 전송되는 것으로 설계가 되었습니다. 그래서 HTML 에서 영어가 아닌 다른 캐릭터셋으로 문서를 작성해서 전송하려면 문제가 발생했습니다. 그래서 강제로 문자열을 웹에 맞는 ASCII 로 변환한 뒤 이를 다시 원하는 문자열로 변환시켜주는 작업이 필요했습니다. 이런 작업이 URL Encoding/Decoding 입니다. ASP 에서는 Server.URLEncode 로 변환을 제공하고, Java 에서는 java.net.URLEncoder 의 encode 매서드를 이용해서 변환을 한 뒤 서버로 전송하게 해줬습니다. 혹은 Javascript 에서 변환시켜주기도 했고, 넘어온 문자열을 깨지지 않고 받기 위해서 URLDecoder.decode() 을 이용해서 받거나 request.setCharacterEncoding() 을 이용해서 직접적인 선언을 해서 받아줬습니다. 또한 받은 매개변수를 정확한 내용으로 변경하기 위해 new String(request.getParameter("매개변수명").getBytes("ISO-8859-1"), "UTF-8) 와 같이 길게 변환을 해주는 작업까지 직접 해줘야 했습니다.
하지만, 이런 불편함을 해결하기 위해서 Java 진영에서는 WAS 에서 문자열을 정해진 인코딩으로 직접 받아오는 방법을 제공하기 시작했습니다.
Java 에서 가장 많이 사용되는 Apache Tomcat 에서 주로 사용하는 <Connector> 의 URIEncoding 은 이렇게해서 만들어진 것입니다. 지금은 그냥 공식처럼 <Connector URIEncoding="UTF-8" /> 와 같이 선언하면 매개변수값을 UTF-8 로 그냥 받을 수 있지만, 예전에는 그렇지 않았습니다. 물론 이 또한 GET 에서만 제공되는 방법이고, WAS 마다 GET 을 위한 URL Encoding 명시 방법은 다르기 때문에 사용하는 WAS 에서 어떤 방식을 제공하는지 확인 후 사용해야 할 것입니다. 많이 사용하는 웹로직만 간단히 예를 들면, 웹로직의 가장 기본이 되는 weblogic.xml 파일을 생성한 뒤 다음과 같은 내용을 입력하면 Tomcat 의 URIEncoding 와 같은 효과를 가지게 됩니다.
<wls:charset-params>
<wls:input-charset>
<wls:resource-path>/</wls:resource-path>
<wls:java-charset-name>EUC-KR</wls:java-charset-name>
</wls:input-charset>
</wls:charset-params>
하지만, 이것들은 WAS 에 종속적이므로 소스 상에서 직접 제어를 하고자 할 때에는 request.setCharacterEncoding() 으로 선언하는 방법을 쓸 수 있습니다. 하지만, 개인적으로는 비효율적이라 생각합니다.
그럼 POST 방식은 어떻게 구현할까요? Spring 을 쓰시는 분들은 web.xml 에 아래와 같이 선언한 것을 많이들 보셨을 겁니다.
<filter>
<filter-name>encodingFilter</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
<async-supported>false</async-supported>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</filter>
필터를 이용한 자동 변환 방법인데, 사실 예전에 Spring 에서 이와 같이 필터를 제공해주기 전에는 CharacterEncodingFilter 와 같은 역활을 해주는 필터를 직접 사용자가 구현해서 필터로 등록해서 사용했습니다. Spring 이 많은 편리함을 제공해준다는게 이런 곳에서도 잘 나타나는 것이죠.
개인적으로 바빠지다 보니 점점 글의 내용이 빈약해진다는게 저 스스로도 느껴지네요. 다음 번에는 인코딩에 대한 마지막 글인 MySQL 에서 정보를 가져올 때 인코딩 설정을 어떻게 하는지 간략하게 알아보고 당분간 팁을 작성하는 것은 쉬어야겠네요.
2015년 7월 2일 목요일
인코딩(Encoding)에 대한 이해 - (2) HTML 에서의 캐릭터셋(CharSet) 지정.
웹 개발을 하면서 처음에는 까다롭게 다가오다가 어느 순간 의미도 모른채 그냥 그 설정 그대로 유지하는게 바로 언어에 대한 인코딩이
아닌가 합니다. 특히 정형화된 구조에서 크게 문제가 발생하지 않기 때문에 신경을 쓰지 않다가 새로운 환경으로 이전을 하게
된다거나 할 때 한글이 깨지는 등의 문제가 발생하여 고생을 할 때가 종종 있습니다.
그래서 인코딩에 대한 최소한의 내용을 알려드려 크게 당황하지 않도록 도움을 드리고자 합니다.
이 글은 초보자를 위한 글이므로, 인코딩(Encoding) 정도는 우습다는 분은 패스해주시길...^^;;;
------------------------------------------------------------------------------------------------------
먼저 살펴볼 것은 HTML 의 캐릭터셋 설정입니다. 아직 웹 프로그램에 익숙하지 않은 분들 중에선 서버와 클라이언트 영역을 혼동하시는 분들이 계신데, 흔히 말하는 웹 프로그램 언어는 서버에서 해석이 되며, HTML 등을 만들어내는 역활을 합니다(물론 동적으로 만들어내는 경우에). 그리고 이렇게 만들어진 HTML 은 사용자의 장비로 전송되어 클라이언트의 브라우져에서 해석되어져 사용자에게 보여지게 됩니다. 이 때 HTML 뿐만 아니라 Javascript, CSS 들도 HTML 에 정의된 내용에 따라 처리되거나 서버에서 읽어오기 때문에 정확한 내용을 읽어오는 것은 중요합니다.
사용자의 브라우져는 HTML 을 해석할 때 스스로 기본적인 캐릭터셋을 가지고 해석을 시도하거나 문서의 내용을 읽어보고 캐릭터셋을 파악할 수 있는지 시도해봅니다. 강제로 지정되어 있다면 그 방식대로 인코딩해서 읽지만, 그렇지 않다면 스스로 인코딩 방식을 변경할 수도 있습니다. 이 때 HTML 내용 중에 <haed> 영역에서 <meta> 로 선언된 부분 중 캐릭터셋에 관련된 설정을 읽어 이를 파악합니다. 주로 다음과 같은 형식으로 되어 있습니다.
<meta http-equiv="content-type" content="text/html; charset=utf-8">
혹은
<meta charset="UTF-8">
전자는 기존의 HTML4, 후자는 HTML5 의 선언방식입니다.
보통 <head> 에서도 가장 먼저 선언을 하는 편이고, 이렇게 선언을 하면(위에서는 utf-8 로 선언을 했습니다) 브라우저는 선언된 방식으로 인코딩을 해서 문서를 해석하려고 할 것입니다.
그럼 외부 링크를 통한 문서 중 Javascript 나 CSS 파일은 어떨까요?
먼저 Javascript 는 HTML 에서 다음과 같이 외부 파일 형태로 읽어올 수 있습니다.
<script type="text/javascript" src="/js/test.js"></script>
이렇게 HTML 에서 외부 파일을 지정하면 다시 서버에 해당 파일을 요청하여 읽어온 뒤 해석을 합니다(type 대신에 language="javascript" 쓰는건 비표준이니까 type 으로 지정하세요). 이 때, 읽어올 파일에 대한 캐릭터셋을 지정할 수 있습니다.
<script type="text/javascript" src="/js/test.js" charset="UTF-8"></script>
눈치채셨겠지만, 동일한 캐릭터셋으로 저장된 파일이라면 굳이 선언을 하지 않아도 됩니다. 하지만, HTML 은 UTF-8 로 저장되었는데, Javascript 파일은 다른 곳에서 가져올 경우 캐릭터셋이 다를 경우 인코딩을 잘못 하여 내용이 깨질 수 있다고 판단되면 charset 애트리뷰트를 명시하여 정확하게 불러오는 것이 좋습니다.
CSS 는 <script> 와 마찬가지로 <link> 의 charset 을 이용할 수도 있지만, 반대로 CSS 파일 제일 상단에 캐릭터셋을 정의할 수도 있습니다.
@charset "UTF-8";
표준 문서에 보면 외부 css 파일을 불러올 때만 사용하고, 파일 제일 상단에 지정하라고 되어 있습니다.
이렇게 하면 정적인 HTML 에서도 인코딩 문제로 인해 글자가 깨지는 문제는 발생하지 않을 것입니다.
팁을 하나 드리면, 흔히 쓰는 이클립스에서는 확장자 별로 캐릭터셋을 UTF-8 로 미리 지정을 해서 새로운 파일을 만들 때 별도로 설정할 필요가 없도록 할 수 있습니다.
윈도우즈용 이클립스 기준으로 CSS 파일을 선언하는 곳은,
Windows > Preferences > General > Content Types
로 이동한 뒤,
Content types: > Text > CSS
을 선택하고 하단의
File associations:
에서 원하는 파일 확장자를 선택한 뒤
Default encoding:
에 UTF-8 을 입력한 뒤 Update 을 누르고 OK 을 눌러서 반영하면 됩니다. 물론 js 파일이나 JSP, HTML, Java 모두 이런 방식으로 인코딩 선언이 가능합니다.
개인적인 일이 좀 바빠서 이번 글은 좀 늦게, 그리고 성의없이(?), 그리고 짧게 끝냈습니다. 죄송합니다. 다음에는 WAS 와 JSP 에서의 설정을 설명드리겠습니다.
이 글은 제 개인 블로그(http://zepinos.blogspot.kr)와 okky(http://okky.kr)에만 공개되는 글입니다. 퍼 가는 것은 금해주시고, 링크로 대신해주시기 바랍니다. 당연히 상업적 용도로 이용하시면...저랑 경찰서에서 정모하셔야 합니다. ^^;;;
위에 작성한 코드 등은 실제 컴파일한 것이 아니라 제가 글을 적으면서 키보드 코딩(?...손 코딩의 친구) 한 것이므로, 오류가 있다면 저에게 알려주시면 고맙겠습니다.
그래서 인코딩에 대한 최소한의 내용을 알려드려 크게 당황하지 않도록 도움을 드리고자 합니다.
이 글은 초보자를 위한 글이므로, 인코딩(Encoding) 정도는 우습다는 분은 패스해주시길...^^;;;
------------------------------------------------------------------------------------------------------
먼저 살펴볼 것은 HTML 의 캐릭터셋 설정입니다. 아직 웹 프로그램에 익숙하지 않은 분들 중에선 서버와 클라이언트 영역을 혼동하시는 분들이 계신데, 흔히 말하는 웹 프로그램 언어는 서버에서 해석이 되며, HTML 등을 만들어내는 역활을 합니다(물론 동적으로 만들어내는 경우에). 그리고 이렇게 만들어진 HTML 은 사용자의 장비로 전송되어 클라이언트의 브라우져에서 해석되어져 사용자에게 보여지게 됩니다. 이 때 HTML 뿐만 아니라 Javascript, CSS 들도 HTML 에 정의된 내용에 따라 처리되거나 서버에서 읽어오기 때문에 정확한 내용을 읽어오는 것은 중요합니다.
사용자의 브라우져는 HTML 을 해석할 때 스스로 기본적인 캐릭터셋을 가지고 해석을 시도하거나 문서의 내용을 읽어보고 캐릭터셋을 파악할 수 있는지 시도해봅니다. 강제로 지정되어 있다면 그 방식대로 인코딩해서 읽지만, 그렇지 않다면 스스로 인코딩 방식을 변경할 수도 있습니다. 이 때 HTML 내용 중에 <haed> 영역에서 <meta> 로 선언된 부분 중 캐릭터셋에 관련된 설정을 읽어 이를 파악합니다. 주로 다음과 같은 형식으로 되어 있습니다.
<meta http-equiv="content-type" content="text/html; charset=utf-8">
혹은
<meta charset="UTF-8">
전자는 기존의 HTML4, 후자는 HTML5 의 선언방식입니다.
보통 <head> 에서도 가장 먼저 선언을 하는 편이고, 이렇게 선언을 하면(위에서는 utf-8 로 선언을 했습니다) 브라우저는 선언된 방식으로 인코딩을 해서 문서를 해석하려고 할 것입니다.
그럼 외부 링크를 통한 문서 중 Javascript 나 CSS 파일은 어떨까요?
먼저 Javascript 는 HTML 에서 다음과 같이 외부 파일 형태로 읽어올 수 있습니다.
<script type="text/javascript" src="/js/test.js"></script>
이렇게 HTML 에서 외부 파일을 지정하면 다시 서버에 해당 파일을 요청하여 읽어온 뒤 해석을 합니다(type 대신에 language="javascript" 쓰는건 비표준이니까 type 으로 지정하세요). 이 때, 읽어올 파일에 대한 캐릭터셋을 지정할 수 있습니다.
<script type="text/javascript" src="/js/test.js" charset="UTF-8"></script>
눈치채셨겠지만, 동일한 캐릭터셋으로 저장된 파일이라면 굳이 선언을 하지 않아도 됩니다. 하지만, HTML 은 UTF-8 로 저장되었는데, Javascript 파일은 다른 곳에서 가져올 경우 캐릭터셋이 다를 경우 인코딩을 잘못 하여 내용이 깨질 수 있다고 판단되면 charset 애트리뷰트를 명시하여 정확하게 불러오는 것이 좋습니다.
CSS 는 <script> 와 마찬가지로 <link> 의 charset 을 이용할 수도 있지만, 반대로 CSS 파일 제일 상단에 캐릭터셋을 정의할 수도 있습니다.
@charset "UTF-8";
표준 문서에 보면 외부 css 파일을 불러올 때만 사용하고, 파일 제일 상단에 지정하라고 되어 있습니다.
이렇게 하면 정적인 HTML 에서도 인코딩 문제로 인해 글자가 깨지는 문제는 발생하지 않을 것입니다.
팁을 하나 드리면, 흔히 쓰는 이클립스에서는 확장자 별로 캐릭터셋을 UTF-8 로 미리 지정을 해서 새로운 파일을 만들 때 별도로 설정할 필요가 없도록 할 수 있습니다.
윈도우즈용 이클립스 기준으로 CSS 파일을 선언하는 곳은,
Windows > Preferences > General > Content Types
로 이동한 뒤,
Content types: > Text > CSS
을 선택하고 하단의
File associations:
에서 원하는 파일 확장자를 선택한 뒤
Default encoding:
에 UTF-8 을 입력한 뒤 Update 을 누르고 OK 을 눌러서 반영하면 됩니다. 물론 js 파일이나 JSP, HTML, Java 모두 이런 방식으로 인코딩 선언이 가능합니다.
개인적인 일이 좀 바빠서 이번 글은 좀 늦게, 그리고 성의없이(?), 그리고 짧게 끝냈습니다. 죄송합니다. 다음에는 WAS 와 JSP 에서의 설정을 설명드리겠습니다.
이 글은 제 개인 블로그(http://zepinos.blogspot.kr)와 okky(http://okky.kr)에만 공개되는 글입니다. 퍼 가는 것은 금해주시고, 링크로 대신해주시기 바랍니다. 당연히 상업적 용도로 이용하시면...저랑 경찰서에서 정모하셔야 합니다. ^^;;;
위에 작성한 코드 등은 실제 컴파일한 것이 아니라 제가 글을 적으면서 키보드 코딩(?...손 코딩의 친구) 한 것이므로, 오류가 있다면 저에게 알려주시면 고맙겠습니다.
2015년 6월 29일 월요일
인코딩(Encoding)에 대한 이해 - (1) ASCII 부터 UTF-8 까지의 변화.
웹 개발을 하면서 처음에는 까다롭게 다가오다가 어느 순간 의미도 모른채 그냥 그 설정 그대로 유지하는게 바로 언어에 대한 인코딩이 아닌가 합니다. 특히 정형화된 구조에서 크게 문제가 발생하지 않기 때문에 신경을 쓰지 않다가 새로운 환경으로 이전을 하게 된다거나 할 때 한글이 깨지는 등의 문제가 발생하여 고생을 할 때가 종종 있습니다.
그래서 인코딩에 대한 최소한의 내용을 알려드려 크게 당황하지 않도록 도움을 드리고자 합니다.
이 글은 초보자를 위한 글이므로, 인코딩(Encoding) 정도는 우습다는 분은 패스해주시길...^^;;;
------------------------------------------------------------------------------------------------------
일반적으로 한국어를 이용하는 분들이 프로그래밍을 하면서 가장 많이 겪게 되는 인코딩(Encoding)은 ASCII, ISO-8859-1, CP949, MS949, EUC-KR, UTF-8, UTF-16 정도일 것입니다. 이런 인코딩은 무엇을 의미하는 것일까요?
최초의 컴퓨터가 애니악이라는 것은 많은 분들이 잘 아실 겁니다. 저 역시 초등학교(국민학교) 때 애니악, 애드삭, 애드박 등 달달 외어서 전국 컴퓨터 경진대회 출전하고 했던 기억이 나네요. 중요한건 이게 아닙니다만, 어쨌든 초기에는 이런 컴퓨터가 만들어져도 천공카드라고 하는 구멍 뚫린 종이를 이용해서 입력을 했지, 사람이 인식하는 글자로 입력을 한 건 아니었습니다. 그래서 실제 문자에 대한 표준이 나오는데 십수년이 걸렸다고 하네요. 역시나 초등학교 때 BCD, ASCII, EBCDIC 코드에 대해서도 달달 외웠는데, 글자 길이에 따라서 짧은게 더 적은 비트를 이용한다...이렇게 외었더랬습니다. BCD 는 6bit, ASCII 는 7bit, EBCDIC 는 8bit...이렇게요. 가장 많이 사용하게 된 코드는 ASCII 가 되었습니다.
화면 상에 출력될 문자를 7bit 로 나타내게 된 건 영어 문화권의 국가에서 컴퓨터의 발전을 주도했기 때문이었습니다. 7bit 는 2^7 이므로 총 128 개(실제로는 127 개)의 문자를 표현할 수 있었고, 영어 대소문자 각 26 개 뿐만 아니라 화면상에 표시하기 위한(실제로는 beep 라고 하는 경고음까지) 제어문자까지 넣을 수 있는 크기였기 때문입니다.
하지만, 실제 라틴어에서 파생된 많은 언어들은 영어와 비슷하지만 몇가지 다른 문자들을 가지고 있고, 이러한 문자를 다 담는데 127 개로는 부족한 상황이 발생했습니다. 그래서 ISO 표준을 통해 ISO-8859(실제로는 ISO/IEC-8859 던가요) 를 재정하고 이런 추가 문자을 담을 수 있는 집합을 만들어냈습니다. 한 개의 추가 비트를 이용해서 문자의 수를 256 개로 늘려버린 것이죠. 하지만, 이 또한 모든 라틴 계열 문자를 담을 수는 없어서 서브 카테고리라는 것을 통해 문자 집합들을 별도로 관리하게 되었는데, 가장 보편적으로 이용되는 영어권 문자들을 라틴1이라는 영역으로 ISO-8859-1 이라고 정의한 것입니다. 물론 ISO-8859-2 도 있고...16 까지 존재한다고 기억합니다.
문제는, CJK 라고 흔히 불리는 중국/일본/한국어 같은 문자는 이런 문자 집합에 포함되지도 않았고, 포함되기 힘든 상황이었습니다.
먼저 한글입니다. 한글은 세종대왕께서 만드신 아주 과학적으로 창의적인 문자이고, 키보드로 타이핑 할 때에도 아주 효율적인 문자입니다. 하지만, 자소의 조합으로 만들어지다 보니문자를 저장할 때에는 약간의 문제가 발생합니다. "가" 라는 하나의 문자를 표현하기 위해서는 "ㄱ" 와 "ㅏ" 를 각각 저장하고 이를 조합하는 방식과 "가" 라는 글자 자체를 저장하는 방식이 있을 수 있습니다. 이를 각각 조합형과 완성형으로 부릅니다. 초반에는 이 두 진영의 의견이 엇갈렸으나, 국가에서 완성형을 채택합니다. 초기에는 현대 한국어에서만 쓰는 언어들만 코드를 부여해서 제공했는데, 드라마 "똠방각하" 가 방영하면서 문제가 생겼습니다. 정부가 지정한 완성형에서 "똠" 이 포함되지 않아 타이핑을 할 수가 없었던 것입니다. 그래서 확장 완성형이라는 코드도 나오고 표준안에 조합형도 포함시킵니다. 하지만 대세는 완성형으로 흘러가서 현재는 조합형을 거의 쓰지 않습니다. 점점 더 문자 집합을 늘리는데, 이렇게 해서 나오게 된 코드가 KSC 5601 이고 이것이 EUC-KR 입니다. 당연히 일본 쪽도 비슷한 과정을 거치면서 EUC-JP 을 만들었고 중국 역시 별도의 언어 집합을 만듭니다.
Microsoft 는 여기서 좀 더 많은 문자집합을 포함한 코드를 만들어내는데 이것이 CP949 혹은 MS949 입니다.
여기서 문자 코드가 정리되는 듯 했지만, 결국 세계화 시대에 접어들면서 하나의 문서에 여러 언어가 같이 표현될 일이 잦아졌습니다. 그래서 세계의 모든 언어에 코드를 부여해서 사용할 수 있는 문자 집합의 필요성이 대두되었고, 가장 두드러지게 강세를 보였던 두 개의 코드가 나타났습니다. 바로 UTF-16 와 UTF-8 입니다.
얼핏 보기엔 16 비트와 8 비트로 보이고, UTF-16 이 더 큰 문자 집합 같아 보이지만, 사실 그렇진 않습니다. UTF-16 은 16bit 혹은 32bit 로 표현되며, UTF-8 은 8bit~32bit(1byte~4byte, 실제로는 3byte 안에 대부분의 언어가 다 포함되어 있음) 가변 형태로 표현이 됩니다. UTF-16 은 문서 내용 앞에 BOM(Byte Order Mark) 이라고 불리는 값을 입력해서 이 문서가 UTF-16 으로 작성된 문서임을 알립니다. UTF-8 은 저장된 값의 연산을 통해 이 문서가 UTF-8 을 알 수 있도록 구성되어 있습니다. 하지만, MS 에서 UTF-8 에도 BOM 을 앞에 삽입하게 됨으로써(UTF-8 표준에는 BOM 을 넣을 필요도 없고, 넣지 않는 것을 권고하고 있고, 넣지 않는게 표준이라고 분명히 명시하고 있습니다) 메모장 등으로 저장한 UTF-8 은 앞에 BOM 이 강제로 삽입되게 되고, 이를 Java 에서 읽을 경우 BOM 영역 때문에 문서 앞이 깨지고 이상 동작이 발생하는 문제가 생기게 되었습니다. 여기서 분명 말씀드리지만, UTF-8 에서 BOM 은 빼는게 맞고, Java 는 표준에 맞는 행동을 하기 때문에 비표준 방식에서 문제가 나타나는 것일 뿐입니다. 그래서 비표준 문서를 바꾸는게 맞는 방법입니다.
어쨌든 국내에서는 초반에 UTF-16 을 좀 더 선호하는 경향이 있었습니다. UTF-8 에서 한글은 모두 16bit 안에 코드가 부여되어서 한 글자를 표현하는데 16bit 가 소비되었지만, UTF-8 에서는 24bit 영역(3바이트)에 코드가 부여되어 있어서 동일한 내용을 저장하는데 UTF-16 이 더 효율적이었기 때문이었습니다. 그래서 제가 초반에 다루었던 수많은 한국학 관련 XML 데이터들은 모두 UTF-16 으로 작성되었습니다.
하지만, UTF-8 은 UTF-16 보다 나은 장점 하나가 있었습니다. 가변 방식이다 보니, 8bit(1byte) 영역에 정의된 문자들은 UTF-16 보다 적은 공간을 차지한다는 것이었습니다. 이 8bit 영역에 정의된 문자가 바로 ISO-8859-1 에 정의된 영어권 문자들이었습니다. 앞서 말씀드렸듯이 영어권이 가장 큰 힘을 발휘하고 있는게 사실이고, 그 사람들은 자기들이 문서를 작성하는데 왜 공간을 낭비하냐는 생각이 앞섰기 때문에 UTF-8 에 더 힘을 실어 주었습니다. 게다가 UTF-8 의 8bit 영역은 ISO-8859-1 와 코드값이 일치해서 그들의 입맛에 더 맞는 형태였습니다.
그러나 예외는 있습니다. 한자가 특히 큰 문제인데요...한자는 아직도 새롭게 생겨나고 있는 언어입니다. 우리나라도 예외는 아닌데, 특히 조선시대 양반들의 경우 자신의 이름에 쓰이는 한자가 다른 사람과 동일하게 쓰이는 것을 싫어해서 원래 한자에 점 하나를 더 찍거나 선 하나를 더 긋는 식으로 새로운 한자를 만들어내기도 했습니다. 이런 문제 때문에 아직도 신출자라고 하는 형태로 해서 새로운 한자가 추가되고 있으며, 중국과 일본에서도 자신들만의 한자를 계속 만들어내고 있는 형편입니다. 그래서 이런 한자들을 써야하는 곳에서는 별도의 폰트를 만들어서 다운로드해서 쓰게 하고 있습니다.
이렇게 문자코드가 발전을 해왔는데, 사실 현재의 대세는 UTF-8 이 되어버린 상황입니다. 그래서 예전 코드를 관리하는 입장에서라면 문자 코드를 유지하는 것이 좋지만, 새로운 프로젝트에서는 UTF- 8 로 문자 집합을 통일해서 쓰는 것을 제안하는 바입니다.
다음 글에서는 HTML 에서 JSP, Java, DBMS 로 이어지는 문자 코드 설정에 대해서 글을 적어보겠습니다.
이 글은 제 개인 블로그(http://zepinos.blogspot.kr)와 okky(http://okky.kr)에만 공개되는 글입니다. 퍼 가는 것은 금해주시고, 링크로 대신해주시기 바랍니다. 당연히 상업적 용도로 이용하시면...저랑 경찰서에서 정모하셔야 합니다. ^^;;;
위에 작성한 코드 등은 실제 컴파일한 것이 아니라 제가 글을 적으면서 키보드 코딩(?...손 코딩의 친구) 한 것이므로, 오류가 있다면 저에게 알려주시면 고맙겠습니다.
그래서 인코딩에 대한 최소한의 내용을 알려드려 크게 당황하지 않도록 도움을 드리고자 합니다.
이 글은 초보자를 위한 글이므로, 인코딩(Encoding) 정도는 우습다는 분은 패스해주시길...^^;;;
------------------------------------------------------------------------------------------------------
일반적으로 한국어를 이용하는 분들이 프로그래밍을 하면서 가장 많이 겪게 되는 인코딩(Encoding)은 ASCII, ISO-8859-1, CP949, MS949, EUC-KR, UTF-8, UTF-16 정도일 것입니다. 이런 인코딩은 무엇을 의미하는 것일까요?
최초의 컴퓨터가 애니악이라는 것은 많은 분들이 잘 아실 겁니다. 저 역시 초등학교(국민학교) 때 애니악, 애드삭, 애드박 등 달달 외어서 전국 컴퓨터 경진대회 출전하고 했던 기억이 나네요. 중요한건 이게 아닙니다만, 어쨌든 초기에는 이런 컴퓨터가 만들어져도 천공카드라고 하는 구멍 뚫린 종이를 이용해서 입력을 했지, 사람이 인식하는 글자로 입력을 한 건 아니었습니다. 그래서 실제 문자에 대한 표준이 나오는데 십수년이 걸렸다고 하네요. 역시나 초등학교 때 BCD, ASCII, EBCDIC 코드에 대해서도 달달 외웠는데, 글자 길이에 따라서 짧은게 더 적은 비트를 이용한다...이렇게 외었더랬습니다. BCD 는 6bit, ASCII 는 7bit, EBCDIC 는 8bit...이렇게요. 가장 많이 사용하게 된 코드는 ASCII 가 되었습니다.
화면 상에 출력될 문자를 7bit 로 나타내게 된 건 영어 문화권의 국가에서 컴퓨터의 발전을 주도했기 때문이었습니다. 7bit 는 2^7 이므로 총 128 개(실제로는 127 개)의 문자를 표현할 수 있었고, 영어 대소문자 각 26 개 뿐만 아니라 화면상에 표시하기 위한(실제로는 beep 라고 하는 경고음까지) 제어문자까지 넣을 수 있는 크기였기 때문입니다.
하지만, 실제 라틴어에서 파생된 많은 언어들은 영어와 비슷하지만 몇가지 다른 문자들을 가지고 있고, 이러한 문자를 다 담는데 127 개로는 부족한 상황이 발생했습니다. 그래서 ISO 표준을 통해 ISO-8859(실제로는 ISO/IEC-8859 던가요) 를 재정하고 이런 추가 문자을 담을 수 있는 집합을 만들어냈습니다. 한 개의 추가 비트를 이용해서 문자의 수를 256 개로 늘려버린 것이죠. 하지만, 이 또한 모든 라틴 계열 문자를 담을 수는 없어서 서브 카테고리라는 것을 통해 문자 집합들을 별도로 관리하게 되었는데, 가장 보편적으로 이용되는 영어권 문자들을 라틴1이라는 영역으로 ISO-8859-1 이라고 정의한 것입니다. 물론 ISO-8859-2 도 있고...16 까지 존재한다고 기억합니다.
문제는, CJK 라고 흔히 불리는 중국/일본/한국어 같은 문자는 이런 문자 집합에 포함되지도 않았고, 포함되기 힘든 상황이었습니다.
먼저 한글입니다. 한글은 세종대왕께서 만드신 아주 과학적으로 창의적인 문자이고, 키보드로 타이핑 할 때에도 아주 효율적인 문자입니다. 하지만, 자소의 조합으로 만들어지다 보니문자를 저장할 때에는 약간의 문제가 발생합니다. "가" 라는 하나의 문자를 표현하기 위해서는 "ㄱ" 와 "ㅏ" 를 각각 저장하고 이를 조합하는 방식과 "가" 라는 글자 자체를 저장하는 방식이 있을 수 있습니다. 이를 각각 조합형과 완성형으로 부릅니다. 초반에는 이 두 진영의 의견이 엇갈렸으나, 국가에서 완성형을 채택합니다. 초기에는 현대 한국어에서만 쓰는 언어들만 코드를 부여해서 제공했는데, 드라마 "똠방각하" 가 방영하면서 문제가 생겼습니다. 정부가 지정한 완성형에서 "똠" 이 포함되지 않아 타이핑을 할 수가 없었던 것입니다. 그래서 확장 완성형이라는 코드도 나오고 표준안에 조합형도 포함시킵니다. 하지만 대세는 완성형으로 흘러가서 현재는 조합형을 거의 쓰지 않습니다. 점점 더 문자 집합을 늘리는데, 이렇게 해서 나오게 된 코드가 KSC 5601 이고 이것이 EUC-KR 입니다. 당연히 일본 쪽도 비슷한 과정을 거치면서 EUC-JP 을 만들었고 중국 역시 별도의 언어 집합을 만듭니다.
Microsoft 는 여기서 좀 더 많은 문자집합을 포함한 코드를 만들어내는데 이것이 CP949 혹은 MS949 입니다.
여기서 문자 코드가 정리되는 듯 했지만, 결국 세계화 시대에 접어들면서 하나의 문서에 여러 언어가 같이 표현될 일이 잦아졌습니다. 그래서 세계의 모든 언어에 코드를 부여해서 사용할 수 있는 문자 집합의 필요성이 대두되었고, 가장 두드러지게 강세를 보였던 두 개의 코드가 나타났습니다. 바로 UTF-16 와 UTF-8 입니다.
얼핏 보기엔 16 비트와 8 비트로 보이고, UTF-16 이 더 큰 문자 집합 같아 보이지만, 사실 그렇진 않습니다. UTF-16 은 16bit 혹은 32bit 로 표현되며, UTF-8 은 8bit~32bit(1byte~4byte, 실제로는 3byte 안에 대부분의 언어가 다 포함되어 있음) 가변 형태로 표현이 됩니다. UTF-16 은 문서 내용 앞에 BOM(Byte Order Mark) 이라고 불리는 값을 입력해서 이 문서가 UTF-16 으로 작성된 문서임을 알립니다. UTF-8 은 저장된 값의 연산을 통해 이 문서가 UTF-8 을 알 수 있도록 구성되어 있습니다. 하지만, MS 에서 UTF-8 에도 BOM 을 앞에 삽입하게 됨으로써(UTF-8 표준에는 BOM 을 넣을 필요도 없고, 넣지 않는 것을 권고하고 있고, 넣지 않는게 표준이라고 분명히 명시하고 있습니다) 메모장 등으로 저장한 UTF-8 은 앞에 BOM 이 강제로 삽입되게 되고, 이를 Java 에서 읽을 경우 BOM 영역 때문에 문서 앞이 깨지고 이상 동작이 발생하는 문제가 생기게 되었습니다. 여기서 분명 말씀드리지만, UTF-8 에서 BOM 은 빼는게 맞고, Java 는 표준에 맞는 행동을 하기 때문에 비표준 방식에서 문제가 나타나는 것일 뿐입니다. 그래서 비표준 문서를 바꾸는게 맞는 방법입니다.
어쨌든 국내에서는 초반에 UTF-16 을 좀 더 선호하는 경향이 있었습니다. UTF-8 에서 한글은 모두 16bit 안에 코드가 부여되어서 한 글자를 표현하는데 16bit 가 소비되었지만, UTF-8 에서는 24bit 영역(3바이트)에 코드가 부여되어 있어서 동일한 내용을 저장하는데 UTF-16 이 더 효율적이었기 때문이었습니다. 그래서 제가 초반에 다루었던 수많은 한국학 관련 XML 데이터들은 모두 UTF-16 으로 작성되었습니다.
하지만, UTF-8 은 UTF-16 보다 나은 장점 하나가 있었습니다. 가변 방식이다 보니, 8bit(1byte) 영역에 정의된 문자들은 UTF-16 보다 적은 공간을 차지한다는 것이었습니다. 이 8bit 영역에 정의된 문자가 바로 ISO-8859-1 에 정의된 영어권 문자들이었습니다. 앞서 말씀드렸듯이 영어권이 가장 큰 힘을 발휘하고 있는게 사실이고, 그 사람들은 자기들이 문서를 작성하는데 왜 공간을 낭비하냐는 생각이 앞섰기 때문에 UTF-8 에 더 힘을 실어 주었습니다. 게다가 UTF-8 의 8bit 영역은 ISO-8859-1 와 코드값이 일치해서 그들의 입맛에 더 맞는 형태였습니다.
그러나 예외는 있습니다. 한자가 특히 큰 문제인데요...한자는 아직도 새롭게 생겨나고 있는 언어입니다. 우리나라도 예외는 아닌데, 특히 조선시대 양반들의 경우 자신의 이름에 쓰이는 한자가 다른 사람과 동일하게 쓰이는 것을 싫어해서 원래 한자에 점 하나를 더 찍거나 선 하나를 더 긋는 식으로 새로운 한자를 만들어내기도 했습니다. 이런 문제 때문에 아직도 신출자라고 하는 형태로 해서 새로운 한자가 추가되고 있으며, 중국과 일본에서도 자신들만의 한자를 계속 만들어내고 있는 형편입니다. 그래서 이런 한자들을 써야하는 곳에서는 별도의 폰트를 만들어서 다운로드해서 쓰게 하고 있습니다.
이렇게 문자코드가 발전을 해왔는데, 사실 현재의 대세는 UTF-8 이 되어버린 상황입니다. 그래서 예전 코드를 관리하는 입장에서라면 문자 코드를 유지하는 것이 좋지만, 새로운 프로젝트에서는 UTF- 8 로 문자 집합을 통일해서 쓰는 것을 제안하는 바입니다.
다음 글에서는 HTML 에서 JSP, Java, DBMS 로 이어지는 문자 코드 설정에 대해서 글을 적어보겠습니다.
이 글은 제 개인 블로그(http://zepinos.blogspot.kr)와 okky(http://okky.kr)에만 공개되는 글입니다. 퍼 가는 것은 금해주시고, 링크로 대신해주시기 바랍니다. 당연히 상업적 용도로 이용하시면...저랑 경찰서에서 정모하셔야 합니다. ^^;;;
위에 작성한 코드 등은 실제 컴파일한 것이 아니라 제가 글을 적으면서 키보드 코딩(?...손 코딩의 친구) 한 것이므로, 오류가 있다면 저에게 알려주시면 고맙겠습니다.
피드 구독하기:
글 (Atom)