레퍼드 타이거의 HFS+ 에서 한글 처리

lineroh · 2008-06-29, 11:11 PM

안녕하세요

레퍼드 타이거의 HFS+에서는 파일명 길이는 utf-16으로 255 캐릭터까지 가능합니다.

즉, 510 바이트까지 가능하다는 소리입니다.

그래서 영문은 255자 까지 가능하고 (255*2 = 510 바이트)

한글은 'ㄱ' 같은 단일 자음도 254자 까지 가능합니다. (254 *2 = 508 바이트)

반면 '가'같은 글자는 120자 +영문 14글자가 가능합니다. ( 120 * x + 14*2 = 508, x= 4)

그리고 '각'같은 글자는 80자 +영문 14글자 까지 가능합니다. ( 80 * y + 14*2 = 508, y=6)

이런것을 볼때 레퍼드에서는 한글을 초중성 단위로 잘라서 저장을 하고 (이것은 예전부터 방식)
각각의 캐릭터는 utf-16으로 저장하고 있는 것을 알수 있습니다.

질문.

utf-16 캐릭터 그대로 쓰지 않고 왜 초중성으로 나눠서 저장을 하나요?

(Max OS 9 과의 호환성을 위해선가요?)

(타이거도 약간만 다르고 거의 똑같습니다.)

skonmeme · 2008-06-29, 11:53 PM

제가 잘못 알고 있는 건가요?.. Mac에서의 Unicode 구현은 UTF-8로 되어 있는 것으로 알고 있습니다.

Mac에서는 Unicode 코드조합 방식으로 NFD라는 방식을 사용합니다. 이점은 정렬이 용이하다는 것이고, 단점은 쓸데없이 저장공간을 낭비하는 것입니다. Linux, Windows 등에서 많이 쓰이는 NFC 방식은 가급적 적은 코드를 사용하여 문자를 조합하여 공간 낭비를 줄이는 되신 코드상의 정렬 순서가 언어별로 일관되지 않아 정렬이 어려운 경우가 있습니다. 한글의 경우 11172자가 순서대로 코드되어 정렬에 큰 문제는 없지만, 액센트등이 붙는 문자를 가지고 있는 유럽 문자나 일본 문자들에 대해서는 정렬이 까다로운게 사실입니다.
UTF-8 - Wikipedia, the free encyclopedia

NFC와 NFD간에 원래는 상호 호환성을 보장해야함에도 지원을 제대로 안해서 맥에서 만든 한글이 Windows 등에서 볼 때, 초중종성이 분리되어 보이는 현상을 보여주고 있습니다.

skonmeme · 2008-06-30, 12:51 AM

찾아보니

struct HFSUniStr255 {
UInt16 length;
UniChar unicode[255];
};

UniChar is a UInt16 that represents a character as defined in the Unicode character set defined by The Unicode Standard, Version 2.0 [Unicode, Inc. ISBN 0-201-48345-9]
라고 되어있네요.. 한 코드당 16bit를 쓰고 있는게 맞습니다. 다만 UTF-16을 쓰는지는 잘 모르겠네요..

lineroh · 2008-06-30, 01:23 AM

HFS Plus permits filenames up to 255 UTF-16 characters in length

HFS Plus - Wikipedia, the free encyclopedia

위키에는 위와 같이 나와있습니다.

utf-8을 쓴다는 소리를 어딘가에서 들은적은 있는데 ,
그렇다면 영문은 1바이트를 차지해야하고,
한글은 3바이트를 차지해야됩니다.

그런데 "ㄱ"은 2바이트 "가"는 4바이트 "각"은 6바이트를 차지하는 걸로 나왔으니,

utf-8이 아니라는 것을 저도 오늘 알았습니다.
그래서 혹시나 다른 분들은 어떻게 알고 계신가 궁금해서 적었습니다.

trip2me · 2008-06-30, 01:27 AM

Internationalization Programming Topics: File Encodings and Fonts

이런 글이 적혀 있네요. UTF-16을 파일 시스템에서 사용하고 있군요.

인용:

File Systems and Unicode Support

Different file systems in Mac OS X have different levels of Unicode support:

