mir.pe (일반/밝은 화면)
최근 수정 시각 : 2024-12-12 20:40:40

문자 깨짐


파일:하위 문서 아이콘.svg   하위 문서: 문자 깨짐/뷁어 테이블
,
,
,
,
,
#!wiki style="display: inline; display: none;"
, }}}
1. 개요2. 일어나는 경우
2.1. 다른 인코딩으로 읽음2.2. 인코딩 정규화 방식이 다름2.3. 문자 코드 읽는 순서가 맞지 않음2.4. 정보 자체가 손실됨2.5. 인코딩 범위를 벗어난 글자를 사용2.6. 출력상의 한계를 넘음2.7. 한 바이트가 잘림2.8. 특정 문자를 표시해 줄 글꼴 없음2.9. 글꼴의 문제
3. 해결 방법
3.1. 한글 인코딩 깨짐 예
4. 관련 문서

1. 개요

컴퓨터 등 IT 기기에서 문자가 올바르게 표시되지 않는 현상을 의미한다.

일본어에서는 문자 깨짐을 모지바케(文字化け, mojibake)라고 하며 영어권에도 이 용어가 수입돼 이 현상을 그냥 mojibake라고 부른다.

2. 일어나는 경우

2.1. 다른 인코딩으로 읽음

텍스트 작성에 쓰인 문자 인코딩과 텍스트를 열 때의 문자 인코딩이 다른 경우이다. 예시로 EUC-KR(또는 CP949)로 작성된 텍스트를 Windows-1252로 열었을 경우, 또는 Shift_JIS로 작성된 텍스트를 CP949로 열었을 경우 등이 있다.

문자가 깨지면서 출력되는 획수가 많은 확장완성형 한글이 과거 유행어였던 뷁을 연상시켜 이를 인터넷 속어로 뷁어라고 부르기도 하는데, 뷁의 어원이 ' break it'이란 걸 생각해보면 의미까지 적절한 번역인 셈이다. 인터넷에 돌아다니는 뷁어 번역기들의 원리는 간단하게 말하자면 CP949로 잘못 인코딩된 텍스트를 Shift_JIS로 재변환하는 것이다. 실제 변환 예시는 문자 깨짐/뷁어 테이블 문서를 참조 바란다.

같은 언어라고 해도 인코딩 체계가 다르면 역시 깨진다. MS-DOS 시절 한글 BIOS를 적용한 한글 DOS를 쓰면서 조합형을 완성형으로 변환하거나, 그 반대의 경우를 해봤다면 알 것이다.

파일:유튜브글자오류.png

2.2. 인코딩 정규화 방식이 다름

윈도우 PC와 애플 맥과의 한글파일명 파일을 교환할 때 발생하는 문제이다. 자소(字素) 각 코드를 조합해서 표현할지, 자소가 합쳐져 있는 문자의 완성형 코드로 표현할지가 달라서 발생한다. 다만 문자 자체가 무엇을 뜻하는지는 동일하기에 검색 엔진에서는 한쪽의 깨진 문자열을 그대로 복사해 검색해도 정상적으로 인식된다.

기술적으로 서술하자면, 서로 다른 유니코드 정규화 방식( Windows NFC ↔ macOS NFD)에 따라 모음과 자음이 분리되어 풀어쓰기처럼 변한다. 해당 규칙은 현대 한글 NFC ↔ NFD 변환 테이블 참고.
관련 서술은 애플의 디스크포맷 관련 문서, HFS+, APFS에도 서술되어 있다.

2.3. 문자 코드 읽는 순서가 맞지 않음

MBCS의 엔디안 문제로서 리틀 엔디안 빅 엔디안의 코드 읽고 쓰는 순서가 달라서 생기는 문제이다. 예를 들자면, 앞 숫자와 뒷 숫자를 바꿔 읽으면 46≠64처럼 전혀 생뚱맞은 다른 숫자(다른문자코드)가 되는 것과 같다. 46을 저장할때 64로 저장하는 시스템이 있는 이유는, 0046보다 64로 처리하는 것이 효율적이라는 장점이 있기 때문이다.

