BOM (봄; Byte Order Mark)은 '바이트 순서 표시'입니다.

유니코드가, little-endian 인지 big-endian 인지 아니면 UTF-8 인지 쉽게 알 수 있도록, 유니코드 파일이 시작되는 첫부분에 보이지 않게, 2~3바이트의 문자열을 추가하는데 이것을 BOM이라고 합니다. 텍스트 에디터 화면에서는 보이지 않고, 헥사 에디터(Hex Editor)*로 열었을 때만 보입니다.



little-endian 의 BOM:
FF FE

big-endian 의 BOM:
FE FF

UTF-8 의 BOM:
EF BB BF



UTF-8에는 BOM이 없는 것이 보통인데, 오래된 프로그램은 BOM이 있는 UTF-8 파일에 오작동할 수 있습니다.

그렇지만 한국어 편집에서는 BOM이 있는 UTF-8이 더 좋습니다. 만약 'BOM이 없는 UTF-8 파일'에 영문과 숫자만 있고 한글이 없다면, 편집기가 그 파일을 유니코드가 아닌 일반 아스키 파일로 오인하기 때문입니다.

그런데 인터넷에 올릴 HTML/CSS/XML 파일을 UTF-8로 작성할 때에는 BOM이 있으면 문제가 생길 수 있습니다.


* 울트라에디트의 헥사 모드(Ctrl+H)로 UTF-8 파일을 보면, 16비트 유니코드처럼 보이고 BOM이 있든 없든 항상 FF FE 라는 엉뚱한 BOM이 나타납니다. 이것은 울트라에디터가 유니코드를 편집할 때, 내부적으로 '16비트 little-endian 유니코드 (UTF-16LE)'로 변환하여 편집하기 때문입니다. 진짜 헥사 에디터로 보아야만 UTF-8의 BOM인 EF BB BF 가 제대로 보이게 됩니다. 물론 BOM이 없는 UTF-8이라면 BOM이 없는 것으로 나옵니다.

BOM 사용시 문제가 생기는 이유는 프로그램이 BOM을 처리하지 않기 때문입니다. 이는 프로그램이 유니코드를 지원하지 않거나, 지원하더라도 제대로 구현되지 않았다는 뜻입니다.
특히 웹에서 이러한 일이 많이 생기는 이유는 웹 프로그램들이 텍스트 파일을 로드해 붙여쓰는 경우가 많은데, 이 때, 파일의 처음에 BOM이 있을 수 있다는 가능성을 무시하고 제작된 프로그램이 많습니다. 그래서 붙여진 텍스트에는 텍스트 중간에 BOM이 존재할 수 있고, BOM의 특성상 제어문자로 오인되는 경우가 많아 처리과정에서 오류가 생겨 비정상으로 작동합니다.

정리하면:
BOM을 제대로 처리하지 못하면 유니코드를 제대로 지원하지 못하는 것입니다. 이상적으로는 제대로 된 프로그램만 사용하는 것이 가장 좋겠으나, 현실적으로는 그러기 힘들고 최대 호환성을 위해 BOM을 제거하는 것이죠.

+ Recent posts