BOM이없는 UTF-8과 UTF-8의 차이점은 무엇입니까?

BOM이 없는 UTF-8과 UTF-8의 차이점은 무엇입니까 ? 어떤게 더 좋아?

UTF-8 BOM은 텍스트 스트림 ( )이 시작될 때 일련의 바이트 로 0xEF, 0xBB, 0xBF, 독자는 파일을 UTF-8로 인코딩 된 것으로보다 확실하게 추측 할 수 있습니다.

일반적으로 BOM 은 인코딩 의 엔디안 을 알리는 데 사용 되지만 엔디안은 UTF-8과 관련이 없으므로 BOM이 필요하지 않습니다.

에 따르면 유니 코드 표준 의 UTF-8 파일의 BOM은 사용하지 않는 것이 좋습니다 :

2.6 부호화 체계

... BOM 사용은 UTF-8에 필요하거나 권장되지 않지만 UTF-8 데이터가 BOM을 사용하는 다른 인코딩 형식에서 변환되거나 BOM이 UTF-8 서명으로 사용되는 컨텍스트에서 발생할 수 있습니다. . 자세한 정보는 16.8 절, Specials 의“Byte Order Mark”하위 섹션 을 참조하십시오.

다른 훌륭한 답변은 이미 다음과 같이 대답했습니다.

• UTF-8과 BOM-ed UTF-8의 공식적인 차이는 없습니다
• BOM이있는 UTF-8 문자열은 다음 3 바이트로 시작합니다. EF BB BF
• 존재하는 경우 해당 바이트는 파일 / 스트림에서 문자열을 추출 할 때 무시해야합니다.

그러나 이에 대한 추가 정보로서 UTF-8 용 BOM은 문자열이 UTF-8로 인코딩 된 경우 "냄새를 맡는"좋은 방법 일 수 있습니다. 또는 다른 인코딩에서는 합법적 인 문자열 일 수 있습니다.

예를 들어, 데이터 [EF BB BF 41 42 43]은 다음 중 하나 일 수 있습니다.

• 합법적 인 ISO-8859-1 문자열 " ABC"
• 합법적 인 UTF-8 문자열 "ABC"

따라서 첫 번째 바이트를 보면서 파일 내용의 인코딩을 인식하는 것이 좋을 수는 있지만 위의 예에서 볼 수 있듯이 이에 의존해서는 안됩니다.

신성이 아닌 인코딩을 알아야합니다.

UTF-8로 인코딩 된 파일에 BOM을 넣는 데는 적어도 세 가지 문제점이 있습니다.

1. 텍스트가없는 파일은 항상 BOM을 포함하므로 더 이상 비어 있지 않습니다.
2. BOM이 ASCII가 아니기 때문에 UTF-8의 ASCII 서브 세트 내에있는 텍스트를 보유한 파일은 더 이상 자체가 ASCII가 아니기 때문에 일부 기존 도구가 고장 나서 사용자가 이러한 레거시 도구를 교체 할 수 없습니다.
3. 각 파일의 시작 부분에 BOM이 있으므로 여러 파일을 함께 연결할 수 없습니다.

그리고 다른 사람들이 언급했듯이 BOM이 UTF-8임을 감지하는 것으로 충분하지도 않습니다.

• BOM을 구성하는 정확한 시퀀스로 임의의 바이트 시퀀스가 ​​시작될 수 있기 때문에 충분하지 않습니다.
• 마치 UTF-8 인 것처럼 바이트를 읽을 수 있기 때문에 필요하지 않습니다. 성공하면, 정의상 유효한 UTF-8입니다.

실제로 실제 문제를 야기하지만 많은 사람들이이를 모르는 BOM 사용법의 예는 다음과 같습니다.

BOM에서 스크립트 중단

쉘 스크립트, Perl 스크립트, Python 스크립트, Ruby 스크립트, Node.js 스크립트 또는 인터프리터가 실행해야하는 기타 실행 파일은 모두 다음 중 하나와 같은 shebang 행으로 시작 합니다.

#!/bin/sh
#!/usr/bin/python
#!/usr/local/bin/perl
#!/usr/bin/env node

