이 프로그램은 클래식 맥에서 StuffIt 으로 압축한 파일을 OS X에서 풀었을 때, 한글 파일이름이 제대로 나오지 않는 경우를 고쳐주는 프로그램 입니다.
 이와 함께 반대의 기능으로서, OS X에서 한글파일이름으로 된 파일을 OS X용 StuffIt 7.x~8.x 를 이용해서 압축시 망가진 한자 혹은 MacKorean 인코딩으로 바꾸어준 후 압축을 해서 OS 9에서 압축을 풀 때 제대로 한글이 나타나도록 하는 것도 가능합니다.

Sit*fiX


프로그램 받기
Sit*fiX 0.2.dmg운영체제 요구사항 : OS X 10.4+ Universal binary

 사용 방법은 간단합니다. 파일이름이 망가진 파일이나 폴더를 프로그램에 마우스를 이용해서 떨어뜨리거나, Cmd+C 로 파일을 복사해 놓은 다음 Sit*fiX 프로그램에서 Cmd+V로 붙여넣기 하면 됩니다. 스노 레퍼드 사용자의 경우에는 오른쪽 마우스를 파일에 눌러서 해당 기능을 편리하게 사용할 수 있습니다.

 옵션 중에 'MacKorean(OS9)으로 인코딩된 파일이름도 바꾸기'는 한자로 바꿔져 있는 한글 파일이름이 아닌, 일부 특정 기호와 한글 파일이름이 같이 있을 경우에 사용하면 제대로 된 파일이름을 복원해 줍니다. 또한 MacKorean으로 인코딩 된 특정 기호들도 최대한 변환가능한 기호로 바꾸어줍니다.


파일이름 변경과 관련된 자세한 설명


그리고 사용자분의 요청으로 소스코드를 모두 올려 드립니다. 이 코드는 Xcode 3.1.3 에서 작성되었습니다.
부가설명을 드리면 StuffItKoreanConvertTable.h , SFConverter.h, SFConverter.m 부분에 변환관련 상수와 코드가 들어있으니 그 부분을 위에서 설명한 것을 참고하여 살펴보시면 되겠습니다.
Sit*fiX src 2010.03.20 v0.2(26).zip

 끝으로 프로그램에 대한 의견이 있으시면 거리낌없이 올려주시기를 부탁드립니다.
그리고 맥에서 쓸만한 프로그램에 관한 글들이 있으니 Mac_Life카테고리에 속한 글들을 읽어 보셔도 후회하시지는 않으실 껍니다.

P.S.
 The Unarchiver를 이용해서 .sit 압축파일을 푸는 분들의 경우 MacKorean 으로 인코딩된 파일이름이 'test07%a2%e6%b1%e2%c8%a3%bf%cd%c7%d1%b1%db2abc' 처럼 퍼센트 인코딩으로 풀릴 수 있습니다. 이럴 때에는 다시 해당 문자로 바꿔주는 프로그램( URI Escape , ... ) 을 사용해 바꿔준 후 Sit*fiX를 사용하거나, 아니면 7.x 이후 버전의 StuffIt Expander를 가지고 풀어주면 이런 문제없이 풀어줄 수 있습니다.
Posted by trip2me
,

 윈도우와 맥의 한영/한자 단축키를 같이 사용하기 위한 방법을 알아 보겠습니다. 파일 하나로 한번에 끝내는 것은 제 실력이 부족해 만들지 못하니 양해를 구하며, 대신 글을 차분하게 읽어주시길 부탁드립니다. 
 덧글) 약간의 부끄러운 광고이긴 하나 압축을 위한 프로그램인 CleanArchiver 게시물도 한번 살펴봐주세요.후회하시지 않을껍니다. 다른 게시물도 심심하시면 읽어보세요. 도움이 될만한 것들이 있습니다. : )

 용어의 혼란을 피하기 위해 몇가지를 알려드립니다.
커맨드(⌘, , command)키는 Cmd 로, 옵션(⌥, option, alt)키는 Opt 로 적겠습니다.
리턴(Return)키는 오른쪽 쉬프트키 위의 키이고, 엔터(Enter)키는 구형 맥북 오른쪽 커맨드키 옆에 있는 키입니다. 요즘의 신형 맥북에는 대신 Opt키가 자리하고 있습니다.
한영키와 한자키는 PC 키보드의 스페이스키 양 옆에 달린 진짜 “한영키” “한자키”를 가리킵니다.

자 그럼 어떤 단축키를 윈도우와 맥에서 같이 사용할 수 있는지 아래의 표를 간단히 살펴봅시다.

표는 크게 두가지로 나누어져 있습니다.

  1. 한영/한자 단축키를 윈도우와 맥에서 같이쓰는 경우 [1, 2 번째 표]
  2. 단축키를 각자 따로 쓰는경우(맥만 사용하거나 부트캠프 포함) [3, 4 번째 표]

여기서는 단축키를 같이 쓰는 경우에 대해서 주로 살펴 보겠습니다.
단독 사용 설정도 내부 설정 방법은 첫번째방법과 동일하기 때문입니다.

 일단 사용하고 싶은 한영/한자 단축키를 고르기 전에 자신이 사용중인 가상화 프로그램이 Parallels, VirtualBox, VMWare 중에서 무엇인지 먼저 알아둡니다. 그러고나서 위의 1, 2 번째 표를 잘 살펴봅시다.

 예를 들어, 자신이 VMWare를 사용하고 맥에서 기본으로 들어있는 한글 입력기를 사용한다면, 한영전환키로 “Cmd+Space, Shift+Space, 한영키” 를 사용할 수 있고, 한자변환을 위해서 “옵션+리턴” 키만 가능하다는 것을 알 수 있습니다. 1, 2번째 표에서 VMWare열의 ◆표시를 살펴보세요.

 사용자가 Parallels를 사용한다면 맥의 기본 입력기로는 한영전환을 거의 할 수 없다는 것을 표를 보고 알 수 있습니다. 하지만 바람입력기나 KeyRemap4Macbook 을 사용하면 맥과 윈도우에서 같이 한영전환/한자변환을 쓸 수 있습니다.

 표에서는 단축키를 사용할 수 있는지 없는지 정도의 간단한 내용만 나와 있습니다. 하지만 초보자들은 표의 내용만 보고서 실제 단축키 설정을 하기 어렵습니다. 그래서 많은 사용자들이 주로 사용할만한 예를 들어서 필요한 설정이 무엇인지 초보자들이 쉽게 따라할 수 있도록 자세하게 살펴보겠습니다.

  예제를 소개하기 전에 앞서서 부트캠프 드라이버를 Parallels, VMWare, VirtualBox에 설치한 윈도우에는  설치하지 말아주세요. 부트캠프의 장치 드라이버와 가상윈도우의 가상 하드웨어 드라이버가 다르기 때문입니다. 부트캠프와 가상화 윈도우를 동시에 한곳에서 사용한다면 설치가 불가피 합니다.

 그리고 한영전환/한자변환과는 별개의 문제이지만 프로그램을 실행했을 때 프로그램의 글자들이 제대로 나타나지 않을 때 대처방법에 대해 알려드립니다. 아래를 펼쳐서 보세요.



 이제 본론으로 다시 돌아와 한영전환/한자변환 예제에 대해 살펴봅시다.

첫번째 예제
VMWare와 맥에서 한영전환을 “Cmd+Space”로 하고 한자변환을 “Opt+Return”키로 사용하기.
(기본 입력기 사용)

두번째 예제
Parallels와 맥에서 한영전환을 "Cmd+Space"로 한자변환을 "Opt+Return"으로 하기.
(바람입력기 사용)

세번째 예제
 Parallels, VirtualBox 또는 VMWare와 맥에서 한영전환을 "오른쪽 Cmd"키로, 한자변환을 "오른쪽 Opt"(신형 맥북) 혹은 "Enter"(구형 맥북) 키로 하기. (바람입력기 사용)

네번째 - 부트캠프와 관련된 것들
부트캠프의 윈도우에서 한영전환/한자변환 단축키 설정 방법 종류에 대한 설명


