바이트 순서 표시(Byte Oder Mark, BOM)은 UTF-8, UTF-16 등을 구분하기 위한 값
UTF-8은 BOM 값을 사용하지 않아도 되지만, 윈도우 기본내장 프로그램등에서는 UTF-8(BOM)을 기본으로 사용하며, 유닉스/리눅스 편집 프로그램에서는 UTF-8을 기본으로 사용
윈도우는 UTF-8, UTF-8(BOM) 모두 인식하여 처리하지만, 유닉스/리눅스에서는 UTF-8만 처리하고 UTF-8(BOM)은 처지하지 못하여, 크로스 플랫폼에서 UTF-8 형식으로 오류가 발생하기도 함
UTF-8에는 BOM이 없는 것이 일반적입니다. 왜냐하면 UTF-8은 BOM이 1가지로 고정이라 인코딩 방식을 바로 알 수 있기 때문입니다. 그런데 윈도우 프로그램의 메모장 같은 것들은 UTF-8 파일을 생성할 때 자동으로 BOM을 꼬박꼬박 집어넣어줍니다.
그런데 이게, 윈도우 환경 안에서는 별 탈없이 잘 돌아가지만, LINUX나 UNIX 계열의 환경으로 Data가 전달 될 때에는 많은 문제를 일으키는 원인이 되기도 합니다. BOM이 추가되면 글자 앞에 빈칸이 생기면서 구분을 하게 되는데 이러한 형태가 대개는 사람의 입장에서 눈으로 확인이 어렵다는 점이 있습니다.
바이트 순서 표시(Byte Order Mark, BOM)는 유니코드 문자 U+FEFF byte order mark로, 매직 넘버로서 문서의 가장 앞에 추가하여 텍스트를 읽는 프로그램에 여러 정보를 전달할 수 있다.
BOM을 반드시 사용할 필요는 없으며, 사용할 경우 문서의 가장 앞에 등장해야 한다.
유니코드는 8비트, 16비트 혹은 32비트 정수 단위로 인코딩할 수 있다. 16비트 및 32비트 표현의 경우, 알 수 없는 출처로부터 텍스트를 읽는 컴퓨터는 데이터를 어떤 바이트 순서로 인코딩했는지 알아야 한다. BOM은 문서의 나머지 부분과 같은 방식으로 인코딩되며 바이트 순서가 바뀔 경우 비문자인 유니코드 코드 포인트가 되므로, 이 텍스트를 읽는 프로세스는 문서 외적인 정보 없이도 처음 몇 바이트를 검사함으로써 엔디언을 확인할 수 있다. 이후 수신자는 필요할 경우 바이트 순서를 자신의 엔디안에 맞게 바꾸며, 이 이후의 처리에는 더 이상 BOM이 필요하지 않다.
BOM의 바이트열은 유니코드 인코딩마다 다르며, 이들이 다른 인코딩으로 저장된 문서의 가장 앞에 등장할 가능성은 적다. 그러므로, 문서의 가장 앞에 인코딩된 BOM을 추가함으로써 텍스트가 유니코드임을 나타내고 그 인코딩 방식을 명시할 수 있다. BOM 문자를 이 방식으로 사용하는 것을 "유니코드 시그니처"라 한다.
BOM 문자가 데이터 스트림 중간에 등장할 경우, 유니코드에서는 이를 "폭과 줄 바꿈 없는 공백"(단어 문자 사이에서 줄바꿈을 방지함)로 해석해야 한다고 명시하고 있다. 유니코드 3.2에서는 이 용례를 단어 결합자 (U+2060)로 대체하는 것을 권장하며, 이로 인해 U+FEFF는 BOM의 용도로만 사용할 수 있게 되었다.