상위 질문
타임라인
채팅
관점

문자 깨짐

컴퓨터에 글자가 올바르게 표시되지 않는 현상 위키백과, 무료 백과사전

문자 깨짐
Remove ads

문자 깨짐은 (일본어: 일본어: 文字化け; ja, '문자 변환') 문자 인코딩이 의도하지 않은 방식으로 텍스트를 디코딩하여 결과적으로 텍스트가 깨져 보이는 현상을 말한다.[2] 이로 인해 종종 전혀 관련 없는 기호, 특히 다른 문자에서 온 기호로 체계적으로 대체된다.

Thumb
UTF-8로 인코딩된 일본어 위키백과가 Windows-1252로 표시된 모습[1]
Thumb
UTF-8로 인코딩된 교회 슬라브어 러시아 위키백과 문서가 KOI8-R로 해석되어 표시된 모습
이 문서에는 특수 문자가 포함되어 있습니다.
관련 글꼴이 설치되지 않은 경우, 일부 문자가 깨진 글자로 표시될 수 있습니다. 관련 도움말은 다국어 지원 가이드를 참고하세요.

이러한 표시는 이진 코드 표현이 유효하지 않은 것으로 간주되는 위치에 일반적인 대체 문자 �(U+FFFD)가 들어갈 수 있다. 또한 한 인코딩에서 여러 개의 연속된 기호로 보이는 것이 다른 인코딩에서는 하나의 기호를 구성할 때, 여러 개의 연속된 기호를 포함할 수도 있다. 이는 서로 다른 고정 길이 인코딩(아시아 16비트 인코딩과 유럽 8비트 인코딩의 차이) 때문이거나, UTF-8 및 UTF-16과 같은 가변 길이 인코딩을 사용하기 때문이다.

글꼴이 없거나 글꼴에 글리프가 없어서 글리프 렌더링에 실패하는 것은 문자 깨짐과 혼동해서는 안 되는 별개의 문제다. 이러한 렌더링 실패의 증상으로는 십육진법으로 표시된 코드 포인트가 포함된 블록이나 일반 대체 문자를 사용하는 경우가 있다. 중요하게도 이러한 대체는 유효하며 소프트웨어의 올바른 오류 처리 결과이다.

인터넷 은어로 뷁 문자(뷁어), 자연자(한국 한자: 自然字) 등으로 불린다.

Remove ads

원인

요약
관점
Thumb
잘못된 도스 버전에서 실행될 때 윈도우 1.01 및 윈도우 2.03의 부팅 화면에서 문자 깨짐이 표시되는 모습

인코딩된 원본 텍스트를 올바르게 재현하려면 인코딩된 데이터와 인코딩 개념 간의 일치(즉, 원본 및 대상 인코딩 표준이 동일해야 함)가 유지되어야 한다. 문자 깨짐은 이들 간의 불일치 사례이므로, 데이터 자체를 조작하거나 단순히 라벨을 다시 지정함으로써 발생할 수 있다.

문자 깨짐은 종종 잘못된 인코딩으로 태그가 지정된 텍스트 데이터에서 나타난다. 태그가 전혀 지정되지 않고, 서로 다른 기본 인코딩을 사용하는 컴퓨터 간에 이동할 수도 있다. 주요 문제의 원인 중 하나는 데이터와 함께 메타데이터를 전송하거나 저장하지 않고 각 컴퓨터의 설정에 의존하는 통신 프로토콜이다.

컴퓨터 간의 서로 다른 기본 설정은 부분적으로 운영체제 계열 간의 유니코드 배포 차이와 부분적으로 인간 언어의 서로 다른 문자에 대한 레거시 인코딩의 특수화 때문이다. 리눅스 배포판은 대부분 2004년에 UTF-8로 전환했지만,[3] 마이크로소프트 윈도우는 일반적으로 UTF-16을 사용하며, 때로는 다른 언어의 텍스트 파일에 8비트 코드 페이지를 사용한다.

