complement

그냥 이전 버전을 사용해야 될거 같습니다.

이전 버전은 아무 문제가 없네요..

ybs485

몇가지 질문 올려봅니다..

1. 한글 파일을 드래그앤드롭했을때 모음자음이 다 풀려버리는데 해결법 아시는분 계신가요^^
2. vmware tools에서 shared folder 옵셔을 켰는데 shared folder를 추가하는건 어디서 하는건지를 못찾겠습니다 ^^
파렐렐즈처럼 설정하는 창을 찾을수가 없네요.

catz

1. 윈도XP는 유니코드를 근간으로 삼지 않아서 생기는 문제입니다.
패래럴즈는 컨버팅이 가능한가 보더군요.
비스타를 설치하시면 문제없습니다만, XP를 (완성형한글)을 사용하는 응용프로그램을 쓰면
마찬가지로 풀려버립니다.

2. setting 에 shared folder 기능을 켜는곳에서 + 키로 추가할 수 있습니다.

* 비스타는 fusion 이 더 잘지원하더군요. 패래럴즈에 비해 CPU점유율이 높지 않습니다.;

__________________
세벌사랑,한글사랑.
글이 살아야 나라가 산다.

socheon

이번참에 확 질렀습니다.
근데 구입하고 사용하다보니 잘 안되는것이 있네요..
맥에서는 인터넷이 잘 되는데 VMWare에서는 인터넷 연결이 안되네요.. 네트웍은 호스트의 설정을 공유할 수 있도록 되어 있는데.. 다시 종료했다가 부팅하기를 몇번 해도 안되요.. 뭐가 문제일까요?

aingoppa

유니코드를 근간으로 삼지 않아서 생기는 것은 아니고, Mac OS X의 Filename은 Unicode의 Canonical Decomposition(자소 분리)방식으로 한글, 일본어 등을 처리하는데 XP의 경우 이 방식을 제대로 지원해 주지 않기 때문에 문제가 생깁니다. XP도 Unicode가 근본입니다. parallels가 문제가 없다면 Unicode의 normalize를 한번 해 주는 것 같습니다. 그런데 Filename을 자소분리하는 OS가 Mac OS X 말고도 더 있는지 모르겠네요.

참고 : UAX #15: Unicode Normalization Forms

catz

앗 그런가요?

헌데 XP는 파일을 쓸때 CP949 로 한글을 쓰는것으로 알고 있습니다.
유니코드도 지원한다고 하지만요..

제가 공부가 많이 부족하군요+o+

__________________
세벌사랑,한글사랑.
글이 살아야 나라가 산다.

aingoppa

Windows의 언어 체계는 참 환장할 노릇입니다. 저도 프로그래밍 하다가 골머리 썩는 경우가 많습니다.

일단 XP에서 기본 FS인 NTFS는 최대 255자까지의 UTF-16을 입력받을 수 있습니다. 이론적으로는 CP949같은 것을 넣을 수 있기는 하지만 Windows자체가 Unicode외에 넣을 수 있는 방법을 제공하지도 않습니다. 즉 현재의 NTFS안에는 99.999%는 Unicode라고 할 수 있습니다. 단지 Mac OS X과 달리 자소 분리를 시키지 않고, 그래서인지 XP에는 자소 분리된 Unicode의 처리를 하지 않습니다.

NTFS.com File Types & File Attributes. ntoskrnl.exe & ntfs.sys

그런데 또다른 FS인 FAT32(혹은 더 이전의 FAT)의 경우 처음에는 ASCII용으로 개발 되었고 이후 여러국가에서 지 맘대로 쓰다보니 (제 사견입니다.) 전부 제 각각 ASCII와 호환되는 식으로 코드체계를 만들어 사용하는 겁니다. 그리고 당연히 FAT32에는 지가 어떤 코드체계로 파일 이름을 만들고 있는지의 정보를 저장하는 곳도 없습니다. 그래서 FAT32안의 CP949로 적힌 한글 코드를 CP949라고 미리 알고있지 않으면 제대로 읽어낼 수 없는 겁니다. 그리고 UTF-16이 영문의 경우 0값이 포함되는데 FAT32에서는 이걸 문자열의 끝이라고 생각해서 읽어내지 못하기 때문에 UTF-8이외의 Unicode는 사용할 수 없습니다. 그런데 XP에서는 UTF-8을 사용하지도 않지요.

... 그런 이유로 XP가 Unicode가 기본이라고 할 수도 있고 아닐 수도 있고 그런겁니다.

