UTF-8은 얼마나 널리 보급되어 있습니까?

Question

WWW 또는 다른 방법으로 영어 이외의 텍스트에 UTF-8을 사용하는 것이 얼마나 광범위합니까? 나는 특정 국가의 통계 자료와 상황 모두에 관심이있다.

저는 ISO-8859-1 (또는 15)가 독일에서 확고하게 자리 잡고 있음을 알고 있습니다. 그렇지만 일본이나 중국처럼 멀티 바이트 인코딩을 사용해야하는 언어는 어떨까요? 몇 년 전에 일본은 거의 모든 JIS 인코딩을 거의 독점적으로 사용하고있었습니다.

이러한 관찰을 감안할 때 UTF-8이 가장 일반적인 멀티 바이트 인코딩이라는 것은 사실일까요? 아니면 기본적으로 국제 시장을 대상으로하고 다국어 텍스트 작업을해야하는 새로운 애플리케이션에서만 내부적으로 사용된다고 말하는 것이 더 정확할까요? 현재 출력물에 UTF-8 만 사용하는 앱을 사용하는 것이 허용 가능합니까 아니면 각 국가의 시장에서 출력 파일이 다른 앱에서 사용할 수 있도록 다른 레거시 인코딩에있을 것으로 기대할 수 있습니까?

편집 : UTF-8이 유용한 지 또는 왜 작동하는지 묻지 않습니다. 나는 그 모든 것을 알고있다. 실제로 널리 채택되고 오래된 인코딩을 대체하고 있는지 묻습니다.

Answer 1

UTF-8 is used on 55% of websites.

Answer 2

Java 및 C# 둘 다 내부적으로 UTF-16을 사용하며 쉽게 다른 인코딩으로 변환 할 수 있습니다. 그들은 엔터프라이즈 세계에서 꽤 잘 정비되어 있습니다.

나는 입력으로 UTF 만 받아들이는 것이 요즘 큰 문제는 아니라고 말하고 싶습니다. 그것을 위해 가라.

Answer 3

우리는 서비스 지향 웹 서비스 세계에서 거의 독점적으로 UTF-8을 사용합니다. 서유럽 언어가 "단지"일지라도 다양한 ISO-8859-X 형식을 사용하여 머리를 만들기에 충분한 "단점"이 있습니다 스핀 - UTF-8로 완전히 완전히 해결됩니다.

그래서 저는 BIG 투표를 사방에 UTF-8 사용에 넣었습니다. :-) 서비스 지향 세계와 .NET 및 Java 환경에서는 더 이상 문제가 아니거나 더 이상 잠재적 인 문제가 아닐 것입니다. 그것은 단지 당신이 정말로 모든 시간을 처리해야 할 필요가없는 많은 문제를 해결

......

마크

나는 그냥 받아들이 허용 생각하지 않습니다

Answer 4

UTF-8 - UTF-8 및 이전에 대상 시장에서 널리 사용 된 인코딩을 수락해야합니다.

좋은 소식은 독일 상황에서 8859-1/15와 ASCII를 주로 사용하는 경우 8859-1을 추가로 수락하여 UTF-8로 변환하는 것이 기본적으로 비용이 전혀 들지 않는다는 것입니다. 감지하기 쉽습니다 : 8859-1로 인코딩 된 ö 또는 ü를 사용하는 것은 잘못된 UTF-8입니다 (예 : 쉽게 검색 할 수없는 잘못된 쌍으로 들어가지 않아도 됨). 문자 128-159를 사용하면 8859-1이 유효하지 않을 수 있습니다. 첫 번째 상위 바이트의 몇 바이트 내에서 일반적으로 어떤 인코딩이 사용 중인지 아주 잘 파악할 수 있습니다. 그리고 스펙을 추측하거나 추측하여 인코딩을 알고 나면 8859-1을 유니 코드로 변환 할 변환 테이블이 필요 없습니다. U + 0080에서 U + 00FF는 8859-1의 0x80-0xFF와 정확히 동일합니다 .

Answer 5

나는 통계 데이터와 특정 국가의 상황에 모두 관심이 있습니다.

저는 이것이 문제 도메인과 그 역사에 더 의존적이라고 생각합니다. 그런 다음 응용 프로그램이 사용되는 국가에 의존합니다.

모든 경쟁 업체가 출력하는 애플리케이션을 구축하는 경우 ISO-8859-1 (지난 10 년간 대다수를 지켜 왔음) 모든 잠재 고객은 많은 파일을 열지 않을 것이라고 생각합니다.