일본어와 같은 일부 문자의 경우, 역사적으로 여러 인코딩이 사용되어 사용자들이 비교적 자주 문자 깨짐을 보게 된다. 예를 들어, EUC-JP로 저장된 모지바케("文字化け")라는 단어는 Shift-JIS로 해석될 경우 "ﾊｸｻ�ｽ､ｱ", "ﾊｸｻ嵂ｽ､ｱ" (MS-932), 또는 "ﾊｸｻ郾ｽ､ｱ"로 잘못 표시될 수 있으며, 텍스트가 Windows-1252 또는 ISO 8859-1 인코딩으로 가정되는 소프트웨어(일반적으로 서양 또는 서유럽으로 분류됨)에서는 "ʸ»ú²½¤±"로 표시될 수 있다. 다른 로케일이 관련되면 문제가 더욱 심각해진다. UTF-8로 저장된 동일한 텍스트는 Shift-JIS로 해석되면 "譁�蟄怜喧縺�", 서양으로 해석되면 "文字化㠑", 또는 (예를 들어) GBK (중국 본토) 로케일로 해석되면 "鏂囧瓧鍖栥亼"로 나타난다.

자세한 정보 원본 텍스트, EUC-JP 인코딩의 원시 바이트 ...

인코딩 비지정

인코딩이 지정되지 않으면 소프트웨어가 다른 방법으로 인코딩을 결정해야 한다. 소프트웨어 유형에 따라 일반적인 해결책은 구성 또는 문자 세트 감지 휴리스틱이며, 둘 다 잘못 예측될 가능성이 있다.

텍스트 파일의 인코딩은 사용자 언어와 운영체제 브랜드 등 여러 조건에 따라 달라지는 로케일 설정의 영향을 받는다. 따라서, 다른 설정의 컴퓨터 또는 동일 시스템 내에서 다르게 지역화된 소프트웨어에서 온 파일의 경우, 가정된 인코딩은 체계적으로 잘못된다. 유니코드의 경우, 해결책 중 하나는 바이트 순서 표식을 사용하는 것이지만, 많은 구문 분석기는 소스 코드 또는 다른 기계가 읽을 수 있는 텍스트에 대해 이를 허용하지 않는다. 또 다른 해결책은 확장 파일 속성을 지원하는 파일 시스템에서 인코딩을 파일 시스템에 메타데이터로 저장하는 것이다. 이 경우 `user.charset`으로 저장할 수 있다.[4] 이것 또한 이를 활용하려는 소프트웨어의 지원이 필요하지만, 다른 소프트웨어에 방해를 주지는 않는다.

UTF-8과 같이 일부 인코딩은 감지하기 쉽지만, 구별하기 어려운 인코딩도 많다(참조: 문자 세트 감지). 예를 들어, 웹 브라우저는 HTTP 헤더를 문서와 함께 보내거나 서버에서 적절한 HTTP 헤더를 보내도록 구성할 수 없는 경우 누락된 HTTP 헤더를 대체하는 데 사용되는 문서의 메타 태그를 사용하여 인코딩이 명시적으로 할당되지 않으면, EUC-JP로 코딩된 페이지와 Shift JIS로 코딩된 페이지를 구별하지 못할 수 있다. (참조: HTML의 문자 인코딩)

인코딩 오지정

문자 깨짐은 인코딩이 잘못 지정될 때도 발생한다. 이는 종종 유사한 인코딩 간에 발생한다. 예를 들어, 마이크로소프트 윈도우용 유도라 이메일 클라이언트는 실제로 Windows-1252로 되어 있는 이메일을 ISO 8859-1로 레이블링하여 보내는 것으로 알려져 있었다.[5] Windows-1252는 C1 제어 코드 범위에 추가 인쇄 가능 문자를 포함하는데(가장 흔하게 보이는 것은 굽은 인용 부호와 추가 줄표이다), 이는 ISO 표준을 준수하는 소프트웨어에서 제대로 표시되지 않았다. 이는 특히 유닉스와 같은 다른 운영체제에서 실행되는 소프트웨어에 영향을 미쳤다.

사용자 부주의

여전히 흔히 사용되는 인코딩 중 상당수는 ASCII를 기반으로 확장된 것이므로, 이러한 인코딩들은 부분적으로 서로 호환된다. Windows-1252와 ISO 8859-1이 그 예이다. 따라서 사람들은 자신이 사용하는 확장된 인코딩 세트를 일반 ASCII와 혼동할 수 있다.

과도한 인코딩 지정

