UTF-8 이외의 문자 인코딩 (및 UTF-16 / UTF-32)은 더 이상 사용되지 않습니까?

내 애완 동물은 문자 세트 지원을위한 코드가 많은 소프트웨어 프로젝트를보고 있습니다. 내가 틀리지 말고, 나는 호환성을 위해 모두 노력하고 있으며, 텍스트 편집기를 사용하여 파일을 여러 문자 세트로 열고 저장할 수있어서 기쁩니다 . 나를 괴롭히는 것은 비 유니버설 문자 인코딩의 확산이“문제”가 아닌“적절한 유니 코드 지원”으로 분류되는 방법입니다.

예를 들어 PostgreSQL과 해당 문자 세트 지원을 선택하겠습니다 . PostgreSQL은 두 가지 유형의 인코딩을 처리합니다.

• 클라이언트 인코딩 : 클라이언트와 서버 간의 통신에 사용됩니다.
• 서버 인코딩 : 데이터베이스에 내부적으로 텍스트를 저장하는 데 사용됩니다.

많은 클라이언트 인코딩을 지원하는 것이 좋은 이유를 이해할 수 있습니다. UTF-8에서 작동하지 않는 클라이언트는 스스로 변환을 수행 할 필요없이 PostgreSQL과 통신 할 수 있습니다. 내가 얻지 못하는 것은 PostgreSQL이 여러 서버 인코딩을 지원하는 이유는 무엇입니까? 데이터베이스 파일은 하나의 PostgreSQL 버전에서 다음 PostgreSQL 버전으로 (거의 항상) 호환되지 않으므로 버전 간 호환성은 문제가되지 않습니다.

UTF-8은 모든 유니 코드 코드 포인트를 인코딩 할 수있는 유일한 ASCII 호환 표준 문자 세트입니다 (잘못되면 알려주세요). 나는 캠프에서 UTF-8이 최고의 문자 세트이지만 UTF-16 및 UTF-32와 같은 다른 범용 문자 세트를 기꺼이 사용하려고합니다.

유니버설이 아닌 모든 문자 세트는 더 이상 사용되지 않아야한다고 생각합니다. 그들이해서는 안되는 설득력있는 이유가 있습니까?

PostgreSQL을 언급 했으므로 UTF-8이 아닌 서버 측 인코딩이 세부적으로 지원되는 주요 킬러 이유는 일본어가 필요하기 때문입니다. 분명히, 유니 코드와 다양한 일본어 "레거시"인코딩간에 동일한 왕복 변환이 항상 가능한 것은 아니며 경우에 따라 공급 업체마다 변환 테이블이 다를 수도 있습니다. 정말 당황 스럽지만 분명히 그렇습니다. (광범위한 문자 집합 지원은 PostgreSQL이 일본에서 인기있는 이유 중 하나입니다.)

데이터베이스 시스템에 대해 이야기하고 있기 때문에 주요 작업 중 하나는 사용자가 정의한대로 데이터를 안정적으로 저장하고 검색 할 수 있으므로 손실 문자 세트 변환이 수행되지 않는 경우가 있습니다. 웹 브라우저를 다루는 경우, 실제로 중요한 것은 결과 가 좋아 보이는지 여부 입니다. 아마도 적은 인코딩을 지원하면 벗어날 수 있지만 데이터베이스 시스템에는 추가 요구 사항이 있습니다.

다른 답변에 언급 된 다른 이유 중 일부는지지 주장으로 적용됩니다. 그러나 일본인이 거부하는 한 문자 설정 지원을 줄일 수 없습니다.

두 가지 분명한 이유 : 저장하는 데이터에 따라 다른 형식으로 변환하는 데 약간의 시간과 추가 공간이 필요할 수 있습니다. 400MB의 정보를 저장하는 경우 스토리지 요구 사항을 두 배로 늘리는 것이 큰 문제는 아니지만 400 테라 바이트를 저장하면 조금 더 의미가 있습니다. Shift-JIS에서 UTF-x로 400 테라 바이트의 데이터를 변환하는 데에도 약간의 시간이 걸릴 수 있습니다.

예를 들어 가동 시간을 보장하여 특정 연도에서 10 분 동안 데이터베이스를 사용할 수 있고 초당 수백 번 업데이트되는 데이터베이스를 보유하고 있다고하는 경우에는 특히 어려워집니다. 이러한 상황에서 주요 전환을 관리 하는 것은 여전히 가능 하지만 가볍게 수행 할 수있는 것은 아닙니다 . 경우에 따라 그러한 전환을 준비하는 데 수년 의 계획 이 쉽게 걸릴 수 있습니다 .

