맨위로가기

Shift JIS

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

Shift JIS는 1980년대 이전에 주로 사용되던 JIS X 0201 인코딩을 확장하여 한자를 표현하기 위해 개발된 가변 길이 문자 인코딩 방식이다. JIS X 0201과의 호환성을 유지하면서 JIS X 0208에서 사용하지 않던 영역에 한자를 할당하는 방식을 사용했다. 개발에는 아스키, 마이크로소프트 등이 참여했으며, 1997년 일본 산업 규격에 부속서로 포함되었다. Shift JIS는 Windows-31J, MacJapanese 등 다양한 확장판을 가지고 있으며, 특히 Windows-31J는 가장 널리 사용되는 확장판이다. Shift JIS는 반각 문자와 전각 문자를 동일한 코드 체계로 표현할 수 있고 UTF-8보다 크기가 작다는 장점이 있지만, 문자의 구분 판정이 어렵고, JIS X 0212를 표현할 수 없으며, 0x5C(백슬래시) 문제와 같은 단점도 존재한다.

더 읽어볼만한 페이지

  • 일본어 컴퓨팅 - JIS X 0212
    JIS X 0212는 1990년 일본 규격 협회에서 발표한 정보 교환용 한자 부호 표준으로, JIS X 0208 문자 집합의 확장 및 적용 범위 부족을 해결하기 위해 6,067개의 문자를 지정하였으며, 유니코드 제정 시 원규격 중 하나로 사용되었으나 현재는 사실상 사장되었고 JIS X 0213에 통합되었다.
  • 일본어 컴퓨팅 - JIS X 0201
    JIS X 0201은 7비트 및 8비트 문자 집합을 포함하는 일본의 문자 인코딩 방식으로, ASCII 기반 로마자, 가타카나, 문장 부호로 구성되며, ASCII의 일부 문자가 엔화 기호나 윗줄로 대체된 특징을 가진다.
  • 문자 인코딩 - 유니코드
    유니코드는 세계의 모든 문자를 하나의 컴퓨터 인코딩 표준으로 통합하기 위해 설계되었으며, 유니코드 컨소시엄에 의해 관리되고 UTF-8, UTF-16, UTF-32 등의 부호화 형식을 제공하지만, 일부 문자 표현 문제, 버전 간 비호환성, 레거시 인코딩과의 호환성 문제 등의 과제를 안고 있다.
  • 문자 인코딩 - UTF-8
    UTF-8은 유니코드 문자를 표현하는 가변 길이 문자 인코딩 방식으로, ASCII 코드와 호환성을 유지하며 다양한 언어의 문자를 표현할 수 있도록 설계되었지만, 보안 문제점과 공간 효율성 측면에서 단점을 가진다.
Shift JIS
일반 정보
MIMEShift_JIS
다른 이름MS_Kanji, PCK
표준JIS X 0208:1997 부록 1
언어주로 일본어이지만 영어, 러시아어, 불가리아어, 그리스어도 지원
상태알 수 없음
이전알 수 없음
확장JIS X 0201 8비트 포맷
인코딩JIS X 0208
다음Shift_JIS-2004 (JIS), Windows-31J (웹; 매우 드물게 사용)
분류확장형 ISO 646, 가변 너비 인코딩, CJK 인코딩

2. 역사

1980년대 이전 일본 컴퓨터 환경에서 사용되던 JIS X 0201 기반 인코딩은 한자 표현에 한계가 있었다. 새로운 하드웨어 등장과 함께 한자 지원 필요성이 커졌으나, 기존 ISO/IEC 2022 방식으로는 하위 호환성 유지가 어려웠다. 이러한 문제를 해결하고 기존 인코딩과 호환성을 유지하며 JIS X 0208의 한자를 효율적으로 표현하기 위해 Shift_JIS가 개발되었다.

Shift_JIS 개발에는 아스키, 마이크로소프트, 미쓰비시 전기 등 여러 기업이 관여했다는 주장이 있으나[44], 마이크로소프트 등이 자사 제품에 이를 채택하면서 사실상 표준으로 빠르게 자리 잡았다.

초기 JIS X 0208과 Shift_JIS 자체에 미할당 영역이 존재하여, 이를 활용한 다양한 확장이 등장했다. 대표적인 예로 마이크로소프트의 코드 페이지 932(Windows-31J)가 있으며, 일부 휴대폰 업체들은 독자적인 그림 문자를 추가하기도 했다. 그러나 이러한 확장들은 상호 호환되지 않는 경우가 많고 IANA에 등록되지 않은 경우도 있어 혼란을 야기하기도 했다.

본래 일본 산업 규격(JIS)과 무관하게 만들어졌으나, 널리 사용됨에 따라 1997년 JIS X 0208 개정판 부속서 1에 '시프트 부호화 표현'(シフト符号化表現|시후토 후고카 효겐일본어)으로 공식 포함되었다. 이후 JIS X 0213 제정(2000년) 및 개정(2004년)에 맞춰 이를 지원하는 '''Shift_JISX0213'''과 '''Shift_JIS-2004'''가 정의되었다.

2. 1. Shift_JIS의 탄생 배경

1980년대 이전의 일본 컴퓨터 환경에서는 주로 JIS X 0201 기반의 인코딩이 사용되었다. 이 방식은 7비트 ASCII 문자와 함께 가타카나를 표현할 수 있었으나, 한자는 표현하지 못했다. 1980년대에 들어 PC용 16비트 CPU가 보급되고 한자, 히라가나, 가타카나를 표시할 수 있는 하드웨어가 등장하면서, 일본어를 온전히 표현할 수 있는 새로운 문자 인코딩 방식의 필요성이 커졌다.[44] 당시 일본어 표현에는 JIS X 0201의 8비트 부호(영숫자 및 반각 가나)와 JIS X 0208(한자)이 주로 사용되었다.

기존의 ISO/IEC 2022 표준에 따른 방식은 이스케이프 시퀀스를 사용하여 문자 집합을 전환해야 했지만, 이는 파일 크기를 늘리고 처리 시간을 지연시키는 단점이 있었다. 또한, 이미 JIS X 0201에서 8비트 부호 공간의 특정 영역(GL: 0x21-0x7E, GR: 0xA1-0xFE)을 영숫자와 반각 가나 표현에 사용하고 있었기 때문에, 이 방식으로는 기존 시스템과의 하위 호환성을 유지하면서 한자(JIS X 0208)를 효율적으로 통합하기 어려웠다.