나머지 못다한 이야기들
 지금까지 다뤄온 내용에 대한 좀 더 자세한 설명이 들어 있습니다. 관심 있으신 분만 살펴보세요.

 이 가이드를 적으면서 전세계 많은 분들의 참고 자료와 프로그램들을 사용했습니다. 모두 여기에서 나열하지는 않았지만 좋은 정보, 프로그램을 만들어 주신 것에 대해서 감사의 말씀을 올립니다.

 끝으로 긴 글을 적다보니 부족한 머리로 지금까지 무슨 말을 한 것인지 잘 모르겠네요. 부디 한분에게라도 도움이 되는 글이 되었으면 좋겠습니다. 궁금한 점이 있거나 글에서 잘못된 내용, 고쳐야할 내용, 추가되었으면 하는 내용등 기타 의견이 있으면 거리낌 없이 댓글을 달아 주시기 부탁드립니다.

Posted by trip2me
,
지난번에는 압축시 한번은 생각해 볼 압축 비밀번호와 유니코드 파일이름에 대해 이야기 했습니다.
이번에는 압축 프로그램을 좀 더 효율적으로 사용하기 위한 정보를 올려봅니다.

저는 압축 프로그램의 기본적인 성능측정 잣대를 5가지로 봅니다.
  1. 압축 후 얼마나 작게 만들어주는가
  2. 압축시 걸리는 시간
  3. 해제시 걸리는 시간
  4. 압축시 필요한 메모리 크기
  5. 해제시 필요한 메모리 크기
위 요소 중에서 사용자들이 가장 체감적으로 느끼는 것은 1,2, (3) 입니다. 그래서 이번 글에서는 1,2,3번에 중점을 두어 압축프로그램들의 벤치마크를 하고, 요즘 사용되는 멀티코어와 대용량의 메모리를 가지는 시스템과의 연관성에 대한 결과를 살펴 보도록 하겠습니다.

테스트 한 예제 파일
  1. 다량의 그림파일과 압축파일이 들어있는 1.31GB(1412160010)의 어느 홈페이지
  2. Google Earth for OSX, Gimp 2.6.8 source code, Maximum Compression사이트의 full_testset테스트파일, 제가 수정한 CleanArchiver 프로그램이 들어있는 약400MB(416703838) 테스트셋
우선 위 파일들은 각각 중복성을 가지게 하기 위해서 내부에 자신의 사본을 2벌씩 가지게 했습니다. 이후 솔리드 압축에서 결과의 차이를 볼 수 있습니다. 그리고 1번 테스트셋은 압축이 이미 거의 된 결과물이고 2번은 압축이 매우 잘 되는 파일이 많이 들어 있어서 테스트 후 결과를 비교하기 위해 설정했습니다.

테스트는 4GB메모리에 쿼드코어 제온 E5355 이 2개 들어가 있고 Windows 2003 R2 x86버전이 설치된 시스템을 사용했습니다. 아쉽게도 64비트 운영체제가 없어서 64비트일때의 차이는 테스트에 고려할 수 없었습니다. 그리고 7zip의 일부 압축률에서의 테스트는 압축시 필요로 하는 총 메모리의 부족으로 테스트 할 수 없었습니다.

테스트에 이용한 압축 프로그램들과 이용한 포멧의 종류는 아래와 같습니다.
일부 생소한 압축 프로그램이 등장하는데요, 결과에서 좋은 정보를 드리기 위해서 추가했습니다. nanozip은 LZPF, LZHD 알고즘을 사용했고, quad, balz는 ROLZ알고리즘을 사용합니다.

그 이외에는 각각의 프로그램들에서 주로 내세우는 압축 포멧을 이용해서 벤치마크에 사용했습니다. 테스트시 사용한 스크립트는 4NT에서 타이머 함수를 가지고 측정했으며 첨부파일을 받아서 직접 해 보실수 있습니다. balz와 quad는 단일파일 압축만 지원하기 때문에 디렉토리 결과를 파악시 7z의 tarball을 이용해 묶은 시간을 벤치마크에 포함했습니다.

이제 본격적으로 벤치마크 결과에 대해서 살펴보도록 하겠습니다. 테스트 결과 택스트 파일을 올립니다.

아래 그래프들은 위 첨부 데이터 중 멀티쓰레드가 모두 가능한 기본적인 시스템 상황에서 각 압축프로그램들의 기본 설정사항에서 압축률만 옵션으로 변화를 주어 압축한 결과를 나타낸 것입니다. 단, 7-zip의 bzip2 알고리즘을 이용한 경우는 보통 압축률에 쓰레드 갯수를 1,2,4,8개로 한 결과입니다. nanozip은 LZPF,LZPF_large, LZHD, LZHDS알고리즘을 지정하고 각각의 결과를 함께 나타냈습니다. 그리고 2번 테스트셋을 하나의 tarball로 묶은 후 그것을 같은 방식으로 압축한 결과를 원래의 2번 테스트셋과 비교하기 위해서 3번째 그래프로 올립니다.

그림의 순서는 압축과 해제결과 각각 차례대로 1번 테스트셋, 2번 테스트셋, 2번 테스트셋의 묶음파일입니다. 각각의 그림은 클릭하면 크게 볼 수 있습니다.

다음은 압축시 걸린 시간과 압축결과 파일 크기의 그래프입니다.
1번 테스트셋 종합 압축결과 1번 테스트셋 종합 압축결과
2번 테스트셋 종합 압축결과 2번 테스트셋 종합 압축결과
2번 싱글 테스트셋 종합 압축결과 2번 싱글 테스트셋 종합 압축결과


다음은 해제시 걸린 시간과 압축결과 파일 크기의 그래프입니다.
1번 테스트셋 종합 해제결과 1번 테스트셋 종합 해제결과
2번 테스트셋 종합 해제결과 2번 테스트셋 종합 해제결과
2번 싱글 테스트셋 종합 해제결과 2번 싱글 테스트셋 종합 해제결과
그림에서 가로축은 압축 또는 해제시에 걸린 시간을 나타내고 세로축은 압축한 결과의 크기가 원래보다 몇퍼센트인지를 보여줍니다. 즉 왼쪽 아래 원점에 가까워질수록 높은 압축률 및 좋은 압축&해제 시간을 보이는 것입니다.

위 그림들을 보고 참고할 사항을 나열해보면
  • 솔리드 압축을 이용할 경우 솔리드 블럭 설정이 매우 중요합니다. 이를 너무 작게 잡으면(압축률을 작게 설정시 해당됨) 압축도 잘 되지 않을뿐만 아니라 압축 시간도 많이 걸리게 됩니다.
  • 압축률을 압축프로그램에서 선택시 가급적 '보통'을 선택하는게 시간&용량면에서 평균적으로 유리합니다.가급적 나머지 압축률은 사용하지 말고 '보통'을 주로 사용하시기 바랍니다.
  • 7zip의 경우 솔리드 압축을 사용하기를 적극 권장(실제 기본으로 켜져있음)하며 4개이상의 멀티코어와 3GB이상의 큰 메모리를 가지는 시스템에서는 LZMA2 알고리즘을 이용할 경우 큰 압축&해제시간 향상을 꾀할 수 있습니다. 압축 해제시 LZMA알고리즘보다 훨씬 빠르기 때문에 LZMA2알고리즘 사용을 적극 권장합니다.
  • rar의 경우 적당한 압축효율과 상대적으로 낮은 압축&해제 시간을 가지는 포멧인 것이 나타납니다. 역시 멀티코어의 이득을 보기 때문에 코어가 많을수록 좋은 결과를 보여줍니다. 여기서 나타나지는 않았지만 한가지 장점은 좋은 결과에도 불구하고 적은 메모리를 사용합니다.제가 언급한 성능 고려요소 5가지 부문에서 종합 1위를 준다면 Winrar에게 줄 수 있겠네요. rar도 7-zip과 마찬가지로 압축파일에 추가 수정을 하지 않는다면 솔리드 압축시 시간 손실 거의 없이 용량의 이득을 볼 수 있으므로 권장합니다.
  • 알집의 alz는 압축시 zip의 일반적인 성능을 가지지만, 해제시 일반 zip보다 2배정도 빠른 속도를 가지고 있습니다.
  • 알집의 새로운 포멧인 egg는 압축 & 해제 시간과 압축효율면에서 7zip의 알고리즘을 사용했음에도 불구하고 7zip보다도 쳐지는 모습을 보여주고 있습니다. 흥미로운 점은 egg의 경우 '최적옵션'을 선택시 알집 스스로 자신이 zip의 deflate와 유사한 알고리즘 혹은 LZMA와 유사한 것을 고르게 되는데 아쉽게도 결과는 둘 다 모두 좋지는 않습니다.
  • quad, balz는 멀티쓰레드를 사용하지 않고 rar와 같이 작은 메모리를 사용함에도 불구하고 중상위권에 속하는 좋은 압축률과 압축&해제 시간을 기록했습니다. 거기에 보테어 기본적으로 솔리드 옵션이 없지만 중복된 파일을 모두 하나로 압축해 주었습니다.
  • nanozip은 정말 경이적인 속도와 압축률을 보여줍니다. quad, balz와 같이 멀티쓰레드를 이용하지 않지만 LZPF & LZPF_large의 경우 최상의 압축률과 압축 속도를 보여주어서 nanozip의 귀추가 주목됩니다. 메모리 사용량의 경우 기본적으로 400MB를 압축시 사용하지만 이정도의 성능 향상은 기적이라 할 수 있습니다.