그렇긴하지만, UTF-8로 인코딩 된 파일을 출력해야 할 필요가 있다고 생각하지 않습니다. 요즘에는 대부분의 프로그램이 대처하지만 YMMV는 타겟 시장에 따라 다릅니다.

Answer 6

UTF-8은 UTF-16보다 일반적으로 충실하므로 일반적으로 많이 사용됩니다. 또한 UTF-16의 엔디안 문제로 인해 문제가되지 않습니다.

이것은 교환 형식으로 아주 좋습니다만, 문자가 바이트 단위로 변하기 때문에 (문자 당 1에서 4 바이트까지) 문자가 작동하기 때문에 항상 좋은 것은 아닙니다. 따라서 일반적으로 데이터 교환을 위해 UTF-8을 예약하고 입력 및 종료 지점에서 변환을 사용하는 것이 더 깔끔합니다.

시스템 내부 저장소 (디스크 파일 및 데이터베이스 포함)의 경우 원시 UTF-16, 다른 압축 또는 8 비트 "ANSI"인코딩의 UTF-16을 사용하는 것이 더 깔끔합니다. 후자는 특정 코드 페이지로 제한하며 다국어 텍스트를 처리하는 경우 어려움을 겪을 수 있습니다. 로컬에서 데이터를 처리하기 위해 "ANSI"인코딩 또는 기본 UTF-16이 필요할 것입니다. 문자 처리는 이되고은 더 간단한 문제가됩니다.

그래서 UTF-8은 일반적으로 이고 외부적으로는이지만 내부적으로는 더 적음을 제안합니다. 내부적으로 UTF-8은 정적 텍스트 얼룩을 제외하고는 악몽처럼 보입니다.

일부 DBMS는 텍스트 얼룩을 항상 UTF-8로 저장하도록 선택하는 것 같습니다. 이는 다른 압축 스키마를 고안하지 않고도 압축의 장점을 제공합니다 (UTF-16 저장 이상). UTF-8 로의 변환은 매우 일반적이므로 효율적이고 안정적으로 작동하는 것으로 알려진 시스템 라이브러리를 사용합니다.

"ANSI"체계의 가장 큰 문제점은 하나의 작은 문자 집합에 바인딩되어 있으며 큰 영문자를 가진 언어에 대한 다중 바이트 문자 집합 시퀀스를 처리해야합니다.

Answer 7

그것은 단지 그 출력에 UTF-8을 사용하는 응용 프로그램을 가지고 현재 허용되어, 각 국가의 시장 가로 사용할 수 출력 파일이 하기 위해 다른 기존 인코딩 것으로 기대 다른 앱.

음, 어떤 종류의 앱과 출력에 따라 달라집니다. 대부분의 경우 (예 : 대부분의 웹 기반 콘텐츠) UTF-8로만 이동할 수 있지만, 예를 들어, 사용자가 일반 텍스트 파일에 일부 데이터를 저장할 수있는 데스크톱 응용 프로그램에서 UTF-8은 이 아니라으로 충분하다고 생각합니다.

Mac OS X은 UTF-8을 광범위하게 사용하며 사용자 파일의 기본 인코딩이므로 대부분의 (모든?) 주요 Linux 배포판에서도 마찬가지입니다. 그러나 Windows에서 ... Windows-1252 (ISO-8859-1과 비슷하지만 동일하지 않음)가 여전히 많은 언어의 기본 인코딩입니까? 적어도 Windows XP에서는 그랬지만, 이것이 바뀌 었는지 확실하지 않습니다. 어쨌든 상당한 수의 Windows 사용자가 Windows-1252 (또는 그와 비슷한 것)로 인코딩 된 컴퓨터에 파일을 가지고있는 한 UTF-8 만 지원하면 많은 사람들에게 슬픔과 혼란을 초래할 수 있습니다.

일부 국가의 특정 정보 : 핀란드에서는 ISO-8859-1 (또는 15)도 여전히 확고합니다. 예를 들어, 핀란드어 IRC 채널은 여전히 ​​afaik를 사용하지만 대부분은 라틴어 -1입니다. (즉, irssi와 같은 텍스트 기반 클라이언트 (예 : irssi)를 사용하는 시스템 기본값으로 UTF-8을 사용하는 Linux 사용자는 설정을 조정할 필요가 있습니다.)

Answer 8

UTF-8은 질문을 구체적으로 다루지 않지만 문자 인코딩은 모든 IETF 트랙 프로토콜에서 구현해야합니다.

http://www.ietf.org/rfc/rfc2277.txt

Answer 9

당신은 this 문제에 관심이있을 수 있습니다. 나는 다양한 언어로 유니 코드에 대한 지원에 대한 CW를 만들려고 노력해 왔습니다.