이러한 스크립트를 호출 할 때 어떤 인터프리터를 실행해야하는지 시스템에 알려줍니다. 스크립트가 UTF-8로 인코딩 된 경우 처음에 BOM을 포함하도록 유혹 될 수 있습니다. 그러나 실제로 "#!" 문자는 단순한 문자가 아닙니다. 실제로 두 개의 ASCII 문자로 구성 되는 마법의 숫자 입니다. 해당 문자 앞에 무언가 (BOM과 같은)를 넣으면 파일에 다른 마법 번호가있는 것처럼 보이며 문제가 발생할 수 있습니다.

Wikipedia, article : Shebang, section : Magic number 참조 :

shebang 문자는 현재 Unix 계열 시스템의 스크립트 및 기타 텍스트 파일에 일반적으로 사용되는 UTF-8을 포함하여 확장 ASCII 인코딩에서 동일한 2 바이트로 표시됩니다. 그러나 UTF-8 파일은 선택적 바이트 순서 표시 (BOM)로 시작할 수 있습니다. "exec"함수가 바이트 0x23 및 0x21을 구체적으로 감지하는 경우 shebang 전에 BOM (0xEF 0xBB 0xBF)이 있으면 스크립트 인터프리터가 실행되지 않습니다.일부 당국은 POSIX (Unix-like) 스크립트에서 바이트 순서 마크를 사용하지 말 것을 권장합니다. [14] 이러한 이유로 그리고 더 넓은 상호 운용성과 철학적 관심사를 위해. 또한 인코딩에는 엔디안 문제가 없으므로 UTF-8에서는 바이트 순서 표시가 필요하지 않습니다. 인코딩은 UTF-8로만 식별합니다. [강조 추가]

JSON에서 BOM이 잘못되었습니다

RFC 7159, 섹션 8.1 참조 :

구현시 JSON 텍스트의 시작 부분에 바이트 순서 표시를 추가해서는 안됩니다.

BOM은 JSON에서 중복됩니다

JSON에서는 불법 일뿐만 아니라 JSON 스트림에서 사용되는 문자 인코딩과 엔디안을 명확하게 결정하는보다 신뢰할 수있는 방법이 있으므로 문자 인코딩을 결정할 필요 도 없습니다 (자세한 내용은 이 답변 참조).

BOM이 JSON 파서를 깨다

JSON 에서는 불법 이며 필요하지 않을 뿐만 아니라 RFC 4627에 제시된 방법을 사용하여 인코딩을 결정하는 모든 소프트웨어 를 실제로 중단합니다 .

JSON의 인코딩 및 엔디안을 결정하고 NUL 바이트의 처음 4 바이트를 검사합니다.

00 00 00 xx - UTF-32BE
00 xx 00 xx - UTF-16BE
xx 00 00 00 - UTF-32LE
xx 00 xx 00 - UTF-16LE
xx xx xx xx - UTF-8

이제 파일이 BOM으로 시작하면 다음과 같습니다.

00 00 FE FF - UTF-32BE
FE FF 00 xx - UTF-16BE
FF FE 00 00 - UTF-32LE
FF FE xx 00 - UTF-16LE
EF BB BF xx - UTF-8

참고 :

1. UTF-32BE는 3 개의 NUL로 시작하지 않으므로 인식되지 않습니다.
2. UTF-32LE 첫 번째 바이트 다음에 세 개의 NUL이 없으므로 인식되지 않습니다.
3. UTF-16BE는 처음 4 바이트에 하나의 NUL 만 있으므로 인식되지 않습니다.
4. UTF-16LE는 처음 4 바이트에 하나의 NUL 만 있으므로 인식되지 않습니다.

구현에 따라 모든 것들이 UTF-8로 잘못 해석 된 다음 잘못된 UTF-8로 잘못 해석되거나 거부되거나 전혀 인식되지 않을 수 있습니다.

또한 구현에서 권장하는대로 유효한 JSON을 테스트하면 RFC에 따라 ASCII 문자 <128로 시작하지 않기 때문에 실제로 UTF-8로 인코딩 된 입력조차 거부합니다.

다른 데이터 형식

JSON의 BOM은 필요하지 않으며 불법이며 RFC에 따라 올바르게 작동하는 소프트웨어를 중단합니다. 그것을 사용하지 않는 것은 당연한 일이지만, BOM, 주석, 다른 인용 규칙 또는 다른 데이터 유형을 사용하여 JSON을 깨뜨릴 것을 주장하는 사람들이 항상 있습니다. 물론 누구나 BOM이나 기타 필요한 것을 자유롭게 사용할 수 있습니다. JSON이라고 부르지 마십시오.

