UTF-16

UTF-16
UTF-16
처음 2개의16 유니코드 코드 포인트.아래쪽의 흰색 줄무늬는 UTF-16이 사용하는 대리모입니다.
언어국제
표준.유니코드 표준
분류유니코드 변환 형식, 가변 너비 인코딩
확장자드UCS-2
변환 / 부호화ISO/IEC 10646 (유니코드)

UTF-16(16비트 유니코드 변환 형식)은 유니코드의 유효한 코드 포인트 1,112,064개를 모두 인코딩할 수 있는 문자 인코딩입니다(실제로 이 코드 포인트의 수는 UTF-16의 설계에 의해 지시됩니다).코드 포인트가 하나 또는 두 개의 16비트 코드 단위로 인코딩되기 때문에 인코딩은 가변 길이입니다.UTF-16은 UCS-2(2바이트 범용 문자 집합의 경우)로 알려진 이전의 고정 너비 16비트 인코딩에서 비롯되었습니다16.[1]

UTF-16은 마이크로소프트 윈도우 API, 자바 프로그래밍 언어, 자바스크립트/ECM스크립트와 같은 시스템에서 사용됩니다.Microsoft Windows에서 일반 텍스트 및 워드 프로세싱 데이터 파일에 사용되기도 합니다.SMS에 의해 사용됩니다(SMS 표준에는 UCS-2가 명시되어 있지만, 거의 모든 사용자가 실제로 UTF-16을 구현하여 이모지가 작동합니다).[citation needed]

UTF-16은 ASCII와[2][nb 1] 호환되지 않고 웹에서 인기를 얻지 못한 유일한 웹 인코딩으로, 웹 페이지의 0.002% 미만이[4] 선언했습니다.[5][6]반면 UTF-8은 전체 웹 페이지의 98%를 차지합니다.[7]WHATWG(Web Hypertext Application Technology Working Group)는 UTF-8을 "모든 [text]에 대한 필수 인코딩"으로 간주하며, 보안상 브라우저 응용프로그램은 UTF-16을 사용하지 않아야 합니다.[8]

역사

1980년대 후반에, 이전의 언어별 인코딩을 하나의 조정된 시스템으로 대체할 "유니버설 문자 집합"(UCS)을 위한 균일한 인코딩을 개발하는 작업이 시작되었습니다.목표는 과학, 수학, 음악과 같은 기술적인 영역의 기호뿐만 아니라 세계 대부분의 언어에서 필요한 모든 문자를 포함하는 것이었습니다.원래 아이디어는 문자당 1바이트가 필요한 일반적인 256자 인코딩을 문자당 2바이트(16비트)가 필요한 65,536(216) 값을 사용하는 인코딩으로 대체하는 것이었습니다.

ISO/IEC JTC 1/SC 2와 유니코드 컨소시엄이라는 두 그룹이 이 작업을 병행했습니다. 후자는 대부분 컴퓨팅 장비 제조업체를 대표합니다.두 그룹은 개발 중인 인코딩이 상호 호환될 수 있도록 캐릭터 할당을 동기화하려고 시도했습니다.초기 2바이트 인코딩은 원래 "유니코드"라고 불렸지만, 현재는 "UCS-2"라고 불립니다.[9]

2자로는16 충분하지 않다는 것이 점점 더 분명해지자,[1] IEEE는 더 큰 31비트 공간과 1자당 4바이트가 필요한 인코딩(UCS-4)을 도입했습니다.유니코드 컨소시엄은 문자당 4바이트로 인해 메모리와 디스크 공간이 많이 낭비되었고, 일부 제조업체는 문자당 2바이트 기술에 이미 많은 투자를 하고 있었기 때문에 이에 저항했습니다.UTF-16 부호화 방식은 절충안으로 개발되어 1996년 7월 유니코드 표준 버전 2.0과 함께 도입되었습니다.[10]IETF에 의해 2000년에 발표된 RFC 2781에 완전히 명시되어 있습니다.[11][12]