이 문제를 해결하기 위해 UTF-8을 도입하게 되었으며, 웬만한 곳(서버, 파일, 웹)에서는 이 인코딩으로 저장하길 권장한다.

2.4. 정보 자체가 손실됨

텍스트 저장 과정에서 문제가 생긴 경우로, 원문을 완전히 복원해 낼 수 없다. UTF-8로 문서를 저장할 때 저장 과정에 문제가 생겨 일부 텍스트가 �(U+FFFD, REPLACEMENT CHARACTER[21])로 변하는 경우 등이 이에 해당된다. 한때 이글루스를 환장하게 만들었던 占쏙옙도 이와 관련이 있다.

현재 사용 중인 문자 인코딩이 처리할 수 없는 문자를 넣고 저장한 경우에도 이런 문제가 생긴다(예: 한글이 섞인 문서를 Shift_JIS로 저장한 경우). 이 경우는 보통 저장 과정에서 해당 문자가 ?나 �로 대체되므로 원문을 복원해 낼 수 없다.

한때 인터넷에서 화제가 되었던 발작난 영수증도 이런 경우로 추정된다.[22]

2.5. 인코딩 범위를 벗어난 글자를 사용

파일:attachment/으으.jpg
완성형이 대표적인 예로, 현대 한글의 조합자 11,172자 중 2,350자만 있어서, 이 범위를 벗어난 조합자는 깨지게 된다. 위 사진이 그 예 중 하나로, 마지막 부분은 본래 '으쌰으쌰!'인데 EUC-KR의 2,350자 중 '쌰'라는 글자가 없어서 '?'로 깨지는 바람에 '으?으?!'로 둔갑했고 결국 이 사진은 점술가가 점 보다가 급사했다며 유머짤로 퍼지게 되었다. 뉴스 기사에서도 이 사진처럼 '으쌰으쌰'가 '으?으?'로 깨지는 경우가 있는데, 이 또한 뉴스 송고 시스템이 EUC-KR로 되어 있어서 '쌰'가 깨진 것.

이 링크를 보면 뉴스 기사에 '살짝 설렜어'가 쓰였는데 '렜'이라는 글자가 EUC-KR에 없어서 깨져서 나온 것을 볼 수 있다. '살짝 설렜어'는 오마이걸의 NONSTOP 타이틀곡이기도 한데 노래방에서는 이 문제 때문에 '살짝 설랬어'나 '살짝 설렛어' 등으로 대신 나온다.

임베디드 컴퓨터에서는 리소스 절약 차원에서 완성형의 2,350자만 사용하는 경우가 많다. 그 예로, 어떤 사람이 배달앱으로 배달 음식을 주문했는데 '김빼주세요'를 '김뺴(ㅃ+ㅒ)주세요'로 오타를 냈고 뺴라는 글자가 완성형에 없어서 영수증 출력기에서 '김?주세요'로 깨져 나오는 바람에 결국 김이 왔다는 사연을 SNS에 남긴 바 있다. (보기) 이 또한 바로 영수증 출력기에 내장된 임베디드 컴퓨터가 '뺴'라는 글자를 인식하지 못해서 일어난 현상이다.

산업용이나 의료용 등 특수 목적용 임베디드 컴퓨터는 호환성 유지를 위해서라도 완성형을 사용하는 경우가 많아서, (실제로 그럴 일은 거의 없겠지만) 이런 기기에도 완성형을 벗어난 글자를 쓰면 깨진다.

이때문에 한글 채움 문자 표현이 있긴하나 Firefox 등 오픈 소스 소프트웨어를 제외하면 지원하는 소프트웨어가 별로 없고 문자표에서 불러와야 해서 번거롭다.

2.6. 출력상의 한계를 넘음