7zip과 rar의 멀티쓰레드 갯수별 결과 그래프가 있는데, 결론을 말하고 생략하겠습니다.
7zip의 LZMA알고리즘은 딱 2개의 쓰레드가 동시에 돌아가면 됩니다. 적으면 큰 성능하락을, 많으면 2개와 별차이가 없습니다.그런 이유로 4개 이상의 멀티코어의 능력을 이용하기 위해서는 LZMA2알고리즘을 반드시 사용해야 합니다. 그리고 압축 해제시에는 언급한데로 LZMA보다 LZMA2가 2배 가까이 빠르며 LZMA와 마찬가지로 쓰레드 갯수에는 영향을 받지 않습니다.

rar도 압축해제시에는 멀티쓰레드의 영향을 받지 않습니다. LZMA2 및 rar 의 경우 4개에서 8개의 쓰레드로 동시에 압축하는 성능 향상은 2개에서 4개의 차이보다 크지 않습니다. 즉 성능 향상은 로그함수적으로 올라갑니다.

pbzip2의 경우는 이와는 달리 쓰레드 갯수=압축성능향상의 비례가 1:1 정비례에 보다 비슷하게 성립합니다. pbzip2해제시에는 멀티쓰레드의 영향은 받지만 압축보다 크지는 않습니다.

위 그림을 비교해보면 얻을 정보가 더 많지만 용두사미로 끝이 나고 말았네요 : )
그래프를 꼼꼼히 비교해서 살펴보시면 많은 정보를 얻을 수 있습니다. 결과 수치를 텍스트 파일로 보면 좀 더 많은 정보를 얻을 수 있지만 그건 추천하지는 않겠습니다.

참고 링크로 Teddy Rogers라는 유저가 Tuts4You.com 에 올린 LZMA vs LZMA2 vs WinRAR64라는 압축 비교 문서를 첨부파일로 올립니다. 문서에는 4코어 CPU를 가진 컴퓨터를 가지고 압축 프로그램에서 사용하는 쓰레드 갯수를 바꿔가면서 실제 CPU사용 현황 및 메모리 사용량 등을 대략 쉽게 보여주기에 제가 벤치마크한 것과 비교하면 좀 더 이해에 도움이 될 듯 합니다.

COLLAGE FACTORY 님의 7-zip 이야기는 압축 알고리즘에 대한 재미있는 내용이 있으니 관심 있으면 읽어보세요.

다른 의견이나 반대의견 또는 하시고 싶은 말씀이 있다면 자유롭게 남겨주시기 바랍니다.
Posted by trip2me
,
한영전환에 대한 보다 많은 내용을 소개한 글을 올렸으니 새로 올린 글을 살펴봐 주세요.





프로그램 추가 : 동영상에 나오는 Hangul remapper.zip 대신 더 편하게 설치할 수 있는 프로그램을 올렸으니 글 마지막 부분의 첨부파일을 사용하세요.

예전에 이런 글에서 한영전환시 수정된 KeyRemap4Macbook을 이용한 일반 한글 키보드에 달린 한영키를 한영키로 사용하기 위한 방법을 쓴적이 있습니다. 이 방법이 보통 사람들에게는 어려워서 이번에는 좀 더 쉬운 방법을 그림을 통한 설명과 함께 올려봅니다.


1. 우선 정태영님께서 만든 최신 버전의 바람입력기를 받아서 설치합니다.
설치 후 재부팅이 필요할 수도 있습니다.



2. 다음 바람입력기를 기본 입력기로 사용하기 위해서 메뉴막대 위의 언어 깃발 표시를 눌러 'Open International' 혹은 환경설정을 열어 만국기 깃발 모양의 'International'을 엽니다.
사용자 삽입 이미지
사용자 삽입 이미지



3. 나온 화면에서 바람입력기를 찾아 체크를 해 줍니다.
이 때 한가지 팁으로서, US라는 영문 입력기를 직접 해제 할 수 없는데 이럴 때 Kotoeri라는 일본어 입력기를 바람입력기와 함께 먼저 체크하고 US입력기를 체크해제한 후 Kotoeri를 해제하면 바람입력기만 체크한 상태로 남겨둘 수 있습니다.
사용자 삽입 이미지



4. 위 화면 아랫부분에 있는 입력기 전환 단축키 설정 버튼(Keyboard Shortcuts)을 눌러서 단축키 설정화면으로 이동합니다. 나타난 아래 화면에서 입력기 전환 단축키중 "Input Menu"섹션에 있는 ⌘-Space를 해제하고 설정을 닫아줍니다.
유의할 사항으로 이전 화면의 입력기 선택을 하면 이곳의 단축키가 다시 살아나게 되므로 나중에 한영키가 안되면 이곳에 단축키가 해제 되었는지 꼭 확인하세요.
사용자 삽입 이미지



5. 이제 메뉴막대로 가서 입력기 모양의 아이콘을 눌러 바람입력기 환경설정을 열어줍니다.
사용자 삽입 이미지

그리고 단축키 설정 메뉴에 가서 +버튼을 눌러 바람입력기에서 한영전환 단축키 추가를 합니다.
아래 그림처럼 한글키, 사용자 정의를 선택하고, 단축키를 입력하는 하얀 창에 마우스 커서를 가져다 눌러준 후 ⌘-Space를 눌러주면 그림처럼 단축키가 입력됩니다. 단축키 입력이 잘 됐다면, Add를 눌러서 추가합니다.
1.5 버전의 바람입력기는 생김새가 아래와는 조금 다르지만 방식은 동일합니다.
이곳에서 원하는 키가 입력되지 않는다면 이는 원하는 키가 이전의 4번째 순서에 나오는 맥 환경설정 단축키에 이미 지정이 되어있기 때문입니다. 그때는 해당 단축키를 다시 확인해 해제하고 다시 시도하면 됩니다.
사용자 삽입 이미지

결과는 아래처럼 됩니다. 저는 한자입력을 위해 단축키를 하나 더 등록했습니다.
사용자 삽입 이미지



6. 이번에는 어플리케이션이란 탭으로 이동해서 바람입력기 리매퍼가 작동하지 않을 프로그램을 지정해 줄 차례입니다. 리매퍼가 작동하지 않아야 가상으로 뜬 윈도우에 단축키가 그대로 전달되기 때문입니다. 맥 환경설정의 입력기 단축키를 지정하였을 때 바람입력기에서 단축키로 추가되지 않는 이유도 이때문입니다.
여기서도 추가를 위해 +버튼을 누른 후 VMWare나 Parallels, Virtual Box와 같이 자신이 사용하는 프로그램을 추가합니다.
그림처럼 Remapper라는 열의 값이 Disable로 비활성화 되게 하는 것이 가장 중요합니다.
사용자 삽입 이미지

