한글이 제대로 안써지는데...

[soonsu]

ㅂㅞㄺ, ㅎㅐㅎ, ㄱㅑㄲ...등등

물론 맞춤법엔 틀린 글자들이긴 하지만..

그리고 꼭, 반드시 써야할 글자들은 아니지만..

그래도 한글이 제대로 표시가 안된다는게 아쉽네요..

아직 1.0 이하 버전이라서 그런가요?

아니면  뭔가 방법이 있는지..궁금하네요..

[빛알갱이]

어디서 말인가요? 이 게시판에 말인가요?

아니면 모든 곳에서 말인가요? 사용하시는 OS가 무엇인지요? 혹시 Win95?

[흠..]

ㅂㅞㄺ 아ㅎㅐㅎㅎㅐㅎ ㄸㅗㅁ방각하 ㅍㅔㅍ시

[지나다가...]

모든 게시판이 다 그런거같진않네요.

이곳은 글자가 제대로 표현 안되지만

다른 곳(적수보드 사용)에서 해보니 그곳에선 이상없네요.

[빛알갱이]

그렇다면 이 게시판의 버그입니다. 이 게시판은 현재 EUC-KR로 되어 있습니다. 따라서, 'ㄸㅗㅁ', '펩', 'ㅎㅔㅎ' 등의 글자를 2byte로 표현할 수 없습니다. 그런 글자들은 EUC-KR에서 8byte로 표현해야합니다. 따라서, 모질라는 KS X 1001 부록 2의 규정에 의거해서 그런 글자들을 8byte로 표현해서 서버에 보냅니다. 그런데, 이 게시판 프로그램은 8byte로 나타낸 글자의 선두를 가리키는 2byte (Hangul Filler)를 날려 버립니다. 한글 filler가 날아가면 모질라는 나머지 6byte를 모아서 한글 음절로 해석할 수 없으므로 자모로 풀어서 보여 줍니다. 반면에 다른 곳에서는 한글 filler를 날려 버리지 않으므로 8byte를 다시 모아서 음절로 표시해서 보여 줍니다. 물론 Hangul filler를 날리지 않아도 KS X 1001 부록 2의 규정을 제대로 따르지 않는 MS IE 등에서는 여전히 자모로 풀어서 표시되겠지요. 하지만, 그것은 MS IE의 버그입니다.

차니님, 이 게시판을 빨리 UTF-8로 전환하거나, 한글 filler를 날려 버리지 않도록 수정해 주세요.

당분간 이 문제를 피하고 싶으면 View | Character Encoding에서 'UHC' (확장 완성형)을 고른 후에 글을 올리세요.

[soonsu]

윈XP -sp2 이고요. 대체적으로 제로보드를 사용한 게시판에선 모두 제대로 안되는듯 싶네요... 답변 감사합니다.

참고로 UHC 로 하니 제대로 표현이 되는군요 ^^

[빛알갱이]

그렇다면 zeroboard의 버그네요. 누가 만들었는지 몰라도 참 이상한 사람이군요. 왜 Hangul Filler를 날려 버리도록 프로그램했는지 도저히 이해할 수 없군요.

zeroboard를 UTF-8에서 동작하도록 고쳐서 쓴 적이 있는데, 별 이상없이 잘 됩니다. 차니님, 귀찮아도 여기도 UTF-8로 변환하는게 어떻습니까? DB 전부 덤프한 다음에 UTF-8로 다시 넣으려면 좀 많이 귀찮기는 하겠지요?

> 아직 1.0 이하 버전이라서 그런가요?

잘 모르고 쓰신 말이니까 이해는 하지만, 모질라의 국제화를 맡은 사람으로서 상당히 기분 나쁜 얘기였습니다. 표준을 제대로 지키지 않고 엉터리로 처리하는 것은 모질라가 아니라 MS IE이니까요.

[soonsu]

기분나쁘셨다면 죄송합니다. ^^;;
님 말씀대로 잘 몰라서 한 말이니 이해해 주시기 바랍니다.
모질라나 파이어폭스에 대해 안것도 몇일 안되고 사용한것도 몇일 안되었거든요.
통상적인 다른 윈도우용 프로그램의 버전 개념이 보통 1.0 이하면 베타버전 정도로 여겨지기 때문에 이것도 그렇게 생각했을 뿐입니다.

[best3286]

흠.. 모질라에선 이상 없이 보네주는 것이였군요..
전 일본어가사, 하오체덕에 그냥 몇달전부터 미니보드를 UTF-8로 돌리고 있습니다 =_=;;
무작정 UTF-8로 돌리면 문제가 몇가지 있죠..
한글 글자 자르기, 한글의 3바이트 차지하는 대이터 공간 낭비..
더있을수 있겠지만 한글 자르기는 소스를 구하여 8바이트 문자까지 자르기가 되고..
대이터 공간 차지가 좀 걸리긴 하죠 ^^;;
아. 그리고 제로보드에서의 꽁수를 한가지 배웠군요 @_@;;