파일:상세 내용 아이콘.svg   자세한 내용은 강제 줄 바꿈 문서
를
의 번 문단을
의 부분을
참고하십시오.
PC통신상에서는 한글 터미널 편집기로 작성시 출력가능한 열이 80열까지밖에 없어서 81열을 넘어서 쭉 쓰려면 이상하게 글자가 깨지는 경우도 많았다. 어찌보면 오버플로 비슷한 것이다. 이는 PC통신 시절 개행된 글이 많이 보이는 이유 중 하나이기도 했다.

2.7. 한 바이트가 잘림

일명 '홰영구셀' 현상으로 불린다. 2바이트 이상이 한 문자를 이루는 멀티바이트 문자셋에서 앞의 한 바이트가 잘리는 바람에 완전히 다른 문자로 둔갑해 버리는 현상이다. 이 현상으로 인해 가장 피해를 많이 입은 문장이 바로 '안녕하세요'인데, PC통신 시절에는 '안녕하세요'로 글을 시작하는 경우가 많았기 때문에 자연히 '안녕하세요'가 '홰 聆 究셀?'로 둔갑하는 사례가 많았다. 이런 경우 깨지는 범위는 확장 아스키 문자의 연속이 끝나는 구간까지이다. 즉 '안녕하세요' 다음에 공백이나 줄바꿈 등 기본 아스키 문자가 이어지면 '홰聆究셀?' 까지만 깨진 것이 보이고 그 뒤로는 정상적으로 보인다.

KS X 1001 문자셋으로 된 '안녕하세요'의 바이트 값을 2바이트씩 잘라서 쓰면 BEC8 B3E7 C7CF BCBC BFE4인데 여기서 맨 앞의 BE가 잘리게 되면 C8 B3E7 C7CF BCBC BFE4가 되고 이를 C8B3 E7C7 CFBC BCBF E4로 해석한 결과가 '홰聆究셀?'인 것. 이런 식으로 문자 깨짐이 일어난 경우 맨 첫 바이트를 지우면 첫 글자를 제외한 나머지 글자가 정상적으로 드러나며, 손실된 첫 글자도 바이트와 문맥 등을 보면서 복원해낼 수 있다.

문자 깨짐은 아니지만 KS X 1001(EUC-KR) 인코딩 환경에서 ' 좆'이라는 글자를 필터링 대상에 추가하면 '어려운', '두려운' 등 '려운'이 들어가는 글을 쓸 수 없는 문제가 발생하는 것도 이 현상과 관련이 있다.

UTF-8에서는 한글이 1110xxxx 10xxxxxx 10xxxxxx의 형식의 3바이트로 저장되고 x의 자리에 해당 글자의 포인터 값이 들어가는 식이다. 첫 바이트와 나머지 두 바이트의 구조가 다르기 때문에 첫 바이트가 잘리는 현상이 일어나도 첫 글자만 깨지고 나머지 글자들은 정상적으로 보인다.

2.8. 특정 문자를 표시해 줄 글꼴 없음

정식 명칭은 누락된 글리프(missing glyph). 이는 문자 인코딩과는 관련이 없고 정보 손실과도 상관이 없다.

코드 값 자체는 손실 없이 그대로 보존됐으나, 사용 중인 시스템에서 해당 코드 값을 가진 문자를 지원하는 글꼴이 없어서 올바른 모양으로 보여 줄 수 없는 경우이다. 주로 유니코드에 추가된 지 얼마 되지 않은 문자(예: 새로 추가된 이모지)를 쓸 때 이 문제가 생기는데, 단순히 그 문자를 지원하는 글꼴을 적용하면 된다.

파일:폰트깨짐-왜날뷁.png
[23]
파일:퀴과상 문자 깨짐.jpg
▲ 퀴즈! 과학상식 유튜브 크리에이터편의 한 장면
파일:뷁뷁뷁뷁!!.jpg
"금영반주기.디스코메들리.번지없는주막외. 전곡가사첨부"라는 영상의 4분 24초 쯤에서 설운도 - 나침반(설운도) 가사 부분에서 "아무리 찾아바[24]도 그 사람은 간 곷[25]이 없네" [26]

