한글이 자소단위로 풀어지는 현상

관련 키워드 : 한글 자소가 분리되는 문제

왜 화일 이름이 다 풀어졌지?

Mac OS X에서는 제대로 보이는 문장이 Windows기반에서 읽으면 자소단위로 풀어지는 현상을 종종 겪습니다.

 

Snow Leopard를 처음 설치하면 하단의 독(Dock) 우측에 스택이라는 기능의 폴더가 있습니다.
여기에 '도큐멘트'와 '다운로드'스택이 있는데 여기에 들어있는 PDF문서들이 바로 풀어져 있는 한글명 파일의 예입니다.
(도큐멘트.pdf, 다운로드에 관하여.pdf)
그림1. 맥에서는 잘 보이던 파일이 윈도우에서는 풀어지는 경우(Mac OS X Snow Leopard)

아래 그림은 같은 곳을 탐색기를 통해 볼 때의 모습입니다.
일부 폴더 및 파일의 자소가 끊어져서 보이는 현상이 나옵니다.

그림2. 맥에서는 잘 보이던 파일이 윈도우에서는 풀어지는 경우(Windows XP Professional SP.3)

 

 

위에서 XACTI_8GB라는 디스크(정확히는 SDHC카드를 USB 인터페이스의 리더기로 읽은)는 FAT32로 포맷되어 있습니다.

따라서 Windows를 포함하여 맥OS X, 리눅스 등 여러 운영체제에서 읽을 수 있습니다. (Microsoft에서 개발을 했으니깐 Windows는 빼는 게 당연할 수도...)

 

이유는? - NFD와 NFC

왜 글씨가 운영체제에 따라 달라보이나 파일명의 문자열 코드를 Visual Studio의 디버깅 기능에서 확인해보았습니다

위의 탐색기 그림에서 "스크린샷 "이라는 글씨가 왜 풀어져서 보이는 가를 예로 살펴보면 아래 [그림3]과 같았습니다.

 

그림3. Visual Studio에서 문자코드 확인(Mac OS X에서 만들어진 풀어진 파일이름 코드)

 

 

코드가 1109, 1173, 110F, 1173 등  유니코드에서 한글 자모(Hangul Jamo)에서 해당하는 1100-11FF에 속해 있음을 알 수 있다.

다시말하면 Mac OS X에서는 1100-11FF에 해당하는 한글자모를 AC00-D7AF 범위의 한글 음절(Hangul Syllables)로 자동으로 바꾸어 준다는 이야기이다.

(위와 같은 방식을 NFD(Normalization Form Decomposition) 방식이라고 합니다. Normalization Forms에는 크게 4가지{NFD, NFC, NFKD, NFKC}가 있습니다.)

 

참고로, 윈도우에서는 한글 자모를 1100-11FF의 영역의 코드를 사용하지 않고 3130-318F 범위의 '한글 호환 자모(Hangul Compatibility Jamo)'를 사용합니다.

그림4. 동일하게 보이는 이름이 존재가 가능하다.

위의 그림에서 동일한 이름으로 보이는 파일이 있는데 대충보았을 때는 같아 보이지만 유니코드 값이 다릅니다.
위에가 Mac OS X에서 만들어진 파일, 아래가 윈도우에서 자소로 나누어 타이핑 한 것입니다.

자세히 보면 위에는 자음의 크기가 다릅니다.

 

그림4. Visual Studio에서 문자코드 확인(Windows에서 일부러 자모를 분리해서 만든 파일이름 코드)

 

 

암튼, NFD는 문자를 해석을 할 때 NFD는 풀어서 쓰려는 방향으로 가고, NFC는 합쳐서 나타내려고 하는 형태라고 이해하시면 되겠습니다.

그림5. 본래의 글씨(Source)와 NFD와 NFC의 예

문제는 Mac OS X에서도 생성한 한글 파일이 반드시 NFD의 형태가 아니라는 것이 문제가 있습니다.

제가 사용하고 있는 Snow Leopard에서는 보통은 NFC형태의 파일 이름(묶여져 있는 이름)의 형태로 생기다가 간혹 풀어지는 경우가 생기더군요.

 

그럼 어떻게 하나? - 프로그램으로 대체~

소량의 파일일 경우에는 수작업으로 하나하나 'ㅎ ㅏㄴㄱㅡ ㄹ'을 '한글'로 바꾸는 것도 해볼 만한 일입니다.

