글자 깨짐
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
글자 깨짐은 문서의 문자 인코딩이 잘못 지정되거나, 폰트 부재 또는 통신 오류 등으로 인해 텍스트가 의도한 대로 표시되지 않는 현상이다. 문자 인코딩의 불일치, 글꼴 부재, 통신 오류, 소프트웨어 또는 하드웨어 문제 등이 원인이 될 수 있으며, 특히 여러 인코딩 방식이 혼재된 환경에서 자주 발생한다. 해결 방법으로는 인코딩 설정 변경, 글꼴 변경, 전용 프로그램 사용, 유니코드 사용 등이 있으며, 예방을 위해서는 올바른 인코딩 사용, 글꼴 확인, 통신 환경 점검 등이 중요하다.
더 읽어볼만한 페이지
- 문자 인코딩 - 유니코드
유니코드는 세계의 모든 문자를 하나의 컴퓨터 인코딩 표준으로 통합하기 위해 설계되었으며, 유니코드 컨소시엄에 의해 관리되고 UTF-8, UTF-16, UTF-32 등의 부호화 형식을 제공하지만, 일부 문자 표현 문제, 버전 간 비호환성, 레거시 인코딩과의 호환성 문제 등의 과제를 안고 있다. - 문자 인코딩 - UTF-8
UTF-8은 유니코드 문자를 표현하는 가변 길이 문자 인코딩 방식으로, ASCII 코드와 호환성을 유지하며 다양한 언어의 문자를 표현할 수 있도록 설계되었지만, 보안 문제점과 공간 효율성 측면에서 단점을 가진다. - 컴퓨터 오류 - 블루스크린
블루스크린은 윈도우 운영체제에서 발생하는 치명적인 오류로, 컴퓨터 작동을 멈추고 파란색 화면에 오류 메시지를 표시하며, 하드웨어 또는 소프트웨어 문제로 인해 발생하고, 시스템 복원, 안전 모드 부팅 등의 방법으로 대처한다. - 컴퓨터 오류 - 글리치
글리치는 예기치 않은 오작동이나 오류를 뜻하며, 전자 공학, 컴퓨터, 비디오 게임, 텔레비전 방송, 대중문화 등 다양한 분야에서 기능 실패, 오류, 그래픽 및 사운드 문제, 신호 오류 등의 이상 현상을 포괄적으로 지칭하는 용어이다.
2. 원인
글자 깨짐은 문서의 문자 인코딩이 제대로 지정되지 않거나, 표시 가능한 문자 인코딩이 제한되어 표시할 수 없을 때 발생한다.[2] 폰트가 없거나 통신이 원활하지 않을 때도 발생한다.[1]
문자 깨짐은 잘못된 인코딩으로 태그된 텍스트 데이터에서 자주 발생하며, 심지어 전혀 태그되지 않은 채 서로 다른 기본 인코딩을 가진 컴퓨터 간에 이동될 수도 있다. 주요 문제의 원인은 데이터와 함께 메타데이터를 전송하거나 저장하는 대신 각 컴퓨터의 설정에 의존하는 통신 프로토콜이다.[3]
컴퓨터 간의 서로 다른 기본 설정은 운영 체제 계열 간의 유니코드 배포 차이와, 서로 다른 문자 체계를 위한 레거시 인코딩의 전문화 때문이다. 리눅스 배포판은 대부분 2004년에 UTF-8로 전환한 반면,[2] 마이크로소프트 윈도우는 일반적으로 UTF-16을 사용하며, 때로는 다른 언어의 텍스트 파일에 8비트 코드 페이지를 사용하기도 한다. 일본어와 같이 일부 문자 체계의 경우, 역사적으로 여러 인코딩이 사용되어 사용자가 문자 깨짐을 비교적 자주 접하게 된다.
인코딩이 지정되지 않은 경우 소프트웨어는 구성 또는 문자 집합 감지 휴리스틱을 사용하여 인코딩을 결정하는데, 이러한 방법은 잘못 예측하기 쉽다.[3] 텍스트 파일의 인코딩은 사용자의 언어 및 운영 체제 브랜드 등에 따라 달라지는 로케일(컴퓨터 소프트웨어) 설정의 영향을 받는다.
소프트웨어나 하드웨어의 문제, 문자 코드의 차이, 인코딩과 디코딩의 불일치, 글꼴의 차이 등이 원인이 된다.[21][22] 문자 인코딩에 따라 표현할 수 있는 문자의 범위, 표시할 수 있는 다른 언어의 문자 등에 차이가 있다. 따라서 특정 문자 인코딩으로 표현할 수 있었던 문자열을 다른 문자 인코딩으로 표현하려고 하면, 처리 오류나 해당 문자가 존재하지 않는 등의 이유로 문자를 표현할 수 없게 된다.
문자 코드에 따라 이미 할당된 문자의 변경을 허용하거나, 새롭게 임의의 문자를 할당할 수 있는 확장 영역을 마련해 둔 경우가 있다. 또한, 문자 코드의 업데이트(사양 변경)에 따라 글자 모양이 변경되는 경우도 있다. 같은 문자 코드라도 어떤 구현이 채택되었는지에 따라 표시가 다르거나 표시가 안 될 수도 있다.
2. 1. 인코딩 불일치
컴퓨터에서 문서를 작성할 때 사용한 문자 인코딩과 문서를 표시하거나 처리할 때 사용하는 인코딩이 서로 다르면 글자가 깨져 보인다. 예를 들어, 문서를 UTF-8로 작성했는데, EUC-KR로 읽으려고 하면 글자가 깨지는 현상이 발생한다.[21] 과거에는 한국어 인코딩 방식으로 EUC-KR, CP949 등이 주로 사용되었으나, 최근에는 UTF-8이 표준으로 자리 잡았다.[22]인코딩이 지정되지 않은 경우, 소프트웨어는 구성 또는 문자 집합 감지 휴리스틱을 사용하여 인코딩을 결정한다. 하지만 이러한 방법은 잘못 예측하기 쉽다.[3]
인코딩이 잘못 지정된 경우에도 글자 깨짐이 발생할 수 있다. 예를 들어, 윈도우-1252로 작성된 이메일을 ISO 8859-1로 표시하면 글자가 깨져 보인다.[4]
2. 2. 글꼴 부재
문서를 표시하는 데 필요한 글꼴이 시스템에 없을 때 글자 깨짐이 발생한다. 특히, 특정 언어의 문자를 지원하지 않는 글꼴을 사용하면 해당 언어의 글자가 깨져 보이거나, 네모, 물음표 등으로 표시된다.글꼴에 따라 표현할 수 있는 글자의 범위에 차이가 있다. 따라서 운영 체제(OS), 소프트웨어(브라우저 등)가 지원할 수 있는 글꼴, 또는 설치된 글꼴의 종류에 따라 표현할 수 없는 경우가 있다. 1바이트 문자에는 1바이트 글꼴, 2바이트 문자에는 2바이트 글꼴을 별도로 지정할 수 있는 소프트웨어도 있지만, 획일적으로 1종류의 글꼴만 지정할 수 있는 소프트웨어도 있다.[21][22]
흔히 발생하는 문제는 다음과 같다:
- 기종 의존 문자를 사용하는 데 따른 문제: Windows 환경과 Macintosh 환경에서 문자 데이터를 교환할 때, 공통으로 사용할 수 있는 문자 인코딩 방식인 Shift_JIS를 사용했을 경우, 각기 독자적으로 확장한 문자(기종 의존 문자)를 가지고 있다. 이러한 문자를 사용했을 경우 의도하지 않은 문자로 표시될 수 있다.
- 각 글꼴 세트의 문자 집합 구현 수준의 차이에 따른 문제: UTF-8과 같이 많은 문자를 표현할 수 있는 문자 인코딩 방식을 이용할 경우, 기종별 글꼴 세트의 구현에 따라 사용할 수 있는 문자의 수가 제한되어 있어, 탑재하지 않은 문자가 깨지는 경우가 있다.
- 사용자 외자 사용에 따른 문제: 사용자가 Windows-31J나 Unicode의 사설 영역에 독자적으로 외자를 등록하여 사용했을 경우, 해당 부호 위치에 같은 문자가 없는 환경에서는 글자 깨짐이 발생하며, 이와 같은 현상이 발생한다.
- 글꼴 제작사 고유의 특수한 글꼴을 사용하는 데 따른 문제: Dingbat 등의 기호 글꼴이나, 문자 코드 내의 일부 문자를 사양과 다른 문자를 구현한 글꼴을 이용하여 글꼴을 내장하지 않은 파일로 하고, 해당 글꼴이 없는 환경에서 표시했을 경우 글자 깨짐이 발생한다.
- 탑재 글꼴의 Unicode의 버전 차이에 따른 문제: Unicode에서는, Unicode의 버전에 따라 같은 부호 위치에 다른 문자가 등록되어 있는 경우가 있다.
구글은 이러한 문제를 해결하기 위해 노토 폰트를 개발하여 배포하고 있다.[25]
2. 3. 통신 오류
통신 또는 기록 단계에서 문자 데이터의 일부가 손실되거나 변질되어, 의미를 알 수 없는 문자열로 표시되는 경우가 있다.[1]- ASCII나 ISO-2022-JP 등의 7비트 부호 이외의 문자를 Base64나 Quoted-printable 등의 인코딩 없이 7비트 계열 통신으로 송수신하려 할 경우, 상위 1비트가 삭제되어 글자가 깨지는 경우가 있다.[1]
- OS나 프로토콜마다 개행을 나타내는 제어 코드의 지정이 다르기 때문에 변환에 실패하면 해당 부분이 깨질 수도 있다.[1]
2. 4. 소프트웨어/하드웨어 문제
글자 깨짐은 소프트웨어나 하드웨어가 특정 문자 집합을 지원하지 않거나, 처리 방식에 문제가 있을 때 발생한다. 오래된 하드웨어는 일반적으로 하나의 문자 집합만 지원하도록 설계되었으며, 해당 문자 집합은 변경할 수 없다.특정 기능이 1바이트 문자를 예상하고 설계되었거나, 2바이트 문자이더라도 특정 문자 집합만을 예상하고 설계된 경우 글자 깨짐이 발생할 수 있다. 2바이트 문자를 예상하지 않고 설계된 소프트웨어나 통신 기능에서는 문자 길이에 제한이 있어, 2바이트 문자로 표현했을 때 태그, 이스케이프 시퀀스, 확장 부호 등의 삽입으로 제한된 문자열 길이보다 짧은 상태로 문자 깨짐이 발생할 수 있다.[21][22]
; 기종 의존 문자를 사용하는 데 따른 문제
: Windows 환경과 Macintosh 환경에서 문자 데이터를 교환할 때, 공통으로 사용할 수 있는 문자 인코딩 방식인 Shift_JIS를 사용했을 경우, 각기 독자적으로 확장한 문자(기종 의존 문자)를 가지고 있다. 이러한 문자를 사용했을 경우 의도하지 않은 문자로 표시될 수 있다.
; 각 글꼴 세트의 문자 집합 구현 수준의 차이에 따른 문제
: UTF-8과 같이 많은 문자를 표현할 수 있는 문자 인코딩 방식을 이용할 경우, 기종별 글꼴 세트의 구현에 따라 사용할 수 있는 문자의 수가 제한되어 있어, 탑재하지 않은 문자가 깨지는 경우가 있다.
: EUC-JP에서는 2면의 문자가 들어가지만, 일부 환경에서는 지원하지 않으므로 해당 영역의 문자가 글자 깨짐을 일으킨다.
; 사용자 외자 사용에 따른 문제
: 사용자가 Windows-31J나 Unicode의 사설 영역에 독자적으로 외자를 등록하여 사용했을 경우, 해당 부호 위치에 같은 문자가 없는 환경에서는 글자 깨짐이 발생한다.
; 글꼴 제작사 고유의 특수한 글꼴을 사용하는 데 따른 문제
: 딩뱃(Dingbat) 등의 기호 글꼴이나, 문자 코드 내의 일부 문자를 사양과 다른 문자를 구현한 글꼴을 이용하여 글꼴을 내장하지 않은 파일로 하고, 해당 글꼴이 없는 환경에서 표시했을 경우 글자 깨짐이 발생한다.
; 탑재 글꼴의 Unicode 버전 차이에 따른 문제
: Unicode에서는, Unicode의 버전에 따라 같은 부호 위치에 다른 문자가 등록되어 있는 경우가 있다.
: 또한, 버전 2.0 이후부터 사용하게 된 서로게이트 페어(대용 쌍)를 지원하지 않는 글꼴 환경도 아직 많기 때문에, 기본 다국어 평면에 미탑재된 문자를 이용했을 경우 제대로 표현하지 못하고 글자 깨짐이 발생하는 경우가 있다.
Shift_JIS를 내부 코드로 사용하는 응용 소프트웨어에서는 이스케이프 시퀀스를 얻는 방식에 약간의 주의가 필요하다. 일본어 지원 시에 특히 나타나기 쉽다.
Shift_JIS에서 2바이트째가 '''0x5c''' (일본의 엔 기호, ASCII에서는 백슬래시)가 되는 문자 (「'''申'''」, 「'''能'''」, 「'''表'''」 등, 속칭 「안 되는 문자」)의 경우, 2바이트째의 '''0x5c'''가 이스케이프 문자를 의미하는 제어 문자로 작동하여 올바르게 표시되지 않는 경우가 있다.
2. 5. 기타 원인
문자 코드 구현 방식의 차이, 문자 코드의 확장 영역 사용, 문자 코드 업데이트(사양 변경)에 따른 글꼴 모양 변경 등도 글자 깨짐의 원인이 될 수 있다.[21][22]예를 들어, "mojibake" (일본어로 "文字化け")를 EUC-JP로 저장하면 "ﾊｸｻ嵂ｽ､ｱ" (MS-932)로, Shift-JIS로 해석될 경우 "ﾊｸｻ郾ｽ､ｱ"로, Windows-1252 또는 ISO 8859-1 인코딩(일반적으로 "서부" 또는 "서유럽"으로 레이블됨)으로 해석될 경우 "ʸ»ú²½¤±"로 잘못 표시될 수 있다. UTF-8로 저장된 동일한 텍스트는 Shift-JIS로 해석될 경우 "譁�蟄怜喧縺�"로, 서부로 해석될 경우 "æ–‡å—化ãけ"로, GBK (중국 본토) 로캘로 해석될 경우 "鏂囧瓧鍖栥亼"로 나타난다.
글자 깨짐은 잘못된 인코딩 해석으로 인해 발생하는 경우가 많으며, 다음과 같은 유형이 있다.
3. 유형
일본어와 같은 일부 문자 체계의 경우, 역사적으로 여러 인코딩이 사용되어 사용자가 문자 깨짐을 비교적 자주 접하게 된다. 다음은 "文字化け"(모지바케)가 잘못 해석되는 예시이다.
오래된 하드웨어는 일반적으로 하나의 문자 집합만 지원하도록 설계되었으며, 해당 문자 집합은 일반적으로 변경할 수 없다. 따라서 다른 국가의 시스템에서 생성된 텍스트를 로드할 때 글자 깨짐 현상을 보일 수 있다.
문자 인코딩에 따라 표현할 수 있는 문자의 범위, 표시할 수 있는 다른 언어의 문자 등에 차이가 있다. 따라서 특정 문자 인코딩으로 표현할 수 있었던 문자열을 다른 문자 인코딩으로 표현하려고 하면, 처리 오류나 해당 문자가 존재하지 않는 등의 이유로 문자를 표현할 수 없게 된다.
3. 1. 1바이트 문자의 잘못된 해석
글자 깨짐 현상은 인코딩이 잘못 지정될 때도 발생한다. 이는 종종 비슷한 인코딩 간에 발생한다. 예를 들어, 윈도우용 유도라 이메일 클라이언트는 실제로는 윈도우-1252로 작성되었지만 ISO 8859-1로 표시된 이메일을 보내는 것으로 알려져 있었다.[4] 윈도우-1252는 C1 범위에 추가적인 인쇄 가능한 문자를 포함하고 있는데(가장 자주 보이는 것은 굽은 따옴표와 추가적인 대시), 이는 ISO 표준을 준수하는 소프트웨어에서는 제대로 표시되지 않았다. 이는 특히 유닉스와 같은 다른 운영 체제에서 실행되는 소프트웨어에 영향을 미쳤다.흔히 사용되는 인코딩 중 다수는 아스키를 기반으로 하여 만들어졌으며, 그 결과 이러한 인코딩들은 서로 부분적으로 호환된다. 예를 들어 Windows-1252와 ISO 8859-1이 있다. 따라서 사람들은 자신이 사용하는 확장 인코딩 세트를 일반 아스키로 착각할 수 있다.
3. 2. 멀티바이트 문자의 잘못된 해석
멀티바이트 문자로 인코딩된 텍스트를 다른 멀티바이트 인코딩으로 해석하거나, 1바이트 인코딩으로 해석할 때 글자 깨짐이 발생한다. 예를 들어, UTF-8로 인코딩된 텍스트를 EUC-KR로 해석하면 한글이 깨져 보인다. 일본어의 경우, UTF-8로 인코딩된 텍스트를 Shift JIS로 해석하면 가타카나와 일부 특수 문자가 깨져 보인다.[2]원래 인코딩된 텍스트를 정확하게 재현하려면, 인코딩된 데이터와 해당 인코딩 개념 사이의 일치(즉, 소스 및 대상 인코딩 표준이 동일해야 함)가 유지되어야 한다. 문자 깨짐은 이러한 불일치의 예시이며, 데이터 자체를 조작하거나 단순히 레이블을 다시 지정하여 해결할 수 있다.
문자 깨짐은 잘못된 인코딩으로 태그된 텍스트 데이터에서 자주 발생하며, 심지어 전혀 태그되지 않은 채 서로 다른 기본 인코딩을 가진 컴퓨터 간에 이동될 수도 있다. 주요 문제의 원인은 데이터와 함께 메타데이터를 전송하거나 저장하는 대신 각 컴퓨터의 설정에 의존하는 통신 프로토콜이다.
컴퓨터 간의 서로 다른 기본 설정은 부분적으로 운영 체제 계열 간의 유니코드 배포 차이와, 부분적으로 서로 다른 문자 체계를 위한 레거시 인코딩의 전문화 때문이다. 리눅스 배포판은 대부분 2004년에 UTF-8로 전환한 반면, 마이크로소프트 윈도우는 일반적으로 UTF-16을 사용하며, 때로는 다른 언어의 텍스트 파일에 8비트 코드 페이지를 사용하기도 한다.
일본어와 같은 일부 문자 체계의 경우, 역사적으로 여러 인코딩이 사용되어 사용자가 문자 깨짐을 비교적 자주 접하게 된다.
글자 깨짐 현상은 인코딩이 잘못 지정될 때도 발생한다. 이는 종종 비슷한 인코딩 간에 발생한다. 예를 들어, 윈도우용 유도라 이메일 클라이언트는 실제로는 윈도우-1252로 작성되었지만 ISO 8859-1로 표시된 이메일을 보내는 것으로 알려져 있었다.[4] 윈도우-1252는 C1 범위에 추가적인 인쇄 가능한 문자를 포함하고 있는데(가장 자주 보이는 것은 굽은 따옴표와 추가적인 대시), 이는 ISO 표준을 준수하는 소프트웨어에서는 제대로 표시되지 않았다. 이는 특히 유닉스와 같은 다른 운영 체제에서 실행되는 소프트웨어에 영향을 미쳤다.
오래된 하드웨어는 일반적으로 하나의 문자 집합만 지원하도록 설계되었으며, 해당 문자 집합은 일반적으로 변경할 수 없다. 디스플레이 펌웨어에 포함된 문자표는 해당 장치가 판매될 국가의 문자를 포함하도록 현지화되며, 일반적으로 이 표는 국가마다 다르다. 따라서 이러한 시스템은 다른 국가의 시스템에서 생성된 텍스트를 로드할 때 글자 깨짐 현상을 보일 수 있다. 마찬가지로, 많은 초기 운영 체제는 여러 인코딩 형식을 지원하지 않으므로 표준이 아닌 텍스트를 표시하도록 하면 글자 깨짐 현상이 발생한다. 예를 들어, 초기 버전의 마이크로소프트 윈도우 및 팜 OS는 국가별로 현지화되어 해당 현지화 버전이 판매될 국가와 관련된 인코딩 표준만 지원하며, 운영 체제가 지원하도록 설계된 버전과 다른 인코딩 형식의 텍스트가 포함된 파일을 열면 글자 깨짐 현상이 나타난다.
문자 인코딩에 따라 표현할 수 있는 문자의 범위, 표시할 수 있는 다른 언어의 문자 등에 차이가 있다. 따라서 특정 문자 인코딩으로 표현할 수 있었던 문자열을 다른 문자 인코딩으로 표현하려고 하면, 처리 오류나 해당 문자가 존재하지 않는 등의 이유로 문자를 표현할 수 없게 된다.
; 유니코드 매핑이 규정과 다른 것으로 인한 문제
윈도우 등 일부 환경에서는 유니코드와 JIS X 0208과의 매핑에서 JIS X 0221의 규정과 다른 규칙을 사용하기 때문에 (물결표나 마이너스 등) 글자 깨짐의 원인이 된다.
Shift_JIS를 내부 코드로 사용하는 응용 소프트웨어에서는 이스케이프 시퀀스를 얻는 방식에 약간의 주의가 필요하다. 그러나 그것이 제대로 이루어지지 않아 문제가 발생하는 경우가 있다. 해외 응용 프로그램의 일본어 지원 시에 특히 나타나기 쉽다.
Shift_JIS에서 2바이트째가 '''0x5c''' (일본의 엔 기호, ASCII에서는 백슬래시)가 되는 문자 (「'''申'''」, 「'''能'''」, 「'''表'''」 등, 속칭 「안 되는 문자」)의 경우, 2바이트째의 '''0x5c'''가 이스케이프 문자를 의미하는 제어 문자로 작동하여 올바르게 표시되지 않는 경우가 있다.
3. 3. 반복적인 인코딩 오류
인코딩 오류가 반복적으로 발생하면 글자가 계속해서 변환되어 원래 내용을 알아보기 어렵게 된다. 예를 들어, UTF-8로 인코딩된 파운드 기호(£)를 윈도우-1252로 해석하면 £가 되고, 이를 다시 윈도우-1252로 해석하면 £가 된다.[4]4. 언어별 양상
ISO 8859-1 문자 집합(''라틴 1'' 또는 ''서부''라고도 함)이 사용된 언어에서 주로 글자 깨짐이 나타난다. 그러나 ISO 8859-1은 하위 호환되는 Windows-1252와 약간 변경된 ISO 8859-15의 두 가지 경쟁 표준으로 인해 구식이 되었다. UTF-8의 출현으로 인해, UNIX와 Windows 컴퓨터 간의 텍스트 파일 교환과 같이 특정 시나리오에서 글자 깨짐이 더 흔해졌다. UTF-8은 Latin-1 및 Windows-1252와 호환되지 않기 때문이다.
- '''한국어''': 윈도우 등 일부 환경에서는 유니코드와 JIS X 0208과의 매핑에서 JIS X 0221의 규정과 다른 규칙을 사용하기 때문에 (물결표나 마이너스 등) 글자 깨짐이 발생하기도 한다.
- '''영어''': 대부분의 인코딩이 ASCII와 호환되기 때문에 문자 텍스트 자체의 깨짐은 드물지만, em 대시(—), en 대시(–), 둥근 따옴표(“, ”, ‘, ’)와 같은 구두점에서 문제가 발생할 수 있다. 예를 들어, 파운드 기호 `£`는 보낸 사람이 UTF-8로 인코딩했지만 받는 사람이 서유럽 인코딩 중 하나(CP1252 또는 ISO 8859-1)로 해석한 경우 `£`로 나타난다.
- '''서유럽 언어''': 라틴 문자를 확장하여 사용하는 언어(예: 프랑스어, 독일어, 스페인어 등)에서 주로 글자 깨짐이 발생한다. 예를 들어, 독일어의 움라우트(ä, ö, ü, ß)나 프랑스어의 악센트 기호(é, à, ç 등)가 깨져 보일 수 있다.[4]
- '''동유럽 언어''': 중앙 유럽 및 동유럽 언어 사용자도 영향을 받을 수 있다. 1980년대 중후반에는 대부분의 컴퓨터가 네트워크에 연결되지 않았기 때문에, 분음 부호가 있는 모든 언어에 대해 서로 다른 문자 인코딩(ISO/IEC 8859 및 KOI-8 참조)이 존재했으며, 이는 운영 체제에 따라서도 달랐다.[4]
- '''키릴 문자 사용 언어''': 러시아어, 불가리아어 등 키릴 문자를 사용하는 언어에서 KOI8-R, Windows-1251 등의 인코딩 차이로 인해 글자 깨짐이 발생할 수 있다. 러시아어에서는 이 현상을 "크라코쟈브리(krakozyabry)"()라고 부른다.[6]
- '''일본어''': 일본에서는 유니코드 인코딩(UTF-8 및 UTF-16) 외에도 Shift JIS (Windows 시스템) 및 EUC-JP (UNIX 시스템)과 같은 다른 표준 인코딩이 존재한다. 일본어에서는 이 현상을 "모지바케(文字化け)"라고 부른다.[2]
- '''중국어''': 중국어에서는 간체자와 번체자의 차이, 그리고 다양한 중국어 문자 인코딩(GB2312, Big5, UTF-8 등)으로 인해 글자 깨짐이 발생할 수 있다. 중국어에서는 이 현상을 "롼마"(乱码, 혼돈된 코드)라고 부른다.[10]
4. 1. 한국어
윈도우 등 일부 환경에서는 유니코드와 JIS X 0208과의 매핑에서 JIS X 0221의 규정과 다른 규칙을 사용하기 때문에 (물결표나 마이너스 등) 글자 깨짐이 발생하기도 한다.4. 2. 영어
대부분의 인코딩이 ASCII와 호환되기 때문에 문자 텍스트 자체의 깨짐은 드물지만, em 대시(—), en 대시(–), 둥근 따옴표(“, ”, ‘, ’)와 같은 구두점에서 문제가 발생할 수 있다. 예를 들어, 파운드 기호 `£`는 보낸 사람이 UTF-8로 인코딩했지만 받는 사람이 서유럽 인코딩 중 하나(CP1252 또는 ISO 8859-1)로 해석한 경우 `£`로 나타난다. CP1252를 사용하여 반복하면 `£`, `£`, `£`, `£` 등으로 이어질 수 있다.[4]마찬가지로, 오른쪽 작은따옴표(’)는 UTF-8로 인코딩되고 Windows-1252를 사용하여 디코딩될 때 `’`, `’`, `’` 등으로 변환된다.
과거에는 일부 컴퓨터가 공급업체별 인코딩을 사용하여 영문 텍스트에서도 불일치가 발생했다. 코모도어 브랜드의 8비트 컴퓨터는 표준 ASCII와 비교하여 대소문자를 반전시키는 것으로 특히 유명한 PETSCII 인코딩을 사용했다. PETSCII 프린터는 당시 다른 컴퓨터에서 잘 작동했지만 모든 문자의 대소문자를 반전시켰다. IBM의 메인프레임은 ASCII와 전혀 일치하지 않는 EBCDIC 인코딩을 사용한다.
4. 3. 서유럽 언어
라틴 문자를 확장하여 사용하는 언어(예: 프랑스어, 독일어, 스페인어 등)에서 주로 글자 깨짐이 발생한다. 예를 들어, 독일어의 움라우트(ä, ö, ü, ß)나 프랑스어의 악센트 기호(é, à, ç 등)가 깨져 보일 수 있다.[4]이러한 현상은 ISO 8859-1 문자 집합(''라틴 1'' 또는 ''서부''라고도 함)이 사용된 언어에서 나타난다. 그러나 ISO 8859-1은 하위 호환되는 Windows-1252와 약간 변경된 ISO 8859-15의 두 가지 경쟁 표준으로 인해 구식이 되었다.
UTF-8의 출현으로 인해, UNIX와 Windows 컴퓨터 간의 텍스트 파일 교환과 같이 특정 시나리오에서 글자 깨짐이 더 흔해졌다. UTF-8은 Latin-1 및 Windows-1252와 호환되지 않기 때문이다.
스웨덴어, 노르웨이어, 덴마크어 및 독일어에서는 모음이 거의 반복되지 않아 글자가 손상되었음을 쉽게 알 수 있다. 예를 들어 스웨덴어 단어 ''kärleksv''("사랑")의 두 번째 문자가 UTF-8로 인코딩되지만 서부에서 디코딩되어 "kärlek"이 생성되거나, 독일어의 ''für''가 "für"가 되는 경우이다. 이러한 경우, 독자가 원래 문자가 무엇인지 추측해야 함에도 불구하고, 거의 모든 텍스트는 읽을 수 있다. 반면에 핀란드어는 ''hääyöfi''("결혼의 밤")과 같이 단어에 반복 모음을 자주 사용하므로 손상된 텍스트를 읽기가 매우 어려울 수 있다.
독일어에서는 ''Buchstabensalatde''("글자 샐러드")가 이 현상을 나타내는 일반적인 용어이고, 스페인어에서는 ''deformaciónes''(문자 그대로 "변형")이 사용되며, 포르투갈어에서는 ''desformataçãopt''(문자 그대로 "서식 제거")가 사용된다.
일부 사용자는 컴퓨터를 사용할 때 문제의 기호를 생략하거나 디그래프 대체(å → aa, ä/æ → ae, ö/ø → oe, ü → ue 등)를 사용하여 글쓰기를 변환한다. 따라서 작성자는 "über" 대신 "ueber"를 쓸 수 있으며, 이는 움라우트를 사용할 수 없는 경우 독일어에서 표준 관행이다.
UTF-8이 ISO 8859-1로 잘못 해석된 아티팩트인 "Ring meg nåno"가 "Ring meg nÃ¥"로 렌더링되는 현상은 2014년 노르웨이를 대상으로 한 SMS 사기에서 발견되었다.[5]
4. 4. 동유럽 언어
중앙 유럽 및 동유럽 언어 사용자도 영향을 받을 수 있다. 1980년대 중후반에는 대부분의 컴퓨터가 네트워크에 연결되지 않았기 때문에, 분음 부호가 있는 모든 언어에 대해 서로 다른 문자 인코딩(ISO/IEC 8859 및 KOI-8 참조)이 존재했으며, 이는 운영 체제에 따라서도 달랐다.[4]헝가리어에서는 이 현상을 ''betűszemét''라고 부르며, 이는 "글자 쓰레기"를 의미한다. 헝가리어는 특히 이 현상에 취약한데, 헝가리어에는 á, é, í, ó, ú, ö, ü (모두 Latin-1 문자 집합에 포함)와 ő 및 ű 두 문자가 포함되어 있기 때문이다. 이 두 문자는 Latin-2, Windows-1250, 유니코드에서 올바르게 인코딩될 수 있다. 그러나 유니코드가 이메일 클라이언트에서 널리 사용되기 전에는 헝가리어 텍스트가 포함된 이메일에서 종종 ő와 ű 문자가 손상되었고, 때로는 알아볼 수 없을 정도로 심각했다. 손상된 이메일에 대해 헝가리어에서 사용되는 모든 악센트 문자를 포함하는 엉뚱한 문구인 "Árvíztűrő tükörfúrógép" (문자 그대로 "홍수 방지 거울 드릴 머신")으로 답장하는 것이 일반적이다.
1987년 ISO 8859-2가 만들어지기 전에는, 다양한 컴퓨팅 플랫폼 사용자들은 각자 고유의 문자 인코딩을 사용했다. 예를 들어, AmigaPL은 아미가에서, Atari Club은 아타리 ST에서, 그리고 Masovia, IBM CP852, Mazovia, Windows CP1250는 IBM PC에서 사용되었다. 초기 DOS 컴퓨터를 판매하는 폴란드 회사들은 폴란드 문자를 인코딩하는 자체적이고 서로 호환되지 않는 방식을 개발했으며, 단순히 EPROM을 비디오 카드(일반적으로 CGA, EGA, 또는 Hercules)에 재프로그래밍하여 폴란드어에 필요한 글리프를 제공하는 하드웨어 코드 페이지를 만들었다. 이 글리프들은 다른 컴퓨터 판매업체들이 배치한 위치와 관계없이 임의로 위치했다.
학계 및 사용자 그룹의 압력으로, ISO 8859-2가 "인터넷 표준"으로 자리 잡으면서 상황이 개선되기 시작했지만, 지배적인 벤더들의 소프트웨어 지원은 제한적이었다(오늘날에는 대부분 유니코드로 대체되었다). 다양한 인코딩으로 인해 발생하는 수많은 문제들 때문에, 오늘날에도 일부 사용자들은 폴란드어 분음 부호를 krzaczki|크샤츠키pl (문자 그대로 "작은 관목")라고 부르는 경향이 있다.
4. 5. 키릴 문자 사용 언어
러시아어, 불가리아어 등 키릴 문자를 사용하는 언어에서 KOI8-R, Windows-1251 등의 인코딩 차이로 인해 글자 깨짐이 발생할 수 있다. 러시아어에서는 이 현상을 "크라코쟈브리(krakozyabry)"()라고 부른다.[6]소련과 초기 러시아 연방은 KOI 인코딩을 개발했다. 이는 ASCII를 기반으로 라틴 문자와 다른 문자를 키릴 문자로 대체한 키릴 문자 전용 7비트 KOI7로 시작되었다. 그 다음에는 8비트 KOI8 인코딩이 등장했는데, 이는 ASCII 확장으로 KOI7의 7비트 코드에 해당하는 높은 비트 세트 옥텟을 사용하여 키릴 문자를 인코딩한다. 이러한 이유로 KOI8 텍스트는 비록 러시아어라 할지라도, 여덟 번째 비트를 제거한 후에도 부분적으로 읽을 수 있는데, 이는 8BITMIME를 인식하지 못하는 이메일 시스템 시대에 주요 이점으로 여겨졌다. 예를 들어, "Школа русского языка|shkola russkogo yazyka|러시아어 학교ru"라는 단어는 KOI8로 인코딩된 후 높은 비트 제거 과정을 거치면 "[KOLA RUSSKOGO qZYKA"로 렌더링된다. 결국 KOI8은 러시아어와 불가리아어 (KOI8-R), 우크라이나어 (KOI8-U), 벨라루스어(KOI8-RU), 심지어 타지크어 (KOI8-T)에 대한 여러 변형을 갖게 되었다.
한편 서방에서는 코드 페이지 866이 우크라이나어, 벨라루스어를 지원했고, MS-DOS에서는 러시아어와 불가리아어도 지원했다. 마이크로소프트 윈도우의 경우, 코드 페이지 1251은 세르비아어와 다른 슬라브어 키릴 문자 변형을 지원했다.
가장 최근에는 유니코드 인코딩이 모든 언어의 거의 모든 문자에 대한 코드 포인트를 포함하며, 모든 키릴 문자도 포함한다.
유니코드 이전에는 텍스트 인코딩을 동일한 인코딩 시스템을 사용하는 글꼴과 일치시켜야 했다. 그렇지 않으면, 읽을 수 없는 깨진 글자가 발생하며, 깨진 글자의 정확한 모습은 텍스트와 글꼴 인코딩의 정확한 조합에 따라 달라졌다. 예를 들어, 라틴 알파벳으로 제한된 글꼴을 사용하거나, 기본("서양") 인코딩을 사용하여 비 유니코드 키릴 문자를 보면, 일반적으로 거의 전부가 대문자 모음에 발음 구별 부호가 붙은 텍스트가 나타난다(예: KOI8의 "Библиотека|biblioteka|도서관ru"가 "âÉÂÌÉÏÔÅËÁ"가 되고, "Школа русского языка|shkola russkogo yazyka|러시아어 학교ru"가 "ûËÏÌÁ ÒÕÓÓËÏÇÏ ÑÚÙËÁ"가 된다). 코드 페이지 1251을 사용하여 KOI8 텍스트를 보거나 그 반대의 경우, 주로 대문자로 구성된 깨진 텍스트가 발생한다(KOI8과 코드 페이지 1251은 동일한 ASCII 영역을 공유하지만, KOI8은 코드 페이지 1251이 소문자를 사용하는 영역에 대문자를 사용하고, 그 반대의 경우도 마찬가지이다).
월드 와이드 웹의 러시아 부문 초창기에는 KOI8과 코드 페이지 1251이 모두 흔했다. 현재 거의 모든 웹 사이트에서 유니코드를 사용하지만, 2023년 11월 기준으로 전 세계 웹 페이지의 약 0.35% (모든 언어 포함)는 여전히 코드 페이지 1251로 인코딩되어 있으며, 0.003% 미만의 사이트가 여전히 KOI8-R로 인코딩되어 있다.[7][8]
불가리아어에서는 글자 깨짐 현상을 흔히 (маймуница|마이무니짜bg), 즉 "원숭이의 [알파벳]"이라고 부른다. 세르비아어에서는 (ђубре|주브레sr), 즉 "쓰레기"라고 부른다. 구 소련과 달리 남 슬라브족은 KOI8과 같은 것을 사용하지 않았고, 코드 페이지 1251이 유니코드 이전의 주요 키릴 문자 인코딩이었기 때문에, 이러한 언어는 러시아어보다 인코딩 호환성 문제가 적었다. 1980년대에는 불가리아 컴퓨터가 자체 MIK 인코딩을 사용했는데, 이는 CP866과 표면적으로 유사하지만 (호환되지 않음) 유사하다.
4. 6. 일본어
일본에서는 유니코드 인코딩(UTF-8 및 UTF-16) 외에도 Shift JIS (Windows 시스템) 및 EUC-JP (UNIX 시스템)과 같은 다른 표준 인코딩이 존재한다. 이러한 여러 인코딩의 존재로 인해 일본어 텍스트에서 글자 깨짐 현상이 특히 심각하게 발생한다.[2] 일본어에서는 이 현상을 "모지바케(文字化け)"라고 부른다.
문자 인코딩에 따라 표현할 수 있는 문자의 범위, 표시할 수 있는 다른 언어의 문자 등에 차이가 있다. 따라서 특정 문자 인코딩으로 표현할 수 있었던 문자열을 다른 문자 인코딩으로 표현하려고 하면, 처리 오류나 해당 문자가 존재하지 않는 등의 이유로 문자를 표현할 수 없게 된다.
; 유니코드 매핑 문제
: 윈도우 등 일부 환경에서는 유니코드와 JIS X 0208과의 매핑에서 JIS X 0221의 규정과 다른 규칙을 사용하기 때문에 (물결표나 마이너스 등) 글자 깨짐의 원인이 된다.
Shift_JIS를 내부 코드로 사용하는 응용 소프트웨어에서는 이스케이프 시퀀스를 얻는 방식에 약간의 주의가 필요하다. 그러나 그것이 제대로 이루어지지 않아 문제가 발생하는 경우가 있다. 해외 응용 프로그램의 일본어 지원 시에 특히 나타나기 쉽다.
Shift_JIS에서 2바이트째가 '''0x5c''' (일본의 엔 기호, ASCII에서는 백슬래시)가 되는 문자 (「'''申'''」, 「'''能'''」, 「'''表'''」 등, 속칭 「안 되는 문자」)의 경우, 2바이트째의 '''0x5c'''가 이스케이프 문자를 의미하는 제어 문자로 작동하여 올바르게 표시되지 않는 경우가 있다.
4. 7. 중국어
중국어에서는 간체자와 번체자의 차이, 그리고 다양한 중국어 문자 인코딩(GB2312, Big5, UTF-8 등)으로 인해 글자 깨짐이 발생할 수 있다. 중국어에서는 이 현상을 "롼마"(乱码, 혼돈된 코드)라고 부른다.[10]이 현상이 발생하면 데이터를 손실하지 않고 문자 인코딩을 전환하여 문제를 해결할 수 있는 경우가 많다. 여러 중국어 문자 인코딩 시스템이 사용되고 있다는 사실 때문에 상황이 복잡해지는데, 가장 일반적인 것은 유니코드, Big5, 국표 코드 (여러 하위 호환 버전 포함)이며, 중국어 문자가 일본어 인코딩을 사용하여 인코딩될 가능성도 있다.
국표 인코딩에서 ''롼마''가 발생하면 원래 인코딩을 비교적 쉽게 식별할 수 있다. 다음 표는 그 예시를 보여준다.
중국어에서 또 다른 문제는 개인 또는 지명에 여전히 사용되는 희귀하거나 낡은 문자가 일부 인코딩에 존재하지 않을 때 발생한다. 다음은 그 예이다.
- Big5 인코딩에는 타이완 정치인 왕젠쉬안의 이름에 있는 "煊"(''xuān'')과 유시쿤의 이름에 있는 "堃"(''kūn''), 가수 타오저의 이름에 있는 "喆"(''zhé'')이 없다.
- GB 2312에는 전 중화인민공화국 국무원 총리 주룽지의 이름에 있는 "镕"(''róng'')이 없다.
- GBK에는 저작권 기호 "©"가 없다.
신문은 누락된 문자를 처리하기 위해 이미지 편집 소프트웨어를 사용하여 다른 부수와 문자를 결합하여 합성하거나, (사람 이름의 경우) 인물의 사진을 사용하거나, 독자들이 올바른 추론을 할 수 있도록 동음을 단순히 대체하는 등 다양한 방법을 사용해 왔다.
문자 인코딩에 따라 표현할 수 있는 문자의 범위, 표시할 수 있는 다른 언어의 문자 등에 차이가 있다. 따라서 특정 문자 인코딩으로 표현할 수 있었던 문자열을 다른 문자 인코딩으로 표현하려고 하면, 처리 오류나 해당 문자가 존재하지 않는 등의 이유로 문자를 표현할 수 없게 된다.
4. 8. 기타 언어
베트남어, 아랍어, 인도 문자(데바나가리 문자 등), 아프리카 언어 등에서도 글자 깨짐 현상이 발생할 수 있다. 이러한 현상은 주로 잘못된 인코딩으로 태그된 텍스트 데이터에서 발생하며, 심지어 전혀 태그되지 않은 채 서로 다른 기본 인코딩을 가진 컴퓨터 간에 이동될 때도 발생한다.[2] 이는 데이터와 함께 메타데이터를 전송하거나 저장하는 대신 각 컴퓨터의 설정에 의존하는 통신 프로토콜 때문에 발생한다.컴퓨터 간의 서로 다른 기본 설정은 부분적으로 운영 체제 계열 간의 유니코드 배포 차이와, 부분적으로 서로 다른 문자 체계를 위한 레거시 인코딩의 전문화 때문이다. 예를 들어, 리눅스 배포판은 대부분 2004년에 UTF-8로 전환한 반면,[2] 마이크로소프트 윈도우는 일반적으로 UTF-16을 사용하며, 때로는 다른 언어의 텍스트 파일에 8비트 코드 페이지를 사용하기도 한다.
글자 깨짐은 비슷한 인코딩 간에도 발생할 수 있다. 예를 들어, 윈도우용 유도라 이메일 클라이언트는 실제로는 윈도우-1252로 작성되었지만 ISO 8859-1로 표시된 이메일을 보내는 것으로 알려져 있었다.[4] 윈도우-1252는 C1 범위에 추가적인 인쇄 가능한 문자를 포함하고 있어(굽은 따옴표와 추가적인 대시 등) ISO 표준을 준수하는 소프트웨어에서는 제대로 표시되지 않았다. 이는 특히 유닉스와 같은 다른 운영 체제에서 실행되는 소프트웨어에 영향을 미쳤다.
단일 바이트 인코딩으로 인코딩된 텍스트를 동아시아 언어의 인코딩과 같은 멀티 바이트 인코딩으로 잘못 해석할 때도 글자 깨짐이 발생한다. 이 경우 한 번에 두 개 이상의 문자가 손상된다. 예를 들어, 스웨덴어 단어 kärlek|셰를레크sv가 Windows-1252로 인코딩되었지만 GBK를 사용하여 디코딩되면 "k鋜lek"으로 표시되는데, 여기서 "är|italic=unset|에르sv"는 "鋜"로 파싱된다.
5. 해결 방법
글자 깨짐은 텍스트 데이터가 잘못된 인코딩으로 표시될 때 발생한다. 이는 컴퓨터 간의 서로 다른 기본 설정, 운영 체제 간 유니코드 배포 차이, 문자 체계별 레거시 인코딩 사용 등 다양한 원인으로 발생한다. 특히 일본어와 같이 역사적으로 여러 인코딩이 사용된 문자 체계에서는 글자 깨짐 현상이 더 자주 나타난다.
예를 들어, "mojibake" (文字化け일본어)라는 단어는 EUC-JP, MS-932, Shift-JIS, Windows-1252, ISO 8859-1 등 다양한 인코딩에서 다르게 해석되어 글자가 깨져 보일 수 있다. 다음 표는 "文字化け"가 각 인코딩에서 어떻게 다르게 보이는지 보여준다.
이러한 문제는 유니코드, 특히 UTF-8을 사용함으로써 해결할 수 있다. UTF-8은 US-ASCII와 하위 호환성을 가지며, 대부분의 리눅스 배포판에서 2004년부터 기본 인코딩으로 사용되고 있다.[2]
글자 깨짐을 해결하기 위한 구체적인 방법은 다음과 같다.
- 인코딩 설정 변경: 웹 브라우저나 텍스트 편집기에서 인코딩 설정을 UTF-8로 변경한다.
- 전용 프로그램 사용: Notepad++와 같은 인코딩 변환 프로그램이나 마이크로소프트 AppLocale과 같은 로케일 설정 변경 프로그램을 사용한다. (Windows XP 이상)
- 글꼴 변경: 특정 언어의 문자를 지원하는 글꼴로 변경한다. 예를 들어, 노토 폰트는 다양한 언어를 지원한다.[25]
하지만, 유니코드를 지원하지 않는 오래된 하드웨어나 소프트웨어에서는 글자 깨짐 문제가 여전히 발생할 수 있다.
5. 1. 인코딩 설정 변경
웹 브라우저나 텍스트 편집기 등에서 인코딩 설정을 변경하여 글자 깨짐을 해결할 수 있다. 일반적으로 UTF-8이 가장 널리 사용되는 인코딩이므로, UTF-8로 설정을 변경하면 대부분의 글자 깨짐 문제를 해결할 수 있다.[2]문자 데이터를 잘못된 인코딩으로 표시하려 할 때 올바르게 표시되지 않는 경우가 있다. ISO/IEC 646에서 규정된 문자는 Shift_JIS, EUC-JP, ISO-2022-JP, ISO-8859, UTF-8 등에서도 동일한 부호 위치로 등록되어 있다. 따라서 ISO/IEC 646 범위를 벗어나는 문자만 깨지는 경우에는 표시 시 인코딩 지정 오류일 가능성이 높다.
글자 깨짐을 방지하기 위해 프로토콜별 헤더에 문자 코드 정보를 첨부하여 전송하거나, 유니코드의 경우 BOM을 사용하는 방법 등이 권장된다.
표시 측 애플리케이션(WWW 브라우저 등)에 따라 표시 가능한 인코딩이 제한되어 지정 오류와 유사한 상태로 글자 깨짐이 발생할 수 있다. 유니코드의 서로게이트 페어(대용 쌍) 표기를 지원하지 않는 환경도 아직 많기 때문에, 기본 다국어 면에 탑재되지 않은 문자를 사용했을 경우 제대로 표현되지 않아 글자 깨짐이 발생할 수 있다.
5. 2. 글꼴 변경
글꼴에 따라 표현할 수 있는 글자의 범위에 차이가 있다. 따라서 운영 체제나 소프트웨어가 지원하는 글꼴, 또는 설치된 글꼴의 종류에 따라 표현할 수 없는 글자가 생겨 글자 깨짐이 발생할 수 있다. 어떤 소프트웨어는 1바이트 문자와 2바이트 문자에 대해 각각 다른 글꼴을 지정할 수 있지만, 어떤 소프트웨어는 한 종류의 글꼴만 지정할 수 있다.특정 언어의 문자를 지원하는 글꼴로 변경하면 글자 깨짐 문제를 해결할 수 있다. 예를 들어, 노토 폰트는 다양한 언어를 지원하는 글꼴로, 여러 언어의 글자 깨짐 문제를 한 번에 해결할 수 있도록 구글에서 개발되었다.[25]
기종 의존 문자 사용 문제Windows 환경과 Macintosh 환경에서 Shift_JIS와 같이 공통으로 사용 가능한 문자 인코딩 방식을 사용하더라도, 각 환경에서 독자적으로 확장한 문자(기종 의존 문자)를 사용하면 의도하지 않은 문자로 표시될 수 있다.
글꼴 세트의 문자 집합 구현 수준 차이 문제UTF-8과 같이 많은 문자를 표현할 수 있는 문자 인코딩 방식을 사용하더라도, 기종별 글꼴 세트의 구현 수준에 따라 사용할 수 있는 문자의 수가 제한되어 탑재되지 않은 문자가 깨지는 경우가 있다. 예를 들어, 어떤 기종에서는 Unicode 전체를 표현할 수 있는 글꼴을 탑재하고 있지만, 다른 기종에서는 JIS X 0208 범위의 문자만 Unicode 부호 위치에 탑재하여 UTF-8 인코딩 방식을 사용할 수만 있는 경우가 있다.
EUC-JP에서는 2면의 문자가 포함되지만, 일부 환경에서는 지원하지 않아 해당 영역의 문자가 글자 깨짐을 일으키기도 한다.
사용자 외자 사용 문제사용자가 Windows-31J나 Unicode의 사설 영역에 독자적으로 외자를 등록하여 사용할 경우, 해당 부호 위치에 같은 문자가 없는 환경에서는 글자 깨짐이 발생한다. 심지어 외자를 상대방에게 보냈을 때, 상대방의 OS가 블루 스크린을 일으키거나 멈추는 현상으로 이어질 수도 있다.
글꼴 제작사 고유의 특수 글꼴 사용 문제Dingbat 등의 기호 글꼴이나, 문자 코드 내의 일부 문자를 사양과 다르게 구현한 글꼴을 사용하고, 해당 글꼴이 없는 환경에서 파일을 표시하면 글자 깨짐이 발생한다.
탑재 글꼴의 Unicode 버전 차이 문제Unicode에서는 버전에 따라 같은 부호 위치에 다른 문자가 등록되어 있는 경우가 있다. 문서 형식은 어떤 버전의 코드인지 판별할 수단을 갖고 있지 않고, 특정 버전만 지원하는 환경이 대부분이므로, 같은 부호 위치의 문자라도 환경에 따라 전혀 다른 문자로 표시될 수 있다.
또한, 버전 2.0 이후부터 사용된 서로게이트 페어(대용 쌍)를 지원하지 않는 글꼴 환경이 아직 많기 때문에, 기본 다국어 평면에 없는 문자를 사용하면 제대로 표현되지 않고 글자 깨짐이 발생할 수 있다.
5. 3. 전용 프로그램 사용
Notepad++와 같은 인코딩 변환 프로그램을 사용하여 문서의 인코딩을 변경하면 글자 깨짐을 해결할 수 있다. 마이크로소프트 AppLocale과 같이 특정 프로그램의 로케일 설정을 변경하는 프로그램을 사용할 수도 있다. (Windows XP 이상)5. 4. 유니코드 사용
유니코드는 전 세계의 모든 문자를 표현할 수 있는 표준 인코딩 방식이므로, 유니코드를 사용하면 글자 깨짐 문제를 근본적으로 해결할 수 있다. 특히 UTF-8은 웹에서 가장 널리 사용되는 유니코드 인코딩 방식이므로, UTF-8을 사용하면 호환성 문제를 최소화할 수 있다.[2] 리눅스 배포판은 대부분 2004년에 UTF-8로 전환한 반면, 마이크로소프트 윈도우는 일반적으로 UTF-16을 사용하며, 때로는 다른 언어의 텍스트 파일에 8비트 코드 페이지를 사용하기도 한다.일본어와 같은 일부 문자 체계의 경우, 역사적으로 여러 인코딩이 사용되어 사용자가 문자 깨짐을 비교적 자주 접하게 된다. 예를 들어, "mojibake" 자체("文字化け")라는 단어를 EUC-JP로 저장하면, MS-932, Shift-JIS, Windows-1252 또는 ISO 8859-1 등에서 다르게 해석되어 글자가 깨져 보일 수 있다.
UTF-8을 기본 인코딩으로 사용하는 응용 프로그램은 US-ASCII와의 하위 호환성으로 인해 더 높은 수준의 상호 운용성을 달성할 수 있다.
6. 예방
글자 깨짐 현상을 예방하려면 문서를 작성하고, 전송하고, 표시하는 모든 단계에서 올바른 문자 인코딩을 사용하고 확인해야 한다.
1. 올바른 인코딩 사용:
- 문서를 작성할 때는 UTF-8과 같이 널리 사용되는 인코딩을 사용하는 것이 좋다. 리눅스 배포판은 대부분 2004년에 UTF-8로 전환했다.[2]
- 웹 페이지를 제작할 때는 HTML 문서의 `` 부분에 `` 태그를 추가하여 인코딩을 명시하는 것이 좋다.
2. 글꼴 확인:
- 글꼴에 따라 표현할 수 있는 글자의 범위가 다르므로, 사용하는 글꼴이 필요한 문자를 모두 지원하는지 확인해야 한다.
- Windows와 Macintosh 환경에서 문서를 교환할 때는 Shift_JIS 대신 UTF-8과 같이 호환성이 좋은 인코딩을 사용하는 것이 좋다.
- Unicode 환경에서는 글꼴의 버전에 따라 지원하는 문자가 다를 수 있으므로, 최신 버전의 글꼴을 사용하는 것이 좋다.
- 사설 영역에 등록된 사용자 외자나 특수한 글꼴은 다른 환경에서 글자 깨짐을 유발할 수 있으므로 사용하지 않는 것이 좋다.
3. 통신 환경 점검:
- 네트워크를 통해 문서를 전송할 때는 통신 환경이 8비트 문자를 지원하는지 확인해야 한다.
- ASCII나 ISO-2022-JP 등의 7비트 문자만 지원하는 통신 환경에서는 Base64나 Quoted-printable 등의 인코딩을 사용하여 8비트 문자를 안전하게 전송해야 한다.[4]
- 운영체제나 프로토콜마다 개행 문자가 다르므로, 텍스트 파일이 깨져 보일 경우 올바른 개행 문자로 변환해야 한다.
4. 소프트웨어 및 하드웨어 업데이트:
- 운영 체제, 웹 브라우저, 워드 프로세서, 텍스트 편집기 등 소프트웨어를 최신 버전으로 업데이트하면 다양한 인코딩 지원이 개선될 수 있다.
- 오래된 하드웨어는 특정 문자 집합만 지원하는 경우가 많으므로, 최신 하드웨어로 교체하면 글자 깨짐 문제를 해결하는 데 도움이 될 수 있다.
6. 1. 올바른 인코딩 사용
문서를 작성할 때 UTF-8과 같이 널리 사용되는 인코딩을 사용하면 글자 깨짐 문제를 예방할 수 있다. 웹 페이지를 제작할 때는 HTML 문서의 `` 부분에 `` 태그를 추가하여 인코딩을 명시하는 것이 좋다.[2] 리눅스 배포판은 대부분 2004년에 UTF-8로 전환한 반면, 마이크로소프트 윈도우는 일반적으로 UTF-16을 사용하며, 때로는 다른 언어의 텍스트 파일에 8비트 코드 페이지를 사용하기도 한다.일본어와 같은 일부 문자 체계의 경우, 역사적으로 여러 인코딩이 사용되어 사용자가 문자 깨짐을 비교적 자주 접하게 된다.
인코딩이 지정되지 않은 경우 소프트웨어는 다른 수단을 사용하여 이를 결정해야 한다. 소프트웨어 유형에 따라 일반적인 해결책은 구성 또는 문자 집합 감지 휴리스틱이며, 둘 다 잘못 예측하기 쉽다.
텍스트 파일의 인코딩은 사용자의 언어 및 운영 체제 브랜드 등에 따라 달라지는 로케일(컴퓨터 소프트웨어) 설정의 영향을 받는다. 따라서 가정된 인코딩은 다른 설정을 가진 컴퓨터 또는 동일한 시스템 내에서 다르게 소프트웨어 현지화된 소프트웨어에서 가져온 파일에 대해 체계적으로 잘못된다. 유니코드의 경우 한 가지 해결책은 바이트 순서 마크를 사용하는 것이지만, 많은 파서는 소스 코드 또는 기타 기계 판독 텍스트에 대해 이를 허용하지 않는다. 또 다른 해결책은 파일 시스템에 인코딩을 메타데이터로 저장하는 것이다. 확장 파일 속성을 지원하는 파일 시스템은 이를 `user.charset`으로 저장할 수 있다.[3]
UTF-8을 기본 인코딩으로 사용하는 응용 프로그램은 광범위한 사용과 US-ASCII와의 하위 호환성으로 인해 더 높은 수준의 상호 운용성을 달성할 수 있다. UTF-8은 간단한 알고리즘으로 직접 인식할 수 있으므로 잘 작성된 소프트웨어는 UTF-8을 다른 인코딩과 혼동하는 것을 피할 수 있다.
6. 2. 글꼴 확인
글꼴에 따라 표현할 수 있는 글자의 범위에 차이가 있다. 따라서 운영 체제(OS), 소프트웨어(브라우저 등)가 지원할 수 있는 글꼴, 또는 설치된 글꼴의 종류에 따라 표현할 수 없는 경우가 있다. 1바이트 문자에는 1바이트 글꼴, 2바이트 문자에는 2바이트 글꼴을 별도로 지정할 수 있는 소프트웨어도 있지만, 획일적으로 1종류의 글꼴만 지정할 수 있는 소프트웨어도 있다.; 기종 의존 문자를 사용하는 데 따른 문제
: Windows 환경과 Macintosh 환경에서 문자 데이터를 교환할 때, 공통으로 사용할 수 있는 문자 인코딩 방식인 Shift_JIS를 사용했을 경우, 각기 독자적으로 확장한 문자(기종 의존 문자)를 가지고 있다. 이러한 문자를 사용했을 경우 의도하지 않은 문자로 표시될 수 있다.
; 각 글꼴 세트의 문자 집합 구현 수준의 차이에 따른 문제
: UTF-8과 같이 많은 문자를 표현할 수 있는 문자 인코딩 방식을 이용할 경우, 기종별 글꼴 세트의 구현에 따라 사용할 수 있는 문자의 수가 제한되어 있어, 탑재하지 않은 문자가 깨지는 경우가 있다. 기종 A에서는 Unicode 전체를 표현할 수 있는 글꼴을 탑재하고 있지만, 기종 B에서는 JIS X 0208의 범위의 문자를 Unicode의 부호 위치로 탑재하고 있어, 인코딩 방식으로 UTF-8을 사용할 수 있을 뿐인 경우 등이 있을 수 있다.
: EUC-JP에서는 2면의 문자가 들어가지만, 일부 환경에서는 지원하지 않으므로 해당 영역의 문자가 글자 깨짐을 일으킨다.
; 사용자 외자 사용에 따른 문제
: 사용자가 Windows-31J나 Unicode의 사설 영역에 독자적으로 외자를 등록하여 사용했을 경우, 해당 부호 위치에 같은 문자가 없는 환경에서는 글자 깨짐이 발생한다. 외자 → �. 게다가 외자를 상대에게 보냈을 경우, 그 상대는 블루 스크린 또는 OS의 멈춤으로 이어질 위험이 있다.
; 글꼴 제작사 고유의 특수한 글꼴을 사용하는 데 따른 문제
: 딩뱃(Dingbat) 등의 기호 글꼴이나, 문자 코드 내의 일부 문자를 사양과 다른 문자를 구현한 글꼴을 이용하여 글꼴을 내장하지 않은 파일로 하고, 해당 글꼴이 없는 환경에서 표시했을 경우 글자 깨짐이 발생한다.
; 탑재 글꼴의 Unicode의 버전 차이에 따른 문제
: Unicode에서는, Unicode의 버전에 따라 같은 부호 위치에 다른 문자가 등록되어 있는 경우가 있다. 문서 형식에서는 어떤 버전의 코드인지 판별할 수 있는 수단을 갖고 있지 않기 때문에, 버전을 판별할 수 없고, 또한, 특정 버전만 지원하는 환경이 대부분이므로, 같은 부호 위치의 문자라도 환경을 바꾸면 전혀 다른 문자로 표시되는 경우가 있다.
: 또한, 버전 2.0 이후부터 사용하게 된 서로게이트 페어(대용 쌍)를 지원하지 않는 글꼴 환경도 아직 많기 때문에, 기본 다국어 평면에 미탑재된 문자를 이용했을 경우 제대로 표현하지 못하고 글자 깨짐이 발생하는 경우가 있다.
6. 3. 통신 환경 점검
네트워크를 통해 문서를 전송할 때, 통신 환경이 8비트 문자를 지원하는지 확인해야 한다.ASCII나 ISO-2022-JP 등의 7비트 부호 이외의 문자를 Base64나 Quoted-printable 등의 인코딩 없이 7비트 계열 통신으로 송수신하려 할 경우, 상위 1비트가 삭제되어 글자 깨짐이 발생할 수 있다.[4]
OS나 프로토콜마다 개행을 나타내는 제어 코드가 다르기 때문에, 변환에 실패하면 해당 부분이 깨질 수도 있다.
6. 4. 소프트웨어/하드웨어 업데이트
글자 깨짐 문제를 줄이기 위해 소프트웨어나 하드웨어를 최신 버전으로 유지하는 것은 중요하다.- 소프트웨어 업데이트:
- 운영 체제: 리눅스 배포판은 2004년부터 대부분 UTF-8로 전환되었지만,[2] 마이크로소프트 윈도우는 여전히 UTF-16을 주로 사용하며, 때때로 8비트 코드 페이지를 사용하기도 한다. 운영체제를 최신 버전으로 업데이트하면 다양한 인코딩 지원이 개선될 수 있다.
- 웹 브라우저: 최신 웹 브라우저는 다양한 문자 인코딩을 지원하며, 사용자가 렌더링 엔진의 인코딩 설정을 쉽게 변경할 수 있다.
- 워드 프로세서: 최신 워드 프로세서도 다양한 문자 인코딩을 지원하며, 파일을 열 때 적절한 인코딩을 선택할 수 있는 기능을 제공한다.
- 텍스트 편집기: 텍스트 편집기를 최신 버전으로 업데이트하면 다양한 인코딩을 지원하고, 바이트 순서 마크와 같은 유니코드 관련 기능도 활용할 수 있다.
- 컴퓨터 게임: 유니코드를 지원하지 않는 오래된 컴퓨터 게임의 경우, 운영체제의 인코딩 설정을 게임에 맞게 변경해야 할 수 있다. Windows XP 이상에서는 Microsoft AppLocale을 사용하여 응용 프로그램별 로케일 설정을 변경할 수 있다.
- 하드웨어 업데이트:
- 오래된 하드웨어는 일반적으로 하나의 문자 집합만 지원하며, 변경이 불가능한 경우가 많다. 다른 국가에서 생성된 텍스트를 표시할 때 글자 깨짐이 발생할 수 있으므로, 최신 하드웨어로 교체하면 다양한 문자 집합을 지원하여 문제를 해결할 수 있다.
최신 버전의 소프트웨어와 하드웨어는 UTF-8과 같이 널리 사용되는 인코딩을 지원하고, US-ASCII와의 하위 호환성도 높아 상호 운용성이 향상된다.
7. 기타
글자 깨짐은 잘못된 인코딩으로 태그된 텍스트 데이터에서 자주 발생하며, 심지어 전혀 태그되지 않은 채 서로 다른 기본 인코딩을 가진 컴퓨터 간에 이동될 수도 있다. 이러한 문제의 주요 원인은 데이터와 함께 메타데이터를 전송하거나 저장하는 대신 각 컴퓨터의 설정에 의존하는 통신 프로토콜이다.[2]
컴퓨터 간의 서로 다른 기본 설정은 부분적으로 운영 체제 계열 간의 유니코드의 상이한 배포와, 부분적으로 서로 다른 문자 체계를 위한 레거시 인코딩의 전문화 때문이다.
여러 계층의 프로토콜이 존재하고, 각 계층이 서로 다른 정보를 기반으로 인코딩을 지정하려고 할 때, 가장 불확실한 정보가 수신자를 오도할 수 있다. 예를 들어, HTTP를 통해 정적 HTML 파일을 제공하는 웹 서버를 생각해 보면, 문자 집합은 다음과 같은 세 가지 방법 중 하나로 클라이언트에게 전달될 수 있다.
- HTTP 헤더: 서버 구성(예: 디스크에서 파일을 제공하는 경우)을 기반으로 하거나 서버에서 실행되는 애플리케이션(동적 웹사이트의 경우)에 의해 제어될 수 있다.
- 파일 내, HTML 메타 태그 (http-equiv 또는 charset) 또는 XML 선언의 encoding 속성: 작성자가 특정 파일을 저장하려는 인코딩이다.
- 파일 내, 바이트 순서 표시: 작성자의 편집기가 실제로 저장한 인코딩이다. 우연한 인코딩 변환(하나의 인코딩으로 열고 다른 인코딩으로 저장하는 경우)이 발생하지 않는 한, 이것이 올바르다. 그러나 유니코드 인코딩(UTF-8 또는 UTF-16)에서만 사용할 수 있다.
많은 초기 운영 체제는 여러 인코딩 형식을 지원하지 않으므로 표준이 아닌 텍스트를 표시하도록 하면 글자 깨짐 현상이 발생했다. 예를 들어, 초기 버전의 마이크로소프트 윈도우 및 팜 OS는 국가별로 현지화되어 해당 현지화 버전이 판매될 국가와 관련된 인코딩 표준만 지원했으며, 운영 체제가 지원하도록 설계된 버전과 다른 인코딩 형식의 텍스트가 포함된 파일을 열면 글자 깨짐 현상이 나타났다.
7. 1. 용어
글자 깨짐은 일본어 "모지바케(文字化け)"를 영어식으로 표현한 "mojibake"로도 불린다. 이 용어는 미국의 알다스에서 일본어판 소프트웨어 개발을 하던 쿠보 요시유키가 페이지메이커 소프트웨어 개발 과정에서 글자 깨짐 현상을 설명하기 위해 사용하면서 매킨토시 관련 업계에 널리 퍼져 정착되었다.[23] 영어 등 각 언어에서는 "글자 깨짐"을 "mojibake"라고 일본어 로마자 표기로 사용하는 것이 정착되어 있다.7. 2. 역사
PC 통신 시대에는 하드웨어상의 글자 깨짐이 빈번하게 발생했다. 인터넷 보급 후에는 운영 체제, 브라우저 등 소프트웨어에 기인하는 글자 깨짐이 발생하고 있다.[2] 마이크로소프트 윈도우는 일반적으로 UTF-16을 사용하며, 때로는 다른 언어의 텍스트 파일에 8비트 코드 페이지를 사용하기도 한다. 반면, 리눅스 배포판은 대부분 2004년에 UTF-8로 전환하였다.일본어와 같은 일부 문자 체계의 경우, 역사적으로 여러 인코딩이 사용되어 사용자가 문자 깨짐을 비교적 자주 접하게 된다. 예를 들어, "mojibake" ("文字化け")라는 단어를 EUC-JP로 저장하면 "ﾊｸｻ�ｽ､ｱ" 또는 "ﾊｸｻ嵂ｽ､ｱ" (MS-932)로, Shift-JIS로 해석될 경우 "ﾊｸｻ郾ｽ､ｱ"로, Windows-1252 또는 ISO 8859-1 인코딩(일반적으로 "서부" 또는 "서유럽")에서는 "ʸ»ú²½¤±"로 잘못 표시될 수 있다. UTF-8로 저장된 동일한 텍스트는 Shift-JIS로 해석될 경우 "譁�蟄怜喧縺�"로, 서부로 해석될 경우 "æ–‡å—化ãけ"로, GBK (중국 본토) 로캘에서는 "鏂囧瓧鍖栥亼"로 나타난다.
오래된 하드웨어는 일반적으로 하나의 문자 집합만 지원하도록 설계되었으며, 해당 문자 집합은 일반적으로 변경할 수 없었다. 디스플레이 펌웨어에 포함된 문자표는 해당 장치가 판매될 국가의 문자를 포함하도록 현지화되었으며, 일반적으로 이 표는 국가마다 달랐다. 따라서 이러한 시스템은 다른 국가의 시스템에서 생성된 텍스트를 로드할 때 글자 깨짐 현상을 보일 수 있었다.
참조
[1]
논문
Will unicode soon be the universal code? [The Data]
[2]
웹사이트
curl -v linux.ars (Internationalization)
https://arstechnica.[...]
2004-03-31
[3]
웹사이트
Guidelines for extended attributes
http://www.freedeskt[...]
2015-02-15
[4]
웹사이트
Unicode mailinglist on the Eudora email client
https://www.unicode.[...]
2014-11-01
[5]
웹사이트
sms-scam
http://tv2.no/2014/0[...]
2014-06-19
[6]
서적
Control + Alt + Delete: A Dictionary of Cyberslang
Globe Pequot
[7]
웹사이트
Usage statistics of Windows-1251 for websites
https://w3techs.com/[...]
[8]
웹사이트
Usage statistics of KOI8-R for websites
https://w3techs.com/[...]
[9]
웹사이트
Declaring character encodings in HTML
https://www.w3school[...]
[10]
웹사이트
PRC GBK (XGB)
https://web.archive.[...]
[11]
뉴스
Some Errors Defy Fixes: A Typo in Wikipedia's Logo Fractures the Sanskrit
https://www.nytimes.[...]
2009-07-17
[12]
웹사이트
Marathi Typing {{!}} English to Marathi {{!}} Online Marathi Typing
https://marathi.indi[...]
2022-08-02
[13]
웹사이트
Content Moved (Windows)
http://msdn.microsof[...]
Msdn.microsoft.com
2014-02-05
[14]
웹사이트
Unicode in, Zawgyi out: Modernity finally catches up in Myanmar's digital world
https://web.archive.[...]
2019-12-24
[15]
웹사이트
Battle of the fonts
https://frontiermyan[...]
2019-12-24
[16]
웹사이트
Unified under one font system as Myanmar prepares to migrate from Zawgyi to Unicode
https://rising.globa[...]
2019-12-24
[17]
웹사이트
Why Unicode is Needed
https://code.google.[...]
2013-10-31
[18]
웹사이트
Myanmar Scripts and Languages
https://www.unicode.[...]
Unicode Consortium
2019-12-24
[19]
웹사이트
Integrating autoconversion: Facebook's path from Zawgyi to Unicode - Facebook Engineering
https://engineering.[...]
Facebook
2019-12-25
[20]
웹사이트
Myanmar switch to Unicode to take two years: app developer
https://web.archive.[...]
2019-12-24
[21]
서적
CJKV日中韓越情報処理
オライリージャパン
[22]
서적
日本語情報処理
ソフトバンククリエイティブ
[23]
웹사이트
漢字トーク KanjiTalk
http://www.d4.dion.n[...]
2009-08-30
[24]
문서
위키피디아 로고의 글자는 깨지지 않았는데, 이는 로고가 사진이여서 그렇다.
[25]
Youtube
구글 노토 폰트 프로젝트
https://www.google.c[...]
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com