여러 프로토콜 계층이 각기 다른 정보에 기반하여 인코딩을 지정하려고 할 때, 가장 불확실한 정보가 수신자에게 혼란을 줄 수 있다. 예를 들어, 웹 서버가 HTTP를 통해 정적 HTML 파일을 제공하는 경우를 고려해 보자. 문자 세트는 다음 세 가지 방법 중 하나로 클라이언트에게 전달될 수 있다.

  • HTTP 헤더에 포함. 이 정보는 서버 구성(예: 디스크에서 파일을 제공할 때)을 기반으로 하거나 서버에서 실행되는 애플리케이션(동적 웹사이트의 경우)에 의해 제어될 수 있다.
  • 파일 내에 HTML 메타 태그(`http-equiv` 또는 `charset`) 또는 XML 선언의 `encoding` 속성으로 포함. 이는 작성자가 특정 파일을 저장하려던 인코딩이다.
  • 파일 내에 바이트 순서 표식으로 포함. 이는 작성자의 편집기가 실제로 파일을 저장한 인코딩이다. 실수로 인코딩 변환이 발생하지 않는 한(한 인코딩으로 열어서 다른 인코딩으로 저장하는 경우), 이는 올바른 인코딩이다. 그러나 이는 UTF-8 또는 UTF-16과 같은 유니코드 인코딩에서만 사용할 수 있다.

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

대부분의 오래된 하드웨어는 일반적으로 하나의 문자 세트만 지원하도록 설계되었으며, 이 문자 세트는 일반적으로 변경할 수 없다. 디스플레이 펌웨어에 포함된 문자표는 해당 장치가 판매될 국가에 맞춰 지역화되어 해당 국가의 문자를 가지며, 일반적으로 이 표는 국가마다 다르다. 따라서 이러한 시스템은 다른 국가의 시스템에서 생성된 텍스트를 로드할 때 문자 깨짐을 표시할 수 있다. 마찬가지로, 많은 초기 운영체제는 여러 인코딩 형식을 지원하지 않으므로 비표준 텍스트를 표시하면 문자 깨짐이 나타난다. 예를 들어, 마이크로소프트 윈도우 및 팜 OS의 초기 버전은 국가별로 지역화되어 해당 지역화된 버전이 판매될 국가와 관련된 인코딩 표준만 지원하며, 따라서 운영체제가 지원하도록 설계된 버전과 다른 인코딩 형식의 텍스트가 포함된 파일을 열면 문자 깨짐이 표시된다.

Remove ads

해결 방법

UTF-8을 기본 인코딩으로 사용하는 애플리케이션은 널리 사용되고 ASCII와의 하위 호환성 덕분에 더 높은 수준의 상호 운용성을 달성할 수 있다. UTF-8은 또한 간단한 알고리즘으로 직접 인식될 수 있는 기능이 있어, 잘 작성된 소프트웨어는 UTF-8을 다른 인코딩과 혼동하는 것을 피할 수 있어야 한다.

문자 깨짐을 해결하는 어려움은 발생한 애플리케이션과 원인에 따라 달라진다. 문자 깨짐이 발생할 수 있는 가장 일반적인 두 가지 애플리케이션은 웹 브라우저와 워드 프로세서이다. 최신 브라우저와 워드 프로세서는 종종 다양한 문자 인코딩을 지원한다. 브라우저는 종종 사용자가 렌더링 엔진의 인코딩 설정을 즉석에서 변경할 수 있도록 허용하는 반면, 워드 프로세서는 사용자가 파일을 열 때 적절한 인코딩을 선택할 수 있도록 한다. 사용자가 올바른 인코딩을 찾으려면 어느 정도 시행착오를 겪어야 할 수도 있다.

이 문제는 비유니코드 컴퓨터 게임과 같이 일반적으로 다양한 문자 인코딩을 지원하지 않는 애플리케이션에서 발생할 때 더 복잡해진다. 이 경우 사용자는 운영체제의 인코딩 설정을 게임과 일치하도록 변경해야 한다. 그러나 시스템 전체의 인코딩 설정을 변경하면 기존 애플리케이션에서도 문자 깨짐이 발생할 수 있다. 윈도우 XP 이상 버전에서는 사용자가 애플리케이션별 로케일 설정을 변경할 수 있는 Microsoft AppLocale 애플리케이션을 사용할 수도 있다. 그럼에도 불구하고 윈도우 98과 같은 이전 운영체제에서는 운영체제 인코딩 설정을 변경할 수 없다. 이전 운영체제에서 이 문제를 해결하려면 타사 글꼴 렌더링 애플리케이션을 사용해야 한다.

Remove ads

다른 문자 체계에서의 문제

요약
관점

영어