Answer 10

CJK 문자의 사용자는 문자가 2 개가 아닌 3 바이트가되기 때문에 자연스럽게 UTF-8에 대해 바이어스됩니다. 분명히 중국에서는 UTF-16이 아닌 자신의 2 바이트 GBK 인코딩을 선호합니다.

는 @Joshua하여이 댓글에 응답

편집는 :

그리고는 HTML과 자바 스크립트 문자로 어쨌든 UTF-8 작은 것 페이지를 작동 대부분의 웹에 대해 밝혀 이제 한 바이트로 인코딩 .

응답 :

기가 바이트 + 인코딩과 다른 동아시아 인코딩은 가변 길이 인코딩입니다.. 0x7F까지의 값을 갖는 바이트는 대개 ASCII로 매핑됩니다 (경우에 따라 사소한 차이가있을 수 있음). 상위 비트 세트가있는 일부 바이트는 2 - 4 바이트 시퀀스의 선두 바이트이며 다른 바이트는 불법입니다. UTF-8처럼.

"HTML 및 javascript 문자"는 ASCII 문자이기 때문에 항상 인코딩과 UTF-8에서 1 바이트를 유지합니다.

Answer 11

여기에 내가 발견 할 수 있었다 통계는 다음과 같습니다

• This page는 "상위 웹 사이트"의 문자 인코딩에 대한 사용 통계를 보여줍니다.
• This page은 또 다른 예입니다.

이 페이지의 두는 심각한 문제로 고통하는 것 :

• 특히 비 영어권 국가, 자신의 샘플 세트가 얼마나 대표 명확하지 않다.
• 통계를 수집하는 데 사용 된 방법론이 명확하지 않습니다. 페이지 액세스 수를 계산하고 있습니까? 다운로드/다운로드 한 콘텐츠는 어떻게됩니까?

더 중요한 통계는 웹에서 액세스 할 수있는 콘텐츠에만 해당됩니다. 사용자의 하드 드라이브에 문서를 인코딩하는 것과 같은 더 광범위한 통계는 얻을 수없는 것 같습니다. (많은 나라에서 필요한 연구를하는 것이 얼마나 어렵거나 비용이 많이 드는가를 감안할 때 이것은 놀라운 일이 아닙니다.)

요약하면 질문에 객관적으로 대답 할 수 없습니다.특정 국가에서 UTF-8 전용 응용 프로그램이 "수용 가능"한 방법에 대한 연구를 찾을 수는 있지만 필자는 찾을 수 없었습니다.

제게는 응용 프로그램을 문자 인코딩에 알맞지 않게 작성하고 사용자가 문서 저장에 사용할 문자 인코딩을 결정하도록하는 것이 좋습니다. 이것은 Java와 C# 같은 현대 언어에서 비교적 쉽게 할 수 있습니다.

Answer 12

나는 종종 Runet 웹 사이트를 방문하는 경향이 있습니다. 많은 사람들이 여전히 Windows-1251 인코딩을 사용합니다. 또한 Yandex Mail 및 Mail.ru (CIS 국가의 두 가지 가장 큰 웹 메일 서비스)의 기본 인코딩입니다. 또한 러시아어 IP 주소에서 다운로드 할 때 Opera 브라우저에서 기본 콘텐트 인코딩으로 설정됩니다 (2 위 Firefox에서 2 위). 나는 다른 브라우저에 대해 확실히 모르겠다.

이유는 매우 간단합니다. UTF-8은 키릴 문자를 인코딩하는 데 2 ​​바이트가 필요합니다. 비 유니 코드 인코딩에는 1 바이트 만 필요합니다 (대부분의 동부 알파벳과는 달리 키릴 문자는 매우 작음). 또한 고정 길이이며 오래된 ASCII 전용 도구로 쉽게 처리 할 수 ​​있습니다.

Answer 13

나는 통계 데이터와 특정 국가의 상황에 모두 관심이 있어요.

W3Techs에

, 우리는이 모든 데이터를 가지고 있지만 그것을 찾을 아마도 쉽지 않다 :

예를 들어, 당신이 먼저 언어를 선택하여 일본어 웹 사이트의 문자 인코딩 분포를 얻을 : 내용 언어> 일본어, 분할> 문자 인코딩을 선택합니다. 이 보고서는 Distribution of character encodings among websites that use Japanese입니다. 당신은 본다 : 일본 위치는 49 % SHIFT-JIS와 38 % UTF-8를 사용한다. 최상위 도메인 당 동일 사이트를 수행 할 수 있습니다 (예 : 모든 .jp 사이트).