현대 한글 11,172자 중 KS X 1001 완성형의 2,350자만 지원하는 글꼴[27]을 사용하는 경우에도 이런 현상을 볼 수 있다. 그런 글꼴로 '정말 뷁스럽군!'이라고 써 보면 '정말'과 '스럽군!'은 제대로 표시되지만 '뷁'은 글꼴에서 지원되지 않아 굴림체나 바탕체 로 문자 깨짐 현상이 일어난다. 나눔고딕은 뷁이 멀쩡히 나온다. 하지만 나눔스퀘어는 아예 공백으로 처리된다. 이유는 2,350자 이외의 한글 글리프를 공백으로 해버렸기 때문. 또한 아래아 한글에만 쓸 수 있는 전용 폰트에서도 완성형 폰트들의 경우 마찬가지로 이러한 현상들이 있다.

Adobe Photoshop을 비롯한 어도비 계열의 그래픽 툴들은 누락된 글리프 보호[28]가 기본적으로 켜진 상태로 설치되므로, 해당설정을 끄지않고 작업하는 경우 뷁어 현상이 발생하면 해당 글씨창 전체가 한글 윈도우 기준 굴림으로 변신한다! 설정을 꺼주면 이전 글씨체는 온전한 대신 지원하지 않는 글자는 엑박이 뜬다.

한국어 번역이된 해외 게임 닉네임에서 이런 현상이 많다.

됐을 '됬'이라고 잘못 적는 경우가 많은데, 이 글자 역시 완성형에 없기 때문에 글자가 깨져 보이는 경우가 많다.강제 맞춤법 교정

Fallback되는 시스템 글꼴에도 글자가 없는 경우 아예 글자가 네모 안에 X 표시가 있는 상자(경우에 따라 다르게 표시될 수도 있음)로 표시되기도 하는데, 이를 tofu라고 부른다.

2.9. 글꼴의 문제

나눔고딕ET 등 일본어 게임의 한글 지원을 위해 제작된 글꼴이 설치되어 있는 경우, 글꼴이 충돌해 몇몇 한자가 한글로 보인다. 예시로 든 나눔고딕ET의 경우 'Preferred Family' 부분이 나눔고딕과 같은데, 이 때문에 충돌하는 경우가 많다.

3. 해결 방법

인코딩 오류인 경우에는 인코딩을 바꿔 주면 된다. 프로그램 인코딩의 경우 과거에는 AppLocale이 주로 쓰였으나, Windows 10에서 작동하지 않는 관계로 NTLEA나 Locale Emulator 등을 써야 한다. 제어판에서 시스템 로캘[29]을 바꿔도 되지만, 이 경우 반대로 한글 프로그램이 깨져 작동불능이 되므로 권장하지 않는다. 텍스트 파일의 경우 Notepad++ 프로그램으로 연 다음 인코딩을 선택해주면 된다.

데이터가 손실된 경우에는 파일을 다시 구하거나 작성하는 방법밖에 없다. 주의할 점은 인코딩 오류로 깨진 파일을 그대로 저장해 버리면 실제로 데이터가 손실될 가능성이 매우 높기 때문에 함부로 저장 버튼을 클릭하지 않도록 주의해야 한다. 이유는 해당 인코딩에서 유효하지 않은 바이트들은 모조리 ?나 �로 치환되어 복구할 수 없도록 바뀌기 때문이다.

글꼴 문제는 글꼴을 바꾸기만 하면 된다. 정 그 글꼴을 사용하고 싶다면 해당 글꼴에서 지원하지 않는 문자를 사용하지 않는 방법밖에 없다.