퀵실버에 대한 한가지 팁으로서 추가한 결과를 살펴보면 다른 것과는 다르게 Initial Mode를 영어로 해 두어서 퀵실버가 뜰 때 마다 영어로 입력기 되게 하면 퀵실버 사용자의 경우 편리합니다.
추가가 끝나면 Save를 눌러서 저장을 하고 마칩니다.


7. 이제 Parallels, VMware등에 있는 윈도우를 실행합니다.
그리고 나서 첨부파일의 'Win-Space to Hangul.exe' 를 살행하고 한영전환이 맥에서와 같은
⌘-Space로 작동되는지 확인해 봅니다. 잘 된다면 성공입니다. : )
사용자 삽입 이미지
실행이 되면 트레이 아이콘에 조그맣게 아이콘이 나타납니다.
만약 Cmd가 윈도우에서 Win키가 아닌 키로 작동하면 첨부파일을 살펴보고 적당한 것을 실행하면 됩니다.

이 프로그램을 부팅할 때마다 자동으로 실행되게 하려면 윈도우 하드디스크의 적당한 곳에 복사해 두고 프로그램의 바로가기를 만들어서 '시작->모든프로그램->시작프로그램'에 넣어주면 됩니다.

이 조그마한 프로그램은 AutoHotKey라는 단축키 지정 프로그램을 통해 만든 것인데요,
자신이 원하면 다른 단축키로 지정할 수 있습니다.
첨부파일에 같이 들어있는 .ahk확장자 파일을 수정하면 되니 관심 있으신 분은 이곳을 방문해 활용해 보세요.

P.S. 7번째 과정을 AutoHotKey 프로그램을 사용하지 않고 대신 이곳의 방법을 통해서도 할 수 있습니다.

추가 좀 더 편하고 자유로운 방법을 추가합니다.
살쾡이님의 IMECur란 프로그램을 약간 수정해서 해당 실행 파일에 리매핑을 하는 코드를 넣고 자신이 원하는 방향으로 만들어 쓰는 방법입니다. 아래 그림처럼 첨부한 파일을 풀어서 나오는 ShortCut.txt 파일을 메모장으로 열어서 원하는 매핑부분의 세미콜론 을 없에고 저장 후 Make.cmd 파일을 실행해 폴더에 새로 생기는 IMECur 를 실행해 사용하면 됩니다.
사용자 삽입 이미지
Posted by trip2me
,
SourceForge에 있는 Keka라는 OSX을 위한  p7zip GUI 프론트엔드 프로그램 버그에 이런 저런 글을 달면서 윈도우에서 기본 압축 프로그램으로 .zip 압축을 할 때 적용되는 몇가지 사항에 대해서 제대로 알게 되었다.
  1. 압축 파일 내부의 파일이름은 현재 시스템의 OEM코드페이지의 문자를 사용한다.
  2. 압축 파일에 암호를 걸면 암호는 현재 시스템의 OEM코드페이지에 한쌍으로 연관된 ANSI 코드페이지 문자열을 사용한다.
.zip 압축은 만들어진지 오래된 압축포멧이다. 하지만 ISO정도의 국제 공인 표준이 아닌 PKWare에서 관리하는 AppNote정도의 De Facto표준이기에 이런저런 회사의 개별 구현들이 표준에 들어가 플랫폼간 파일 교류에 문제를 일으키게 한다.

 첫번째 항목은 예전 DOS시절에 사용하던 zip압축의 파일명 저장 방식때문에 일어난다. 실제 zip 포멧을 처음 만들었을 때는 유니코드와 같은 전세계 문자가 들어있는 파일명을 고려하지 않았다. 사실 유니코드와 같은 다국어 지원에 대한 지원을 그 당시로서는 고려하지 않았다. 그 대신에 각각의 언어환경에서는 각자의 문자셋이 있는 코드페이지로 압축파일 저장을 했다. 그래서 압축 파일안에 있는 파일명이 무슨 문자셋으로 인코딩이 되어있는지  정보가 들어있지 않아서 다른 외국어 윈도우 사용자가 압축을 풀려고 시도를 하면 이상하게 깨어저 보이게 된다.

 현재 사용하는 윈도우들은 유니코드를 모두 지원하지만 하위호환성을 염두에 둔 이유인지 AppNote에 UTF-8 파일명을 사용하는 플래그를 아직까지도 지원하지 않고 있어서 사용자들에게 불편을 주고 있다. 그나마 다행인 것은 요즘 나오는 써드파티 압축 프로그램들에서 유니코드 지원을 위해서 UTF-8 플래그를 인식하게 해 주도록 업데이트 되고 있는 상황이다.

 그리고 OSX나 요즘의 Linux의 경우 파일처리 시스템 콜에서 UTF-8을 파일이름 전달에 기본적으로 사용하게 되어 상황이 좋아졌는데, OSX의 경우 한가지 문제는 압축파일에 UTF-8 파일명을 사용한다는 플래그를 전혀 세팅하지 않아서 유니코드를 지원하는 프로그램들이 제대로 인식하지 못한다는 사실이다.( 윈도우의 기본 압축 프로그램이 하는 행동처럼 아마 자신들만 사용하는 로컬 문자셋이라고 생각하는 모양이다.)  또다른 문제아닌 문제는 OSX에서는 기본적으로 일부 풀어쓰기 영역의 유니코드문자로 표현하는 언어(한글,라틴어,...)가 그 상태 그대로 압축파일에 저장되기에 이 파일을 윈도우나 리눅스에서 풀게되면 보통 사용하는 NFC정규형으로 되지 않아 있기에 이런저런 사소한 불편함이 따른다는 것이다. 아직까지 파일이름의 정규화에 대해서는 AppNote에도 고려가 되어 있지 않고 사실 어떻게 보면 압축 포멧 자체에서 고려할 사항이 아닌 부분이다. 하지만 실제 불편함이 일어나기에 어느정도 정규화 변환 정도의 옵션은 압축 프로그램에서 제공해 주어야 하지 않을까 하는 생각이 든다.

 첫번째 위의 이유로 인해서 윈도우에서 아래 언어를 사용하는 로케일은 ANSI/OEM 코드페이지가 없기 때문에 유니코드로 지원하지 않는 윈도우의 기본 zip압축을 가지고서 자신의 언어로 이루어진 파일명을 압축파일안에 사용하지 못한다. 그래서 IT가 발전하는 인도에서는 도대체 자신들의 컴퓨터에 저장하는 파일 이름을 영어로만 저장하고 압축하는지 참으로 궁금하다. 이것과는 직접적인 연관성이 있지는 않지만 한편으로 한글이라는 글자를 세종대왕께서 과학적으로 창제하여 지금껏 잘 사용할 수 있는 것에 다시금 감사하게 생각할수 밖에 없다.
