UTF - 8 - 위키백과, 우리 모두의 백과사전 UTF - 8 위키백과, 우리 모두의 백과사전. 둘러보기로 가기 검색하러 가기 유니코드 부호화 형식 UTF - 7 UTF - 8 CESU - 8 UTF - 16 UTF - 32 UTF - EBCDIC SCSU 퓨니코드 GB18030 UCS 양방향 텍스트 BOM 한중일 통합 한자 유니코드 범위 목록 유니코드 정규화 유니코드와 HTML 유니코드와 전자 우편 유니코드 글꼴 v. d. e. h UTF - 8은 유니코드를 위한 가변 길이 문자 인코딩 방식 중 하나로, 켄 톰프슨과 롭 파이크가 만들었다. UTF - 8은 Universal Coded Character Set Transformation Format - 8 - bit 의 약자이다. 본래는 FSS - UTF ( File System Safe UCS / Unicode Transformation Format ) 라는 이름으로 제안되었다. UTF - 8 인코딩은 유니코드 한 문자를 나타내기 위해 1바이트에서 4바이트까지를 사용한다. 예를 들어서, U00부터 U007F 범위에 있는 ASCII 문자들은 UTF - 8에서 1바이트만으로 표시된다. 4바이트로 표현되는 문자는 모두 기본 다국어
사용한다. 예를 들어서, U00부터 U007F 범위에 있는 ASCII 문자들은 UTF - 8에서 1바이트만으로 표시된다. 4바이트로 표현되는 문자는 모두 기본 다국어 평면 ( BMP ) 바깥의 유니코드 문자이며, 거의 사용되지 않는다. UTF - 16과 UTF - 8 중 어느 인코딩이 더 적은 바이트를 사용하는지는 문자열에서 사용된 코드 포인트에 따라 달라지며, 실제로 DEFLATE와 같은 일반적인 압축 알고리즘을 사용할 경우 이 차이는 무시할 수 있을 정도이다. 이러한 압축 알고리즘을 사용하기 힘들고 크기가 중요할 경우 유니코드 표준 압축 방식 ( Standard Compression Scheme for Unicode ) 을 대신 사용할 수 있다. 목차 1 구조 2 변형된 UTF - 8 3 UTF - 8의 설계 원칙 4 오류 처리 5 장점과 단점 5. 1 일반적으로 5. 2 기존의 인코딩들과 비교했을 때 5. 3 UTF - 7과 비교했을 때 5. 4 UTF - 16과 비교했을 때 6 같이 보기 7 각주 8 외부 링크 구조 [ 편집 ] UTF - 8은 여러 표준 문서에서 다른 방법으로 정의되어 있지만, 일반적인 구조는 모두 동일하다고 볼 수 있다.
코딩과는 달리, UTF - 8은 ASCII와 호환되기 때문에 0x00이나 0x2f [UNK] 항상 U00과 U002F에 대응되므로 기존 API를 약간 수정해서 쓸 수 있다. UTF - 16은 바이트 순서를 나타내기 위하여 바이트 순서 문자 ( BOM, UFEFF ) 가 필요하지만, UTF - 8은 바이트 순서가 정해져 있기 때문에 BOM이 필요하지 않다. 단점 UTF - 8은 가변 길이 인코딩이며, 다른 문자는 다른 바이트 수로 표현될 수 있다. 사실 이 문제는 별로 심각한 것이 아니며, UTF - 8 문자열을 다루기 위한 추상적인 인터페이스를 만드는 것으로 해결될 수 있다. 실제로 기술적으로는 UTF - 16도 BMP 바깥 문자를 4바이트로 표현하기 때문에 가변 길이 인코딩이다. BMP에 들어 있는 한중일 문자들은 UTF - 8에서 3바이트로 표현되지만, UTF - 16에서는 2바이트로 표현된다. 따라서 UTF - 8에서는 이러한 문자를 표현하기 위하여 더 많은 바이트가 필요하며 UTF - 16과 비교할 때 최대 50 % 까지 크기가 늘 수 있다. 하지만 반대로 U00부터 U007F 사이의 글자들
상위 2비트가 항상 10이다. UTF - 8이 이런 성질을 가지도록 설계한 까닭은 어떤 경우에도 한 문자에 대한 바이트 표현이 다른 문자에 대한 바이트 표현의 일부가 되는 경우가 없도록 하기 위함이다. 따라서 텍스트 안에 들어 있는 다른 텍스트를 찾는 데 쓰이는 바이트 단위의 부문자열 매칭이 UTF - 8 문자열에서도 쓰일 수 있다. CP949, 상용 조합형, Shift - JIS, Big5과 같이 ISO 2022 체계에 부합하지 않는 이전의 가변 길이 인코딩은 그런 성질을 지니지 않았고 ( 기존 인코딩 가운데 EUC - KR이나 EUC - JP 등은 이 점에서는 UTF - 8과 비슷한 성질을 지닌다. ), 더 복잡한 알고리즘을 써야 했다. 왜냐하면, 이들 인코딩은 ASCII 영역의 글자를 나타내는 바이트를 2바이트로 나타내는 다른 글자의 두 번째 바이트로 사용하기 때문이다. 또한, UTF - 8에서 하나 이상의 바이트들이 손실되었을 때도, 다음의 정상 문자를 찾아서 동기화할 수 있기 때문에 피해를 줄일 수 있다. 그 설계 때문에 어떤 바이트들이 올바른 UTF - 8로 확인되면, 그 문자열이 실제로 UTF - 8로 인코딩되었
저장하며, 문자열 직렬화를 위하여 UTF - 8을 변형하여 사용하고 있다. 이를 변형된 UTF - 8이라 부른다. 표준 UTF - 8과의 차이는 크게 두 가지로, 한 가지는 U00을 1바이트가 아니라 2바이트, 즉 1100 100으로 표현하는 것이다. 따라서 수정된 UTF - 8에서는 인코딩된 문자열에 널 문자가 나타나지 않게 되며, 따라서 널 문자를 문자열의 끝으로 사용하는 C와 같은 언어에서 처리할 때 문자열이 잘리는 것을 막을 수 있다. 다른 한 가지 차이는 BMP 바깥의 문자를 인코딩하는 방법이다. 표준 UTF - 8에서는 이 문자들은 위와 같이 4바이트로 인코딩되지만, 수정된 UTF - 8에서는 이 문자들을 surrogate pair로 표시하여 두 문자로 나눈 뒤 같은 방법으로 인코딩한다. ( 이는 CESU - 8과 동일하다 ) 이러한 방법은 자바의 문자 형이 16비트 크기이며, 따라서 U100 이상의 영역에 속한 유니코드 문자는 항상 두 개의 자바 문자로 표현되어야 한다는 것에서 유래하였다. 하지만 이 방법은 BMP 바깥의 문자를 UTF - 8보다 더 긴 6바이트로
다른 가짜 UTF - 8 표현 ( 예를 들어서 너무 긴 형식 ) 을 같은 유니코드 문자열로 해석할 수 있다. 기존의 인코딩들과 비교했을 때 [ 편집 ] 장점 UTF - 8은 모든 유니코드 문자를 표현할 수 있다. 예를 들어서, UCS - 2는 BMP 안의 문자만을 표현할 수 있다. 바이트 경계를 순서대로 혹은 역순으로 찾기 쉽다. 만약 여러 바이트로 표시된 문자의 중간에서 찾기 시작한다면, 단지 해당 문자만 손실되고 나머지 문자들은 손상을 입지 않는다. 기존의 많은 다중바이트 인코딩들은 이러한 재동기화가 훨씬 힘들다. 한 문자를 표현하는 바이트 표현은 다른 문자를 표현하는 어떤 바이트 표현에도 포함되지 않는다. 따라서 ASCII 문자가 아닌 값들에 투명한 파일 시스템이나 다른 소프트웨어 ( 예를 들어서 C의 printf 함수 ) 와 호환성을 가진다. 바이트 표현의 첫 바이트만 사용하여 해당 바이트 표현의 길이를 결정할 수 있다. 따라서 부분 문자열을 얻는 과정이 매우 쉽다. 인코딩에 간단한 비트 연산만 사용되므로 효과적이다. UTF - 8은 곱셈이나 [UNK] 같은 느린 연산들을 사용하지 않는다. 단점 대부분의 UTF - 8
않으면 한국어가 깨지는 경우가 많이 일어난다 따라서 첫 128 문자는 1바이트로 표시되고, 그 다음 1920 문자 [ 1 ] 는 2바이트로 표시되며, 나머지 문자들 중 BMP 안에 들어 있는 것은 3바이트, 아닌 것은 4바이트로 표시된다. 위의 패턴을 사용하면 더 큰 코드 포인트를 표시할 수도 있다. 원래 UTF - 8은 6바이트를 사용해서 U7FF까지의 코드 포인트를 표현할 수 있게 하였으나, 2003년 11월에 발표된 RFC 3629에서는 유니코드에서 실제로 정의하는 U10FF까지의 문자만을 표시할 수 있도록 제한하였다. 따라서 이전까지는 UTF - 8에서 나타날 수 없는 바이트가 0xFE와 0xFF 뿐이었지만, RFC 3629에 따라서 0xC0, 0xC1, 그리고 0xF5부터 0xFF까지의 13개의 바이트가 나타날 수 없게 되었다. 변형된 UTF - 8 [ 편집 ] 자바는 내부적으로 문자열을 UTF - 16 인코딩으로 저장하며, 문자열 직렬화를 위하여 UTF - 8을 변형하여 사용하고 있다. 이를 변형된 UTF - 8이라 부른다. 표준 UTF - 8과의 차이는 크게 두 가지
과 비교했을 때 6 같이 보기 7 각주 8 외부 링크 구조 [ 편집 ] UTF - 8은 여러 표준 문서에서 다른 방법으로 정의되어 있지만, 일반적인 구조는 모두 동일하다고 볼 수 있다. 유니코드 코드 포인트를 나타내는 비트들은 여러 부분으로 나뉘어서, UTF - 8로 표현된 바이트의 하위 비트들에 들어 간다. U007F까지의 문자는 7비트 ASCII 문자와 동일한 방법으로 표시되며, 그 이후의 문자는 다음과 같은 4바이트까지의 비트 패턴으로 표시된다. 7비트 ASCII 문자와 혼동되지 않게 하기 위하여 모든 바이트들의 최상위 비트는 1이다. 코드 범위 ( 십육진법 ) UTF - 16BE 표현 ( 이진법 ) UTF - 8 표현 ( 이진법 ) 설명 00 - 007F 00 0xx 0xx ASCII와 동일한 범위 0080 - 0007FF 00xxx xx 110xx 10xx 첫 바이트는 110 또는 1110으로 시작하고, 나머지 바이트들은 10으로 시작함 000800 - 00FF xx xx 1110xx 10xx 10xx 0100 - 10FF 110110yy yyxx 110111xx xx 110zzz 10zzxx 10xx 10
을 수행하는 알고리즘으로도 코드 포인트 단위로 올바르게 정렬할 수 있다. ( 일반적인 목적으로는 재정렬이 필요하다 ) UTF - 8과 UTF - 16은 XML 문서의 표준 인코딩으로, 다른 인코딩들을 사용하려면 외부에서, 또는 문서 안에서 명시적으로 인코딩을 정해야 한다. [ 1 ] 다른 인코딩과의 왕복 변환이 간단하다. 바이트 단위 문자열 검색 알고리즘들을 그대로 사용할 수 있다. 간단한 알고리즘을 통하여 UTF - 8 문자열임을 확인할 수 있다. 즉, 다른 인코딩에서 나타나는 바이트들이 올바른 UTF - 8 문자열일 가능성은 낮다. U00을 표현할 때를 제외하면, 널 문자는 UTF - 8 문자열 안에 나타나지 않는다. 따라서 널 문자로 끝나는 문자열을 사용하는 C 언어의 문자열 함수 ( strncpy 같은 ) 를 그대로 사용할 수 있다.. 단점 나쁘게 만들어진 ( 그리고 현재 표준을 따르지 않는 ) UTF - 8 파서는 서로 다른 가짜 UTF - 8 표현 ( 예를 들어서 너무 긴 형식 ) 을 같은 유니코드 문자열로 해석할 수 있다. 기존의 인코딩들과 비교했을 때 [ 편집 ] 장점 UTF - 8은
이러한 문자를 표현하기 위하여 더 많은 바이트가 필요하며 UTF - 16과 비교할 때 최대 50 % 까지 크기가 늘 수 있다. 하지만 반대로 U00부터 U007F 사이의 글자들은 UTF - 16에서 크기가 두 배로 늘기 때문에 실질적으로는 큰 문제가 없을 수도 있다. 같이 보기 [ 편집 ] ASCII UCS 바이트 순서 문자 ( BOM ) UTF - 16 각주 [ 편집 ] ↑ 발음 구별 기호가 붙은 라틴 문자, 그리스 문자, 키릴 문자, 콥트 문자, 아르메니아 문자, 히브리 문자, 아랍 문자 외부 링크 [ 편집 ] UTF - 8이 만들어진 계기와 개요 유니코드 용어집 Java 언어를 이용한 유니코드 서로게이트 프로그래밍 Unicode / UTF8 변환 표 vdeh문자 인코딩 문자 집합초기 전기통신 ASCII ISO / IEC 646 ISO / IEC 6937 T. 61 BCDIC 보도 코드 모스 부호 ( 전신 부호 와분 코드 ) 특수 인쇄 전신 부호 : 라틴어가 아닌 계열, 중국어, 키릴 니들 전신 부호 ISO / IEC 8859 - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12 - 13 - 14 - 15 - 16 서지적 이용 ANSEL ISO 5426 / 5426 - 2 /
UTF-8은 유니코드를 위한 가변 길이 문자 인코딩 방식 중 하나로, 켄 톰프슨과 롭 파이크가 만들었다. UTF-8은 Universal Coded Character Set Transformation Format - 8-bit의 약자이다. 본래는 FSS-UTF(File System Safe UCS/Unicode Transformation Format)라는 이름으로 제안되었다. UTF-8 인코딩은 유니코드 한 문자를 나타내기 위해 1바이트에서 4바이트까지를 사용한다. 예를 들어서, U00부터 U007F 범위에 있는 ASCII 문자들은 UTF-8에서 1바이트만으로 표시된다. 4바이트로 표현되는 문자는 모두 기본 다국어 평면(BMP) 바깥의 유니코드 문자이며, 거의 사용되지 않는다. UTF-16과 UTF-8 중 어느 인코딩이 더 적은 바이트를 사용하는지는 문자열에서 사용된 코드 포인트에 따라 달라지며, 실제로 DEFLATE와 같은 일반적인 압축 알고리즘을 사용할 경우 이 차이는 무시할 수 있을 정도이다. 이러한 압축 알고리즘을 사용하기 힘들고 크기가 중요할 경우 유니코드 표준 압축 방식(Standard Compression Scheme for Unicode)을 대신 사용할 수 있다.