모지바케

Mojibake
Windows-1252 인코딩으로 해석되는 경우 표시되는 Mojibake용 UTF-8 인코딩 일본어 Wikipedia 문서
이 문서에는 특수 문자가 포함되어 있습니다.적절한 렌더링을 지원하지 않으면 물음표, 상자 또는 기타 기호가 표시될 수 있습니다.

Mojibake(일본어: 「」, IPA: 「mod」, 「ibake」)[1]는, 의도하지 않은 문자 인코딩을 사용해 디코딩 된 텍스트입니다.그 결과, 전혀 관련 없는 기호(종종 다른 문자 시스템)로 체계적으로 교체됩니다.

이 표시는 바이너리 표현이 무효라고 생각되는 위치에 범용 치환 문자("")를 포함할 수 있습니다.같은 바이너리 코드가 다른 부호화에서 하나의 기호를 구성하는 경우, 치환에는 하나의 부호화에서 볼 수 있듯이 여러 개의 연속된 심볼이 포함될 수도 있습니다.이것은, 일정한 길이의 부호화(아시아의 16비트 부호화와 유럽의 8비트 부호화의 경우와 같음)가 다르거나, 가변 길이의 부호화(특히 UTF-8 및 UTF-16)가 사용되고 있기 때문입니다.

폰트가 없거나 폰트의 글리프가 없기 때문에 글리프가 렌더링되지 않는 것도 mojibake와 혼동해서는 안 되는 문제입니다.이 렌더링 실패의 증상으로는 코드 포인트가 16진수로 표시되거나 범용 치환 문자를 사용하는 블록이 있습니다.중요한 것은, 이러한 교환은 유효하며, 소프트웨어에 의한 올바른 에러 처리의 결과입니다.

어원학

Mojibake는 일본어로 "성격 변화"를 의미합니다.이 단어는 moji, IPA: [modʑi], "caracter" 및 "bake, IPA: [béke]), "bah-keh", "transform"으로 구성되어 있습니다.

원인들

인코딩된 원본 텍스트를 올바르게 재생하려면 인코딩된 데이터와 인코딩 개념 간의 대응 관계가 유지되어야 합니다.mojibake는 이들 간의 컴플라이언스 위반 사례이므로 데이터 자체를 조작하거나 라벨을 다시 붙이는 것만으로 실현할 수 있습니다.

Mojibake는 잘못된 인코딩으로 태그가 지정된 텍스트 데이터와 함께 자주 볼 수 있습니다. 태그가 전혀 지정되지 않고 기본 인코딩이 다른 컴퓨터 간에 이동할 수 있습니다.주요 문제의 원인은 메타데이터를 데이터와 함께 전송하거나 저장하는 대신 각 컴퓨터의 설정에 의존하는 통신 프로토콜입니다.

컴퓨터 간의 디폴트 설정이 다른 것은 부분적으로 운영체제 패밀리 간의 유니코드 배포와 인간 언어의 다양한 쓰기 시스템에 대한 레거시 인코딩의 전문화 때문입니다.Linux 디스트리뷰션의 [2]대부분은 2004년에 UTF-8로 전환되었습니다만, Microsoft Windows 에서는 일반적으로 UTF-16 을 사용하고 있습니다.또한 다른 [dubious – discuss]언어의 텍스트파일에8비트 코드 페이지를 사용하는 경우도 있습니다.

일본어를 예로 들 수 있는 몇몇 문자 체계에서는 역사적으로 여러 개의 인코딩이 사용되었고, 이로 인해 사용자들은 비교적 자주 모히바케를 볼 수 있게 되었다.예를 들어, EUC-JP로서 격납되어 있는 mojibake 「Mojibake」라고 하는 말은 「Mojibake」, 「Mojibake」(MS-932), 「Mojibake」(Shift JIS-2004)라고 잘못 표시되는 경우가 있습니다.UTF-8과 같은 텍스트가 Shift JIS로 해석될 경우 ""로 표시됩니다.이는 다른 로케일이 관련될 경우 더욱 악화된다. 동일한 UTF-8 텍스트가 Windows-1252 또는 ISO-8859-1 인코딩에 있는 것으로 가정하는 소프트웨어에서 "e–hu-hu-hu-"로 표시되며, 일반적으로 Western으로 표기되는 경우 "e–hu-hu-hu"로 해석되는 경우(예를 들어 GB)로 표시된다.

Mojibake의 예
원문 文 字 化 け
EUC-JP 인코딩의 원시 바이트 수 CA B8 BB FA B2 BD A4 지하 1층
Shift-J로 해석되는 바이트 수IS 부호화 ﾊ ｸ ｻ 郾 ｽ ､ ｱ
ISO-8859-1 인코딩으로 해석되는 바이트 수 ê ¸ » u ² ½ ¤ ±
GBK 인코딩으로 해석된 바이트 수 矢 机 步 け

사양 미달

부호화가 지정되어 있지 않은 경우는, 다른 방법으로 부호화를 결정하는 것은 소프트웨어에 의해서 다릅니다.소프트웨어의 종류에 따라 일반적인 솔루션은 구성 또는 문자 집합 탐지 휴리스틱입니다.둘 다 그다지 흔하지 않은 시나리오에서는 예측이 빗나가기 쉽습니다.

텍스트 파일의 인코딩은 사용자의 언어, 운영 체제 브랜드 및 기타 조건에 따라 달라지는 로케일 설정의 영향을 받습니다.따라서, 설정이 다른 컴퓨터나 같은 시스템내의 다른 현지화 소프트웨어로부터 송신되는 파일의 경우, 상정되는 부호화는 시스템적으로 잘못되어 있습니다.Unicode의 경우 한 가지 해결 방법은 바이트 순서 마크를 사용하는 것이지만 소스 코드 및 기타 기계 판독 가능한 텍스트의 경우 많은 파서가 이를 허용하지 않습니다.다른 하나는 인코딩을 메타데이터로 파일 시스템에 저장하는 것입니다.확장 파일 속성을 지원하는 파일 시스템은 이 파일을 다음과 같이 저장할 수 있습니다.user.charset또, 이 기능을 이용하려면 , 다른 소프트웨어를 방해하지 않는 소프트웨어의 서포트가 필요합니다.[3]

