바이트 순서 표식

위키백과, 우리 모두의 백과사전.
이동: 둘러보기, 검색
유니코드
부호화 형식
UCS
양방향 텍스트
BOM
한중일 통합 한자
유니코드 범위 목록
유니코드 정규화
유니코드와 HTML
유니코드와 전자 우편
유니코드 글꼴
v  d  e  h

바이트 순서 표시(Byte Order Mark, BOM)는 유니코드 문자, U+FEFF 바이트 순서 표식(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으로만 사용됩니다.

UTF-8[편집]

BOM의 UTF-8 표현은 (16진수) 바이트 시퀀스인 0xEF, 0xBB, 0xBF 입니다. 텍스트를 ISO-8859-1 혹은 CP1252로 잘못 해석하는 텍스트 에디터 혹은 웹 브라우저는 이를  문자로 표시합니다.

유니코드 표준은 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[편집]

UTF-16에서, BOM(U+FEFF)은 파일의 첫번째 문자 혹은 캐릭터 스트림으로 배치되어 파일이나 스트림의 모든 16비트 코드 단위의 엔디언(바이트 순서)을 나타냅니다. 만약 잘못된 엔디언으로 해당 스트림을 읽으려고 하면, 바이트가 스와핑되어서, 텍스트 내에서 결코 나타나서는 안되는 "비문자"로 유니코드에 의해 정의된 U+FFFE를 전달합니다.

  • 16비트 단위가 빅엔디언 바이트 순서로 나타나면, 해당 BOM 문자는 0xFF 뒤에 0xFE가 오는 순서의 시퀀스로 나옵니다. 이 시퀀스는 텍스트가 ISO-8859-1인 것으로 간주하는 텍스트 디스플레이에서 ISO-8859-1 문자인 으로 þÿ 나옵니다.
  • 16비트 단위가 리틀엔디언 순서를 사용한다면, 0xFE 다음에 0xFF가 오는 순서의 시퀀스가 나옵니다. 이 시퀀스는 텍스트가 ISO-8859-1인 것으로 간주하는 텍스트 디스플레이에서 ISO-8859-1 문자인 으로 ÿþ 나옵니다.

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 바이트 순서 결정의 한 방법입니다.

UTF-32[편집]

BOM을 UTF-32와 함께 사용할 수는 있지만, 이 인코딩은 전송에 거의 사용되지 않습니다. 만약 사용된다면, UTF-16과 동일한 규칙이 적용됩니다.

인코딩 별 바이트 순서 표시[편집]

아래 표는 BOM 문자가 다양한 인코딩에서 바이트 시퀀스로 표현되는 방법과 각각의 바이트를 레거시 인코딩(C0 제어를 위한 CP1252와 심볼)으로 해석하고 있는 텍스트 에디터에서 그러한 시퀀스가 출력되는 방식을 나타내고 있습니다.

인코딩 표현 (16진수) 표현 (10진수) CP1252 문자로 된 바이트
UTF-8 [인코딩 별 바이트 순서 1] EF BB BF 239 187 191 
UTF-16 (BE) FE FF 254 255 þÿ
UTF-16 (LE) FF FE 255 254 ÿþ
UTF-32 (BE) 00 00 FE FF 0 0 254 255 ␀␀þÿ ( 은 ASCII 널 문자를 참조합니다)
UTF-32 (LE) FF FE 00 00[인코딩 별 바이트 순서 2] 255 254 0 0 þÿ␀␀ ( 은 ASCII 널 문자를 참조합니다)
UTF-7[인코딩 별 바이트 순서 1] 2B 2F 76 38

2B 2F 76 39

2B 2F 76 2B

2B 2F 76 2F[인코딩 별 바이트 순서 3]

2B 2F 76 38 2D[인코딩 별 바이트 순서 4]

43 47 118 56

43 47 118 57

43 47 118 43

43 47 118 47

43 47 118 56 45

+/v8

+/v9

+/v+

+/v/

+/v8-

UTF-1[인코딩 별 바이트 순서 1] F7 64 4C 247 100 76 ÷dL
UTF-EBCDIC[인코딩 별 바이트 순서 1] DD 73 66 73 221 115 102 115 Ýsfs
SCSU[인코딩 별 바이트 순서 1] 0E FE FF[인코딩 별 바이트 순서 5] 14 254 255 ␎þÿ ( 는 ASCII "쉬프트 아웃" 문자를 표현합니다)
BOCU-1[인코딩 별 바이트 순서 1] FB EE 28 251 238 40 ûî(
GB-18030[인코딩 별 바이트 순서 1] 84 31 95 33 132 49 149 51 „1•3
  1. 이것은 리터럴한 "바이트 순서" 표시가 아닌데, 바이트가 해당 인코딩의 코드 단위가 아니고 해석될 바이트 순서도 없기 때문입니다. 하지만, 시퀀스의 뒤에 있는 텍스트의 인코딩을 가리키기 위해 시퀀스를 사용할 수 있습니다.
  2. 이것은 BOM과 NUL로 시작하는 UTF-16LE 파일과 동일한 바이트 패턴입니다.
  3. UTF-7에서, base64로 된 인코딩 앞에 오는 BOM의 4번째 바이트는 이진수로 001111xx입니다. 마지막 두 비트, xx는 명확히 말하자면 BOM의 일부가 아닌데, BOM 다음에 처음으로 인코딩된 문자 중 첫 두 비트를 포함합니다. 위 표에서는 가능한 네 개의 바이트 조합 뿐만 아니라 빈 문자열을 위해 사용된 다섯째 바이트도 보여주고 있습니다.
  4. 인코딩된 다음 문자가 존재하지 않는다면, 38이 4번째 바이트로 사용되고 다음 바이트는 2D가 됩니다.
  5. SCSU는 U+FEFF의 다른 인코딩을 허용하며, 위 형식은 UTR #6에서 권장되는 시그니처입니다.