바이트오더마크

Byte order mark
"FFF"는 여기로 리디렉션됩니다. 기타 용도는 FFF(동음이의)를 참조하십시오.

BOM(바이트 순서 표시)은 특수 유니코드 문자 코드인 U+FEFF ZERO WIDTH NO-BREAK SPACE의 특정 용도로, 텍스트 스트림 시작 시 매직 넘버로 표시되어 텍스트를 읽는 프로그램에 여러 가지 신호를 보낼 수 있습니다.[1]

  • 16비트 및 32비트 인코딩의 경우 텍스트 스트림의 바이트 순서 또는 엔디안니스.
  • 텍스트 스트림의 인코딩이 유니코드(Unicode)라는 사실, 높은 수준의 신뢰도.
  • 사용되는 유니코드 문자 인코딩.

BOM 사용은 선택 사항입니다. 비 ASC를 기대하지 않는 소프트웨어가 UTF-8을 사용하는 것을 방해합니다.파일을 시작할 때 II 바이트를 사용하지만 그렇지 않으면 텍스트 스트림을 처리할 수 있습니다.

유니코드는 8비트, 16비트 또는 32비트 정수 단위로 인코딩할 수 있습니다. 16비트 및 32비트 표현의 경우, 임의의 소스로부터 텍스트를 수신하는 컴퓨터는 정수가 어떤 바이트 순서로 인코딩되었는지 알아야 합니다. BOM은 문서의 나머지와 동일한 방식으로 인코딩되며 바이트가 스왑되면 문자가 아닌 유니코드 코드 포인트가 됩니다. 따라서 텍스트에 액세스하는 프로세스는 텍스트 스트림 자체 외부의 계약이나 메타데이터를 요구하지 않고 처음 몇 바이트를 검사하여 엔디안니스를 결정할 수 있습니다. 일반적으로 수신 컴퓨터는 필요에 따라 바이트를 자체 엔디안니스로 전환하고 더 이상 처리를 위해 BOM이 필요하지 않습니다.

BOM의 바이트 시퀀스는 유니코드 인코딩마다 다르며(UTF-7과 같은 유니코드 표준을 벗어난 것을 포함하여 아래 표 참조), 다른 인코딩에 저장된 텍스트 스트림의 시작 부분에 시퀀스가 나타나지 않을 가능성이 높습니다. 따라서 텍스트 스트림의 시작 부분에 인코딩된 BOM을 배치하면 텍스트가 유니코드임을 나타낼 수 있으며 사용된 인코딩 방식을 식별할 수 있습니다. 이러한 BOM의 사용을 "유니코드 서명"이라고 합니다.[2]

사용.

BOM은 간단히 유니코드 코드 포인트입니다. U+FEFF ZERO WIDTH NO-BREAK SPACE, 현재 인코딩으로 인코딩되었습니다. 바이트로 시작하는 텍스트 파일 FE FF 파일이 빅엔디안 UTF-16으로 인코딩되었음을 시사합니다.

데이터 스트림 중간에 BOM이 나타나면 ZWNBSP라는 이름을 사용해야 합니다. 유니코드는 BOM이 아닌 일반 코드 포인트(즉, 단어 조인자)로 해석해야 한다고 말합니다. 유니코드 3.2 이후로 이 사용은 다음과 같은 이유로 사용이 금지되었습니다. U+2060 WORD JOINER.[1]

이 코드 포인트의 유니코드 1.0 이름은 BYTE ORDER MARK[3]

UTF-8

BOM의 UTF-8 표현은 (16진수) 바이트 시퀀스입니다. EF BB BF.