UTF-16 인코딩에서, 2보다16 작은 코드 포인트들은 이전의 UCS-2에서처럼 코드 포인트의 수치와 동일한 단일 16비트 코드 유닛으로 인코딩됩니다.216 이상의 최신 코드 포인트는 두 개의 16비트 코드 단위를 사용하여 복합 값으로 인코딩됩니다.이 두 개의 16비트 코드 유닛은 UTF-16 대리 범위 0xD800–0xDF에서 선택됩니다.이전에는 캐릭터에 할당되지 않았던 FF.이 범위의 값은 문자로 사용되지 않으며 UTF-16은 개별 코드 포인트로 코드화하는 법적 방법을 제공하지 않습니다.따라서 UTF-16 스트림은 BMP(기본 다국어 평면)의 코드 포인트에 대한 대리 범위 밖의 단일 16비트 코드 포인트와 BMP 이상의 코드 포인트에 대한 대리 범위 내의 16비트 값 쌍으로 구성됩니다.

UTF-16은 국제 표준 ISO/IEC 10646과 유니코드 표준의 최신 버전에 명시되어 있습니다."UCS-2는 이제 더 이상 쓸모가 없는 것으로 여겨져야 합니다.더 이상 10646 또는 유니코드 표준의 인코딩 형식을 참조하지 않습니다."[13] UTF-16은 더 많은 수의 코드 포인트를 지원하거나 대리 코드 포인트로 대체된 코드 포인트를 지원하기 위해 결코 확장되지 않습니다. 이는 일반 범주 또는 대리 코드 포인트에 대한 유니코드 안정성 정책을 위반하는 것이기 때문입니다.[14](자체 동기화 코드로 남아있는 방식은 시퀀스를 시작하기 위해 적어도 하나의 BMP 코드 포인트를 할당해야 합니다.코드 포인트의 용도를 변경하는 것은 허용되지 않습니다.

묘사

각 유니코드 코드 포인트는 하나 또는 두 개의 16비트 코드 단위로 인코딩됩니다.이러한 16비트 코드가 바이트로 저장되는 방법은 텍스트 파일 또는 통신 프로토콜의 엔디안(endian) 여부에 따라 달라집니다.

"문자"를 기록하려면 최소 2바이트에서[15] 14바이트 또는 그 이상의 바이트가 필요할 수 있습니다.예를 들어 이모지 플래그 문자는 "유니코드 스칼라 값 쌍으로 구성"[16]되므로 8바이트가 소요됩니다(이 값들은 BMP 외부에 있으며 각각 4바이트가 필요합니다).

U+0000 - U+D7FF 및 U+E000 - U+FFFFF

U+D800 ~ U+DFFF는 특별한 목적을 가지고 있으며, 아래를 참조하십시오.

UTF-16 및 UCS-2 모두 이 범위의 코드 포인트를 해당 코드 포인트와 수치적으로 동일한 단일 16비트 코드 유닛으로 인코딩합니다.기본 다국어 평면(BMP)의 이러한 코드 포인트는 UCS-2에서 표현할 수 있는 유일한 코드 포인트입니다.[citation needed] 유니코드 9.0 현재 일부 현대 비 라틴 아시아, 중동 및 아프리카 스크립트는 대부분의 이모지 문자와 마찬가지로 이 범위에 속합니다.

U+010000에서 U+10FFFF까지의 코드 포인트

다른 평면의 코드 포인트는 대리쌍이라고 불리는 두 개의 16비트 코드 단위로 인코딩됩니다.첫 번째 코드 단위는 높은 대리자이고 두 번째 코드 단위는 낮은 대리자입니다(이들은 UTF-8의 선두 바이트와 후행 바이트와 유사하게 각각 "선두" 및 "후행" 대리자라고도 함).[17]

UTF-16 디코더
낮은
높은
DC00 DC01 ... DFFF
D800 010000 010001 ... 0103FF
D801 010400 010401 ... 0107FF
⋮ ⋮ ⋮ ⋱ ⋮
DBFF 10FC00 10FC01 ... 10FFFFF
  • 0x10000은 코드 포인트(U)에서 차감되며, 20비트 숫자(U')는 16진수 범위 0x00000–0x에 남습니다.FFFFF.
  • 상위 10비트(0x000–0x3 범위)FF)를 0xD800에 추가하여 0xD800–0xDB 범위에 있는 첫 번째 16비트 코드 단위 또는 높은 대리자(W1)를 제공합니다.FF.
  • 낮은 10비트(또한 0x000–0x3 범위)FF)를 0xDC00에 추가하여 두 번째 16비트 코드 단위 또는 로우 대리(W2)를 제공합니다. 이 단위는 0xDC00–0xDFFF 범위입니다.