JSON 이외의 다른 데이터 형식의 경우 실제로 어떻게 보이는지 살펴보십시오. 유일한 인코딩이 UTF- *이고 첫 번째 문자가 128보다 낮은 ASCII 문자 여야하는 경우 데이터의 인코딩 및 엔디안을 결정하는 데 필요한 모든 정보가 이미 있습니다. 선택적 기능으로도 BOM을 추가하면 더 복잡하고 오류가 발생하기 쉽습니다.

BOM의 다른 용도

JSON 또는 스크립트 이외의 용도에 대해서는 이미 여기에 좋은 답변이 있다고 생각합니다. 실제 문제를 일으키는 BOM 문자의 예이므로 스크립팅 및 직렬화에 대한 자세한 정보를 구체적으로 추가하고 싶었습니다.

BOM이없는 UTF-8과 UTF-8의 차이점은 무엇입니까?

짧은 대답 : UTF-8에서 BOM은 EF BB BF파일 시작 부분에 바이트 로 인코딩됩니다 .

긴 대답 :

원래 유니 코드 는 UTF-16 / UCS-2로 인코딩 될 것으로 예상되었습니다 . BOM은이 인코딩 양식을 위해 설계되었습니다. 2 바이트 코드 단위가있는 경우 해당 2 바이트의 순서를 표시해야하며이를 수행하는 일반적인 규칙은 데이터 시작 부분에 문자 U + FEFF를 "바이트 순서 표시"로 포함시키는 것입니다. 문자 U + FFFE는 영구적으로 할당이 해제되어 존재하므로 잘못된 바이트 순서를 감지 할 수 있습니다.

UTF-8은 플랫폼 엔디안과 상관없이 바이트 순서가 동일하므로 바이트 순서 표시가 필요하지 않습니다. 그러나 EF BB FFUTF-16에서 UTF-8로 변환 된 데이터에서 ( 바이트 시퀀스로 ) 또는 데이터가 UTF-8임을 나타내는 "서명"으로 발생할 수 있습니다 .

어떤게 더 좋아?

없이. Martin Cote가 대답했듯이 유니 코드 표준은 권장하지 않습니다. 비 BOM 인식 소프트웨어에 문제가 발생합니다.

파일이 UTF-8인지 여부를 감지하는 더 좋은 방법은 유효성 검사를 수행하는 것입니다. UTF-8에는 유효한 바이트 시퀀스에 대한 엄격한 규칙이 있으므로 오 탐지 확률은 무시할 수 있습니다. 바이트 시퀀스가 ​​UTF-8처럼 보이면 아마도 그렇습니다.

BOM이있는 UTF-8이 더 잘 식별됩니다. 나는이 결론에 도달하기 어려웠다. 결과 중 하나가 유니 코드 문자를 포함 하여 CSV 파일 인 프로젝트를 진행 중입니다 .

CSV 파일을 BOM없이 저장하면 Excel은 파일이 ANSI라고 생각하고 횡설수설합니다. 전면에 "EF BB BF"를 추가하면 (예 : UTF-8이있는 메모장을 사용하여 다시 저장하거나 BOM이있는 UTF-8이있는 메모장 ++을 사용하여 다시 저장) Excel에서 잘 열립니다.

RFC 3629는 2003 년 11 월 http://tools.ietf.org/html/rfc3629 에서 "UTF-8, ISO 10646의 변환 형식"인 BOM 문자를 유니 코드 텍스트 파일 앞에 추가하는 것이 좋습니다 (최종 정보는 다음 위치에 있음). http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html )

BOM은 어딘가 어딘가에서 호황을 느끼는 경향이 있습니다. 또한 호황을 누리면 (예 : 브라우저, 편집자 등이 인식하지 못하는 경우) 문서 시작시 이상한 문자 (예 : HTML 파일, JSON 응답, RSS 등)로 표시됩니다. 트위터에서 오바마와 대화하는 동안 경험 한 최근의 인코딩 문제 와 같은 종류의 당혹감을 유발합니다. .

디버깅하기 어려운 장소 나 테스트가 무시 될 때 매우 성가시다. 따라서 사용하지 않으면 피하는 것이 가장 좋습니다.

질문 : BOM이없는 UTF-8과 UTF-8의 차이점은 무엇입니까? 어떤게 더 좋아?