(예를 들어) ASCII 만 지원하는 데이터베이스로 시작한 경우 모든 인코딩에 대한 지원을 추가해야하는지 여부를 논의 할만한 충분한 이유가 있을 수 있습니다. 그러나 이미 지원하는 경우에는이를 제거 할 필요가 거의 없습니다. 그들을 지원합니다.

특히, 코드를 단순화하거나 그와 비슷한 방식으로 아무것도 얻지 못할 것입니다. 어쨌든 클라이언트와 서버 간의 변환을 처리하려면 여전히 모든 변환 루틴이 필요합니다. 따라서 지원을 삭제한다는 것은 "디스크에 쓰기"및 "디스크에서 읽기"경로에서 하나의 (사소한) 함수 호출을 삭제하는 것을 의미하지만 그 외의 것은 거의 없습니다. 디스크에서 두 개의 인코딩 을 지원하더라도 얻을 수조차 없습니다. 여기에서 함수 호출이 있으므로 실제로는 해당 기능이 지원하는 인코딩 범위를 제한하는 것입니다.

적어도 이것을 설계했다면 아마도 UCS-4에서 작동하도록 데이터베이스의 핵심을 작성한 다음 핵심과 디스크 사이, 핵심과 사용자 사이에서 변환 루틴을 수행했을 것입니다. 두 경우 모두 동일한 루틴 세트를 사용하므로 가장 간단한 경로는 디스크 스토리지가 클라이언트가 사용할 수 있는 것과 정확히 동일한 인코딩 세트를 사용하도록 허용하는 것입니다.

서버에 UTF-8 만 저장하는 데에는 몇 가지 문제가 있습니다.

1. VARCHAR(20)열의 한계는 무엇입니까 ? 20 바이트 또는 20 개의 "문자"입니까 (그리고 유니 코드에서는 문자, 합자 등을 고려할 때 "문자"란 무엇입니까?)? 더 나쁜 것은, CHAR(20)가능한 전체 공간을 실제로 예약 해야하는 곳 은 어떻습니까? MySQL은 믿기 때문에 CHAR(20)최악의 경우를 처리하기 위해 UTF-8로 인코딩 된 열 (즉, 80 바이트 ) 의 바이트 수를 4 배로 예약 합니다.
2. 서버 인코딩과 클라이언트 인코딩간에 지속적인 인코딩 변환을 수행해야합니다. 여러 클라이언트 인코딩 지원을 중단하고 싶다고 주장 할 수 있지만, 그렇게하지 않으면 모든 문자열을 항상 변환해야합니다. 서버 인코딩과 클라이언트 인코딩을 일치시킬 수 있으면 변환이 필요하지 않습니다.
3. 다른 사람들이 지적했듯이 UTF-8은 영어 텍스트를 저장하는 데 매우 효율적이지만 동아시아 언어와 같은 다른 언어에는 매우 비효율적 입니다. UTF-16 또는 UTF-8을 적합하게 사용할 수 있다고 생각합니다. 또는 텍스트를 압축하지만 인덱싱 및 검색이 비효율적입니다.

레거시 인코딩은 대부분 무의미하며 유니 코드는 일반적으로 모든 새로운 응용 프로그램에 사용하기에 가장 적합한 인코딩입니다. 오늘 처음부터 데이터베이스 서버를 작성하는 경우 유니 코드 만 지원하고 레거시 인코딩은 전혀 지원하지 않습니다.

차이점은 오늘날 사용되는 PostgreSQL과 대부분의 다른 데이터베이스 서버가 유니 코드가 실행 가능한 옵션이 되기 전에 존재 한다는 것입니다. 그래서 그들은 이미 레거시 인코딩을 지원했으며 (물론 레거시가 아니 었습니다) 이데올로기 적 이유로 많은 코드를 추출하는 것은 그리 중요하지 않습니다.

비 유니버설 (특히 1 바이트) 인코딩의 위치는 다음과 같습니다.

• 유니 코드 문자 데이터베이스를 저장할 메모리가 충분하지 않습니다.
• ROM에 1 바이트 글꼴을 하드 코딩하십시오.
• 다르게 인코딩 된 파일의 소스를 제공하기 위해 인터넷에 액세스 할 수 없습니다.

오늘날 일부 유형의 임베디드 장치에 적용됩니다. 하지만 바탕 화면, 서버 룸에, 비 유니 코드 인코딩을해야 오랫동안 지금까지 사용되지 않습니다.

UTF-8은 자기 중심에 가장 적합 ^한 영어 스피커. 일본어 인 경우 문자의 약 99 %가 UTF-16에서 2 개 대신 3-4 바이트를 사용합니다.

비 라틴어 방언은 실제로 크기 수준에서 UTF-8로 고통받습니다. 몇 년 안에 대부분의 고객이 중국어 일 수 있으며 중국어 작문에는 수백만의 문자가 있다는 것을 잊지 마십시오. UTF-8을 사용하면 효율적으로 유지할 수 없습니다.