시각적으로 볼 때, W1과 W2 사이의 U' 분포는 다음과 같습니다.[18]

U' = yyyyyyyyxxxxxxxxxxxxxxxxxx/ U - 0x10000 W1 = 110110110yyyyyyy// 0xD800 + yyyyyyw2 = 110111xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.

높은 대리모의 범위(0xD800–0xDB)이기 때문에FF), 낮은 대용치(0xDC00–0xDFFF) 및 유효한 BMP 문자(0x0000–0xD7)FF, 0xE000–0xFFFF)는 서로소이고 대리인이 BMP 문자와 일치하거나 두 개의 인접 코드 유닛이 법적 대리인 쌍처럼 보이는 것은 불가능합니다.이렇게 하면 검색이 매우 간단해집니다.또한 UTF-16은 16비트 워드에서 자체 동기화를 수행하고 있음을 의미합니다. 코드 유닛이 문자를 시작하는지 여부는 이전 코드 유닛을 조사하지 않고도 확인할 수 있습니다(즉, 코드 유닛의 유형은 코드 유닛이 속하는 값의 범위에 따라 결정할 수 있음).UTF-8은 이러한 장점을 공유하지만 이전의 많은 멀티바이트 인코딩 방식(Shift JIS 및 기타 아시아 멀티바이트 인코딩 등)은 모호하지 않은 검색을 허용하지 않으며 문자열의 시작부터 다시 구문 분석해야 동기화할 수 있습니다.UTF-16은 하나의 바이트가 손실되거나 임의의 바이트에서 순회가 시작되는 경우 자체 동기화되지 않습니다.

가장 일반적으로 사용되는 문자는 모두 BMP에 포함되어 있기 때문에 대리쌍의 처리는 철저하게 테스트되지 않는 경우가 많습니다.이로 인해 인기 있고 잘 검토된 애플리케이션 소프트웨어(예: CVE-)에서도 지속적인 버그와 잠재적인 보안 구멍이 발생할 수 있습니다.2008-2938, CVE-2012-2135).

U+D800에서 U+DFFF(대리점)까지

공식 유니코드 표준은 UTF-16을 포함한 어떤 UTF 형식도 대리 코드 포인트를 인코딩할 수 없다고 말합니다.문자가 할당되지 않으므로 암호화할 이유가 없습니다.그러나 Windows(윈도우)에서는 파일 이름[19] 및 기타 장소에서 짝을 이루지 않은 대리 대리인을 허용하므로 일반적으로 유니코드 표준에서 제외되더라도 소프트웨어에서 지원해야 합니다.

UCS-2, UTF-8 및 UTF-32는 이러한 코드 포인트를 사소하고 명백한 방식으로 인코딩할 수 있으며, 표준에서는 이러한 배열을 인코딩 오류로 처리해야 한다고 명시하고 있지만, 많은 양의 소프트웨어가 이러한 코드 포인트를 인코딩합니다.