Mac OS Extended (HFS+) uses canonically decomposed Unicode 3.2 in UTF-16 format, which consists of a sequence of 16-bit codes. (Characters in the ranges U2000-U2FFF, UF900-UFA6A, and U2F800-U2FA1D are not decomposed.)
The UFS file system allows any character from Unicode 2.1 or later, but uses the UTF-8 format, which consists mostly of 8-bit ASCII codes but which may also include multibyte codes. (Characters in the ranges U2000-U2FFF, UF900-UFA6A, and U2F800-U2FA1D are not decomposed.)
Mac OS Standard (HFS) does not support Unicode and instead uses legacy Mac encodings, such as MacRoman.
Locking the canonical decomposition to a particular version of Unicode does not exclude usage of characters defined in a newer version of Unicode. Because the Unicode consortium has guaranteed not to add any more precomposed characters, applications can expect to store characters defined in future versions of Unicode without compatibility issues.

Note: Because of implementation differences, erroneous Unicode in filenames on HFS+ volumes may display correctly when entered on Mac OS 9 but appear garbled on Mac OS X. Similarly, erroneous Unicode entered on Mac OS X may appear garbled in Mac OS 9.
All BSD system functions expect their string parameters to be in UTF-8 encoding and nothing else. Code that calls BSD system routines should ensure that the contents of all const *char parameters are in canonical UTF-8 encoding. In a canonical UTF-8 string, all decomposable characters are decomposed; for example, é (0x00E9) is represented as e (0x0065) + ´ (0x0301). To put things into a canonical UTF-8 encoding, use the “file-system representation” interfaces defined in Cocoa and Carbon (including Core Foundation).

nearfri · 2008-06-30, 10:17 AM

skonmeme님이 말씀하신대로 Decomposed 방식은 공간을 많이 차지하지만 정렬이 용이하다는 장점이 있습니다.
그리고 또 하나, 한글에서 명사 뒤에 '은/는/이/가' 등을 붙이려면 마지막 음절의 종성 유무를 알아야 합니다.
여기에 유용하게 사용할 수 있지 않을까요?
정확히 어떤 식으로 인코딩하는지 보질 않아서 모르겠네요. 혹시 아시는 분 있다면 답글 달아주셨으면 합니다.

신입사원 때 과제로 BSD 웹서버 만들었었는데 시험삼아 맥에서 서버 띄우고 윈도우즈에서 접속하니
초중성 다 분리돼서 난감했던 기억이 나네요.
그땐 시간도 없고 과제 범위도 벗어나는 일이라 그냥 놔두기로 했었죠.

jeongyun · 2008-06-30, 11:20 AM

유니코드에 한글 인코딩이 두가지가 들어있습니다. 하나는 완성형(이지만 사실상 조합형이나 다를바 없는) 영역이 있고 조합형 영역이 있습니다.
이 조합형 부분은 첫가끝 코드라고도 하는데, 고어 및 완성형에서 허용하지 않는 자모의 조합도 쓸 수 있습니다.
문제는 이 첫가끝 코드 영역을 쓰거나 지원하는 사례가 드물다는 거죠.

2008-06-29, 11:11 PM	#1
lineroh Senior Member Registered: May 2007 My Mac: 맥북 Posts: 153 오프라인	레퍼드 타이거의 HFS+ 에서 한글 처리 안녕하세요 레퍼드 타이거의 HFS+에서는 파일명 길이는 utf-16으로 255 캐릭터까지 가능합니다. 즉, 510 바이트까지 가능하다는 소리입니다. 그래서 영문은 255자 까지 가능하고 (2552 = 510 바이트) 한글은 'ㄱ' 같은 단일 자음도 254자 까지 가능합니다. (254 2 = 508 바이트) 반면 '가'같은 글자는 120자 +영문 14글자가 가능합니다. ( 120 * x + 142 = 508, x= 4) 그리고 '각'같은 글자는 80자 +영문 14글자 까지 가능합니다. ( 80 y + 142 = 508, y=6) 이런것을 볼때 레퍼드에서는 한글을 초중성 단위로 잘라서 저장을 하고 (이것은 예전부터 방식) 각각의 캐릭터는 utf-16으로 저장하고 있는 것을 알수 있습니다. 질문. utf-16 캐릭터 그대로 쓰지 않고 왜 초중성으로 나눠서 저장을 하나요? (Max OS 9 과의 호환성을 위해선가요?) (타이거도 약간만 다르고 거의 똑같습니다.) __________________ iPod touch 호모 파베르에게 이제야 쓸만한 도구가 쥐어졌어요. lineroh 님께서 2008-06-29 11:27 PM 에 수정하셨습니다.. 이유: (숫자 계산에 오류가 있었습니다. )*

