Tại sao có nhiều bảng mã Unicode?

Tôi nghĩ rằng Unicode được thiết kế để giải quyết toàn bộ vấn đề có nhiều mã hóa khác nhau do không gian địa chỉ nhỏ (8 bit) trong hầu hết các lần thử trước (ASCII, v.v.).

Tại sao sau đó có rất nhiều bảng mã Unicode? Ngay cả nhiều phiên bản của (về cơ bản) cùng một phiên bản, như UTF-8, UTF-16, v.v.

Bởi vì mọi người không muốn dành 21 bit cho mỗi nhân vật. Trên tất cả các hệ thống hiện đại, điều này về cơ bản có nghĩa là sử dụng ba byte cho mỗi ký tự, gấp ba lần so với những gì mọi người đã sử dụng, vì vậy họ không sẵn sàng chấp nhận Unicode. Các thỏa hiệp phải được tìm thấy: ví dụ UTF-8 rất phù hợp với văn bản tiếng Anh vì các tệp ASCII cũ không cần phải chuyển đổi, nhưng nó ít hữu ích hơn cho các ngôn ngữ châu Âu và ít sử dụng cho các ngôn ngữ châu Á.

Về cơ bản, vâng, chúng ta có thể đã định nghĩa một mã hóa phổ quát duy nhất cũng như một biểu đồ ký tự phổ quát duy nhất, nhưng thị trường sẽ không chấp nhận nó.

Unicode là một ký tự 21 bit mã hóa mô tả duy nhất "CodePoints" mỗi điểm mã được biểu thị bằng aa glyph (biểu diễn đồ họa).

• 16 bit được sử dụng để xác định một điểm mã trong mặt phẳng (hầu hết các điểm mã nằm trên mặt phẳng 0).
• 5 bit để xác định mặt phẳng.

Các mã hóa được hỗ trợ là:

• UTF-8 (để mã hóa từng điểm bằng các giá trị 8 bit)
• UTF-16 (để mã hóa từng điểm bằng các giá trị 16 bit)
• UTF-32 (để mã hóa từng điểm bằng các giá trị 32 bit)

Nhưng bất kể mã hóa là gì khi bạn giải mã tất cả chúng đều ánh xạ trở lại một loại tiền mã hóa cụ thể có cùng ý nghĩa (đó là lý do tại sao nó tuyệt vời).

• 'A' (U + 65)
  UTF-32 => 0x00000041 UTF-16 => 0x0041 UTF-8 => 0x41
• LATIN NHỎ LIGATURE OE '(U + 0153)
  UTF-32 => 0x00000153 UTF-16 => 0x0153 UTF-8 => 0xC5 0x93
• Chưa được gán (U + 11153)
  UTF-32 => 0x00011153 UTF-16 => 0xD804 0xDD53 UTF-8 => 0xF0 0x91 0x85 0x93

UTF-8

Đây là một định dạng có kích thước thay đổi. Trong đó mỗi codepoint được biểu thị bằng 1 đến 4 byte.

UTF-16

Đây là một định dạng có kích thước thay đổi. Các điểm mã trên "Mặt phẳng đa ngôn ngữ cơ bản" (BMP hoặc Mặt phẳng 0) có thể được biểu thị bằng 1 giá trị 16 bit đơn. Điểm mã trên các mặt phẳng khác được biểu thị bằng cặp thay thế (2 giá trị 16 bit).

UTF-32

Đây là một định dạng kích thước cố định. Tất cả các điểm mã được biểu thị bằng một giá trị 32 bit duy nhất.

Tôi nghĩ thật hữu ích khi tách 2 ý tưởng:

1. Unicode - ánh xạ các ký tự từ khắp nơi trên thế giới tới các điểm mã.
2. Mã hóa - ánh xạ các điểm mã đến các mẫu bit (UTF-8, UTF-16, v.v.).

UTF-8, UTF-16 và các bảng mã khác có mỗi ưu điểm và nhược điểm riêng. Tham khảo ý kiến ​​tốt hơn về Wikipedia .

UTF-7, UTF-8, UTF-16 và UTF-32 chỉ đơn giản là các định dạng chuyển đổi thuật toán của cùng một mã hóa ( mã hóa ) của các ký tự. Chúng là mã hóa của một hệ thống mã hóa các ký tự.

