유니코드로 변환
글쓴이: hbsnow / 작성시간: 월, 2005/01/03 - 5:10오후
프로세스를 말씀드리면
중국프로젝트로... 중국어 간자를 사용합니다.
웹(리눅스아파치, PHP)에 어드민페이지에 사용자이름(중국간자)을 넣습니다
입력된 사용자이름은 mysql에 저장되며
저장된정보는 C프로그램을 통해
중국폰으로 네트웍 전송후 중국폰에 디스플레이됩니다
근데 글자가 깨집니다.
수많은 테스트를 통해 깨지지 않는 경우를 발견했는데..
유니코드로 저장된 텍스트 문서를 폰에 저장해서 읽어온 텍스트는 깨지지가 않습니다.
문제는 유니코드인데..
추론해본결과
1. 웹에서 유니코드로 문자를 넣는다 - 과연가능할지
제가 알기로는 ansi로 저장되는걸로 아는데...
2. ansi로 저장된 글자가 db에 들어가고 나중에 db에서 꺼내올때 ansi를 유니코드로 변환한다 - 말이되는건지.. 된다면 어떻게 변환할지
3. 제가알기로는 db에 저장될때는 유니코드로 저장되는걸로 아는데 아닌가요? -- 쩝
고수님들에 조언을 부탁드립니다
Forums:
Re: 유니코드로 변환
추론에서 재고하실 내용은
"그때 그때 달라요"
라는 학설입니다.
아시는 형태대로 고정되어 있는 것이 아니라, 학설대로입니다.
따라서, 원하시는대로 하실수도 있습니다.
가장 올바른 방법이.
그때 그때 달라요^^
가장 올바른 방법이 무얼지요??
제가 질문을 제대로 이해했는지는 모르겠습니다만...charset의
제가 질문을 제대로 이해했는지는 모르겠습니다만...
charset의 개념과 컴퓨터가 문자를 표현하는 방법에 대해서 좀 더 많은 이해가 필요한 것 같습니다.
일단, 유니코드에도 UCS-2, UCS-2BE, UCS-2LE, UCS-4, UCS-4LE, UCS-4BE, UTF-8, UTF-16, UTF-16BE, UTF-16LE, UTF-32, UTF-32BE, UTF-32LE 등의 여러 종류가 있음을 밝혀둡니다. ASCII 문자가 그대로 표현된다는 점 때문에 보통 사용하는 것은 UTF-8입니다만, 사용하시는 charset이 정확히 어떤 것인지는 잘 모르겠군요. 유니코드에 대한 자세한 내용은 아래 문서를 참고하세요.
http://www.cl.cam.ac.uk/~mgk25/unicode.html
웹에서 유니코드로 문자를 넣는다 함은 HTML에서 form을 통해 문자열을 입력받는다는 뜻으로 해석하겠습니다. 다음 페이지의 HTML 소스 처음 부분을 보십시오.
http://moniwiki.sourceforge.net/wiki.php
그냥 해당하는 HTML form 페이지의 charset만 원하시는 것으로 지정하면 받는 문자열은 지정한 charset으로 들어가게 됩니다. 옵션에서 지정하기 나름이지만, moniwiki는 UTF-8인코딩을 사용하며, 사용자가 입력한 텍스트 문서를 UTF-8 인코딩으로 저장합니다. 즉 CGI 쪽에서 처리하기 나름입니다.
그리고 ANSI로 저장한다 함은 올바른 문장이 아닙니다. ANSI란 charset은 없습니다.
컴퓨터는 문자를 숫자로 바꾸어 저장합니다. 하지만 어떤 숫자가 어떤 문자와 대응하는지는 약속하기 나름입니다. 이런 약속을 character set(이하 charset)이라 하며 일찌기 쓰였던 chaset중에 유명한 것으로는 ASCII, EBCDIC 등이 있습니다. 그러나 이러한 charset은 영어권 사용자를 위해 만들어진 것으로, 아시아권의 문자들을 전혀 표현할 수 없습니다. 무엇보다도 ASCII, EBCDIC 등에서 1자를 표현하기 위해 사용하는 저장공간이 1byte(2^8=256자)밖에 안됩니다.
그렇기 때문에 아시아의 각각의 나라에서는 EUC-KR, EUC-JP, Shift_JP, BIG5 등의 고유의 charset을 만들어 사용했습니다. 그 원리는 다음과 같습니다.
1. 우선 ASCII 안의 문자는 그대로 표현한다. (원래의 ASCII 문자들은 0~127까지만 사용합니다. 128~255의 그래픽 문자들은 확장 ASCII 문자라고 하며, 제공하는 업체마다 제각각입니다.)
2. 128~255인 byte 두개를 묶어서 자국어를 표현하는데 사용한다.
이러면 ASCII 문자들은 그대로 사용하면서 자국어도 같이 사용할 수 있게 되는 거지요. 이게 바로 영문자는 1byte로, 한글은 2byte로 표현하는 이유입니다.
그러나 서로 다른 charset을 사용하기 때문에 생기는 문제점들이 있었기 때문에 결국 모든 문자들을 표현할 수 있는 유니코드가 나오게 되었습니다. 그러나 이 유니코드는 0~65536영역을 거의 대부분 사용하기 때문에 기존의 아시아 문자를 처리했던 방법으로는 표현이 어렵게 되었습니다. (128*128= 16384밖에 안되죠)
그래서 위에서 말한 것과 같은 다양한 유니코드 charset들이 나오게 된 것입니다. 그 중에서 UTF-8이 가장 널리 쓰이는 이유는 ASCII 문자들을 원래 코드값 그대로 사용할 수 있기 때문입니다(예를 들자면, UTF-8문서를 기존의 UTF-8을 지원하지 않는 편집기로 열어보면 다른 문자들은 깨져서 나오지만 ASCII에 해당하는 문자들은 그대로 볼 수 있습니다). 대신에 ASCII에 들어가지 않는 문자들을 가변 byte로 표현하기 때문에 1자가 차지하는 byte가 1~?byte가 되므로, 1자 1자 잘라내는 것이 상당히 까다롭게 됩니다.
보통 db는 유니코드라고 해서 특별히 따로 처리하지 않으며(요새는 바뀌었을지도... 확인이 필요합니다) 그냥 연속된 byte들로 저장할 뿐입니다. 저장할 때 UTF-8인 문자열을 저장했다면 꺼낼때도 UTF-8로 나오겠지요. EUC-KR일때도 역시 EUC-KR로 들어가서 EUC-KR로 나오게 될 것입니다.
유니코드를 특별히 따로 처리하는 DB가 아닌 이상 그냥 연속된 byte열로 저장하는 것이 보통입니다. 즉, 그대로 저장하는 거지요.
현재 겪고있는 문제를 해결하기 위해서는, 각각의 진행과정에서 사용하는 charset을 정확히 알고 그에 맞춰 charset을 변환해서 처리하는 프로그램을 잘 짜는 수밖에는 없는 것 같습니다.
1. 웹의 form이 있는 HTML 문서에서 사용하는 charset(아마 BIG5같은 중국에서 사용하는 charset이나 UTF-8등의 유니코드 charset을 사용하게 될 겁니다.)
2. PHP와 C프로그램, MySQL 내부에서 사용하는 charset(이놈들은 그냥 charset을 무시하고 연속된 byte들로 처리할 가능성이 높습니다.)
3. 중국 폰에서 사용하는 charset(BIG5 같은 중국에서 사용하는 charset을 사용할 가능성이 높습니다. 아니면 유니코드 charset일수도...)
각각의 과정에서 charset간의 불일치는 프로그래머가 직접 변환해서 처리하는 코드를 짜서 처리해야 합니다. 이때 ICONV 같은 라이브러리가 유용하게 쓰일 수 있을 겁니다.
댓글 달기