2008-06-29, 11:53 PM	#2
skonmeme Senior Member Registered: Dec 2005 My Mac: Macbook Posts: 149 오프라인	제가 잘못 알고 있는 건가요?.. Mac에서의 Unicode 구현은 UTF-8로 되어 있는 것으로 알고 있습니다. Mac에서는 Unicode 코드조합 방식으로 NFD라는 방식을 사용합니다. 이점은 정렬이 용이하다는 것이고, 단점은 쓸데없이 저장공간을 낭비하는 것입니다. Linux, Windows 등에서 많이 쓰이는 NFC 방식은 가급적 적은 코드를 사용하여 문자를 조합하여 공간 낭비를 줄이는 되신 코드상의 정렬 순서가 언어별로 일관되지 않아 정렬이 어려운 경우가 있습니다. 한글의 경우 11172자가 순서대로 코드되어 정렬에 큰 문제는 없지만, 액센트등이 붙는 문자를 가지고 있는 유럽 문자나 일본 문자들에 대해서는 정렬이 까다로운게 사실입니다. UTF-8 - Wikipedia, the free encyclopedia NFC와 NFD간에 원래는 상호 호환성을 보장해야함에도 지원을 제대로 안해서 맥에서 만든 한글이 Windows 등에서 볼 때, 초중종성이 분리되어 보이는 현상을 보여주고 있습니다. __________________ 멍멍 :P skonmeme 님께서 2008-06-29 11:56 PM 에 수정하셨습니다..

2008-06-30, 12:51 AM	#3
skonmeme Senior Member Registered: Dec 2005 My Mac: Macbook Posts: 149 오프라인	찾아보니 struct HFSUniStr255 { UInt16 length; UniChar unicode[255]; }; UniChar is a UInt16 that represents a character as defined in the Unicode character set defined by The Unicode Standard, Version 2.0 [Unicode, Inc. ISBN 0-201-48345-9] 라고 되어있네요.. 한 코드당 16bit를 쓰고 있는게 맞습니다. 다만 UTF-16을 쓰는지는 잘 모르겠네요.. __________________ 멍멍 :P

2008-06-30, 01:23 AM	#4
lineroh Senior Member Registered: May 2007 My Mac: 맥북 Posts: 153 오프라인	HFS Plus permits filenames up to 255 UTF-16 characters in length HFS Plus - Wikipedia, the free encyclopedia 위키에는 위와 같이 나와있습니다. utf-8을 쓴다는 소리를 어딘가에서 들은적은 있는데 , 그렇다면 영문은 1바이트를 차지해야하고, 한글은 3바이트를 차지해야됩니다. 그런데 "ㄱ"은 2바이트 "가"는 4바이트 "각"은 6바이트를 차지하는 걸로 나왔으니, utf-8이 아니라는 것을 저도 오늘 알았습니다. 그래서 혹시나 다른 분들은 어떻게 알고 계신가 궁금해서 적었습니다. __________________ iPod touch 호모 파베르에게 이제야 쓸만한 도구가 쥐어졌어요.

2008-06-30, 11:20 AM	#7
jeongyun Veteran Member Registered: Feb 2002 My Mac: iMac G5 1.6GHz Posts: 828 오프라인	유니코드에 한글 인코딩이 두가지가 들어있습니다. 하나는 완성형(이지만 사실상 조합형이나 다를바 없는) 영역이 있고 조합형 영역이 있습니다. 이 조합형 부분은 첫가끝 코드라고도 하는데, 고어 및 완성형에서 허용하지 않는 자모의 조합도 쓸 수 있습니다. 문제는 이 첫가끝 코드 영역을 쓰거나 지원하는 사례가 드물다는 거죠. __________________ Programmer since 1986 / Mac User since 1996 2.5RS (블로그)

2008-06-30, 10:17 AM	#6
nearfri Member Registered: Jun 2006 My Mac: macbook Posts: 29 오프라인	skonmeme님이 말씀하신대로 Decomposed 방식은 공간을 많이 차지하지만 정렬이 용이하다는 장점이 있습니다. 그리고 또 하나, 한글에서 명사 뒤에 '은/는/이/가' 등을 붙이려면 마지막 음절의 종성 유무를 알아야 합니다. 여기에 유용하게 사용할 수 있지 않을까요? 정확히 어떤 식으로 인코딩하는지 보질 않아서 모르겠네요. 혹시 아시는 분 있다면 답글 달아주셨으면 합니다. 신입사원 때 과제로 BSD 웹서버 만들었었는데 시험삼아 맥에서 서버 띄우고 윈도우즈에서 접속하니 초중성 다 분리돼서 난감했던 기억이 나네요. 그땐 시간도 없고 과제 범위도 벗어나는 일이라 그냥 놔두기로 했었죠.

글타래 옵션
프린트 메일