그런데 한가지 질문이 있습니다.
x-windows-949 가 윈도우 브라우저에서만 작동하는 문자셋인가요?
CP949와 같은 코드인듯한데.. 저문자셋으로 되있음 문제없이 확장 완성형글자까지 보네지더군요..

[빛알갱이]

순수님, 제가 좀 ㅂㅜㄿ필요하게 강한 어조를 쓴 것 같아서 죄송합니다. 괜히 그런 것 때문에 불여우를 미워하지 마시고, 아껴 써 주시고, 주변에도 널리 알려 주세요. 불여우를 쓰는 일은 브라우저 하나 바꾸는 일보다 좀더 중요한 의미가 있습니다. 우리가 소중하게 얻은 인터넷이란 공간과 그 안에서 누리는 여러 가지를 누군가에게 빼앗기지 않고 지켜나가는 것과 어느 정도 관련이 있으니까요.

> x-windows-949 가 윈도우 브라우저에서만 작동하는 문자셋인가요?

Mozilla는 cross-platform 브라우저입니다. 따라서, x-windows-949 [1]
는 모질라가 돌아가는 모든 플랫폼에서 지원됩니다. 하지만, 그렇다고 그것을 쓰는 것을 윈도우 바깥에서 쓰는 것을 (즉, 인터넷에서) 권장하지 않습니다. 다른 플랫폼에서 오직 모질라만 쓰는 것이 아니라면요.

어차피 그것으로도 한국어를 완벽하게 표현할 수 없습니다. 오직, 유니코드에 기반한 UTF-8과 같은 인코딩으로만 한글로 한국어를 완벽하게 표시할 수 있습니다. 그러니까, 모든 문서는 앞으로 UTF-8이나 UTF-16(UTF-8이 많은 경우에 더 바람직하지만, UTF-16이 유리한 경우도 있습니다.)을 써서 만들어야 합니다.


> 무작정 UTF-8로 돌리면 문제가 몇가지 있죠..
> 한글 글자 자르기, 한글의 3바이트 차지하는 대이터 공간 낭비..

UTF-8의 특성을 잘 이해하고 있으면 글자 경계를 가르는 일은 매우 쉽습니다. (그런데, 8byte는 무슨 얘기신지? UTF-8은 Unicode의 한 글자를 표현하는데 최고 4byte 밖에 쓰지 않습니다.)
또, 글자폭 계산을 위해서는 UTF-16이나 UTF-32로 변환한 뒤에 POSIX의 wcwidth()에 해당하는 함수 (PHP나 Perl에 비슷한 것이 있을 것입니다)를 쓰면 됩니다.

2바이트와 3바이트의 문제는 2004년에 그리 큰 문제가 된다고 보지 않습니다. 정말 문제가 된다면 UTF-16을 쓰는 수도 있습니다. 하지만, html 문서의 경우에는 많은 부분이 ASCII 영역의 글자이므로 UTF-16을 쓸 경우 ASCII 영역의 글자까지 2byte가 되어서 공간 절약의 효과가 그리 크지 않습니다. DB에 저장할 때 얘기라면, 요새 하드 디스크 엄청나게 싸잖아요? 또 DB가 아니고 그냥 저장한다면 얼마든지 좋은 압축 알고리즘이 많이 있고요.


[1] M$ 이 사람들 정말 짜증나는 사람들입니다. ,Windows-125(1,2,3,4,5) 등은 IANA에 다 등록해 놓고서 Windows-949/CP949/UHC는 등록을 하지 않고, 아무 관련도 없는 ks_c_5601-1987이란 이름을 자기네들 제품에서 쓰고 있습니다. 그 이름은 그 의미로 쓰면 안 되기 때문에 모질라에서는 'x-' (등록 안 된 MIME charset에 붙이는 prefix)를 붙여서 부릅니다.

[best3286]

예전에 하느글에선가 UTF-8은 8바이트까지 차지하며 한문은 7바이트까지 사용합니다.

라는 코맨트를 읽어본 기억때문에 쭉 그렇구나 라고 생각해 와 버렸내요 ;;
그런데 이상한건 4바이트까지라고 하셨는데.. 제가 가지고 있다는 UTF-8자르기 소스는

if ( $t == 9 || $t == 10 || (32 <= $t && $t <= 126) ) {$n=1;..........}
else if ( 194 <= $t && $t <= 223 ) {$n=2;..........}
else if ( 224 <= $t && $t <= 239 ) {$n=3;..........}
else if ( 240 <= $t && $t <= 247 ) {$n=4;..........}
else if ( 248 <= $t && $t <= 251 ) {$n=5;..........}
else if ( $t == 252 || $t == 253 ) {$n=6;..........}
else { ; }
로 되어 있거든요..

지금 다시보니 8바이트는 아니지만 6바이트까지 처리를 하더군요..
빛알갱이님 말씀대로 4바이트라면 실제로는
else if ( 248 <= $t && $t <= 251 ) {$n=5;..........}
else if ( $t == 252 || $t == 253 ) {$n=6;..........}
else { ; }
저부분은 없어도 된다는 건가요?