catz

링크주신것을 보니~ 이러저러한것들이 적혀있군요+O+
잘못된 지식을 또 하나 고쳐갑니다~ 아흣~
------------------

Vmware Fusion 에서 vista 사용시 공유폴더(share folder)에서 응용프로그램 설치가 불가능합니다.
다른 응용프로그램 이용하여 다운로드같은걸 이용하지도 못하고요.
반값에 끌리긴 하는데.. 패래럴이랑 갈팡질팡하게 되네요.

__________________
세벌사랑,한글사랑.
글이 살아야 나라가 산다.

ziozzang

뭔가 제가 알고 있는 것이랑 다른데요...

맥이 다른 OS와 계속 트러블이 생기는 이유는 맥의 유니코드 처리의 특수성때문입니다.맥에서는 유니코드로 저장을 하는것까지 맞는데, 이걸 풀어쓰기로 저장합니다. 뭐 물론 이것도 당연히 유니코드에서 한글을 표시 하는 표준 중 하나인건 맞구요. 그러나 맥에서만 저렇게 쓰기 때문에 다른데선 참 난감하죠.

리눅스에서도 (우분투/데비안의 경우) 기본을 유니코드(UTF-8)로 쓰는데 여기선 또 풀어쓰기 안합니다. 모아쓰기라고 할까요? 캐릭터 그자체로 표현합니다. 둘다 유니코드인데 여기선 모아 쓰고 저기선 풀어쓰고 그러다 보니 호환이 안되니 미치고 환장할지경이 되죠. 윈도우요? 내부적으로 거진 유니코드 처리 합니다. 뭐 어플따라 안하는게 많아서 한글 처리를 CP949로 하네 마네 하는거죠. 걍 멀티바이트 처리 안하고 Char로 간주해서 막 짤경우에는 CP949로 보는것 뿐이구요. 그 거아니면 멀티바이트에 넣어야죠. 저건 그냥 디폴트 인코딩을 어떻게 간주하느냐의 문제구요. 당연히 까놓고 말하자면 운영체제 보단 소프트웨어 개발자의 문제에 더 가깝습니다. 잘짜여진 멀티바이트 프로그램을 보면, 운영체제의 인코딩환경이어쨌든간에 잘돕니다. 안돌리가 있겠습니까. 윈도우도 그렇게 허술한 OS아닙니다.

이게 말입니다. 풀어쓰기 문제는 웃기게도 CJK에서는 한국만 문제가 생기는 겁니다. 원체 글자가 희한해서 말이죠. 근데 다른데서 이 문제가 안생기느냐? 것도 아니거든요. 움라우트 라던가 뭐 그런 희한한 독일어 문자나 위에 뭐 이상한거 붙는 영문자들 계열에서도 생기는 문제입니다. 뭐 거기야 그냥 그러려니 하고 넘어가는건지 아닌지 전 잘모르겠네요.

걍 리눅스랑 맥이랑 윈도우랑 한번에 같이 쓸려니까 인코딩때문에 엄청 피곤하군요.. 맥이 사실 한글을 이상하게 처리 하는게 맞습니다. 디 팩토(사실상의 표준)는 모아쓰는거 라니까요....

덕분에 꽤 많은 프로그램들이 삽질 그자체를 하고 있다는걸 생각한다면야. 대략 난감하죠.

__________________
컨설턴트에서 엔지니어로 전직중

cdream

맥의 파일 네임이 유니코드 한글 조합형 코드를 사용한는 건 잘알려진 일(문제?)입니다.

1. 조합형 코드가 분명히 유니코드 스탠다드이고
2. 파일 네임에 고어를 쓰지 말란 법도 없고 (한글 고문서 연구엔 꼭 필요한 일입니다)
3. 컴퓨터에서 조합형으로 작성되었던 아주 많은 오랜문서들과의 호환에서도 조합형이 더 유리합니다.
4. 그동안 컴퓨터에서 한글과 관련된 문제는 대부분 완성형 코드가 표준화 되다시피 하면서 생긴 문제들입니다.
5. 유니코드 완성형 영역을 사용할 때도 여전히 그전에 사용되었던 완성형 코드가 가졌던 문제들을 내포하고 있습니다.
(고어 표기시 정열 문제, 미완성 음절 표기/기록 불가능, 80년대에 사용되었던 조합형 코드나 기타 한글코드와 호환성 등)
6. 파일 네임에 조합형 코드를 사용할 때 형태적인 문제를 해결할 수 있는 기술이 이미 마련되어 있습니다.
트루타입이나 오픈타입 서체 표준 기술안에 이미 GSUB라고 조합형 코드를 완성형으로 치환하는 방안이 마련되어있습니다.
The Glyph Substitution Table
KLE: GSUB
문제는 이것이 어플리케이션이 작성하는 문서 내부의 문제이고 OS 전체에는 통용되지 않는 다는 것이지요 ^^
맥이 문제가 안생기는 건 조합형으로 글자가 작성되어도
OS가 자동으로 확장형 영역으로 글리피를 치환하기 때문입니다.

