최근 수정 시각 : 2024-04-16 18:12:24

MBCS



[[컴퓨터공학|컴퓨터 과학 & 공학
Computer Science & Engineering
]]
[ 펼치기 · 접기 ]
||<tablebgcolor=#fff,#1c1d1f><tablecolor=#373a3c,#ddd><colbgcolor=#0066DC><colcolor=white> 기반 학문 || 수학( 해석학 · 이산수학 · 수리논리학 · 선형대수학 · 미적분학 · 미분방정식 · 대수학( 환론 · 범주론) · 정수론) · 이론 컴퓨터 과학 · 암호학 · 전자공학 · 언어학( 형태론 · 통사론 · 의미론 · 화용론 · 음운론) · 인지과학 ||
하드웨어 구성 SoC · CPU · GPU( 그래픽 카드 · GPGPU) · ROM · RAM · SSD · HDD · 참조: 틀:컴퓨터 부품
기술 기계어 · 어셈블리어 · C/ C++ · C# · Java · Python · BIOS · 절차적 프로그래밍 · 객체 지향 프로그래밍 · 해킹 · ROT13 · 일회용 비밀번호 · 사물인터넷 · 와이파이 · GPS · 임베디드 · 인공신경망 · OpenGL · EXIF · 마이크로아키텍처 · ACPI · UEFI · NERF · gRPC · 리버스 엔지니어링 · HCI · UI · UX · 대역폭 · DBMS · NoSQL · 해시( SHA · 브루트 포스 · 레인보우 테이블 · salt · 암호화폐) · RSA 암호화 · 하드웨어 가속
연구
및
기타 		논리 회로( 보수기 · 가산기 · 논리 연산 · 불 대수 · 플립플롭) · 정보이론 · 임베디드 시스템 · 운영 체제 · 데이터베이스 · 프로그래밍 언어{ 컴파일러( 어셈블러 · JIT) · 인터프리터 · 유형 이론 · 파싱 · 링커 · 난해한 프로그래밍 언어} · 메타데이터 · 기계학습 · 빅데이터 · 폰노이만 구조 · 양자컴퓨터 · 행위자 모델 · 인코딩( 유니코드 · MBCS) · 네트워크 · 컴퓨터 보안 · OCR · 슈퍼컴퓨터 · 튜링 머신 · FPGA · 딥러닝 · 컴퓨터 구조론 · 컴퓨터 비전 · 컴퓨터 그래픽스 · 인공지능 · 시간 복잡도( 최적화) · 소프트웨어 개발 방법론 · 디자인 패턴 · 정보처리이론 · 재귀 이론 · 자연어 처리( 기계 번역 · 음성인식) · 버전 ( 버전 관리 시스템 · Git · GitHub)

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

[clearfix]

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라고 불리는 프로그램을 자동으로 불러오도록 되어 있다. 문제는 램상주 프로그램이다 보니 메모리를 더 많이 잡아먹고, 일부 비디오 카드와 충돌을 일으키기도 했다. 그리고 영문 프로그램과 충돌을 일으키는 경우도 많았기 때문에 이럴 때에는 별도의 명령어를 입력[2]해서 언로드해줘야 했다.

3. 호환성 문제

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

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

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

문제는 Microsoft Windows의 경우 유니코드를 지원하지 않았던 Windows 9x와의 하위 호환성 때문에 여전히 MBCS를 기본 인코딩으로 사용한다는 것이다.[5] 윈도우는 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 문서를 제대로 해석하지 못한다.[6] 이렇듯 국가간의 호환성 문제가 존재하는데다가 SBCS 체계에서는 MBCS 인코딩을 예외처리하기가 복잡해지기 때문에 서구권 프로그래머들은 MBCS를 싫어한다.

스마트폰(=비 MS윈도우 컴퓨터)이 널리 보급되고 국가간의 교류가 점차 커지고 있는 상황이기에 유니코드의 사용이 늘고 있다. Windows 10 1803에서 시스템 로캘을 설정하는 부분을 보면 'Beta: 세계 언어 지원을 위해 Unicode UTF-8 사용'이라는 항목이 생긴 것을 알 수 있는데, 이것은 맥이나 리눅스처럼 시스템 로캘을 UTF-8로 아예 바꿔버리는 것이다.[7] 다만, MBCS와 유니코드를 섞어서 사용하는 몇몇 구 프로그램에서 �를 반환하는 등의 문자열 오류를 일으킨다. 아직까지는 하위 호환성 문제가 남아있는데다가 베타 기능이기 때문에 기본 적용은 되어 있지 않지만, 차후 MBCS가 사장되면 윈도우 역시 유니코드를 전면 적용할 가능성이 생겼다고 할 수 있다.

Windows 10 1903부터는 메모장에서 BOM 없는 UTF-8을 기본 인코딩으로 사용하도록 바뀌었다. 이전까지는 UTF-8 저장 시 무조건 BOM을 붙였다.

4. 목록

5. 관련 문서

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

분류