Chúng cũng dễ dàng hơn về mặt thuật toán để điều hướng tiến và lùi so với hầu hết các sơ đồ trước đây để xử lý các bộ ký tự lớn hơn 256 ký tự.

Điều này rất khác so với việc mã hóa glyphs nói chung theo quốc gia và đôi khi của nhà cung cấp. Chỉ riêng tiếng Nhật, đã có rất nhiều biến thể của riêng JIS, chưa kể đến EUC-JP và phép biến đổi theo định hướng mã hóa của JIS mà các máy DOS / Windows sử dụng được gọi là Shift-JIS. (Ở một mức độ nào đó, đã có các phép biến đổi thuật toán trong số này, nhưng chúng không đặc biệt đơn giản và có sự khác biệt cụ thể của nhà cung cấp về các ký tự có sẵn. Nhân số này với vài trăm quốc gia và sự phát triển dần dần của các hệ thống phông chữ phức tạp hơn (màn hình xanh lá cây thời đại), và bạn đã có một cơn ác mộng thực sự.

Tại sao bạn cần những dạng chuyển đổi này của Unicode? Do có rất nhiều hệ thống kế thừa giả định các chuỗi ký tự 7 bit trong phạm vi ASCII, nên bạn cần một giải pháp sạch 7 bit để truyền dữ liệu một cách an toàn qua các hệ thống đó, do đó bạn cần UTF-7. Sau đó, có các hệ thống hiện đại hơn có thể xử lý các bộ ký tự 8 bit, nhưng null thường có ý nghĩa đặc biệt với chúng, vì vậy UTF-16 không hoạt động với chúng. 2 byte có thể mã hóa toàn bộ mặt phẳng đa ngôn ngữ cơ bản của Unicode trong lần đầu tiên xuất hiện, do đó UCS-2 có vẻ như là một cách tiếp cận hợp lý cho các hệ thống sẽ được "nhận biết Unicode từ đầu" (như Windows NT và Java VM); sau đó các phần mở rộng vượt ra ngoài các ký tự bổ sung cần thiết, dẫn đến việc chuyển đổi thuật toán của mã hóa trị giá 21 bit được bảo lưu theo tiêu chuẩn Unicode và các cặp thay thế đã ra đời; bắt buộc phải có UTF-16. Nếu bạn có một số ứng dụng trong đó tính nhất quán của độ rộng ký tự quan trọng hơn hiệu quả lưu trữ, UTF-32 (từng được gọi là UCS-4) là một tùy chọn.

UTF-16 là điều duy nhất phức tạp từ xa phải đối phó và dễ dàng giảm thiểu bởi phạm vi nhỏ của các ký tự bị ảnh hưởng bởi phép chuyển đổi này và thực tế là các chuỗi 16 bit dẫn đầu nằm gọn trong một phạm vi hoàn toàn khác biệt so với dấu vết Chuỗi 16 bit. Thế giới cũng dễ dàng hơn là cố gắng tiến lên và lùi lại trong nhiều mã hóa Đông Á đầu tiên, nơi bạn cần một cỗ máy nhà nước (JIS và EUC) để xử lý các chuỗi thoát hoặc có thể di chuyển trở lại một số ký tự cho đến khi bạn tìm thấy thứ gì đó được đảm bảo chỉ là một byte dẫn (Shift-JIS). UTF-16 cũng có một số lợi thế trên các hệ thống có thể điều khiển các chuỗi 16 bit một cách hiệu quả.

Trừ khi bạn phải sống qua hàng tá (hàng trăm, thực sự) các mã hóa khác nhau ngoài kia hoặc phải xây dựng các hệ thống hỗ trợ nhiều ngôn ngữ trong các mã hóa khác nhau đôi khi ngay cả trong cùng một tài liệu (như WorldScript trong các phiên bản MacO cũ hơn), bạn có thể nghĩ của các định dạng chuyển đổi unicode là phức tạp không cần thiết. Nhưng đó là một sự giảm đáng kể về độ phức tạp so với các lựa chọn thay thế trước đó và mỗi định dạng giải quyết một hạn chế kỹ thuật thực sự. Chúng cũng thực sự có thể chuyển đổi hiệu quả giữa nhau, không yêu cầu bảng tra cứu phức tạp.

Unicode không được thiết kế để giải quyết toàn bộ vấn đề có nhiều bảng mã khác nhau.

Unicode được thiết kế để giải quyết toàn bộ vấn đề về một số đại diện cho nhiều thứ khác nhau tùy thuộc vào trang mã được sử dụng. Các số 0 - 127 đại diện cho các ký tự giống nhau trong bất kỳ trang mã Ansi nào. Đây là những gì còn được gọi là biểu đồ hoặc bộ ký tự ASCII. Trong các trang mã Ansi, cho phép 256 ký tự, các số 128 - 255 thể hiện các ký tự khác nhau trong các trang mã khác nhau.

Ví dụ

• Số $ 57 đại diện cho chữ W viết hoa trong tất cả các trang mã, nhưng
• Số $ EC đại diện cho biểu tượng không có giá trị trong trang mã 437 (Hoa Kỳ), nhưng "LATIN SMALL LETTER N VỚI CEDILLA" trong mã trang 775 (Baltic)
• Dấu hiệu Cent là số $ 9B trong mã trang 437, nhưng số 96 trong mã trang 775

Những gì Unicode đã làm, đã đảo ngược tất cả. Trong Unicode không có "tái sử dụng". Mỗi số đại diện cho một ký tự duy nhất. Số $ 00A2 bằng Unicode là ký hiệu cent và ký hiệu cent xuất hiện không ở đâu khác trong định nghĩa Unicode.

Tại sao sau đó có rất nhiều bảng mã Unicode? Ngay cả nhiều phiên bản của (về cơ bản) cùng một phiên bản, như UTF-8, UTF-16, v.v.

Không có nhiều phiên bản của cùng một mã hóa. Có nhiều bảng mã của cùng một bản đồ định nghĩa ký tự Unicode và chúng đã được "phát minh" để quản lý các yêu cầu lưu trữ cho các cách sử dụng khác nhau của các mặt phẳng ngôn ngữ khác nhau tồn tại trong Unicode.

Unicode định nghĩa (hoặc có không gian để xác định) 4.294.967.295 ký tự duy nhất. Nếu bạn muốn ánh xạ những thứ này vào bộ nhớ đĩa / bộ nhớ mà không thực hiện bất kỳ chuyển đổi thuật toán nào, bạn cần 4 byte cho mỗi ký tự. Nếu bạn cần lưu trữ văn bản với các ký tự từ tất cả các mặt phẳng ngôn ngữ, thì UTF-32 (về cơ bản là ký tự 1 ký tự - mã hóa lưu trữ 4 byte của định nghĩa unicode) có lẽ là thứ bạn cần.

Nhưng hầu như không có văn bản nào sử dụng các ký tự từ tất cả các mặt phẳng ngôn ngữ. Và sau đó sử dụng 4 byte cho mỗi ký tự có vẻ là một sự lãng phí lớn. Đặc biệt là khi bạn tính đến việc hầu hết các ngôn ngữ trên trái đất được xác định trong phạm vi được gọi là Mặt phẳng đa ngôn ngữ cơ bản (BMP): 65536 số đầu tiên của định nghĩa Unicode.

Và đó là nơi UTF-16 xuất hiện. Nếu bạn chỉ sử dụng các ký tự từ BMP, UTF-16 sẽ lưu trữ rất hiệu quả khi chỉ sử dụng hai byte cho mỗi ký tự. Nó sẽ chỉ sử dụng nhiều byte hơn cho các ký tự bên ngoài BMP. Sự khác biệt giữa UTF-16LE (Little Endian) và UTF-16BE (Big Endian) thực sự chỉ liên quan đến cách các số được biểu thị trong bộ nhớ máy tính (mẫu byte A0có nghĩa là hex $ A0 hoặc có nghĩa là $ 0A).

Nếu văn bản của bạn sử dụng ít ký tự khác nhau hơn, như hầu hết các văn bản trong các ngôn ngữ Tây Âu, bạn sẽ muốn hạn chế các yêu cầu lưu trữ cho văn bản của mình hơn nữa. Do đó UTF-8, sử dụng một byte đơn để lưu trữ các ký tự có trong biểu đồ ASCII (128 số đầu tiên) và lựa chọn từ các ký tự Ansi (128 số thứ hai của các trang mã khác nhau). Nó sẽ chỉ sử dụng nhiều byte hơn cho các ký tự bên ngoài bộ "ký tự được sử dụng nhiều nhất" này.

Vì vậy, để tóm tắt lại:

• Unicode là ánh xạ các ký tự trong tất cả các ngôn ngữ trên trái đất (và một số Klingon để khởi động) và sau đó một số (toán học, âm nhạc, v.v.) thành một số duy nhất.
• Mã hóa là các thuật toán được xác định để lưu trữ văn bản bằng cách sử dụng số của bản đồ ký tự duy nhất này một cách hiệu quả nhất có thể với "mức sử dụng trung bình" của các ký tự trong văn bản.

Unicode xác định bản đồ giữa số và ký tự. Tuy nhiên, khi bạn gửi một số đến một người nhận, bạn vẫn cần xác định cách thể hiện số đó. Đó là những gì UTF dành cho. Nó định nghĩa cách biểu diễn một số trong luồng byte.

Lý do đằng sau UTF-32 rất đơn giản: Đó là cách trình bày đơn giản nhất về các điểm mã Unicode. Vậy tại sao mọi thứ trong UTF-32 không? Hai lý do chính:

Một là kích thước . UTF-32 yêu cầu 4 byte cho mỗi ký tự. Đối với văn bản chỉ sử dụng các ký tự trong Vị trí đa ngôn ngữ cơ bản, đây là không gian gấp đôi so với UTF-16. Đối với văn bản tiếng Anh, nó gấp 4 lần dung lượng so với US-ASCII.

Lý do lớn hơn là khả năng tương thích ngược . Mỗi mã hóa Unicode khác với UTF-32 "không mã hóa" được thiết kế để tương thích ngược với một tiêu chuẩn trước đó.

• UTF-8: Khả năng tương thích ngược với US-ASCII.
• UTF-16: Khả năng tương thích ngược với UCS-2 (Unicode 16 bit trước khi được mở rộng ra ngoài BMP).
• UTF-7: Khả năng tương thích ngược với các máy chủ thư không phải là 8 bit.
• GB18030: Khả năng tương thích ngược với mã hóa GB2312 và GBK cho tiếng Trung.
• UTF-EBCDIC: Khả năng tương thích ngược với tập hợp con Latin cơ bản của EBCDIC.

Tôi nghĩ Unicode được thiết kế để giải quyết toàn bộ vấn đề có nhiều mã hóa khác nhau

Nó đã được, và nó đã làm. Việc chuyển đổi giữa UTF-8, -16 và -32 dễ dàng hơn nhiều so với hệ thống cũ gồm hàng trăm mã hóa ký tự khác nhau cho các ngôn ngữ khác nhau và các hệ điều hành khác nhau.

Bạn biết rằng một tệp zip có thể nén một tệp nhỏ hơn nhiều (đặc biệt là văn bản) và sau đó giải nén nó thành một bản sao giống hệt của tệp gốc.

Thuật toán nén thực sự có một số thuật toán khác nhau với các đặc điểm khác nhau để lựa chọn: được lưu trữ (không nén), Shrunk, Giảm (phương thức 1-4), Imploding, Tokenizing, Deflated, Deflate64, BZIP2, LZMA (EFS), WavPack, PPMd, về mặt lý thuyết có thể thử tất cả chúng và chọn kết quả tốt nhất nhưng thường chỉ đi với Deflated.

UTF hoạt động theo cùng một cách. Có một số thuật toán mã hóa, mỗi thuật toán có các đặc điểm khác nhau, nhưng bạn thường chỉ chọn UTF-8 vì nó được hỗ trợ rộng rãi trái ngược với các biến thể UTF khác, do đó nó tương thích bit với ASCII 7 bit giúp dễ dàng sử dụng trên hầu hết các nền tảng máy tính hiện đại thường sử dụng phần mở rộng 8 bit của ASCII.