코드 포인트와 동일한 코드 유닛을 사용하여 UTF-16 형식으로 쌍을 이루지 않은 대리 코드 포인트(높은 대리 코드 포인트 뒤에 낮은 코드 포인트 또는 높은 코드 포인트 뒤에 있지 않은 낮은 코드 포인트)를 명확하게 인코딩할 수 있습니다.그 결과는 유효하지 않지만, 대부분의 UTF-16 인코더 및 디코더 구현은 인코딩 간의 변환을 수행합니다.[citation needed]

예

U+10437(𐐷)을 UTF-16으로 인코딩하려면:

  • 코드 포인트에서 0x10000을 뺀 후 0x0437을 남깁니다.
  • 대리모가 높은 경우 오른쪽으로 10씩 이동한 다음(divide는 0x400) 0xD800을 추가하면 0x0001 + 0xD800 = 0xD801이 됩니다.
  • 낮은 대리수의 경우 낮은 10비트(0x400으로 나누는 remainder)를 취한 다음 0xDC00을 더하면 0x0037 + 0xDC00 = 0xDC37이 됩니다.

UTF-16에서 U+10437(𐐷)을 디코딩하려면:

  • 높은 대리인(0xD801)을 구하고 0xD800을 뺀 다음 0x400을 곱하면 0x0001 × 0x400 = 0x0400이 됩니다.
  • 낮은 대리점(0xDC37)을 구하고 0xDC00을 빼면 0x37이 됩니다.
  • 이 두 결과를 함께 더하면 (0x0437), 마지막으로 0x10000을 더하면 최종 코드 포인트인 0x10437을 얻을 수 있습니다.

다음 표에는 이 변환과 기타 변환이 요약되어 있습니다.색상은 코드 포인트의 비트가 UTF-16 바이트 사이에서 어떻게 분배되는지 나타냅니다.UTF-16 인코딩 프로세스에 의해 추가된 추가 비트는 검은색으로 표시됩니다.

성격 이진 코드 포인트 이진 UTF-16 UTF-16 육각형
코드 단위		 UTF-16BE
16진수 바이트		 UTF-16LE
16진수 바이트
$ U+0024 0000 0000 0010 0100 0000 0000 0010 0100 0024 00 24 24 00
€ U+20AC 0010 0000 1010 1100 0010 0000 1010 1100 20AC 20 AC AC 20
𐐷 U+10437 0001 0000 0100 0011 0111 1101 1000 0000 0001 1101 1100 0011 0111 D801 DC37 D8 01 DC 37 01 D8 37 DC
𤭢 U+24B62 0010 0100 1011 0110 0010 1101 1000 0101 0010 1101 1111 0110 0010 D852 DF62 D8 52 DF 62 52 D8 62 DF

바이트 순서 인코딩 방식

UTF-16 및 UCS-2는 일련의 16비트 코드 유닛을 생성합니다.대부분의 통신 및 저장 프로토콜은 바이트에 대해 정의되며 따라서 각 유닛은 2개의 8비트 바이트를 사용하므로, 바이트의 순서는 컴퓨터 아키텍처의 엔디안니스(바이트 순서)에 따라 달라질 수 있습니다.

UTF-16은 코드 단위의 바이트 순서를 인식하는 데 도움을 주기 위해 U+FEFF 값을 가진 코드 포인트인 바이트 순서 표시(BOM)를 첫 번째 실제 코드 값 앞에 배치합니다.[nb 2](U+FEFF는 눈에 보이지 않는 0폭 비파괴 공간/Z입니다.WNBSP 문자.)[nb 3]디코더의 엔디안 아키텍처가 인코더의 엔디안 아키텍처와 일치하는 경우, 디코더는 0xFEFF 값을 감지하지만, 반대 엔디안 디코더는 BOM을 이 목적을 위해 예약된 비문자 값 U+FFE로 해석합니다.이 잘못된 결과는 나머지 값에 대해 바이트 스왑을 수행할 힌트를 제공합니다.