영어 텍스트의 문자 깨짐은 주로 em 대시(—), en 대시(–), 구부러진 따옴표(“,”, ‘, ’)와 같은 구두점에서 발생하지만, 대부분의 인코딩이 영어 알파벳의 인코딩에서 ASCII와 일치하므로 문자 텍스트에서는 거의 발생하지 않는다. 예를 들어, 파운드 기호 £는 발신자가 UTF-8로 인코딩했지만 수신자가 서유럽 인코딩(CP1252 또는 ISO 8859-1) 중 하나로 해석하면 `£`로 나타난다. CP1252를 사용하여 반복하면 `£`, `£`, `£`, `£` 등이 될 수 있다.

마찬가지로, 작은 따옴표(')는 UTF-8로 인코딩되어 Windows-1252로 디코딩될 때 `’`, `’`, `’` 등으로 바뀐다.

과거에는 일부 컴퓨터가 공급업체별 인코딩을 사용하여 영어 텍스트에서도 불일치가 발생했다. 코모도어 인터내셔널 브랜드 8비트 컴퓨터는 PETSCII 인코딩을 사용했는데, 표준 ASCII와 비교하여 대문자와 소문자를 뒤집는 것이 특히 주목할 만하다. PETSCII 프린터는 그 시대의 다른 컴퓨터에서도 잘 작동했지만, 모든 글자의 대소문자를 뒤집었다. IBM 메인프레임은 ASCII와 전혀 일치하지 않는 확장 이진화 십진법 교환 부호 인코딩을 사용한다.

기타 서유럽 언어

북게르만어군, 카탈루냐어, 루마니아어, 핀란드어, 프랑스어, 독일어, 이탈리아어, 포르투갈어, 스페인어의 알파벳은 모두 라틴 음소문자의 확장이다. 추가 문자는 일반적으로 손상되는 문자이며, 문자 깨짐으로 인해 텍스트를 약간만 읽기 어렵게 만든다.

... 그리고 해당되는 경우 대문자도 마찬가지이다.

이들은 ISO 8859-1 문자 세트(라틴 1 또는 서양으로도 알려짐)가 사용되어 온 언어들이다. 그러나 ISO 8859-1은 두 개의 경쟁 표준인 하위 호환 Windows-1252와 약간 변경된 ISO 8859-15에 의해 구식화되었다. 둘 다 유로 기호 €와 프랑스어 œ를 추가하지만, 이 세 문자 세트의 혼동은 이러한 언어에서 문자 깨짐을 생성하지 않는다. 더욱이 ISO 8859-1을 Windows-1252로 해석하는 것은 항상 안전하며, ISO 8859-15로 해석하는 것은 상당히 안전하며, 특히 거의 사용되지 않는 국제 통화 기호 (¤)를 대체하는 유로 기호에 관해서는 더욱 그렇다. 그러나 UTF-8의 등장과 함께, UTF-8이 라틴-1 및 Windows-1252와 호환되지 않기 때문에 유닉스와 마이크로소프트 윈도우 컴퓨터 간의 텍스트 파일 교환과 같은 특정 시나리오에서 문자 깨짐이 더 흔해졌다. 그러나 UTF-8은 간단한 알고리즘으로 직접 인식될 수 있는 기능이 있어, 잘 작성된 소프트웨어는 UTF-8을 다른 인코딩과 혼동하는 것을 피할 수 있어야 하므로, 이는 많은 소프트웨어가 UTF-8을 지원하지 않던 시절에 가장 흔했다. 이러한 언어의 대부분은 MS-DOS 기본 코드 페이지 437 및 ASCII를 제외한 다른 기기 기본 인코딩에서 지원되었으므로 운영체제 버전 구매 시 문제는 덜 흔했다. 그러나 Windows와 MS-DOS는 호환되지 않는다.

스웨덴어, 노르웨이어, 덴마크어, 독일어에서는 모음이 거의 반복되지 않으며, 한 문자가 손상될 때 일반적으로 명확하게 알 수 있다. 예를 들어, 스웨덴어 단어 kärlek("사랑")의 두 번째 글자가 UTF-8로 인코딩되었지만 서유럽 인코딩으로 디코딩될 때 "kÃ⁠¤rlek"으로 렌더링되거나, 독일어의 "für"가 "für"로 바뀌는 경우이다. 이러한 방식으로 독자가 원본 문자를 추측해야 하더라도 거의 모든 텍스트는 읽을 수 있다. 반면에 핀란드어는 hääyö("결혼 밤")와 같은 단어에서 모음이 자주 반복되어 손상된 텍스트를 읽기 매우 어렵게 만들 수 있다(예: hääyö는 "hÃ⁠¤Ã⁠¤yÃ⁠¶"로 나타난다). 아이슬란드어는 10개의 잠재적인 혼동 문자를 가지고 있으며, 페로어는 8개를 가지고 있어 많은 단어가 손상되면 거의 완전히 알아볼 수 없게 된다(예: 아이슬란드어 þjóðlöð, "탁월한 환대",는 "þjóðlöð"으로 나타난다).

독일어에서는 Buchstabensalat("글자 샐러드")가 이 현상에 대한 일반적인 용어이며, 스페인어에서는 deformación(말 그대로 "변형")이 사용되고, 포르투갈어에서는 desformatação(말 그대로 "서식 해제")가 사용된다.

일부 사용자들은 컴퓨터를 사용할 때 문제가 되는 발음 구별 기호를 생략하거나, 이중음자 대체(Å → aa, Ä/Æ → ae, Ö/Ø → oe, Ü → ue 등)를 사용하여 글을 옮겨 적는다. 따라서 저자는 "über" 대신 "ueber"를 쓸 수 있는데, 이는 독일어에서 움라우트를 사용할 수 없을 때 표준적인 관행이다. 후자의 관행은 노르딕 국가보다 독일어권에서 더 잘 용인되는 것으로 보인다. 예를 들어, 노르웨이어에서는 이중음자가 고풍스러운 덴마크어와 연관되어 있으며 농담으로 사용될 수 있다. 그러나 이중음자는 세계의 다른 지역과의 의사소통에 유용하다. 예를 들어, 노르웨이 축구 선수 올레 군나르 솔셰르는 맨체스터 유나이티드에서 뛸 때 유니폼에 자신의 성이 "SOLSKJAER"로 표기되었다.

UTF-8이 ISO 8859-1로 잘못 해석되어 "Ring meg nå"가 "Ring meg nÃ¥"로 렌더링된 현상은 2014년 노르웨이를 대상으로 한 단문 메시지 서비스 스캠에서 관찰되었다.[6]

자세한 정보 스웨덴어 예시, 원본 인코딩 ...

루마니아어에서도 같은 문제가 발생하며, 다음 예시들을 참조하라.

자세한 정보 루마니아어 예시, 원본 인코딩 ...

중앙유럽 및 동유럽

중앙유럽 및 동유럽 언어 사용자도 영향을 받을 수 있다. 1980년대 중반부터 후반까지 대부분의 컴퓨터가 어떤 네트워크에도 연결되지 않았기 때문에, 발음 구별 기호가 있는 모든 언어마다 서로 다른 문자 인코딩이 존재했으며(참조: ISO/IEC 8859 및 KOI-8), 종종 운영체제에 따라서도 달랐다.

헝가리어

헝가리어에서는 이 현상을 "글자 쓰레기"를 의미하는 '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월 기준 전 세계 웹 페이지의 약 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을 포함한 대부분의 비우선순위 단일 바이트 코드 페이지로 설정할 수 있지만, 설치 시에만 가능하다.

아시아 인코딩

또 다른 유형의 문자 깨짐은 단일 바이트 인코딩으로 인코딩된 텍스트가 동아시아 언어 중 하나와 같은 다중 바이트 인코딩으로 잘못 구문 분석될 때 발생한다. 이러한 종류의 문자 깨짐에서는 하나 이상의 (일반적으로 두 개) 문자가 한 번에 손상된다. 예를 들어, 스웨덴어 단어 kärlek이 Windows-1252로 인코딩되었지만 GBK를 사용하여 디코딩되면 "k鋜lek"으로 나타나는데, 여기서 "är"가 "鋜"로 구문 분석된다. 위의 문자 깨짐과 비교할 때, 이는 문제가 되는 Å, Ä 또는 Ö와 관련 없는 글자들이 없기 때문에 읽기 더 어렵고, 특히 Å, Ä 또는 Ö로 시작하는 짧은 단어에 문제가 된다(예: "än"은 "鋘"가 된다). 두 글자가 결합되기 때문에 문자 깨짐은 또한 더 무작위적으로 보인다(일반적인 세 가지보다 50가지 이상 많은 변형, 드문 대문자는 제외). 일부 드문 경우에는 "Bush hid the facts" 문장과 같이 특정 단어 길이 패턴을 포함하는 전체 텍스트 문자열이 잘못 해석될 수 있다.

베트남어

 이 부분의 본문은 베트남어 및 컴퓨터입니다.

베트남어에서는 이 현상을 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월 기준에 다시 디자인된 로고는 이러한 오류들을 수정했다.

일반 텍스트의 개념은 운영 체제가 유니코드 코드를 표시할 글꼴을 제공해야 한다는 것이다. 이 글꼴은 싱할라어의 경우 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]