다음은 바이트 순서 표시 (BOM) 에 관한 Wikipedia 기사에서 발췌 한 내용입니다. .이 질문에 대한 확실한 대답을 제공한다고 생각합니다.

BOM 및 UTF-8의 의미에서 :

유니 코드 표준은 BOM 을 UTF-8로 허용 하지만 사용을 요구하거나 권장하지는 않습니다. 바이트 순서는 UTF-8에서 의미가 없으므로 UTF-8에서의 유일한 사용은 처음에 텍스트 스트림이 UTF-8로 인코딩되었음을 신호하는 것입니다.

BOM을 사용 하지 않는 인수 :

BOM을 사용하지 않는 주요 동기는 유니 코드를 인식하지 않는 소프트웨어와의 하위 호환성입니다. BOM을 사용하지 않는 또 다른 동기는 UTF-8을 "기본"인코딩으로 권장하는 것입니다.

인수 에 대한 BOM이 사용 :

BOM 사용에 대한 논점은 파일이 없으면 파일이 어떤 문자 인코딩을 사용하는지 판별하기 위해 휴리스틱 분석이 필요하다는 것입니다. 역사적으로 다양한 8 비트 인코딩을 구별하기위한 이러한 분석은 복잡하고 오류가 발생하기 쉽고 때로는 느립니다. Mozilla Universal Charset Detector 및 국제 구성 요소 (Unicode)와 같은 작업을 쉽게하기 위해 여러 라이브러리를 사용할 수 있습니다.

프로그래머는 실수로 UTF-8의 탐지가 똑같이 어렵다고 가정합니다 (대부분의 바이트 시퀀스가 ​​유효하지 않은 UTF-8이 아니기 때문에 이러한 라이브러리는 가능한 모든 바이트 시퀀스를 허용하도록 인코딩하려고합니다). 따라서 모든 유니 코드 인식 프로그램이 이러한 분석을 수행하는 대신 BOM에 의존하지는 않습니다.

특히 Microsoft 컴파일러 및 인터프리터 및 메모장과 같은 Microsoft Windows의 많은 소프트웨어는 ASCII 문자 만 있거나 BOM으로 시작하지 않으면 UTF-8 텍스트를 올바르게 읽지 않으며 저장시 시작에 BOM을 추가합니다. UTF-8로 텍스트. Google 문서는 Microsoft Word 문서가 일반 텍스트 파일로 다운로드 될 때 BOM을 추가합니다.

있는, 더 나은 함께 나 없이 BOM을 :

IETF는 프로토콜 중 하나 (A)는 항상 사용하는 경우, UTF-8, 또는 (b)는 부호화를 사용하고 있는지 표시하는 다른 방법으로, 다음을 갖는 것이 권장 "서명으로 U + FEFF 사용을 금지해야한다 있습니다."

나의 결론 :

BOM 사용 만 사용소프트웨어 응용 프로그램과의 호환성이 반드시 필요한 경우 .

또한 참조 된 Wikipedia 기사에서 많은 Microsoft 응용 프로그램이 BOM을 사용하여 UTF-8을 올바르게 감지한다고 설명하지만 모든 Microsoft 응용 프로그램 에는 해당되지 않습니다 . 예를 들어,이 가리키는 아웃으로 @barlop UTF-8 프롬프트 윈도우 명령을 사용하는 경우, ^† , 같은 명령 type및 moreBOM을가 존재하는 것으로 기대하지 않습니다. BOM 이 있으면 다른 응용 프로그램에서와 같이 문제가 될 수 있습니다.

† chcp명령 이벤트 (UTF-8에 대한 지원을 하지 않고 코드 페이지를 통해 BOM) 65001 .

이 질문에는 이미 백만 및 하나의 답변이 있으며 많은 답변이 훌륭하지만 BOM을 사용해야 할 때와 사용하지 않아야 할 시점을 명확히하고 싶었습니다.

언급 한 바와 같이, 문자열이 UTF-8인지 여부를 판별하는 데 UTF BOM (Byte Order Mark)을 사용하는 것은 교육적인 추측입니다. 사용 가능한 적절한 메타 데이터가있는 경우 (예 :charset="utf-8" :) 이미 사용중인 것으로 알고 있지만 그렇지 않은 경우 테스트하고 가정해야합니다. 여기에는 문자열이 나오는 파일이 16 진 바이트 코드 인 EF BB BF로 시작하는지 확인하는 작업이 포함됩니다.

