추가) 프로젝트명을 바꾸셨네요 : )
위 코드를 적절히 wchar_t 의 정규화 변환에 사용하면 libiconv 사용을 하지 않아도 되고
문제의 BMP를 벗어나는 문자의 정규화 에러를 막을 수 있습니다.
먼저 술집 2소식에 감사드립니다.
이번이 릴리즈 하신 버전을 보니 libiconv를 사용하신거라고 추측이 되지만,
맥에서 zip 파일을 압축해서 술집2로 열어보니 열리네요. 감사합니다.
하나의 문제는 언급했던 libiconv에 관련된 것인데요,
UTF-8-MAC -> ? 을 하는 경우에 libiconv의 UTF-8-MAC 구현상의 문제로 인해(UCS-2를 중간변환에 사용함)
U+10000 이상의 유니코드 문자열을 제대로 변환하지 못하고 에러를 냅니다.
그런 이유로 제가 첨부한 파일을 열어보시면 술집 2에서 인코딩을 UTF-8-MAC으로
고르면 프로그램이 비정상 종료되는 모습을 볼 수 있으실껍니다.
추가로 7zip과 rar가 유니코드를 사용하기는 하지만, 맥에서 압축을 하면 애플에서 HFS+ 에
저장된 NFD 정규화 파일이름을 그대로 압축파일에 가지고 있기 때문에, 그대로 윈도우에서
압축을 풀어주면 Windows XP에서는 합쳐진 모습을 제대로 보여주지 못할 뿐만 아니라,
비스타 이상이라면 사용자가 같은 이름을 가지는 파일을 하나의 폴더에 만들수 있고, 자신이
덮어 썼다고 생각했는데 그렇게 되지 않는 경우가 생길 수 있습니다.
그래서 가급적 리눅스나 윈도우에서 주로 사용하는 NFC형태의 유니코드 정규화를 해 주는게 좀 더
나아보입니다. NFD와 NFC 정규형은 서로 1:1 변환이 되는 것이라서 파일명이 망가지는 걱정은
하시지 않으셔도 될듯 합니다. (단 애플은 BMP의 특정 글자들을 NFD형식으로 정규화해서 BMP를
벗어나는 글자의 정규화 변환은 나중에 영향을 줄 수 있으나 BMP를 벗어나는 글자의 풀어쓰기 영역을
사용하는 문자셋이 그리 많지 않고 사용빈도가 적어서 영향이 없다고 생각하면 됩니다.)
항상 적용하는게 압축 해제 속도에 조금이나마 영향을 준다고 생각이 드시면 옵션에 지정할 수 있게
해 놓는 것도 좋을 듯 합니다.
그래서 위의 2가지 정규화와 관련된 문제를 해결하기 위해서 libiconv 대신
귀찮으시더라도 Microsoft Internationalized Domain Names (IDN) Mitigation APIs
ttp://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=ad6158d7-ddba-416a-9109-07607425a815
를 사용해 zip, rar, 7zip에서 Apple의 변형된 UTF-8 NFD -> 유니코드 표준 NFC 정규화 변경을
해 주셨으면 좋겠습니다. 위 링크의 normaliz.dll은 비스타 이상에서는 기본으로 들어있고
나머지는 위 링크를 설치하면 나오는 재배포 패키지를 설치해야 합니다.
그리고 마지막으로 구현에 참고가 될까 싶어서 Rarlab의 unrarsrc-3.9.6.tar.gz 와
여기에 NFC 정규화 변경을 하는 부분 코드패치를 올려 둡니다. 제가 Visual C++ 6.0 에서 돌려본 것이라
헤더파일 등에 수정을 약간 하셔야 할 듯 합니다.
IDN API 배포본을 설치하고 미리 제가 빌드한 unrar.exe로 test2.rar 를 열어보시면 한글이 풀리지 않은
원래 샘플 모습을 보실 수 있습니다. 이를 동일한 내용이 들어있는 test2.zip 과 비교해 보시면 됩니다.
비록 소수의 Mac 사용자들이지만 조금만 관심을 가져주시길 부탁드립니다 : )
답변 감사합니다. : )
저도 APSL라이센스를 영어를 그리 썩 못하는지라 자세히 읽어보지 못해서 잘은 모릅니다.
ttp://www.fsf.org/licensing/essays/apsl.html
을 읽어보니 Free software license의 자격이 있다고 하네요. 단 크게 2가지 고려할 점으로
이 있다고 합니다. 그런 점으로 살펴보면 압축시대에 사용을 해서 그리 문제가 될 소지는 없어 보이네요.
vfs_utfconv.c 에 들어있는 변환 함수를 MS의 IDN 정규화 API 대신 사용하면
일단 플랫폼에 제약이 사라지고, 정확하게 보면 HFS+에서 정규화하는 방식을 그대로 적용한다는 장점이 있습니다. 해제를 위해서 사용할때는 별 차이가 없지만, 압축 저장을 위해서 반대방향인 풀어쓰기로 정규화시에는 vfs_utfconv.c에 들어있는 함수를 쓰는게 정확합니다.
한동안 답이 없으시길레, 혼자서 7-zip 소스를 가지고 해보지도 않았던 MFC로 드랍애로우도 억지로 달고 삽질하고 있었는데 적용해주신다고 하니 한시름 놓았습니다. : )
드랍다운 상자를 달고 여기서 선택된 결과를 압축 모듈별 콜백함수에서 사용하는 프로퍼티로 전달할까 , 아니면 파일매니져 리스트뷰에서 사용하는 파일리스트 구조체의 인코딩을 바꿀까 갈피를 잡기 힘들던데 혹시나 압축시대에서 zip은 어떻게 처리한건지 궁금하네요. 본문에 첨부파일로 올린 패치에는 압축 모듈별로 있는 ?Handler.cpp 에서 GetProperty함수부분의 경로 리턴하는 부분에 정규화를 하게 했는데 이걸 어떻게 GUI에서 통제를 할까 고민중이었습니다.
그리고 가능하시다면 제가 올린 다른글에 있는 유니코드 BMP밖의 컨버터 버그도 적용해 주시기를 부탁드립니다.
대만이나 홍콩에서 사용하는 한자의 경우에 유니코드로 저장하면 해당 영향을 받을 수 있기 때문입니다.
그리고 vfs_utfconv.c 소스를 살펴보다가 한가지 더 발견한 버그가 있는데 이건 어떻게 해야 할런지 모르겠네요.
Windows에서는 파일이나 디렉토리명 시작과 끝에 스페이스가 들어가지 않게 권장하고 있는데 맥에서는 그런 제한이 없습니다. 그래서 파일명 앞이나 끝에 스페이스가 들어갈 수 있고 끝에 .으로 끝날수도 있습니다.
이게 그대로 압축에 지원됩니다. 그래서 첨부한 파일로 풀어보면 7-zip에서 파일을 열지않고 풀기 명령으로는 스페이스가 들어있는체 풀리는데 압축 파일을 열고 나서 마우스로 파일을 골라서 풀면 폴더를 제대로 만들지 못해서 압축풀기에 실패하는군요. 7-zip 이외의 프로그램에서는 무참히 실패합니다.
압축 프로그램 잘못이라 할수는 없고 난감하네요. 첨부파일을 올려 봅니다.
각각 OS X에서 제가 수정한 CleanArchiver에 들어있는 info-zip, rar, 7zip으로 압축한 파일입니다.
자세한 정보 감사합니다. 테스트해보니 잘 되는군요. 담 업데이트때 적용하도록 하겠습니다. ^^
그나저나 APPLE PUBLIC SOURCE LICENSE 는 익숙하지가 않네요.
일단은 사용해도 별 문제가 없는듯 하지만, 혹시 주의사항 알고 계시면 알려주세요. ~