Một đề xuất mới cho Corrected UTF-8 nhằm khắc phục những gì người tạo ra nó coi là các lỗ hổng thiết kế cơ bản trong tiêu chuẩn mã hóa văn bản UTF-8 được sử dụng rộng rãi. Tuy nhiên, cộng đồng công nghệ đã phản ứng với sự hoài nghi đáng kể, nêu ra những lo ngại nghiêm trọng về tính tương thích và triển khai thực tế.
Đề xuất này cố gắng giải quyết ba vấn đề chính với UTF-8 hiện tại: loại bỏ các mã hóa quá dài từng gây ra các lỗ hổng bảo mật, loại bỏ hỗ trợ cho một số ký tự điều khiển và mã thay thế nhất định, và mở rộng không gian ký tự vượt ra ngoài giới hạn hiện tại. Mặc dù những mục tiêu này có thể nghe có vẻ hợp lý trên lý thuyết, phản ứng của cộng đồng cho thấy phương thuốc có thể tệ hơn căn bệnh.
Những Khác Biệt Chính So Với UTF-8 Chuẩn
- Khắc Phục Mã Hóa Quá Dài: Thêm các offset vào chuỗi đa byte thay vì từ chối những chuỗi không hợp lệ
- Loại Trừ Ký Tự: Không thể mã hóa các ký tự điều khiển C1 (U+0080-U+009F) hoặc Unicode surrogates (U+D800-U+DFFF)
- Mở Rộng Phạm Vi: Hỗ trợ mã hóa lên đến U+8421 109F (so với U+10 FFFF trong UTF-8 chuẩn)
- Magic Number: Sử dụng chuỗi 8-byte EF B7 9D ED B2 AE 00 0A để nhận diện văn bản UTF-8 đã được sửa lỗi
- Hạn Chế Kết Thúc Dòng: Cấm kết thúc dòng \r\n ( Windows ), chỉ yêu cầu kiểu Unix \n
Phá vỡ Tính tương thích Tạo ra Nhiều Vấn đề hơn là Giải quyết
Lời chỉ trích quan trọng nhất tập trung vào cách tiếp cận của đề xuất để khắc phục các mã hóa quá dài. Thay vì đơn giản từ chối các chuỗi không hợp lệ như UTF-8 hiện tại làm, hệ thống mới thêm các offset vào các chuỗi đa byte. Điều này có nghĩa là văn bản UTF-8 hiện có sẽ giải mã thành các ký tự hoàn toàn khác dưới hệ thống mới, trong khi văn bản đã sửa mới vẫn có thể được giải mã bởi các hệ thống UTF-8 cũ - chỉ là không chính xác.
Các thành viên cộng đồng chỉ ra rằng điều này tạo ra một tình huống nguy hiểm khi văn bản có vẻ hoạt động nhưng tạo ra kết quả sai. Sự phức tạp của việc xử lý các offset này, đặc biệt là xung quanh các khoảng trống trong không gian ký tự, sẽ làm cho các bộ mã hóa và giải mã phức tạp hơn nhiều so với hiện tại.
Dải Chuỗi Byte UTF-8 Đã Được Sửa Chữa
| Dải Chuỗi Byte | Offset | Dải Codepoint |
|---|---|---|
| 00...7F | 0 | 0000 0000...0000 007F |
| C0 80...DF BF | 160 | 0000 00A0...0000 089F |
| E0 80 80...EC BD 9F | 2,208 | 0000 08A0...0000 D7FF |
| EC BD A0...EF BF BF | 4,256 | 0000 E000...0001 109F |
| F0 80 80 80...F7 BF BF BF | 69,792 | 0001 10A0...0021 109F |
| F8 80 80 80 80...FB BF BF BF BF | 2,166,944 | 0021 10A0...0421 109F |
| FC 80 80 80 80 80...FD BF BF BF BF BF | 69,275,808 | 0421 10A0...8421 109F |
Loại bỏ Các ký tự Hợp lệ Gây ra Tranh cãi
Một khía cạnh gây tranh cãi khác liên quan đến việc cố ý làm cho một số ký tự Unicode không thể mã hóa được. Đề xuất bỏ qua hoàn toàn các ký tự điều khiển C1 và các Unicode surrogate, lập luận rằng chúng không nên xuất hiện trong văn bản bình thường. Tuy nhiên, quyết định này đã thu hút sự chỉ trích gay gắt từ các nhà phát triển cần xử lý dữ liệu cũ hoặc làm việc với các hệ thống hiện có.
Có vẻ như một đề xuất rất táo bạo khi cố ý có các codepoint không thể được mã hóa.
Hạn chế này mở rộng đến các ký tự phổ biến như tab ngang và carriage return, với đề xuất thậm chí còn cấm các kết thúc dòng kiểu Windows . Các nhà phê bình cho rằng điều này tạo ra những rào cản không cần thiết cho việc áp dụng và buộc các nhà phát triển từ chối văn bản hoàn toàn hợp lệ mà người dùng có thể cần xử lý.
Magic Number và Các mối lo Thực tế
Đề xuất bao gồm một magic number - một chuỗi byte đặc biệt xác định văn bản corrected UTF-8 , tương tự như byte order mark trong UTF-16 . Tuy nhiên, phản hồi từ cộng đồng cho thấy cách tiếp cận này đã tỏ ra có vấn đề trong thực tế. Những dấu hiệu này có xu hướng lẻn vào giữa các chuỗi văn bản và gây ra những vấn đề bất ngờ trong các ứng dụng thực tế.
Cộng đồng cũng đặt câu hỏi liệu việc mở rộng không gian ký tự có thực sự cần thiết hay không. Sự tăng trưởng Unicode hiện tại chủ yếu đến từ việc thêm nhiều ký tự Trung Quốc, Nhật Bản và Hàn Quốc hơn, nhưng sự mở rộng này sẽ không tiếp tục vô thời hạn. Với tốc độ phân bổ hiện tại, không gian hiện có sẽ kéo dài khoảng 600 năm.
Các giải pháp Thay thế Đã tồn tại
Một số thành viên cộng đồng đã chỉ ra các giải pháp hiện có giải quyết các vấn đề tương tự mà không phá vỡ tính tương thích. Tiêu chuẩn UCSX , được phát triển bởi các contributor Unicode thực sự, cung cấp mở rộng không gian ký tự khi cần thiết. Trong khi đó, một tiêu chuẩn IETF sắp tới sẽ cung cấp hướng dẫn về những ký tự Unicode nào nên tránh trong thực tế, giải quyết một số mối lo ngại tương tự mà không cần một mã hóa mới.
Thách thức cơ bản mà bất kỳ sự thay thế UTF-8 nào phải đối mặt là cơ sở hệ thống và dữ liệu hiện có khổng lồ. Thành công của UTF-8 đến từ việc hoàn toàn tương thích với ASCII trong khi xử lý tất cả các ký tự Unicode . Bất kỳ sự thay thế nào phá vỡ tính tương thích này đều phải đối mặt với một cuộc chiến khó khăn để được áp dụng, bất kể các ưu điểm kỹ thuật của nó.
Sự đồng thuận của cộng đồng có vẻ rõ ràng: mặc dù UTF-8 có thể có một số quirk lịch sử, lợi ích thực tế của một mã hóa mới không vượt trội hơn chi phí phân mảnh hệ sinh thái. Hiện tại, có vẻ như thế giới công nghệ sẽ tiếp tục sống với UTF-8 chưa được sửa chữa.
Tham khảo: Corrected UTF-8