UTF-8 등, 검출이 용이한 인코딩이 몇개 있습니다만, 구별하기 어려운 것이 많이 있습니다( 「문자 집합 검출」을 참조).문서와 함께 전송된 HTTP 헤더를 사용하거나 서버가 적절한 HTTP 헤더를 전송하도록 구성할 수 없는 경우 HTML 문서의 메타 태그를 사용하여 웹 브라우저가 EUC-JP에서 코딩된 페이지와 Shift-JIS에서 코딩된 페이지를 명시적으로 구분할 수 없습니다.HTML 문자 인코딩을 참조하십시오.

오사양식

부호화가 잘못 지정되어 있는 경우에도 Mojibake가 발생합니다.이 문제는 유사한 인코딩 간에 자주 발생합니다.예를 들어 Windows용 Eudora 전자 메일클라이언트는 실제로는 Windows-1252에 있는 ISO-8859-1로 라벨이 지정된 전자 메일을 송신하는 것으로 알려져 있습니다.[4]Windows-1252 에는, C1 범위의 여분의 인쇄 가능 문자(가장 빈번하게 볼 수 있는 것은 곡선의 따옴표와 여분의 대시)가 포함되어 있습니다.이것은 ISO 표준에 준거한 소프트웨어에서는 올바르게 표시되지 않았습니다.특히 Unix 등의 다른 운영체제시스템에서 가동하고 있는 소프트웨어에 영향을 줍니다.

사용자의 감시

아직 일반적으로 사용되고 있는 인코딩의 대부분은 ASCII를 채택하여 그 위에 추가하는 것으로부터 시작되었습니다.그 결과, 이러한 인코딩은 부분적으로 서로 호환성이 있습니다.예를 들면, Windows-1252 와 ISO 8859-1 이 있습니다.따라서 일반 ASCII에서 사용하는 확장 부호화 세트를 잘못 사용할 수 있습니다.

과잉 사양