제가 보기엔 미래를 내다 보면 애플이 매우 잘 결정한 일이라고 생각합니다.
(가끔 애플의 타이포그라피 문서를 뒤지다 보면 한글에 대한 연구 문서들이 나오는데 가끔 놀라곤 합니다 ^^)

실질적인 표준이라고 잘못 된 것을 이끌고 가선 안되는 것 아닌가요 ^^

capri91

동감입니다. 한글 표기 원리에 충실한 조합형 코드를 사용하는 것이 당연함에도 불구하고, 완성형 코드가 표준이 되어 있기 때문에 많은 문제들이 발생합니다.

특히 Naver Dictionary 위젯에 한글 텍스트를 읽어주는 Text to Speech 기능을 넣으면서 많이 느꼈던 점입니다. 만약 Mac에서 조합형 유니코드를 사용하지 않았더라면 애초에 코딩할 엄두조차 내지 못했을 겁니다.

예를 들어 "한글사랑"이란 단어를 TTS가 가능한 발음 기호로 변환하려면, 완성형에서는 2단계가 필요하지만 조합형에서는 1단계만으로 충분합니다. 게다가 완성형 코드을 일일이 대조하여 자소 단위로 분리하는 과정을 생각한다면 장난이 아니죠.

1) 완성형 : "한글사랑" -> "ㅎ ㅏ ㄴ, ㄱ ㅡ ㄹ, ㅅ ㅏ, ㄹ ㅏ ㅇ" -> "h ah n, gh u l, s ah, r ah ng"
2) 조합형 : "ㅎ ㅏ ㄴ, ㄱ ㅡ ㄹ, ㅅ ㅏ, ㄹ ㅏ ㅇ" -> "h ah n, gh u l, s ah, r ah ng"

그런 점에서 애플의 조합형 유니코드는 고맙기도 하고, 한편으론 잘못된 표준 때문에 한숨이 나오기도 합니다.

PS. 지금은 아쉽게도 완성형 코드와 두벌식이 대표적인 표준이지만, 한글 표기 원리에 부합하는 조합형 코드와 세벌식이 대세가 되는 때가 빨리 오기를 바랍니다.

__________________

NeXTcube - Powered by NeXTSTEP/OPENSTEP/Mac OS X

혹시 제가 개발한 어플이 도움이 되셨다면 후원을 부탁드립니다...

• Naver Dictionary Widget
• Lotto 645 Widget
• Pedia Search Plugins for Aladdin
• Delicious Library Plugins for Aladdin
• capriPerian Patch for SAMI

ziozzang

분명 한글을 처리할때, 그것이 검색이든, 뭐 다른 어떤 방법이든, 조합형으로 한번 변환 과정이 필요하긴 합니다. 검색엔진을 만들건 뭐 형태소 분석을 하건, 위에 TTS같은 기능을 넣건, 단어를 품사별로 쪼갤때도 분명히 한번정도는 조합형으로 변환해주는것이 당연한것입니다. 그리고 이걸 모르지도 않습니다.

그렇지만 이것 자체가 쪼개져 있는 상태로 그냥 놔두기에는 소모되는 바이트가 너무 크죠. 그리고 맥외의 브라우저에서는 제대로 보이지도 않구요. (맥외에 쪼개진 이런 문자를 제대로 보여주는 메이저급 브라우저가 단한개도 있습니까? 제가 알기론 없습니다.)

저는 지금이라도 풀어쓰는 형태보다 모아쓰는 형태를 동시에라도 지원을 좀 해줬으면 하네요. 매번 자료를 올리거나 받고, 또는 유닉스에서 삽질을 해대다 보니 맥의 한글체계가 지긋지긋합니다. MacFuse에 sshfs만 써도 그렇습니다. 이걸로 쓰게되면 원격로케일에 파일들을 읽고 쓸수 있는데 보통 그런덴 모아쓰기가 표준(?)이죠. 한글을 입력해도 쪼개쓰기로는 불가능합니다. 추가 코드가 내장되어있지 않거든요...