이러한 문제를 해결하고, 이스케이프 시퀀스 없이 여러 문자 집합을 혼용하여 파일 크기를 줄이고 처리 속도를 높이기 위해 1982년 Shift_JIS가 개발되었다. Shift_JIS는 기존 JIS X 0201과의 호환성을 유지하면서 JIS X 0208 한자를 표현하기 위해, ISO 2022에서 사용하지 않던 영역과 기존 반각 가나 영역(GR) 중 미사용 부분을 활용했다. 구체적으로, 한자 표현의 첫 번째 바이트로는 ISO 2022에서 미사용이던 0x80-0x9F 영역과, 기존 GR 영역(0xA1-0xFE) 중 비어있던 0xE0-0xEF 영역을 사용했다. 두 번째 바이트에는 0x40-0x7E, 0x80-0xFC 범위의 값을 사용하여 JIS X 0208의 모든 문자를 표현할 수 있도록 설계했다. 이 과정에서 두 번째 바이트에 128(0x80)보다 작은 값을 사용하는 것이 불가피했다.

Shift_JIS를 개발한 주체에 대해서는 여러 주장이 있다. 마이크로소프트 일본 법인 전 회장인 후루카와 토오루( 古川享|일본어 )는 아스키, 마이크로소프트, 미쓰비시 전기, 마이크로소프트웨어 어소시에이츠, 디지털 리서치가 관련되었으며, 특히 아스키의 야마시타 료조( 山下良蔵|일본어 )가 중심 역할을 했다고 언급했다. 반면, 교토 대학의 야스오카 코이치( 安岡孝一|일본어 )는 초기에 마이크로소프트웨어 어소시에이츠와 미쓰비시 전기만이 개발에 참여했다고 주장했으나, 이후 야마시타 본인의 증언 등을 통해 자신의 주장을 일부 수정했다.[44] 개발 주체에 대한 논란과 별개로, 마이크로소프트를 비롯한 여러 기업이 자사 제품에 Shift_JIS를 빠르게 도입하면서 사실상의 표준으로 자리 잡게 되었다.

2. 2. 개발 주체 및 초기 구현

Shift_JIS를 개발한 주체에 대해서는 몇 가지 설이 있다. 일본 마이크로소프트 전 회장인 후루카와 토오루( 古川享|후루카와 토오루일본어 )에 따르면 아스키, 마이크로소프트, 미쓰비시 전기, 마이크로소프트웨어 어소시에이트, 디지털 리서치가 관련되었으며, 특히 아스키의 야마시타 료조( 山下良蔵|야마시타 료조일본어 )가 중심이 되어 만들어졌다고 한다. 반면 교토 대학 조교수인 야스오카 코이치( 安岡孝一|야스오카 코이치일본어 )는 마이크로소프트웨어 어소시에이트와 미쓰비시 전기만이 관련되었다고 주장한다.[44] 개발 주체가 누구인지와는 별개로, 마이크로소프트를 비롯한 여러 회사들이 초기부터 자신들의 제품에서 Shift_JIS를 지원했던 것은 사실이다.

Shift_JIS는 마이크로소프트의 MS-DOS에서 "MS 한자 코드"(이후 Microsoft 코드 페이지 932)라는 이름으로, 디지털 리서치의 CP/M-86에서는 "SJC-26"이라는 이름으로 채택되었다. 이 두 시스템의 Shift_JIS 구현은 거의 동일했지만, 전각 공백을 처리하는 방식에 차이가 있었다. MS-DOS는 전각 공백에 `0x8140`이라는 고유한 코드를 할당한 반면, CP/M-86은 반각 공백 두 개와 동일하게 `0x2020`으로 처리했다.

CP/M-86 방식은 문자열에서 공백을 검색하는 프로그래밍 처리가 간단해지는 장점이 있었다. 반면 MS-DOS 방식은 전각 공백에 별도의 코드를 부여함으로써, 사용자가 반각 입력 모드에서 스페이스바를 두 번 눌렀는지, 아니면 전각 입력 모드에서 스페이스바를 한 번 눌렀는지를 프로그램이 구별할 수 있게 했다. 이는 당시 Multiplan과 같은 일부 응용 소프트웨어에서 메뉴 선택에 스페이스바를 사용했기 때문에 필요했던 기능이다. 또한, 프린터에 따라 전각 공백과 반각 공백의 폭 비율이 정확히 2:1이 아닌 경우가 있어, 공백을 구분하는 것이 장표 설계에도 영향을 미쳤다.[34]

2. 3. 표준화 과정

Shift_JIS는 본래 ISO/IEC 2022의 표준적인 부호화 방식을 따르지 않고 특정 업체(벤더)들이 독자적으로 구현한 인코딩 방식이었다. 초기에는 공식적인 일본 산업 규격(JIS)과 관련 없이 만들어졌으나, 마이크로소프트 윈도우를 비롯한 여러 시스템에서 널리 채택되면서 사실상의 표준으로 자리 잡게 되었다.

이러한 광범위한 사용을 반영하여, 1997년에 개정된 JIS X 0208 표준에서는 부속서 1에 '시프트 부호화 표현'(シフト符号化表現|시후토 후고카 효겐일본어)이라는 이름으로 Shift_JIS의 사양을 공식적으로 포함시켰다. 또한 IANA에도 "Shift_JIS"라는 명칭으로 등록되어 인터넷 환경에서의 식별자로 사용되게 되었다.

이후 JIS X 0208의 확장 규격인 JIS X 0213이 2000년에 제정되면서, 이를 지원하기 위한 상위 호환 사양으로 '''Shift_JISX0213'''이 정의되었다. 2004년에는 JIS X 0213이 개정됨에 따라 이 사양의 명칭도 '''Shift_JIS-2004'''로 변경되었다.

한편, Shift_JIS에는 여러 확장판이 존재하는데, 가장 널리 사용되는 것은 마이크로소프트의 코드 페이지 932(윈도우-31J)이다. 이 확장판은 IANA에 "Windows-31J"라는 별도의 이름으로 등록되어 있다.[8] W3C와 WHATWG가 정의하는 HTML5 등의 웹 표준 인코딩에서는 이 Windows-31J를 실질적인 Shift_JIS 구현으로 간주하며, "shift_jis"라는 레이블을 "windows-31j"와 상호 교환 가능한 것으로 취급한다.[16][17]

비록 Shift_JIS 자체에 대한 공식적인 업데이트는 중단되었지만, 일본어 윈도우 환경에서 오랫동안 기본 인코딩으로 사용되어 왔기 때문에 여전히 많은 시스템과 데이터에서 사용되고 있다. 그러나 여러 기술적인 문제점과 유니코드의 보급으로 인해 점차 유니코드로 전환하려는 움직임이 나타나고 있다.

3. 구성

Shift_JIS는 1바이트 문자 집합인 JIS X 0201을 기반으로, 사용되지 않는 코드 영역에 2바이트 문자 집합인 JIS X 0208을 배치하는 방식으로 구성된다. 이는 JIS X 0201의 1바이트 코드(0x00~0x7F의 ASCII 유사 영역, 0xA1~0xDF의 반각 가타카나 영역)를 그대로 사용하면서, 비어있는 바이트 값(0x81~0x9F, 0xE0~0xEF)을 2바이트 문자의 첫 번째 바이트(선행 바이트)로 활용한다.

