자주 볼 수 있는 정겨운 깨진 한글들

오늘 IRC에서 얘기하다가 생각나서
예전부터 있었던 정겨운 깨진 한글들 패턴 몇개를 모아서 소개해 봅니다. 🙂

占쏙옙占쏙옙!

주로 맥이나 emacs, gnome-terminal등등 유니코드 처리를 하긴 하는데, 설정을 뭔가 잘못했거나 제대로 못 처리한 경우에 자주 발생하는 놈입니다. 구글에서 검색하면 무려 1450000건이나 나옵니다. -ㅇ-; 가히 깨진 한글 중 최고봉..

이 녀석의 의미는 U+FFFD U+FFFD를 utf-8로 인코딩한 것을 euc-kr로 푼 것입니다. 디코드하는 녀석은 euc-kr을 바라고 있고, 인코딩하는 녀석은 뭔가 안에서 단단히 꼬인 경우죠. U+FFFD는 REPLACEMENT CHARACTER이라고, 뭔가 잘못되면 이걸로 글자 수를 유지하기 위해서 바꾸는 경우가 있습니다. 이 경우 대부분 보내는 놈이 잘못했다고 눈치를 챌 수 있습니다.

홰聆究셀

옛날에 PC통신 하시던 분들은 자주 보셨을 것 같은데, 이것도 지금 구글에서 검색하면 29900건이 나오는 상당히 인기깨진한글 입니다. 홰영구셀은 점쏙옙과는 달리 좌우로 물음표나 좀 불길한 표시가 곁들여진다는 특징이 있죠. 🙂

이 놈의 정체는 바로 euc-kr에서 “안녕하세요”에서 첫 바이트를 떼낸 것입니다. 안녕하세요는 문자열이나 각 줄의 맨 앞에 자주 와서 앞 글자가 잘리는 경우가 유독 많죠~

컴컴컴컴컴컴넴

요새는 컴컴컴컴컴이 나오면 좀 어색하겠지만, 옛날에는 동네 꼬마아이들도 컴컴컴컴을 보면 이게 바로 그거구나! 하고 정겨워할 정도였었죠~ 컴컴컴컴컴에는 옆에 넴이나 백백백, 낡낡이 곁들여 줘야 좀 더 맛이 납니다. 이 놈의 정체는 미국 영어 코드페이지인 cp437에서 좌우로 긋는 선문자입니다. 아직도 와레즈 그룹들은 cp437을 자주 쓰는 관계로 .nfo 파일들에서 컴컴컴컴을 만날 수 있어서 나름대로(?) 반갑습니다;;

이 녀석은 구글에서 검색이 되긴 하는데, 길이에 따라 따로 따로 인덱스되어 있어서 전체적인 수는 정확히 모르겠지만 대략 5000은 될 것 같네요.

덈뀗섏꽭 쩗꿇뀘

요놈은 고정적인 내용을 가지는 것은 아니고 대충 “띠리띠리”가 새끼손가락 콧구멍에 넣고 외계와 통신할 때 내는 소리로 깨지는 형태입니다. 이것도 어설픈 유니코드 프로그램에서 상당히 자주 볼 수 있죠. 이 놈의 정체는 utf-8 인코딩된 것을 cp949로 푼 것입니다. 주로 겹자음과 희한한 받침들이 오는데, 그 이유는 utf-8에서 쓰는 영역이 주로 두 번째 바이트에 0x81~0x9f를 많이 써서, 그 영역이 cp949에서 euc-kr에 추가로 배치한 자주 안 쓰이는 한글 영역과 겹치기 때문입니다.

)C>H3gGO

이것도 고정적인 내용은 아니고 그냥 형태입니다. 주로 대문자, 소문자, 기호 몇가지가 나오고 중간 중간 음표도 곁들여 주며 나오는 이 모양은 8비트를 모두 지원하지 않는 환경에서 EUC-KR에서의 상위 비트가 모두 날아간 놈입니다. 최근에는 볼 일이 거의 없지만, 예전에는 한국IBM같이 도미노 솔루션을 쓰던 곳에서 보낸 메일이 이런식으로 안 보이게 보여서 난감한 경우가 있었죠. 그리고, ISO-2022-KR로 인코드하고 나서 제어문자 필터링에 걸려서 제어문자가 유실되는 경우도 이렇게 됩니다.

¾È³çÇϼ¼¿ä~

아마도 가장 흔하게 많이 볼 수 있는 형태가 아닌가 싶네요~ 요건 EUC-KR을 ISO-8859로 보고 디코딩했을 때 발생하는 형태입니다. 즉, 한글 1글자가 EUC-KR에서 높은 2 바이트가 되기 때문에, ISO-8859에서의 추가 문자에 해당하는 것들이 2개씩 나오게 됩니다. 요건 그래도 ISO-8859-1이 256개 모두 할당되어 있어서 정보의 손실은 없어서 복구는 가능하기 때문에, 다른 것들에 비해서 그래도 준수한 편이라고 할 수 있겠죠. 🙂

켓아~

요놈은 대부분의 글자가 보이지만 일부가 고정적으로 다른 글자로 대체되는 형태입니다. 대표적으로 “횽아” -> “켓아”와 “아햏햏” -> “아쥑쥑” 이 있죠. 둘다 구글에서 검색해 보면 용례가 그렇게 많지는 않지만, 의외로 유닉스 프로그램들에서는 상당히 자주 겪는 패턴입니다.
이 경우는 인코딩이 euc-kr이라고 가정하고, 두 번째 바이트 글자의 하위 7비트만 보고 디코딩해서 생기는 문제입니다. cp949의 경우에는 두 번째 바이트에 MSB가 없는 경우가 있기 때문에, 구분해 줘야 글자를 제대로 판단할 수 있겠죠.

우선 생각나는 것은 써 봤는데, 그 외에 자주 봤던 깨진 한글 있으시면 알려주시면 추가하겠습니다. ^_^