문자 깨짐 - 위키백과, 우리 모두의 백과사전

헝가리어에서는 이 현상을 "글자 쓰레기"를 의미하는 'betűszemét'이라고 부른다. 헝가리어는 특히 이 현상에 취약했는데, 이는 라틴-1 문자 세트에 있는 모든 악센트 문자(á, é, í, ó, ú, ö, ü)와 라틴-1에 없는 ő 및 ű 두 문자를 포함하기 때문이다. 이 두 문자는 라틴-2, Windows-1250 및 유니코드에서 올바르게 인코딩될 수 있다. 그러나 유니코드가 이메일 클라이언트에서 보편화되기 전에는 헝가리어 텍스트가 포함된 이메일에서 ő 및 ű 문자가 종종 손상되어 알아보기 어려울 정도였다. 손상된 이메일에 모든 헝가리어 악센트 문자를 포함하는 의미 없는 구절인 "Árvíztűrő tükörfúrógép"(문자 그대로 "홍수 방지 거울 드릴링 머신")으로 답하는 것이 일반적이다.

1987년 ISO 8859-2가 만들어지기 전에 다양한 컴퓨팅 플랫폼 사용자들은 아미가에서는 AmigaPL, 아타리 ST에서는 Atari Club, 그리고 IBM PC에서는 Masovia, 코드 페이지 852, 마조비아 및 Windows-1250과 같은 자체 문자 인코딩을 사용했다. 초기 도스 컴퓨터를 판매하던 폴란드 회사들은 폴란드어 문자를 인코딩하는 서로 호환되지 않는 자체적인 방식을 만들었고, 단순히 EPROM 비디오 카드(일반적으로 컬러 그래픽스 어댑터, 강화 그래픽 어댑터, 또는 허큘리스 그래픽 카드)를 재프로그래밍하여 다른 컴퓨터 판매자들이 문자를 배치했던 위치와 전혀 상관없이 임의의 위치에 필요한 폴란드어 하드웨어 코드 페이지 글리프를 제공했다.

학계 및 사용자 그룹의 압력으로 ISO 8859-2가 지배적인 공급업체 소프트웨어의 제한된 지원과 함께 "인터넷 표준"으로 성공하면서 상황이 개선되기 시작했다(오늘날에는 대부분 유니코드로 대체되었다). 다양한 인코딩으로 인한 수많은 문제 때문에 오늘날에도 일부 사용자들은 폴란드어 발음 구별 기호 문자를 krzaczki([ˈkʂät͜ʂ.ki], 문자 그대로 "작은 관목")라고 부르곤 한다.

문자 깨짐은 러시아어에서 구어적으로 krakozyabry(кракозя́бры ru)라고 불리며, 이는 키릴 문자 인코딩 시스템이 여러 개로 복잡해졌고 여전히 복잡한 문제로 남아 있다.^[7] 소련과 초기 러시아 연방은 KOI 인코딩(Kod Obmena Informatsiey, Код Обмена Информацией, "정보 교환 코드"로 번역됨)을 개발했다. 이는 ASCII를 기반으로 라틴 문자 및 기타 일부 문자를 키릴 문자로 대체한 키릴 전용 7비트 KOI7로 시작되었다. 이어서 8비트 KOI8 인코딩이 등장했는데, 이는 확장 ASCII 확장으로, 7비트 KOI7의 코드에 해당하는 상위 비트 설정 옥텟으로만 키릴 문자를 인코딩한다. 이러한 이유로 러시아어와 같은 KOI8 텍스트는 8번째 비트를 제거한 후에도 부분적으로 읽을 수 있는데, 이는 8BITMIME을 인식하지 못하는 이메일 시스템 시대에 큰 장점으로 여겨졌다. 예를 들어, KOI8로 인코딩된 "Школа русского языка" (shkola russkogo yazyka)라는 단어가 상위 비트 제거 과정을 거치면 "[KOLA RUSSKOGO qZYKA"로 렌더링된다. 결국 KOI8은 러시아어와 불가리아어(KOI8-R), 우크라이나어(KOI8-U), 벨라루스어(KOI8-RU), 심지어 타지크어(KOI8-T)를 위한 다양한 변형을 가지게 되었다.

한편, 서양에서는 코드 페이지 866이 MS-DOS에서 우크라이나어와 벨라루스어뿐만 아니라 러시아어와 불가리아어도 지원했다. 마이크로소프트 윈도우의 경우, Windows-1251은 세르비아어 키릴 문자 및 기타 슬라브 키릴 문자 변형에 대한 지원을 추가했다.

가장 최근에는 유니코드 인코딩이 모든 언어의 거의 모든 문자, 포함한 모든 키릴 문자에 대한 코드 포인트를 포함한다.