Amharic (Ethiopia) አማርኛ (ኢትዮጵያ)
Armenian (Armenia) Հայերեն (Հայաստան)
Assamese (India) অসমীয়া (ভাৰত)
Bengali (Bangladesh) বাংলা (বাংলাদেশ)
Bengali (India) বাংলা (ভারত)
Divehi (Maldives)‎ ދިވެހިބަސް (ދިވެހި ރާއްޖެ)‏
Georgian (Georgia) ქართული (საქართველო)
Gujarati (India) ગુજરાતી (ભારત)
Hindi (India) हिंदी (भारत)
Inuktitut (Syllabics) ᐃᓄᒃᑎᑐᑦ (ᖃᓂᐅᔮᖅᐸᐃᑦ)
Inuktitut (Syllabics, Canada) ᐃᓄᒃᑎᑐᑦ (ᑲᓇᑕᒥ)
Kannada (India) ಕನ್ನಡ (ಭಾರತ)
Kazakh (Kazakhstan) Қазақ (Қазақстан)
Khmer (Cambodia) ខ្មែរ (កម្ពុជា)
Konkani (India) कोंकणी (भारत)
Lao (Lao P.D.R.) ລາວ (ສ.ປ.ປ. ລາວ)
Malayalam (India) മലയാളം (ഭാരതം)
Maltese (Malta) Malti (Malta)
Maori (New Zealand) Reo Māori (Aotearoa)
Marathi (India) मराठी (भारत)
Mongolian (Traditional Mongolian) ᠮᠤᠨᠭᠭᠤᠯ ᠬᠡᠯᠡ
Mongolian (Traditional Mongolian, PRC) ᠮᠤᠨᠭᠭᠤᠯ ᠬᠡᠯᠡ (ᠪᠦᠭᠦᠳᠡ ᠨᠠᠢᠷᠠᠮᠳᠠᠬᠤ ᠳᠤᠮᠳᠠᠳᠤ ᠠᠷᠠᠳ ᠣᠯᠣᠰ)
Nepali (Nepal) नेपाली (नेपाल)
Oriya (India) ଓଡ଼ିଆ (ଭାରତ)
Pashto (Afghanistan)‎ پښتو (افغانستان)‏
Punjabi (India) ਪੰਜਾਬੀ (ਭਾਰਤ)
Sanskrit (India) संस्कृत (भारतम्)
Sinhala (Sri Lanka) සිංහ (ශ්‍රී ලංකා)
Syriac (Syria)‎ ܣܘܪܝܝܐ (سوريا)‏
Tamil (India) தமிழ் (இந்தியா)
Telugu (India) తెలుగు (భారత దేశం)
Tibetan (PRC) བོད་ཡིག (ཀྲུང་ཧྭ་མི་དམངས་སྤྱི་མཐུན་རྒྱལ་ཁབ།)
Yi (PRC) ꆈꌠꁱꂷ (ꍏꉸꏓꂱꇭꉼꇩ)


 두번째 항목인 압축 암호의 코드페이지 종류가 또다른 골칫거리가 된다. MS에서 제공하는 National Language Support (NLS) API Reference을 가 보면 각각의 언어와 관련된 로케일에서 사용되는 ANSI, OEM 코드페이지가 무엇인지 쉽게 잘 알 수 있다. 이것이 무슨 연관성이 있는가 하면, 압축을 할 때 암호 문자열에 대한 인코딩과 문자셋에 지정을 하는 규정이 AppNote에 없기 때문에 윈도우의 경우에는 OEM 코드페이지와 연관된 한쌍의 ANSI 코드페이지를 사용 한다. 결과적으로, 한글 윈도우에서 압축파일에 한글로 암호를 준 것을 다른 외국 윈도우 사용자에게 전달하면 그 사용자는 윈도우에서 사용되는 CP949코드페이지의 한글문자열을 똑같이 입력해야 압축해제를 할 수 있다는 사실이다.

 설상가상으로 위에서 소개한 링크에서 찾아보면 하나의 로케일에서 OEM코드페이지와 ANSI코드페이지가 다른 언어들이 있는데 이 경우에는 상황이 더 복잡해진다. 글 처음에서 소개했듯이 압축시 암호는 ANSI코드페이지를 사용한다고 했기에 가령 히브리어 윈도우에서 압축한 'עִבְרִית'란 파일과 압축암호가 실제 헥사코드로는 값이 각각 다르다는 의미이다. 이런 고려를 하지 않은 압축 프로그램들은 이런 압축 파일을 제대로 다룰 수 없게 된다.
 그래서 이런 사실을 사용자들이 제대로 인식하고 사용을 해 주었으면 한다. 그리고 가능하면 .zip 압축파일의 암호에는 알파벳 문자와 기본적 숫자,기호만을 사용하는게 보안상 취약성이 올라간다고 할지는 모르겠지만 다국어 사용자들간 .zip 파일 교환의 측면에서는 바람직해 보인다. 또한 앞으로 zip파일에 UTF-8을 사용한 압축을 하고 암호에도 UTF-8문자열을 사용한다면 반드시 정규화에 대한 고려를 해 주거나 사용자들의 인식이 되 있어야 하지 않을까 하는 바램이다. 보기에는 똑같지만 다른 글자인 암호를 사용해서 윈도우와 OSX사이의 파일 교환에 곤란한 일이 일어날 수도 있기 때문이다.

 마지막으로 가급적이면 유니코드 사용이 기본인 .7z, .rar 포멧을 사용하는것을 추천하지만, 관성의 법칙으로 인해서 사용자들에게 무조건 바꾸라고 하기에는 힘든것이 사실이다. 그런 이유에서라도 MS나 Apple등 기업에서 적어도 UTF-8파일명 사용 플래그를 제대로 인식하는 압축 프로그램을 기본으로 제공해 주었으면 하는 바램이다. 하지만 실제 그렇지 않은 현실에서 사용자들이 위와 같은 내용을  제대로 인식을 한 상태에서 사용을 하면 이런저런 애로사항을 줄일 수 있지 않을까 생각한다. 그리고 각각의 써드파티 압축 프로그램들이 정규화나 기본 다국어 평면을 벗어나는 유니코드 글자 지원이 아직까지는 미비한 경우가 많은데 이에 대한 지원을 힘써서 zip포멧에서 제대로된 유니코드 압축 지원을 해 주었으면 좋겠다.
Posted by trip2me
,
사용자 삽입 이미지

참고) 2010.4.22 일자로 올라온 알집 8.0 공개용 버전에서 zip 파일 압축 해제시 위 기능을 지원하도록 추가했네요. 알집 8.0 버전 이상을 쓰시는 분은 알집으로 압축을 풀어주시면 되겠습니다. 

 이번에 소개하는 7-zip 수정버전은 CleanArchiver의 윈도우쪽 상대 역할을 하는 프로그램으로서,  맥에서 위 프로그램을 사용하지 않고 압축한 7zip, rar, zip, tar 파일을 윈도우에서 풀 때, 'ㅎㅏㄴㄱㅡㄹ' -> '한글' 과 같은 풀어쓰기 파일이름을 하나의 글자로 합쳐서 풀어줍니다.

여기에 하나 더 보테어 Winrar에서 공개한 압축 해제 CLI 프로그램인 unrar 소스를 수정해서 역시나 같은 역할을 하는 실행파일을 함께 올립니다.


먼저 필요한 사항
프로그램을 작동시키기 위해서는 적어도 아래 세가지 중 하나를 만족해야 합니다.
  1. 비스타 혹은 이후의 운영체제를 사용중
  2. 윈도우 XP Sp2 이상에서 인터넷 익스플로러 7.x 이후 버전을 사용중
  3. 윈도우 XP Sp2 이상에서 같이 첨부된 Microsoft의 IDN APIs 패치를 함께 설치

설치 방법
 첨부된 압축 파일을 받아서 적당한 곳에 풀어놓고 사용하면 됩니다.

 기존에 7-zip을 쓰듯이 탐색기 메뉴를 통해 사용하려면 7-zip 사이트에서 먼저 설치버전을 받아서 설치하고 제가 올린 파일의 압축을 풀어서 "C:\Program Files\7-Zip" 경로에 덮어쓰면 됩니다. 이렇게 하기 전에 꼭 .zip 파일에 대한 제한사항을 읽어보세요.

 추천하는 방법으로는 동일하게 술집 설치버전을 받아서 설치하고 아래 첨부 파일의 압축을 풀어서 "C:\Program Files\Soolzip" 경로에 "7z.dll, 7zg.exe 7z.sfx" 파일을 자신의 윈도우 버전(32bit, 64bit에 따라 7zg.exe를 7zg32.exe 혹은 7zg64.exe로, 7z.dll을 동일하게)에 맞게 복사하면 .rar, .7z 의 경우 제가 수정한 기능이 술집에서 아래 그림처럼 지원 됩니다.
사용자 삽입 이미지



사용 방법
 기존의 7-zip을 사용하던 것과 동일합니다. 술집에 추가해 사용해도 인터페이스에 아무런 차이는 없습니다.