유니코드 표준은 UTF-8의 BOM을 허용하지만 [4]사용을 요구하거나 권장하지는 않습니다.[5] UTF-8은 항상 같은 바이트 순서를 [6]가지므로 UTF-8에서 유일하게 사용되는 것은 텍스트 스트림이 UTF-8로 인코딩되었거나 선택적인 BOM이 포함된 스트림에서 UTF-8로 변환되었음을 처음에 알리는 것입니다. 또한 이 표준에서는 BOM이 있을 때 제거하는 것을 권장하지 않으므로 인코딩 간에 라운드 트립(round tripping)이 정보를 잃지 않고 이에 의존하는 코드가 계속 작동하도록 합니다.[7][8] IETF는 프로토콜이 항상 UTF-8을 사용하거나 (b) 어떤 인코딩이 사용되고 있는지를 나타내는 다른 방법이 있는 경우 "U+FEFF를 서명으로 사용하는 것을 금지해야 한다"고 권장합니다.[9] 이 권장 사항을 따르지 않는 예로는 텍스트가 UTF-8에 있어야 하고 BOM이 필요한 IETF Syslog 프로토콜이 있습니다.[10]

BOM을 사용하지 않으면 확장 ASCII용으로 설계된 소프트웨어와 텍스트를 역호환할 수 있습니다. 예를 들어 많은 프로그래밍 언어는 ASC가 아닌 것을 허용합니다.문자열 리터럴 단위의 II 바이트이지만 파일 시작 부분에는 없습니다.

UTF-8 인코딩을 감지하려면 BOM이 필요하지 않습니다. UTF-8은 희소 인코딩입니다. 가능한 바이트 조합의 대부분은 유효한 UTF-8 텍스트를 생성하지 않습니다. 다른 인코딩의 이진 데이터와 텍스트는 UTF-8로서 유효하지 않은 바이트 시퀀스를 포함할 가능성이 높기 때문에 이러한 유효하지 않은 시퀀스가 있으면 파일이 UTF-8이 아님을 나타내는 반면, 유효하지 않은 시퀀스가 없으면 텍스트가 UTF-8임을 나타내는 매우 강력한 표시입니다. 사실상 유일한 예외는 ASCII 범위 바이트만 포함하는 텍스트입니다. 이것은 ASCII가 아닌 7비트 인코딩일 수 있지만, 이것은 어떤 최신 데이터에서도 가능성이 없으며 심지어 ASCII와의 차이도 미미합니다(예를 들어 '\'를 '¥'로 변경).

마이크로소프트 컴파일러와[11] 인터프리터, 메모장(Windows 10 Build 1903[12] 이전)과 같은 마이크로소프트 윈도우의 많은 소프트웨어는 휴리스틱을 사용하기보다는 BOM을 필수 마법 번호로 취급합니다. 이러한 도구는 텍스트를 UTF-8로 저장할 때 BOM을 추가하며, BOM이 있거나 파일에 ASCII만 포함되어 있지 않으면 UTF-8을 해석할 수 없습니다. Windows PowerShell(최대 5.1)은 UTF-8 XML 문서를 저장할 때 BOM을 추가합니다. 그러나 PowerShell Core 6는 다음과 같은 기능을 추가했습니다. -Encoding 문서를 BOM 없이 저장할 수 있도록 utf8NoBOM이라고 불리는 일부 cmdlet을 켭니다. Google 문서는 다운로드를 위해 문서를 일반 텍스트 파일로 변환할 때 BOM도 추가합니다.

UTF-16

UTF-16에서는 BOM.U+FEFF)는 파일 또는 문자 스트림의 첫 번째 바이트로 배치되어 파일 또는 스트림의 모든 16비트 코드 단위의 엔디안니스(바이트 순서)를 나타낼 수 있습니다. 잘못된 엔디안니스로 이 스트림을 읽으려는 시도가 있을 경우 바이트가 스왑되어 문자가 전달됩니다. U+FFFE, 유니코드는 텍스트에 절대 나타나지 않아야 하는 "비문자"로 정의합니다.

  • 16비트 단위가 큰 엔디안 바이트 순서("UTF-16BE")로 표시되는 경우 BOM은 (16진수) 바이트 시퀀스입니다. FE FF
  • 16비트 단위가 little-endian order("UTF-16LE")를 사용하는 경우 BOM은 (16진수) 바이트 시퀀스입니다. FF FE