유니코드 이전에는 텍스트 인코딩과 동일한 인코딩 시스템을 사용하는 글꼴을 일치시켜야 했다. 이를 실패하면 특정 텍스트와 글꼴 인코딩의 조합에 따라 특정 모양이 달라지는 읽을 수 없는 엉터리 문자가 생성되었다. 예를 들어, 라틴 알파벳으로 제한되거나 기본("서유럽") 인코딩을 사용하는 글꼴을 사용하여 비유니코드 키릴 텍스트를 보려고 시도하면, 일반적으로 발음 구별 기호가 있는 대문자 모음으로 거의 전적으로 구성된 텍스트가 나타난다(예: KOI8 "Библиотека"(biblioteka, 도서관)는 "âÉÂÌÉÏÔÅËÁ"가 되고, "Школа русского языка"(shkola russkogo yazyka, 러시아어 학교)는 "ûËÏÌÁ ÒÕÓÓËÏÇÏ ÑÚÙËÁ"가 된다). 코드 페이지 1251을 사용하여 KOI8 텍스트를 보거나 그 반대로 하면 대부분 대문자로 구성된 깨진 텍스트가 나타난다(KOI8과 코드 페이지 1251은 동일한 ASCII 영역을 공유하지만, KOI8은 코드 페이지 1251이 소문자를 가지는 영역에 대문자를 가지고 그 반대도 마찬가지이다).

월드 와이드 웹의 러시아어 부문 초기에는 KOI8과 코드 페이지 1251이 모두 흔했다. 거의 모든 웹사이트는 이제 유니코드를 사용하지만, 2023년 11월 기준^[update] 전 세계 웹 페이지의 약 0.35%(모든 언어 포함)는 여전히 코드 페이지 1251로 인코딩되어 있으며, 0.003% 미만의 사이트만이 여전히 KOI8-R로 인코딩되어 있다.^[8][9] HTML 표준에는 주어진 웹 페이지의 인코딩을 소스에서 지정하는 기능이 포함되어 있지만,^[10] 이는 때때로 간과되어 사용자가 브라우저에서 인코딩을 수동으로 전환해야 한다.

불가리아어에서는 문자 깨짐을 종종 "원숭이 [알파벳]"을 의미하는 majmunica(маймуница)라고 부른다. 세르비아어에서는 "쓰레기"를 의미하는 đubre(ђубре)라고 부른다. 구 소련과는 달리, 남슬라브족은 KOI8과 같은 것을 사용한 적이 없으며, 유니코드 이전에 코드 페이지 1251이 지배적인 키릴 문자 인코딩이었다. 따라서 이 언어들은 러시아어보다 인코딩 비호환성 문제를 덜 겪었다. 1980년대에는 불가리아 컴퓨터들이 자체 MIK 인코딩을 사용했는데, 이는 CP866과 표면적으로는 유사하지만 호환되지 않는다.

크로아티아어, 보스니아어, 세르비아어 (세르보크로아트어에서 분리된 방언들) 및 슬로베니아어는 기본 라틴 알파벳에 š, đ, č, ć, ž와 그 대문자 Š, Đ, Č, Ć, Ž를 추가한다 (슬로베니아어에서는 č/Č, š/Š, ž/Ž만 공식적으로 사용되지만, 필요할 때 주로 외국어 이름에 다른 문자들도 사용된다). 이 모든 문자는 라틴-2 및 Windows-1250에 정의되어 있으며, 일부(š, Š, ž, Ž, Đ)만 일반적인 OS 기본 Windows-1252에 존재하는데, 이는 다른 언어들 때문인 것이다.

이러한 문자들 중 어느 것이든 문자 깨짐이 발생할 수 있지만, Windows-1252에 포함되지 않은 문자들이 오류에 훨씬 더 취약하다. 따라서 오늘날에도 "šđčćž ŠĐČĆŽ"는 종종 "šðèæž ŠÐÈÆŽ"로 표시되지만, ð, È, Æ는 슬라브어에서 사용되지 않는다.

기본 ASCII로 제한될 경우(예: 대부분의 사용자 이름), 일반적인 대체 문자는 š→s, đ→dj, č→c, ć→c, ž→z이다(대문자 형식은 단어의 대소문자에 따라 Đ→Dj 또는 Đ→DJ와 같이 유사하게 적용된다). 이러한 모든 대체는 모호성을 유발하므로, 이러한 형식에서 원본을 재구성하는 것은 필요한 경우 일반적으로 수동으로 이루어진다.

Windows-1252 인코딩은 지역화된 버전이 아닌 영어 버전의 Windows 운영체제가 가장 널리 사용되기 때문에 중요하다. 그 이유는 상대적으로 작고 파편화된 시장으로 인해 고품질 지역화 비용이 증가하고, 높은 수준의 소프트웨어 불법 복제(소득 대비 소프트웨어 가격이 높기 때문에 발생)로 인해 지역화 노력이 저해되며, 사람들이 영어 버전의 Windows 및 기타 소프트웨어를 선호하기 때문이다.

