Resistance things (나무위키 퍼가기 금지)

재패니메이션 자막을 보면서 화날 수 밖에 없는 이유 본문

유니코드

재패니메이션 자막을 보면서 화날 수 밖에 없는 이유

Hurss 2011. 3. 9. 01:44
728x90
(이 글은 예전에 있던 블로그에 기재하였으나, 실수로 글을 삭제하는 바람에 캐시에서 제목을 바꾸어 복원한 것임. 올린 날짜는 2009년 7월 25일)

인터넷에서 재패니메이션 등을 볼 때면 대다수 사람들은 자막에 의존하면서

애니메이션을 즐길 것입니다.

이러한 자막은 사실상 애니메이션의 필수 요소가 되었는데요,

 

유감스럽게도 유니코드 5.1까지 나온 현재까지도

자막 인코딩을 유니코드 부호화 형식 UTF-8이나 UTF-16 등이 아닌

EUC-KR (또는 CP949로도 부름)에 지나치게 의존하고 있다는 점

몹시나 안타깝습니다.

 

정말이지 방금 전에 인터넷을 돌아다니다가

어느 재패니메이션 자막에 일본어 한자가 아닌 한국에서 쓰이는

한자가 쓰여 있어 몹시 신경쓰이는 바람에 포스팅을 남기게 되었습니다.

 

한국식 한자도 과거에 일본에서는 자주 쓰이기는 했죠.

일본은 1945년 이후 한자 사용을 편하게 하기 위해

상용한자 1945자를 제정하였고, 그 이후 오늘날까지도 일본식 한자를 유지하면서

사용하고 있습니다.

 

그런 도중 일본에서 쓰이는 일부 약자들은 이상하게도

한국에서는 전혀 인식을 할 수 없습니다.

그 이유는 한국은 KS X 1001을 사용하는 반면, 일본은 Shift-JIS를 기본 코드로 사용하고 있기 때문인데,

Shift-JIS의 문자들(히라가나, 카타카나, 상용한자)을 KS X 1001에 대입해 보면

KS X 1001에서 표현이 불가능한 한글들(뷁, 햏 등)이 있는 영역에 자리잡고 있습니다.

그래서 그 이후 한국에서도 일부 약자를 KSC 5607로 조금 보완하기는 했지만,

오히려 맞지 않는 한자들은 여전히 많습니다.

 

게다가 더욱 놀랄 만한 사실은

한자가 지원되는 대부분의 한글 폰트들은 KS X 1001에 실린 한자 수 4888자에 맞게만

한자 글리프(glyph)들이 디자인되어 있습니다.

여기서 왜 한자 얘기가 나오냐 하면,

유니코드에서는 '중일 통합 한자'라는 문자 세트를 만들어서

한국, 중국, 일본, 대만 등에서 쓰이는 한자들을 하나로 통합했습니다.

그래서 각 버전별로, 각 폰트나 국가 코드별로 한자에 대한 디자인이 미묘하게 다르기는 하지만,

(책받침 부수의 점 개수, 점의 생략 유무 등)

한국 한자도 입력면서 동시에 일본어 약자도 입력이 가능합니다.

 

그래서 애니메이션 자막(특히 재패니메이션 자막)을 제작 시에는

기본 코드 형식을 EUC-KR이 아닌 유니코드(혹은 UTF-8)로 제작한다면

한자의 대체나 깨짐의 위험 없이 표현이 가능할 것으로 보입니다.

 

하지만 유니코드로 대체한다고 해결될 문제가 아닌 게,

자막 만드는 프로그램도 문제가 많습니다.

한방에 등과 같은 자막 제작 프로그램 자체가

MFC에서 유니코드가 아닌 멀티바이트로 코딩 및 컴파일된 프로그램이기 때문에

유니코드에서 쓰이는 일본어 약자는 ?처럼 문자가 깨져 버립니다.

이것 역시 유니코드를 경시한 프로그램 제작자들이나 유니코드에 대한 인식이 적은 사람들 문제도 있겠지만

유니코드 지원 기능이 부족한 컴파일러 몫도 문제입니다.

 

대부분의 프로그램을 만들 때 컴파일러 저작 도구들은