IANA 등록 문자 집합 UTF-16BE 및 UTF-16LE의 경우 이러한 문자 집합의 이름이 이미 바이트 순서를 결정하기 때문에 바이트 순서 표시를 사용해서는 안 됩니다. 이러한 텍스트 스트림의 어느 곳에서나 발생하는 경우 U+FEFF는 "0폭 무브레이크 공간"으로 해석됩니다.

BOM이 없는 경우 ASCII 문자(즉, 0x20-0x7E 범위의 바이트에 인접한 0바이트, CR 및 LF의 경우 0x0A 및 0x0D)를 검색하여 텍스트가 UTF-16인지 및 바이트 순서를 추측할 수 있습니다. 같은 순서로 큰 숫자(즉, 랜덤 찬스보다 훨씬 높음)는 UTF-16을 매우 잘 나타내고 0이 짝수 바이트인지 홀수 바이트인지는 바이트 순서를 나타냅니다. 그러나 이로 인해 위양성과 위음성이 모두 발생할 수 있습니다.

유니코드 표준 적합성 조항 D98(섹션 3.10)은 "UTF-16 인코딩 체계는 BOM으로 시작하거나 시작하지 않을 수 있습니다. 그러나 BOM이 없고, 상위 수준의 프로토콜이 없는 경우에는 UTF-16 인코딩 방식의 바이트 순서가 빅엔디안입니다." 보다 높은 수준의 의정서가 시행되고 있는지 여부는 해석의 여지가 있습니다. 예를 들어, 네이티브 바이트 순서가 little-endian인 컴퓨터의 로컬 파일은 암묵적으로 UTF-16LE로 인코딩된다고 주장할 수 있습니다. 따라서 빅 엔디안의 가정은 널리 무시되고 있습니다. HTML5에서 사용되는 W3C/WHWG 인코딩 표준은 "utf-16" 또는 "utf-16le"로 표시된 콘텐츠를 "배치된 콘텐츠를 처리하기 위해" 작은 엔디안으로 해석하도록 명시합니다.[13] 그러나 바이트 순서 표시가 있는 경우 해당 BOM은 "무엇보다 권위 있는" 것으로 처리됩니다.[14]

UTF-16을 바이트 기반 인코딩으로 해석하는 프로그램은 문자의 난잡함을 표시할 수 있지만, UTF-16 표현의 낮은 바이트는 ASCII 코드와 같으므로 ASCII 문자를 인식할 수 있습니다. 0의 상위 바이트는 아무것도, 공백, 마침표 또는 기타 불변 글리프로 표시될 수 있습니다.

UTF-32

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

Little-endian UTF-32의 BOM은 Little-endian UTF-16 BOM과 동일한 패턴이며 UTF-16 NUL 문자가 뒤따릅니다. 이는 BOM이 두 개의 다른 인코딩에서 동일한 패턴이라는 특이한 예입니다. 인코딩을 식별하기 위해 BOM을 사용하는 프로그래머는 UTF-32 또는 NUL 첫 번째 문자가 있는 UTF-16 중 어느 것이 더 가능한지 결정해야 합니다.

인코딩에 의한 바이트 순서 표시

다음 표는 BOM이 다양한 인코딩에서 바이트 시퀀스로 표현되는 방법과 각 바이트를 레거시 인코딩(Windows-1252 및 C0 컨트롤의 캐럿 표기)으로 해석하는 텍스트 편집기에서 이러한 시퀀스가 어떻게 나타날 수 있는지를 보여줍니다.