UTF-8 BOM에 해당하는 바이트 코드가 발견되면 UTF-8이라고 가정 할 가능성이 높으므로 그 위치에서 벗어날 수 있습니다. 그러나이 추측을 강요 할 때, 읽는 동안 추가 오류 검사는 여전히 문제가 발생하는 경우 좋은 아이디어입니다. 입력이 확실하지 않아야 하는 경우 BOM이 UTF-8 (예 : latin-1 또는 ANSI)이 아니라고 가정 해야합니다. 이 소스를 기반으로 UTF-8 . 그러나 BOM이없는 경우 인코딩에 대해 유효성 검증을 수행하여 UTF-8인지 여부를 간단히 판별 할 수 있습니다.

BOM이 권장되지 않는 이유는 무엇입니까?

1. 유니 코드를 인식하지 않거나 호환되지 않는 소프트웨어는 라틴 -1 또는 ANSI라고 가정하고 문자열에서 BOM을 제거하지 않으므로 분명히 문제가 발생할 수 있습니다.
2. 실제로 필요하지는 않습니다 (콘텐츠가 호환되는지 확인하고 호환되는 인코딩을 찾을 수없는 경우 항상 UTF-8을 대체로 사용하십시오)

때 해야 당신은 BOM으로 인코딩?

문자셋 태그 또는 파일 시스템 메타를 통해 다른 방식으로 메타 데이터를 기록 할 수없고 BOM과 같이 사용되는 프로그램을 BOM으로 인코딩해야합니다. 이것은 BOM이없는 것이 일반적으로 레거시 코드 페이지를 사용하는 것으로 가정되는 Windows에서 특히 그렇습니다. BOM은 Office와 같은 프로그램에이 파일의 텍스트가 유니 코드임을 알려줍니다. 사용 된 인코딩은 다음과 같습니다.

그것이 실제로 문제가되는 유일한 파일은 CSV입니다. 프로그램에 따라 BOM이 있거나 없어야합니다. 예를 들어, Windows에서 Excel 2007+를 사용하는 경우 BOM을 부드럽게 열고 데이터 가져 오기에 의존하지 않으려면 BOM으로 인코딩해야합니다.

일부 파일의 경우 Windows에서도 BOM 이 없어야합니다 . 예는 다음과 같다 SQL*plus또는 VBScript파일입니다. 이러한 파일에 BOM이 포함 된 경우 실행하려고하면 오류가 발생합니다.

BOM이있는 UTF-8은 파일에 실제로 비 ASCII 문자가 포함 된 경우에만 도움이됩니다. 포함 된 파일이 없으면 파일을 일반 ASCII로 해석 한 이전 응용 프로그램을 손상시킬 수 있습니다. 이러한 응용 프로그램은 ASCII가 아닌 문자를 발견하면 확실히 실패하므로 BOM은 파일이 더 이상 일반 ASCII로 해석 될 수 없을 때만 추가되어야한다고 생각합니다.

BOM이 전혀없는 것을 선호하고 싶습니다. 오래된 쓰레기가 없으면 쓰레기를 넣으십시오. 이전 응용 프로그램을 대체하는 것은 불가능합니다.

UTF-8의 BOM을 기대하지 마십시오.

BOM의 Wikipedia 페이지 하단에 인용되어 있습니다 : http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2

"BUT 사용은 UTF-8에 필요하거나 권장되지 않지만 UTF-8 데이터가 BOM을 사용하는 다른 인코딩 형식에서 변환되거나 BOM이 UTF-8 서명으로 사용되는 컨텍스트에서 발생할 수 있습니다."

BOM이없는 UTF-8에는 BOM이 없으므로 파일 소비자가 파일이 UTF-8로 인코딩되었는지 여부를 알아야하거나 알면 도움이되는 경우를 제외하고 BOM이있는 UTF-8보다 우수하지 않습니다 또는 아닙니다.

BOM은 일반적으로 인코딩의 엔디안을 결정하는 데 유용하며 대부분의 사용 사례에는 필요하지 않습니다.

또한 BOM은 모르거나 신경 쓰지 않는 소비자에게는 불필요한 소음 / 통증이 될 수 있으며 사용자 혼동을 초래할 수 있습니다.