인코딩 문제를 피하고 싶다면 가급적 UTF-8[30]로 저장하는 습관을 들이도록 하자. 메모장에서는 ANSI 형식으로 저장할 때 지원하지 않는 문자가 포함되면 손실될 수 있다는 경고창을 띄우는데, 이때 '취소' 버튼을 누른 다음 인코딩을 'UTF-8'로 선택해주자.

NFC ↔ NFD가 문제가 된다면, 문자열 인코딩을 전환해주는 웹사이트( #, # #등) 통해서 문자열을 변환받아 복사해 오던가, 파일명 변환 프로그램( #, #, # 등)을 이용해서 문자열을 정상화시키면 된다.

만약 압축한 파일의 제목이 깨진다면, 압축포멧을 ZIP가 아니라 7-Zip(7z)로 하면 해결될 확률이 높다.

3.1. 한글 인코딩 깨짐 예

한글 깨짐 처리의 예시[31]
글자 깨짐 한글
Á¿î 좌운

4. 관련 문서

[1] 일명 Latin-1이라고 불리는 코드 체계로 아메리카 대륙과 서유럽에서 많이 쓰였다. [2] 마이크로소프트가 만든, ISO/IEC 8859-1의 아종. [3] 문자 깨짐 호환성 테스트 https://uv337.github.io/ [4] 예전 Roblox에서도 이러한 문제가 발생했다. [5] 한국어 환경에서 웹페이지에 인코딩 정의를 안 한 영어권 웹사이트에 들어갈 경우 자주 볼 수 있다. 또 스타크래프트: 브루드 워 테란 미션 선택 창에서 이런 오류가 발생하는 것을 볼 수 있다. [6] 구버전 AIDA64에서 흔히 볼 수 있는 오류로, 현재도 언어를 'English'로 설정하면 이렇게 나온다. 캟빈 [7] 청계천 한글 코드에서는 ASCII 코드의 라틴 문자 소문자 + 대문자 조합에 해당하는 코드 넘버에도 한글을 할당하였기 때문에 이런 현상이 발생했다. [8] 실제로 이 게임은 '특훈99'보다 '벫똏'으로 훨씬 더 잘 알려져 있다. [9] 전각 문자. [10] 일본 웹상에서 암호로 종종 쓰인다. [11] 레인보우 스네이크 헤드을 의미하는 것으로 보인다. [12] 영어로 하면 타겟 어스인데 이는 레이노스의 북미수출명. [13] 자이로마이트. [14] 코나미의 패미컴 게임 모아이군. [15] 단어 자체는 크레이지 카트 혹은 크레이지레이싱을 의미. [16] 직역하면 '로켓 차'이지만 로드파이터도 의미. [17] 스파이 VS 스파이라는 고전게임. [18] 코드네임 바이퍼. 1990년 캡콤 제작의 패미컴 게임. [19] 스파이 헌터. [20] 2010년대 이후로는 더 이상 이런 문제가 생기지 않는다. [21] replacement character는 '대체 문자'를 뜻한다. [22] 베스트 댓글에서 이것을 해독한 용자가 있다! [23] 예시의 폰트는 다음체다. [24] 봐 [25] 곳 [26] 여기서 해당 글꼴에는 바라는 글자가 있지만, 곷이라는 글자가 만들어지지 않았기 때문에 굴림체로 뜬다. [27] 이런 글꼴이 많은 이유는 간단한데, 제작 시간 및 용량 등을 아끼기 위해서이다. [28] 영문판 기준 Missing Glyph Protection. [29] 흔히 유니코드 변경이라고 하지만 이는 잘못된 용어이다. 윈도우 XP까지는 로케일이라 표기했지만 외래어 표기법에 어긋나기 때문에 윈도우 비스타부터는 로캘로 수정되었다. [30] UTF-16은 엔디안 문제 때문에 권장되지 않는다. 다른 시스템으로 가면 호환성 문제가 생긴다. [31] 한글 깨짐 복구 웹사이트 https://hangulnara.github.io/

분류