2바이트 문자의 두 번째 바이트(후행 바이트)는 0x40~0x7E 또는 0x80~0xFC 범위의 값을 가진다. 이 할당 방식은 JIS X 0208의 구점 번호를 특정 계산 규칙에 따라 변환하여 Shift_JIS 코드 값으로 매핑한다.

이 구조 때문에 몇 가지 특징과 문제점이 발생한다. 2바이트 문자의 두 번째 바이트 값이 1바이트 ASCII 문자가 사용하는 범위(0x40~0x7E)와 겹칠 수 있어, 특정 바이트가 1바이트 문자인지 2바이트 문자의 일부인지 구분하기 어려워 인코딩 자동 감지나 문자열 검색이 복잡해진다. 또한, 두 번째 바이트 값으로 역슬래시와 동일한 코드(0x5C)가 사용될 수 있어 파일 시스템 등에서 문제를 일으키기도 한다.

3. 1. 기본 구조

Shift_JIS는 JIS X 0201 (1바이트 문자 집합)과 JIS X 0208 (2바이트 문자 집합)을 함께 사용하기 위한 가변 길이 인코딩 방식이다. ISO/IEC 2022 표준에서 정의된 이스케이프 시퀀스 없이 두 문자 집합을 혼용할 수 있도록 설계되었다.

=== 1바이트 문자 ===

Shift_JIS의 1바이트 문자는 JIS X 0201 표준을 따른다.

  • 0x00 ~ 0x7F: 이 범위는 기본적으로 ASCII 인코딩과 일치한다. 다만, JIS X 0201 표준에 따라 일부 코드 포인트가 다르게 정의되어 있다. 대표적으로 0x5C는 ASCII의 역슬래시(\) 대신 엔화 기호(¥)로 사용되고, 0x7E는 ASCII의 물결표(~) 대신 오버라인(‾)으로 사용된다.
  • 0xA1 ~ 0xDF: 이 범위는 JIS X 0201에 정의된 반각 가타카나 문자에 할당된다.


=== 2바이트 문자 ===

Shift_JIS의 2바이트 문자는 JIS X 0208 문자 집합을 표현하는 데 사용된다.

  • 첫 번째 바이트: 2바이트 문자의 첫 번째 바이트(선행 바이트)는 0x81 ~ 0x9F 또는 0xE0 ~ 0xEF 범위의 값을 가진다. 이 범위는 1바이트 문자가 사용하는 0x00 ~ 0x7F 및 0xA1 ~ 0xDF 범위와 겹치지 않으므로, 1바이트 문자와 2바이트 문자를 구분하는 기준으로 사용된다.
  • 두 번째 바이트: 두 번째 바이트(후행 바이트)는 0x40 ~ 0x7E 또는 0x80 ~ 0xFC 범위의 값을 가진다. 이 범위는 1바이트 문자의 ASCII 영역(0x40 ~ 0x7E) 및 기타 영역과 겹칠 수 있다.


=== JIS X 0208 구점 번호와의 관계 ===

JIS X 0208은 문자를 94x94 크기의 표에 배치하고, 각 문자의 위치를 구점 번호(행 번호 k, 열 번호 t)로 정의한다. Shift_JIS는 이 구점 번호를 다음과 같은 계산 규칙에 따라 2바이트 값(s_1, s_2)으로 변환한다.[37] 여기서 \lfloor x \rfloor는 바닥 함수를 의미한다.

:s_1 = \begin{cases} \left \lfloor \frac{k + 257}{2} \right \rfloor & \mbox{if } 1 \le k \le 62 \\ \left \lfloor \frac{k + 385}{2} \right \rfloor & \mbox{if } 63 \le k \le 94 \end{cases}

:s_2 = \begin{cases} t + 63 & \mbox{if } k \mbox{ is odd and } 1 \le t \le 63 \\ t + 64 & \mbox{if } k \mbox{ is odd and } 64 \le t \le 94 \\ t + 158 & \mbox{if } k \mbox{ is even } \end{cases}

아래 표는 JIS X 0208 제1면의 구점 번호가 Shift_JIS의 어떤 바이트 범위에 대응되는지를 보여준다.

'''JIS X 0208 구점(제1면)과 Shift_JIS 부호화'''
Shift_JIS제2바이트 (0x)
40…7E80…9F…FC
제1바이트
(0x)		811구1점1구63점1구64점2구1점2구94점
⋮
9F61구1점61구63점61구64점62구1점62구94점
E063구1점63구63점63구64점64구1점64구94점
⋮
EF93구1점93구63점93구64점94구1점94구94점



=== 주요 특징 ===


  • 하위 호환성: Shift_JIS는 JIS X 0201 인코딩과 완벽하게 호환된다. 즉, 유효한 JIS X 0201 문자열은 그 자체로 유효한 Shift_JIS 문자열이다.
  • 인코딩 감지의 어려움: 2바이트 문자의 두 번째 바이트가 1바이트 문자의 ASCII 영역(0x40 ~ 0x7E)과 겹칠 수 있다. 이 때문에 특정 바이트가 1바이트 문자인지, 아니면 2바이트 문자의 일부인지 판별하기 어려워 문자열 처리나 인코딩 자동 감지에 문제가 발생할 수 있다. 예를 들어, 단순 검색 시 문자의 두 번째 바이트와 다음 문자의 첫 번째 바이트가 우연히 유효한 Shift_JIS 문자처럼 보일 수 있어, 문자열 검색 알고리즘은 Shift_JIS에 맞게 특별히 구현되어야 한다.
  • 0x5C 문제: 2바이트 문자의 두 번째 바이트 값 중에 0x5C가 포함될 수 있다. 이 값은 많은 운영체제에서 파일 시스템의 경로 구분 문자인 역슬래시(\)와 동일하다. 이로 인해 Shift_JIS로 인코딩된 파일명을 포함하는 ZIP 아카이브 파일 등을 다른 시스템에서 처리할 때 파일 경로 해석 오류나 압축 해제 실패 등의 문제가 발생하기도 한다.

3. 2. JIS X 0213 확장 (Shift_JIS-2004)

JIS X 0213 표준을 지원하기 위해 확장된 Shift_JIS-2004는 기존 Shift_JIS에서 사용하지 않던 제1바이트 영역인 `0xF0`부터 `0xFC`까지의 범위를 활용한다. Shift_JIS-2004는 기존 Shift_JIS의 상위 집합이다. 아래 표는 Shift_JIS의 전체 바이트 구조를 보여주며, 확장된 영역(`0xF0`–`0xFC`)을 포함한다.

