1. 개요
Windows XP, Windows 2000의 메모장에서 ANSI 인코딩으로 저장된 문자열을 UTF-16으로 읽어서 발생하는 버그.2. 증상
메모장에 Bush hid the facts처럼 특정 패턴의 글자로 이루어진[1] 문장을 작성하고 ANSI 인코딩으로 저장하면 그 파일을 다시 열었을 때 문장 대신 한자들로 바뀐다.[2] 다음 한자들은 별 의미가 없다.[3]3. 원인
ASCII 형태의 텍스트 파일을 UTF-16으로 읽어서 벌어진다. UTF-16으로 해석했을 때 보통 U+6100부터 U+7AFF에 이르는 영역의 문자로 해석되는데, 이 문자들은 모두 한자에 속하므로 결과물은 항상 한자로 나온다.Windows XP의 메모장에는 BOM이 없어도 해당 파일이 유니코드인지 구별하기 위해 Windows API의
IsTextUnicode 함수를 사용하는데, 이게 Bush hid the facts와 같은 일부 텍스트를 UTF-16으로 인식되어버려서 발생한다.
Windows Vista에 내장된 메모장부터는 구현 방식을 바꿨는지 버그가 고쳐졌지만, API 자체의 버그는 고쳐지지 않았기 때문에 해당 API를 사용하는 프로그램들은 여전히 버그가 발생한다. 참고로
Windows 98이나
Windows Me의 메모장은 유니코드를 지원하지 않기 때문에 해당 버그가 일어날 여지가 없다.상세한 설명이 담긴 유튜브 영상. 이에 따르면 알고리즘에서 홀수 번째 바이트와 짝수 번째 바이트끼리 값 차이를 계산함으로써 유니코드 여부를 테스트하는 것이라고 한다.[4] 그러나 이 테스트는 추정이다. 따라서 이 알고리즘을 역이용하여 로마자 텍스트를 적을때 띄어쓰기나 문장부호 등을 적절히 사용한다면 일종의 false positive에 걸리게 되어 윈도우가 UTF-16으로 오판하게 되는 것이다.
영단어의 경우 대체로 홀수 글자씩으로 맞춘다면 (홀짝 중 특정한 위치에서 띄어쓰기가 발생하면서) 이 버그가 생길 확률이 높아진다. 위의 Bush hid the facts의 경우에도 첫 단어를 제외하고는 모두 홀수에 해당한다. [예시설명]
Bush hid the facts를 UTF-16 형식으로 인식하면 글자가 2바이트씩 묶이며, Little Endian 형식의 경우 묶인 바이트가 순서가 뒤바뀐다. 아래에서는 편의상 16진수가 아닌 문자로 표기한다.
-
Big Endian:
B-u / s-h / (Space)-h / i-d / (Space)-t / h-e / (Space)-f / a-c / t-s -
Little Endian:
u-B / h-s / h-(Space) / d-i / t-(Space) / e-h / f-(Space) / c-a / s-t
한자로 바뀐 내용을 지우고 다시 Bush hid the facts라고 적고 저장을 하면 버그가 발생하지 않는다는 말이 퍼지기도 했는데, 이는 위에서 말했듯이 UTF-16 형식으로 저장이 되었기 때문이다. 즉 텍스트 형식이 ASCII에서 UTF-16으로 바뀌어서 그렇다는 것.
4. 기타
메모장의 또다른 버그로는 "자동 줄바꿈" 기능 관련 버그가 있다. Windows NT 3.51에서부터 Windows 7에도 있는 버그이다.[6] 이 버그는 Windows 10 1709 기준 해결된 상태이다. 설명하자면 자동 줄바꿈이 설정된 상태에서 텍스트 파일을 저장하고 창 크기를 조절하면 줄바뀜 부분이 강제 줄 바꿈된 것처럼 잘려서 나오는 현상이다.[7] 텍스트를 잠깐 열어보기만 할게 아니라면 차라리 워드패드를 쓰는 것이 편할지도 모른다. 그리고 만약 코딩이 목적이라면 메모장이나 워드패드 대신 Notepad++나 EditPlus 등의 전문 편집기를 쓰는 것이 좋다.몇몇 커뮤니티에서는 하필이면 원문이 ' 부시가 진실을 숨겼다'인 것과 당시 9.11 테러, 이라크 전쟁 등과 관련된 음모론과 엮여서 해당 인코딩 버그로 나온 한자를 '진실은 곧 밝혀진다'와 같이 해석하는 경우가 있는데[8][9], 위에서 말했듯이 이는 버그일 뿐이다. 즉 해당 한자들은 아무 의미가 없다. 저 버그가 발생한 OS인 Windows XP가 2001년 10월에 나왔기에 9.11 테러와 절묘하게 시기가 겹쳐서 저렇게 알려진 것일 뿐이다. 물론 상술했듯 저 버그는 Windows 2000에도 존재한다.
[1]
일반적으로 4-3-3-5개 글자로 알려져 있는데, 4-3-3-5개의 글자로 이루어진 문장이라고 해서 꼭 버그가 발생하는 것도 아니며, 4-3-3-5 패턴이 아닌 문장에서 버그가 발생하기도 한다. 줄바꿈 문자가 들어가면 버그가 발생하지 않는다고 한다.
[2]
일부 한자는 확장 한자에 속하기 때문에 메모장 기본 글꼴인 'Fixedsys'에서는 사각형 모양으로 나온다. 이 경우 글꼴을 바꿔주면 제대로 나온다.
[3]
끝의 捡獴 때문에
구글 번역기를 돌리면 "
몽구스를 집어든다"라고 나오고
파파고를 돌리면 "
미어캣을 줍는다"라고 나왔으나 현재는 구글에선 '몽구스', 파파고에선 '몽구스 줍기' 라고 뜬다.
[4]
동북아의
CJK처럼 2바이트가 필수적인 언어들의 경우에는, 이를 16진수로 환산하면 65 7E / 66 2A 등과 같이 홀짝 중 한쪽은 변화가 적고 한쪽은 변화가 랜덤할 것이며 (전체 256*256=65,536개 중 일부 대역만 갖다 쓸 것이기 때문), 로마자를 UTF-16으로 저장하면 한쪽은 사실상 00(공백)만 반복될 것이다. 즉 이런 식으로 홀짝 중 한쪽은 바이트 변화가 크고, 한쪽은 작다면 유니코드일 것으로 추정하는 것이며, 일반적으로 UTF-8을 타이핑한다면 그러지 않을 것으로 추정하는 것이다.
[예시설명]
다음 글은 이 버그의 유도법에 대한 설명이면서, 동시에 이 버그를 발생시키는 문구이기도 하다. 위의 유튜브 영상 댓글에서 발견 가능. 원문: So I ran a few tests and found the exact letters and words don't influence notepad's unicode detection algorithm too significantly. By far the biggest factor is the location of the space and punctuation symbols. If the space and punctuation symbols occur primarily at an odd index, then the unicode detection algorithm can get a large bonus towards the odd/lower bytes since the ascii distances between the punctuation symbols and lowercase letters greatly exceeds the ascii distances between any two lowercase letters. This means that if you use words with an odd number of letters, most space symbols end up on the odd indices. However, writing sentences using exclusively odd number of letters for all the words isn't easy. You can therefore sometimes use pairs of even words for a nicer structure. By using these tips, you can write quite lengthy sentences which sound almost completely natural without having to recalculate a new score every other character. PS. This whole comment would get censored by notepad
[6]
다만
Windows 9x 계열에서는 발생하지 않는다.
[7]
물론 실제 텍스트 파일까지 강제 개행이 된 것은 아니라서, 메모장을 껐다 켜면 정상적으로 돌아온다.
[8]
스펀지에서도 이 뜻으로 해석했으며,
대만의 어느 커뮤니티에서도 이와 같은 해석이 나왔다고 한다.
[9]
한자폰트가 없는 영어권에서는 □□□로 나오기때문에 검열당한것으로 해석하기도 했다.