MBCS
[clearfix]
1. 개요
Multi-Byte Character Set
유니코드를 제외한 문자 인코딩에서 두 개 이상의 바이트를 사용해서 문자를 표시하는 방식.
대부분 2바이트를 사용하기 때문에 '''DBCS'''(double-byte character set)라고도 부른다. 이론상으로 MBCS는 3바이트 이상의 문자도 포함할 수 있기 때문에 MBCS가 곧 DBCS인 것은 아니지만, 2바이트를 초과하는 경우는 거의 없기 때문에 사실상 DBCS=MBCS로 굳어졌다. 그 외에도 한국어, 중국어, 일본어에서 주로 쓰이기 때문에 '''C'''hinese, '''J'''apanese, '''K'''orean의 앞글자를 딴 '''CJK'''라고도 불린다. 반대로 1바이트만 사용하는 문자 표기 방식은 SBCS(single-byte character set)라고 부른다.
일반 ASCII 문자와 반각 가타카나는 1바이트로 처리하며, 한글이나 한자, 히라가나, 전각 가타카나와 같은 전각 문자들은 2바이트로 처리한다.
2. 상세
동아시아권에서 사용하는 문자는 그 수가 매우 많기 때문에 확장 ASCII 영역의 128자만으로는 부족했다. 일본에서는 1969년 제정된 JIS X 0201에서 반각 가타카나를 사용해서 일본어를 표기하기는 했지만, 가독성이 매우 나빴기 때문에 컴퓨터 기술이 발달한 뒤에는 MBCS를 도입했다. 한국어나 중국어 환경에서는 반각 가타카나 같은 꼼수가 불가능하기 때문에 처음부터 MBCS를 사용했다.
확장 ASCII 영역의 문자를 두 개 합쳐서 표시하는 것이기 때문에 이론상으로는 128*128=16384자를 표현할 수 있다. 하지만 호환성 등으로 인해 각 바이트에 128자를 전부 사용하지는 않기 때문에 실질적으로 표현할 수 있는 글자는 이보다 적다. 이 때문에 1990년대 이후 등장한 Shift_JIS나 CP949 등은 둘째 바이트에 표준 ASCII 영역도 사용해서 텍스트를 표시한다.
MS-DOS 시절에는 MBCS 처리를 위해 별도의 프로그램을 RAM에 불러와야 했다. 예를 들어 한글 MS-DOS는 HBIOS라고 불리는 프로그램을 자동으로 불러오도록 되어 있다. 문제는 램상주 프로그램이다 보니 메모리를 더 많이 잡아먹고, 일부 비디오 카드와 충돌을 일으키기도 했다. 그리고 영문 프로그램과 충돌을 일으키는 경우도 많았기 때문에 이럴 때에는 별도의 명령어를 입력해서 언로드해줘야 했다.
3. 호환성 문제
국가간의 호환이 되지 않는 방식이기에 다른 시스템으로 보내면 글자가 알아볼 수 없게 깨진다. 일본어 텍스트 파일을 한글 윈도우에서 열었을 때 소위 말하는 '''뷁어'''로 깨지는 것이 대표적인 예시. 이에 대한 자세한 내용은 문자 깨짐 문서 참고.
이 문제를 해결하기 위해 나온 것이 유니코드.[1] 세계의 거의 모든 문자를 표현할 수 있기 때문에 최근 2010년대에 들어서 많이 사용되고 있다. 그 중에서도 특히 UTF-8[2]이 널리 쓰인다.
문제는 Microsoft Windows의 경우 유니코드를 지원하지 않았던 Windows 9x와의 하위 호환성 때문에 여전히 MBCS를 기본 인코딩으로 사용한다는 것이다. 윈도우는 NT 커널을 개발했을 때부터, 이미 선구적으로 2바이트 유니코드인 UCS-2를 적용하고(현재는 UTF-16 LE) 커널 내부에서 사용하고 있지만, 텍스트 파일을 작성하거나 옛날 프로그램을 실행하거나 ZIP 파일을 열거나 할 때 MBCS를 사용하는 프로그램이 많아 국가 간의 호환성 문제가 있다. UTF-8이나 UTF-16에 BOM 문자가 없으면 무조건 MBCS로 읽어들이는 프로그램들이 존재하기 때문에 Windows용 프로그램들은 UTF-8로 저장 시 BOM을 붙이는 경우가 많은데, 이는 BOM 없는 UTF-8을 사용하는 타 운영체제에서 인코딩 오류를 일으키게 된다.
반대로 UTF-8을 기본 인코딩으로 도입한 macOS나 리눅스 등은 기본적으로 텍스트 파일을 단일 인코딩으로 읽어들이기 때문에[3] MBCS 형태로 작성된 텍스트 파일은 전부 �로 보이며, BOM 문자가 있는 UTF-8 문서를 제대로 해석하지 못한다.[4] 이렇듯 국가간의 호환성 문제가 존재하는데다가 SBCS 체계에서는 MBCS 인코딩을 예외처리하기가 복잡해지기 때문에 서구권 프로그래머들은 MBCS를 싫어한다.
스마트폰(=비 MS윈도우 컴퓨터)이 널리 보급되고 국가간의 교류가 점차 커지고 있는 상황이기에 유니코드의 사용이 늘고 있다. Windows 10 RS4 빌드에서 시스템 로캘을 설정하는 부분을 보면 'Beta: 세계 언어 지원을 위해 Unicode UTF-8 사용'이라는 항목이 생긴 것을 알 수 있는데, 이것은 맥이나 리눅스처럼 시스템 로캘을 UTF-8로 아예 바꿔버리는 것이다.[5] 다만, MBCS와 유니코드를 섞어서 사용하는 몇몇 구 프로그램에서 �를 반환하는 등의 문자열 오류를 일으킨다. 아직까지는 하위 호환성 문제가 남아있는데다가 베타 기능이기 때문에 기본 적용은 되어 있지 않지만, 차후 MBCS가 사장되면 윈도우 역시 유니코드를 전면 적용할 가능성이 생겼다고 할 수 있다.
Windows 10 19H1 빌드부터는 메모장에서 BOM 없는 UTF-8을 기본 인코딩으로 사용하도록 바뀌었다. 이전까지는 UTF-8 저장 시 무조건 BOM을 붙였다.
4. 목록
- 한글(완성형): EUC-KR, CP949
- 한글(조합형): 한컴 2바이트 코드 등.
- 중국어(간체자): GB2312(EUC-CN), GBK(CP936)[6], GB18030[7] 등.
- 중국어(번체자): Big5
- 일본어: Shift_JIS, EUC-JP[8]
[1] 유니코드의 첫 버전은 이미 1990년대 초에 등장했지만, 이를 사용하는 소프트웨어가 많지 않았다.[2] ASCII와 호환되고, 영어(소스코드 등)작성시 용량 효율이 좋으며, 2바이트 중 앞에서부터 읽을지 뒤에서부터 읽을지 고민하는 "리틀엔디언 빅엔디언" 문제가 없다. 단점은 비 알파벳 언어 용량의 증가[3] 단, iconv와 같은 명령어를 통해 MBCS를 UTF-8로 변환하여 입출력할 수는 있다. 윈도우처럼 MBCS를 네이티브에 가깝게 지원하지 않을 뿐.[4] UTF-8 문서에 서술된 바와 같이 BOM을 붙이는 것은 유니코드 컨소시엄에서 권장하지 않는 방법이지만, 인코딩을 구별하기 위해서 여전히 사용되고 있다.[5] 이 경우, 비유니코드 함수를 사용하여 새로 개발된 프로그램이 사용하는 인코딩은 UTF-8이 된다.[6] 마이크로소프트에서 제작한 GB2312의 확장판. GB2312에서 사용되지 않은 나머지 영역에 유니코드 1.1에 배당된 한중일 통합 한자를 집어넣었다. 이후 유로 기호가 추가되는 등의 변화가 몇번 있었다.[7] GBK를 기반으로 중국 정부에서 추가적으로 확장한 인코딩 체계. 유니코드를 지원하지 않는 기기에서 유니코드를 지원하기 위해 만들어졌으며, 이 경우 글자당 4바이트를 차지한다.[8] 유니코드 보급 이전에 Unix 계열 서버에서 주로 쓰이던 인코딩. Shift_JIS의 0x5C 문제 같은 것이 없어서 이쪽을 선호하는 사람들도 있다.