한글이 물음표나 이상한 기호로 보이는 것은 인코딩이 어긋났기 때문입니다. 깨짐이 일어나는 구조와 유니코드가 해결한 것, 글자 수와 바이트 수, 깨진 글자를 진단하는 순서를 정리했습니다.
컴퓨터는 글자를 그림으로 저장하지 않고 숫자로 저장합니다. 어떤 숫자가 어떤 글자인지 정해 둔 표가 필요한데, 이 표를 정한 약속이 문자 인코딩입니다. 초기에는 영어권에서 만든 작은 표만 있었고, 각 나라가 자기 글자를 넣은 표를 따로 만들면서 표가 여러 개로 갈라졌습니다. 가장 오래된 표 가운데 하나인 아스키는 7비트로 128개의 문자만 정했고, 영문 대소문자·숫자·기본 기호·제어 문자가 전부였습니다. 한국어 환경에서는 EUC-KR과 이를 넓힌 CP949가, 일본어 환경에서는 Shift_JIS가 오래 쓰였습니다.
파일을 저장할 때 쓴 표와 열 때 쓴 표가 다르면, 같은 숫자를 다른 글자로 읽게 됩니다. 그래서 한글이 알 수 없는 기호나 물음표로 보입니다. 내용이 손상된 것이 아니라 잘못 해석된 것이므로, 맞는 인코딩으로 다시 열면 대개 원래대로 보입니다. 반대로 깨진 상태로 다시 저장해 버리면 잘못 읽힌 글자가 그대로 굳어 되돌리기 어려워지므로, 깨진 파일은 고치기 전에 원본을 먼저 복사해 두는 것이 좋습니다.
유니코드는 세상의 모든 글자에 고유한 번호를 붙인 하나의 표입니다. 표가 하나면 나라마다 다른 표를 쓰는 문제가 사라집니다. 그 번호를 실제 파일에 몇 바이트로 적을지는 또 다른 문제이고, 그것을 정한 방식 중 가장 널리 쓰이는 것이 UTF-8입니다. 한글 완성형 음절은 유니코드에 11,172자가 모두 들어 있어, EUC-KR이 기본으로 담던 2,350자로는 적을 수 없던 글자도 표현할 수 있습니다.
UTF-8에서는 글자마다 차지하는 바이트가 달라서, 글자 수와 바이트 수가 일치하지 않습니다. 한글 10자는 30바이트쯤 됩니다. 글자 수 제한이 있는 입력란에서 한글이 영문보다 빨리 한도에 걸리는 경우, 그 제한이 바이트 기준일 가능성이 큽니다. 어떤 기준인지 모르면 짧게 쓰는 편이 안전합니다. 같은 한글 한 글자가 UTF-8에서는 3바이트지만 EUC-KR이나 UTF-16에서는 2바이트라서, 어떤 인코딩을 쓰느냐에 따라 같은 글의 파일 크기가 달라집니다.
웹 주소에는 원래 영문과 일부 기호만 쓸 수 있습니다. 그래서 한글이나 공백은 퍼센트 기호와 두 자리 16진수로 바꿔 적습니다. 주소를 복사했더니 알 수 없는 문자열이 붙어 오는 것이 이것이고, 깨진 것이 아니라 규칙대로 변환된 상태입니다. 예를 들어 '가'는 UTF-8로 EA B0 80 세 바이트이고, 주소에서는 %EA%B0%80으로 적힙니다. 공백은 %20으로 바뀝니다.
글자가 깨졌을 때 무작정 여러 설정을 바꾸기보다 아래 순서로 확인하면 원인을 빨리 찾을 수 있습니다. 대부분은 저장한 쪽과 여는 쪽의 인코딩만 맞추면 해결됩니다.
파일 이름의 '한글'이 'ㅎㅏㄴㄱㅡㄹ'처럼 자모가 풀어져 보이는 경우가 있습니다. 이것은 인코딩이 아니라 정규화의 차이입니다. 유니코드에서는 완성형 '한' 한 글자로 적을 수도, 'ㅎ'·'ㅏ'·'ㄴ' 세 자모를 이어 적을 수도 있는데, 운영체제에 따라 파일 이름을 저장하는 방식이 다릅니다. 맥 계열에서 만든 파일을 다른 운영체제로 옮길 때 자주 보이며, 보기에는 같아도 검색이나 비교에서 다른 글자로 취급될 수 있습니다.
UTF-8 파일 맨 앞에 EF BB BF라는 세 바이트가 붙어 있는 경우가 있는데, 이것을 바이트 순서 표시라고 부릅니다. 일부 프로그램은 이 표식이 있어야 UTF-8로 알아보고, 반대로 일부 프로그램은 이 표식을 글자로 읽어 첫 줄 앞에 이상한 문자가 보이게 합니다. 표 계산 프로그램에서 UTF-8 파일의 한글이 깨질 때 이 표식을 붙여 저장하면 해결되는 경우가 있고, 프로그래밍용 설정 파일에서는 반대로 떼는 편이 안전합니다.