BOM이 누락된 경우 RFC 2781은 BE(big-endian) 인코딩을 가정할 것을 권장합니다[nb 4].실제로 Windows에서 기본적으로 LE(Little-endian) 순서를 사용하기 때문에 많은 응용 프로그램에서 LE(Little-endian) 인코딩을 가정합니다.또한 U+0100 이하의 문자가 매우 일반적이라는 가정하에 널 바이트를 찾아 엔디안니스를 감지하는 것도 안정적입니다.0에서 시작하는 짝수 바이트가 더 많으면 빅 엔디안이 됩니다.

표준은 또한 UTF-16BE 또는 UTF-16LE를 인코딩 유형으로 지정하여 바이트 순서를 명시적으로 명시할 수 있도록 합니다.바이트 순서가 이런 방식으로 명시적으로 지정된 경우 BOM은 텍스트 앞에 붙이지 않아야 하며 처음에 U+FEFF를 ZWNBSP 문자로 처리해야 합니다.대부분의 응용 프로그램은 이 규칙에도 불구하고 모든 경우에 BOM을 무시합니다.

인터넷 프로토콜의 경우, IANA는 "UTF-16", "UTF-16BE" 및 "UTF-16LE"을 이러한 인코딩의 이름으로 승인했습니다(이름은 대소문자 구분 없음).별칭 UTF_16 또는 UTF16은 일부 프로그래밍 언어 또는 소프트웨어 응용 프로그램에서 의미가 있을 수 있지만 인터넷 프로토콜에서는 표준 이름이 아닙니다.

유사한 명칭인 UCS-2BE 및 UCS-2LE는 UCS-2 버전을 표시하는 데 사용됩니다.

크기

UTF-16은 UTF-8에서 3 바이트를 사용하는 문자에 2 바이트를 사용하기 때문에 동아시아 언어의 경우 UTF-8보다 공간 효율적이라고 종종 주장됩니다. 실제 텍스트에는 UTF-8에서 1 바이트만 사용되는 숫자, 구두점, 마크업(예: 웹 페이지) 및 제어 문자가 많이 포함되어 있기 때문에,이것은 인공적으로 구성된 밀집한 텍스트 블록에만 해당됩니다.[citation needed]데바나가리와 벵골어는 더 심각한 주장을 할 수 있는데, 데바나가리는 여러 글자의 단어를 사용하고 모든 글자는 UTF-8에서는 3바이트, UTF-16에서는 2바이트만 사용합니다.

또한 중국어 유니코드 인코딩 표준 GB 18030은 항상 중국어 뿐만 아니라 모든 언어에 대해 UTF-16보다 작은 크기의 파일을 생성합니다.

사용.

UTF-16은 윈도우 10을 포함하여 현재 지원되는 모든 마이크로소프트 윈도우 버전(최소한 윈도우 CE/2000/XP/2003/비스타/7[20] 이후)의 OS API의 텍스트에 사용됩니다.Windows XP(윈도우 XP)에서는 유럽 언어용 Windows(윈도우)와 함께 제공되는 글꼴에 U+FFFF 이상의 코드 포인트가 포함되지 않습니다.[21][22]이전 Windows NT 시스템(Windows 2000 이전)은 UCS-2만 지원합니다.[23] 파일과 네트워크 데이터는 UTF-16, UTF-8 및 레거시 바이트 인코딩이 혼합된 경향이 있습니다.

윈도우 XP에 대해서도 UTF-8 지원이 있었지만, 윈도우 10 내부 빌드 17035와 2019년 5월 업데이트에서 개선되었습니다.[24]2019년 5월부터 마이크로소프트는 다른 8비트 인코딩 대신 윈도우와 엑스박스에서 UTF-8을 사용할 것을 권장하고 있습니다.[25]UTF-16보다 UTF-8을 사용할 것을 권고하는지는 불분명하지만, "UTF-16 [...]은 여러 플랫폼을 대상으로 하는 코드에 Windows가 부여하는 고유한 부담입니다."[26]라고 명시하고 있습니다.