제1바이트
0123456789ABCDEF
0␀␁␂␃␄␅␆␇␈␉␊␋␌␍␎␏
1␐␑␒␓␔␕␖␗␘␙␚␛␜␝␞␟
2␠!"#$%&'()*+,-./
30123456789:;<=>?
4@ABCDEFGHIJKLMNO
5PQRSTUVWXYZ[₩]^_
6`abcdefghijklmno
7pqrstuvwxyz{|}‾␡
8
9
A｡｢｣､･ｦｧｨｩｪｫｬｭｮｯ
Bｰｱｲｳｴｵｶｷｸｹｺｻｼｽｾｿ
Cﾀﾁﾂﾃﾄﾅﾆﾇﾈﾉﾊﾋﾌﾍﾎﾏ
Dﾐﾑﾒﾓﾔﾕﾖﾗﾘﾙﾚﾛﾜﾝﾞﾟ
E
F



제2바이트
0123456789ABCDEF
0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F


3. 3. 코드표

Shift JIS는 1바이트 문자 코드인 JIS X 0201을 확장하여, JIS X 0201에서 사용하지 않는 코드 영역을 활용해 2바이트 문자 코드인 JIS X 0208 문자 집합을 표현하는 가변 길이 인코딩 방식이다.
1바이트 문자

  • 0x00 ~ 0x7F: ASCII 문자와 거의 동일하다. 다만, JIS X 0201 표준에 따라 0x5C에는 백슬래시(\) 대신 엔화 기호(¥)가, 0x7E에는 물결표(~) 대신 오버라인(‾)이 할당되어 있다.
  • 0xA1 ~ 0xDF: JIS X 0201에 정의된 반각 가타카나 문자가 할당되어 있다.

2바이트 문자2바이트 문자는 JIS X 0208 문자를 나타내며, 첫 번째 바이트(선행 바이트)와 두 번째 바이트(후행 바이트)로 구성된다.

  • 선행 바이트: 0x81 ~ 0x9F 또는 0xE0 ~ 0xEF 범위의 값을 가진다. 이 범위는 1바이트 문자가 사용하는 0x00 ~ 0x7F, 0xA1 ~ 0xDF 범위와 겹치지 않도록 설계되었다. 총 47가지 종류가 있다.
  • 후행 바이트: 0x40 ~ 0x7E 또는 0x80 ~ 0xFC 범위의 값을 가진다. 총 188가지 종류가 있다. 이 범위는 1바이트 ASCII (0x40 ~ 0x7E) 및 반각 가타카나 (0xA1 ~ 0xDF) 범위와 일부 겹칠 수 있다.
  • 선행 바이트가 홀수(0x81, 0x83, ... 0x9F, 0xE1, ... 0xEF)이면 후행 바이트는 0x40 ~ 0x9E (0x7F 제외) 범위의 값을 가진다.
  • 선행 바이트가 짝수(0x82, 0x84, ... 0x9E, 0xE0, ... 0xEE)이면 후행 바이트는 0x9F ~ 0xFC 범위의 값을 가진다.

특징 및 문제점Shift JIS는 2바이트 문자의 선행 바이트 값이 항상 0x80 이상(최상위 비트가 1)이 되도록 보장한다. 그러나 후행 바이트는 0x40 ~ 0x7E 범위의 값을 가질 수 있는데, 이 값들은 1바이트 ASCII 문자와 동일하다. 이 때문에 특정 바이트 값이 선행 바이트인지, 후행 바이트인지, 혹은 독립적인 1바이트 문자인지 구분하기 어려워 Shift JIS 인코딩을 자동으로 감지하거나 문자열을 검색하는 것이 복잡하다. 따라서 Shift JIS를 처리하는 문자열 검색 알고리즘은 이러한 특성을 고려하여 특별히 제작되어야 한다.
Shift JIS 변형표준 Shift JIS 외에도 여러 변형이 존재한다.

  • MacJapanese: 클래식 Mac OS에서 사용된 변형으로, 코드 페이지 10001[9]로도 알려져 있다. 표준 Shift JIS와 달리 0x7E에 물결표(~)를 할당하고(US-ASCII와 동일), 0x5C에는 엔화 기호(¥)를 할당했다. 또한 백슬래시(\, 0x80), 줄 바꿈 없는 공백(0xA0), 저작권 기호(©, 0xFD), 상표 기호(™, 0xFE), 반각 가로 줄임표(…, 0xFF) 등 일부 문자를 추가로 정의했다. 세로 쓰기 문자(0xEB41–0xED96)와 특수 문자(0x8540–0x886D) 확장도 포함되었다.[18] 이 변형은 KanjiTalk 버전 7에서 도입되었다.[19] 특정 Mac OS 서체(사이 민초, 추 고딕 등)는 NEC 특수 문자를 기반으로 한 추가 확장을 포함하는 다른 변형을 사용하기도 했다.[18]
  • 이모지 확장: 일본의 휴대 전화 통신사들은 이메일 등에서 이모지를 사용하기 위해 표준 Shift JIS에서 사용하지 않던 영역(선행 바이트 0xF5~0xF9 등)을 활용했다.[26] KDDI는 선행 바이트 0xF3, 0xF4 영역에도 수백 개의 이모지를 추가로 정의했다.[27]
  • C 언어 등에서의 변형: C 언어와 유사한 프로그래밍 언어의 소스 코드 문자열에서 Shift JIS를 사용할 경우, 0x5C 바이트가 이스케이프 시퀀스의 시작 문자인 '\'로 해석될 수 있다. 이 때문에 2바이트 문자의 후행 바이트로 0x5C가 사용될 때 이를 특별히 처리하는 변형이 필요하다.
  • 기타: 이 외에도 개별 문자의 할당이 조금씩 다른 수많은 사소한 변형들이 존재한다. 이러한 확장 및 변형 중 상당수는 IANA에 공식적으로 등록되지 않아, 서로 다른 시스템 간에 데이터를 주고받을 때 혼란을 일으킬 수 있다.

확장 및 표현 가능 문자 수기본적인 Shift JIS는 JIS X 0208 문자 집합을 기준으로, 선행 바이트 47가지와 후행 바이트 188가지를 조합하여 47 × 188 = 8,836개의 2바이트 문자를 표현할 수 있다. 이는 JIS X 0208에서 규정된 94x94=8836개의 구획 번호를 모두 포함할 수 있도록 설계된 것이다. 여기에 158자의 1바이트 문자(영숫자, 반각 가나 등, 공백 포함, DEL 제외)를 더하면 총 8,994자를 표현할 수 있다.

JIS X 0213 문자를 포함하도록 확장된 Shift_JIS-2004나 마이크로소프트 코드 페이지 932(Windows-31J)와 같은 일부 확장 규격에서는 기존에 사용되지 않던 선행 바이트 영역인 0xF0 ~ 0xFC(총 13개)를 추가로 사용한다. 이를 통해 선행 바이트 종류가 60가지(47 + 13)로 늘어나며, 총 60 × 188 (2바이트 문자) + 158 (1바이트 문자) = 11,438자를 표현할 수 있게 된다. IBM 확장 문자나 Shift_JIS-2004의 제4수준 문자 등이 이 확장 영역을 사용한다.

4. 특징

클래식 Mac OS에서 파생된 Shift_JIS 버전('x-mac-japanese', 코드 페이지 10001[9] 또는 MacJapanese로 알려짐)은 물결표를 0x7E에 할당했고(ASCII를 따르며, 여기에서 윗줄을 할당하는 JIS X 0201와는 다름), 엔화 기호를 0x5C에 할당했다 (JIS X 0201 및 표준 Shift JIS에서와 같이). 또한 JIS X 0201를 확장하여 백슬래시를 0x80(ASCII의 0x5C에 해당), 줄 바꿈 없는 공백을 0xA0, 저작권 기호를 0xFD, 상표 기호를 0xFE, 반각 줄임표를 0xFF에 할당했다. 또한 0xEB41–0xED96 범위의 Shift JIS에 53개의 세로형 표현 양식과 0x8540–0x886D 범위의 Shift_JIS에 260개의 특수 문자를 포함하는 확장된 2바이트 문자를 추가했다.[18] 이 변형은 KanjiTalk 버전 7에서 도입되었다.[19]

그러나 특정 Mac OS 서체는 다른 변형을 사용했다. 사이 민초 및 추 고딕은 MacJapanese의 "포스트스크립트" 변형을 사용했으며, 여기에는 추가 세로형 표현 양식과 NEC 특수 문자를 기반으로 하는 다른 일련의 확장 특수 문자가 포함되었으며, 그 중 일부는 글꼴의 프린터 버전에서만 사용할 수 있었다.[18] System 7.1의 이전 버전의 마루 고딕과 혼 민초는 세로형 표현 양식을 정규 양식에서 10(84가 아닌) JIS 행 아래에 인코딩했으며 특수 문자 확장을 포함하지 않았으며, 이는 이후 변경되었다.[18][20] KanjiTalk 버전 6에서 사용된 일반적인 변형은 세로형 표현 양식을 10행 아래에 배치했으며, 행 13에 대한 NEC 확장 레이아웃도 사용했다.[21]

아래 표는 표준 Shift JIS (JIS X 0208:1997를 준수)로 인코딩된 스트림의 각 바이트에 대한 자세한 의미를 제공한다.

첫 번째 바이트
0123456789ABCDEF
0␀␁␂␃␄␅␆␇␈␉␊␋␌␍␎␏
1␐␑␒␓␔␕␖␗␘␙␚␛␜␝␞␟
2␠!"#$%&'()*+,-./
30123456789:;<=>?
4@ABCDEFGHIJKLMNO
5PQRSTUVWXYZ[￥]^_
6`abcdefghijklmno
7pqrstuvwxyz{|}‾␡
8
9
A｡｢｣､･ｦｧｨｩｪｫｬｭｮｯ
Bｰｱｲｳｴｵｶｷｸｹｺｻｼｽｾｿ
Cﾀﾁﾂﾃﾄﾅﾆﾇﾈﾉﾊﾋﾌﾍﾎﾏ
Dﾐﾑﾒﾓﾔﾕﾖﾗﾘﾙﾚﾛﾜﾝﾞﾟ
E
F



