바이트 순서 표식

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 역사적 배경
3. 사용법
4. 사용해야 하는가?
5. 인코딩에 따른 바이트 순서 표식
참조

1. 개요

바이트 순서 표식(BOM)은 유니코드 텍스트 파일의 시작 부분에 삽입되어, 해당 파일의 인코딩 방식과 엔디안(바이트 순서)을 나타내는 특수 문자이다. 유니코드의 다양한 인코딩 방식과 바이트 순서의 차이를 식별하기 위해 개발되었으며, 특히 UTF-16과 UTF-32에서 사용된다. UTF-8에서는 BOM 사용이 권장되지 않지만, 파일이 UTF-8로 인코딩되었음을 나타내는 용도로 사용될 수 있다. BOM은 XML과 같은 특정 형식에서는 필수적으로 사용되며, JSON과 같은 형식에서는 사용이 권장되지 않는다.

더 읽어볼만한 페이지

유니코드에 관한 - UTF-8
UTF-8은 유니코드 문자를 표현하는 가변 길이 문자 인코딩 방식으로, ASCII 코드와 호환성을 유지하며 다양한 언어의 문자를 표현할 수 있도록 설계되었지만, 보안 문제점과 공간 효율성 측면에서 단점을 가진다.
유니코드에 관한 - UTF-1
UTF-1은 유니코드 초기 버전을 인코딩하기 위해 1992년에 설계된 가변 길이 문자 인코딩 방식으로, ASCII 호환성을 유지하고 ISO 2022 및 MIME과의 호환성을 고려했지만, "모듈로 190" 산술을 사용하는 특징과 현대 유니코드 표준과의 차이점을 가진다.
유니코드 - 이모지
이모지는 1999년 NTT 도코모에서 처음 도입된 그림 문자로, 유니코드 표준 제정 후 전 세계적으로 확산되어 다양한 언어적 기능을 수행하며 대중문화에 영향을 미치지만, 플랫폼별 표현 방식 차이와 의미 해석 논란도 존재한다.
유니코드 - 국제 음성 기호
국제 음성 기호는 국제 음성 협회가 개발한 언어의 음성 표기 문자 기호 체계로, 라틴 문자를 기반으로 자음, 모음, 초분절 기호 등을 포함하여 모든 언어의 음성을 정확하게 표기하는 것을 목표로 한다.
컴퓨터에 관한 - 고속 패킷 접속
고속 패킷 접속(HSPA)은 3세대 이동통신(3G)의 데이터 전송 속도를 높이는 기술 집합체로, 고속 하향/상향 패킷 접속(HSDPA/HSUPA)을 통해 속도를 개선하고 다중 안테나, 고차 변조, 다중 주파수 대역 활용 등의 기술로 진화했으나, LTE 및 5G 기술 발전으로 현재는 상용 서비스가 중단되었다.
컴퓨터에 관한 - 데이터베이스
데이터베이스는 여러 사용자가 공유하고 사용하는 정보의 집합으로, 데이터베이스 관리 시스템을 통해 접근하며, 검색 및 갱신 효율을 높이기 위해 고도로 구조화되어 있고, 관계형, NoSQL, NewSQL 등 다양한 모델로 발전해왔다.

바이트 순서 표식

2. 역사적 배경

유니코드가 개발되었을 당시에는 미국에서는 ASCII, 유럽 등에서는 ISO-8859, 일본에서는 Shift JIS나 EUC-JP와 같은 다른 문자 인코딩이 주류였고, 사용되는 부호화 방식이 유니코드임을 명시할 필요가 있었다. 또한, 유니코드의 부호화 방식은 여러 종류가 있으며, 특히 UTF-16과 UTF-32에는 각각 바이트 순서가 다른 2가지 종류가 있어서 부호화 방식끼리 구별할 필요가 있었다. 그 방법으로, 텍스트가 아닌 데이터를 맨 앞에 넣는 것이 발안되었다.^[1]

3. 사용법

BOM(바이트 순서 표식)은 텍스트 데이터의 맨 앞에 위치하여 해당 데이터가 유니코드임을 나타내고, 사용된 인코딩 방식을 판별하는 데 사용된다. 프로그램이 텍스트 데이터를 읽을 때, 선두의 몇 바이트를 통해 데이터가 유니코드로 표현되어 있는지, 어떤 부호화 형식을 사용하는지 알 수 있다.^[3]