IBM i 운영 체제는 UCS-2 인코딩의 경우 CCSID(코드 페이지) 13488을 지정하고 UTF-16 인코딩의 경우 CCSID 1200을 지정합니다.[27]

UTF-16은 Qualcomm BREW 운영 체제에서 사용됩니다.NET 환경; 및 Qt 크로스 플랫폼 그래픽 위젯 툴킷.

노키아 S60 단말기와 소니에릭슨 UIQ 단말기에 사용되는 심비안 OS는 UCS-2를 사용합니다. 아이폰 단말기는 3GPP TS 23.038(GSM) 및 IS-637(CDMA) 표준에 명시된 UCS-2 대신 단문 메시지 서비스를 위한 UTF-16을 사용합니다.[28]

CD-ROM 미디어에 사용되는 Joliet 파일 시스템은 UCS-2BE (파일 이름당 최대 64자의 유니코드 문자)를 사용하여 파일 이름을 인코딩합니다.

파이썬 버전 2.0은 공식적으로 UCS-2를 내부적으로만 사용했지만, UTF-8 디코더에서 "유니코드"가 나온 것은 정확한 UTF-16입니다.또한 파이썬을 컴파일할 수 있는 기능도 있어서 내부적으로 UTF-32를 사용하기도 했는데, 이는 유닉스에서 수행되기도 했습니다.Python 3.3은 문자열에서 가장 큰 코드 포인트에 따라 ISO-8859-1, UCS-2 또는 UTF-32 중 하나를 사용하도록 내부 스토리지를 전환했습니다.[29]파이썬 3.12는 모든 문자열에 대해 UTF-8로 쉽게 마이그레이션할 수 있도록 일부 기능(CPython 확장용)을 삭제합니다.[30]

자바는 원래 UCS-2를 사용했으며, J2SE 5.0에서 UTF-16 보조 문자 지원을 추가했습니다.최근에는 UTF-8 이외의[31] 8비트 인코딩에 대한 덤핑 지원을 장려하고 있지만 내부적으로는 여전히 UTF-16이 사용되고 있습니다.

자바스크립트는 UCS-2 또는 UTF-16을 사용할 수 있습니다.[32]ES2015년부터, 문자열 방식과 정규 표현식 플래그는 인코딩에 구애받지 않는 관점에서 문자열을 처리할 수 있는 언어에 추가되었습니다.

애플이 선호하는 응용 프로그램 언어인 스위프트는 UTF-16을 사용하여 UTF-8로 전환된 버전 5까지 문자열을 저장했습니다.[33]

상당히 많은 언어가 문자열 객체의 인코딩 부분을 만들기 때문에 UTF-16을 포함한 많은 인코딩 집합을 저장하고 지원합니다.대부분의 사람들은 UTF-16과 UCS-2를 서로 다른 인코딩으로 생각합니다.예를 들어[34] PHP 언어와 MySQL이 있습니다.[35]

시스템이 내부적으로 사용하는 인코딩을 결정하는 방법은 단일 비 BMP 문자를 포함하는 문자열의 "길이"를 묻는 것입니다.길이가 2인 경우 UTF-16이 사용되고 있습니다.4는 UTF-8을 나타냅니다. 3 또는 6은 CESU-8을 나타낼 수 있습니다. 1은 UTF-32를 나타낼 수 있지만 언어가 "길이"를 측정하기 전에 문자열을 코드 포인트로 디코딩한다는 것을 나타낼 가능성이 높습니다.

