바이트 순서 표식
바이트 순서 표시(Byte Order Mark, BOM)는 유니코드 문자, codice_1 (BOM)으로, 텍스트 스트림 시작 부분에 있는 매직 넘버처럼 나온 것은 텍스트를 소비하는 프로그램에 여러 가지 내용을 알려줍니다:
BOM의 사용은 옵션이며, 사용되었다면, 텍스트 스트림 시작 부분에 나와야 합니다.
유니코드는 8비트, 16비트 혹은 32비트 정수 단위로 인코딩될 수 있습니다. 16비트 그리고 32비트 표현을 위해, 임의의 출처로 부터 텍스트를 수신하는 컴퓨터는 정수가 인코딩 된 바이트 순서가 무엇인지 알아야 합니다. BOM 자체는 나머지 문서와 동일한 스킴으로 인코딩되지만 정해진 값을 가지고 있기 때문에, 텍스트의 컨슈머는 인코딩을 알아내기 위해 첫 몇 바이트를 검사할 수 있습니다. 따라서 BOM은 텍스트 스트림 외부에 어떤 거래 혹은 메타 데이터를 요구하지 않고 텍스트 컨슈머에게 텍스트 엔디언을 설명해주기 위한 방법으로 텍스트 프로듀서를 제공합니다. 수신 컴퓨터가 텍스트 스트림을 수신하고 나면, 자신의 네이티브 바이트 순서로 문자들을 자유롭게 처리하게 되며 BOM은 더 이상 필요하지 않습니다. 그래서 BOM에 대한 요구는 닫혀 있는 환경의 보다는 텍스트 교환 측면에서 일어납니다.
BOM 문자의 바이트 시퀀스는 유니코드 인코딩 별로 다르며, 다른 인코딩으로 저장된 텍스트 스트림에서는 시작 부분에 해당 시퀀스가 나타나지 않습니다. 그러므로, 텍스트 시작 부분에 인코딩된 BOM을 두는 것은 텍스트가 유니코드 임을 나태내고, 엔디언이 없는 UTF-8의 경우 조차도, 사용되는 인코딩 스킴을 식별하는데 도움을 줄 수 있습니다. BOM 문자의 이러한 일반적인 용도를 유니코드 시그니처라고 부르며, 유니코드 시그니처는 UTF-7과 같이 유니코드 표준의 일부가 아닌 유니코드 기반의 인코딩 스킴으로도 확장됩니다.
BOM 문자가 데이터 스트림 중간에 나오면, "zero-width non-breaking space" (word-glyphs 사이에서 line-breaking을 금지)으로 해석되어야 한다고 유니코드가 알려주는 것입니다. 유니코드 3.2에서, 이 사용법은 "단어 결합자" 문자인 U+2060으로 인해 사용 폐기되었습니다. 그로 인해 U+FEFF는 BOM으로만 사용됩니다.
BOM의 UTF-8 표현은 (16진수) 바이트 시퀀스인 codice_2 입니다. 텍스트를 ISO-8859-1 혹은 CP1252로 잘못 해석하는 텍스트 에디터 혹은 웹 브라우저는 이를 codice_3 문자로 표시합니다.
유니코드 표준은 UTF-8의 BOM을 허용하지만, 그것의 사용은 필수가 아니며 권장되지도 않습니다. UTF-8에서 바이트 순서는 어떤 의미도 없어서, UTF-8에서 사용되는 경우 텍스트 스트림이 UTF-8로 인코딩되었거나, 혹은 다른 BOM을 포함한 또 다른 스트림에서 변환되었다는 것을 알리기 위함이 유일한 용도입니다. 또한 해당 표준은 BOM이 존재하는 경우 제거하는 것을 권장하지는 않으므로, 인코딩을 변경하는 것으로 인한 정보 손실은 없어 BOM에 의존하는 코드는 계속 동작합니다. IETF는 프로토콜이 (a) 항상 UTF-8을 사용하거나 (b) 인코딩이 사용되고 있는지를 나타낼 다른 방법을 가진 경우, "U+FEFF를 시그니처로 사용하는 것을 금지해야 한다"고 합니다.
BOM을 사용하지 않는 경우 유니코드를 인지하지 못하는 일부 소프트웨어와 텍스트가 하위 호환될 수 있습니다. 예로는 문자열 리터럴 내에서 ASCII가 아닌 바이트를 허용하지만 파일의 시작 부분에서는 그렇지 않은 프로그래밍 언어가 있습니다.
만약 인코딩에 대한 BOM이나 다른 지시가 없는 경우, UTF-8에서 유효하지 않은 많은 수의 바이트 시퀀스로 인해 UTF-8이 사용 중인지를 휴리스틱 분석으로 신뢰도 있게 알 수 있습니다(텍스트가 UTF-8이 아닌 것으로 밝혀진 경우 어떤 레거시 인코딩이 어렵고 불확실할 수 있는지를 결정합니다. Mozilla Universal Charset Detector와 International Components for Unicode와 같이, 몇 가지 무료 라이브러리를 사용해 쉽게 작업할 수 있습니다).
마이크로소프트의 컴파일러와 인터프리터 그리고 노트패드와 같은 마이크로소프트 윈도우의 많은 소프트웨어들은 BOM을 휴리스틱을 이용하지 않고 필수적인 매직 넘버처럼 처리합니다. 이 도구들은 UTF-8로 텍스트를 저장할 때 BOM을 추가하며, BOM이 나타나지 않거나 파일에 ASCII만 포함되어 있지 않다면 UTF-8을 해석할 수 없습니다. 또한 구글 독스는 문서를 다운로드를 위한 플레인 텍스트로 변환할 때 BOM을 추가합니다.
UTF-16에서, BOM(codice_1)은 파일의 첫번째 문자 혹은 캐릭터 스트림으로 배치되어 파일이나 스트림의 모든 16비트 코드 단위의 엔디언(바이트 순서)을 나타냅니다. 만약 잘못된 엔디언으로 해당 스트림을 읽으려고 하면, 바이트가 스와핑되어서, 텍스트 내에서 결코 나타나서는 안되는 "비문자"로 유니코드에 의해 정의된 U+FFFE를 전달합니다.
UTF-8을 예상하는 프로그램은 UTF-8 인코딩 오류를 다루는 방법에 따라, 오류 내용을 표시합니다. 모든 경우 그 프로그램들은 아마도 파일의 나머지 부분을 쓸모없는 데이터로 표시합니다(ASCII 만 포함하는 UTF-16 텍스트는 잘 읽을 수 있을 겁니다).
IANA에 등록된 문자인 UTF-16BE와 UTF-16LE의 경우, 이런 문자 집합의 이름이 이미 바이트 순서를 결정하기 때문에 바이트 순서 표시를 사용하면 안됩니다. 텍스트 스트림 내 어디서든 발견되면 U+FEFF는 "zero width no-break space"로 해석됩니다.
유니코드 표준의 D98항 기준은 "UTF-16 인코딩 스킴은 BOM으로 시작할 수도 그렇지 않을 수도 있습니다. 하지만, BOM이 없다면, 그리고 고수준의 프로토콜이 아니라면, UTF-16 인코딩 스킴의 바이트 순서는 빅 엔디언입니다."라고 명시하고 있습니다. 고수준의 프로토콜이 강제되고 있는지 아닌지는 해석의 차이입니다. 예를 들어, 네이티브 바이트 순서가 리틀 엔디언인 컴퓨터의 로컬 파일은 암시적으로 UTF-16LE로 인코딩되도록 강제합니다. 그러므로, 빅 엔디언에 관한 추정은 널리 무시됩니다. 반대로, 그런 파일과 같은 파일이 인터넷에서 접근 가능하다면, 그러한 추정을 할 수 없습니다. ASCII 범위 혹은 공백 문자(U+0020)에서 16비트 문자의 검색은 UTF-16 바이트 순서 결정의 한 방법입니다.
BOM을 UTF-32와 함께 사용할 수는 있지만, 이 인코딩은 전송에 거의 사용되지 않습니다. 만약 사용된다면, UTF-16과 동일한 규칙이 적용됩니다.
아래 표는 BOM 문자가 다양한 인코딩에서 바이트 시퀀스로 표현되는 방법과 각각의 바이트를 레거시 인코딩(C0 제어를 위한 CP1252와 심볼)으로 해석하고 있는 텍스트 에디터에서 그러한 시퀀스가 출력되는 방식을 나타내고 있습니다.