뒤에 있는 텍스트의 인코딩을 가리키기 위해 사용할 수 있습니다. ↑ 이것은 BOM과 NUL로 시작하는 UTF - 16LE 파일과 동일한 바이트 패턴입니다. ↑ UTF - 7에서, base64로 된 인코딩 앞에 오는 BOM의 4번째 바이트는 이진수로 0011xx입니다. 마지막 두 비트, xx는 명확히 말하자면 BOM의 일부가 아닌데, BOM 다음에 처음으로 인코딩된 문자 중 첫 두 비트를 포함합니다. 위 표에서는 가능한 네 개의 바이트 조합 뿐만 아니라 빈 문자열을 위해 사용된 다섯째 바이트도 보여주고 있습니다. ↑ 인코딩된 다음 문자가 존재하지 않는다면, 38이 4번째 바이트로 사용되고 다음 바이트는 2D가 됩니다. ↑ SCSU는 UFEFF의 다른 인코딩을 허용하며, 위 형식은 UTR # 6에서 권장되는 시그니처입니다. 원본 주소 " " 분류 : 유니코드숨은 분류 : 정리가 필요한 글 / 2019년 6월정리가 필요한 모든 글전체에 정리가 필요한 글 둘러보기 메뉴 개인 도구 로그인하지 않음토론기여계정 만들기로그인 이름공간 문서토론 변수 보기 읽기편집역사 보기 더
##딩 별 바이트 순서 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 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 각주 [ 편집 ] ↑ 가 나 다 라 마 바 사 이것은 리터럴한 " 바이트 순서 " 표시가 아닌데, 바이트가 해당 인코딩의 코드 단위가 아니고 해석될 바이트 순서도 없기 때문입니다. 하지만, 뒤에 있는 텍스트의 인코딩을 가리키기 위해 사용할 수 있습니다. ↑ 이것은 BOM과 NUL
##지 않음토론기여계정 만들기로그인 이름공간 문서토론 변수 보기 읽기편집역사 보기 더 보기 검색 둘러보기 대문사용자 모임요즘 화제최근 문서 보기임의 문서로도움말기부 도구 여기를 가리키는 문서가리키는 글의 최근 올리기특수 문서 목록고유 링크문서 정보위키데이터 항목이 문서 인용하기 인쇄 / 내보내기 책 만들기PDF로 다운로드인쇄용 판 다른 언어 日 本 語 中 文 링크 편집 이 문서는 2019년 6월 6일 ( 목 ) ( 목 ) 13 : 42에 마지막으로 편집되었습니다. 모든 문서는 크리에이티브 커먼즈 저작자표시 - 동일조건변경허락 3. 0에 따라 사용할 수 있으며, 추가적인 조건이 적용될 수 있습니다. 자세한 내용은 이용 약관을 참고하십시오. 미국 및 다른 국가에 등록되어 있는 Wikimedia Foundation, Inc. 소유의 등록 상표입니다. 개인정보 정책 위키백과 소개 면책 조항 개발자 쿠키 정책 모바일 보기
] 아래 표는 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
##에서, 이 사용법은 " 단어 결합자 " 문자인 U2060으로 인해 사용 폐기되었습니다. 그로 인해 UFEFF는 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 ) 인코딩이 사용되고 있는지를
바이트 순서 표식 - 위키백과, 우리 모두의 백과사전 바이트 순서 표식 위키백과, 우리 모두의 백과사전. 둘러보기로 가기 검색하러 가기 이 문서는 위키백과의 편집 지침에 맞춰 다듬어야 합니다. 더 좋은 문서가 되도록 문서 편집을 도와주세요. 내용에 대한 의견이 있으시다면 토론 문서에서 나누어 주세요. ( 2019년 6월 6일 ) 유니코드 부호화 형식 UTF - 7 UTF - 8 CESU - 8 UTF - 16 UTF - 32 UTF - EBCDIC SCSU 퓨니코드 GB18030 UCS 양방향 텍스트 BOM 한중일 통합 한자 유니코드 범위 목록 유니코드 정규화 유니코드와 HTML 유니코드와 전자 우편 유니코드 글꼴 v. d. e. h 바이트 순서 표시 ( Byte Order Mark, BOM ) 는 유니코드 문자, UFEFF 바이트 순서 표식 ( BOM ) 으로, 텍스트 스트림 시작 부분에 있는 매직 넘버처럼 나온 것은 텍스트를 소비하는 프로그램에 여러 가지 내용을 알려줍니다 : 텍스트 스트림이 저장되는 바이트 순서 또는 엔디언 텍스트 스트림이 유니코드라는 사실 ( 높은 수준의 신뢰를 위함 ) 여러 유니코드 인코딩 중 텍스트 스트림이 인코딩된 것 BOM의 사용은 옵션이며, 사용
##납니다. BOM 문자의 바이트 유니코드 인코딩 별로 다르며, 다른 인코딩으로 저장된 텍스트 스트림에서는 시작 부분에 해당 나타나지 않습니다. 그러므로, 텍스트 시작 부분에 인코딩된 BOM을 두는 것은 텍스트가 유니코드 임을 나태내고, 엔디언이 없는 UTF - 8의 경우 조차도, 사용되는 인코딩 스킴을 식별하는데 도움을 줄 수 있습니다. BOM 문자의 이러한 일반적인 용도를 유니코드 시그니처라고 부르며, 유니코드 시그니처는 UTF - 7과 같이 유니코드 표준의 일부가 아닌 유니코드 기반의 인코딩 스킴으로도 확장됩니다. 목차 1 사용법 1. 1 UTF - 8 1. 2 UTF - 16 1. 3 UTF - 32 2 인코딩 별 바이트 순서 표시 3 각주 사용법 [ 편집 ] BOM 문자가 데이터 스트림 중간에 나오면, " zero - width non - breaking space " ( word - glyphs 사이에서 line - breaking을 금지 ) 으로 해석되어야 한다고 유니코드가 알려주는 것입니다. 유니코드 3. 2에서, 이 사용법은 " 단어 결합자 " 문자인 U2060으로 인해 사용 폐기되었습니다. 그로 인해 UFEFF는
##와 인터프리터 그리고 노트패드와 같은 마이크로소프트 윈도우의 많은 소프트웨어들은 BOM을 휴리스틱을 이용하지 않고 필수적인 매직 넘버처럼 처리합니다. 이 도구들은 UTF - 8로 텍스트를 저장할 때 BOM을 추가하며, BOM이 나타나지 않거나 파일에 ASCII만 포함되어 있지 않다면 UTF - 8을 해석할 수 없습니다. 또한 구글 독스는 문서를 다운로드를 위한 플레인 텍스트로 변환할 때 BOM을 추가합니다. UTF - 16 [ 편집 ] UTF - 16에서, BOM ( UFEFF ) 은 파일의 첫번째 문자 혹은 캐릭터 스트림으로 배치되어 파일이나 스트림의 모든 16비트 코드 단위의 엔디언 ( 바이트 순서 ) 을 나타냅니다. 만약 잘못된 엔디언으로 해당 스트림을 읽으려고 하면, 바이트가 스와핑되어서, 텍스트 내에서 결코 나타나서는 안되는 " 비문자 " 로 유니코드에 의해 정의된 UFFFE를 전달합니다. 16비트 단위가 빅엔디언 바이트 순서로 나타나면, 해당 BOM 문자는 0xFE 뒤에 0xFF가 오는 순서의 나옵니다. 이 텍스트가 ISO - 8859 - 1인 것으로 간주하는 텍스트 디스플레이에서 ISO - 8859 - 1 문자인 으로
##는 프로토콜이 ( a ) 항상 UTF - 8을 사용하거나 ( b ) 인코딩이 사용되고 있는지를 나타낼 다른 방법을 가진 경우, " UFEFF를 시그니처로 사용하는 것을 금지해야 한다 " 고 합니다. BOM을 사용하지 않는 경우 유니코드를 인지하지 못하는 일부 소프트웨어와 텍스트가 하위 호환될 수 있습니다. 예로는 문자열 리터럴 내에서 ASCII가 아닌 바이트를 허용하지만 파일의 시작 부분에서는 그렇지 않은 프로그래밍 언어가 있습니다. 만약 인코딩에 대한 BOM이나 다른 지시가 없는 경우, UTF - 8에서 유효하지 않은 많은 수의 바이트 인해 UTF - 8이 사용 중인지를 휴리스틱 분석으로 신뢰도 있게 알 수 있습니다 ( 텍스트가 UTF - 8이 아닌 것으로 밝혀진 경우 어떤 레거시 인코딩이 어렵고 불확실할 수 있는지를 결정합니다. Mozilla Universal Charset Detector와 International Components for Unicode와 같이, 몇 가지 무료 라이브러리를 사용해 쉽게 작업할 수 있습니다 ). 마이크로소프트의 컴파일러와 인터프리터 그리고 노트패드와 같은 마이크로소프트 윈도우의 많은 소프트웨어들은 BOM을 휴리스틱을 이용하지
나옵니다. 이 텍스트가 ISO - 8859 - 1인 것으로 간주하는 텍스트 디스플레이에서 ISO - 8859 - 1 문자인 으로 나옵니다. 16비트 단위가 리틀엔디언 순서를 사용한다면, 0xFF 다음에 0xFE가 오는 순서의 나옵니다. 이 텍스트가 ISO - 8859 - 1인 것으로 간주하는 텍스트 디스플레이에서 ISO - 8859 - 1 문자인 으로 나옵니다. UTF - 8을 예상하는 프로그램은 UTF - 8 인코딩 오류를 다루는 방법에 따라, 오류 내용을 표시합니다. 모든 경우 그 프로그램들은 아마도 파일의 나머지 부분을 쓸모없는 데이터로 표시합니다 ( ASCII 만 포함하는 UTF - 16 텍스트는 잘 읽을 수 있을 겁니다 ). IANA에 등록된 문자인 UTF - 16BE와 UTF - 16LE의 경우, 이런 문자 집합의 이름이 이미 바이트 순서를 결정하기 때문에 바이트 순서 표시를 사용하면 안됩니다. 텍스트 스트림 내 어디서든 발견되면 UFEFF는 " zero width no - break space " 로 해석됩니다. 유니코드 표준의 D98항 기준은 " UTF - 16 인코딩 스킴은 BOM으로 시작할 수도 그렇지 않을 수도 있습니다. 하지만, BOM이 없다면, 그리고
바이트 순서 표시(Byte Order Mark, BOM)는 유니코드 문자 UFEFF byte order mark로, 매직 넘버로서 문서의 가장 앞에 추가하여 텍스트를 읽는 프로그램에 여러 정보를 전달할 수 있다. 16비트 혹은 32비트 인코딩의 경우, 문서의 바이트 순서 또는 엔디언 문서의 인코딩이 거의 확실히 유니코드임 문서에 사용한 유니코드 문자 인코딩 방식BOM을 반드시 사용할 필요는 없으며, 사용할 경우 문서의 가장 앞에 등장해야 한다. 유니코드는 8비트, 16비트 혹은 32비트 정수 단위로 인코딩할 수 있다. 16비트 및 32비트 표현의 경우, 알 수 없는 출처로부터 텍스트를 읽는 컴퓨터는 데이터를 어떤 바이트 순서로 인코딩했는지 알아야 한다. BOM은 문서의 나머지 부분과 같은 방식으로 인코딩되며 바이트 순서가 바뀔 경우 비문자인 유니코드 코드 포인트가 되므로, 이 텍스트를 읽는 프로세스는 문서 외적인 정보 없이도 처음 몇 바이트를 검사함으로써 엔디언을 확인할 수 있다. 이후 수신자는 필요할 경우 바이트 순서를 자신의 엔디안에 맞게 바꾸며, 이 이후의 처리에는 더 이상 BOM이 필요하지 않다. BOM의 바이트열은 유니코드 인코딩마다 다르며, 이들이 다른 인코딩으로 저장된 문서의 가장 앞에 등장할 가능성은 적다. 그러므로, 문서의 가장 앞에 인코딩된 BOM을 추가함으로써 텍스트가 유니코드임을 나타내고 그 인코딩 방식을 명시할 수 있다. BOM 문자를 이 방식으로 사용하는 것을 "유니코드 시그니처"라 한다.