그렇지 않으면 UTF- 뭔가 가 아닌 텍스트 문서가있을 때 나는 그것을 싫어합니다 . 적절한 인코딩이 필요한 경우 종종 방해가됩니다. 필자의 책에서 비 유니 코드 인코딩은 죽었다.

_{1. 자기 중심적인 부분을 개인적으로 취하지 마십시오. 나는 화려한 그림을 만들고 싶었고 실제로 그것을 의미하지는 않습니다.}

유니 코드는 근본적으로 손상되었으며 수정되지 않았을 것입니다. 그것은 더 나은 것으로, 진정으로 보편적 인 것으로 대체되어야합니다. 더 이상 사용되지 않는 것이 있으면 유니 코드입니다.

Unicide 관련 문제 예 :

• UTF8은 합리적인 해킹이지만 대부분의 UTF16 기반 소프트웨어가 손상되었습니다. 유니 코드를 지원하는 대부분의 Windows 앱은 OS 자체를 포함하여 UTF16을 사용합니다. 가장 일반적인 문제는 기본 단어 이상을 지원하지 않는 것입니다 (예 : 다중 단어 문자).

• 한 통일은 완화되지 않은 재앙입니다. 추가 메타 데이터없이 일본어 / 중국어 / 한국어 텍스트를 단일 문서에 혼합하는 것은 불가능하며 어떤 글꼴을 사용해야하는지 감지하기가 어렵습니다.

• 조합 캐릭터는 또 다른 재앙입니다. 보다 합리적인 인코딩 체계는 하나의 문자를 하나의 코드로 매핑하여 문자열 처리를 비교적 깔끔하게 만듭니다. 유니 코드는 그렇지 않습니다. 유니 코드도 일관성이 없습니다. 한 문자는 대부분 조합이지만 유럽 조합 문자와 같이 인코딩되지는 않습니다.

• 일부 사람들의 이름은 유니 코드로 올바르게 쓰여지지 않거나 위에서 언급 한 문제로 인해 잘못 렌더링되기 쉽습니다. 예를 들어, 티켓에 인쇄 된 것과 일치하지 않는 여권으로 항공기에 탑승하려고 할 때 심각한 결과를 초래할 수 있습니다.

이러한 문제 등으로 인해 영어 이외의 많은 소프트웨어는 유니 코드를 사용할 수 없으며 로컬 문자 인코딩을 사용합니다. 이것은 특히 일본어 및 중국어 소프트웨어에서 일반적입니다.

이상적으로는 유니 코드가 더 이상 사용되지 않아야합니다. TRON 문자 코딩은 유니 코드를 대체하기에 적합하며 업데이트되지 않는 기존 소프트웨어와 대체로 호환됩니다.

글쓰기에는 적합하지만 읽기에는 적합하지 않습니다.

이러한 인코딩을 사용하는 기존 내용이 많이 있으며 base64와 같은 일부 인코딩은 이진 데이터를 포함하는 방법으로 명령을 요구하기 때문에 아무데도 갈 수 없습니다.

실제 문제는 인코딩의 자동 감지로 보안 허점을 초래합니다. UTF-7 과 같은 모호한 인코딩이 사라지는 것을 신경 쓰지 않을 것 입니다.

자동 감지는 또한 순전히 바이트 문자열을 연결하여 생성 된 컨텐츠를 잘못 처리하는 경향이 있습니다.

데이터베이스 및 새 응용 프로그램 의 기본 문자 인코딩이 일종의 UTF 변형이어야 한다는 것에 동의 할 수 있습니다 . 나는 개인적으로 UTF-16을 선택합니다. UTF-16은 공간과 복잡성 (UTF-8보다 더 타당한)과 합리적인 균형을 유지하기 때문입니다. 그러나 일부 문자 인코딩은 특정 경우에 여전히 의미가 있습니다.

• base64 텍스트를 저장 / 전송하는 경우 ASCII 만 있으면되며 전자 메일과 같은 7 비트 인코딩 프로토콜을 사용할 수도 있습니다. UTF-8의 추가 오버 헤드는 필요하지 않습니다.
• 이러한 오래된 문자 인코딩을 기반으로 여러 파일과 기존 데이터가 작성되므로 읽을 수 있어야합니다.

표준 UTF 정규화 알고리즘에는 4 가지가 있습니다. 다중 코드 포인트 문자가 걱정되는 경우 두 개의 정규화 알고리즘 중 하나를 사용하여 해당 코드를 동등한 단일 코드 포인트 문자로 축소 할 수 있습니다. 이들의 차이점은 논리적 동등성 대 문자의 물리적 동등성과 관련이 있습니다.