크로아티아어와 세르비아어, 보스니아어와 크로아티아어 및 세르비아어, 그리고 이제는 몬테네그로어와 다른 세 언어를 구분하려는 움직임은 많은 문제를 야기한다. 다양한 표준과 다양한 품질을 사용하는 다양한 지역화가 있다. 영어에서 유래한 방대한 컴퓨터 용어에 대한 공통 번역이 없다. 결국 사람들은 영어 차용어("computer"를 "kompjuter"로, "compile"을 "kompajlirati" 등으로)를 사용하며, 번역된 용어에 익숙하지 않은 경우 번역된 문구만으로는 메뉴의 어떤 옵션이 무엇을 해야 하는지 이해하지 못할 수 있다. 따라서 영어를 이해하는 사람들과 영어 용어에 익숙한 사람들(이러한 문제로 인해 학교에서도 영어 용어가 주로 가르쳐지기 때문에 대부분의 사람들)은 일반적으로 비전문가용 소프트웨어의 원본 영어 버전을 선택한다.

마케도니아어 및 부분적으로 세르비아어에 키릴 문자가 사용될 경우, 문제는 다른 키릴 문자 기반 문자와 유사하다.

최신 영어 Windows 버전에서는 코드 페이지를 변경할 수 있지만(이전 버전에서는 이 기능을 지원하는 특수 영어 버전이 필요함), 이 설정은 잘못 설정될 수 있고 종종 잘못 설정되었다. 예를 들어, 윈도우 98 및 윈도우 미는 1250을 포함한 대부분의 비우선순위 단일 바이트 코드 페이지로 설정할 수 있지만, 설치 시에만 가능하다.

베트남어에서는 이 현상을 chữ ma(한월: 𡨸魔, "귀신 문자") 또는 loạn mã(중국어 乱码에서 유래)라고 부른다. 컴퓨터가 UTF-8로 인코딩된 텍스트를 Windows-1258, TCVN3 또는 VNI로 디코딩하려고 할 때 발생할 수 있다. 베트남에서는 윈도우 비스타 이전 버전의 윈도우를 실행하는 컴퓨터나 저렴한 휴대폰에서 chữ ma가 흔히 목격되었다.

일본에서는 다양한 일본어 텍스트 인코딩이 많아 문자 깨짐이 특히 문제가 된다. 유니코드 인코딩(UTF-8 및 UTF-16) 외에도 Shift JIS(Windows 시스템) 및 EUC-JP(유닉스 시스템)와 같은 다른 표준 인코딩이 있다. 오늘날까지도 일본 시장을 위해 작성된 소프트웨어를 실행하려고 할 때 일본인과 비일본인 모두 문자 깨짐을 자주 접한다.

중국어에서는 같은 현상을 '혼란스러운 코드'를 뜻하는 Luàn mǎ(한어병음, 간체자 乱码, 번체자 亂碼)라고 부르며, 컴퓨터 텍스트가 한 중국어 문자 인코딩으로 인코딩되었지만 잘못된 인코딩을 사용하여 표시될 때 발생할 수 있다. 이 경우 문자 인코딩을 변경하여 데이터 손실 없이 문제를 해결할 수 있는 경우가 많다. 이 상황은 여러 중국어 문자 인코딩 시스템(가장 일반적인 것은 유니코드, Big5, 궈뱌오 코드와 여러 하위 호환 버전)의 존재와 일본어 인코딩을 사용하여 중국어 문자가 인코딩될 가능성 때문에 복잡하다.

궈뱌오 인코딩에서 luànmǎ가 발생하면 원본 인코딩을 식별하기가 비교적 쉽다.

중국어에서 추가적인 문제는 개인이나 지명에 여전히 사용되는 희귀하거나 고풍스러운 문자가 일부 인코딩에 존재하지 않을 때 발생한다. 그 예시는 다음과 같다.

• Big5 인코딩에 중화민국 정치인 왕젠쉬엔(중국어 정체자: 王建煊, 병음: Wáng Jiànxuān)의 이름에 있는 "煊"(xuān), 유시쿤(중국어 간체자: 游锡堃, 정체자: 游錫堃, 병음: Yóu Xíkūn)의 이름에 있는 "堃"(kūn), 가수 타오저(중국어 정체자: 陶喆, 병음: Táo Zhé)의 이름에 있는 "喆"(zhé)가 없는 경우
• GB 2312에 전 PRC 총리 주룽지(중국어: 朱镕基, 병음: Zhū Róngjī)의 "镕"(róng)이 없는 경우
• GBK에 저작권 기호 "©"가 없는 경우^[11]

