WWW 또는 다른 방법으로 비영어권 텍스트에 UTF-8을 사용하는 것이 얼마나 광범위합니까? 나는 특정 국가의 통계 자료와 상황 모두에 관심이있다.
저는 ISO-8859-1 (또는 15)가 독일에서 확고하게 확고하게 자리 잡고 있음을 알고 있습니다. 그러나 일본이나 중국처럼 멀티 바이트 인코딩을 사용해야하는 언어는 어떨까요? 몇 년 전에 일본은 거의 모든 JIS 인코딩을 거의 독점적으로 사용하고있었습니다.
이러한 관찰을 감안할 때 UTF-8이 가장 일반적인 멀티 바이트 인코딩 인 것은 사실일까요? 아니면 기본적으로 국제 시장을 대상으로하고 다국어 텍스트 작업을해야하는 새로운 애플리케이션에서만 내부적으로 사용된다고 말하는 것이 더 정확할까요? 현재 출력물에 UTF-8 만 사용하는 앱을 사용하는 것이 허용 가능합니까 아니면 각 국가의 시장에서 출력 파일이 다른 앱에서 사용할 수 있도록 다른 레거시 인코딩에있을 것으로 기대할 수 있습니까?
편집하다: UTF-8이 유용한 지 또는 왜 작동하는지에 대해 묻지 않습니다. 나는 그 모든 것을 알고있다. 실제로 널리 채택되고 오래된 인코딩을 대체하고 있는지 묻습니다.
우리는 서비스 지향 웹 서비스 세계에서 거의 독점적으로 UTF-8을 사용합니다. 심지어 서구 유럽 언어를 사용하는 경우에도 ISO-8859-X 형식을 사용하여 머리를 회전시킬만큼 충분한 "단점"이 있습니다. UTF- 8은 정말로 그것을 완전히 해결합니다.
그래서 나는큰UTF-8 사용을 위해 언제 어디서나 투표하십시오! :-) 서비스 지향 세계와 .NET 및 Java 환경에서는 더 이상 문제가 아니거나 더 이상 잠재적 인 문제가 아닐 것입니다.
그것은 단지 많은 문제를 해결하기 때문에 항상 처리 할 필요가 없습니다 ......
마크
나는 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와 정확히 동일합니다 .
나는 방문하는 경향이있다.룬 문자웹 사이트를 자주 방문하십시오. 그들 중 많은 사람들이 여전히 사용하고 있습니다.Windows-1251부호화. 또한 Yandex Mail 및 Mail.ru (CIS 국가의 두 가지 가장 큰 웹 메일 서비스)의 기본 인코딩입니다. 또한 러시아어 IP 주소에서 다운로드 할 때 Opera 브라우저에서 기본 콘텐트 인코딩으로 설정됩니다 (2 위 Firefox에서 2 위). 나는 다른 브라우저에 대해 확실히 모르겠다.
그 이유는 아주 간단합니다. UTF-8은 키릴 문자를 인코딩하는 데 2 바이트가 필요합니다. 비 유니 코드 인코딩에는 1 바이트 만 필요합니다 (대부분의 동부 알파벳과는 달리 키릴 문자는 매우 작음). 또한 고정 길이이며 오래된 ASCII 전용 도구로 쉽게 처리 할 수 있습니다.
요즘에는 앱은 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)를 사용하는 Linux 사용자가 시스템 기본값으로 UTF-8을 사용한다는 것은 몇 가지 해결 방법 / 조정 설정이 필요함을 의미합니다.
내가 찾을 수 있었던 몇 가지 통계는 다음과 같습니다.
이 두 페이지 모두 심각한 문제로 고통 받고있는 것 같습니다.
더 중요한 것은 통계는 웹에서 액세스 할 수있는 콘텐츠에만 해당됩니다. 사용자의 하드 드라이브에 문서를 인코딩하는 것과 같은 더 광범위한 통계는 얻을 수없는 것 같습니다. (이것은 많은 나라에서 필요한 연구를하는 것이 얼마나 어렵거나 비용이 많이 드는가를 감안할 때 놀라지 않습니다.)
간단히 말해서, 당신의 질문은 객관적으로 답할 수 없습니다. 특정 국가에서 UTF-8 전용 응용 프로그램이 "수용 가능"한 방법에 대한 연구를 찾을 수는 있지만 필자는 찾을 수 없었습니다.
필자의 경우, 응용 프로그램을 문자 인코딩에 독립적으로 작성하고 사용자가 문서 저장에 사용할 문자 인코딩을 결정하게하는 것이 좋습니다. 이것은 Java와 C #같은 현대 언어에서 비교적 쉽게 할 수 있습니다.
CJK 문자의 사용자는 문자가 2 바이트가 아닌 3 바이트가되기 때문에 자연스럽게 UTF-8에 대해 바이어스됩니다. 분명히 중국에서는 UTF-16이 아닌 자신의 2 바이트 GBK 인코딩을 선호합니다.
편집하다@ Joshua에 의한이 코멘트에 대한 응답으로 :
그리고 HTML과 자바 스크립트 문자가 이제 1 바이트로 인코딩되기 때문에 어쨌든 UTF-8에서 페이지가 더 작아지는 것은 대부분의 웹 작업에서 드러납니다.
응답:
GB. + 인코딩 및 기타 동아시아 인코딩은 가변 길이 인코딩입니다. 0x7F까지의 값을 갖는 바이트는 대개 ASCII로 매핑됩니다 (경우에 따라 사소한 차이가있을 수 있음). 상위 비트 세트가있는 일부 바이트는 2 - 4 바이트 시퀀스의 선두 바이트이며 다른 바이트는 불법입니다. UTF-8처럼.
"HTML 및 javascript 문자"는 ASCII 문자이기 때문에 항상 인코딩과 UTF-8에서 1 바이트가 있습니다.
UTF-8은 UTF-16보다 일반적으로 충실하므로 일반적으로 많이 사용됩니다. 또한 UTF-16의 엔디안 문제로 인해 문제가되지 않습니다.
이것은 교환 형식으로 좋은 선택이지만, 문자가 바이트 단위로 변하기 때문에 (문자 당 1에서 4 바이트까지) 문자가 작동하기 때문에 항상 좋은 것은 아닙니다. 따라서 일반적으로 데이터 교환을 위해 UTF-8을 예약하고 입력 및 종료 지점에서 변환을 사용하는 것이 더 깔끔합니다.
시스템 내부 저장소 (디스크 파일 및 데이터베이스 포함)의 경우 원시 UTF-16, UTF-16 또는 다른 8 비트 "ANSI"인코딩을 사용하는 것이 더 깨끗합니다. 후자는 특정 코드 페이지로 제한하며 다국어 텍스트를 처리하는 경우 어려움을 겪을 수 있습니다. 로컬에서 데이터를 처리하기 위해 "ANSI"인코딩 또는 기본 UTF-16이 필요할 것입니다. 문자 처리가많은그렇게 간단한 문제.
그래서 UTF-8이 인기가 있다고 제안합니다.외부 적으로내부적으로는 더 드물다. 내부적으로 UTF-8은 정적 텍스트 얼룩을 제외하고는 악몽처럼 보입니다.
일부 DBMS는 텍스트 얼룩을 UTF-8로 항상 저장하도록 선택하는 것 같습니다. 이는 다른 압축 스키마를 고안하지 않고도 압축의 장점을 제공합니다 (UTF-16 저장 이상). UTF-8 로의 변환은 매우 일반적이므로 효율적이고 안정적으로 작동하는 것으로 알려진 시스템 라이브러리를 사용합니다.
"ANSI"체계의 가장 큰 문제점은 하나의 작은 문자 집합에 바인딩되어 있으며 큰 영문자를 가진 언어에 대한 다중 바이트 문자 집합 시퀀스를 처리해야합니다.
나는 둘 다 통계학에 관심이있다. 특정 상황에서의 데이터 및 상황 국가.
W3Techs에는 이러한 모든 데이터가 있지만 쉽게 찾을 수 없습니다.
예를 들어, 먼저 언어를 선택하여 일본어 웹 사이트의 문자 인코딩 분포를 가져옵니다. 언어> 일본어를 선택한 다음 분할> 문자 인코딩을 선택합니다. 이 보고서는 다음과 같이 나타납니다.일본어를 사용하는 웹 사이트 간의 문자 인코딩 배포. 당신은 본다 : 일본 위치는 49 % SHIFT-JIS와 38 % UTF-8를 사용한다. 최상위 도메인 당 동일 사이트, 예를 들어 모든 .jp 사이트를 운영 할 수 있습니다.
Java와 C #은 내부적으로 UTF-16을 사용하며 쉽게 다른 인코딩으로 변환 할 수 있습니다. 그들은 엔터프라이즈 세계에서 꽤 잘 정비되어 있습니다.
나는 UTF만을 입력으로 받아들이는 것이 요즘 큰 일이 아니라고 말하고 싶다. 그것을 위해 가라.
나는 둘 다 통계학에 관심이있다. 특정 상황에서의 데이터 및 상황 국가.
저는 이것이 문제 영역과 그 역사에 훨씬 더 의존적이라고 생각합니다. 그런 다음 응용 프로그램이 사용되는 국가에 의존합니다.
모든 경쟁 업체가 출력하는 애플리케이션을 구축하는 경우 ISO-8859-1 (지난 10 년간 대다수를 지켜 왔음) 모든 잠재 고객은 많은 파일을 열지 않을 것이라고 생각합니다.
즉, UTF-8로 인코딩 된 파일을 출력해야 할 필요가 있다고 생각하지 않습니다. 요즘에는 대부분의 프로그램이 대처하지만 YMMV는 타겟 시장에 따라 다릅니다.