아프리카 언어

특정 아프리카 문자 체계에서는 인코딩되지 않은 텍스트를 읽을 수 없다. 문자 깨짐이 발생할 수 있는 텍스트는 암하라어, 티그레어 및 기타 언어에 사용되는 에티오피아 및 에리트레아의 게에즈 문자와 오스마냐 문자를 사용하는 소말리어와 같은 아프리카의 뿔 지역에서 온 것이다. 남아프리카에서는 말라위의 언어를 표기하는 데 음왕웨고 문자가 사용되며, 콩고 민주 공화국을 위해 만돔베 문자가 만들어졌지만, 일반적으로 지원되지 않는다. 기니의 만딩어에 사용되는 응코 문자와 라이베리아에서 사용되는 바이 음절 문자와 같은 서아프리카 고유의 다양한 다른 문자 체계들도 유사한 문제를 보인다.

아랍어

다른 영향을 받는 언어는 아랍어이며(아래 예시 참조), 이 경우 인코딩이 일치하지 않으면 텍스트를 완전히 읽을 수 없게 된다.

예시

자세한 정보 아랍어 예시, 브라우저 렌더링 ...

이 문서의 예시들은 브라우저 설정으로 UTF-8을 사용하지 않는다. UTF-8은 쉽게 인식되기 때문에 브라우저가 UTF-8을 지원한다면 자동으로 인식해야 하며, 다른 것을 UTF-8로 해석하려고 시도하지 않을 것이다.