두 번째 바이트
0123456789ABCDEF
0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F


4. 1. 장점


  • 전각 문자와 JIS X 0201에서 정의된 반각 가나 문자를 동일한 코드 체계 안에서 표현할 수 있다.
  • 일본어 환경에서는 MS-DOS에서 일본어용 문자 코드로 채택된 이후 개인용 컴퓨터(PC)에서 널리 사용되어 다른 문자 인코딩 방식에 비해 데이터 교환이 용이하다.
  • UTF-8과 비교했을 때, 일본어 텍스트의 경우 일반적으로 데이터 크기가 더 작다. UTF-8 인코딩에서는 반각 가나나 대부분의 한자가 3바이트를 필요로 하기 때문이다.

4. 2. 단점

Shift JIS는 몇 가지 단점을 가지고 있다.

  • 구점 번호와 부호 간 변환의 복잡성: 반각 가나 문자를 위한 영역을 확보하면서, 문자의 위치를 나타내는 구점 번호와 실제 바이트 값 사이의 변환 규칙이 복잡해졌다. 이로 인해 특정 문자를 찾거나 변환하는 연산에 여러 조건 분기가 필요하다.[22][23]
  • 두 번째 바이트의 ASCII 영역 침범: Shift JIS는 2바이트 문자의 두 번째 바이트에 미만, 즉 ASCII 코드 영역에 해당하는 값이 올 수 있다. 이는 문자열을 처리할 때 어디까지가 하나의 문자인지 구분하기 어렵게 만든다. 특히 문자열의 뒤쪽부터 문자를 판별해야 하는 경우, 정확한 경계를 찾기 위해 문자열의 맨 앞까지 거슬러 올라가야 할 수도 있어 프로그램 구현 시 추가적인 고려가 필요하다. 또한, 이 영역에 포함되는 특정 바이트(특히 0x5C, 백슬래시 또는 엔 기호(¥)로 해석될 수 있는 값)의 처리 문제로 인해, EUC-JP나 UTF-8 같은 다른 멀티바이트 인코딩 방식에 비해 프로그래밍이 더 까다로워지는 원인이 된다 (관련 문제점).
  • JIS 보조 한자 표현 불가: JIS X 0212 표준에 정의된 보조 한자들을 Shift JIS로는 표현할 수 없다.
  • 벤더별 확장과 호환성 문제: 여러 소프트웨어 개발사(벤더)들이 JIS X 0208 표준에 규정되지 않은 독자적인 확장 문자(소위 기종 의존 문자)를 Shift JIS에 추가하는 경우가 많다. 이렇게 확장된 문자들은 서로 다른 시스템이나 프로그램 간에 호환되지 않아 데이터 교환 시 문제를 일으킬 수 있다. 대표적인 예로, 널리 사용되는 마이크로소프트의 코드 페이지 932(CP932 또는 MS932)는 JIS X 0213을 기반으로 확장된 Shift_JIS-2004와는 호환되지 않는 부분이 존재한다.[24][25][26][27]

4. 3. 2바이트 문자의 문제점 (0x5C 등)

Shift_JIS는 문자를 표현할 때, 두 번째 바이트가 0x40부터 0x7E까지와 0x80부터 0xFC까지의 범위를 사용한다. 이 중 0x40부터 0x7E까지는 ASCII 문자가 사용하는 영역과 겹치는데, 이 때문에 몇 가지 문제가 발생할 수 있다. 특히 두 번째 바이트가 역슬래시(\, 0x5C)와 같은 특정 ASCII 문자와 동일한 값을 가지는 경우가 문제가 된다.[39] Shift_JIS를 사용하는 시스템에서 압축한 ZIP 파일이 다른 시스템에서 제대로 풀리지 않는 경우가 대표적인 예시다.