나는 이것을 다른 관점에서 본다. 생각 UTF-8 BOM과는 더 는 파일에 대한 자세한 정보를 제공한다. 문제가 발생하는 경우에만 BOM없이 UTF-8을 사용합니다.

내 페이지에서 오랫동안 여러 언어 ( 키릴 문자 )를 사용하고 있으며 BOM없이 파일을 저장하고 편집기를 사용하여 편집하기 위해 파일을 다시 열면 ( cherouvim 도 언급했듯이) 일부 문자가 손상되었습니다.

UTF-8 인코딩으로 새로 작성된 파일을 저장하려고하면 Windows의 클래식 메모장 이 BOM과 함께 파일을 자동으로 저장합니다.

BOM 없이 서버 측 스크립팅 파일 (.asp, .ini, .aspx)을 BOM 및 .html 파일로 개인적으로 저장합니다 .

UTF-8로 인코딩 된 정보를 표시하려는 경우 문제가 발생하지 않을 수 있습니다. 예를 들어 HTML 문서를 UTF-8로 선언하면 문서 본문에 포함 된 모든 것이 브라우저에 표시됩니다.

그러나 우리가 텍스트를 가지고있을 때는 그렇지 않습니다. Windows 나 Linux에 CSV 및 XML 파일 .

예를 들어, 상상할 수있는 가장 쉬운 것 중 하나 인 Windows 또는 Linux의 텍스트 파일은 UTF-8이 아닙니다.

XML로 저장하고 UTF-8로 선언하십시오.

<?xml version="1.0" encoding="UTF-8"?>

UTF-8로 선언 된 경우에도 올바르게 표시되지 않습니다 (읽을 수 없음).

프랑스어 문자를 포함하는 일련의 데이터가 있었는데 신디케이션을 위해 XML로 저장해야했습니다. 맨 처음부터 UTF-8 파일을 작성하지 않고 (IDE 및 "새 파일 작성"에서 옵션 변경) 파일 시작 부분에 BOM을 추가하지 않고

$file="\xEF\xBB\xBF".$string;

프랑스어 문자를 XML 파일로 저장할 수 없습니다.

한 가지 실질적인 차이점은 Mac OS X 용 셸 스크립트를 작성하고 일반 UTF-8로 저장하면 다음과 같은 응답을 얻을 수 있다는 것입니다.

#!/bin/bash: No such file or directory

사용할 쉘을 지정하는 shebang 행에 대한 응답으로 다음을 수행하십시오.

#!/bin/bash

UTF-8로 저장하면 BOM ( BBEdit 등 )이 모두 적합 하지 않습니다 .

위에서 언급 한 것처럼 BOM이있는 UTF-8은 비 BOM 인식 (또는 호환) 소프트웨어에 문제를 일으킬 수 있습니다. 클라이언트가 WYSIWYG 프로그램을 필요로했기 때문에 Mozilla 기반 KompoZer 로 UTF-8 + BOM으로 인코딩 된 HTML 파일을 편집했습니다 .

저장할 때 레이아웃이 항상 손상됩니다. 이 문제를 해결하는 데 시간이 걸렸습니다. 이 파일들은 Firefox에서 잘 작동했지만 Internet Explorer에서 CSS를 무시하고 레이아웃을 다시 파괴했습니다. 몇 시간 동안 연결된 CSS 파일을 찾은 후 Internet Explorer가 BOMfed HTML 파일을 좋아하지 않는다는 것을 발견했습니다. 다시는

또한 방금 Wikipedia에서 이것을 발견했습니다.

shebang 문자는 현재 Unix 계열 시스템의 스크립트 및 기타 텍스트 파일에 일반적으로 사용되는 UTF-8을 포함하여 확장 ASCII 인코딩에서 동일한 2 바이트로 표시됩니다. 그러나 UTF-8 파일은 선택적 바이트 순서 표시 (BOM)로 시작할 수 있습니다. "exec"함수가 바이트 0x23 0x21을 구체적으로 감지하면 shebang 이전에 BOM (0xEF 0xBB 0xBF)이 있으면 스크립트 인터프리터가 실행되지 않습니다. 일부 당국은 POSIX (Unix-like) 스크립트에서 바이트 순서 마크를 사용하지 말 것을 권장합니다. [15] 이러한 이유로 그리고 더 넓은 상호 운용성과 철학적 관심사를 위해