BOM 문자가 데이터 스트림 중간에 등장할 경우, 유니코드에서는 이를 "폭과 줄 바꿈 없는 공백"으로 해석해야 한다. 즉, 단어 문자 사이에서 줄바꿈을 방지하는 역할을 한다. 유니코드 3.2부터는 이 용례를 단어 결합자(U+2060)로 대체하는 것을 권장하며,^[24] 이로 인해 U+FEFF는 BOM의 용도로만 사용할 수 있게 되었다.^[1]

3. 1. UTF-8

UTF-8의 BOM 표현은 16진수 바이트열 0xEF,0xBB,0xBF이다.

유니코드 표준은 UTF-8에 BOM을 허용하지만,^[26] 필수는 아니며 권장하지도 않는다.^[27] UTF-8은 바이트 순서가 정해져 있으므로,^[28] UTF-8에서 BOM은 파일이 UTF-8로 인코딩되었음을 나타내는 용도로만 사용된다.^[29]^[30]

BOM이 없는 텍스트는 유니코드를 인식하지 못하는 일부 소프트웨어와의 하위 호환성을 유지한다. 예를 들어, 문자열 리터럴에는 ASCII가 아닌 바이트를 허용하지만 파일의 가장 앞에서는 금지하는 프로그래밍 언어가 있다.

UTF-8은 올바른 UTF-8 문자열을 이루지 않는 바이트 조합이 많아 "성긴" 인코딩이라고 할 수 있다. 이진 데이터나 다른 인코딩으로 작성된 텍스트는 UTF-8로 올바르지 않은 바이트열을 포함할 가능성이 크다. 예외는 텍스트가 ASCII 범위의 바이트로만 작성되었을 때뿐이다. ASCII만 포함하는 텍스트는 어떤 인코딩을 사용했는지와 무관하게 UTF-8로 해석해도 문제가 없다. 이러한 특성으로 인해 휴리스틱 접근을 이용해 BOM 없이도 UTF-8을 사용하고 있는지 높은 신뢰도로 판정할 수 있다.

마이크로소프트 컴파일러^[32]와 인터프리터, 메모장 등 마이크로소프트 윈도우의 여러 소프트웨어는 휴리스틱 대신 BOM을 필수적인 매직 넘버로 취급한다. 이러한 프로그램은 UTF-8로 텍스트를 저장할 때 BOM을 추가하며, BOM이 있거나 파일에 ASCII만 포함된 경우가 아니면 UTF-8을 해석하지 못한다. 파워셸은 5.1 버전까지 UTF-8 XML 문서를 저장할 때 BOM을 추가했지만, PowerShell Core 6부터는 -Encoding 스위치로 utf8NoBOM을 추가해 문서를 BOM 없이 저장할 수 있도록 하였다. 구글 독스 역시 문서를 다운로드 가능한 플레인 텍스트로 변환할 때 BOM을 추가한다.

3. 2. UTF-16

UTF-16에서 BOM(U+FEFF)은 파일의 첫 번째 문자로 배치되어 해당 파일의 모든 16비트 코드 단위의 엔디안(바이트 순서)을 나타낸다. 이 스트림을 잘못된 엔디안으로 읽으려고 하면 바이트가 뒤집혀 문자 U+FFFE를 읽을 수 있으며, 이는 유니코드에서 텍스트에 등장해서는 안 되는 "비문자"(non-character)로 정의되어 있다.^[3]

문서가 빅 엔디언으로 작성되어 있을 경우, BOM 문자는 바이트열에서 `0xFE 0xFF`로 기록된다.
문서가 리틀 엔디언으로 작성되어 있을 경우, BOM 문자는 바이트열에서 `0xFF 0xFE`로 기록된다.

이들은 모두 올바른 UTF-8이 아니므로, 이러한 파일은 UTF-8로 인코딩되지 않았음을 알 수 있다.

IANA에 등록된 문자 집합인 UTF-16BE와 UTF-16LE의 경우, 이 문자 집합의 이름으로 이미 바이트 순서가 결정되기 때문에 바이트 순서 표식을 사용해서는 안 된다. 이런 문서 내의 어떤 위치에든 BOM이 있을 경우 "폭과 줄 바꿈 없는 공백"으로 해석한다.