C와 같은 프로그래밍 언어의 문자열 리터럴에서도 문제가 발생할 수 있다. 일반적으로 백슬래시로 사용되는 이스케이프 문자 0x5C는 Shift_JIS에서 반각 엔 기호(¥)에 해당한다. 만약 프로그래머가 이를 인지하고 있고, 입출력 시스템이 Shift JIS 출력을 지원한다면 `printf("ハローワールド¥n");` (여기서 ハローワールド는 'Hello, world'를 의미하고 ¥n은 줄 바꿈 이스케이프 시퀀스)처럼 사용할 수 있다. 하지만 진짜 문제는 '소'(ソ, 0x835C), '표'(表, 0x955C)와 같이 2바이트 문자의 두 번째 바이트가 0x5C인 경우다. 이 0x5C 바이트가 이스케이프 문자로 잘못 해석되어 문자열 처리에 오류를 일으킬 수 있다.[39]

'''JIS X 0208에서 두 번째 바이트가 0x5C가 되는 문자 목록'''
문자부호 (16진수)읽기・자구(字義)깨짐 예시
―0x815C대시
소0x835C소 (가타카나)소프트→ャt트
Ы0x845Cゥイ (키릴 문자)
噂0x895C손, 소문뜬소문 이야기→더b
浬0x8A5C리, 해리 , 노트
欺0x8B5C기, 속이다사기꾼→사t
圭0x8C5C케이니시코리 케이 등→니시코리 ᄀﾈ 등
構0x8D5C코우, 갖추다구성→告ｬ
蚕0x8E5C산, 누에양잠업→양시ﾆ
十0x8F5C쥬우, 열 (한자 숫자의 10)십인십색→署l署F
申0x905C신, 아뢰다, 원숭이신청→瑞ｿ, 신청→錐桙ﾝ
曾0x915C소, 히 (「曾」의 옛 글자)증손→장ｷ, 증조부→장c父
箪0x925C탄 (「簞」의 간이 관용 글자)찬장→주y
貼0x935C쵸, 붙이다붙이기→당阨tけ
能0x945C노우, 잘, 할 수 있다능력→박ﾍ, 가능성→가柏ｫ
表0x955C효우, 겉, 나타내다표시→무ｦ, 대표적→대蕪I
暴0x965C보우, 폭, 날뛰다폭력→말ﾍ, 폭로→까지I
予0x975C요, 미리, 미리예산→락Z, 예상→란z
禄0x985C로쿠원록X년→원납년
兔0x995C토, 토끼 (「兎」의 이체자)
喀0x9A5C카쿠, 캬쿠, 토하다객혈하다→향격ｷる
媾0x9B5C코우구화→묘a
(「講和」의 비표기 변경)
彌0x9C5C미, 비, 야 (「弥」의 옛 글자)이즈미 모토야 등→이즈미 모토怩ﾈ 등
拿0x9D5C다나포하다→지ﾟ하다
杤0x9E5C토치 (「밤나무」의 이체자)
歃0x9F5C소우, 쇼우, 삼키다피를 삽하여→피를 민ﾁて
浚0xE05C슌, 긁다하세가와 쥰 등→하세가와 烽ﾈ 등
奔0xE15C혼, 푸고, 모코분에 타다→담ﾉ타다
秉0xE25C헤이, 힌, 잡다병촉→숙C
彩0xE35C사이, 아야동식채회→동식승G
臀0xE45C덴, 엉덩이둔부 등→딸기 배ﾈ 등
藹0xE55C아이화기애애→화기주X
觸0xE65C쇼쿠 (「촉」의 옛 글자)
體0xE75C타이 (「몸」의 이체자)
鏤0xE85C탄, 츠바금칩 구이→금闖ﾄき
饅0xE95C만만두→체ｪ
鷭0xEA5C바아 (새의 이름)번의 무리→흑ﾌ무리



이 문제는 Shift_JIS와 유사하게 두 번째 바이트 범위에 0x5C를 포함하는 Big5나 드물게 GBK 같은 다른 문자 코드에서도 발생할 수 있다.

0x5C 외에도 비슷한 문제를 일으키는 경우가 있다.


  • 0x7C: 두 번째 바이트가 0x7C인 문자('포'(褒), '예'(Jes) 등)가 있다. 이 코드는 ASCII에서 `|`(수직선)에 해당하며, 유닉스나 MS-DOS 같은 셸 환경에서는 파이프 기호로 인식된다. 이 때문에 해당 문자가 포함된 파일명을 셸에서 정상적으로 다루기 어려울 수 있다.
  • 0x5B, 0x5D: 두 번째 바이트가 0x5B('제'(擢), '심'( Fakultät) 등) 또는 0x5D('조'( 凋), '전'(詮) 등)인 문자도 있다. 이 코드들은 ASCII에서 각각 `[`와 `]`에 해당하므로, 정규 표현식에서 특수 문자로 해석되어 문제를 일으킬 수 있다.


이처럼 ASCII 문장 부호와 동일한 바이트 값을 포함하여 프로그램 처리 시 문제를 일으킬 수 있는 멀티바이트 문자를 속칭 "안 되는 문자" 또는 "안 돼 문자"라고 부른다.[39]

