eucKR 이냐..utf-8이냐.....
글쓴이: 쎄피로 / 작성시간: 화, 2004/03/09 - 4:58오후
안녕하세요..
회사에 리눅스 시스템이 다양하게 있는데요
전 어제 fedora를 설치했습니다.
기존 시스템들은 euckr로 되 있고 fedora는 utf-8을
사용하더군요. 덕분에 잘 쓰던 crt에서 한글 안되서 고생중이고..
기존 시스템의 한글 화일을 카피하면 iconv없이는 망막하고..
의문이 생기는 군요. 이런 불일치를 어떻게 쓰면 편하게
해결해 나갈것인가. ...
그리고 왜 utf8가는 것인가... 각종 터미널 프로그램들이
맥을 못 추는것을 보면..움.... 이런 의문들이 드네요..
unicode만이 font 세계의 해답인 것인가 ...움..
조언 답변 부탁드립니다.
감사합니다. ^^;
Forums:
확장성과 편리함의 차이...
물론 유니코드가 높은 비트로 전세계의 모든 언어를 구현하니 따지고 보면 당연히 유니코드를 써야 하겠지만...
또 현실은 그렇지 않죠. 뭐... 당장 호환성의 문제라는 것이 있으니...
모두들 현재까지 쓰던 캐릭터 코드를 포기하고 바로 유니코드로 바꾸는 데는 좀 시일이 걸릴 것이라 봅니다. 당장 좋은 것보다는 편한 것을 찾는 것이니.
cd매체가 tape보다 훨씬 우월함에도 불구하고 바로 시장을 잠식하지 못한 것과 비슷한거라 봅니다. ^^;
void main(void)
{
char *brain;
brain = malloc(sizeof(stress));
free(brain);
}
뭐든지 답은 간단한데서 시작한다.
어디서 들은 이야긴데, 유니코드로는 한글 3벌식 모아치기가 안된다더군
어디서 들은 이야긴데,
유니코드로는 한글 3벌식 모아치기가 안된다더군요.
[quote="happibum"]어디서 들은 이야긴데, 유니코드로는
유니코드와는 무관한 문제일듯 한데요 ;)
그건 입력기가 할일인걸요..?
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
[quote="happibum"]어디서 들은 이야긴데, 유니코드로는
코드와 입력방식과는 관계가 없습니다. ^^;
void main(void)
{
char *brain;
brain = malloc(sizeof(stress));
free(brain);
}
뭐든지 답은 간단한데서 시작한다.
1. 유니코드에 대해서저는 유니코드를 적극 지지 합니다. 그리고 un
1. 유니코드에 대해서
저는 유니코드를 적극 지지 합니다. 그리고 unicode가 charset 세계의 해답이라고 말하고 싶군요.
기존의 방식에서는 한글과 영어, 일본어, 인도어등을 한꺼번에 쓰는 방법이 없다(?)고 볼수 있겠습니다.
그러나 유니코드를 사용하면 그런 여러나라 글자들을 한꺼번에 표기가 가능하죠.
이것만 해도 충분한 메리트라고 할 수 있겠습니다.
예를 들어 일본어로 된 mp3파일을 우리나라로 가져오면 파일이름이나 태그나 읽을수 없게 되겠죠.
깨진다는 말입니다.
그러나 유니코드로 작성된 파일이라면 mp3 파일 이름도 멀쩡하고 태그도 일본어지만 읽을수 있게 됩니다.
게다가 이전 방식에서는 한글 패치를 하고 나서도 일본어 보이게 하려면 일본어 패치하고, 중국어 보이게하려면 중국어 패치하고 그런식이었습니다만, 유니코드 보이게 하면 한국어 중국어 일본어 상관없이
나머지 다른 글자까지 모두 보이게 되는 효율적인 상황이 됩니다.
폰트세계는 이제 거의 유니코드라고 봐야 합니다. 요즘 Xft를 많이 쓰고 있는데 ttf는 내부적으로 유니코드 테이블로 글리프를 관리한다는 점에서 유니코드로 바뀌었다고 볼수 있겠죠.
문제는 기존의 시스템과의 호환성인데, 이부분은 고생하는 수밖에 없겠습니다.
2. 모아치기
입력 방식과 charset과는 관계 없습니다. 모아치기는 입력기 수준에서 지원해야 하는 문제입니다.
그리고 유니코드가 아닌 euckr 수준에서는 오히려 모아치기를 구현하는 게 더 어렵다고 봐야 합니다.
현재 입력기 모아치기 기능에서 실질적으로 발목을 잡는 부분은 미완성 음절때문입니다.
입력기가 유니코드로 캐릭터 코드를 처리 하는 부분은 아무 문제가 없습니다만, 미완성 음절의 경우
그 글자를 화면에 보여주는 데서 문제가 생깁니다. (유니코드의 문제가 아니란 거죠)
미완성 음절이란, 초성과 종성만 있거나, 중성과 종성만 있는 글자들을 말합니다.
그런 글자들은 글꼴에 해당하는 글자체가 없어서 보여 줄때 어려움이 있기 때문입니다.
그래서 새나루( http://chem.skku.ac.kr/~kle/main/%BB%F5%B3%AA%B7%E7 )의 경우는 초성과 종성만 있는 경우
거짓 중성 ㅏ를 넣거나 중성과 종성만 있는 경우 거짓 초성 o을 넣어 마치 완성된 음절인 것 처럼
처리하는 시도를 하고 있습니다.
http://chem.skku.ac.kr/~kle/main/%BC%BC%B9%FA%BD%C4%B8%F0%BE%C6%C4%A1%B1%E2
[quote="krisna"]기존의 방식에서는 한글과 영어, 일본어, 인
iso-2022 규약이 그런 일을 가능하게 합니다. emacs-mule이 내부적으로 그렇게 다국어를 구현하도록 되어 있습니다(mule의 다국어 지원은 10년도 넘었습니다. 유니코드가 널리 쓰이기 이전부터...). euc-kr이나 iso-2022-kr도 iso-2022의 일부분으로 정의되어 있습니다.
오히려 다국어 문자열이 간단히 구분되는 장점도 있습니다. 이런 이유 때문에 일본 쪽에서는 한동안 유니코드를 싫어하는 사람들이 꽤 있던 걸로 압니다. 요즘에는 많이 나아졌겠죠... 하지만 iso-2022도 이런저런 이유도 안쓰고 요즘 대세가 유니코드라는 건 인정해야 하겠습니다(그래도 emacs-mule의 내부는 오랫동안 바뀌지 않을것 같군요. 이미 유니코드 인코딩도 처리가 되니...)
--
익스펙토 페트로눔
참고로 제가 관련이야기를 들었던곳은[url]http://moogi.n
참고로 제가 관련이야기를 들었던곳은
http://moogi.new21.org/zb41/view.php?id=bugreport&page=1&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=asc&no=11
입니다.
찬찬히 다시 읽어보니, 입력기가 유니코드기반에 기반했을때 문제가 생기는 것이지
유니코드글자를 모아치기로 입력할수없다는 이야기는 아니었네요...
답변 달아주신분들 감사합니다.
무지가 드러나도 배울수있으니 기쁩니다.
해결법이 안써있기에..한줄올려요..
저도 이걸루 고생좀했네요..
[root@Test ~]# cat /etc/sysconfig/i18n
LANG="ko_KR.eucKR"
SUPPORTED="en_US.UTF-8:en_US:en:ko_KR.eucKR:ko_KR:ko"
SYSFONT="lat0-sun16"
cameltv.net에서 설치한것. 페도라.
[root@stream ~]# cat /etc/sysconfig/i18n
LANG="ko_KR.UTF-8"
SYSFONT="none"
- 위두개중 한개는 UTF-8 한개는 eucKR이지요..
원하는것으로 쓰세요.. 위에껄로 해놓으니 아주 잘되네요...
아래것도 잘되요.. SYSFONT="none" 이거 없을때는 많이깨지더군요..
export LANG=Ko.KR_eucKR
이거 해두 안되더군요~~ 그럼 도움되셨기를.
-- 벌써 밤새 삽질하는중인데::한자질문들리깨요..
댓글 달기