거기다 인코딩떄문에 무언가 계속 한단계를 더 거치는 "맥만을 위한" 코드를 넣어줘야 한다는 사실이 맘에 들진 않네요. 매번 버그리포팅할때, 한글은 풀어쓰기 베이스에요 처리좀 해주세요 라고 이야기 하는것도 지긋지긋합니다. 그저, 이게 맥이라서 좋다, 또는 애플이 신경을써줬다, 조합형이 더 좋다 라는 정도로는 부족하지 않나 싶습니다. 한글로만 본다면 분명 조합형 자체는 환영할만합니다만, 한국의 표준 인코딩이 사실상 euc-kr이나 ksc5601인 완성형 베이스로 결정되어있는 마당에 (물론 유니코드로 옮겨가고 있지만) 풀어쓰기 방식 또한 표준이긴하지만 맥에 이런 풀어쓰기 코드가 계속 남아있는한 그다지 즐겁진 못할것 같습니다.

맥에선 보이긴하는데 사용이 불가능한 파일이 있다면(sshfs를 쓰면 맥에서 쓴 파일은 풀어쓰기로 원격 저장됩니다. 원격서버의 모아쓰기 한글이름은 파일이 보이긴 하나 읽거나 쓰기는 안됩니다.), 또는 유닉스에서 제대로 나오지 않는 파일이 있다면(심지어 로케일이 UTF-8임에도 불구하고) 조금 문제가 있지 않나 싶군요.

__________________
컨설턴트에서 엔지니어로 전직중

gluebyte

HFS+에서 풀어쓰기로 저장되는 건 한글뿐만 아니라 서유럽어(움라우트나 액센트)도 마찬가지인 걸로 알고 있습니다...

hopark

각자 처한 상황과 보는 관점에 따라 여러 가지 주장이 있을 수 있다고 봅니다. 하지만, 좀 극단적인 비유를 들자면, 많은 나라가 영어를 쓴다고 우리말 버리고 영어를 사용하자고 주장하는 사람들도 있습니다. 저로서는 도무지 동의할 수 없지만요.

변화하는 문명의 이기들 속에서, 우리말의 근본을 지켜나가는 것이 문명의 발전 과정에서 가장 지혜로운 선택이라고 봅니다.
새로운 기기들을 그 분야 전문가들이 우리말에 맞게 개선해 나가는 것이 옳다고 보며, 우리말을 기기들에 맞추다 보면 나중에는 가지 떼고 잎 떼고 앙상해진 몽뚱이마저 흉하니 떼자고 하게 될 날도 올 수 있다고 봅니다.

현장에서 근무하는 실무자로서 당하는 불편은 이기종 간의 통일된 체계를 마련하지 못한 우리 선배들의 잘못 때문이라 생각하며, 늦더라도 우리말의 근본을 제대로 구현하는 길로 언젠가는 바꾸어 나갈 수 있으면 좋겠습니다.

우리가 쓰는 글자는(한글은) 초성, 중성, 종성으로 모아쓰기를 하고 있으므로, 이런 조합 조형의 원리를 충실히 구현해 내는 것이 어떤 시대를 맞이하더라도 가장 간단하게 우리의 글자생활을 왜곡없이 기계화할 수 있는 길이라고 보아 왔습니다.

hopark

유니코드 규약에는 분명히 첫소리+가운뎃소리+끝소리를 낱자로 놓고 모아쓰기로 출력하게 한다는, 이른바 "첫가끝 조합" 방식이 명시되어 있는 것으로 압니다.

우리 나라 시장에서 엄청난 수익을 가져가는 마이크로소프트가 이 부분을 구현하지 않고 있기 때문에, 마이크로소프트의 운영체계에서 우리가 겪는 큰 불편 중의 하나일 뿐입니다. 즉 일부 유니코드로 된 한글 파일이름들(아이튠즈 포함)에서 초+중+종성이 풀어져 표시되는 문제가 해결되지 않고 있습니다. 잘못의 원천이 저기라는 뜻입니다.

처음에야 이 방식을 사용하는 곳이 없었으니 굳이 구현할 필요를 느끼지 못했다고 변명할 수 있지만, 몇 년이 지난 지금, 다른 회사의 운영체계에서 이미 구현하여 사용하고 있는데도 개선할 생각을 않고 있는 MS가 밉습니다. (솔직이 뭘해도 미워 보이기는 합니다만...)