이 문제를 피하기 위한 전통적인 방법들은 다음과 같다.

  • 소스 코드 전체를 EUC-JP나 UTF-8처럼 첫 번째 바이트와 두 번째 바이트의 영역이 ASCII와 겹치지 않는 문자 인코딩으로 변환하여 사용한다. (예: Perl의 `encoding` 프라그마)
  • 0x5C를 포함하는 문자열을 다룰 때, 문제가 되는 문자 바로 뒤에 이스케이프 문자(보통 `\`)를 추가하여 `ソ` → `ソ\` 와 같이 처리한다. (예: Perl의 Sjis 라이브러리[40]나 JavaScript)
  • 문자열을 직접 다루는 대신, 문자 코드를 숫자의 배열로 변환하여 처리하고, 필요할 때 다시 문자로 변환하여 사용한다. (예: Perl의 `Encode` 모듈[41])


Shift_JIS를 지원하지 않는 환경에서 "構わない"(카마와나이, 상관없다)라는 문자열을 처리하면, '構'(0x8D5C)의 두 번째 바이트인 0x5C가 이스케이프 문자로 인식되어 사라지면서 뒤따르는 문자들의 해석이 틀어질 수 있다. 예를 들어 "構\わない"에서 0x5C가 누락되면 다음과 같이 깨져 보일 수 있다. 여기서 0xED는 반각 가나 'ﾈ'(네)에 해당한다. 이후 'な'(나)부터는 다시 정상적으로 디코딩될 수 있다.

構 (코우)わ (와)な (나)い (이)
0x8D0x5C0x820xED0x820xC80x820xA2
▼ 이스케이프 문자로 오인되어 0x5C가 누락된 경우 ▼
0x8D 0x820xED0x820xC80x820xA2
고[43] 또는 墲[42]ﾈ (네)い (이)



마찬가지로 "芸能界"(게이노카이, 연예계)라는 문자열은 '能'(0x945C)의 두 번째 바이트 0x5C 때문에 "芸\能界"로 처리되다가 0x5C가 누락되면 다음과 같이 깨질 수 있다.

芸 (게이)能 (노우)界 (카이)
0x8C0x7B0x940x5C0x8A0x45
▼ 이스케이프 문자로 오인되어 0x5C가 누락된 경우 ▼
0x8C0x7B0x94 0x8A0x45
芸 (게이)矧E


5. 명칭

Shift JIS의 "시프트(Shift)"는 JIS X 0208 문자 집합을 분할하여 8비트 코드 공간 안에 "이동 배치"하여 부호화한다는 의미를 가진다.

다른 부호화 방식에서도 여러 문자 집합을 시프트 코드로 전환하는 조작을 "시프트"라고 부르기도 하지만, Shift JIS의 "시프트"와는 의미가 다르다. 예를 들어, ISO-2022-JP는 이스케이프 시퀀스로 한자와 영숫자를 전환하는 것을, EUC-JP는 보조 한자와 반각 가나를 싱글 시프트로 전환하는 것을 가리킨다. 또한, 비트 연산의 비트 시프트와도 관계가 없다.
MS Kanji는 IANA에서 Shift_JIS의 별칭으로 할당한 이름이다.[35]
x-sjis는 IANA에 Shift_JIS가 등록되기 전에 Netscape Navigator 2.0에서 사용했던 문자 인코딩 지정자명이다. 일부 브라우저 엔진에서는 HTML 문서의 문자 집합("charset") 지정에 Shift_JIS의 별칭으로 이 이름을 사용할 수 있도록 지원한다.

6. Shift JIS의 확장

오일러 다이어그램은 JIS X 0208, JIS X 0212, JIS X 0213, Windows-31J, 마이크로소프트 표준 레퍼토리 및 유니코드의 레퍼토리를 비교한다.


PC상의 Shift_JIS 변형과 교차점 및 기타 하위 집합을 포함한 관련 인코딩 간의 관계. 제공된 이름은 설명적이다.


Shift JIS에는 여러 가지 버전이 존재한다. 확장될 수 있는 두 가지 영역이 있다.

첫째, JIS X 0208은 Shift JIS에서 인코딩된 94×94 공간 전체를 채우지 않으므로 더 많은 문자를 위한 공간이 있다. 이것은 Shift JIS 자체보다는 JIS X 0208의 확장이라고 볼 수도 있다.

둘째, Shift JIS는 JIS X 0201과 JIS X 0208에 필요한 것보다 더 많은 인코딩 공간을 가지고 있으며 (아래의 § Shift JIS 바이트 맵 참조), 이 공간은 더 많은 문자(단일 바이트 또는 더블 바이트 문자)를 위해 사용될 수 있으며 실제로 사용되고 있다.

6. 1. Windows-31J (코드 페이지 932)



Shift_JIS의 가장 널리 사용되는 확장판은 Windows 코드 페이지 932이다. 이는 Shift_JIS에 대한 CCSID이자 IBM의 확장판으로도 사용된다. IANA에는 Shift_JIS와 별개로 "Windows-31J"라는 이름으로 등록되어 있다.[8] 마이크로소프트는 이 코드 페이지를 널리 사용하지만, 정작 "Windows-31J"라는 이름은 사용하지 않고 해당 변형을 "shift_jis"라고 부른다.[9][10] IBM의 코드 페이지 943은 마이크로소프트의 코드 페이지 932와 동일한 2바이트 코드를 포함하지만, IBM의 코드 페이지 932는 더 적은 확장 문자(마이크로소프트가 NEC에서 통합한 확장 제외)를 포함하며, 1983년 표준의 문자 교환을 구현하는 대신 1978년판 JIS X 0208의 문자 순서를 유지한다.[11]

Windows-31J는 US-ASCII를 따라 코드 포인트 0x5C에 U+005C REVERSE SOLIDUS (백슬래시)를, 0x7E에 U+007E TILDE (물결표)를 할당한다.[12] 그러나 실제 윈도우 환경의 대부분의 일본어 글꼴은 JIS X 0201과의 호환성을 위해 U+005C를 엔화 기호(¥)로 표시한다.[13][14] Windows-31J는 여러 확장 문자를 포함하는데, 대표적으로 "NEC 특수 문자(행 13), IBM 확장의 NEC 선택(행 89~92), IBM 확장(행 115~119)"[8] 등이 있으며, 개인 사용 영역을 위한 인코딩 공간도 일부 할당한다.[15]

Windows 코드 페이지 932는 W3C/WHATWG 인코딩 표준에서 사용되는 버전으로, HTML5에서도 사용된다. 이 표준은 JIS X 0208에 대한 해당 테이블에 Windows-31J의 "이전의 IBM 및 NEC 독점 확장"을 포함하고 있으며,[16] "배포된 콘텐츠와의 호환성"을 위해 "shift_jis"라는 레이블을 "windows-31j"와 상호 교환 가능한 것으로 취급한다.[17]

Shift_JIS는 마이크로소프트의 MS-DOS에서는 "MS 한자 코드"(이후 Microsoft 코드 페이지 932로 불림)로, 디지털 리서치의 CP/M-86에서는 "SJC-26"으로 채택되었다. 두 시스템의 구현은 거의 동일했지만 전각 공백 처리 방식에 차이가 있었다. MS-DOS는 전각 공백에 0x8140 코드를 할당했지만, CP/M-86은 반각 공백 두 개와 동일하게 0x2020 코드를 할당했다. CP/M-86 방식은 문자열에서 공백을 검색하는 처리가 간단해지는 프로그래밍상의 이점이 있었다. 반면, MS-DOS 방식은 전각 공백에 별도의 코드를 할당함으로써 사용자가 반각 입력 모드에서 스페이스바를 두 번 눌렀는지, 전각 입력 모드에서 스페이스바를 한 번 눌렀는지를 프로그램이 구별할 수 있게 했다. 이는 당시 Multiplan과 같은 일부 응용 소프트웨어에서 메뉴 선택에 스페이스바를 사용했기 때문에 중요했다. 또한, 프린터에서는 전각 공백과 반각 공백의 폭 비율이 정확히 2:1이 아닌 경우가 있어, 공백의 구분은 장표 설계에도 영향을 미쳤다.[34]

6. 2. MacJapanese



Shift JIS에는 여러 가지 버전이 존재하며, 확장될 수 있는 두 가지 영역이 있다.

첫째, JIS X 0208은 Shift JIS에서 사용 가능한 94×94 문자 공간 전체를 채우지 않기 때문에, 더 많은 문자를 추가할 여유 공간이 있다. 이는 Shift JIS 자체의 확장이라기보다는 JIS X 0208의 확장으로 볼 수 있다.

둘째, Shift JIS는 JIS X 0201과 JIS X 0208에서 요구하는 것보다 더 많은 인코딩 공간을 가지고 있다. 이 여분의 공간은 실제로 1바이트 또는 2바이트 문자를 추가하는 데 사용될 수 있으며, 여러 변형 버전에서 활용되었다.

6. 3. 기타 확장



Shift JIS에는 여러 가지 버전이 존재한다. 확장할 수 있는 두 가지 영역이 있다.

첫째, JIS X 0208은 Shift JIS에서 인코딩된 94×94 공간 전체를 채우지 않으므로, 더 많은 문자를 위한 공간이 있다. 이것은 Shift JIS 자체보다는 JIS X 0208의 확장이라고 볼 수도 있다.

둘째, Shift JIS는 JIS X 0201과 JIS X 0208에 필요한 것보다 더 많은 인코딩 공간을 가지고 있으며 (§ Shift JIS 바이트 맵 참조), 이 공간은 더 많은 문자(단일 바이트 또는 더블 바이트 문자)를 위해 사용될 수 있고 실제로 사용되고 있다.

참조

[1] 논문 convutf8.c https://github.com/k[...] 2008-11-12
[2] 웹사이트 Additional Japanese iconv Modules https://docs.oracle.[...] Oracle Corporation
[3] 웹사이트 Historical trends in the usage of character encodings for websites, December 2024 https://w3techs.com/[...] 2024-12-10
[4] 웹사이트 Distribution of Character Encodings among websites that use .jp https://w3techs.com/[...] 2024-12-10
[5] 웹사이트 Distribution of Character Encodings among websites that use Japanese https://w3techs.com/[...] 2024-12-10
[6] 웹사이트 Is UTF-8 the encoding of choice for QR-codes with non ASCII chars by now? https://stackoverflo[...] 2024-11-01
[7] 웹사이트 QR Code features https://web.archive.[...]
[8] 웹사이트 Character Sets https://www.iana.org[...] IANA
[9] 웹사이트 Encoding.WindowsCodePage Property – .NET Framework (current version) https://msdn.microso[...] Microsoft
[10] 웹사이트 Code Page Identifiers https://docs.microso[...] Microsoft 2021-01-07
[11] 웹사이트 IBM-943 and IBM-932 https://www.ibm.com/[...] IBM
[12] 웹사이트 CP932.TXT https://www.unicode.[...] Unicode Consortium
[13] 웹사이트 3.1.1 Details of Problems https://web.archive.[...] The Open Group Japan
[14] 웹사이트 When is a backslash not a backslash? http://archives.milo[...] 2005-09-17
[15] 웹사이트 The PUA outside of Unicode http://archives.milo[...] 2007-05-26
[16] 웹사이트 5. Indexes (§ Index jis0208) https://encoding.spe[...] WHATWG
[17] 웹사이트 4.2. Names and labels https://encoding.spe[...] WHATWG
[18] 웹사이트 JAPANESE.TXT: Map (external version) from Mac OS Japanese encoding to Unicode 2.1 and later. https://unicode.org/[...] Apple Computer, Inc.; Unicode Consortium
[19] 웹사이트 A Brief History of Japan's Era Name Ligatures https://blogs.adobe.[...] Adobe Inc 2019-03-21
[20] 웹사이트 Encoding Variants for MacJapanese https://developer.ap[...] Apple
[21] 서적 Appendix E: Vendor Character Set Standards https://resources.or[...] O'Reilly Media 2008
[22] 웹사이트 JIS X 0213 Code Mapping Tables http://x0213.org/cod[...] x0213.org
[23] 웹사이트 JIS X 0213の代表的な符号化方式 § Shift_JIS-2004 http://www.asahi-net[...]
[24] 표준 Japanese Graphic Character Set for Information Interchange, Plane 1 2004-04-13
[25] 웹사이트 Index jis0208 visualization https://encoding.spe[...] WHATWG
[26] 웹사이트 Original Emoji from DoCoMo https://www.fileform[...] FileFormat.info
[27] 웹사이트 Original Emoji from KDDI https://www.fileform[...] FileFormat.info
[28] 웹사이트 XML用語事典 [シフトJIS（Shift_JIS）] https://www.atmarkit[...] 2021-01-11
[29] 문서 EUC-JP 설명
[30] 블로그 私のマイコン遍歴、日本のパソコン30年史、その1 https://web.archive.[...] 2005-12-28
[31] 논문 및 웹사이트 日本における最新文字コード事情, シフトJISの誕生, Re:古川享さんがシフトJIS誕生について書いています http://kanji.zinbun.[...] システム/制御/情報, slashdot.jp 2001, 2005-12-22, 2005-12-29
[32] 블로그 私のマイコン遍歴、日本のパソコン30年史、その1 http://furukawablog.[...] 2006-09-21
[33] 블로그 Re:古川享さんがシフトJIS誕生について書いています http://slashdot.jp/c[...] 2006-09-29
[34] 뉴스 Unix風の機能を持ち込んだ日本語MS-DOS2.0の機能と内部構造 日経エレクトロニクス 1983-12-19
[35] 웹사이트 CHARACTER SETS https://www.iana.org[...] Internet Assigned Numbers Authority 2011-07-04
[36] 웹사이트 外字を使うのはやめてくれ！ Unicodeへの移行を呼びかけるMicrosoftの公式ブログ記事が話題に - やじうまの杜 - 窓の杜 https://forest.watch[...]
[37] 웹사이트 JIS X 0213の代表的な符号化方式 § Shift_JIS-2004 https://www.asahi-ne[...] 2019-04-27
[38] 문서 区点番号では、奇数区29点の文字が該当する。
[39] 웹사이트 Linuxマイグレーションガイド　LinuxのShift JISサポート　－現状とその対応策－ http://www.ossforum.[...] 2009-07-10
[40] 웹사이트 Char-Sjis-1.08 - Native Encoding Support by Traditional Scripting - metacpan.org https://metacpan.org[...]
[41] 웹사이트 Encode-3.00 - character encodings in Perl - metacpan.org https://metacpan.org[...]
[42] 문서 Microsoftコードページ932による符号
[43] 문서 Shift_JIS-2004による符号
[44] 블로그 일본 슬래시닷의 글 http://slashdot.jp/~[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com