BOM이 없더라도 텍스트가 UTF-16인지 및 어떤 엔디언을 사용했는지를 ASCII 문자를 이용해(즉, `0x20`에서 `0x7E` 범위 혹은 `0x0A`(LF)와 `0x0D`(CR) 바이트에 인접한 0 바이트) 추측할 수 있다. 이러한 문자가 많이 (즉, 무작위로 등장하는 경우보다 훨씬 자주) 등장할 경우 문서가 높은 확률로 UTF-16임을, 0이 짝수 번째로 등장하는지 홀수 번째로 등장하는지를 확인해 이 문서의 엔디언을 추론할 수 있다. 그러나 이 방법은 오진의 가능성이 있다.

유니코드 표준의 '적합성' (3.10장) 중 D98항에서는 "UTF-16 인코딩 스킴은 BOM으로 시작하거나 시작하지 않을 수 있다. 그러나, BOM이 없고 고수준의 프로토콜이 존재하지 않을 경우 UTF-16 인코딩 스킴의 바이트 순서는 빅 엔디언이다."라고 명시하고 있다. 고수준의 프로토콜이 언제 적용되는지는 해석의 여지가 있다. 예를 들어, 리틀 엔디언을 사용하는 컴퓨터에 저장된 파일은 암시적으로 UTF-16LE로 인코딩되었다고 할 수 있다. 이런 이유로 빅 엔디언 추정 조항은 무시되는 경우가 많다. HTML5에 사용된 W3C/WHATWG 인코딩 표준에서는 "utf-16"이나 "utf-16le"로 표시된 콘텐츠를 리틀 엔디언으로 해석하는 것으로 명시하지만,^[33] 바이트 순서 표식이 있을 경우 이 BOM을 다른 모든 사항보다 우선한다.^[34]

인코딩 형식	엔디안 구분	바이트 순서 표시 (BOM)
UTF-16	BE	0xFE 0xFF
UTF-16	LE	0xFF 0xFE
UTF-16BE		(추가는 인정되지 않음)
UTF-16LE		(추가는 인정되지 않음)

3. 3. UTF-32

UTF-32에도 바이트 순서 표식(BOM)을 사용할 수 있지만, 이 인코딩은 전송에 거의 사용되지 않는다. 그 외에는 UTF-16과 동일한 규칙이 적용된다.

리틀 엔디언 UTF-32의 BOM은 리틀 엔디언 UTF-16 BOM에 NUL^영어 문자(U+0000)가 뒤따르는 패턴(0xFF 0xFE 0x00 0x00)이다. 이는 서로 다른 인코딩에서 BOM 패턴이 같은 드문 예시이다. 따라서 BOM을 사용하여 인코딩을 식별하는 프로그래머는 UTF-32인지, 아니면 첫 번째 문자가 NUL^영어인 UTF-16인지 판단해야 한다.

인코딩 형식	엔디안	바이트 순서 표식 (BOM)
UTF-32	빅 엔디안(BE)	0x00 0x00 0xFE 0xFF
UTF-32	리틀 엔디안(LE)	0xFF 0xFE 0x00 0x00
UTF-32BE		(추가 불가)
UTF-32LE		(추가 불가)

4. 사용해야 하는가?

유니코드 표준은 UTF-8에서 BOM을 허용하지만,^[4] 사용을 요구하거나 권장하지 않는다.^[5]^[23] UTF-8은 항상 동일한 바이트 순서를 가지므로,^[6] UTF-8에서 BOM의 유일한 용도는 텍스트 스트림이 UTF-8로 인코딩되었거나, 선택적 BOM을 포함하는 스트림에서 UTF-8로 변환되었음을 시작 부분에서 알리는 것이다. 표준은 BOM이 존재할 때 BOM을 제거하는 것을 권장하지 않으므로, 인코딩 간의 왕복 처리가 정보를 잃지 않고 BOM에 의존하는 코드가 계속 작동할 수 있도록 한다.^[7]^[8]