Remove ads

예시

 대체 문자 문서를 참고하십시오.

UTF-8 디코더는 데이터를 처리하는 데 오류가 있을 때, 오류 처리 중 하나로 대체 문자 �(U+FFFD)를 사용한다. UTF-8 인코딩에서 이 문자가 2개 붙어 있는 경우(��), EUC-KR 인코딩으로 해석하면 占쏙옙이라는 글자로 변한다.

노토 폰트

 이 부분의 본문은 노토 폰트입니다.

구글은 폰트가 지원하지 않아 깨진 문자를 없애자는 목표로 '영어: No Tofu 노 토푸[*]'의 약자인 노토 폰트를 개발하여 배포한 바 있다.[22] 여기서 Tofu는 두부의 일본어 발음인데, 깨진 문자를 표시하는 사각형이 두부와 비슷해 보인다는 이유에서 이름을 지었다고 한다.

같이 보기

  • 코드 포인트
  • 대체 문자
  • 치환 문자
  • 새줄 문자 – 줄 바꿈을 나타내는 규칙은 Windows와 Unix 시스템 간에 다르다. 대부분의 소프트웨어는 두 가지 규칙을 모두 지원하지만(이는 사소한 문제임), 차이를 보존하거나 표시해야 하는 소프트웨어(예: 버전 관리 시스템 및 데이터 비교 도구)는 한 가지 규칙을 따르지 않으면 사용하기가 상당히 더 어려워질 수 있다.
  • 바이트 순서 표식 – 인코딩을 데이터와 함께 저장하는 가장 인밴드한 방법은 인코딩을 데이터 앞에 추가하는 것이다. 이는 의도적으로 준수하는 소프트웨어를 사용하는 사람들에게는 보이지 않지만, 비준수 소프트웨어(많은 인터프리터 포함)에게는 "쓰레기 문자"로 인식될 것이다.
  • HTML 엔티티 – HTML에서 특수 문자를 인코딩하는 방법으로, 대부분 선택 사항이지만 특정 문자가 마크업으로 해석되는 것을 이스케이프하기 위해서는 필요하다. 이 변환을 적용하지 않으면 취약점(사이트 간 스크립팅 참조)이 되지만, 너무 많이 적용하면 이 문자들이 깨진다. 예를 들어, 따옴표 "는 ", ", ", " 등으로 바뀐다.
  • Bush hid the facts
  • 글꼴
Remove ads

각주

외부 링크

Loading related searches...

Wikiwand - on

Seamless Wikipedia browsing. On steroids.

Remove ads
Remove ads