유니코드 1.0 엔 KS C 5601 기반 완성형 코드 2,350자가 순서대로 들어가 있고, 유니코드 1.1엔 여기에 아무도 모를 KS X 1002 및 중국 요청 추가자를 포함한 4,306자가 더해져서 총 6,656자가 들어있었다고 합니다.
이미 유니코드 1.1 부터 MS의 통합형(=확장 완성형, CP949, 윈95부터 도입됨) 한글보다 더 개판인 상태였죠. (통합형은 그나마 현대한글 11,172자를 다 넣은 상태임.)
이에 한국대표는 유니코드 2.0 제정시 완성형 현대한글 11,172자를 가나다순으로 새 영역에 배당할 것을 요청했습니다.
여기에 대해 갑론을박이 많았으나 결국 기존 평면(U+3400~U+4DFF)에 배당한 한글 6,656자를 없애고 새 평면(U+AC00~U+D7A3)에 현대한글 11,172자를 가나다 순으로 배당하는 것으로 결정했으며, 여기에 덧붙여 유니코드 2.0부터는 한 번 배당한 문자는 절대 옮기거나 없애지 않는다는 정책을 세웠죠.
즉, 유니코드 1.0~1.1과 2.0 이후는 완성형 한글 입장에서는 전혀 호환되지 않는 딴 코드가 되어버렸습니다.
(그리고 제가 2000년도 중반 유니코드 1.1 기반의 오라클 DB에서 매운맛을 톡톡히 보았... orz 이것땜에 이걸 기억하고 있습죠.)
덧. 첫가끝 기반 조합형 코드의 경우 유니코드 1.1부터 U+1100~U+11FF에 할당되어 있으며, 이 영역을 계속 유지하고 있습니다. 애플이 한글 파일명에 대해 이 조합형 영역을 지금까지도 사용하고 있는데, 이는 유니코드 호환을 위한 정책으로 보입니다. 반대로 MS는 제 경험상 XP까지 첫가끝을 제대로 지원 안했죠. 종종 윈7에서도 mac에서 저장한 한글 파일명이 풀려나오는걸 본 기억도 있고요.
mac도 nfc nfd 모두 잘 보여주는건 좋은데 nfd 잘 보여주는건 선택이지만 외부로 보낼 때는 nfc 변환해서 보내야죠.
ms 덕에 완성형의 코드들이 누더기가 되어 난리도 아니었는데...
적어도 한글 문제에 있어서 마이크로소프트는 절대 좋은 소리 들을 수 없습니다..
영상으로 한 번 보시는 것도 좋습니다..
하지만 정작 macOS를 메인으로 쓰는 제 입장에서, 몇몇 프로그램에서 긴 한글명으로 저장시 디렉토리 패스+파일명 길이 초과로 저장이 튕기는걸 생각하면... NFC가 이득이 크긴 해요. ㅎㅎㅎㅎㅎ
오죽하면 구식 Win32 API에서 강제하는 255bytes 상에서의 한글명보다 macOS의 한글명이 체감상 훨씬 짧게 느껴지거든요.
https://www.newshankuk.com/news/content.asp?news_idx=2010102511064747409
아래 KSx1026-1 문서 5.2 절 참고 부탁 드립니다.
https://e-ks.kr/streamdocs/view/sd;streamdocsId=72059251690133256
응용 프로그램의 외부와 자료를 보내고 받을 때는 반드시 완성형 한글 글자마디로 처리해야 한다.
시간이 너무 늦어서 더 이상 의견 교환은 어려운 점 양해 부탁 드립니다.
분명 완성형 코드에는 "쓩"이 있지만, 정작 "쓔"가 없어서 쓩을 일반적인 방법으로는 입력할 수 없었다는 것이...
MS가 유니코드는 무시하고 완성-통합형 한글만 지원하던 윈2000 까진 사실 NFC를 지키려고 지킨게 아니었던 걸로 보입니다.
어차피 MS든 애플이든 둘 다 외국회사라 KS X 1026 를 안지켜도 큰 문제가 없긴 하지만요. (이 두 회사에겐 유니코드를 지키는게 더 큰 과제.)
통합형 논쟁 이후 정말로 오랜만에 이런 이야기를 다 해보게 되니 뭔가 새로운 기분이네요. ㅎㅎㅎ
애시당초 한글 자체를 쓸 수 없거나, 도깨비 카드 같은 한글 하드웨어 카드를 설치해야만 한글을 사용할 수 있던 1980년대 시절에 KS 표준을 지켜서 추가비용없이 한글을 사용할 수 있는 환경을 만들었던 건 칭찬 들을만 했다고 생각하는데요. 뭐, 첫 단추가 저렇다보니 이후에는 엉망이 되긴 했죠.
MS에 대해 전반적으론 좋은 이야기 해줄 수 어렵다는 점에는 동의합니다.
마소쪽 사람이니 그닥 신뢰하실것 같진 않지만 어쨋든 여기 내용 상에는 한글을 NFD로 표현하는건
유니코드와 한국의 권장사항을 무시하는 행위라고 이야기 하고 있습니다
아마 NFD가 또하나의 표준이기도 하고 NFC를 쓸지, NFD를 쓸지는 권장사항이지 강제는 아니기 때문에 저렇게 돌려서 이야기 하는것 같네요
그외에도 iOS에서는 아래 문서의 일부가 깨져서 나옵니다 (제 아이폰은 iOS 16입니다)
깨지는 부분은 한글기준으로 내용 부분, 영문 기준으로는 Implications of the Songs 부분이며
애플이 유니코드를 제대로 준수했다면 그런일은 없어야겠죠?
https://ko.wikipedia.org/wiki/%EC%9A%A9%EB%B9%84%EC%96%B4%EC%B2%9C%EA%B0%80
앞서 언급되었지만, 조합형은 물론이고 모든 완성형까지 다 들어가 있고 한글 고어도 있죠. 게다가 한자도 다 들어 있습니다.
한국 사람들이 대략 유니코드 1/3을 다 쓴다는 이야기죠.. 유니코드는 한국어 사용자를 위해 만들어졌다고 해도 과언은 아닌 것 같습니다..
게다가 중국 한자는 번체, 간체 2세트에다가 온갖 고문자가 있어서 갯수가 워낙 넘사벽이라...
https://preview.redd.it/6ng5o74p7d841.png?auto=webp&s=34674c7a482c4f879f640a34e86db322f5dd6d83
최신 버전의 유니코드에서 한자와 한글에 배정된 개수는 대략 다음과 같습니다.
- 한자 (CJK; China, Japan, Korea에서 사용하는 한자) : 약 97,000자
- 한글 : 약 11,000자
참고 1. 일본어는 히라가나와 가타카나를 모두 합쳐 200개가 안 됩니다.
참고 2. 현재 유니코드에 배정된 언어는 150개 정도이고, 배정된 총 개수는 약 149,000개 정도입니다.
참고 3. 예~전에는 CJKV(CJK + 베트남에서 사용하는 한자를 포함) 버전도 있었으나, 지금은 거의 안 씁니다.
결론 : 유니코드 전체 개수의 65% 정도는 한자. 반면 한글은 7% 정도.
http://kristalinfo.dynu.net/K-Lab/unicode/Unicode_intro-kr.html