윈도가 NFC만 지원 가능하고,
맥이 NFC, NFD를 모두 지원한다는
윈도에서는 NFC 한글 파일명만
제대로 보이고,
맥에서는 NFC, NFD 한글 파일명
모두가 보인다는
이유만으로 윈도가 문제라는 인식을
하시는 분들이 많네요.
OS의 지원 범위와는 별개로,
한국어에서는 NFC가 표준입니다.
한글 파일명의 처리 시에는
NFC가 표준입니다.
즉, 윈도가 표준을 준수하는 겁니다.
관련하여 참고할 글을 남깁니다.
https://devblogs.microsoft.com/oldnewthing/20201009-00/?p=104351&WT.mc_id=DT-MVP-4038148
(수정 2022-10-01 02:07)
일부 모호한 표현들과
잘못 전달될 수 있는 내용을
수정하였습니다.
(추가 2022-10-01 05:11)
그냥 가볍게 적은 글인데 댓글들이 많이 길어져서 놀랐네요. (이럴 줄 알았으면 더 명확하게 쓸 걸 ㅠ) 윈도에 대해 은연 중에 퍼져있는 부정적인 인식으로 인해, 한글 파일명 처리에 대해서 "윈도가 표준을 지키지 않는다."라는 잘못된 정보가 퍼지는 것 같아, 위의 원문을 작성했었습니다.
파일이 특정 로컬 시스템에서 처리될 때, 사용자 인지 영역(UI)과 시스템 내부 처리 영역별 정규화 방식이 완벽하게 나눠지는 게 좋겠죠. 화면 표시부터 정렬, 탐색까지 모두 불편함이 없게 처리되는 것이 최선일 것입니다.
하지만 '파일'은 최초 생성한 사람의 로컬 시스템에서만 존재하는 것이 아닙니다. 생성된 파일은 네트워크를 통해 다른 시스템으로 퍼져 나갑니다. 업로드 되는 서버에 물리적으로 존재하고요, 이러한 파일 정보를 관리하는 DB에도 파일명 정보가 존재하죠.
이처럼 물처럼 흘러가며 다양한 환경에서의 파일 사용 시 혼란을 줄이기 위한 가이드, 그게 '표준'이 아닐까요? 파일명 처리 방식에 대해서 OS 마다 철학이 다를 수는 있습니다. 하지만 개별 OS의 파일 처리 방식을 다른 이들에게 강요(?)하면 모두가 힘들어 집니다.
--------------------
현재의 유니코드 체계 하에서, 그리고 대표적인 OS들의 파일 처리 방식에서는, 파일만으로 "이 파일의 파일명은 NFD를 기준으로 생성했으므로, 파일명 표시 시 NFC처럼 보이게 해야 한다."라고 구분/처리할 수 있는 방법이 없는 걸로 알고 있습니다. (물론 파일명 글자의 유니코드상 위치를 통해서 OS가 암묵적 추측을 할 수는 있겠죠.)
[ 원문 : "안녕" ]
- NFC : c548 b155
- NFD : 110b 1161 11ab 1102 1167 11bc (ᄋ ᅡ ᆫ ᄂ ᅧ ᆼ)
파일명 자체가 NFC로 되어 있다면, NFC 든 NFD 든 상관없이 어느 시스템에서나 "안녕"이라고 표시가 됩니다. 하지만 파일명 자체를 NFD로 할 경우, 각 시스템에서 파일명을 표시 방식에 따라 표기가 다르게 됩니다.
--------------------
다시 한번 정리하자면...
- NFC 적용 파일명 : 유니코드 체계의 모든 OS 에서 동일하게 파일명 표시
- NFD 적용 파일명 : NFD 파일명을 '모아서 보여주기' 처리하는 OS에서만 제대로 표시
- 윈도 : (탐색기 기준)파일 생성/파일명 수정 시 파일명은 NFC 적용, 파일 정보 표시 시 유니코드 문자열 그대로 보여줌
- 맥 : (Finder 기준)파일명 수정 시 파일명은 NFD 적용, 파일 정보 표시 시 NFD 파일명을 모아서 보여줌
결론
- NFC가 표준인 상태에서는, NFC로 파일을 생성하는 윈도가 제대로 하는 겁니다.
- 한글 파일명의 표준을 해치는 건 Mac입니다.
- 파일의 이름에 한해서는, 다양한 OS에서 동일하게 처리될 수 있도록 Mac OS에도 NFC가 기본 적용되길 바랍니다.
한글 표현에 있어서 Windows가 처리하는 방식이 사실상의 표준에서 공식적인 표준으로 이어져 왔습니다.
그러나 컴퓨팅이 단독 PC에서 Stand-Alone으로 활용되는 방식에서 여러 이기종간 서로 연결되고, 인터넷 서비스를 통해 전송되고, DB와 웹서버를 통해 통해 처리되는 방식에는 많은 문제가 발생합니다. Windows도 이런 점을 고려해서 많이 보완해왔지만 Windows의 가장 큰 짐인 하위호환성에 발목이 잡혀서 째빠르게 움직이지는 못하는 것 같습니다.
Windows를 개발한 MS 단일 회사의 정책과 기술에 종속되기 보다는 더 넓고 광범위하게 활용되는 실질적 표준에 맞춰가는게 더 효과적이지 않을까 생각합니다.
레이먼드 첸의 윈도우 한글 구현에 대한 글에서 일부를 인용합니다.
문제는, ICU(Internationl Components for Unicode)도, iOS도, Android도 모두 U+1100, U+1161, U+11A8을 하나의 글자로 합쳐서 보여주는데, 왜 윈도우만 그것을 곧이곧대로 'ㄱㅏᆨ'으로 보여주냐는 것입니다. Raymond Chend은 이에 대해 '가장 먼저 표준을 도입하는 선발 주자로써 겪게 되는 아픔'의 한 사례라고 합니다. 실제로, 윈도우는 당시 한국의 산업 표준인 "KS X 1026"에 따라 NFC 방식을 따르게 되었다고 합니다.
표준은 국제표준. 국가별 표준. 산업별 표준…들이 있고 개정시기나 수요, 적용범위 등에 따라 서로 정합성이 맞지않을 수 있습니다.
이런걸 맞춰가는 과정이 표준화라고 할 수 있고 완성된 표준은 없습니다.
맥과 같은 BSD 계열 운영체제(Unix, Linux, Android, ios 등)들이 구현한 방식이 표준이 아니라고 하는데 사실 유니코드 표준에 NFD 방식의 구현이 "UAX #29" 문서로 명확하게 나와 있습니다.
KS X 1026-1이 2007년 제정되었고 최근 개정은 2017년입니다.
한글 데이터화와 데이터 행정을 위한 개정이 예정되어 있습니다.
의견을 얘기하는데 왜 따지듯이 그러시나요.
그럼 앞으로도 계속 NFC 표준에 맞게 사세요.
표준이 정립된 것에 대해서는 공식적인 표준이 표준인겁니다. 말장난은 그만하세요
사실관계를 말하는데 니말은 틀렸고 내말이 맞아 라고 하는건 현대 사회에서는 의견을 예기한다고 하지 않고 보통 우긴다고 합니다 선생님.
공식적 표준은 실질적 표준을 항상 참고하면서 확장되고 개정됩니다.
왜 이런 논의에 화를 내시는지는 모르겠네요.
~ 말장난은 그만하세요
~ 보통 우긴다고 합니다 선생님.
이런 무례한 댓글은 처음이라 당황스러워서 발끈했습니다.
더이상 얘기하지 맙시다.
유니코드 표준은 유니코드란 하나의 문자 전산 처리 방식에 대한 표준으로, 하나의 코드로 모든 문자를 다 표현하고자 하는 유니코드 에서는 각 문자는 몰론 문자의 특성별로 효율적으로 전산 처리가 가능하도록 처리 방법에 대한 표준도 정의되어 있습니다. 그게 NFC/NFD 등등이죠.
그러나 이게 해당 언어의 문자를 전신 처리할 때 표준이라는 것은 아닙니다. 유니코드에서는 말 그대로 모든 문자를 다 처리할 수 있도록 여러가지 방법을 제공하는 것이고, 실제로 한국어와 한글을 유니코드를 통해 표현 및 처리할 때는 이 방법을 사용한다고 정의한 것이 국가 표준 KS X 1026-1입니다.
선생님께서 한글도 NFC 이외의 다른 방법으로도 처리해야고 생각하신다면, 당시 유니코드에 한글을 넣기 위해 표준 작업에 노력하신 분들에게 새로이 표준을 정립해야 한다고 하시는 것이 가장 빠른 길이라고 생각됩니다.
댓글에서 언급한 대로, 표준이 영역별(국제, 국가...)로 다를 수가 있죠. 근데 한글의 정규화는 이미 국제 표준 = 국가 표준이였다는 겁니다.
파일명에 NFD를 적용한 Mac OS가 오히려 표준을 지키지 않는 것이고, 이로 인해 OS간 파일 전송에 대한 사용자 불편을 야기하는 거죠.
저는 NFD 지원하지 않는 윈도를 두둔하려는 게 아닙니다.
<< 수정 : 지원하지 않는 게 아니라 별도의 처리를 하지 않는 것입니다. NFD 기준의 파일에 대한 별도의 처리를 하지 않으므로 당연히 풀어져서 보일 수밖에 없습니다. 윈도가 NFD 지원을 안 한다기 보다는, NFD에 대한 별도의 처리를 하지 않는다는 표현이 정확합니다. API 상에 당연히 NFD 처리가 가능하도록 구현되어 있습니다.>>
표준인 NFC가 아닌 NFD를 선택한 Mac이 잘못된 선택을 했다는 걸 말하려는 겁니다.
전세계가 사용하는 Unicode의 한정된 자원을 활용해야 하는 상황에서는, 표준을 따라가는 것이 맞지 않을까요?
한글 처리에 대해서는 "공공 정보시스템 한글 처리 가이드라인" 문서를 보시면, 한글에 대한 처리를 위해 IT 시스템 관점에서 얼마나 고민할 거리가 많은지 확인하실 수 있습니다.
https://m.korea.kr/expertWeb/resources/files/data/document_file/2010/%ea%b3%b5%ea%b3%b5%20%ec%a0%95%eb%b3%b4%ec%8b%9c%ec%8a%a4%ed%85%9c%20%ed%95%9c%ea%b8%80%20%ec%b2%98%eb%a6%ac%20%ea%b0%80%ec%9d%b4%eb%93%9c%eb%9d%bc%ec%9d%b8.pdf
윈도가 파일명 등록 시 NFD를 적용했다면 오히려 그로 인해 데이터 처리에 더 많은 혼란이 가중되는 상황도 발생할 수 있을 것입니다.
- Mac이 NFC를 채택해야 한다 (O)
- Mac의 NFD 채택이 옳다 (X)
- 윈도도 NFD를 채택해야 한다 (X)
------------------------
(수정 : 2022-10-01 01:49)
기존 글에서 <윈도가 "NFD 지원을 하지 않는다">와 연관된 항목들은 삭제/수정합니다. 윈도도 (당연히) NFD 처리 가능합니다.)
NFD 방식이 추가된 건, 고어 때문도 있습니다.
현재는 사용되지 않는 고어들도 유니코드로 다 관리할 수 있게 하려면 NFD 방식이 유리하기 때문이지요.
그리고 한글 창제 원리에도 NFD가 더 맞는 것도 사실이구요.
하지만, 현대한글만 사용하는데에는 NFC가 압도적으로 유리합니다. 그래서 무리해가며 현대한글 모든 조합을 유니코드에 넣은 것이지요. (해당 한글 들어간 시점 기준으론 유니코드 내에 가장 많은 공간을 사용하는게 한글일 정도였습니다.)
그리고 KS X 표준에서 정의하는 내부 시스템은 프로그램 내에서 처리할 때를 이야기합니다. 저장하거나 이동할 때에는 반드시 NFC를 이용하라고 명시되어 있습니다. 파일시스템이 내부시스템이 되려면... 상당한 억지를 부려야만 할 듯 하네요.
어… 선생님께서는 왜 정보교환 표준이 정립되었는지 먼저 알아보시는 것이 좋을것 같습니다
요
애플이 NFD를 파일시스템에 쓴것은 그들의 아주 이른 선택이었고, Mark Davis 덕분에 한글이 굳이 NFD에서 자모 분해가 되는것은 한글처리에 대한 비극이었던 것입니다. 이제와서 애플이 다시 번복하지는 않을것이라고 생각합니다. 다만 KS X 1026이 여러가지 이유로 한글 자모의 현대어 글자로의 표현을 막은것은 탁월한 선택이었다고 아직도 믿습니다.
이상 Unicode와 ISO 10646, KS X 1001, KS X1026의 저자이자 해당 코드들을 만들어온 사람의 생각을 전해드립니다.
데이터베이스 필드 크기 정의를 예로 들 수 있는데요. 문자열 저장 공간의 필드 크기를 물리적으로 바이트 단위로 할 수 있는 경우가 있고, 아니면 코드포인트 단위로 할 수 있는 경우가 있고(이쪽이 일반적) 있을 지 모르겠지만 실제 최종 출력에 필요한 문자단위로 할 수 있는 경우가 있을겁니다.
만약 NFD 형식을 기본 데이터베이스 저장 단위로 삼는다면, 특정 크기 내에서 저장가능한 한글의 갯수가 크게 줄어들게 되며, 글자 단위로 보존한다 한들 DBMS 입장에서 사전에 할당해야하는 공간의 범위가 너무 넓어져 비효율을 부르게 됩니다.
어차피 데이터베이스에서 정렬은 NFC든 NFD든 간에 별도 처리가 필요한만큼 컴팩트한 형태를 취하는 NFC가 맞다고 생각합니다.
Rust 같은 언어에 UTF-8로 저장되는 String을 보시면 왜 가변문자가 불편한지 아시게 됩니다.
그리고 영문윈도우와 한글윈도우간의 처리 방식은 동일합니다. 오해 없으시길 바랍니다.
Windows도 NFC, NFKC , NFD, NFKD 4가지 방식 모두 지원합니다. 단지 한글 표시에는 한국 표준에 맞춰 NFC만을 사용할 뿐입니다.
EU에서 별 이야기가 없다는 것은 결국 Apple 과 MS 모두 정상적으로 처리하고 있다는 것이죠.
NFC, NFD 모두 표준이라는 말씀을 드리고 싶었습니다.
https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6AATIntro.html
Ligatures and Contextual Forms 부분입니다.