BOM을 사용하지 않으면 텍스트가 확장 ASCII용으로 설계된 소프트웨어와 하위 호환된다. 예를 들어, 많은 프로그래밍 언어는 파일 시작 부분이 아닌 문자열 리터럴에 비-ASCII 바이트를 허용한다.

BOM은 UTF-8 인코딩을 감지하는 데 불필요하다. UTF-8은 희소 인코딩으로, 가능한 바이트 조합의 상당 부분이 유효한 UTF-8 텍스트를 생성하지 않는다. 이진 데이터와 다른 인코딩의 텍스트는 UTF-8로 유효하지 않은 바이트 시퀀스를 포함할 가능성이 높으므로, 그러한 유효하지 않은 시퀀스의 존재는 파일이 UTF-8이 아님을 나타내고, 유효하지 않은 시퀀스가 없다는 것은 텍스트가 ''UTF-8''임을 매우 강력하게 나타낸다.

마이크로소프트 컴파일러^[11] 및 인터프리터, 메모장과 같은 마이크로소프트 윈도우의 많은 소프트웨어는 BOM을 휴리스틱 대신 필수 매직 넘버로 취급한다. 이러한 도구는 텍스트를 UTF-8로 저장할 때 BOM을 추가하고, BOM이 존재하거나 파일에 ASCII만 포함된 경우가 아니면 UTF-8을 해석할 수 없다. Windows PowerShell (5.1까지)은 UTF-8 XML 문서를 저장할 때 BOM을 추가한다. 그러나 PowerShell Core 6은 문서를 BOM 없이 저장할 수 있도록 `-Encoding` 스위치에 `utf8NoBOM`을 추가했다. 구글 문서도 문서를 일반 텍스트 파일로 변환하여 다운로드할 때 BOM을 추가한다.

실제로 BOM을 사용해야 하는지, 사용하지 않아야 하는지는 유니코드를 이용하는 상위 명세에 따라 결정되는 경우가 있다. XML의 경우 UTF-16으로 인코딩하는 경우, 파일 시작 부분에 BOM을 반드시 포함해야 하며, XML을 해석하는 소프트웨어에서는 파일 시작 부분에 BOM이 있는 경우, XML 선언의 `` 지시자보다 BOM을 우선하여 인코딩을 판별해야 한다고 규정하고 있다.^[21] JSON의 경우, 네트워크로 전송할 때는 BOM을 사용하지 않아야 한다고 규정하고 있다.^[22]

UTF-8은 문자 코드로서 ASCII를 전제로 하는 프로그램에서도 거의 문제없이 작동하도록 설계되었지만, BOM 때문에 정상적으로 처리되지 않는 경우가 있다. 또한, 데이터베이스나 메모리에 로드하는 데이터 등 내부적인 데이터 형식에서는 프로그램의 성능이나 효율성을 고려하여 일반적으로 BOM을 사용하지 않는다.

5. 인코딩에 따른 바이트 순서 표식

인코딩	16진수 표현	10진수 표현	CP1252 문자로 된 바이트
UTF-8	`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`	`^@^@þÿ` (`^@`은 널 문자)
UTF-32 (LE)	`FF FE 00 00`	`255 254 0 0`	`þÿ^@^@` (`^@`은 널 문자)
UTF-7^[36]^[37]^[38]	`2B 2F 76 38` `2B 2F 76 39` `2B 2F 76 2B` `2B 2F 76 2F`	`43 47 118 56` `43 47 118 57` `43 47 118 43` `43 47 118 47`	`+/v8` `+/v9` `+/v+` `+/v/`
UTF-1	`F7 64 4C`	`247 100 76`	`÷dL`
UTF-EBCDIC	`DD 73 66 73`	`221 115 102 115`	`Ýsfs`
SCSU	`0E FE FF`	`14 254 255`	`^Nþÿ` (`^N`은 시프트 아웃 문자)
BOCU-1	`FB EE 28`	`251 238 40`	`ûî(`
GB-18030	`84 31 95 33`	`132 49 149 51`	`„1•3`

참조

