UTF-8

UTF-8
UTF-8
표준.유니코드 표준
분류유니코드 변환 형식, 확장 ASCII, 가변 길이 인코딩
확장자드아스키
변환 / 부호화ISO/IEC 10646 (유니코드)
앞에UTF-1

UTF-8은 전자 통신에 사용되는 가변 길이 문자 인코딩 표준입니다.유니코드 표준에 의해 정의된 이름은 유니코드(또는 범용 부호화 문자 집합) 변환 형식 8비트에서 파생되었습니다.[1]

UTF-8은 1~4개의 1바이트(8비트) 코드 단위를 사용하여 유니코드의 유효한 문자 코드 포인트 1,112,064개를[a] 모두 인코딩할 수 있습니다.더 자주 발생하는 수치가 낮은 코드 포인트는 더 적은 바이트를 사용하여 인코딩됩니다.ASCII와의 하위 호환성을 위해 설계되었습니다. ASCII와 일대일 대응하는 유니코드의 처음 128자는 ASCII와 동일한 이진값을 가진 단일 바이트를 사용하여 인코딩되므로 유효한 ASCII 텍스트도 유효한 UTF-8 인코딩 유니코드입니다.

UTF-8은 부분 ASCII 호환성을 가진 제안된 가변 길이 인코딩인 UTF-1보다 우수한 대안으로 설계되었으며, 이는 자체 동기화 및 슬래시와 같은 문자의 완전 ASCII 호환 처리를 포함한 일부 기능이 부족했습니다.1992년 9월, Ken Thompson과 Rob PikePlan 9 운영 체제를 위한 첫 번째 구현을 했습니다.[2][3]이로 인해 X/OpenFSS-UTF에 대한 규격으로 채택하였으며,[4] 1993년[5] 1월 USENIX에서 처음으로 공식적으로 발표되었으며 이후 RFC 2277(BCP 18)[6]에서 인터넷 엔지니어링 태스크 포스(IETF)에 의해 채택되어 향후 인터넷 표준 작업을 위해 이전 RFC에서 라틴-1과 같은 단일 바이트 문자 집합을 대체하게 되었습니다.

UTF-8은 대체 텍스트 인코딩보다 국제화 문제가[7][8] 덜 발생하며, 마이크로소프트 윈도우를 포함한 모든 최신 운영 체제와 JSON과 같은 표준에 구현되어 있으며, 이는 점점 더 증가하고 있는 유니코드의 유일한 형태입니다.

UTF-8은 월드 와이드 웹(및 인터넷 기술)을 위한 지배적인 인코딩으로, 2023년 현재 전체 웹 페이지의 98.0%, 상위 10,000 페이지의 99.0%, 여러 언어의 경우 최대 100%를 차지합니다.[9]사실상 모든 국가와 언어가 웹에서 UTF-8 인코딩을 95% 이상 사용하고 있습니다.

작명

부호화의 공식 명칭은 UTF-8이며, 모든 유니코드 컨소시엄 문서에서 사용되는 철자입니다.대부분의 표준은 공식적으로 대문자로 표시하지만, 그 모든 것은 또한 대소문자 구분이 없습니다.utf-8코드에서 자주 사용됩니다.[citation needed]

일부 다른 철자법은 표준에 의해 받아들여질 수도 있습니다. 예를 들어 웹 표준(CSS, HTML, XMLHTTP 헤더 포함)은 명시적으로 utf8을 허용하고 인코딩에 대해 많은 별칭을 허용하지 않습니다.[10]공백(예: "UTF 8")이 있는 철자는 사용해서는 안 됩니다.공식 인터넷 번호 지정 기관은 csUTF8을 유일한 별칭으로 나열하기도 하지만 거의 사용되지 않습니다.[11]

윈도우에서 UTF-8은 코드 페이지입니다. 65001[12] (즉,CP_UTF8소스코드로).

MySQL에서 UTF-8은utf8mb4[13] (함께)utf8mb3, 그리고 그 가명은utf8, 기본 다국어 평면[14] 문자에 대한 부분 집합 인코딩입니다.HP PCL에서 UTF-8의 기호 ID는18N.[15]

Oracle Database(버전 9.0 이후)에서AL32UTF8[16] 는 UTF-8을 의미합니다. 거의 사용하지 않아야 하는 UTF-8과 거의 동의어에 대해서는 CESU-8도 참조하십시오.

UTF-8-BOM과 UTF-8-NObOM은 바이트 순서 표시(BOM)를 포함하거나 포함하지 않는 텍스트 파일에 사용되기도 합니다.[citation needed]특히 일본에서는 BOM이 없는 UTF-8 부호화를 UTF-8N이라고 부르기도 합니다.[17][18]

인코딩

UTF-8은 코드 포인트의 값에 따라 1~4바이트 단위로 코드 포인트를 인코딩합니다.다음 표에서 x자는 코드 포인트의 비트로 대체됩니다.

코드 포인트 ↔ UTF-8 변환
첫 번째 코드 포인트 마지막코드점 바이트 1 바이트2 바이트 3 바이트 4
U+0000 U+007F 0xxxxxxxx
U+0080 U+07FF 110 xxxxxx 10xxxxxxx
U+0800 U+FFFF 1110xxxxx 10xxxxxxx 10xxxxxxx
U+10000 [b]U+10FFFF 11110xxx 10xxxxxxx 10xxxxxxx 10xxxxxxx

처음 128개의 코드 포인트(ASCII)는 1바이트가 필요합니다.다음 1,920개의 코드 포인트는 인코딩하기 위해 2바이트가 필요한데, 이 바이트는 거의 모든 라틴 문자 알파벳의 나머지 부분과 IPA 확장, 그리스어, 키릴 문자, 콥트 문자, 아르메니아어, 히브리어, 아랍어, 시리아어, 타나 문자, N'Ko 문자를 포함합니다.BMP(Basic Multilinguation Plane)의 나머지 61,440개의 코드 포인트에는 대부분의 한자, 일본어한국어 문자를 포함하여 3바이트가 필요합니다.유니코드의 다른 평면에 있는 1,048,576개의 코드 포인트에는 이모지(그림 기호), 덜 일반적인 CJK 문자, 다양한 역사 스크립트, 수학 기호 등 4바이트가 필요합니다.

"문자"는 두 개 이상의 코드 포인트로 구성되어 있으므로 4바이트 이상이 걸릴 수 있습니다.예를 들어 국기 문자는 BMP 외부에서 "유니코드 스칼라 값 쌍으로 구성"되므로 8바이트가 걸립니다.[19][c]

부호화과정

이 예에서 빨간색, 녹색 및 파란색 숫자는 코드 포인트의 비트가 UTF-8 바이트 간에 어떻게 분배되는지 나타냅니다.UTF-8 인코딩 프로세스에 의해 추가된 추가 비트는 검은색으로 표시됩니다.

  1. 유로 부호 €의 유니코드 코드 포인트는 U+20AC입니다.
  2. 이 코드 포인트는 U+0800과 U+FFFF 사이에 있으므로 인코딩하는 데 3바이트가 소요됩니다.
  3. 16진수 20AC는 이진수 001000101100입니다.3바이트 인코딩에는 코드 포인트에서 정확히 16비트가 필요하기 때문에 두 개의 선행 0이 추가됩니다.
  4. 인코딩 길이가 3바이트이므로 선두 바이트는 3개의 1초로 시작한 다음 0(1110...)으로 시작합니다.
  5. 코드 포인트의 가장 중요한 4비트는 이 바이트의 나머지 하위 4비트에 저장됩니다(11100010). 코드 포인트의 12비트는 아직 인코딩되지 않았습니다(...0000101100).
  6. 모든 연속 바이트는 코드 포인트에서 정확히 6비트를 포함합니다.따라서 코드 포인트의 다음 6비트는 다음 바이트의 하위 6비트로 저장되고, 10은 연속 바이트로 표시하기 위해 상위 2비트로 저장됩니다(따라서 10000010).
  7. 마지막으로 코드 포인트의 마지막 6비트는 최종 바이트의 하위 6비트로 저장되고, 다시 10비트는 상위 2비트로 저장됩니다(10101100).

세 바이트 11100010 10000010 10101100E282 AC와 같이 16진수로 더 간결하게 작성할 수 있습니다.

다음 표는 UTF-8의 다른 길이를 가진 다른 변환들과 이 변환을 요약한 것입니다.

UTF-8 부호화 과정
성격 이진 코드 포인트 이진 UTF-8 헥스 UTF-8
$ U+0024 010 0100 00100100 24
£ U+00A3 000 1010 0011 11000010 10100011 C2 A3
И U+0418 100 0001 1000 11010000 10011000 D0 98
U+0939 0000 1001 0011 1001 11100000 10100100 10111001 E0 A4 B9
U+20AC 0010 0000 1010 1100 11100010 10000010 10101100 E2 82 교류.
U+D55C 1101 0101 0101 1100 11101101 10010101 10011100 ED 95 9C
𐍈 U+10348 0 0001 0000 0011 0100 1000 11110000 10010000 10001101 10001000 F0 90 8D 88