BOM ( Unicode Byte Order Mark) FAQ 는 다음과 같은 간결한 답변을 제공합니다.

Q : BOM을 어떻게 처리해야합니까?

A : 준수해야 할 지침은 다음과 같습니다.

1. 특정 프로토콜 (예 : .txt 파일에 대한 Microsoft 규칙)은 파일과 같은 특정 유니 코드 데이터 스트림에서 BOM을 사용해야 할 수 있습니다. 이러한 프로토콜을 준수해야하는 경우 BOM을 사용하십시오.

2. 태그가없는 텍스트의 경우 일부 프로토콜에서 선택적 BOM을 허용합니다. 이 경우

   • 텍스트 데이터 스트림이 일반 텍스트이지만 인코딩이 알려지지 않은 경우 BOM을 서명으로 사용할 수 있습니다. BOM이 없으면 인코딩이 될 수 있습니다.

   • 텍스트 데이터 스트림이 일반 유니 코드 텍스트로 알려져 있지만 (엔디안은 아님) BOM을 서명으로 사용할 수 있습니다. BOM이없는 경우 텍스트는 빅 엔디안으로 해석되어야합니다.

3. 일부 바이트 지향 프로토콜은 파일 시작 부분에 ASCII 문자가 필요합니다. UTF-8을 이러한 프로토콜과 함께 사용하는 경우 BOM을 인코딩 양식 서명으로 사용하지 않아야합니다.

4. 정확한 유형의 데이터 스트림이 알려진 경우 (예 : 유니 코드 빅 엔디안 또는 유니 코드 리틀 엔디안) BOM을 사용해서는 안됩니다. 특히, 데이터 스트림이 UTF-16BE, UTF-16LE, UTF-32BE 또는 UTF-32LE로 선언 될 때마다 BOM을 사용해서는 안됩니다.

에서 http://en.wikipedia.org/wiki/Byte-order_mark :

바이트 순서 표시 (BOM)는 텍스트 파일 또는 스트림의 엔디안 (바이트 순서)을 알리는 데 사용되는 유니 코드 문자입니다. 코드 포인트는 U + FEFF입니다. BOM 사용은 선택 사항이며 사용되는 경우 텍스트 스트림의 시작 부분에 나타납니다. BOM 순서는 바이트 순서 표시 자로 사용되는 것 외에도 텍스트가 인코딩 된 여러 유니 코드 표현 중 하나를 나타낼 수도 있습니다.

파일에서 항상 BOM을 사용하면 UTF-8 및 BOM을 지원하는 편집기에서 항상 BOM이 올바르게 열립니다.

BOM이없는 나의 실제 문제는 다음과 같습니다. 다음을 포함하는 파일이 있다고 가정하십시오.

abc

BOM이 없으면 대부분의 편집기에서 ANSI로 열립니다. 따라서이 파일의 다른 사용자가 파일을 열고 일부 고유 문자를 추가합니다 (예 :

abg-αβγ

죄송합니다. 이제 파일은 여전히 ​​ANSI로되어 있으며 "αβγ"가 6 바이트를 차지하지 않는 것은 3입니다. UTF-8이 아니므로 나중에 개발 체인에서 다른 문제가 발생합니다.

Visual Studio, Sourcetree 및 Bitbucket pull 요청에 대한 나의 경험은 다음과 같습니다 .

따라서 서명이있는 BOM은 풀 요청을 검토 할 때 각 파일에 빨간색 점 문자가 포함되어 있습니다 (매우 성 가실 수 있습니다).

마우스를 가져 가면 "ufeff"와 같은 문자가 표시되지만 Sourcetree에는 이러한 유형의 바이트 마크가 표시되지 않으므로 풀 요청으로 끝날 가능성이 높습니다. 2017은 이제 새 파일을 인코딩하므로 Bitbucket 은이를 무시하거나 다른 방법으로 표시해야합니다. 자세한 내용은 여기에 있습니다.

빨간 점 마커 BitBucket diff보기

HTML 파일에서 UTF-8을 사용하고 동일한 페이지에서 Serbian Cyrillic, Serbian Latin, German, Hungarian 또는 일부 이국적인 언어를 사용하는 경우 BOM이있는 UTF가 더 좋습니다.

이것이 저의 의견입니다 (30 년의 컴퓨팅 및 IT 산업).