이것은 문서의 이전 버전입니다!
마이크로소프트와 주식회사아스키가 합작해서 만든 일본어 문자 인코딩. JIS X 0201 및 JIS X 0208 문자 집합을 지원하는 인코딩이지만, 그 모양새나 쓰임새나 여러 모로 문제가 많은(…) 인코딩이다. 그럼에도 불구하고 마이크로소프트 윈도의 기본 인코딩이었기 때문에(정확히는, Windows-31J의 형태로) UTF-8이 나올 때까지는 매우 널리 쓰였다.
1982년 발표 당시에는 표준화 과정을 거치지 않은 사실상의표준(de facto standard)이었으나, 1997년 이후로 JIS X 0208 부속서 1에 "시프트 인코딩"이라는 이름으로 기술되면서 정식으로 표준화되었다. 상용조합형의 표준화 과정을 생각해 보면 비슷할 듯.
Shift_JIS의 등장에는 슬픈 전설이 있다. 나는 전설 따위는 믿지 않아 본래 일본은 문자 전산화를 처음 할 때(무려 1960년대)만 해도 2바이트 인코딩을 위한 체계가 전혀 마련되어 있지 않았기 때문에 가타카나만을 1바이트 인코딩으로 넣어 버리게 되는데, 이게 바로 JIS X 0201(당시에는 JIS C 6220)이다.1) 그런데 나중에 2바이트 인코딩으로 히라가나, 가타카나 및 칸지를 모두 담은 JIS X 0208(당시에는 JIS X 6226)이 나오는데, 본래의 의도대로라면 JIS X 0208은 JIS X 0201을 "대체"하는 표준이 되었어야 했지만 기존에 작성된 문서가 전혀 호환되지 않는 심각한 문제가 발생하고 만다. 게다가 JIS X 0208은 흔히 볼 수 있는 94x94 문자 집합임에도 불구하고 JIS X 0201이 이미 GR 영역(0xA0~0xFF)을 일부 사용하고 있어서 간단하게 붙여 넣을 수가 없었다. (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(0x80~0x9F) 및 GL(0x20~0x7F) 영역 대부분을 함께 써야 했는데, 물론 온갖 문제가 일어나게 된다. 십수년 뒤에 나온 Windows-949에서도 사실상 같은 접근이 쓰이긴 했지만, Shift_JIS에서 엄청나게 데인 마이크로소프트는 두번째 바이트의 범위를 잘 조정하여 호환성 문제를 상당수 피해 갔다.
이런 혼란은 기본적으로는 일본이 한중일 삼국 중 문자 전산화를 가장 먼저 시작했기 때문에 벌어진 것이지만, 결과적으로는 후술할 문제들 때문에 널리 쓰이긴 해도 완벽하게 다른 모든 인코딩을 대체할 수는 없었다. Shift_JIS는 DOS V 및 마이크로소프트 윈도에서, EUC-JP는 유닉스 계열 운영체제에서, 그리고 ISO-2022-JP는 플랫폼 독립적인 상황(HTML 및 MIME)에서 오랫동안 널리 쓰였다. 또한 마이크로소프트는 한중일 문자 인코딩을 모두 자체적으로 재정의했음에도 불구하고 일본어 인코딩만큼은 다른 회사와 보조를 맞출 수 밖에 없었다(게다가 인코딩 설계에 결정적인 역할도 담당하지 못 했다).
JIS X 0201이 할당하고 있던 GR 영역 바이트는 A1
부터 DF
까지로, Shift_JIS의 첫 바이트는 이 영역을 피하여 할당되어 있다. 즉:
81
을 첫 바이트로,82
를 첫 바이트로,9F
를 첫 바이트로,E0
을 첫 바이트로,EF
를 첫 바이트로 한다.Shift_JIS의 둘째 바이트는 JIS X 0208에서 두 행에 속하는 188개의 문자를 적절히 쪼개서 할당되어 있다. 즉:
40
부터 7E
까지를 둘째 바이트로,80
부터 9E
까지를 둘째 바이트로,9F
부터 FC
까지를 둘째 바이트로 한다.
…이걸로 설명이 끝나면 참 좋을텐데, 현실은 그렇지 않다. Shift_JIS에는 확장의 여지가 두 군데 남아 있는데, 일단 JIS X 0208에서 할당되지 않고 남아 있는 영역들(9~15행 및 85~94행)이 있고 Shift_JIS에서 첫 바이트로 사용하지 않는 F0
부터 FF
까지의 영역들이 있다. 후자의 경우 JIS X 0208을 95행 이후로 확장했을 경우를 상정해서 95~126행이라고 부르기도 한다. 이 남아 있는 공간들이 워낙 큰데다가, 일본어의 경우 기존 인코딩으로 표현이 불가능한 가이지(外字)의 수요가 높기 때문에 똑같은 Shift_JIS를 쓴다 하더라도 확장된 문자들에 따라서 인코딩이 달라지는 경우가 흔하다. 다음은 Shift_JIS의 주요 확장들과 확장된 문자들의 목록이다:
80
, A0
, FD
~FF
에 문자가 더 추가되었다.여기서 볼 수 있듯이, 똑같은 Shift_JIS라 하더라도 확장에 대해서는 완전히 다른 결과가 나올 수 있다.3)
확장 영역으로 인한 호환성은 둘째치고라도, Shift_JIS는 특히 문자열 처리에 매우 취약하다. 여타 다른 멀티바이트 문자 인코딩이라고 안 그렇다는 건 아니지만 이 쪽은 그 정도가 특히 심하다. 예를 들어서:
\
(0x5c)가 보통 문자열 \
말고 바이트열 속에 5C
가 들어갈 경우 단순한 바이트 비교로는 감지를 할 수 없게 된다. 일본어 윈도에서 압축한 ZIP 파일 열어 보면 이게 뭔 소린지 알 수 있게 된다.세번째 문제는 너무 궤멸적인 까닭에 압축 해제 소프트웨어들이 웬만해서는 ZIP 파일의 인코딩을 사용자가 선택할 수 있게 하는데 큰 역할을 했다. 어찌 보면 잘 된 걸수도 있다(…). Windows-949 인코딩은 여기에서 뼈저린 교훈을 얻고 좀 더 정상적인 설계를 사용하였다.