이 예에서 색상이 있는 숫자는 ASCII 이상의 문자를 인코딩하는 데 사용되는 멀티바이트 시퀀스를 나타내는 반면 검은색의 숫자는 ASCII입니다.

예를 들어, 베트남어 문구 M ì노이티 ếng Vi ệ트(𨉟呐㗂越(I speak Vietnam)는 다음과 같이 인코딩됩니다.

성격 M ì n h n i t i ế n g V i t
코드 포인트 4D EC 6E 68 20 6E F3 69 20 74 69 1EBF 6E 67 20 56 69 1EC7 74
헥스 UTF-8 C3 교류. C3 B3 E1 BA BF E1 BB 87
성격 𨉟
코드 포인트 2825F 5450 35C2 8D8A
헥스 UTF-8 F0 A8 89 9층 E5 91 90 E3 97 82 E8 B6 8A

코드페이지배치

다음 표는 UTF-8 코드 단위(개별 바이트 또는 옥텟)의 사용을 코드 페이지 형식으로 요약한 것입니다.위쪽 절반은 단일 바이트 코드에서만 사용되는 바이트에 대한 것이므로 일반 코드 페이지처럼 보입니다. 아래쪽 절반은 연속 바이트 및 선행 바이트에 대한 것이며 아래 범례에서 자세히 설명합니다.

UTF-8
0 1 2 3 4 5 6 7 8 9 A B C D E F
0배 NUL SOH STX ETX EOT ENQ ACK BS HT LF VT FF CR 그렇게 SI
1배 DLE DC1 DC2 DC3 DC4 NAK SYN ETB 할 수 있다 EM 후보선수 ESC FS 지에스 RS 미국
2배 SP ! " # $ % & ' ( ) * + , - . /
3배 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
4배 @ A B C D E F G H I J K L M N O
5배 P Q R S T U V W X Y Z [ \ ] ^ _
6배 ` a b c d e f g h i j k l m n o
7배 p q r s t u v w x y z { } ~ DEL
8배의 +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
9배 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +1A +1B +1C +1D +1E +1층
도끼 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +2A +2B +2C +2D +2E +2층
Bx +30 +31 +32 +33 +34 +35 +36 +37 +38 +39 +3A +3B +3C +3D +3E +3층
Cx 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
Dx 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
Ex 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
에프엑스 4 4 4 4 4 4 4 4 5 5 5 5 6 6
7비트(단일 바이트) 코드 포인트.연속 바이트 뒤에 연속 바이트가 있으면 안 됩니다.[20]
연속 바이트.[21]셀은 추가된 6비트의 값을 16진수로 표시합니다.[d]
여러 바이트 시퀀스의 선행 바이트는 정확히 N-1개의 연속 바이트 뒤에 와야 합니다.[22]툴팁에는 코드 포인트 범위와 이 바이트로 시작하는 시퀀스로 인코딩된 유니코드 블록이 표시됩니다.
모든 연속 바이트 배열이 유효하지 않은 선행 바이트.E0F0는 긴 인코딩을 시작할 수 있습니다.F4는 U+10FFFF보다 큰 코드 포인트를 시작할 수 있습니다.ED는 U+D800–U+DFFF 범위의 코드 포인트를 시작할 수 있으며, 이는 잘못된 UTF-16 대리점입니다.[23]
유효한 UTF-8 시퀀스에 나타나지 마십시오.C0C1은 1바이트 문자의 "오버롱" 인코딩에만 사용할 수 있습니다.[24]F5 ~ FD는 U+10FFFF보다 큰 코드 포인트만 인코딩할 수 있는 4바이트 이상 시퀀스의 선행 바이트입니다.[23]FEFF는 어떤 의미도 부여받지 못했습니다.[25]

오버롱 인코딩

원칙적으로 코드 포인트에 선두 0을 추가하여 인코딩의 바이트 수를 부풀리는 것이 가능합니다.위의 예에서 유로 부호 €를 3바이트가 아닌 4바이트로 인코딩하려면 21비트 길이가 될 때까지 선두 0으로 패딩하여 1111000000100000101000001010101100(또는 16진수로 F0882 AC)로 인코딩할 수 있습니다.이를 오버롱 인코딩이라고 합니다.

표준은 코드 포인트의 올바른 인코딩은 코드 포인트의 중요한 비트를 유지하는 데 필요한 최소 바이트 수만을 사용한다고 지정합니다.긴 인코딩은 너무 길게 호출되며 코드 포인트의 유효한 UTF-8 표현이 아닙니다.이 규칙은 코드 포인트와 코드 포인트의 유효한 인코딩 간에 일대일 대응 관계를 유지하므로 코드 포인트마다 고유한 유효한 인코딩이 있습니다.이렇게 하면 문자열 비교 및 검색이 잘 정의됩니다.

잘못된 시퀀스 및 오류 처리

바이트의 모든 시퀀스가 유효한 UTF-8은 아닙니다. UTF-8 디코더는 다음을 위해 준비되어야 합니다.

  • 유효하지 않은 바이트
  • 예기치 않은 연속 바이트
  • 문자가 끝나기 전에 계속되지 않는 바이트
  • 문자의 끝 앞에 끝나는 문자열(단순 문자열 잘라내기에서 발생할 수 있음)
  • 지나치게 긴 부호화
  • 잘못된 코드 포인트로 디코딩하는 시퀀스

많은 최초의 UTF-8 디코더들은 잘못된 비트들을 무시하고 너무 긴 결과를 받아들이면서 이것들을 해독할 것입니다.주의 깊게 조작된 잘못된 UTF-8은 NUL, 슬래시 또는 따옴표와 같은 ASCII 문자를 스킵하거나 만들 수 있습니다.잘못된 UTF-8은 Microsoft의 IIS 웹 서버[26] 및 Apache의 Tomcat 서블릿 컨테이너를 포함한 유명 제품의 보안 유효성 검사를 무시하는 데 사용되었습니다.[27]RFC 3629는 "디코딩 알고리즘의 구현은 무효 시퀀스의 디코딩으로부터 보호해야 합니다."[23]라고 명시합니다.유니코드 표준에서는 디코더들이 "잘못된 코드 단위 시퀀스를 오류 상태로 취급"하도록 요구하고 있습니다.이것은 잘못된 코드 유닛 시퀀스를 해석하거나 방출하지 않는다는 것을 보장합니다."

RFC 3629(2003년 11월) 이후 UTF-16(U+D800 ~ U+DFFF)이 사용하는 높고 낮음 대리반부와 UTF-16이 인코딩할 수 없는 코드 포인트(U+10FFF 이후)는 합법적인 유니코드 값이 아니며 UTF-8 인코딩은 잘못된 바이트 시퀀스로 처리되어야 합니다.쌍을 이루지 않은 대리반부를 디코딩하지 않으면 잘못된 UTF-16(예: Windows 파일 이름 또는 대리반부 간에 분할된 UTF-16)을 UTF-8로 저장할 수 없지만 [28]WTF-8에서는 가능합니다.

디코더의 일부 구현은 오류에 대한 예외를 제공합니다.[29]이를 통해 무해한 오류(예: "해당 파일 없음" 오류)를 서비스 거부로 전환할 수 있다는 단점이 있습니다.예를 들어 명령줄 또는 환경 변수에 잘못된 UTF-8이 포함되어 있으면 초기 버전의 파이썬 3.0은 즉시 종료됩니다.[30]

유니코드 6[31](2010년 10월) 이후 표준(3장)에서는 오류가 1바이트 길이이거나 허용되지 않는 첫 번째 바이트보다 먼저 끝나는 "모범 사례"를 권장하고 있습니다.이 디코더 E1,A0,C0에서 두 개의 오류(첫 번째 오류의 경우 2바이트)가 발생합니다.즉, 오류는 3바이트 이하이며 유효한 문자의 시작을 포함하지 않으며 21,952개의 다양한 오류가 있을 수 있습니다.[32]표준은 또한 각 오류를 대체 문자 "�"(U+FFFD)로 대체할 것을 권장합니다.

이러한 권장 사항은 자주 지켜지지 않습니다.각 바이트를 오류로 간주하는 것이 일반적이며, 이 경우 E1,A0,C0는 세 의 오류(각각 1바이트 길이)입니다.즉, 128개의 다른 오류만 존재하며, 디코딩을 "무손실"로 만들기 위해 128개의 다른 문자로 대체하는 것도 일반적입니다.[33]

바이트순서표시

유니코드 바이트 순서 표시(BOM, U+FEFF) 문자가 UTF-8 파일의 시작 부분에 있으면 처음 세 바이트는 0xEF, 0xBB, 0xBF가 됩니다.

유니코드 표준에서는 UTF-8에 대해 BOM을 사용할 필요도 없고 권장하지도 않지만 다른 인코딩에서 변환된 파일을 시작할 때 발생할 수 있음을 경고합니다.[34]UTF-8을 사용하여 인코딩된 ASCII 텍스트는 ASCII와 하위 호환되지만 유니코드 표준 권장 사항을 무시하고 BOM을 추가하면 그렇지 않습니다.BOM은 준비되지 않은 소프트웨어를 혼동할 수 있지만 그렇지 않으면 UTF-8을 수용할 수 있습니다(예: 비ASC를 허용하는 프로그래밍 언어).문자열 리터럴의 II 바이트이지만 파일의 시작 부분에는 없습니다.그럼에도 불구하고 UTF-8을 작성할 때 항상 BOM을 삽입하고 첫 번째 문자가 BOM(또는 파일에 ASCII만 포함됨)이 아니면 UTF-8의 올바른 해석을 거부하는 소프트웨어가 있었고 여전히 존재합니다.[35]

입양

2010년 이후 가장 인기 있는 1000만 개 웹사이트를 대상으로 선언된 문자 집합
2001년부터 2012년까지 구글이 기록한 웹에서의 주요 인코딩의 사용.[36] UTF-8은 2008년에 다른 모든 인코딩을 추월했고 2012년에는 웹의 60% 이상을 추월했습니다(이후 100%에 육박).UTF-8은 여기에 명시적으로 나열된 유니코드의 유일한 인코딩이며, 나머지는 유니코드의 하위 집합만 제공합니다.ASCII 전용 그림에는 선언된 헤더에 관계없이 ASCII 문자만 포함된 모든 웹 페이지가 포함됩니다.

UTF-8은 2008년 이후 월드 와이드 웹을 위한 가장 일반적인 인코딩이었습니다.[37]2023년 10월 현재 UTF-8은 조사 대상 웹사이트의 98.0%가 사용하고 있습니다.[9][e]많은 페이지에서 콘텐츠를 표시하기 위해 ASCII 문자만 사용하지만 UTF-8 대신 ASCII로만 인코딩을 선언하는 웹 사이트는 거의 없습니다.[38] 추적되는 언어의 50% 이상이 UTF-8을 100% 사용합니다.

많은 표준들이 UTF-8만 지원합니다. 예를 들어 JSON 교환이 필요합니다(바이트 순서 표시(BOM)).[39] 또한 UTF-8은 HTML 및 DOM 사양에 대해 WHATWG에서 권고한 것입니다.그리고 "UTF-8 인코딩이 유니코드 교환에 가장 적합한 인코딩"[8]이라고 명시하고, 인터넷 메일 컨소시엄은 모든 전자 메일 프로그램이 UTF-8을 사용하여 메일을 표시하고 생성할 수 있도록 권장합니다.[40][41]World Wide Web Consortium은 XML과 HTML의 기본 인코딩으로 UTF-8을 권장합니다(UTF-8만 사용하는 것이 아니라 메타데이터로 선언). "모든 문자가 ASCII 범위에 있는 경우에도...UTF-8이 아닌 인코딩을 사용하면 예상치 못한 결과가 발생할 수 있습니다."[42]

많은 소프트웨어들이 UTF-8을 읽고 쓸 수 있습니다. 하지만 일반 설정에서 옵션을 변경해야 하거나, 파일을 읽기 위해 첫 번째 문자로 BOM(바이트 순서 표시)이 필요할 수 있습니다.UTF-8을 지원하는 소프트웨어의 예로는 Microsoft Word,[43][44][45] Microsoft Excel(2016 이상),[46][47] Google Drive, LibreOffice 및 대부분의 데이터베이스가 있습니다.

그러나 로컬 텍스트 파일의 경우 UTF-8 사용이 덜 일반적이며, 기존 단일 바이트(및 몇 개의 CJK 멀티 바이트) 인코딩이 여전히 사용되고 있습니다.파일의 첫 번째 바이트가 바이트 순서 표시 문자(BOM)를 인코딩하지 않는 한 UTF-8을 읽기를 거부하는 오래된 텍스트 편집기가 주된 원인입니다.[48]

일부 최신 소프트웨어는 UTF-8만 읽고 쓸 수 있거나 적어도 BOM이 필요하지 않습니다.[49]현재 지원되는 모든 버전의 Windows 메모장은 기본적으로 BOM 없이 UTF-8을 작성합니다([50]이전 버전/지원되지 않는 Windows 7에서 변경).윈도우 11의 일부 시스템 파일은 BOM을 필요로 하지 않는 UTF-8이[51] 필요하며, macOS와 리눅스의 거의 모든 파일은 BOM을 필요로 하지 않는 UTF-8이 필요합니다.[citation needed]Java 18은 기본적으로 UTF-8로 파일을 읽고 쓰는 기능을 수행하며,[52] 이전 버전(예: LTS 버전)에서는 NIO API만 변경되었습니다.Ruby 3.0[53][54]R 4.2.2를 포함한 많은 다른 프로그래밍 언어는 I/O용 UTF-8을 기본값으로 합니다.[55]현재 지원되는 모든 버전의 파이썬은 I/O용 UTF-8을 지원하며, 심지어 윈도우(옵션인 경우)에서도 지원됩니다.open() 기능[56]) 및 모든 플랫폼에서 UTF-8 I/O를 Python 3.15의 기본값으로 만드는 계획이 있습니다.[57][58]C++23은 UTF-8을 유일한 휴대용 소스 코드 파일 형식으로 채택하고 있습니다(놀랍게도 이전에는 없었습니다.[59]

메모리에서 UTF-8의 사용량은 다른 영역보다 훨씬 적으며 대신 UTF-16을 사용하는 경우가 많습니다.이는 특히 Windows에서 발생하지만 자바스크립트, 파이썬,[f] Qt 및 기타 여러 크로스 플랫폼 소프트웨어 라이브러리에서도 발생합니다.Windows API와의 호환성이 주된 이유인데, 이는 BMP의 직접 인덱싱이 속도를 향상시킬 것이라는 믿음 때문에 처음에 선택한 것입니다.UTF-8에 있는 외부 텍스트에서/외부 텍스트로 번역하면 소프트웨어 속도가 느려지고, 다른 코드 조각이 동일한 번역을 수행하지 않을 때 버그가 발생합니다.

백호환성은 16비트 인코딩 대신 UTF-8을 사용하도록 코드를 변경하는 데 심각한 장애가 되지만, 이런 일이 발생하고 있습니다.Go,[61] Julia, Rust, Swift 5,[62] PyPy[63] 기본 문자열 프리미티브는 모든 경우에 내부적으로 UTF-8을 사용하는 반면, Python 3.3 이후 Python은 일부 경우에 내부적으로 UTF-8을 사용합니다([67]Python C API 확장용).[60][64] 향후 버전의 Python은 기본적으로 UTF-8로 문자열을 저장할 계획입니다.[65][66] 그리고 최신 버전의 Microsoft Visual Studio는 내부적으로 UTF-8을 사용합니다.마이크로소프트의 SQL 서버 2019는 UTF-8에 대한 지원을 추가했으며 이를 사용하면 속도가 35% 향상되고 스토리지 요구 사항이 거의 50% 감소했습니다.[68]

현재 지원되는 모든 윈도우 버전은 UTF-8을 지원합니다(Xbox 포함).[7]2019년 5월, 마이크로소프트는 UTF-16만 권장하던 기존의 입장을 뒤집었고, UTF-8을 윈도우 API를 위한 "코드 페이지"로 설정할 수 있는 기능이 도입되었으며, 마이크로소프트는 프로그래머들에게 UTF-8을 사용할 것을 권장하며,[69] 심지어 "UTF-16 [...]은 윈도우가 여러 플랫폼을 대상으로 하는 코드에 부여하는 독특한 부담입니다."[7]라고 말하기도 합니다.

역사

국제표준화기구(ISO)는 1989년에 보편적인 멀티바이트 문자 집합을 구성하기 시작했습니다.ISO 10646 표준 초안에는 32비트 코드 포인트의 바이트 스트림 인코딩을 제공하는 UTF-1이라는 불필요한 부속서가 포함되어 있었습니다.이 인코딩은 성능적인 면에서 만족스럽지 못했고, 가장 큰 문제는 ASCII와 ASCII가 아닌 것 사이에 명확한 구분이 없다는 것이었습니다.II: 새로운 UTF-1 도구는 ASCII 인코딩 텍스트와 하위 호환되지만 UTF-1 인코딩 텍스트는 ASCII(또는 확장 ASCII)를 기대하는 기존 코드에 혼란을 줄 수 있습니다. 예를 들어 '/'의 경우 0x2F와 같이 ASCII에서 다른 의미를 가진 0x21–0x7E 범위의 연속 바이트를 포함할 수 있기 때문입니다.그리고 이 예는 그 대체품의 이름과 소개문에 반영되어 있습니다.아래 표는 부속서의 본문 설명에서 도출한 것입니다.

UTF-1
번호
바이트 단위의
첫번째
코드 포인트
지난
코드 포인트
바이트 1 바이트2 바이트 3 바이트 4 바이트 5
1 U+0000 U+009F 00-9F
2 U+00A0 U+00FF A0 A0–FF
2 U+0100 U+4015 A1–F5 21–7E, A0–FF
3 U+4016 U+38E2D F6–FB 21–7E, A0–FF 21–7E, A0–FF
5 U+38E2E U+7FFFFFF FC–FF 21–7E, A0–FF 21–7E, A0–FF 21–7E, A0–FF 21–7E, A0–FF

1992년 7월 X/Open 위원회 XoJIG는 더 나은 인코딩을 찾고 있었습니다.Unix System Laboratories의 Dave Proser는 더 빠른 구현 특성을 가진 것에 대한 제안서를 제출했고, 7비트 ASCII 문자는 높은 비트가 설정된 곳에서 바이트만 포함된다는 개선점을 소개했습니다.FSS-UTF(File System Safe UCS Transformation Format)라는 이름과 이 제안서의 대부분의 본문은 나중에 최종 명세서에 보존되었습니다.[70][71][72][73]

FSS-UTF

FSS-UTF안 (1992)
번호
바이트 단위의
첫번째
코드 포인트
지난
코드 포인트
바이트 1 바이트2 바이트 3 바이트 4 바이트 5
1 U+0000 U+007F 0xxxxxxxx
2 U+0080 U+207F 10xxxxxxx 1xxxxxxxx
3 U+2080 U+8207F 110 xxxxxx 1xxxxxxxx 1xxxxxxxx
4 U+82080 U+208207F 1110xxxxx 1xxxxxxxx 1xxxxxxxx 1xxxxxxxx
5 U+2082080 U+7FFFFFF 11110xxx 1xxxxxxxx 1xxxxxxxx 1xxxxxxxx 1xxxxxxxx

1992년 8월, IBM X/Open 담당자가 이 제안을 이해 당사자들에게 전달했습니다.Bell LabsPlan 9 운영 체제 그룹의 Ken Thompson이 수정한 것은 독자가 어디서든 시작하여 문자 경계를 즉시 감지할 수 있도록 하는 동시에 이전 제안보다 비트 효율성이 다소 떨어졌습니다.또한 편향의 사용을 포기하고 대신 가능한 가장 짧은 인코딩만 허용된다는 규칙을 추가했습니다. 콤팩트성의 추가 손실은 상대적으로 미미하지만 이제 독자들은 신뢰성과 특히 보안 문제를 피하기 위해 잘못된 인코딩을 주의해야 합니다.톰슨의 디자인은 1992년 9월 2일 롭 파이크와 함께 뉴저지 식당의 플레이스매트에서 윤곽이 드러났습니다.다음 날 Pike와 Thompson은 이를 실행하고 Plan 9를 업데이트하여 전체적으로 사용할 수 있도록 한 후 X/Open에 성공 소식을 전했고, X/Open은 이를 FSS-UTF의 사양으로 받아들였습니다.[72]

FSS-UTF(1992)/UTF-8(1993)[2]
번호
바이트 단위의
첫번째
코드 포인트
지난
코드 포인트
바이트 1 바이트2 바이트 3 바이트 4 바이트 5 바이트 6
1 U+0000 U+007F 0xxxxxxxx
2 U+0080 U+07FF 110 xxxxxx 10xxxxxxx
3 U+0800 U+FFFF 1110xxxxx 10xxxxxxx 10xxxxxxx
4 U+10000 U+1FFFF 11110xxx 10xxxxxxx 10xxxxxxx 10xxxxxxx
5 U+200000 U+3FFFFFF 111110xx 10xxxxxxx 10xxxxxxx 10xxxxxxx 10xxxxxxx
6 U+4000000 U+7FFFFFF 1111110x 10xxxxxxx 10xxxxxxx 10xxxxxxx 10xxxxxxx 10xxxxxxx

UTF-8은 1993년 1월 25일부터 29일까지 샌디에이고에서 열린 USENIX 컨퍼런스에서 처음으로 공식 발표되었습니다.인터넷 공학 태스크 포스는 미래의 인터넷 표준 작업을 위해 RFC 2277 BCP(18)[6]의 문자 집합 및 언어에 관한 정책에서 UTF-8을 채택하여, 이전 RFC에서 라틴-1과 같은 단일 바이트 문자 집합을 대체했습니다.

2003년 11월, UTF-8은 다음과 같이 제한되었습니다. UTF-16 문자 인코딩의 제약 조건과 일치시키기 위한 RFC3629: 높은 문자와 낮은 대리 문자에 해당하는 코드 포인트를 명시적으로 금지하는 것은 3바이트 시퀀스의 3% 이상을 제거하고, U+10FFFF로 끝나는 것은 4바이트 시퀀스의 48% 이상과 모든 5바이트 및 6바이트 시퀀스를 제거합니다.

기준

다양한 표준 문서에서 UTF-8의 현재 정의는 다음과 같습니다.

  • UTF-8을 표준 인터넷 프로토콜 요소로 설정하는 RFC 3629 / STD 63 (2003)
  • RFC 5198 네트워크 교환을 위한 UTF-8 NFC 정의 (2008)
  • ISO/IEC 10646:2014 §9.1 (2014)[74]
  • 유니코드 표준, 버전 15.0.0 (2022)[75]

이들은 다음의 오래된 저작물에서 주어진 정의를 대체합니다.

  • 유니코드 표준, 버전 2.0, 부록 A (1996)
  • ISO/IEC 10646-1:1993 개정판 2/부속서 R(1996)
  • RFC 2044 (1996)
  • RFC 2279 (1998)
  • 유니코드 표준, 버전 3.0, §2.3 (2000) + Corrigendum #1 : UTF-8 최단 형식 (2000)
  • 유니코드 표준 부속서 #27: 유니코드 3.1 (2001)[76]
  • 유니코드 표준, 버전 5.0 (2006)[77]
  • 유니코드 표준, 버전 6.0 (2010)[78]

코드 포인트 값의 허용 범위 및 잘못된 입력의 안전한 처리와 같은 문제에 대한 주요 차이점으로 일반적인 메커니즘은 모두 동일합니다.

다른 인코딩과 비교

이 인코딩의 몇 가지 중요한 기능은 다음과 같습니다.

  • 역호환성: ASCII와의 역호환성과 ASCII 부호화된 텍스트를 처리하도록 설계된 막대한 소프트웨어 양이 UTF-8 설계의 주요 원동력이었습니다. UTF-8에서는 0에서 127 범위의 값을 가진 단일 바이트가 ASCII 범위의 유니코드 코드 포인트에 직접 매핑됩니다.이 범위의 단일 바이트는 ASCII에서와 같이 문자를 나타냅니다.또한 7비트 바이트(가장 중요한 비트가 0인 바이트)는 멀티바이트 시퀀스에 나타나지 않으며 유효한 멀티바이트 시퀀스가 ASCII 코드 포인트로 디코딩되지 않습니다.7비트 바이트 시퀀스는 유효한 ASCII 및 유효한 UTF-8 둘 다이며, 두 해석 중 하나로 동일한 문자 시퀀스를 나타냅니다.따라서 UTF-8 스트림의 7비트 바이트는 스트림의 모든 ASCII 문자만을 나타냅니다.따라서 포맷 및 제어 목적으로 ASCII 문자를 사용하는 많은 텍스트 프로세서, 파서, 프로토콜, 파일 형식, 텍스트 디스플레이 프로그램 등은 멀티바이트 시퀀스를 디코딩하지 않고 UTF-8 바이트 스트림을 단일 바이트 문자 시퀀스로 처리함으로써 의도한 대로 계속 작동할 것입니다.구두점, 공백 및 컨트롤 문자와 같이 처리가 전환되는 ASCII 문자는 멀티바이트 시퀀스로 인코딩되지 않습니다.따라서 이러한 프로세서는 멀티바이트 시퀀스를 디코딩하지 않고 단순히 무시하거나 전달하는 것이 안전합니다.예를 들어, ASCII 공백은 UTF-8 스트림을 단어로 토큰화하는 데 사용될 수 있고, ASCII 라인 피드는 UTF-8 스트림을 라인으로 분할하는 데 사용될 수 있으며, ASCII NUL 문자는 UTF-8 인코딩된 데이터를 널 종단 문자열로 분할하는 데 사용될 수 있습니다.마찬가지로 "printf"와 같은 라이브러리 함수에서 사용되는 많은 형식 문자열은 UTF-8 인코딩된 입력 인수를 올바르게 처리합니다.
  • 폴백 및 자동 감지:가능한 바이트 문자열의 작은 부분 집합만이 유효한 UTF-8 문자열입니다. 여러 바이트가 나타나지 않으며, 높은 비트 집합을 가진 바이트는 단독일 수 없으며, 추가 요구 사항은 확장 ASCII에서 읽을 수 있는 텍스트가 유효한 UTF-8일 가능성이 매우 낮다는 것을 의미합니다.UTF-8의 인기의 일부는 이들에게도 하위 호환성을 제공하기 때문입니다.확장 ASCII를 입력으로 잘못 수신하는 UTF-8 프로세서는 매우 높은 신뢰성으로 이를 "자동 감지"할 수 있습니다.UTF-8 스트림은 단순히 오류를 포함할 수 있으며, 이로 인해 자동 검출 방식이 거짓 양성을 생성할 수 있습니다. 하지만 자동 검출은 대부분의 경우, 특히 더 긴 텍스트에서 성공적이며 널리 사용됩니다.또한 UTF-8의 오류가 탐지되었을 때 레거시 인코딩에 대한 적절한 코드 포인트를 사용하여 8비트 바이트를 "폴백"하거나 교체하는 기능을 수행하므로 UTF-8과 레거시 인코딩이 동일한 파일에 연결된 경우에도 복구가 가능합니다.
  • 접두사 코드:첫 번째 바이트는 시퀀스의 바이트 수를 나타냅니다.스트림에서 읽는 것은 먼저 다음 시퀀스의 첫 번째 바이트나 스트림 종료 표시를 기다릴 필요 없이 완전히 수신된 각 시퀀스를 순간적으로 디코딩할 수 있습니다.멀티 바이트 시퀀스의 길이는 단순히 선행 바이트의 고차 1의 개수이기 때문에 인간에 의해 쉽게 결정됩니다.스트림이 시퀀스 중간에 끝나면 잘못된 문자는 디코딩되지 않습니다.
  • 자체 동기화:선행 바이트와 연속 바이트는 값을 공유하지 않습니다(연속 바이트는 비트 10으로 시작하는 반면 단일 바이트는 0으로 시작하고 긴 선행 바이트는 11로 시작).이는 검색이 실수로 한 문자에 대한 순서를 다른 문자의 중간에서 찾지 않는다는 것을 의미합니다.또한 선두 바이트를 찾기 위해 최대 3바이트를 백업함으로써 임의의 위치에서 문자의 시작을 찾을 수 있음을 의미합니다.스트림이 시퀀스 중간에 시작하면 잘못된 문자가 디코딩되지 않으며 더 짧은 시퀀스는 긴 시퀀스 내부에 나타나지 않습니다.
  • 정렬 순서:선행 바이트의 선택된 값은 UTF-8 문자열의 목록을 해당 바이트 시퀀스를 정렬하여 코드 포인트 순서로 정렬할 수 있음을 의미합니다.

싱글바이트

  • UTF-8은 모든 유니코드 문자를 인코딩할 수 있으므로 "코드 페이지"를 파악하고 설정할 필요가 없거나 사용 중인 문자 집합을 나타낼 필요가 없으며 여러 스크립트에서 동시에 출력할 수 있습니다.많은 스크립트의 경우 하나 이상의 단일 바이트 인코딩이 사용되었으며, 따라서 스크립트를 알고 있어도 스크립트를 올바르게 표시하기에는 정보가 부족했습니다.
  • 바이트 0xFE 및 0xFF가 나타나지 않으므로 유효한 UTF-8 스트림은 UTF-16 바이트 순서 표시와 일치하지 않으므로 이 스트림과 혼동할 수 없습니다.또한 0xFF(0377)가 없으면 Telnet(및 FTP 제어 연결)에서 이 바이트를 벗어날 필요가 없습니다.
  • UTF-8 인코딩된 텍스트는 일반 ASCII 문자를 제외하고 특수화된 단일 바이트 인코딩보다 큽니다.라틴 문자가 아닌 문자를 상단에 인코딩한 8비트 문자 집합을 사용한 스크립트의 경우(대부분의 키릴 문자 및 그리스 문자 코드 페이지 등), UTF-8의 문자 크기는 두 배가 됩니다.태국어데바나가리(다양한 남아시아 언어에서 사용되는)와 같은 일부 스크립트의 경우 문자 크기가 세 배가 됩니다.유니코드에서는 단일 바이트가 합성 문자로 바뀌어 UTF-8에서는 6배 더 큰 예도 있습니다.이것은 인도와 다른 나라들에서 반대를 야기시켰습니다.[citation needed]
  • UTF-8(또는 다른 멀티바이트 인코딩)에서는 문자열을 문자 중간에 분할하거나 자를 수 있습니다.두 조각을 문자로 해석하기 전에 나중에 다시 추가하지 않으면 이전 섹션의 끝과 다음 섹션의 시작에 모두 잘못된 시퀀스가 도입될 수 있으며 일부 디코더는 이러한 바이트를 보존하지 않아 데이터 손실이 발생합니다.UTF-8은 자체적으로 동기화되기 때문에 유효한 다른 문자를 사용할 수 없으며 잘라내기 지점을 문자의 시작 부분으로 뒤로 이동하는 것도 매우 쉽습니다.
  • 코드 포인트의 크기가 모두 같으면 고정된 개수를 측정하기 쉽습니다."문자"가 "바이트"의 동의어로 사용되는 ASCII 시대의 문서 때문에 이는 종종 중요하게 여겨집니다.그러나 "문자" 대신 바이트를 사용하여 문자열 위치를 측정함으로써 대부분의 알고리즘을 UTF-8에 쉽고 효율적으로 적용할 수 있습니다. 긴 문자열 내의 문자열을 검색하는 것은 예를 들어 바이트 단위로 수행될 수 있습니다. 자체 동기화 속성은 오탐을 방지합니다.

기타 멀티바이트

  • UTF-8은 모든 유니코드 문자를 인코딩할 수 있습니다.올바른 코드 페이지나 글꼴을 선택할 필요 없이 다른 스크립트의 파일을 올바르게 표시할 수 있습니다.예를 들어 중국어와 아랍어는 특수 마크업이나 인코딩을 지정하는 수동 설정 없이 동일한 파일로 작성할 수 있습니다.
  • UTF-8은 자체적으로 동기화됩니다. 문자 경계는 어느 방향으로든 잘 정의된 비트 패턴을 스캔하여 쉽게 식별할 수 있습니다.오류나 손상으로 바이트가 손실될 경우 언제든지 다음 유효 문자를 찾아 처리를 재개할 수 있습니다.지정된 필드에 맞게 문자열을 줄여야 하는 경우 이전 유효한 문자를 쉽게 찾을 수 있습니다.Shift JIS와 같은 많은 멀티바이트 인코딩은 재동기화하기가 훨씬 어렵습니다.이는 바이트 지향 문자열 검색 알고리즘을 UTF-8과 함께 사용할 수 있음을 의미하기도 합니다(문자가 그 많은 바이트로 구성된 "단어"와 동일하므로). 최적화된 버전의 바이트 검색은 하드웨어 지원 및 256개의 항목만 있는 룩업 테이블로 인해 훨씬 더 빨라질 수 있습니다.그러나 자체 동기화를 수행하려면 크기를 늘리면서 모든 바이트에서 이러한 마커에 대해 비트를 예약해야 합니다.
  • 간단한 비트 단위 연산을 사용하여 인코딩하기에 효율적입니다.UTF-8은 곱셈이나 나눗셈과 같은 느린 수학 연산을 필요로 하지 않습니다(Shift JIS, GB 2312 및 기타 인코딩과 달리).
  • UTF-8은 특정 스크립트를 위해 설계된 멀티바이트 인코딩보다 더 많은 공간을 차지합니다.동아시아 레거시 인코딩은 일반적으로 문자당 2바이트를 사용하지만 UTF-8에서는 문자당 3바이트를 사용합니다.

UTF-16

  • 바이트 인코딩과 UTF-8은 프로그램에서 바이트 배열로 표현되며, 소스 코드를 바이트 인코딩에서 UTF-8로 변환할 때 함수를 수행할 필요가 없습니다. UTF-16은 16비트 워드 배열로 표현되며, 기존 ASCII 기반 프로그램(예: 윈도우에서 실행)과의 호환성을 유지하면서 UTF-16으로 변환합니다.i는 문자열을 복제하는 데 필요한 모든 API 및 데이터 구조이며, 한 버전은 바이트 문자열을 허용하고 다른 버전은 UTF-16을 허용합니다.이전 버전과의 호환성이 필요하지 않은 경우에도 모든 문자열 처리를 수정해야 합니다.
  • U+0080 이하의 코드 포인트가 U+0800 범위보다 많을 경우 UTF-8로 인코딩된 텍스트는 UTF-16으로 인코딩된 동일한 텍스트보다 작습니다.U+FFFF.이것은 모든 현대 유럽 언어에 해당됩니다.일반적인 파일의 공백, 새 줄, 숫자 및 HTML 마크업의 수가 크기 때문에 중국어와 같은 언어에도 해당되는 경우가 많습니다.
  • 대부분의 통신(예: HTML 및 IP)과 스토리지(예: Unix의 경우)는 바이트 스트림을 위해 설계되었습니다.UTF-16 문자열은 각 코드 단위에 대해 바이트 쌍을 사용해야 합니다.
    • 이 두 바이트의 순서는 문제가 되며 바이트 순서 표시와 같이 UTF-16 프로토콜에 지정되어야 합니다.
    • UTF-16에서 홀수 바이트 수가 누락된 경우 문자열의 전체가 무의미한 텍스트가 됩니다.UTF-8에서 누락된 바이트는 누락된 바이트 다음 문자부터 텍스트를 정확하게 복구할 수 있습니다.

파생상품

다음 구현은 UTF-8 사양과 약간의 차이를 보여줍니다.이들은 UTF-8 규격과 호환되지 않으며, UTF-8 적용을 준수하면 거부될 수 있습니다.

CESU-8

Unicode Technical Report #26에서[79] CESU-8이라는 이름을 UTF-8에서 요구하는 4바이트가 아닌 6바이트를 사용하여 보충 평면의 유니코드 문자를 인코딩하는 UTF-8의 비표준 변형에 할당합니다. CESU-8 인코딩은 4바이트 UTF-16 대리 쌍의 각 절반을 2바이트 UCS-2 문자로 처리하여 2개의 3바이트 UTF-8 문자를 생성합니다.원래의 보조 캐릭터를 함께 나타내는 배우들.기본 다국어 평면 내의 유니코드 문자는 UTF-8에서와 같이 나타납니다.보고서는 유니코드 컨소시엄이 사용을 금지했음에도 불구하고 CESU-8로 인코딩된 데이터의 존재를 인정하고 공식화하기 위해 작성되었으며, CESU-8 인코딩의 의도적인 이유는 UTF-16 바이너리 대조의 보존이라고 언급합니다.

CESU-8 인코딩은 UCS-2 데이터를 가정하는 변환 방법을 사용하여 보조 문자가 있는 UTF-16 데이터를 UTF-8로 변환함으로써 발생할 수 있습니다. 즉, 4바이트 UTF-16 보조 문자를 인식하지 못합니다.주로 마이크로소프트 윈도우와 같이 내부적으로 UTF-16을 많이 사용하는 운영 체제에서 문제가 됩니다.[citation needed]

Oracle Database에서UTF8문자 집합은 CESU-8 인코딩을 사용하며, 더 이상 사용되지 않습니다.AL32UTF8문자 집합은 표준 호환 UTF-8 인코딩을 사용하며 선호됩니다.[80][81]

CESU-8은 HTML5 문서에 사용이 금지되어 있습니다.[82][83][84]

MySQL utf8mb3

MySQL에서,utf8mb3문자 집합은 문자당 최대 3바이트의 UTF-8 인코딩 데이터로 정의되며, 이는 기본 다국어 평면(예: UCS-2)의 유니코드 문자만 지원됨을 의미합니다.보조 평면의 유니코드 문자는 명시적으로 지원되지 않습니다.utf8mb3더 이상 사용하지 않을 것입니다.utf8mb4표준 호환 UTF-8 인코딩을 사용하는 문자 집합.utf8는 에 대한 별칭입니다.utf8mb3, 하지만 이들의 가명이 될 것입니다.utf8mb4MySQL의 향후 릴리스에서.[14]지원되지는 않지만 CESU-8 인코딩 데이터를 저장할 수 있습니다.utf8mb3, UTF-16 데이터를 UCS-2인 것처럼 보충 문자로 처리함으로써.

개조 UTF-8

수정된 UTF-8(MUTF-8)은 자바 프로그래밍 언어로 시작되었습니다.Modified UTF-8에서 null 문자(U+0000)는 000000000000(16진수00) 대신 2바이트 overlong 인코딩 110000000(16진수 C080)을 사용합니다.[85]수정된 UTF-8 문자열은 실제 null 바이트를 포함하지 않지만 U+0000을 포함한 모든 유니코드 코드 포인트를 포함할 수 있습니다.[86] U+0000은 이러한 문자열(null 바이트가 추가된)을 기존의 null-terminated 문자열 함수로 처리할 수 있게 해줍니다.알려진 모든 Modified UTF-8 구현은 또한 CESU-8에서와 같이 대리쌍을 처리합니다.

일반적인 사용에서 이 언어는 문자열을 읽고 쓸 때 표준 UTF-8을 지원합니다.InputStreamReader그리고.OutputStreamWriter(플랫폼의 기본 문자 집합이거나 프로그램에서 요청한 경우).그러나 다른 응용 프로그램 중 객체 직렬화[87] 위해 수정된 UTF-8을 사용합니다.DataInput그리고.DataOutput, Java Native Interface [88]클래스 파일에 일정한 문자열을 포함하는 경우.[89]

Dalvik이 정의한 덱스 형식도 문자열 값을 나타내기 위해 동일한 수정된 UTF-8을 사용합니다.[90]또한 Tcl은 유니코드 데이터의 내부 표현을 위해 Java와 동일한 수정된 UTF-8을[91] 사용하지만 외부 데이터를 위해 엄격한 CESU-8을 사용합니다.

WTF-8

WTF-8(Wobbly Transformation Format, 8비트)에서 짝을 이루지 않은 대리반부(U+D800 ~ U+DFFF)를 사용할 수 있습니다.[92]Windows 파일 이름과 같이 잘못된 UTF-16을 저장하려면 이 옵션이 필요합니다.UTF-8을 다루는 많은 시스템들은 이것이 더 간단하기 때문에 다른 인코딩을 고려하지 않고 이러한 방식으로 동작합니다.[93]

"WTF-8"이라는 용어는 때때로 CP1252 바이트가 유일하게 인코딩되었다는 암시와 함께 잘못 이중 인코딩된 UTF-8[94][95] 지칭하는 데 유머러스하게 사용되기도 합니다.[96]

PEP 383

Python 프로그래밍 언어 버전 3은 잘못된 UTF-8 바이트 스트림의 각 바이트를 오류로 처리합니다(Python 3.7의[97] 새로운 UTF-8 모드 변경 사항 참조). 이것은 128개의 다른 가능한 오류를 제공합니다.UTF-8로 추정되는 바이트 시퀀스를 UTF-16 또는 UTF-32로 무손실 변환할 수 있도록 확장 기능이 생성되었습니다. 128개의 가능한 오류 바이트를 예약된 코드 포인트로 변환하고 해당 코드 포인트를 다시 오류 바이트로 변환하여 UTF-8을 출력합니다.가장 일반적인 방법은 코드를 U+DC80으로 번역하는 것입니다.PythonPEP 383(또는 "surgate escape") 접근 방식에서 사용되는 낮은 (추적) 대리 값이므로 "잘못된" UTF-16입니다.[33]MirBSD OPTU-8/16이라고 불리는 또 다른 인코딩은 그들을 U+EF80으로 변환합니다...전용 영역에서 U+EFF.[98]어느 쪽이든 바이트 값은 출력 코드 포인트의 하위 8비트로 인코딩됩니다.

이러한 인코딩은 "잘못된" 바이트 문자열을 나중까지 처리할 필요가 없으며, "텍스트"와 "데이터" 바이트 배열이 동일한 개체가 되도록 허용하기 때문에 매우 유용합니다.프로그램이 내부적으로 UTF-16을 사용하고자 하는 경우, 유효하지 않은 UTF-8을 사용할 수 있는 파일 이름을 보존하고 사용하는 데 이러한 파일 이름이 필요합니다.[99] 윈도우 파일 시스템 API가 UTF-16을 사용하기 때문에, 유효하지 않은 UTF-8을 지원할 필요성은 줄어듭니다.[33]

인코딩이 가역적이려면 잘못된 바이트에 사용되는 코드 포인트의 표준 UTF-8 인코딩은 무효로 간주되어야 합니다.이로 인해 인코딩이 WTF-8 또는 CESU-8과 호환되지 않게 됩니다(128개의 코드 포인트만 해당).재인코딩 시 유효한 UTF-8로 다시 변환되는 에러 코드 포인트의 시퀀스를 주의할 필요가 있는데, 이는 악성 소프트웨어가 출력에 예기치 않은 문자를 얻기 위해 사용할 수 있지만, 이것은 ASCII 문자를 생성할 수 없으므로 비교적 안전하다고 간주됩니다.악성 시퀀스(예: 사이트스크립팅)는 대개 ASCII 문자에 의존하기 때문입니다.[99]

참고 항목

메모들

  1. ^ 17대의 비행기와 비행기당 코드 포인트 2개를 곱하고 기술적으로는 2대의 invalid 대용품을 뺀 것입니다.
  2. ^ 최대 0x1FFFF를 인코딩하기에 충분한 x 비트가 있지만, 현재 RFC 3629 §3는 UTF-16의 한계에 맞추기 위해 UTF-8 인코딩을 코드 포인트 U+10FFF로 제한합니다.오래된 RFC 2279는 UTF-8 인코딩을 (이후 합법적인) 코드 포인트 U+7FFFFFFF.
  3. ^ 일부 복잡한 이모티콘 문자는 이보다 더 많은 것을 취할 수 있습니다. 트랜스젠더 플래그 이모티콘(🏳️⚧️)은 5개의 코드 포인트 시퀀스 U+1F3 U+FE0F U+200D U+26A7 U+FE0F로 구성되어 있으며, 인코딩하기 위해 16바이트가 필요합니다.스코틀랜드 국기(🏴󠁧󠁢󠁳󠁣󠁴󠁿)의 경우 7코드 포인트 시퀀스 U+1F3F4 U+E0067 U+E0062 U+E0073 U+E0063 U+E0074 U+E007F에 대해 총 28바이트가 필요합니다.
  4. ^ 예를 들어, 9D 셀은 +1D라고 말합니다.이진법의 16진수 9D는 10011101이고, 가장 높은 2비트(10)는 이를 연속 바이트로 표시하기 위해 예약되므로 나머지 6비트(011101)는 1D의 16진수 값을 가집니다.
  5. ^ W3Techs.com 설문조사는 서버의 응답에 명시된 인코딩을 기반으로 합니다. https://w3techs.com/forum/topic/22994 을 참조하십시오.
  6. ^ 파이썬은 이른바 "유니코드"에 여러 가지 인코딩을 사용하지만, 이 인코딩들 중 어떤 것도 UTF-8이 아닙니다. 파이썬 2와 초기 버전 3은 윈도에서는 UTF-16을, 유닉스에서는 UTF-32를 사용했습니다.파이썬 3의 최신 구현에서는 필요한 최대 코드 포인트에 따라 ISO-8859-1, UCS-2, UTF-32의 세 가지 고정 길이 인코딩을 사용합니다.[60]

참고문헌

  1. ^ "Chapter 2. General Structure". The Unicode Standard (6.0 ed.). Mountain View, California, US: The Unicode Consortium. ISBN 978-1-936213-01-6.
  2. ^ a b Pike, Rob (30 April 2003). "UTF-8 history".
  3. ^ Pike, Rob; Thompson, Ken (1993). "Hello World or Καλημέρα κόσμε or こんにちは 世界" (PDF). Proceedings of the Winter 1993 USENIX Conference.
  4. ^ "File System Safe UCS - Transformation Format (FSS-UTF) - X/Open Preliminary Specification" (PDF). unicode.org.
  5. ^ "USENIX Winter 1993 Conference Proceedings". usenix.org.
  6. ^ a b Alvestrand, Harald T. (January 1998). IETF Policy on Character Sets and Languages. IETF. doi:10.17487/RFC2277. BCP 18. RFC 2277.
  7. ^ a b c "UTF-8 support in the Microsoft Game Development Kit (GDK) - Microsoft Game Development Kit". learn.microsoft.com. Retrieved 2023-03-05. By operating in UTF-8, you can ensure maximum compatibility [..] Windows operates natively in UTF-16 (or WCHAR), which requires code page conversions by using MultiByteToWideChar and WideCharToMultiByte. This is a unique burden that Windows places on code that targets multiple platforms. [..] The Microsoft Game Development Kit (GDK) and Windows in general are moving forward to support UTF-8 to remove this unique burden of Windows on code targeting or interchanging with multiple platforms and the web. Also, this results in fewer internationalization issues in apps and games and reduces the test matrix that's required to get it right.
  8. ^ a b "Encoding Standard". encoding.spec.whatwg.org. Retrieved 2020-04-15.
  9. ^ a b c "Usage Survey of Character Encodings broken down by Ranking". w3techs.com. Retrieved 2023-10-01.
  10. ^ "Encoding Standard § 4.2. Names and labels". WHATWG. Retrieved 2018-04-29.
  11. ^ "Character Sets". Internet Assigned Numbers Authority. 2013-01-23. Retrieved 2013-02-08.
  12. ^ Liviu (2014-02-07). "UTF-8 codepage 65001 in Windows 7 - part I". Retrieved 2018-01-30. Previously under XP (and, unverified, but probably Vista, too) for loops simply did not work while codepage 65001 was active
  13. ^ "MySQL :: MySQL 8.0 Reference Manual :: 10.9.1 The utf8mb4 Character Set (4-Byte UTF-8 Unicode Encoding)". MySQL 8.0 Reference Manual. Oracle Corporation. Retrieved 2023-03-14.
  14. ^ a b "MySQL :: MySQL 8.0 Reference Manual :: 10.9.2 The utf8mb3 Character Set (3-Byte UTF-8 Unicode Encoding)". MySQL 8.0 Reference Manual. Oracle Corporation. Retrieved 2023-02-24.
  15. ^ "HP PCL Symbol Sets Printer Control Language (PCL & PXL) Support Blog". 2015-02-19. Archived from the original on 2015-02-19. Retrieved 2018-01-30.
  16. ^ "Database Globalization Support Guide". docs.oracle.com. Retrieved 2023-03-16.
  17. ^ "BOM". suikawiki (in Japanese). Archived from the original on 2009-01-17.
  18. ^ Davis, Mark. "Forms of Unicode". IBM. Archived from the original on 2005-05-06. Retrieved 2013-09-18.
  19. ^ "Apple Developer Documentation". developer.apple.com. Retrieved 2021-03-15.
  20. ^ "Chapter 3" (PDF), The Unicode Standard, p. 54
  21. ^ "Chapter 3" (PDF), The Unicode Standard, p. 55
  22. ^ "Chapter 3" (PDF), The Unicode Standard, p. 55
  23. ^ a b c Yergeau, F. (November 2003). UTF-8, a transformation format of ISO 10646. IETF. doi:10.17487/RFC3629. STD 63. RFC 3629. Retrieved August 20, 2020.
  24. ^ "Chapter 3" (PDF), The Unicode Standard, p. 54
  25. ^ "Chapter 3" (PDF), The Unicode Standard, p. 55
  26. ^ Marin, Marvin (2000-10-17). "Web Server Folder Traversal MS00-078".
  27. ^ "Summary for CVE-2008-2938". National Vulnerability Database.
  28. ^ "PEP 529 -- Change Windows filesystem encoding to UTF-8". Python.org. Retrieved 2022-05-10. This PEP proposes changing the default filesystem encoding on Windows to utf-8, and changing all filesystem functions to use the Unicode APIs for filesystem paths. [..] can correctly round-trip all characters used in paths (on POSIX with surrogateescape handling; on Windows because str maps to the native representation). On Windows bytes cannot round-trip all characters used in paths
  29. ^ "DataInput (Java Platform SE 8)". docs.oracle.com. Retrieved 2021-03-24.
  30. ^ "Non-decodable Bytes in System Character Interfaces". python.org. 2009-04-22. Retrieved 2014-08-13.
  31. ^ "Unicode 6.0.0".
  32. ^ 128 1바이트, (16+5)×642바이트, 5×64×64 3바이트.각 연속 바이트에 대해 더 정밀한 테스트를 수행하는 경우 다소 적을 수 있습니다.
  33. ^ a b c von Löwis, Martin (2009-04-22). "Non-decodable Bytes in System Character Interfaces". Python Software Foundation. PEP 383.
  34. ^ "Chapter 2" (PDF), The Unicode Standard - Version 15.0.0, p. 39
  35. ^ "UTF-8 and Unicode FAQ for Unix/Linux".
  36. ^ Davis, Mark (2012-02-03). "Unicode over 60 percent of the web". Official Google blog. Archived from the original on 2018-08-09. Retrieved 2020-07-24.
  37. ^ Davis, Mark (2008-05-05). "Moving to Unicode 5.1". Official Google Blog. Retrieved 2023-03-13.
  38. ^ "Usage statistics and market share of ASCII for websites, October 2021". w3techs.com. Retrieved 2020-10-01.
  39. ^ Bray, Tim (December 2017). Bray, T. (ed.). The JavaScript Object Notation (JSON) Data Interchange Format. IETF. doi:10.17487/RFC8259. RFC 8259. Retrieved 16 February 2018.
  40. ^ "Usage of Internet mail in the world characters". washingtonindependent.com. 1998-08-01. Retrieved 2007-11-08.
  41. ^ "Encoding Standard". encoding.spec.whatwg.org. Retrieved 2018-11-15.
  42. ^ "Specifying the document's character encoding". HTML 5.2 (Report). World Wide Web Consortium. 14 December 2017. Retrieved 2018-06-03.
  43. ^ "Choose text encoding when you open and save files". support.microsoft.com. Retrieved 2021-11-01.
  44. ^ "utf 8 - Character encoding of Microsoft Word DOC and DOCX files?". Stack Overflow. Retrieved 2021-11-01.
  45. ^ "Exporting a UTF-8 .txt file from Word".
  46. ^ "excel - Are XLSX files UTF-8 encoded by definition?". Stack Overflow. Retrieved 2021-11-01.
  47. ^ "How to open UTF-8 CSV file in Excel without mis-conversion of characters in Japanese and Chinese language for both Mac and Windows?". answers.microsoft.com. Retrieved 2021-11-01.
  48. ^ "How can I make Notepad to save text in UTF-8 without the BOM?". Stack Overflow. Retrieved 2021-03-24.
  49. ^ Galloway, Matt (October 2012). "Character encoding for iOS developers. Or, UTF-8 what now?". www.galloway.me.uk. Retrieved 2021-01-02. in reality, you usually just assume UTF-8 since that is by far the most common encoding.
  50. ^ "Windows 10 Notepad is getting better UTF-8 encoding support". BleepingComputer. Retrieved 2021-03-24. Microsoft is now defaulting to saving new text files as UTF-8 without BOM, as shown below.
  51. ^ "Customize the Windows 11 Start menu". docs.microsoft.com. Retrieved 2021-06-29. Make sure your LayoutModification.json uses UTF-8 encoding.
  52. ^ "JEP 400: UTF-8 by default". openjdk.java.net. Retrieved 2022-03-30.
  53. ^ "Feature #16604: Set default for Encoding.default_external to UTF-8 on Windows". bugs.ruby-lang.org. Ruby master – Ruby Issue Tracking System. Retrieved 2022-08-01.
  54. ^ "Feature #12650: Use UTF-8 encoding for ENV on Windows". bugs.ruby-lang.org. Ruby master – Ruby Issue Tracking System. Retrieved 2022-08-01.
  55. ^ "New features in R 4.2.0". The Jumping Rivers Blog. R bloggers. 2022-04-01. Retrieved 2022-08-01.
  56. ^ "PEP 540 – add a new UTF-8 mode". peps.python.org. Retrieved 2022-09-23.
  57. ^ "PEP 686 – Make UTF-8 mode default peps.python.org". peps.python.org. Retrieved 2023-07-26.
  58. ^ "PEP 597 – add optional EncodingWarning". Python.org. Retrieved 2021-08-24.
  59. ^ "Support for UTF-8 as a portable source file encoding" (PDF).
  60. ^ a b "PEP 393 – Flexible String Representation". Python.org. Retrieved 2022-05-18. As interaction with other libraries will often require some sort of internal representation, the specification chooses UTF-8 as the recommended way of exposing strings to C code. [..] The data and utf8 pointers point to the same memory if the string uses only ASCII characters (using only Latin-1 is not sufficient). [..] The recommended way to create a Unicode object is to use the function PyUnicode_New [..] A new function PyUnicode_AsUTF8 is provided to access the UTF-8 representation.
  61. ^ "Source code representation". The Go Programming Language Specification. golang.org (Report). Retrieved 2021-02-10.
  62. ^ Tsai, Michael J. (21 March 2019). "UTF-8 string in Swift 5" (blog). Retrieved 2021-03-15. Switching to UTF-8 fulfills one of string's long-term goals, to enable high-performance processing, [...] also lays the groundwork for providing even more performant APIs in the future.
  63. ^ "PyPy v7.1 released; now uses UTF-8 internally for Unicode strings". Mattip. PyPy status blog. 2019-03-24. Retrieved 2020-11-21.
  64. ^ "Unicode Objects and Codecs". Python documentation. Retrieved 2023-08-19. UTF-8 representation is created on demand and cached in the Unicode object.
  65. ^ "PEP 623 – remove wstr from Unicode". Python.org. Retrieved 2020-11-21. Until we drop [the] legacy Unicode object, it is very hard to try other Unicode implementation[s], like UTF-8 based implementation in PyPy.
  66. ^ Wouters, Thomas (2023-07-11). "Python Insider: Python 3.12.0 beta 4 released". Python Insider. Retrieved 2023-07-26. The deprecated wstr and wstr_length members of the C implementation of unicode objects were removed, per PEP 623.
  67. ^ "/validate-charset (validate for compatible characters)". docs.microsoft.com. Retrieved 2021-07-19. Visual Studio uses UTF-8 as the internal character encoding during conversion between the source character set and the execution character set.
  68. ^ "Introducing UTF-8 support for SQL Server". techcommunity.microsoft.com. 2019-07-02. Retrieved 2021-08-24. For example, changing an existing column data type from NCHAR(10) to CHAR(10) using an UTF-8 enabled collation, translates into nearly 50% reduction in storage requirements. [..] In the ASCII range, when doing intensive read/write I/O on UTF-8, we measured an average 35% performance improvement over UTF-16 using clustered tables with a non-clustered index on the string column, and an average 11% performance improvement over UTF-16 using a heap.
  69. ^ "Use the Windows UTF-8 code page – UWP applications". docs.microsoft.com. Retrieved 2020-06-06. As of Windows version 1903 (May 2019 update), you can use the ActiveCodePage property in the appxmanifest for packaged apps, or the fusion manifest for unpackaged apps, to force a process to use UTF-8 as the process code page. [...] CP_ACP equates to CP_UTF8 only if running on Windows version 1903 (May 2019 update) or above and the ActiveCodePage property described above is set to UTF-8. Otherwise, it honors the legacy system code page. We recommend using CP_UTF8 explicitly.
  70. ^ "Appendix F. FSS-UTF / File System Safe UCS Transformation format" (PDF). The Unicode Standard 1.1. Archived (PDF) from the original on 2016-06-07. Retrieved 2016-06-07.
  71. ^ Whistler, Kenneth (2001-06-12). "FSS-UTF, UTF-2, UTF-8, and UTF-16". Archived from the original on 2016-06-07. Retrieved 2006-06-07.
  72. ^ a b Pike, Rob (2003-04-30). "UTF-8 history". Retrieved 2012-09-07.
  73. ^ Pike, Rob (2012-09-06). "UTF-8 turned 20 years old yesterday". Retrieved 2012-09-07.
  74. ^ ISO/IEC 10646:2014 §9.1, 2014.
  75. ^ 유니코드 표준, 버전 15.0 §3.9 D92, §3.10 D95, 2021.
  76. ^ 유니코드 표준 부속서 #27: 유니코드 3.1, 2001
  77. ^ 유니코드 표준, 버전 5.0 §3.9§3.10 ch. 3, 2006.
  78. ^ 유니코드 표준, 버전 6.0 §3.9 D92, §3.10 D95, 2010.
  79. ^ McGowan, Rick (2011-12-19). "Compatibility Encoding Scheme for UTF-16: 8-Bit (CESU-8)". Unicode Consortium. Unicode Technical Report #26.
  80. ^ "Character Set Support". Oracle Database 19c Documentation, SQL Language Reference. Oracle Corporation.
  81. ^ "Supporting Multilingual Databases with Unicode § Support for the Unicode Standard in Oracle Database". Database Globalization Support Guide. Oracle Corporation.
  82. ^ "8.2.2.3. Character encodings". HTML 5.1 Standard. W3C.
  83. ^ "8.2.2.3. Character encodings". HTML 5 Standard. W3C.
  84. ^ "12.2.3.3 Character encodings". HTML Living Standard. WHATWG.
  85. ^ "Java SE documentation for Interface java.io.DataInput, subsection on Modified UTF-8". Oracle Corporation. 2015. Retrieved 2015-10-16.
  86. ^ "The Java Virtual Machine Specification, section 4.4.7: "The CONSTANT_Utf8_info Structure"". Oracle Corporation. 2015. Retrieved 2015-10-16.
  87. ^ "Java Object Serialization Specification, chapter 6: Object Serialization Stream Protocol, section 2: Stream Elements". Oracle Corporation. 2010. Retrieved 2015-10-16.
  88. ^ "Java Native Interface Specification, chapter 3: JNI Types and Data Structures, section: Modified UTF-8 Strings". Oracle Corporation. 2015. Retrieved 2015-10-16.
  89. ^ "The Java Virtual Machine Specification, section 4.4.7: "The CONSTANT_Utf8_info Structure"". Oracle Corporation. 2015. Retrieved 2015-10-16.
  90. ^ "ART and Dalvik". Android Open Source Project. Archived from the original on 2013-04-26. Retrieved 2013-04-09.
  91. ^ "UTF-8 bit by bit". Tcler's Wiki. 2001-02-28. Retrieved 2022-09-03.
  92. ^ Sapin, Simon (2016-03-11) [2014-09-25]. "The WTF-8 encoding". Archived from the original on 2016-05-24. Retrieved 2016-05-24.
  93. ^ Sapin, Simon (2015-03-25) [2014-09-25]. "The WTF-8 encoding § Motivation". Archived from the original on 2020-08-16. Retrieved 2020-08-26.
  94. ^ "WTF-8.com". 2006-05-18. Retrieved 2016-06-21.
  95. ^ Speer, Robyn (2015-05-21). "ftfy (fixes text for you) 4.0: changing less and fixing more". Archived from the original on 2015-05-30. Retrieved 2016-06-21.
  96. ^ "WTF-8, a transformation format of code page 1252". Archived from the original on 2016-10-13. Retrieved 2016-10-12.
  97. ^ "PEP 540 -- Add a new UTF-8 Mode". Python.org. Retrieved 2021-03-24.
  98. ^ "RTFM optu8to16(3), optu8to16vis(3)". www.mirbsd.org.
  99. ^ a b Davis, Mark; Suignard, Michel (2014). "3.7 Enabling Lossless Conversion". Unicode Security Considerations. Unicode Technical Report #36.

외부 링크