제한 사항
 이 프로그램은 맥의 기본 압축프로그램으로 압축된 .zip 파일만 제대로 읽도록 만들어져 있어서 7-zip을 대체해서 사용할 경우 기존에 윈도우에서 압축한 .zip파일에서는 제대로 보이지 않습니다. 반드시 유의하세요. 또한 맥에서 압축한.zip 압축파일에 파일추가나 파일안 이름바꾸기를 하면 맥에서 기본 압축 프로그램으로 제대로 풀리지 않습니다.

이런사항들은 제가 MFC를 잘 몰라서 메뉴 추가등이 어려워서 지원이 되지 않고 있는 상황이니 수정된 소스를 참고해서 코드페이지와 유니코드 normalize관련 드랍다운 버튼을 옵션으로 달아 7zip이 해당 옵션을 가지고 코드페이지 변환 및 정규화를 할 수 있게 도와주실분이 있으면 좋겠습니다.

파일받기( 2009.12.07 )

32bit(x86) 실행파일:
MD5 : 4adff1d5a444d5dc84014f0f7def4d10

64bit(x64) 실행파일:
MD5 : d3234c6656d7a112c02fcff2b5a8884c



7-zip & unrar 의 소스수정 내용

끝으로 수정한 사항을 알집, 빵집, 술집, Winrar, 7-zip, info-zip 등의 개발자들에게 알려서 고려해 줄 것을 요청하고 있습니다. 여러 개발자들이 지원해주면 조만간 여기저기서 좋은 소식이 있으리라 생각되네요. 혹시나 사용중에 문제점이나 좋은 생각이 있으시면 거리낌없이 댓글로 남겨주시기 바랍니다.
Posted by trip2me
,
공지) CleanArchiver 원 개발자분인 INAJIMA Daisuke님과 연락이 되어서 지금까지 수정한 내용을 모두 원래 공식 CleanArchiver 프로젝트에 전달했습니다. 단 개발자분과 저의 구현상 의견차이가 있어서 이곳에 올리는 수정한 버전과는 기능상 차이가 있으니 참고하세요.  개발자님의 홈페이지

참고) 2010.4.22 일자로 올라온 알집 8.0 공개용 버전에서 zip 파일 압축 해제시 위 기능을 지원하도록 추가했네요. 알집 8.0 버전 이상을 쓰시는 분은 맥의 기본 압축 프로그램으로 압축을 하였더라도 알집으로 압축을 풀어주시면 되겠습니다. 

참고2) 2011.5.10 추가로 '압축시대' 프로그램을 제작한 키플러 님의 새로운 압축 프로그램 '반디집'을 통해서도 압축을 풀 수 있다고 합니다. 아래 SkyKIDS 덧글 인용.
 

CleanArchiver 3.1.b2

 맥에서 한글 등의 풀어쓰기로 저장되는 파일명이 있는 파일들을 압축하고 윈도우나 리눅스에서 풀면 글자가 깨어져 보이는 것을 해결하기 위한 오토메이터 버전을 예전에 올렸더랬습니다.

이번에는 기존에 있던 프로그램들을 가지고 보다 쉽게 압축하기 위한 프로그램을 만들어 올려 봅니다.

 사용법은 간단합니다. 압축할 파일이나 폴더를 하나이상 고른 후 프로그램 아이콘이나 프로그램창에 떨어뜨리면 됩니다. 사용자가 원하는 선택사항을 맞춰놓고 기본값을 저장해 놓으면 나중에 파일을 떨어뜨릴때 설정한 값으로 바로 압축을 합니다.

   윈도우나 리눅스 사용자에게 전달 할 때 사용할 압축 형식은 zip과 7zip 두가지가 가능합니다. 이 때 .7z은 '윈도우 호환 파일이름 사용' 옵션을 체크하고 압축하면 됩니다. .zip의 경우 한글윈도우에서 한글파일이름을 위해서는 인코딩 설정에 'CP949'를 입력하거나 드랍다운메뉴를 열어 고르면 됩니다.
 rar의 경우는 개발자가 상용 프로그램으로 소스를 공개하지 않기 때문에 개발자 지원이 있지 않는한 풀어쓰기 글자로만 압축가능합니다. 그런 이유로 맥에서 압축한 rar 파일을 윈도우에서 압축해제시에는 자매품인 7-zip 수정버전 혹은 Namo님의 HangulJasoFixer.exe 을 사용하세요.

 다른 언어의 윈도우 사용자와의 호환성을 위해서 zip 압축을 하려면 외국 윈도우에서 압축시 사용하는 코드페이지를 아래 목록에서 참고 후'CP949'대신 원하는 윈도우 코드페이지를 골라서 압축하면 됩니다. 목록은 택스트박스에 풍선 도움말로 나타납니다. 그리고 지정한 코드페이지로 변경이 되지 않는 문자는 유니코드로 저장이 됩니다.윈도우 기본 압축 프로그램과 같은 유니코드를 지원하지 못하는 압축 프로그램으로 열어보면 유니코드로 저장된 파일을 제외하고는 보이게 됩니다. 7zip은 유니코드를 기본적으로 사용하기 때문에 그런 고민을 하지 않아도 되므로 여러 언어를 동시에 압축하기 위해서는 zip대신 7zip을 이용하기를 추천합니다.

 참고사항으로 zip의 분할압축은 pkzip의 Application note의 split 표준 권고안을 구현하는 압축 프로그램(Winzip, v3zip등)에서만 압축해제가 됩니다. 그리고 프로그램의 인코딩을 지정하는 곳에는 드랍박스에 나타나는 목록 이외에도 실제 iconv 에서 지정가능한 인코딩명이면 아무것이나 가능합니다.

다른 추천 프로그램으로 마우스 오른쪽 버튼을 눌러서 기본 압축 프로그램처럼 사용을 하려면 FinderPop 을 추천합니다. 스노우 레퍼드 사용자를 위해서 서비스 메뉴를 통한 압축을 할 수 있게 만들어 놓았습니다. 그리고 이 프로그램은 압축만 하기 때문에 압축해제는 The Unarchiver를 추천하며 압축 파일의 손상복구를 위한 정보 생성을 위해서는  MacPAR deluxe 를 추천합니다.

  • CP437 - 영어
  • CP737 - 그리스어
  • CP775 - 발트어
  • CP850 - Multlingual 라틴문자 I
  • CP852 - 라틴문자 II
  • CP855 - 키릴어
  • CP857 - 터키어
  • CP858 - Multlingual 라틴문자 I + Euro symbol
  • CP860 - 포르투갈어
  • CP861 - 아이슬란드어
  • CP862 - 히브리어
  • CP863 - 프랑스어(캐나다)
  • CP864 - 아랍어
  • CP865 - 북유럽어
  • CP866 - 러시아어
  • CP869 - 현대 그리스어 
  • CP874 - 태국어
  • CP932 - 일본어, Shift-JIS와 비슷함
  • CP936 - 간화자 중국어(중국, 싱가폴)
  • CP949 - 한국어
  • CP950 - 정체자 중국어(대만, 홍콩)