신문사들은 누락된 문자를 다양한 방식으로 처리해왔는데, 이미지 편집 소프트웨어를 사용하여 다른 부수와 문자를 결합하여 합성하거나, 인물의 경우 사진을 사용하거나, 독자들이 올바른 추론을 할 수 있기를 바라며 단순히 동음이의어를 대체하는 식이다.

유사한 효과는 남아시아의 브라흐미계 문자에서도 발생할 수 있는데, 이는 힌두스탄어(힌디어-우르두어), 벵골어, 펀자브어, 마라티어 등과 같은 인도아리아어군에서 사용되며, 심지어 사용된 문자 세트가 애플리케이션에 의해 제대로 인식되는 경우에도 발생할 수 있다. 이는 많은 인도 문자에서 개별 글자 기호가 결합하여 음절 기호를 생성하는 규칙이 적절한 소프트웨어가 없는 컴퓨터에서는 제대로 이해되지 않을 수 있기 때문이며, 개별 글자 형태의 글리프가 사용 가능하더라도 마찬가지이다.

이것의 한 예시가 오래된 위키백과 로고인데, 여러 퍼즐 조각 각각에 "wi"(위키백과의 첫 음절)와 유사한 문자를 표시하려고 시도한다. 데바나가리 문자로 "wi" 문자를 나타내야 하는 퍼즐 조각은 대신 "wa" 문자와 짝을 이루지 않는 "i" 변형 모음을 표시했으며, 이는 인도어 텍스트를 표시하도록 구성되지 않은 컴퓨터에서 생성된 문자 깨짐으로 쉽게 인식할 수 있다.^[12] 2010년 05월 기준^[ref]에 다시 디자인된 로고는 이러한 오류들을 수정했다.

일반 텍스트의 개념은 운영 체제가 유니코드 코드를 표시할 글꼴을 제공해야 한다는 것이다. 이 글꼴은 싱할라어의 경우 OS마다 다르며, 모든 운영 체제에서 일부 글자(음절)에 대해 정형학적으로 틀린 글리프를 생성한다. 예를 들어, 짧은 'r' 형태인 '레프'는 일반적으로 일반 글자 위에 오는 발음 구별 기호이다. 그러나 특정 상황에서 '야'나 '라'와 같은 일부 글자 위에 오면 잘못된 것이다. 산스크리트어 단어나 현대 언어에 계승된 이름, 예를 들어 कार्य, IAST: kārya, 또는 आर्या, IAST: āryā의 경우 이러한 글자 위에 오는 것이 적절하다. 대조적으로, 현대 언어에서 특정 규칙으로 인해 발생하는 유사한 소리의 경우, 예를 들어 마라티어의 일반적인 단어 करणारा/री, IAST: karaṇārā/rī의 어간 형태인 करणाऱ्या, IAST: karaṇāryā와 같이 위에 오지 않는다.^[13] 하지만 대부분의 운영 체제에서 이런 현상이 발생한다. 이는 글꼴의 내부 프로그래밍 문제로 보인다. Mac OS와 iOS에서는 muurdhaja l(어두운 l)과 'u' 조합 및 그 장형 모두 잘못된 형태를 생성한다.

일부 인도 및 인도계 문자, 특히 라오 문자는 윈도우 비스타 출시 전까지 윈도우 XP에서 공식적으로 지원되지 않았다.^[14] 그러나 다양한 사이트에서 무료로 다운로드할 수 있는 글꼴을 만들었다.

서구의 제재^[15]와 컴퓨터에 버마어 지원이 늦게 도입된 탓에,^[16][17] 초기 버마어 지역화의 상당수는 국제 협력 없이 국내에서 이루어졌다. 버마어 지원의 주요 수단은 조지 글꼴을 통하는 것인데, 이 글꼴은 유니코드 글꼴로 만들어졌지만 실제로는 유니코드 준수가 부분적으로만 이루어졌다.^[17] 조지 글꼴에서는 버마어 스크립트의 일부 코드 포인트는 유니코드에 명시된 대로 구현되었지만, 다른 일부는 그렇지 않았다.^[18] 유니코드 컨소시엄은 이를 애드혹(ad hoc) 글꼴 인코딩이라고 부른다.^[19] 휴대폰의 등장과 함께 삼성과 화웨이와 같은 모바일 공급업체는 유니코드 준수 시스템 글꼴을 조지 버전으로 단순히 대체했다.^[16]

이러한 임시 인코딩으로 인해 조지 글꼴 사용자와 유니코드 사용자 간의 통신은 깨진 텍스트로 렌더링된다. 이 문제를 해결하기 위해 콘텐츠 제작자들은 조지 글꼴과 유니코드로 동시에 게시물을 작성하곤 했다.^[20] 미얀마 정부는 2019년 10월 1일을 유니코드로 공식 전환하는 "U-데이"로 지정했다.^[15] 전체 전환에는 2년이 걸릴 것으로 예상되었다.^[21]