마이크로소프트와 주식회사 아스키가 합작해서 만든 일본어 문자 인코딩. JIS X 0201 및 JIS X 0208 문자 집합을 지원하는 인코딩이지만, 그 모양새나 쓰임새나 여러 모로 문제가 많은(…) 인코딩이다. 그럼에도 불구하고 마이크로소프트 윈도의 기본 인코딩이었기 때문에(정확히는, Windows-31J의 형태로) UTF-8이 나올 때까지는 매우 널리 쓰였다.

1982년 발표 당시에는 표준화 과정을 거치지 않은 사실상의 표준(de facto standard)이었으나, 1997년 이후로 JIS X 0208 부속서 1에 “시프트 인코딩”이라는 이름으로 기술되면서 정식으로 표준화되었다. 상용 조합형의 표준화 과정을 생각해 보면 비슷할 듯.

1 배경

Shift_JIS의 등장에는 슬픈 전설이 있다. 나는 전설 따위는 믿지 않아 본래 일본은 문자 전산화를 처음 할 때(무려 1960년대)만 해도 2바이트 인코딩을 위한 체계가 전혀 마련되어 있지 않았기 때문에 가타카나만을 1바이트 인코딩으로 넣어 버리게 되는데, 이게 바로 JIS X 0201(당시에는 JIS C 6220)이다.[1] 그런데 나중에 2바이트 인코딩으로 히라가나, 가타카나 및 칸지를 모두 담은 JIS X 0208(당시에는 JIS C 6226)이 나오는데, 본래의 의도대로라면 JIS X 0208은 JIS X 0201을 “대체”하는 표준이 되었어야 했지만 기존에 작성된 문서가 전혀 호환되지 않는 심각한 문제가 발생하고 만다. 게다가 JIS X 0208은 흔히 볼 수 있는 94x94 문자 집합임에도 불구하고 JIS X 0201이 이미 GR 영역(A0–FF)을 일부 사용하고 있어서 간단하게 붙여 넣을 수가 없었다. (KS X 1001이 KS X 1003과 말끔하게 결합하여 EUC-KR이 되는 것과는 대조적이다.)

그래서 JIS X 0201에서 할당되지 않은 65개의 바이트를 첫 바이트로 하고, 둘째 바이트의 범위를 크게 늘려 잡아서 JIS X 0208을 인코딩하는 꼼수를 쓴 것이 바로 Shift_JIS이다. “시프트”라는 이름은 JIS X 0208의 행 번호를 1비트 오른쪽 시프트하여 첫 바이트를 정한 점에서 유래한다. 행 번호의 맨 아래 1비트는 열 번호에 합쳐서 두번째 바이트에 인코딩하는데, 이 때문에 두번째 바이트는 94×2 = 188개의 문자를 인코딩해야 했다. 이 때문에 GR 영역은 물론이고 CR(80–9F) 및 GL(20–7F) 영역 대부분을 함께 써야 했는데, 물론 온갖 문제가 일어나게 된다. 십수년 뒤에 나온 Windows-949에서도 사실상 같은 접근이 쓰이긴 했지만, Shift_JIS에서 엄청나게 데인 마이크로소프트는 두번째 바이트의 범위를 잘 조정하여 호환성 문제를 상당수 피해 갔다.

이런 혼란은 기본적으로는 일본이 한중일 삼국 중 문자 전산화를 가장 먼저 시작했기 때문에 벌어진 것이지만, 결과적으로는 후술할 문제들 때문에 널리 쓰이긴 해도 완벽하게 다른 모든 인코딩을 대체할 수는 없었다. Shift_JIS는 DOS V 및 마이크로소프트 윈도에서, EUC-JP는 유닉스 계열 운영체제에서, 그리고 ISO-2022-JP는 플랫폼 독립적인 상황(HTML 및 MIME)에서 오랫동안 널리 쓰였다. 또한 마이크로소프트는 한중일 문자 인코딩을 모두 자체적으로 재정의했음에도 불구하고 일본어 인코딩만큼은 다른 회사와 보조를 맞출 수 밖에 없었다(게다가 인코딩 설계에 결정적인 역할도 담당하지 못 했다).

2 구조

JIS X 0201이 할당하고 있던 GR 영역 바이트는 A1부터 DF까지로, Shift_JIS의 첫 바이트는 이 영역을 피하여 할당되어 있다. 즉:

Shift_JIS의 둘째 바이트는 JIS X 0208에서 두 행에 속하는 188개의 문자를 적절히 쪼개서 할당되어 있다. 즉:

…이걸로 설명이 끝나면 참 좋을텐데, 현실은 그렇지 않다. Shift_JIS에는 확장의 여지가 두 군데 남아 있는데, 일단 JIS X 0208에서 할당되지 않고 남아 있는 영역들(9–15행 및 85–94행)이 있고 Shift_JIS에서 첫 바이트로 사용하지 않는 F0부터 FF까지의 영역들이 있다. 후자의 경우 JIS X 0208을 95행 이후로 확장했을 경우를 상정해서 95–126행이라고 부르기도 한다. 이 남아 있는 공간들이 워낙 큰데다가, 일본어의 경우 기존 인코딩으로 표현이 불가능한 가이지(外字)의 수요가 높기 때문에 똑같은 Shift_JIS를 쓴다 하더라도 확장된 문자들에 따라서 인코딩이 달라지는 경우가 흔하다. 다음은 Shift_JIS의 주요 확장들과 확장된 문자들의 목록이다:

여기서 볼 수 있듯이, 똑같은 Shift_JIS라 하더라도 확장에 대해서는 완전히 다른 결과가 나올 수 있다.[3]

3 문제점

확장 영역으로 인한 호환성은 둘째치고라도, Shift_JIS는 특히 문자열 처리에 매우 취약하다. 여타 다른 멀티바이트 문자 인코딩이라고 안 그렇다는 건 아니지만 이 쪽은 그 정도가 특히 심하다. 예를 들어서:

세번째 문제는 너무 궤멸적인 까닭에 압축 해제 소프트웨어들이 웬만해서는 ZIP 파일의 인코딩을 사용자가 선택할 수 있게 하는데 큰 역할을 했다. 어찌 보면 잘 된 걸수도 있다(…). Windows-949 인코딩은 여기에서 뼈저린 교훈을 얻고 좀 더 정상적인 설계를 사용하였다.

4 같이 보기

1

사실 제2차 세계 대전 이전의 공식 문서에서는 가타카나가 현재의 히라가나의 자리를, 히라가나가 현재의 칸지의 자리를 차지하고 있었으며, 1980년대까지만 해도 전산화가 필요한 곳(전보 등)에서는 가타카나가 기본으로 쓰였다. 어쩌면 JIS X 0201의 설계자들은 GB 2312 및 GB/T 12345와 같이 똑같은 매핑에 히라가나와 가타카나만 다른 문자 집합을 구상했을 지도 모른다. ▲

2

실제로는 특수 문자는 NEC 특수 문자를 기준으로, 한자는 IBM 확장 한자를 기준으로 인코딩하고 나머지는 호환을 위해서만 유지한다. ▲

3

심지어 유니코드에 인코딩이 안 되어 있어서 유니코드 기반 글꼴로는 완벽한 지원이 불가능한 경우도 있다. MacJapanese가 그런 경우로, 오에스텐에 기본으로 들어 있는 ヒラギノ 계열의 글꼴이 이 이유로 일부 문자를 지원하지 않는다. 이게 무슨…. ▲