P.S.
 좀 더 섬세한 설정을 하시기 원하는 분은 '추가 압축 옵션'에 압축 프로그램별 커맨드라인 옵션을 스페이스를 띄워서 넣어주시면 됩니다. 가령 7zip의 solid 압축을 해제하려면 '-ms=off' 옵션을, 멀티코어를 이용해 압축시간을 많이 줄일 수 있는 LZMA2알고리즘을 사용하려면 '-m0=LZMA2' 옵션을 주면 됩니다. 이외에도 파워유저들의 사용을 위해 나머지 옵션은 내장된 압축프로그램에 -h 옵션을 주고 터미널에서 살펴보거나 info-zip , 7zip 홈페이지에 있는 온라인 매뉴얼을 참고하세요.

 zip에 인코딩 문제를 지원하기위해 추가한 옵션으로는 -EN=? 과 -UN=NFC 가 있고 7za에는 -nfc 옵션이 있습니다. -EN=? 는 압축시 파일명을 물음표에 적은 윈도우 코드페이지로 변환해서 압축합니다. -UN=NFC 는 유니코드 파일명을 유지하기는 하되 맥 이외의 운영체제에서 주로 사용하는 NFC로 정규화해서 저장합니다. 7zip의 -nfc 도 zip의 -UN=NFC 와 동일한 역할을 합니다.

 ClealArchive 프로그램 안에 zip과 7za 커맨드라인 유틸리티가 들어있습니다. 인코딩 처리 패치가 모든 기능에 구현이 된 것이 아니기 때문에 새로 압축을 할 때만 압축이 잘 되고 기존의 압축한 파일을 업데이트하거나 삭제등의 기능을 사용하면 제대로 작동되지 않을수 있습니다. 그래서 내부에 있는 커맨드라인 툴을 따로 빼서 사용하시려는 분은 이점을 꼭 참고하시기 바랍니다. info-zip , 7zip 개발자에게 인코딩변경에 대한 수정의견을 전달했지만 그리 좋은 답변이 오지 않아서 fork를 하게 되었습니다. rar개발자에게도 전달했으나 중요한 사항이라고 생각하지는 않아서 언제 공식 지원이 될지는 미지수 입니다.

 7za에 대한 한가지 참고사항으로 터미널에서 압축 대상파일을 전달할 때 한글과 같은 풀어쓰기가 되는 유니코드 파일명을 전달하면 파일을 찾지 못합니다. 이는 CleanArchiver가 호출할때는 풀어쓰기(NFD)형식으로 파일명이 전달되지만 터미널에서 사용자가 언어 입력기로 입력한 문자열은 NFC형식이기 때문입니다. 

위 프로그램을 만드는데 사용한 오픈소스들은 아래와 같습니다.
  1. CleanArchiver
  2. Info-zip
  3. p7zip
  4. Apple's CFUniCharPrecompose() , vfs_utfconv.c (실제 파일은 Open Darwin의 xnu 패키지에서 받을 수 있습니다.)
  5. libiconv
수정한 소스들을 올리려니 온라인 리파지토리가 없어서 요청하면 모두 올려드리겠습니다. : )

<업데이트 내역>
2009.09.22
zip에서 암호를 지정해도 압축되지 않던 경우를 제대로 작동하게 수정했습니다.
zip 분할압축시 압축자체가 실행되지 않던 문제를 해결했습니다.
rar 압축형식을 추가했습니다. ( 단 윈도우/리눅스 호환 파일명 지원은 지원하지 않습니다.)

2009.09.23
외국 사용자를 고려해 윈도우 호환 파일명 사용 옵션에 인코딩을 지정할 수 있게 택스트 필드를 추가했습니다.

2009.10.22
압축 포멧별 설정 상태를 저장해서 사용가능합니다.
압축이 끝나면 Growl로 결과를 알려줍니다.
업데이트를 자동으로 할 수 있게 Spakle을 추가했습니다.
( 하지만 아직 구글코드나 소스포지에 올리지 않아서 작동되지는 않습니다.)
zip 포멧으로 윈도우 호환 파일명 압축시 지정한 인코딩으로 변경되지 않으면 해당 파일명을 유니코드로 저장해줍니다.
( 이렇게 압축된 파일의 경우 Winzip, 7zip, winrar, v3zip 에서 잘 풀립니다. 단 v3zip는 U+10000의 유니코드 글자를 표준 UTF-8로 처리하지 않아서 제대로 풀어주지 못합니다. 99.99% 사용하지 않는 글자들이니 평소 사용에는 지장이 없을껍니다. 안랩에는 버그리포트를 한 상태입니다.)

2009.10.30
CleanArchiver 원 개발자이신 INAJIMA Daisuke님과 연락이 되어서 지금까지 수정한 내용을 모두 원래 공식 CleanArchiver 프로젝트에 전달했습니다.

2009.11.22 버전 3.0b1
서비스 메뉴를 통한 압축을 할 수 있게 했습니다.
실행을 위해 요구되는 OS X의 최소 버전을 10.4로 수정했습니다.  Intel, PPC에서 모두 실행됩니다.
편의를 위한 메뉴와 일부 옵션이름을 수정하였습니다.
원 개발자분의 업데이트 링크를 사용하여 나중에 업데이트를 자동으로 할 수 있게 해놓았습니다.
(단 윈 개발자분과 제가 만든 프로그램의 기능 차이가 있습니다.)

2009.12.07 버전 3.1b2
압축 프로그램의 32 & 64bit를 구분해 실행합니다. 64비트로 압축시 20%정도 성능향상이 있습니다.
일부 압축 형식에서 파일이름 암호화, 솔리드압축 등의 옵션이 추가되었습니다.
dmg파일의 암호지정, 압축률 지정이 가능합니다.
분할압축, zip에서 인코딩지정 메뉴가 바뀌었습니다.
Posted by trip2me
,
애플포럼에 WebDAV를 사용함에 있어서 애로사항에 대한 글을 보고 요즘 관심사이기에 문제를 해결하는 패치를 만들어 올려 봅니다.

WebDAV( Web-based Distributed Authoring and Versioning) (웹기반 분산형 저작 및 버전관리)는 기존의 HTTP프로토콜을 확장해서 웹서버에 있는 파일을 관리(목록 조회, 수정, 삭제, 이동 등)할 수 있게 하는 확장된 프로토콜 셋입니다. Apache웹서버에서도 이 기능을 mod_dav란 확장 모듈을 통해서 지원합니다. 자세한 소개는 커피닉스님의 소개글과 한컴사의 남동선님글을 참고하세요

OS X에서 항상 한글등의 풀어쓰기로 표현이 되는 문자들에서 문제가 되는 Unicode Normalization이 여기에서도 관심사가 됩니다.

만약 OS X에다 아파치 웹서버를 운영하고 mod_dav를 사용하면 결국 접속하는 클라이언트들은 애플에서만 유일하다시피 사용중인 NFD(Normalization Form Decomposed)(풀어쓰기로 최대한 나타내는 형태)로 표현된 유니코드 UTF-8 문자열을 보게 됩니다. 그렇게 되면 NFD를 제대로 표시하지 못하는 운영체제나 WebDAV클라이언트에서는 한글이나 기타 풀어쓰기 문자들이 죄다 망가져 보이거나 풀어헤쳐져 보이게 됩니다. 여기에서만 문제가 있는게 아니라 이 파일을 자신의 컴퓨터에 복사하면 한 폴더에 같은 이름을 가지는 두개의 파일이 생길 수도 있습니다.( 같은 글자이지만 풀어쓰기 모아쓰기된 유니코드의 섞임때문에 )

사실 유니코드 영역에 풀어쓰기와 모아쓰기글자영역이 모두 있는 언어의 경우에 이들(완성된글자 '한' = 초성ㅎ+중성ㅏ+종성ㄴ) 사이를 같은 글자로 볼 것인가 다른 글자로 볼 것인가에 대해서 Unicode consortium과 국제 표준을 규정하는 ISO/IEC 간에 의견차이가 있다고 하던데 정확히는 모르겠네요. 하지만 실제적으로 사용상에 다르게 본다면 앞문단 끝부분에 적었듯이 문제꺼리가 됩니다.

애플에서도 이런 사항에 대해 몇가지 관련 링크가 있습니다.그 중 하나인 커널레벨에서 인코딩 변환을 위한 자료인Text Encodings in VFS를 가지고 위 문제를 해결했습니다. 추가로 맥에서 제공하는 iconv에서도 자신들의 풀어쓰기 인코딩을 'UTF-8-MAC'이라는 이상야릇한 비공식적인 이름으로 지원합니다. 마찬가지로 여기서도 위 링크의 커널레벨 변환을 이용하여서 구현했더군요. 현재 위 링크의 vfs_utfconv.c란 소스코드는 받을 수 없는데 다행히 공개된 OS X의 xnu소스코드안에 찾아보면 파일이 있습니다. 실제 구현은 HFS+에서 사용하는 인코딩 표를 그대로 배열로 만들어서 1:1변환합니다.

