문자 깨짐
1. 개요
컴퓨터 등 IT 기기에서 문자가 올바르게 표시되지 않는 경우. 보통 '문자가 깨지는 현상'으로 부르기에 '문자 깨짐'이라는 문서명으로 되었다. 인터넷 속어로 '''뷁어'''라고 부르기도 해서, 이러한 인코딩 문제를 해결해주는 프로그램을 흔히 '''뷁어번역기'''라고 부른다. 문자가 깨지면서 출력되는 획수가 많은 확장완성형 한글이 과거 유행어였던 뷁을 떠올리게 해 이렇게 부르기 시작한 것인데, 뷁의 원래 어원이 'break it'이란 걸 생각해보면 의미까지 적절한 번역인 셈. 인터넷에 돌아다니는 '''뷁어번역기'''는 일본어 문자가 깨진 경우 사용하는 것인데 원리는 간단하게 말하자면 CP949로 작성된 텍스트를 Shift_JIS로 변환하는 것이다.
일본어에서는 문자 깨짐을 '''모지바케'''(文字化け, mojibake)라고 하며 영어권에도 이 용어가 수입돼 이 현상을 그냥 mojibake라고 부른다.
2. 일어나는 경우
2.1. 다른 인코딩으로 읽었을 경우
텍스트 작성에 쓰인 문자 인코딩과 텍스트를 열 때의 문자 인코딩이 다른 경우로, EUC-KR(또는 CP949)로 작성된 텍스트를 Windows-1252로 열었을 경우, 또는 Shift_JIS로 작성된 텍스트를 CP949로 열었을 경우 등이 있다. 이런 경우는 텍스트 작성에 쓰인 문자 인코딩으로 다시 읽어 주거나, 인터넷에서 '뷁어 번역기'를 받아서 사용하면 정상적인 텍스트를 볼 수 있다. 문자 깨짐/뷁어 테이블 문서도 참조할 것.
같은 언어라고 해도 인코딩 체계가 다르면 역시 깨진다. MS-DOS 시절 한글 BIOS를 적용한 한글 DOS를 쓰면서 조합형을 완성형으로 변환하거나, 그 반대의 경우를 해봤다면 알 것이다.
[image]
- ASCII ↔ UTF-16
- Bush hid the facts ↔ 畂桳栠摩琠敨映捡獴
- EUC-KR/CP949 ↔ ISO/IEC 8859-1[1] 또는 Windows-1252[2]
- 문자 깨짐 테스트 ↔ ¹®ÀÚ ±úÁü Å×½ºÆ®
- [image]
- 스타크래프트에서 한글 지원을 안 하던 1.12(2005) 이전 시절에 억지로 한글을 치면 이런 식으로 깨졌다.
- ISO/IEC 8859-1 또는 Windows-1252 ↔ CP949
- ’s ↔ 뭩[3]
- °C ↔ 캜, °F ↔ 캟[4]
- ASCII ↔ 7비트 2바이트 완성형 한글 코드(일명 청계천 한글)
- dBase ↔ 늦ase[5]
- Shift_JIS ↔ MS949
- こんにちは ↔ 궞귪궸궭궼
- ソウル → ?긂깑
- Ryu☆ ↔ Ryu걲
- 冥 ↔ 뼸
- 特訓 ↔ 벫똏[6]
- 東方 ↔ 뱦뺴
- 猫叉Master ↔ 봍뜵Master
- 猫叉王子 ↔ 봍뜵돞럔
- 斬る·ビル ↔ 럂귡긮깑
- 音楽 ↔ 돶뒁
- 桜 ↔ 랎
- Ｖ[7] ↔ 놶
- 誹 ↔ 뷁
- 力 ↔ 쀍
- しょぼんのアクション ↔ 궢귛귍귪궻귺긏긘깈깛
- クレヨンしんちゃん ↔ 긏깒깉깛궢귪궭귗귪
- Shift_JIS ↔ UTF-16
- 繧ゅ⊆繧ゅ⊆縺｣縺ｦ縺ｪ繧薙〒縺吶° ↔ もぺもぺってなんですか
- EUC-CN ↔ EUC-KR/MS949
- 猫叉Master ↔ 챔꿩Master
- 火龙 ↔ 삽질
- 首尔 ↔ 看랑
- 魂斗罗 ↔ 산떱쭈
- 东京热 ↔ 땜쑴훑
- 法拉利赛车 ↔ 랬윗적힙났
- 七彩龙[8] ↔ 폄꽈질
- 高尔夫球 ↔ 멕랑뤼헷
- 究极虎 ↔ 씩썜빪
- 埃及 ↔ 간섟
- 目标地球[9] ↔ 커깃뒈헷
- 机器人格罗[10] ↔ 샙포훙목쭈
- 疯狂大脚 ↔ 룩욺댕신
- 宾果 ↔ 깟벎
- 打气泡 ↔ 댔폭텟
- 滑板 ↔ 뺄겼
- 阿拉丁 3 ↔ 각윗땀 3
- 保龄球 ↔ 괏줙헥
- 摩艾君[11] 칡갔엌
- 扑克方块 ↔ 팝옹렘욥
- 超级玛丽 ↔ 낚섬쯔쟝
- 忍者 ↔ 땃뎟
- DJ 男孩 ↔ DJ 켕벗
- 仓库番 ↔ 꾑욋랸
- 美国大兵 ↔ 쳄벌댕깡
- 火炮 ↔ 삽텔
- 超级马里奥 ↔ 낚섬쯩쟁걔
- 柏青哥 ↔ 겝행며
- 企鹅和海豹 ↔ 폐띠뵨베괭
- 雷鸟号 ↔ 잉쿰뵀
- 大蜜蜂 ↔ 댕쵯룝
- 敲冰块 ↔ 플깝욥
- 疯狂赛车[12] ↔ 룩욺힙낫
- 火鸡 ↔ 삽샷
- 金刚 ↔ 쏜먼
- 火箭车[13] ↔ 삽숬낫
- 冲击波 ↔ 녑샌꺼
- 雷电 ↔ 잉든
- 谍对谍[14] ↔ 딴뚤딴
- 人间兵器[15] ↔ 훙쇌깡포
- 恶魔城 2 ↔ 띳침냘 2
- 间谍猎人[16] - ↔ 쇌딴죤훙
- 将棋秘传 ↔ 쉥펙쵤눈
- 比卡丘 ↔궐엥헴
- 七宝谋奇 ↔ 펌괜캇펜
- 崩坏3 ↔ 굼뻐3 (#)
- 马卡洛夫 ↔ 쯩엥쭤리
- 李-恩菲尔德 ↔ 쟀-람렵랑돠
- 利贝罗勒 ↔ 적굔쭈잇
- 内格夫 ↔ 코목뤼
- 布伦 ↔ 꼈쬈
- 赫丽安 ↔ 붐쟝갛
- 格林娜 ↔ 목주컹
- 克鲁格 ↔옹쨀목
- 诺爱尔梵蜜莉欧 ↔ 킵갖랑拗쵯쟌킹
- 克莉尔 ↔ 옹쟌랑
- 皮卡丘 ↔ 튄엥헴
- 天安门广场 ↔ 莖갛쳔밤끝
- UTF-8 ↔ EUC-KR(cp949)
- 全てあなたの所為です。 ↔ 押ⓦ겍徇귙겒徇잆겗偃?縯뷩겎徇쇻?
- UTF-8 ↔ EUC-JP
- 魔方大厦 ↔ 鬲疲婿螟ｧ蜴ｦ
2.2. 인코딩 정규화 방식이 다른 경우
윈도우 PC와 애플 맥과의 한글파일명 파일을 교환할 때 발생하는 문제이다. 자소 각 코드를 조합해서 표현할지, 자소가 합쳐져 있는 문자의 완성형 코드로 표현할지가 달라서 발생한다.
기술적으로 서술하자면, 서로 다른 유니코드 정규화 방식(Windows NFC ↔ macOS NFD)에 따라 모음과 자음이 분리되어 풀어쓰기처럼 변한다. 해당 규칙은 현대 한글 NFC ↔ NFD 변환 테이블 참고.
- NFC(Windows) ↔ NFD(macOS)
- 10대힙합 ↔ 10ㄷㅐㅎㅣㅂㅎㅏㅂ
2.3. 문자 코드 읽는 순서가 맞지 않는 경우
MBCS의 엔디안 문제로서 리틀 엔디안 빅 엔디안의 코드 읽고 쓰는 순서가 달라서 생기는 문제이다. 예를 들자면, 앞 숫자와 뒷 숫자를 바꿔 읽으면 46≠64처럼 전혀 생뚱맞은 다른 숫자(다른문자코드)가 되는 것과 같다. 46을 저장할때 64로 저장하는 시스템이 있는 이유는, 0046보다 64로 처리하는 것이 효율적이라는 장점이 있기 때문이다.
이 문제를 해결하기 위해 UTF-8을 도입하게 되었으며, 왠만한 곳(서버, 파일, 웹)에서는 이 인코딩으로 저장하길 권장한다.
2.4. 정보 자체가 손실된 경우
텍스트 저장 과정에서 문제가 생긴 경우로, 원문을 완전히 복원해 낼 수 없다. UTF-8로 문서를 저장할 때 저장 과정에 문제가 생겨 일부 텍스트가 �(U+FFFD, REPLACEMENT CHARACTER[17])로 변하는 경우 등이 이에 해당된다. 한때 이글루스를 환장하게 만들었던 占쏙옙도 이와 관련이 있다.
현재 사용 중인 문자 인코딩이 처리할 수 없는 문자를 넣고 저장한 경우에도 이런 문제가 생긴다(예: 한글이 섞인 문서를 Shift_JIS로 저장한 경우). 이 경우는 보통 저장 과정에서 해당 문자가 ?나 �로 대체되므로 원문을 복원해 낼 수 없다.
한때 인터넷에서 화제가 되었던 발작난 영수증도 이런 경우로 추정된다.
2.5. 출력상의 한계를 넘을 경우
PC통신상에서는 한글 터미널 편집기로 작성시 출력가능한 열이 80열까지밖에 없어서 81열 넘어서 죽 쓰려면 이상하게 글자가 깨지는 경우도 많았다. 어찌보면 오버플로 비슷한것(?). 이는 결국 PC통신상에서 개행된 글이 많이 보이는 이유중 하나이기도 하였다. 자세한것은 강제 줄 바꿈참조.
2.6. 문자를 표시해 줄 글꼴이 없는 경우
정식 명칭은 누락된 글리프(missing glyph). 이는 문자 인코딩과는 관련이 없고 정보 손실과도 상관이 없다.
코드 값 자체는 손실 없이 그대로 보존됐으나, 사용 중인 시스템에서 해당 코드 값을 가진 문자를 지원하는 글꼴이 없어서 올바른 모양으로 보여 줄 수 없는 경우이다. 주로 유니코드에 추가된 지 얼마 되지 않은 문자(예: 새로 추가된 이모지)를 쓸 때 이 문제가 생기는데, 단순히 그 문자를 지원하는 글꼴을 적용하면 된다.
[image]
(예시의 폰트는 다음체)
현대 한글 11,172자 중 KS X 1001 완성형의 2,350자만 지원하는 글꼴[18]을 사용하는 경우에도 이런 현상을 볼 수 있다. 그런 글꼴로 '정말 뷁스럽군!'이라고 써 보면 '정말'과 '스럽군!'은 제대로 표시되지만 '뷁'은 글꼴에서 지원되지 않아서 굴림체나 바탕체로 문자 깨짐 현상이 일어난다. 나눔고딕은 뷁이 멀쩡히 나온다. 하지만 나눔스퀘어는 아예 공백으로 처리된다. 이유는 2,350자 이외의 한글 글리프를 공백으로 해버렸기 때문. 또한 아래아 한글에만 쓸 수 있는 전용 폰트에서도 완성형 폰트들의 경우 마찬가지로 이러한 현상들이 있다.
한글화된 해외 게임 닉네임에서 이런 현상이 많다.
됐을 '됬'이라고 잘못 적는 경우가 많은데, 이 글자 역시 완성형에 없기 때문에 글자가 깨져 보이는 경우가 많다.
2.6.1. 글꼴에 문제가 있는 경우
나눔고딕ET 등 일본어 게임의 한글 지원을 위해 제작된 글꼴이 설치되어 있는 경우, 글꼴이 충돌해 몇몇 한자가 한글로 보인다. 예시로 든 나눔고딕ET의 경우 'Preferred Family' 부분이 나눔고딕과 같은데, 이 때문에 충돌하는 경우가 많다.
2.7. 관련 문서
3. 해결 방법
인코딩 오류인 경우에는 인코딩을 바꿔 주면 된다. 프로그램 인코딩의 경우 과거에는 AppLocale이 주로 쓰였으나, Windows 10에서 작동하지 않는 관계로 NTLEA나 Locale Emulator 등을 써야 한다. 제어판에서 시스템 로캘[19]을 바꿔도 되지만, 이 경우 반대로 한글 프로그램이 깨지므로 권장하지 않는다. 텍스트 파일의 경우 Notepad++ 프로그램으로 연 다음 인코딩을 선택해주면 된다.
데이터가 손실된 경우에는 파일을 다시 구하거나 작성하는 방법 밖에 없다. 주의할 점은 인코딩 오류로 깨진 파일을 그대로 저장해 버리면 실제로 데이터가 손실될 가능성이 매우 높기 때문에 함부로 저장 버튼을 클릭하지 않도록 주의해야 한다. 이유는 해당 인코딩에서 유효하지 않은 바이트들은 모조리 ?나 �로 치환되어 복구할 수 없도록 바뀌기 때문.
글꼴 문제는 글꼴을 바꾸기만 하면 된다. 정 그 글꼴을 사용하고 싶다면 해당 글꼴에서 지원하지 않는 문자를 사용하지 않는 방법밖에 없다.
인코딩 문제를 피하고 싶다면 가급적 UTF-8[20]로 저장하는 습관을 들이도록 하자. 메모장에서는 ANSI 형식으로 저장할 때 지원하지 않는 문자가 포함되면 손실될 수 있다는 경고창을 띄우는데, 이때 '취소' 버튼을 누른 다음 인코딩을 'UTF-8'로 선택해주자.
[1] 일명 Latin-1이라고 불리는 코드 체계로 아메리카 대륙과 서유럽에서 많이 쓰였다.[2] 마이크로소프트가 만든, ISO/IEC 8859-1의 아종.[3] 한국어 환경에서 웹페이지에 인코딩 정의를 안 한 영어권 웹사이트에 들어갈 경우 자주 볼 수 있다. 또 스타크래프트: 브루드 워 테란 미션 선택 창에서 이런 오류가 발생하는 것을 볼 수 있다.[4] 구버전 AIDA64에서 흔히 볼 수 있는 오류로, 현재도 언어를 'English'로 설정하면 이렇게 나온다.[5] 청계천 한글 코드에서는 ASCII 코드의 라틴 문자 소문자 + 대문자 조합에 해당하는 코드 넘버에도 한글을 할당하였기 때문에 이런 현상이 발생했다.[6] 실제로 이 게임은 '특훈99'보다 '벫똏'으로 훨씬 더 잘 알려져 있다.[7] 전각 문자.[8] 카멜레온을 의미하는 것으로 보인다.[9] 영어로 하면 타겟 어스인데 이는 레이노스의 북미수출명.[10] 자이로마이트.[11] 코나미의 패미컴 게임 모아이군.[12] 단어 자체는 크레이지 카트 혹은 크레이지레이싱을 의미.[13] 직역하면 '로켓 차'이지만 로드파이터도 의미.[14] 스파이 VS 스파이라는 고전게임.[15] 코드네임 바이퍼. 1990년 캡콤 제작의 패미컴 게임.[16] 스파이 헌터.[17] replacement character는 '대체 문자'를 뜻한다.[18] 이런 글꼴이 많은 이유는 간단한데, 제작 시간 및 용량 등을 아끼기 위해서이다.[19] 흔히 유니코드 변경이라고 하지만 이는 잘못된 용어이다. 윈도우 XP까지는 '''로케일'''이라 표기했지만 외래어 표기법에 어긋나기 때문에 윈도우 비스타부터는 로캘로 수정되었다.[20] UTF-16은 엔디안 문제 때문에 권장되지 않는다. 다른 시스템으로 가면 호환성 문제가 생긴다.