많은 언어에서 따옴표로 묶은 문자열은 BMP가 아닌 문자를 따옴표로 묶는 새로운 구문이 필요합니다."\uXXXX" 구문은 명시적으로 4개의 16진수로 제한합니다.다음 예제는 비 BMP 문자 U+1D11E 𝄞MUSIC Symbol GCLEF에 대한 구문을 보여줍니다.

  • 가장 일반적인 (C++, C#, D 및 기타 여러 언어)는 다음과 같은 8개의 16진수를 가진 대문자 'U'입니다."\U0001D11E".[36]
  • Java 7 정규 표현식, ICU 및 Perl, 사용"\x{1D11E}".
  • ECMAScript 2015 (JavaScript) 용도"\u{1D11E}".
  • 다른 많은 경우(정규식 이외의 Java 등), [37]BMP가 아닌 문자를 얻을 수 있는 유일한 방법은 대리자 반을 개별적으로 입력하는 것입니다."\uD834\uDD1E".

참고 항목

메모들

  1. ^ 또한 UTF-32는 ASCII와 호환되지 않지만 웹 인코딩으로 나열되지는 않습니다.[3]
  2. ^ UTF-8 인코딩은 0xFE보다 엄격하게 작은 바이트 값을 생성하므로 BOM 시퀀스의 어느 바이트도 인코딩을 UTF-16으로 식별합니다(UTF-32가 예상되지 않는다고 가정).
  3. ^ BOM 대신 문자 ZWNBSP로 U+FEFF를 사용하는 것이 U+2060(WORD JOINER)을 위해 더 이상 사용되지 않습니다. unicode.org 의 Byte Order Mark(BOM) FAQ를 참조하십시오.그러나 응용 프로그램에서 초기 BOM을 문자로 해석하는 경우 ZWNBSP 문자가 보이지 않으므로 영향이 적습니다.
  4. ^ RFC 2781 섹션 4.3은 BOM이 없는 경우 "텍스트는 빅 엔디언으로 해석되어야 한다"고 말합니다.섹션 1.2에 따르면, "Should"라는 용어의 의미는 RFC 2119에 의해 규율됩니다.이 문서에서 섹션 3은 "... 특정 항목을 무시할 수 있는 타당한 이유가 특정 상황에서 존재할 수 있지만, 다른 경로를 선택하기 전에 전체적인 의미를 이해하고 신중하게 고려해야 합니다."라고 말합니다.

참고문헌

  1. ^ a b "What is UTF-16?". The Unicode Consortium. Unicode, Inc. Retrieved 29 March 2018.
  2. ^ "HTML Living Standard". w3.org. 2020-06-10. Archived from the original on 2020-09-08. Retrieved 2020-06-15. UTF-16 encodings are the only encodings that this specification needs to treat as not being ASCII-compatible encodings.
  3. ^ "Encoding Standard". encoding.spec.whatwg.org. Retrieved 2023-04-22.
  4. ^ "Usage Statistics of UTF-16 for Websites, June 2021". w3techs.com. Retrieved 2021-06-17.
  5. ^ "Web Technologies used by Fxblue.com". w3techs.com. Retrieved 2022-11-01.
  6. ^ "Web Technologies used by Jeffcopublicschools.org". w3techs.com. Retrieved 2022-11-01.
  7. ^ "Usage Statistics of UTF-8 for Websites, November 2021". w3techs.com. Retrieved 2021-11-10.
  8. ^ "Encoding Standard". encoding.spec.whatwg.org. Retrieved 2018-10-22. The UTF-8 encoding is the most appropriate encoding for interchange of Unicode, the universal coded character set. Therefore for new protocols and formats, as well as existing formats deployed in new contexts, this specification requires (and defines) the UTF-8 encoding. [..] The problems outlined here go away when exclusively using UTF-8, which is one of the many reasons that UTF-8 is now the mandatory encoding for all text things on the Web.
  9. ^ "MySQL :: MySQL 5.7 Reference Manual :: 10.1.9.4 The ucs2 Character Set (UCS-2 Unicode Encoding)". dev.mysql.com.
  10. ^ "Questions about encoding forms". Retrieved 2010-11-12.
  11. ^ ISO/IEC 10646:2014 "정보 기술 – 범용 부호화 문자 집합(UCS)" 섹션 9 및 10.
  12. ^ 유니코드 표준 버전 7.0 (2014) 섹션 2.5.
  13. ^ "The Unicode® Standard Version 10.0 – Core Specification. Appendix C Relationship to ISO/IEC 10646" (PDF). Unicode Consortium. Archived (PDF) from the original on 2022-10-09. 섹션 C.2 페이지 913 (pdf 페이지 10)
  14. ^ "Unicode Character Encoding Stability Policies". unicode.org.
  15. ^ "It's not wrong that "🤦🏼♂️".length == 7". hsivonen.fi. Retrieved 2021-03-15.
  16. ^ "Apple Developer Documentation". developer.apple.com. Retrieved 2021-03-15.
  17. ^ Allen, Julie D.; Anderson, Deborah; Becker, Joe; Cook, Richard, eds. (2014). "3.8 Surrogates" (PDF). The Unicode Standard, Version 7.0—Core Specification. Mountain View: The Unicode Consortium. p. 118. Archived (PDF) from the original on 2022-10-09. Retrieved 3 November 2014.
  18. ^ Yergeau, Francois; Hoffman, Paul (February 2000). "UTF-16, an encoding of ISO 10646". tools.ietf.org. Retrieved 2019-06-18.
  19. ^ "Maximum Path Length Limitation". Microsoft. 2022-07-18. Retrieved 2022-10-10. […] the file system treats path and file names as an opaque sequence of WCHARs
  20. ^ 유니코드(Windows).2011-03-08 검색 "이러한 기능은 Windows 운영 체제의 네이티브 유니코드 인코딩에 사용되는 UTF-16(와이드 문자) 인코딩(…)을 사용합니다."
  21. ^ "Unicode". microsoft.com. Retrieved 2009-07-20.
  22. ^ "Surrogates and Supplementary Characters". microsoft.com. Retrieved 2009-07-20.
  23. ^ "Description of storing UTF-8 data in SQL Server". microsoft.com. 7 December 2005. Retrieved 2008-02-01.
  24. ^ "[Updated] Patch for cmd.exe for windows xp for cp 65001 - Page 2 - DosTips.com". www.dostips.com. Retrieved 2021-06-17.
  25. ^ "Use UTF-8 code pages in Windows apps". learn.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.
  26. ^ "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.
  27. ^ "UCS-2 and its relationship to Unicode (UTF-16)". IBM. Retrieved 2019-04-26.
  28. ^ Selph, Chad (2012-11-08). "Adventures in Unicode SMS". Twilio. Archived from the original on 2012-11-09. Retrieved 2015-08-28.
  29. ^ "PEP 0393 – Flexible String Representation". Python.org. Retrieved 2015-05-29.
  30. ^ "PEP 623 – Remove wstr from Unicode peps.python.org". peps.python.org. Retrieved 2023-02-24.
  31. ^ "JEP 400: UTF-8 by Default". openjdk.org. Retrieved 2023-03-12.
  32. ^ "JavaScript's internal character encoding: UCS-2 or UTF-16? · Mathias Bynens".
  33. ^ "UTF-8 String". Swift.org. 2019-03-20. Retrieved 2020-08-20.
  34. ^ "PHP: Supported Character Encodings - Manual". php.net.
  35. ^ "MySQL :: MySQL 8.0 Reference Manual :: 10.9.2 The utf8mb3 Character Set (3-Byte UTF-8 Unicode Encoding)". dev.mysql.com. Retrieved 2023-02-24.
  36. ^ "ECMA-334: 9.4.1 Unicode escape sequences". en.csharp-online.net. Archived from the original on 2013-02-15.
  37. ^ 어휘 구조: 유니코드 탈출하기

외부 링크