흠.. 그러고보면 왠지 웹용에 UTF-16으로 쓴다는것은 왠지 내키진 않는 방법이라 생각하거든요 ^^;
특히나 php를 돌리는 환경에서 UTF-16으로 돌린다면 <?php 등으로 php코드부에서의 처리가 곤란해 질테구요 @_@;;
( < 와 ? 사이에 null문자가 들어가 버리니 말이죠;; )


뭐 현제로선 무한db용량을 제공해준다는 계정들이 많으니... 2바이트공간 3바이트 공간 이런건 그리 따질때가 아닌듯 싶긴 하군요;;

[빛알갱이]

UTF-16은 저도 좋아하지 않습니다. 내부 프로세싱의 편의를 위해서라면 UTF-16 대신 UTF-32를 쓰는 걸 더 좋아합니다. 하지만, UTF-16도 장점이 없는 것은 아니고, 널리 쓰이기도 합니다. 다 용도에 맞게 쓰면 됩니다.

UTF-8을 쓰고 프로세싱할 때에만 UTF-32(혹은 UTF-16)로 변환해서 쓰면 됩니다. 프로세싱이 끝난 후에 다시 UTF-8로 바꿔서 출력하고요. UTF 사이의 변환은 그리 비싼 operation이 아닙니다. UTF-32로 변환해 놓고 나면 위에 적은 것과 같은 일을 할 필요도 별로 없습니다. 또, 위에 적어 놓으신 것은 이제는 쓰지 않는 5byte, 6byte도 유효한 것으로 처리하는 것 이외에도 문제가 아주 많습니다. 저 코드를 그대로 썼다가는 큰 일 나는 수가 있습니다. 다음에 적은 참고 문헌을 보시고 over long sequence filter, surrogate code point filter, Non-character filter 등을 다 구현하셔야 합니다.


6byte까지 된 것은 UTF-8의 옛날 정의입니다. UTF-8의 최대 길이는 4byte입니다. 네트웍에 돌아 다니는 확실치 않은 '전설'을 믿지 마시고 직접 표준 사이트에 가서 확인하는 습관을 들이세요. Unicode 4.0 책은 PDF로 모든 내용이 여기에 가면 있습니다.

<a href=http://www.unicode.org
target=_blank>http://www.unicode.org
</a>

또, ETF에서도 이에 맞게 UTF-8을 재정의한 RFC를 내놓았습니다.

<a href=http://www.faqs.org/rfcs/rfc3629.html
target=_blank>http://www.faqs.org/rfcs/rfc3629.html
</a>

-------------
<?php 등으로 php코드부에서의 처리가 곤란해 질테구요 @_@;;
( < 와 ? 사이에 null문자가 들어가 버리니 말이죠;; )
--------

그거야 PHP interpreter가 UTF-16을 이해하기만 하면 아무 문제도 없습니다. 즉, BOM을 보고 판단한다든지 하는 식으로. 예를 들어, 다음 문서에서 설명한 방법을 PHP interpreter도 약간 변형해서 적용할 수 있지요 :

<a href=http://www.w3.org/TR/2004/REC-xml-20040 ... c-guessing target=_blank>http://www.w3.org/TR/2004/REC-xml-20040 ... uessing</a>

[best3286]

모든 페이지를 전부 UTF-8로 돌려야 하는 홈페이지에도
over long sequence filter, surrogate code point filter, Non-character filter
라는 것들을 적용 해야 한다는 건가요? ;;;
잘못 넘어온 문자라든지 의도적으로 잘못 보네진 문자를 위한것이라면 모르겠지만..
그저 개인적인 적인 취미라고 해야할지...
친구들끼리 즐기는 홈페이지에서 저렇게까지 해야할진 모르겠구요 @_@;;
단지 문자 자르기는 고정 비트를 가지고 있는 UTF-16로 변환하고 자른다음 다시
UTF-8로 바꾸어서 표시하는건 좋은 방법인듯 하군요. ( UTF-16은 고정 바이트 문자셋 맞죠? ;;

아무튼 알려주신 문서들 지금은 영어 해석도 잘 않되는상황이라 보긴 힘들듯해도 필요하게 되면 봐야겠군요.
그리고보면.. php가 저런것까지 처리하면서 php문서를 파싱하면 속도에 영향이 크지 않을까 의문이 갑니다;;
부하가 거의 없는 서버는 모르겠지만 외국홈페이지를 보면 상당한 사용자들로 페이지 처리가 1초씩 걸리는 것들을
몇몇 보았는데 그런곳에선 상당히 문제되지 않을까 하는군요;;
저렇게 지원해도 속도에 거의 영향 없다면 다행이지만요 ^^;
영향간다헤도 BOM까지 판단하고 처리하는 php와 그렇지 않고 바로 처리하는 php다 따로나온다면 모르겠지만..
php게발자 분들이 여간 골치아프지 않을까 하는군요 ;;

[ddd]

쵝오