하지만 파일의 수가 많아 질 경우에는 시간도 많이 걸리게 되고 정신 건강에 좋지 않습니다.

 

그래서 유니코드에 대해 공부도 할 겸 프로그램으로 만들었습니다. v^^;;v

비스타 부터는 NormalizeString() 라는 윈도우 API가 지원이 됩니다만, 저가 XP를 쓰는 바람에 변환용 함수를 직접 만들어야 했습니다.

(UI를 위해 WTL를, 변환 엔진을 위해 C++ STL, 파일 검색을 위해 Windows API를 이용하여 개발했습니다. 아이콘도 적당한게 없어서 손수 제작했습니다.)

 

그림6. NF간 변환ㅇ르 해주는 함수는 아쉽게도 롱혼(0x0600) 이상에서만 된다. 흑흑~;

 

다운 받기

HangulJasoFixer.exe - 무설치 단독 실행 파일입니다.

사용 방법

처음에 실행을 하면 아래와 같은 윈도우가 나타납니다.

그림7. '자소 합치기' 프로그램 최초 화면

 

 

"찾아보기" 버튼을 눌러 자소가 분리되어 있는 파일들을 검색 할 수 있습니다. (위의 UI는 [시작]메뉴의 [실행]창에서 모티브를 따왔습니다.)
경로를 알고 있다면 "열기(O):" 옆의 에디트 상자에 직접 입력할 수도 있습니다. (에디트 상자가 바뀔때마다 디렉토리가 있는지 체크하여 '확인'버튼이 비활성/활성화가 됩니다.)

경로가 지정이 되었으면 "확인"버튼을 누릅니다.

 

위에서 정해준 경로를 기준으로 파일을 검색하여 자소단위로 풀어진 파일/디렉토리 이름과 합쳐진 이름을 보여줍니다.

그림8. 검색된 화면

 

목록을 검토해서 변환을 할 파일을 체크하고 도구모음에 녹색 ▷버튼을 누르면 '기존 이름'에서 '바꿀 이름'으로 이름을 바꾸어 줍니다.

참고로 디렉토리명과 파일명 둘다 자소가 분리되어 있는 경우에는 파일명만 합쳐줍니다. 디렉토리는 제일 나중에 한꺼번에 바뀌게 됩니다.

참고로 선택을 아무것도 하지 않은채로 녹색 ▷버튼을 누르면 전체를 바꿀 것인지 물어봅니다.(전체를 바꿀 분들은 일일이 체크를 하지마시고 바로 녹색 ▷버튼을 누르시기 바랍니다.)

 

결과를 한번 보겠습니다.

그림9. 변환 전(C:\temp)

 

그림10. 변환 전(C:\temp\iTunesㅇㅔ ㅈㅏㄷㅗㅇㅇㅡㄹㅗ ㅊㅜㄱㅏ)

 

그림11. 변환 후(C:\temp)

 

그림12. 변환 후(C:\temp\iTunesㅇㅔ ㅈㅏㄷㅗㅇㅇㅡㄹㅗ ㅊㅜㄱㅏ)

 

[그림 12]에서 보면 "C:\temp\iTunes에 자동으로 추가"아래에 있던 파일 하나는 제대로 변환이 되지 않았는데요,
이 파일은 제가 윈도우에서 일부러 자소를 분리해서 입력을 했던 파일입니다.

변경전 사진을 다시 보면 같은 이름의 파일 두 개의 글씨가 약간 다름이 알 수 있습니다.

참고로 윈도우에서는 자소를 따로 나누어 입력을 하면 Hangul Jamo 코드로 들어가는 것이 아닙니다.

Hangul Compatibility Jamo로 들어가게 되어 비슷하게 보이지만 코드값이 달라집니다.

따라서 같은 이름으로 보이는 파일이 같은 디렉토리에 존재할 수 있는 것입니다.

 

 Canonical Equivalence이 적용되었다면 이름이 중복된다고 생성이 되면 안되겠지요??

위의 폴더를 Mac OS X에서 열려고 하면 아래와 같은 에러가 나타납니다.

 

퍼 날르기

KMUG: 맥에서는 잘 보이던 한글이 윈도우에서 풀려져 보이는 이유? 로 게시하였습니다.

 

관련 트랙백

맥에서 압축된 한글 파일이름이 들어간 zip, 7zip, rar 파일을 잘 풀어주는 윈도우용 7-zip 수정버전

맥오에스는 외롭습니다. - KLDP