MS(마이크로소프트)에서 만든 비주얼 스튜디오 6.0을 이용하는데,

학교에서 프로그램을 코딩하거나 회사에서 솔루션 등을 개발할 때 널리 쓰고 있습니다.

하지만 MS에서는 오래 전에 그 차기 버전들인 2003(닷넷), 2005, 2008을 내놓았고

현재는 비주얼 스튜디오 2010 베타 버전까지 내놓았습니다.

흔히들 비주얼 스튜디오 6.0이 다른 컴파일러들에 비해 컴파일 속도도 빠르다는 인식 때문에

그 이상의 버전을 사용하는 컴퓨터는 많지 않습니다. 그래서 그런지

자막 제작 프로그램들도 비주얼 스튜디오 6.0을 이용하여 멀티바이트 지원 상태에서 컴파일을 할 가능성이

높았다는 것이 제가 추측하는 바입니다.

(사실 비주얼 스튜디오 6.0에서도 유니코드 지원이 가능합니다.

컴파일 옵션에서 /MBCS 대신 /UNICODE로 대체하는 것으로 알고 있습니다.)

 

자막 파일들은 대게 *.smi (*.smil) 파일을 사용하고 있는데

이 파일 형식 구조가 은근히 html이나 xml과 비슷합니다.

메모장 등으로 자막 파일을 보면, 각 태그들이 동영상 파일의 밀리초(ms)마다 표시할

자막의 내용과 함께 한 부분을 구성합니다.

그런 부분들이 모여서 하나의 자막들을 이루며,

자막 제작자들은 앞부분의 <head></head> 부분에 고유의 헤더를 넣거나

주석을 첨부하는 경우도 있습니다.

그런데 smi파일을 그냥 만들 때에는 동영상의 싱크 및 해당 밀리초까지 계산하면서

자막을 만들어야 하는 무척이나 복잡하고 번거로운 면이 있기 때문에,

자막 제작자들은 자막 프로그램에 100% 의존하게 됩니다.

이 때문에 유니코드를 지원하지 않는 자막 프로그램 때문에

?로 표시되는 일본어 한자들 대신 어쩔 수 없이

한국 한자들을 집어넣거나 히라가나로 표시하게 되는 거죠.

 

하지만 심각한 점은 OS 차원에서 보는 자막 파일 문제입니다.

대부분 사람들이 자막 딸린 동영상을 볼 때는

대부분 윈도를 사용하는데,

리눅스도 동영상 및 자막에 관한 기술들이 나날이 발전하여

자막 딸린 동영상을 코덱만 설치하면 볼 수 있습니다.

제가 사용하는 리눅스 종류 중 하나인 우분투 9.04를 예로 들면,

기본 인코딩을 아예 UTF-8로 설정했기 때문에

EUC-KR로 만들어진 자막 파일의 한글이

완전히 깨진 문자들(ISO 8859-1 영역의 문자들)로 나옵니다.

그래서 우분투 사용자들은 자막을 보기 위해서

우분투에서 쓰이는 동영상 플레이어인 Totem 플레이어에서

옵션에서 기본 코드를 EUC-KR로 지정하거나,

혹은 gedit나 OpenOffice의 워드 프로그램 등으로 UTF-8로 코드를 변환해서

자막을 봐야 합니다.

정말이지 이러한 과정들은 번거롭기 짝이 없는 거나 다름 없습니다.

 

이에 대한 해결책으로는 다음과 같습니다.

 

첫째, smi파일은 유니코드(UTF-8) 형식으로 저장하자.

둘째, 만약 자막 제작 프로그램 파일을 사용할 시, 일본어 한자를 써야 할 부분은

UTF-8로 저장된 smi파일 내에서, 일일이 해당 싱크 태그에서 편집해서라도 쓰자.

셋째, 윈도뿐만 아니라 리눅스 등의 타 OS까지 고려하여 자막을 만들자.

 

이상이 제가 말하고 싶은 요지이자, 많은 자막 제작자들한테 개인적, 주관적인 의견으로 권유하는 바입니다.

혹시나 이 글을 보고 공감하는 사람들이나,

이를 계기로 기존의 자막 구조를 바꾸었으면 하는 사람들이 생겼으면 좋겠습니다.
Comments