각각 다른 정보를 기반으로 인코딩을 지정하려는 프로토콜 계층이 있을 경우, 최소한의 정보는 수신자에게 오해를 일으킬 수 있습니다.예를 들어 HTTP를 통해 정적 HTML 파일을 제공하는 웹 서버를 생각해 보겠습니다.문자 세트는, 다음의 3개의 방법으로 클라이언트에 통신할 수 있습니다.

  • HTTP 헤더에 격납되어 있습니다.이 정보는 서버 구성(예를 들어 디스크에서 파일을 처리하는 경우)에 기반하거나 서버에서 실행 중인 애플리케이션(동적 웹 사이트용)에 의해 제어될 수 있습니다.
  • HTML 메타태그(http-equiv또는charset또는encodingXML 선언의 Atribute.이것은 작성자가 특정 파일을 저장하기 위해 의도한 인코딩입니다.
  • 바이트 순서 표시로 사용합니다.이것은 작성자의 편집자가 실제로 저장한 인코딩입니다.우발적인 부호화 변환이 이루어지지 않는 한(어떤 부호화에서 열고 다른 부호화에 저장함으로써) 이것은 올바른 것입니다.단, UTF-8이나 UTF-16 등의 Unicode 인코딩에서만 사용할 수 있습니다.

하드웨어 또는 소프트웨어 지원 부족

훨씬 오래된 하드웨어는 일반적으로 하나의 문자 집합만 지원하도록 설계되어 있으며 일반적으로 문자 집합을 변경할 수 없습니다.디스플레이 펌웨어에 포함된 문자 테이블은 디바이스 판매 대상 국가의 문자를 포함하도록 현지화됩니다.일반적으로 표는 국가에 따라 다릅니다.따라서 이들 시스템은 다른 국가에서 시스템에서 생성된 텍스트를 로드할 때 mojibake를 표시할 수 있습니다.마찬가지로 많은 초기 운영체제는 여러 인코딩 포맷을 지원하지 않기 때문에 비표준 텍스트를 표시할 경우 mojibake가 표시됩니다.예를 들어 Microsoft Windows 및 Palm OS의 초기 버전은 국가별로 현지화되어 있으며 현지화된 버전이 지원되는 국가와 관련된 인코딩 표준만 지원합니다.e는 OS가 지원하도록 설계된 버전과 다른 인코딩 형식의 텍스트를 포함하는 파일을 열면 mojibake가 표시됩니다.

해상도

UTF-8을 디폴트 부호화로서 사용하는 애플리케이션은, US-ASCII 와의 광범위한 사용이나 하위 호환성이 있기 때문에, 보다 큰 상호 운용성을 실현할 수 있습니다.또한 UTF-8은 단순한 알고리즘으로 직접 인식할 수 있기 때문에, 올바르게 기술된 소프트웨어가 UTF-8을 다른 부호화와 혼재하는 것을 피할 수 있습니다.

mojibake 인스턴스의 해결의 어려움은 발생한 애플리케이션과 그 원인에 따라 달라집니다.mojibake가 발생하는 가장 일반적인 어플리케이션의 2개는 웹 브라우저와 워드프로세서입니다.최신 브라우저와 워드 프로세서는 다양한 문자 인코딩을 지원합니다.브라우저에서는 렌더링 엔진의 인코딩 설정을 즉시 변경할 수 있는 경우가 많은 반면 워드프로세서는 파일을 열 때 적절한 인코딩을 선택할 수 있습니다.사용자가 올바른 인코딩을 찾기 위해서는 시행착오가 필요할 수 있습니다.

이 문제는 유니코드 이외의 컴퓨터 게임 등 일반적으로 광범위한 문자 인코딩을 지원하지 않는 응용 프로그램에서 발생할 경우 더욱 복잡해집니다.이 경우 사용자는 운영 체제의 인코딩 설정을 게임의 인코딩 설정에 맞게 변경해야 합니다.단, 시스템 전체의 부호화 설정을 변경하면 기존 어플리케이션에서도 Mojibake가 발생할 수 있습니다.Windows XP 이후에서는 애플리케이션별 로케일 설정을 변경할 수 있는 응용 프로그램인 Microsoft AppLocale을 사용할 수도 있습니다.그래도 Windows 98 등의 이전 운영체제에서는 운영체제 인코딩 설정을 변경할 수 없습니다.이전 운영체제에서 이 문제를 해결하려면 서드파티 글꼴 렌더링 응용 프로그램을 사용해야 합니다.

다양한 문자 시스템의 문제

영어

영어 텍스트의 Mojibake는 일반적으로 em-dash(--), um-dash(–), colly 따옴표("")와 같은 구두점에서는 발생하지만 대부분의 인코딩이 영어 알파벳의 인코딩에 ASCII와 일치하기 때문에 문자 텍스트에서는 거의 발생하지 않습니다.예를 들어, 파운드 기호 """는 송신자에 의해 UTF-8로 인코딩되었지만 수신자에 의해 CP1252 또는 ISO 8859-1로 해석된 경우 """"로 표시됩니다.CP1252를 사용하여 반복할 경우 " "",",", "ššš " "", "æ'' "ããã if if" 등으로 이어질 수 있습니다.

일부 컴퓨터에는 구시대에는 벤더 고유의 인코딩이 있어 영어 텍스트에도 불일치가 있었습니다.코모도어 브랜드의 8비트 컴퓨터는 PETSCI 인코딩을 사용했습니다.특히 표준 ASCII에 비해 대소문자를 반전시키는 것이 눈에 띄었습니다.PETSCII 프린터는 그 시대의 다른 컴퓨터에서는 정상적으로 동작했지만, 모든 문자의 대소문자를 반전시켰습니다.IBM 메인프레임은 ASCII와 전혀 일치하지 않는EBCDIC 인코딩을 사용합니다.

기타 서유럽 언어

북게르만어, 카탈로니아어, 핀란드어, 독일어, 프랑스어, 포르투갈어, 스페인어의 알파벳은 모두 라틴어 알파벳의 연장선이다.추가 문자는 일반적으로 손상되어 mojibake로 텍스트를 읽을 수 없게 됩니다.

… 및 해당되는 경우 대문자 대응.

ISO-8859-1 문자 집합(라틴어 1 또는 서부어라고도 함)이 사용되고 있는 언어입니다.단, ISO-8859-1은 하위 호환성이 있는 Windows-1252와 약간 변경된 ISO-8859-15라는2개의 경쟁 규격에 의해 폐지되었습니다.둘 다 유로 기호 €와 프랑스어 ,를 추가하지만, 그렇지 않으면 이들 3개의 문자 집합이 혼동되어도 이들 언어에서 mojibake는 이들 언어에서 생성되지 않습니다.또한 ISO-8859-1을 Windows-1252로 해석하는 것이 항상 안전하며, 특히 거의 사용되지 않는 통화 기호(¤)를 대체하는 유로 표기에 대해서는 ISO-8859-15로 해석하는 것이 매우 안전하다.그러나 UTF-8의 등장으로 UNIX와 Windows 컴퓨터 간의 텍스트 파일 교환 등 특정 시나리오에서는 UTF-8이 Latin-1 및 Windows-1252와 호환되지 않기 때문에 mojibake가 더욱 보편화되었습니다.단, UTF-8은 간단한 알고리즘으로 직접 인식할 수 있는 기능이 있기 때문에 적절하게 작성된 소프트웨어는 UTF-8을 다른 인코딩과 혼재시키는 것을 피할 수 있습니다.따라서 UTF-8을 지원하지 않는 소프트웨어가 다수 있는 경우에 가장 일반적입니다.이러한 언어의 대부분은 MS-DOS 디폴트 CP437 및 ASCII를 제외한 다른 머신 디폴트 인코딩에서 지원됩니다.따라서 운영체제 버전을 구입할 때 문제가 발생하는 경우가 적었습니다.다만, Windows 와 MS-DOS 는 호환성이 없습니다.

스웨덴어, 노르웨이어, 덴마크어 및 독일어에서는 모음이 거의 반복되지 않으며, 일반적으로 한 문자가 잘못될 때(예: "kérlek"의 두 번째 문자) 명백하다.이렇게 하면 독자는 ,, and, , 사이에서 추측해야 하지만, 거의 모든 텍스트는 읽을 수 있습니다.반면 핀란드어 텍스트는 haeyö("웨딩 나이트")와 같은 단어에서 반복 모음을 특징으로 하며, 이는 때때로 텍스트를 읽기 어렵게 만들 수 있다(예: haeyö는 "Hã ¤ y y y y Yy "로 표시됨).Icelandic and Faroese have ten and eight possibly confounding characters, respectively, which thus can make it more difficult to guess corrupted characters; Icelandic words like þjóðlöð ("outstanding hospitality") become almost entirely unintelligible when rendered as "þjóðlÃð".

독일어로 부흐스타벤살라트(편지 샐러드)는 이러한 현상을 나타내는 일반적인 용어이며, 스페인어로 데모마시온(말 그대로 변형)이다.

일부 사용자는 컴퓨터를 사용할 때, 문제가 있는 분음 부호를 생략하거나 이중 글자로 대체하여 자신의 글을 번역한다(å → aa, //æ → ae, ü → ue 등).따라서 저자는 umlauts를 사용할 수 없을 때 독일어의 표준 관행인 "uber" 대신 "uever"로 표기할 수 있다.후자의 관행이 북유럽 국가들보다 독일어권에서 더 잘 용인되는 것 같다.예를 들어 노르웨이어에서 이중 글자는 고대 덴마크어와 관련이 있으며 농담으로 사용될 수 있습니다.하지만, 이중 글자는 세계의 다른 지역과의 의사소통에 유용하다.예를 들어, 노르웨이 축구 선수 올레 군나르 솔셰르는 맨체스터 유나이티드에서 뛸 때 등에 "SOLSKJAER"라는 철자를 달았다.

ISO-8859-1로 잘못 해석된 UTF-8의 인공물인 "Ring meg N""("Ring meg nö")은 2014년 [5]6월 노르웨이에서 발생한 SMS 사기에서 발견되었다.

예
스웨덴의 예: Smörgos (오픈 샌드위치)
파일 부호화 브라우저에서의 설정 결과
MS-DOS 437 ISO 8859-1 SM'rgs
ISO 8859-1 맥 로만 SMG
UTF-8 ISO 8859-1 스메르제스
UTF-8 맥 로만 sm-s

중동유럽어

중부 및 동유럽 언어 사용자도 영향을 받을 수 있습니다.1980년대 중후반에는 대부분의 컴퓨터가 네트워크에 접속되어 있지 않았기 때문에, 분음 문자(ISO/IEC 8859 및 KOI-8 참조)를 사용하는 모든 언어에 대해 다른 문자 인코딩이 존재했으며, 운영 체제에 따라도 종종 다양했습니다.

헝가리어

헝가리어는 26개의 기본 영어 문자와 악센트 형식 ers, ented, ,, ,, ,, ((모두 라틴어-1 문자 집합에 있음), 그리고 라틴어-1에는 없는 두 가지 문자 and와 ,를 사용하는 영향을 받는 언어이다.이러한 2 문자는, 라틴어 2, Windows 1250, 및 Unicode 로 올바르게 부호화할 수 있습니다.Unicode가 전자 메일클라이언트에 보편화되기 전에는 헝가리의 텍스트를 포함한 전자 메일에는 문자 「」와 「」가 파손되어 있어 인식할 수 없는 경우가 있었습니다.문자 망글링('베츠제메트'라는 뜻)에 의해 읽을 수 없게 된 전자 메일(아래 예 참조)에 대해 헝가리어로 된 어처구니없는 문구('홍수 방지 미러 드릴링 머신')인 "Arvijtztr t tükörfurogép"로 응답하는 것이 일반적입니다.

예
소스 부호화 타깃 부호화 결과 발생.
헝가리의 예 아르비제트
아르비제트루게프		 빨간색 문자는 잘못되어 왼쪽 상단 예시와 일치하지 않습니다.
CP 852 CP 437 【RV】【ZT】【Ré TüKORF】【RαGéP】
아르비제트루게프		 이것은 중앙유럽 CP 852 인코딩으로 텍스트가 인코딩된 DOS 시대에 매우 흔했지만 운영 체제, 소프트웨어 또는 프린터는 기본 CP 437 인코딩을 사용했습니다.(()) 및 ((√)를 제외하고 주로 소문자만 맞으므로 주의하시기 바랍니다.CP 852는 독일어와 호환성이 있기 때문에 ü/ü가 맞습니다.오늘날은 주로 인쇄된 처방전과 수표에서 발생한다.
CWI-2 CP 437 ORViZT r R t TüKORF r R g GéP
아르비츠트로트뢰로게프		 CWI-2 인코딩은 디스플레이 또는 프린터가 기본 CP 437 인코딩을 사용하더라도 텍스트가 읽기 쉬운 상태로 유지되도록 설계되었습니다.이 인코딩은 1980년대와 1990년대 초반에는 많이 사용되었지만 현재는 완전히 사용되지 않습니다.
Windows-1250 윈도-1252 아르비제트
아르비제트루게프		 기본 Western Windows 인코딩은 중앙유럽 인코딩 대신 사용됩니다.'-'와 '-'만 틀렸을 뿐 텍스트는 완전히 읽을 수 있습니다.이것은 오늘날 가장 흔한 오류입니다. 무지로 인해 웹 페이지나 인쇄 매체에서 자주 발생합니다.
CP 852 Windows-1250 【RVöZTerr】TshK™【R】G】P
rv'zt'r't'k'rfWr'g'p		 DOS 인코딩 대신 중앙 유럽 Windows 인코딩이 사용됩니다.is의 용법이 맞습니다.
Windows-1250 CP 852 【RV】【ZT】【R】【KIRF】【RERG】【P】
'rv'zt'r' t'k'rf'r'gUp'		 Windows 인코딩 대신 중앙 유럽 DOS 인코딩이 사용됩니다.is의 용법이 맞습니다.
인용 인쇄 가능 7비트 ASCII =C1RV=CDZT=DBR=D5 T=DCK=D6RF=DAR=D3G=C9P
=E1rv=EDZT=FBr=F5 t=FCk=F6rF=FAr=F3g=E9p		 주로 메일 서버가 잘못 설정되어 있기 때문에 발생합니다만, 일부의 휴대 전화에서는 SMS 메시지로도 발생할 수 있습니다.
UTF-8 윈도-1252 【RV】【RV】【RV】【°】【T】【K】【RF】【RV】【RV】【RV】【R】【RF】【R】【G】P】
ãrvãztå±r t' Tãkãrfã Rp Gp © p		 주로 잘못 설정된 웹 서비스 또는 웹 메일클라이언트에 의해 발생합니다.이 클라이언트는 해외에서의 사용에 대해 테스트되지 않았습니다(영문 텍스트에 대해서는 문제가 은폐되어 있기 때문입니다).이 경우 실제(흔히 생성된) 콘텐츠는 UTF-8에 있지만 HTML 헤더에는 설정되어 있지 않기 때문에 렌더링 엔진은 기본 Western 인코딩으로 표시합니다.

폴란드의

1987년 ISO 8859-2가 만들어지기 전에는 다양한 컴퓨팅 플랫폼 사용자가 Amiga와 같은 자체 문자 인코딩을 사용했습니다.Amiga의 PL, Atari ST 및 Masovia의 Atari Club, IBM PC의 IBM CP852, Mazovia 및 Windows CP1250.초기 DOS 컴퓨터를 판매한 폴란드 기업은 서로 호환되지 않는 폴란드 문자를 인코딩하는 방법을 자체 개발하여 비디오 카드(일반적으로 CGA, EGA 또는 헤라클레스)의 EPROM을 재프로그래밍하여 폴란드어에 필요한 글리프가 포함된 하드웨어 코드 페이지를 제공합니다.다른 컴퓨터 판매자가 플래그를 사용한 장소를 참조하지 않고 임의로 배치했습니다.에드가 있어요.

학계 및 사용자 그룹의 압력에 따라 ISO 8859-2가 주요 공급업체의 소프트웨어(현재는 유니코드로 대체됨)를 제한적으로 지원하면서 "인터넷 표준"으로 성공하면서 상황이 개선되기 시작했다.인코딩의 다양성으로 인해 많은 문제가 발생하고 있기 때문에 오늘날에도 일부 사용자는 폴란드어의 발음이 다른 문자를 krzaczki([kkät͜.ki])라고 부르고 있습니다.'작은 관목').

러시아어 및 기타 키릴 문자

Mojibake may be colloquially called krakozyabry (кракозя́бры [krɐkɐˈzʲæbrɪ̈]) in Russian, which was and remains complicated by several systems for encoding Cyrillic.[6]소련과 초기 러시아 연방은 KOI 인코딩(Kod Obmena Informatsiey, 정보 교환 코드)을 개발했다.이것은 ASCII를 기반으로 한 키릴 문자만의 7비트 KOI7에서 시작되었지만 라틴어와 일부 다른 문자는 키릴 문자로 대체되었습니다.이어서 8비트 KOI8 인코딩이 등장했는데, 이는 키릴 문자를 KOI7의 7비트 코드에 대응하는 고비트 세트 옥텟으로만 인코딩하는 ASCII 확장입니다.이 때문에 KOI8 텍스트는 러시아어도 8비트 삭제 후에도 부분적으로 읽을 수 있게 되어 있습니다.이는 8비트 미사용 이메일 시스템의 주요 장점으로 간주되고 있습니다.예를 들어 KOI8로 인코딩된 후 높은 비트스트립 처리를 거친 "KOLA RUSKOGO QZYKA"라는 단어는 "KOLA RUSKOGO QZYKA"로 표시됩니다.결국 KOI8은 러시아어와 불가리아어(KOI8-R), 우크라이나어(KOI8-U), 벨라루스어(KOI8-RU), 타지크어(KOI8-T)의 다른 맛을 갖게 되었다.

한편, 서양에서는 866페이지의 코드(Code)가 우크라이나어, 벨라루스어, 러시아어/불가리아어(MS-DOS)를 지원했습니다.Microsoft Windows의 경우, 코드 페이지 1251은 세르비아어 및 기타 슬라브어 키릴어 변종에 대한 지원을 추가했습니다.

최근 유니코드 부호화에는 모든 키릴 문자를 포함한 전 세계 언어의 거의 모든 문자에 대한 코드 포인트가 포함되어 있습니다.

유니코드 이전에는 텍스트 인코딩을 동일한 인코딩 시스템을 사용하여 글꼴과 일치시켜야 했습니다.이렇게 하지 않으면 텍스트 인코딩과 글꼴 인코딩의 정확한 조합에 따라 특정 모양이 달라지는 읽을 수 없는 횡설수가 발생합니다.예를 들어, 라틴 알파벳으로 제한된 글꼴을 사용하거나 기본("서양") 인코딩을 사용하여 유니코드 이외의 텍스트를 표시하려고 하면 일반적으로 발음 구별 마크가 있는 거의 모든 모음으로 구성된 텍스트가 됩니다.(KOI8 "бблиии library library library library library library)))))))))))))))))))))))))))))))))))) （ biblioteka, 라이브러리)"가 됩니다.Windows 코드 페이지 1251을 사용하여 KOI8 또는 그 반대로 텍스트를 표시하면 대부분 대문자로 구성된 왜곡된 텍스트가 생성됩니다(KOI8과 코드 페이지 1251은 같은 ASCII 영역을 공유하지만 코드 페이지 1251이 소문자로 되어 있는 영역에는 대문자 또는 그 반대).일반적으로 키릴 문자의 횡설수설은 잘못된 키릴 문자 글꼴을 사용하는 증상을 나타냅니다.월드 와이드 웹의 러시아 섹터 초창기에는 KOI8과 코드 페이지 1251이 모두 일반적이었다.2017년 현재 코드 페이지 1251에서 HTML 페이지를 볼 수 있으며 드물게는 유니코드뿐만 아니라 KOI8 인코딩도 볼 수 있습니다.(모든 언어를 포함한 전 세계 웹 페이지의 약 1.7%가 코드 페이지 1251로 인코딩되어 있습니다.)[7]HTML 표준에는 [8]소스의 임의의 Web 페이지의 부호화를 지정하는 기능이 포함되어 있습니다만, 이것은 무시되는 경우가 있기 때문에, 유저는 브라우저의 부호화를 수동으로 전환할 필요가 있습니다.

In Bulgarian, mojibake is often called majmunica (маймуница), meaning "monkey's [alphabet]".세르비아어로, 그것은 "쓰레기"라는 뜻의 주브르라고 불립니다.구소련과는 달리, 남부 슬라브인들은 KOI8과 같은 것을 사용하지 않았고, 유니코드 이전에는 코드 페이지 1251이 지배적인 키릴 부호화였다.따라서 이들 언어에서는 러시아어보다 부호화 비호환성 문제가 적었습니다.1980년대에 불가리아 컴퓨터는 자체 MIK 인코딩을 사용했는데, 이는 표면적으로는 CP866과 유사합니다(비호환).

예
러시아어 예: Krakojabry, garbage characters
파일 부호화 브라우저에서의 설정 결과
MS-DOS 855 ISO 8859-1 애애애애애애니
KOI8-R ISO 8859-1 ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★♪
UTF-8 KOI8-R 【-】

유고슬라비아어

크로아티아어, 보스니아어, 세르비아어(세르보-크로아티아어 분리) 및 슬로베니아어는 기본 라틴 알파벳에 the, ,, ,, ,, ,, ć, ć, ć, ć, only, only, only, only(only, /, /, /, č, only, only, /, /, /, /, /, /, /, /, /, /, /, /, /, /, /, /, /, /, /, /, /,이러한 문자는 모두 라틴어 2 및 Windows-1250으로 정의되어 있습니다만, 통상의 OS 디폴트의 Windows-1252 에는 일부(sh, ,, ,, ž, ž, ž)만이 존재하고 있습니다.다른 언어도 있기 때문입니다.

Mojibake는 이러한 문자와 함께 발생할 수 있지만 Windows-1252에 포함되지 않은 문자는 오류가 발생하기 쉽습니다.Thus, even nowadays, "šđčćž ŠĐČĆŽ" is often displayed as "šðèæž ŠÐÈÆŽ", although ð, è, æ, È, Æ are never used in Slavic languages.

기본 ASCII(예: 대부분의 사용자 이름)로 제한되는 경우, 일반적인 대체 방법은 다음과 같다: sh→s, d→c, ich→c, z→z(대문자 형식은 대문자 대소문자에 따라 D→D 또는 D→DJ)이다.이러한 치환에는 모두 애매한 부분이 생기기 때문에, 통상, 필요에 따라서 그러한 형식으로부터 원본을 재구축합니다.

Windows-1252 인코딩은 중요합니다.이는 영어 버전의 Windows 운영시스템이 현지화가 아닌 [citation needed]가장 널리 보급되어 있기 때문입니다.그 이유로는 비교적 작고 단편적인 시장, 고품질 현지화 가격 상승, 소프트웨어 불법복제(수입 대비 소프트웨어 가격 상승으로 인한 현상), 영어판 Windows 및 기타 소프트웨어 [citation needed]선호 등이 있습니다.

크로아티아어와 세르비아어, 보스니아어, 크로아티아어, 세르비아어, 그리고 심지어 몬테네그린을 다른 세 명과 구별하려는 움직임은 많은 문제를 일으킨다.다양한 표준과 품질을 사용하는 다양한 현지화가 있습니다.영어에서 유래한 방대한 컴퓨터 용어의 일반적인 번역은 없습니다.결국, 사람들은 채택된 영어 단어("컴퓨터"는 kompjuter, "컴파일"은 "kompajlirati" 등)를 사용하며, 번역된 용어에 익숙하지 않으면 번역된 문구를 바탕으로 메뉴의 일부 옵션이 무엇을 해야 하는지 이해하지 못할 수 있다.따라서 영어를 이해하는 사람뿐만 아니라 영어 용어에 익숙한 사람(이들 문제 때문에 영어 용어도 대부분 학교에서 가르치기 때문에)은 비전문 소프트웨어의 원본을 정기적으로 선택한다.

키릴 문자(마케도니아어 및 세르비아어 부분)를 사용하는 경우, 이 문제는 다른 키릴 문자 기반 문자와 유사합니다.

새로운 버전의 영어 Windows 에서는 코드 페이지를 변경할 수 있습니다(구 버전에서는 이 지원 기능이 있는 특수한 영어 버전이 필요).다만, 이 설정은 잘못 설정되어 있는 경우가 종종 있습니다.예를 들어 Windows 98 및 Windows Me는 1250을 포함한 대부분의 오른쪽에서 왼쪽으로의 단일 바이트 코드 페이지로 설정할 수 있지만 설치 시에만 설정할 수 있습니다.

코카서스어

그루지야어와 아르메니아어 문자를 포함한 코카서스 지역의 특정 언어의 문자 체계는 모지바케를 만들어 낼 수 있다.이 문제는 Unicode 표준으로 대체된 아르메니아어 알파벳의 구식 문자 인코딩 세트인 ArmsCII 또는 ARMCII의 경우 특히 심각합니다.ArmSCII는 컴퓨터 업계의 지원이 부족하기 때문에 널리 사용되지 않습니다.예를 들어 마이크로소프트 윈도우즈는 이 기능을 지원하지 않습니다.

아시아 부호화

또 다른 유형의 mojibake는 동아시아 언어의 인코딩 중 하나와 같이 텍스트가 멀티바이트 인코딩으로 잘못 해석될 때 발생합니다.이런 종류의 mojibake에서는 한 번에 여러 개의 문자(일반적으로 두 개)가 손상됩니다. 예를 들어 스웨덴어로 "kérlek"(kérlek)는 """로 해석됩니다.위의 mojibake와 비교하면, 이것은 문제가 되는 ,, or, are와 관련 없는 글자가 누락되어 있기 때문에 읽기 어렵고, 특히 such, such로 시작하는 짧은 단어('"'가 된다)에 문제가 있다.두 글자가 조합되어 있기 때문에, mojibake는 또한 더 랜덤하게 보입니다(일반적인 세 글자에 비해 50개 이상의 변형, 더 희귀한 대문자 수를 세지 않음).드물게는 "Bush hidded the facts"라는 문장과 같이 특정 단어 길이의 패턴을 포함하는 텍스트 문자열 전체가 잘못 해석될 수 있습니다.

베트남의

주요 기사:베트남어와 컴퓨터

베트남어로 이 현상을 또는 이라고 합니다.이 문제는 컴퓨터가 Windows-1258, TCVN3 또는 VNI에서 정의된 분음 문자를 UTF-8로 인코딩하려고 할 때 발생할 수 있습니다.Ch'ma는 Windows XP 컴퓨터 또는 저렴한 휴대 전화를 사용할 때 베트남에서 일반적이었습니다.

예: 트럼남트롱까엉까이따
(응우옌두 ru ki, nguy nguy)
원래의 부호화 타깃 부호화 결과
윈도-1258 UTF-8 TRA cm NAE trm TRONG Cãi ngEU°ai ta
TCVN3 UTF-8 ¨¨ c c âê âê tr tr tr
VNI(Windows) UTF-8 트렘나엠트롱코이응외이타

일본인입니다

주요 기사 : 일본어 및 컴퓨터

같은 현상을 일본어로 '모지바케'라고 한다.일본어 텍스트에 대해 다양한 인코딩이 존재하기 때문에 일본에서는 특히 문제가 되고 있습니다.UTF-8 및 UTF-16과 같은 Unicode 인코딩과 더불어 Shift-JIS(Windows 머신) 및 EUC-JP(UNIX 시스템)와 같은 다른 표준 인코딩이 있습니다.Mojibake는 일본 사용자뿐만 아니라 일본 시장용으로 작성된 소프트웨어를 실행하려고 할 때 외국인도 자주 볼 수 있습니다.

중국인

중국어로 뤄안모(pin安ǎ, 중국어 간체자, 번체자, 혼돈 코드라는 뜻)라고 불리며, 컴퓨터화된 텍스트가 하나의 한자 인코딩으로 인코딩되지만 잘못된 인코딩으로 표시될 때 발생할 수 있다.이 경우 대부분의 경우 데이터 손실 없이 문자 인코딩을 전환하여 문제를 해결할 수 있습니다.사용 중인 몇 가지 한자 부호화 시스템이 존재하기 때문에 상황은 복잡합니다.가장 일반적인 것은 다음과 같습니다.Unicode, Big5 및 Guobiao(여러 하위 호환 버전 포함) 및 일본어 인코딩을 사용하여 한자를 인코딩할 수 있습니다.

Guoviao 인코딩에서 luanma가 발생하면 원래 인코딩을 쉽게 식별할 수 있습니다.

원래의 부호화 표시: 결과 원문 메모
빅5 GB ?t瓣瓣 ? 三國志曹操傳 본래의 의미를 알 수 없는 왜곡된 한자.빨간색 문자는 GB 2312의 유효한 코드 포인트가 아닙니다.
Shift-JIS GB 暥帤壔偗僥僗僩 文字化けテスト 가나에는 부수 ,가 붙어 있고, 한자는 그 외의 문자로 표시되어 있습니다.대부분은 극히 드물고 현대 중국어에서는 실용적이지 않다.
EUC-KR GB 叼力捞钙胶 抛农聪墨 디제이맥스 테크니카 랜덤 공통 간체자.대부분의 경우 의미가 없습니다.여러 문자마다 공백이 있기 때문에 쉽게 식별할 수 있습니다.

인코딩에 문자가 없는 경우 추가적인 문제가 발생하는데, 이는 개인 이름이나 지명에서 여전히 사용되는 희귀 문자 또는 오래된 문자에서 흔히 볼 수 있습니다.그 예로는 대만 정치인 왕젠셴(王建ien)이 있다.Wáng Jiànxuān)'s "煊", Yu Shyi-kun (simplified Chinese: 游锡堃; traditional Chinese: 游錫堃; pinyin:Yóu Xíkūn)'s "堃" and singer David Tao (Chinese: 陶喆; pinyin:Big5에서 Tao Zhé)의 "big5"가 누락되었고, 전 PRC 총리인 Zhu Rongji(중국어: pin pin pinyyyyyyyyyyyyyyyy pin pin pin pin pin pin t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t)가 GB2312에서 누락되었으며, 저작권 기호 "©"가 누락되었습니다.[9]

신문들은 이 문제를 다양한 방법으로 다루었는데, 여기에는 기존의 유사한 두 인물을 결합하는 소프트웨어를 사용하는 것, 성격의 그림을 사용하는 것, 또는 독자들이 올바른 추론을 할 수 있기를 바라며 단순히 희귀한 인물을 동음이의어로 대체하는 것 등이 포함된다.

표시 텍스트

힌두스타니어(힌디우르두어), 벵갈어, 펀자비어, 마라티어 등 인도아리아어 또는 인도어권에서 사용되는 남아시아의 브라흐 문자 또는 인도 문자에서도 유사한 효과가 발생할 수 있다.이는 많은 인디케이터 스크립트에서 개별 문자 기호가 음절에 대한 기호를 만들기 위해 결합하는 규칙을 개별 문자 형식의 글리프가 사용 가능하더라도 적절한 소프트웨어가 없는 컴퓨터에서 제대로 이해하지 못할 수 있기 때문입니다.

이것의 한 예는 오래된 위키피디아 로고로, 많은 퍼즐 조각 각각에 "위"와 유사한 문자를 보여주려고 시도한다.'wi'를 뜻하는 데바나가리 문자를 포함하는 퍼즐 조각은 대신 '와'자를 표시하고, 이어 'i'자를 짝짓기 수식모음을 표시하기 위해 사용되었으며, Indician [10]텍스트를 표시하도록 구성되지 않은 컴퓨터에서 생성된 모지바케로 쉽게 인식될 수 있다.2010년 5월에 새롭게 디자인된 로고에서는 이러한 오류가 수정되었습니다.

일반 텍스트의 개념을 사용하려면 운영 체제가 유니코드 코드를 표시하기 위한 글꼴을 제공해야 합니다.이 글꼴은 OS마다 Singhala용 OS마다 다르며 모든 운영체제에서 일부 문자(심볼러블)에 대해 맞춤법이 올바르지 않습니다.예를 들어, 'r'의 줄임말인 'reph'는 보통 일반 문자 위에 오는 분음 부호입니다.하지만, 특정한 문맥에서 'ya'나 'la'와 같은 글자 위에 가는 것은 잘못된 것이다.산스크리트어 단어나 이름, 예를 들어 山스크리트어, IAT: karrya, IAST: arya는 그 위에 붙이는 경향이 있습니다.By contrast, for similar sounds in modern languages which result from their specific rules, it is not put on top, such as the word करणाऱ्या, IAST: karaṇāryā, a stem form of the common word करणारा/री, IAST: karaṇārā/rī, in the Marathi language.[11]그러나 대부분의 운영 체제에서 이러한 현상이 발생합니다.이것은, 폰트의 내부 프로그래밍의 장해인 것 같습니다.Mac OS와 iOS에서는 muurdhaja l(dark l)과 u'의 조합과 긴 형태가 모두 잘못된 [citation needed]모양을 만듭니다.

일부 Indicator 및 Indicator에서 파생된 스크립트, 특히 Lao는 Vista가 [12]출시될 때까지 Windows XP에서 공식적으로 지원되지 않았습니다.그러나 다양한 사이트에서 무료로 다운로드 할 수 있는 글꼴을 만들고 있습니다.

버마어

서방의[13] 제재와 버마어의 컴퓨터 [14][15]언어 지원의 늦은 도착으로 인해, 초기 버마 현지화의 대부분은 국제 협력 없이 자생되었다.버마 지원의 주요 수단은 유니코드 글꼴로 작성되었지만 실제로는 부분적으로만 유니코드를 [15]준수하는 글꼴인 Zawgyi 글꼴을 사용하는 것입니다.Zawgyi 글꼴에서는 Unicode에서 지정된 대로 버마어 스크립트의 코드 포인트가 구현되어 있지만 [16]구현되어 있지 않은 코드 포인트도 있습니다.Unicode Consortium에서는 이를 애드혹 글꼴 [17]인코딩이라고 부릅니다.휴대전화의 등장으로, 삼성이나 화웨이와 같은 모바일 업체들은 유니코드 호환 시스템 폰트를 Zawgyi [14]버전으로 대체했다.

이러한 애드혹 인코딩으로 인해 Zawgii와 Unicode 사용자 간의 통신은 왜곡된 텍스트로 표시됩니다.이 문제를 피하기 위해 콘텐츠 제작자들은 Zawgyi와 [18]Unicode로 글을 올렸습니다.미얀마 정부는 2019년 10월 1일을 "U-Day"로 지정해 [13]유니코드로 공식 전환했다.완전한 인수인계는 2년이 [19]걸릴 것으로 추정된다.

아프리카 언어

아프리카의 일부 문자 시스템에서는 인코딩되지 않은 텍스트를 읽을 수 없습니다.모지바케를 만들 수 있는 문자에는 에티오피아와 에리트레아의 게즈 문자, 암하라어, 티그레어, 그리고 다른 언어들에 사용되는 소말리아어와 같은 아프리카의 뿔 문자들이 포함된다.남아프리카에서는 Mwangwego 알파벳이 말라위의 언어를 쓸 때 사용되며 만돔베 알파벳은 콩고민주공화국을 위해 만들어졌지만 일반적으로 지원되지 않는다.서아프리카 원산의 다양한 문자 체계에는 기니의 만딩어족에 사용되는 N'Ko 알파벳이나 라이베리아에서 사용되는 Vai 음절 문자 같은 유사한 문제가 있다.

아랍어

또 다른 영향을 받는 언어는 아랍어입니다(아래 참조).인코딩이 일치하지 않으면 텍스트를 읽을 수 없게 됩니다.

예

파일 부호화 브라우저에서의 설정 결과
아랍어 예: (세계인권선언)
브라우저 렌더링: الإعلان العالمى لحقوق الإنسان
UTF-8 윈도-1252 裏¥¥¥¹¹…………………………………………………………………...
KOI8-R О╩©ь╖ы└ь╔ь╧ы└ь╖ы├ ь╖ы└ь╧ь╖ы└ы┘ы┴ ы└ь╜ы┌ы┬ы┌ ь╖ы└ь╔ы├ьЁь╖ы├
ISO 8859-5 яЛПиЇй�иЅиЙй�иЇй� иЇй�иЙиЇй�й�й� й�ий�й�й� иЇй�иЅй�иГиЇй�
CP 866 я╗┐╪з┘Д╪е╪╣┘Д╪з┘Ж ╪з┘Д╪╣╪з┘Д┘Е┘Й ┘Д╪н┘В┘И┘В ╪з┘Д╪е┘Ж╪│╪з┘Ж
ISO 8859-6 ُ؛؟ظ�ع�ظ�ظ�ع�ظ�ع� ظ�ع�ظ�ظ�ع�ع�ع� ع�ظع�ع�ع� ظ�ع�ظ�ع�ظ�ظ�ع�
ISO 8859-2 ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
윈도-1256 윈도-1252 åç á á á á á á á áççççç çççççç

이 문서의 예에서는 UTF-8을 브라우저 설정으로 사용하지 않습니다.UTF-8은 쉽게 인식할 수 있기 때문에 UTF-8을 지원하는 브라우저는 UTF-8을 자동으로 인식하고 UTF-8로 해석하지 마십시오.

「 」를 참조해 주세요.

  • 코드 포인트
  • 치환 문자
  • 대체 문자
  • 줄 바꿈 – 줄 바꿈을 나타내는 규칙은 Windows 시스템과 Unix 시스템에 따라 다릅니다.대부분의 소프트웨어는 두 가지 규칙을 모두 지원하지만(사소한) 차이를 유지하거나 표시해야 하는 소프트웨어(예: 버전 제어 시스템 및 데이터 비교 도구)는 하나의 규칙을 준수하지 않으면 훨씬 더 사용하기 어려워질 수 있습니다.
  • 바이트 순서 마크: 인코딩을 데이터와 함께 저장하는 가장 높은 대역 내 방법: 선두에 추가합니다.이는 호환 소프트웨어를 사용하는 사람에게는 의도적으로 보이지 않지만 호환되지 않는 소프트웨어(많은 통역자를 포함)에는 "쓰레기 문자"로 인식될 것입니다.
  • HTML 엔티티 – HTML에서 특수문자를 인코딩합니다.대부분은 옵션이지만, 특정 문자는 마크업으로서 해석을 회피하기 위해 필요합니다.

    이 변환을 적용하지 못하는 것은 취약성(사이트 간 스크립팅 참조)이지만 너무 많이 적용하면 이러한 문자가 왜곡됩니다.예를 들어 따옴표는"된다",","기타 등등.

  • 부시는 사실을 숨겼다.

레퍼런스

  1. ^ King, Ritchie (2012). "Will unicode soon be the universal code? [The Data]". IEEE Spectrum. 49 (7): 60. doi:10.1109/MSPEC.2012.6221090.
  2. ^ WINDISCHMANN, Stephan (31 March 2004). "curl -v linux.ars (Internationalization)". Ars Technica. Retrieved 5 October 2018.
  3. ^ "Guidelines for extended attributes". 2013-05-17. Retrieved 2015-02-15.
  4. ^ "Unicode mailinglist on the Eudora email client". 2001-05-13. Retrieved 2014-11-01.
  5. ^ "sms-scam". June 18, 2014. Retrieved June 19, 2014.
  6. ^ 141, Control + Alt + Delete: 사이버랑 사전, Jonathon Keats, Globe Pequot, 2007, ISBN 1-59921-039-8.
  7. ^ "Usage of Windows-1251 for websites".
  8. ^ "Declaring character encodings in HTML".
  9. ^ "PRC GBK (XGB)". Microsoft. Archived from the original on 2002-10-01. 코드 페이지 936과 유니코드 사이의 변환 맵.올바르게 표시하려면 브라우저에서 GB 18030 또는 GBK를 수동으로 선택해야 합니다.
  10. ^ Cohen, Noam (June 25, 2007). "Some Errors Defy Fixes: A Typo in Wikipedia's Logo Fractures the Sanskrit". The New York Times. Retrieved July 17, 2009.
  11. ^ "Marathi Typing English to Marathi Online Marathi Typing". marathi.indiatyping.com. Retrieved 2022-08-02.
  12. ^ "Content Moved (Windows)". Msdn.microsoft.com. Retrieved 2014-02-05.
  13. ^ a b "Unicode in, Zawgyi out: Modernity finally catches up in Myanmar's digital world". The Japan Times. 27 September 2019. Retrieved 24 December 2019. Oct. 1 is “U-Day", when Myanmar officially will adopt the new system.... Microsoft and Apple helped other countries standardize years ago, but Western sanctions meant Myanmar lost out.
  14. ^ a b Hotchkiss, Griffin (March 23, 2016). "Battle of the fonts". Frontier Myanmar. Retrieved 24 December 2019. With the release of Windows XP service pack 2, complex scripts were supported, which made it possible for Windows to render a Unicode-compliant Burmese font such as Myanmar1 (released in 2005). ... Myazedi, BIT, and later Zawgyi, circumscribed the rendering problem by adding extra code points that were reserved for Myanmar’s ethnic languages. Not only does the re-mapping prevent future ethnic language support, it also results in a typing system that can be confusing and inefficient, even for experienced users. ... Huawei and Samsung, the two most popular smartphone brands in Myanmar, are motivated only by capturing the largest market share, which means they support Zawgyi out of the box.
  15. ^ a b Sin, Thant (7 September 2019). "Unified under one font system as Myanmar prepares to migrate from Zawgyi to Unicode". Rising Voices. Retrieved 24 December 2019. Standard Myanmar Unicode fonts were never mainstreamed unlike the private and partially Unicode compliant Zawgyi font. ... Unicode will improve natural language processing
  16. ^ "Why Unicode is Needed". Google Code: Zawgyi Project. Retrieved 31 October 2013.
  17. ^ "Myanmar Scripts and Languages". Frequently Asked Questions. Unicode Consortium. Retrieved 24 December 2019. "UTF-8" technically does not apply to ad hoc font encodings such as Zawgyi.
  18. ^ LaGrow, Nick; Pruzan, Miri (September 26, 2019). "Integrating autoconversion: Facebook's path from Zawgyi to Unicode - Facebook Engineering". Facebook Engineering. Facebook. Retrieved 25 December 2019. It makes communication on digital platforms difficult, as content written in Unicode appears garbled to Zawgyi users and vice versa. ... In order to better reach their audiences, content producers in Myanmar often post in both Zawgyi and Unicode in a single post, not to mention English or other languages.
  19. ^ Saw Yi Nanda (21 November 2019). "Myanmar switch to Unicode to take two years: app developer". The Myanmar Times. Retrieved 24 December 2019.

외부 링크

  • Wiktionary의 mojibake 사전 정의
  • 위키미디어 커먼스의 Mojibake 관련 미디어