본론으로 돌아와서 패치를 어떻게 한 것인지에 대한 내역을 적습니다. 먼저 아래 그림을 보면 mod_dav와 mod_encoding의 메시지 흐름을 볼 수 있습니다.
mod_dav layer

WebDAV표준에 근거해 mod_dav가 UTF-8 인코딩으로 파일명을 보네달라는 요청에도 로컬 인코딩으로 응답하는 클라이언트의 문제 해결을 위해서 일본에서 mod_enconding 모듈이 만들어 졌습니다. 모듈을 올리면 mod_dav가 파일생성등의 요청을 받기전 먼저 가로채서 클라이언트의 로컬 인코딩을 UTF-8로 바꾸어 전달해주는 방식입니다. 하지만 반대의 상황, 즉 그림에서 역시나 보이듯이 mod_dav가 클라이언트에게 파일이름을 전달하는 경우에는 mod_encoding이 작동하지 않습니다. 그래서 이것을 해결하기 위해서 mod_encoding에서 받아들인 요청에 대한 클라이언트 인코딩 설정을 기록하고 이를 mod_dav에 전달해서 mod_dav가 응답을 할 때 제대로 인코딩을 맞추어 주도록 패치를 만들었습니다.

바꾼 내용은 많지 않습니다. 일본에서 맥용으로 만든 패치가 있는데 이것을 기본으로 해서 단순히 NFD -> NFC로만 바꾸는게 아니라 mod_encoding에서 설정한 인코딩으로 다시 변경을 하여 보내도록 요청된 페이지 정보에 추가 인코딩 정보를 넣어서 mod_dav모듈에서 인코딩이 무엇인지 알 수 있게 만들어 vfs_utfconv.c 혹은 libiconv로 인코딩을 바꾸어 주게 만들었습니다. 그렇게 되면 httpd.conf의 mod_encoding.c 에서 설정한 클라이언트별 인코딩 변경이 서버->클라이언트로도 적용 됩니다. 그러면 표준을 따르지 않던 클라이언트에서도 제대로 파일명을 보고 파일을 만들 수 있습니다.

애플포럼에 첨부파일 용량이 작아서 이곳에 백업 및 좀 더 자유스러운 다운로드가 되게 하기 위해 올립니다. 아무래도 모듈 업그레이드가 되면 업데이트 되어야 하므로 소스의 변경 부분만 diff로 만들어서 나중 적용이 쉽게 해 놓았습니다.

소스코드는 mod_encoding 사이트와 애플의 공개 소스코드 사이트에서 받아 왔습니다. 수정이 필요하다면 소스쪽의 라이센스에 따라 자유롭게 사용하시면 됩니다.

같이 첨부한 모듈 바이너리는 10.5.8에서 컴파일한 유니버설 바이너리 모듈입니다. /usr/libexec/apache2에 mod_dav.so, mod_encoding.so 파일을 넣고 httpd.conf 설정을 아래 예제와 비슷하게 해 주면 됩니다.



/etc/apache2/httpd.conf... # 모듈 로드 설정부 LoadModule dav_module libexec/apache2/mod_dav.so LoadModule encoding_module libexec/apache2/mod_encoding.so ... # mod_encoding 옵션 설정부분 <IfModule mod_encoding.c> EncodingEngine on # 인코딩 변경 활성화 여부 SetServerEncoding UTF-8 # 기본 서버측 인코딩 NormalizeUsername on #윈도우처럼 '워크그룹\아이디'형식의 사용자명을 아이디만 걸러줍니다. DefaultClientEncoding UTF-8 CP949 # 아래에 클라이언트별 인코딩 설정이 없는 경우 기본 인코딩을 적용할 값 # AddClientEncoding "UserAgent를 매칭할 문자열 정규식" "하나이상의 여러 시도할 인코딩" AddClientEncoding "Microsoft-WebDAV*" UTF-8 CP949 # MS Windows XP AddClientEncoding "RMA/*" CP949 # RealPlayer AddClientEncoding "DataFreeway/.*" CP949 # datafree client AddClientEncoding "WebDAVFS/*" UTF-8-MAC # OS X 인코딩 변환을 무시할 것은 이렇게 인코딩을 지정해도 됩니다. </IfModule> ...


추가로 UTF-8-MAC 인코딩을 다룰 수 있게 패치한 리눅스에서 컴파일되는 libiconv도 함께 올립니다. 단 libiconv의 중간 변형단계를 거치는 특성상 유니코드 Surrogate pair의 변환이 되지 않으므로 U+10000 이상의 문자를 변환시도시 실패하게 됩니다.
Posted by trip2me
,
디스크 이미징 프로그램을 받아서 빌드하던 중 아래와 같은 에러가 났다.

ld_classic: can't locate file for: -lcrt0.o

즉 crt0.o를 찾지 못한다는 이야기인데 구글링해 보니 Apple Developer문서에 있는 내용이었다.

결론은 애플에서는 static링킹을 지원하지 않고 있으므로 가급적 dynamic linking을 사용하여 crt1.o를 링크하라는 내용이었다. 결국 그래서 Makefile에 있는 -static 옵션을 제거하고 동적으로 링킹해서 빌드를 했다.

그리고 반드시 static linking이 필요한 경우라면 Open Darwin에서 Csu 라는 모듈을 다운받아서 빌드후 crt0.o 를 사용하라고 한다. 단 이 모듈은 업데이트가 되지 않으므로 릴리즈 업데이트시 수동으로 빌드를 해 주어야 하는 단점이 있다.


다운받은 Csu module을 빌드할 때
export RC_ARCHS="ppc i386 ppc64 x86_64"
식으로 지정 후 make하면 원래 /usr/lib에 있던 기존 crt1.o와 같은 4가지 아키텍쳐를 지원하게 빌드 가능하다.

10.5.6에서 빌드한 Csu-75 결과물을 첨부파일로 올린다. tarball을 풀어서 crt0.o를 /usr/lib 에 집어넣고 빌드해 주거나 static 빌드하는 패키지에서 적당히 파일 링크를 추가하면 된다.
Posted by trip2me
,
모니터 캘리브레이션 장비가 없는 나로서는 눈을 이용해서 그나마 모니터가 색을 잘 표현하게 설정을 해 줄 수밖에 없다.

맥에서는 캘리브레이션 마법사가 있지만 조금 부족해서 Berg Design사의 Supercal을 이용해서 세밀한 보정을 할 수 있다. 물론 자신의 눈으로 모든 설정을 한다. 조금 힘이 들긴 하지만 세세한 설정으로 꽤나 만족스러운 결과를 볼 수 있다.

첨부파일은 Supercal로 내가 설정한 X61T의 모니터인 HV121P01의 컬러 프로파일이다.



그런데 쭉 맥을 쓰다가 윈도우로 가끔 가면 이 프로파일이 적용되지 않아서 사진을 보거나 웹사이트를 갈 때 색감이 맞지 않아서 불편할때가 많다. 그래서 이리저리 웹서치를 한 결과 northlight-images라는 사이트에서 소개한 Monitor Calibration Wizard라는 무료 프로그램을 소개 받았다. 프로그램을 설치하고 Supercal보다는 덜 세세한 설정을 하긴 했지만 결과 보정 후 나은 색상을 볼 수 있었다. 조금 아쉬운 점이라면 Gamma수치에 대해서 쉽게 캘빈 온도단위로 설정을 알려주면 좋은데 단지 상대적인 수치로 밝기 조절을 해서 그게 어려웠다. 그리고 컬러 프로파일을 적용하기 위해서 항상 윈도우 실행시마다 해당 프로그램을 실행해 주어야 한다는 단점이 있다. 물론 조그마한 프로그램이라서 부담을 주지는 않는다.

그리고 두 프로그램을 올려본다.


P.S. 좀 더 자세한 캘리브레이션에 대한 내용은 Norman Koren의 사이트를 참고하면 된다.
Posted by trip2me
,