인코딩 표현(16진수) 표현(10진수) Windows-1252로 해석되는 바이트
UTF-8[a] EF BBB BF 239 187 191 
UTF-16 (BE) FFF 254 255 þÿ
UTF-16 (LE) FFFE 255 254 ÿþ
UTF-32 (BE) 000 FFF 0 0 254 255 ^@^@þÿ(^@는 null 문자)
UTF-32 (LE) FFF FE 000 255 254 0 0 ÿþ^@^@ (^@는 null 문자)
UTF-7[a] 2B 2F 76[b][16][17] 43 47 118 +/v
UTF-1[a] F7644C 247 100 76 ÷dL
UTF-EBCDIC[a] DD 736673 221 115 102 115 ý sfs
SCSU[a] 0E FEFF[c] 14 254 255 ^N þÿ(^N은 "shift out" 문자)
BOCU-1[a] FEE 28 251 238 40 ûî(
GB18030[a] 84 31 95 33 132 49 149 51 „1•3
  1. ^ a b c d e f g 이러한 인코딩의 코드 단위는 1바이트이므로 "잘못된" 순서로 바이트를 가질 수 없기 때문에 이것은 문자 그대로 "바이트 순서" 표시가 아닙니다. 그럼에도 불구하고 BOM을 사용하여 뒤에 오는 텍스트의 인코딩을 나타낼 수 있습니다.[6][15]
  2. ^ 뒤를 이어 38, 39, 2B, 또는 2F (ASCII) 8, 9, + 또는 /), 다음 캐릭터가 무엇인지에 따라 다릅니다.
  3. ^ SCSU는 U+FEFF의 다른 인코딩을 허용하며, 표시된 양식은 UTR #6에서 권장하는 서명입니다.[18]

참고 항목

참고문헌

  1. ^ a b "FAQ - UTF-8, UTF-16, UTF-32 & BOM". Unicode.org. Retrieved 28 January 2017.
  2. ^ "The Unicode® Standard Version 9.0" (PDF). The Unicode Consortium.
  3. ^ "Zero Width No-Break Space (U+Feff)".
  4. ^ "The Unicode Standard 5.0, Chapter 2:General Structure" (PDF). p. 36. Retrieved 29 March 2009. Table 2-4. The Seven Unicode Encoding Schemes
  5. ^ "The Unicode Standard 5.0, Chapter 2:General Structure" (PDF). p. 36. Retrieved 30 November 2008. Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature
  6. ^ a b "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?". Unicode.org. Retrieved 4 January 2009.
  7. ^ "Re: pre-HTML5 and the BOM from Asmus Freytag on 2012-07-13 (Unicode Mail List Archive)". Unicode.org. Retrieved 14 July 2012.
  8. ^ "Bug ID: JDK-6378911 UTF-8 decoder handling of byte-order mark has changed". Bugs.java.com. Retrieved 14 October 2021.
  9. ^ Yergeau, Francois (November 2003). UTF-8, a transformation format of ISO 10646. IETF. doi:10.17487/RFC3629. RFC 3629. Retrieved 15 May 2014.
  10. ^ Gerhards, Rainer (March 2009). "MSG". The Syslog Protocol. IETF. sec. 6.4. doi:10.17487/RFC5424. RFC 5424.
  11. ^ Alf P. Steinbach (2011). "Unicode part 1: Windows console i/o approaches". Retrieved 24 March 2012. However, since the C++ source code was encoded as UTF-8 without BOM (as is usual in Linux), the Visual C++ compiler erroneously assumed that the source code was encoded as Windows ANSI.
  12. ^ "Windows 10 Notepad is Getting Better UTF-8 Encoding Support". BleepingComputer. Retrieved 7 March 2023.
  13. ^ "UTF-16LE". Encoding Standard. WHATWG.
  14. ^ "Decode". Encoding Standard. WHATWG.
  15. ^ Yergeau, François (8 November 2003). "RFC 3629 - UTF-8, a transformation format of ISO 10646". Ietf Datatracker. Retrieved 28 January 2017.
  16. ^ Honermann, Tom (2 January 2021). "Clarify guidance for use of a BOM as a UTF-8 encoding signature" (PDF). Unicode.
  17. ^ "SDL Documentation".
  18. ^ Markus Scherer. "UTS #6: Compression Scheme for Unicode". Unicode.org. Retrieved 28 January 2017.

외부 링크