_[1] 웹사이트 FAQ - UTF-8, UTF-16, UTF-32 & BOM https://www.unicode.[...] 2017-01-28
_[2] 웹사이트 The Unicode® Standard Version 9.0 https://www.unicode.[...]
_[3] 웹사이트 Zero Width No-Break Space (U+Feff) https://www.fileform[...]
_[4] 웹사이트 The Unicode Standard 5.0, Chapter 2:General Structure https://www.unicode.[...] 2009-03-29
_[5] 웹사이트 The Unicode Standard 5.0, Chapter 2:General Structure https://www.unicode.[...] 2008-11-30
_[6] 웹사이트 FAQ - UTF-8, UTF-16, UTF-32 & BOM: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If yes, then can I still assume the remaining UTF-8 bytes are in big-endian order? http://unicode.org/f[...] 2009-01-04
_[7] 웹사이트 Re: pre-HTML5 and the BOM from Asmus Freytag on 2012-07-13 (Unicode Mail List Archive) https://www.unicode.[...] 2012-07-14
_[8] 웹사이트 Bug ID: JDK-6378911 UTF-8 decoder handling of byte-order mark has changed https://bugs.java.co[...] 2021-10-14
_[9] 간행물 UTF-8, a transformation format of ISO 10646 IETF 2014-05-15
_[10] 간행물 The Syslog Protocol IETF 2009-03
_[11] 웹사이트 Unicode part 1: Windows console i/o approaches http://alfps.wordpre[...] 2012-03-24
_[12] 웹사이트 Windows 10 Notepad is Getting Better UTF-8 Encoding Support https://www.bleeping[...] 2023-03-07
_[13] 웹사이트 UTF-16LE https://encoding.spe[...] WHATWG
_[14] 웹사이트 Decode https://encoding.spe[...] WHATWG
_[15] 학술지 RFC 3629 - UTF-8, a transformation format of ISO 10646 http://tools.ietf.or[...] 2017-01-28
_[16] 문서
_[17] 웹사이트 Clarify guidance for use of a BOM as a UTF-8 encoding signature https://unicode.org/[...] 2021-01-02
_[18] 웹사이트 SDL Documentation https://docs.sdl.com[...]
_[19] 웹사이트 UTS #6: Compression Scheme for Unicode https://www.unicode.[...] 2017-01-28
_[20] 웹사이트 Unicode FAQ https://www.unicode.[...] 2012-07-25
_[21] 문서
_[22] 문서
_[23] 서적 The Unicode Standard -- Version 5.0 https://www.unicode.[...]
_[24] 웹인용 FAQ - UTF-8, UTF-16, UTF-32 & BOM https://www.unicode.[...] 2017-01-28
_[25] 웹인용 The Unicode® Standard Version 9.0 https://www.unicode.[...]
_[26] 웹인용 The Unicode Standard 5.0, Chapter 2:General Structure https://www.unicode.[...] 2009-03-29
_[27] 웹인용 The Unicode Standard 5.0, Chapter 2:General Structure https://www.unicode.[...] 2008-11-30
_[28] 웹인용 FAQ - UTF-8, UTF-16, UTF-32 & BOM: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If yes, then can I still assume the remaining UTF-8 bytes are in big-endian order? http://unicode.org/f[...] 2009-01-04
_[29] 웹인용 Re: pre-HTML5 and the BOM from Asmus Freytag on 2012-07-13 (Unicode Mail List Archive) https://www.unicode.[...] 2012-07-14
_[30] 웹인용 Bug ID: JDK-6378911 UTF-8 decoder handling of byte-order mark has changed http://bugs.sun.com/[...] 2017-01-28
_[31] 간행물 UTF-8, a transformation format of ISO 10646 국제 인터넷 표준화 기구 2014-05-15
_[32] 웹인용 Unicode part 1: Windows console i/o approaches http://alfps.wordpre[...] 2012-03-24
_[33] 웹인용 UTF-16LE https://encoding.spe[...] WHATWG
_[34] 웹인용 Decode https://encoding.spe[...] WHATWG
_[35] 웹인용 RFC 3629 - UTF-8, a transformation format of ISO 10646 http://tools.ietf.or[...] 2017-01-28
_[36] 문서 다음에 오는 문자에 따라 형태가 달라진다.
_[37] URL https://unicode.org/[...]
_[38] URL https://docs.sdl.com[...]
_[39] 웹인용 UTS #6: Compression Scheme for Unicode https://www.unicode.[...] 2017-01-28

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com