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
,