MBCS

덤프버전 :


1. 개요
2. 상세
3. 호환성 문제
4. 목록
5. 관련 문서



1. 개요[편집]


Multi-Byte Character Set

유니코드를 제외한 문자 인코딩에서 두 개 이상의 바이트를 사용해서 문자를 표시하는 방식.

대부분 2바이트를 사용하기 때문에 DBCS(double-byte character set)라고도 부른다. 이론상으로 MBCS는 3바이트 이상의 문자도 포함할 수 있기 때문에 MBCS가 곧 DBCS인 것은 아니지만, 2바이트를 초과하는 경우는 거의 없기 때문에 사실상 DBCS=MBCS로 굳어졌다. 그 외에도 한국어, 중국어, 일본어에서 주로 쓰이기 때문에 Chinese, Japanese, Korean의 앞글자를 딴 CJK라고도 불린다. 반대로 1바이트만 사용하는 문자 표기 방식은 SBCS(single-byte character set)라고 부른다.

일반 ASCII 문자와 반각 가타카나는 1바이트로 처리하며, 한글이나 한자, 히라가나, 전각 가타카나와 같은 전각 문자들은 2바이트로 처리한다.


2. 상세[편집]


동아시아권에서 사용하는 문자는 그 수가 매우 많기 때문에 확장 ASCII 영역의 128자만으로는 부족했다. 일본에서는 1969년 제정된 JIS X 0201에서 반각 가타카나를 사용해서 일본어를 표기하기는 했지만, 가독성이 매우 나빴기 때문에 컴퓨터 기술이 발달한 뒤에는 MBCS를 도입했다. 한국어중국어 환경에서는 반각 가타카나 같은 방식이 불가능하기 때문에[1] 처음부터 MBCS를 사용했다.

확장 ASCII 영역의 문자를 두 개 합쳐서 표시하는 것이기 때문에 이론상으로는 128*128=16384자를 표현할 수 있다. 하지만 호환성 등으로 인해 각 바이트에 128자를 전부 사용하지는 않기 때문에 실질적으로 표현할 수 있는 글자는 이보다 적다. 이 때문에 1990년대 이후 등장한 Shift_JIS나 CP949 등은 둘째 바이트에 표준 ASCII 영역도 사용해서 텍스트를 표시한다.

MS-DOS 시절에는 MBCS 처리를 위해 별도의 프로그램을 RAM에 불러와야 했다. 예를 들어 한글 MS-DOS는 MSHBIOS라고 불리는 프로그램을 자동으로 불러오도록 되어 있다. 문제는 램상주 프로그램이다 보니 메모리를 더 많이 잡아먹고, 일부 비디오 카드와 충돌을 일으키기도 했다. 그리고 영문 프로그램과 충돌을 일으키는 경우도 많았기 때문에 이럴 때에는 별도의 명령어를 입력해서 언로드해줘야 했다.


3. 호환성 문제[편집]


국가간의 호환이 되지 않는 방식이기에 다른 시스템으로 보내면 글자가 알아볼 수 없게 깨진다. 일본어 텍스트 파일을 한글 윈도우에서 열었을 때 소위 말하는 뷁어로 깨지는 것이 대표적인 예시. 이에 대한 자세한 내용은 문자 깨짐 문서 참고.

이외에도 철저히 자국어 표기만을 위한 인코딩이다 보니 외국어 교재 같이 다른 문자체계가 필요한 경우 불편함이 크다.

이 문제를 해결하기 위해 나온 것이 유니코드.[2] 세계의 거의 모든 문자를 표현할 수 있기 때문에 최근 2010년대에 들어서 많이 사용되고 있다. 그 중에서도 특히 UTF-8[3]이 널리 쓰인다.

문제는 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나 2000년대 이후의 리눅스 등은 기본적으로 텍스트 파일을 단일 인코딩으로 읽어들이기 때문에 MBCS 형태로 작성된 텍스트 파일은 별도의 처리를 하지 않는 한 전부 로 보인다. 과거의 국산 리눅스 배포판처럼 시스템 로캘을 MBCS로 전환해서 쓸 수는 있었으나, UTF-8이 상당히 빠르게 정착했기 때문에 MBCS 자료를 다룰 일이 있는 프로그램이 개별적으로 인코딩을 지원하는 쪽으로 발전했다. 그래서 여기에서는 UTF-8이 아닌 것으로 인코딩된 자료를 명시할 일이 더 많기 때문에 BOM을 안 쓰는 것이 정착해서 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]


5. 관련 문서[편집]


파일:크리에이티브 커먼즈 라이선스__CC.png 이 문서의 내용 중 전체 또는 일부는 2023-10-30 14:21:25에 나무위키 MBCS 문서에서 가져왔습니다.

[1] 한글도 풀어쓰기를 하자는 움직임이 있었고 아래아 한글 초창기 버전에서는 반각 한글 자모를 지원하기도 하였으나 가독성이 반각 가나카나보다도 나쁘기 때문에 사장되었다.[2] 유니코드의 첫 버전은 이미 1990년대 초에 등장했지만, 이를 사용하는 소프트웨어가 많지 않았다.[3] ASCII와 호환되고, 영어(소스코드 등)작성시 용량 효율이 좋으며, 2바이트 중 앞에서부터 읽을지 뒤에서부터 읽을지 고민하는 "리틀엔디언 빅엔디언" 문제가 없다. 단점은 비 알파벳 언어 용량의 증가[4] UTF-8 문서에 서술된 바와 같이 BOM을 붙이는 것은 유니코드 컨소시엄에서 권장하지 않는 방법이지만, 인코딩을 구별하기 위해서 여전히 사용되고 있다.[5] 이 경우, 비유니코드 함수를 사용하여 새로 개발된 프로그램이 사용하는 인코딩은 UTF-8이 된다.[6] 마이크로소프트에서 제작한 GB2312의 확장판. GB2312에서 사용되지 않은 나머지 영역에 유니코드 1.1에 배당된 한중일 통합 한자를 집어넣었다. 이후 유로 기호가 추가되는 등의 변화가 몇번 있었다.[7] GBK를 기반으로 중국 정부에서 추가적으로 확장한 인코딩 체계. 유니코드를 지원하지 않는 기기에서 유니코드를 지원하기 위해 만들어졌으며, 이 경우 글자당 4바이트를 차지한다.[8] 유니코드 보급 이전에 Unix 계열 서버에서 주로 쓰이던 인코딩. Shift_JIS의 0x5C 문제 같은 것이 없어서 이쪽을 선호하는 사람들도 있다.