UTF-16 có nên được coi là có hại?

Tôi sẽ hỏi điều gì có lẽ là một câu hỏi gây tranh cãi: "Liệu một trong những mã hóa phổ biến nhất, UTF-16, có được coi là có hại không?"

Tại sao tôi hỏi câu hỏi này?

Có bao nhiêu lập trình viên nhận thức được thực tế rằng UTF-16 thực sự là một mã hóa có độ dài thay đổi? Điều này có nghĩa là có những điểm mã, được biểu diễn dưới dạng cặp thay thế, lấy nhiều hơn một phần tử.

Tôi biết; Rất nhiều ứng dụng, khung và API sử dụng UTF-16, chẳng hạn như Chuỗi của Java, Chuỗi của C #, API Win32, thư viện GUI Qt, thư viện Unicode của ICU, v.v. trong số các ký tự ngoài BMP (các ký tự nên được mã hóa bằng hai phần tử UTF-16).

Ví dụ: cố gắng chỉnh sửa một trong các ký tự sau:

• ( U + 1D11E ) BIỂU TƯỢNG ÂM NHẠC
• ( U + 1D565 ) NHÂN ĐÔI TOÀN CẦU-MẠNH M SM NHỎ
• ( U + 1D7F6 ) TIẾNG VIỆT
• Nhân vật Han U ( U + 2008A )

Bạn có thể bỏ lỡ một số, tùy thuộc vào phông chữ bạn đã cài đặt. Các ký tự này đều nằm ngoài BMP (Mặt phẳng đa ngôn ngữ cơ bản). Nếu bạn không thể nhìn thấy các ký tự này, bạn cũng có thể thử xem chúng trong tham chiếu Ký tự Unicode .

Ví dụ: cố gắng tạo tên tệp trong Windows bao gồm các ký tự này; hãy thử xóa các ký tự này bằng "backspace" để xem cách chúng hoạt động trong các ứng dụng khác nhau sử dụng UTF-16. Tôi đã làm một số xét nghiệm và kết quả khá tệ:

• Opera có vấn đề với việc chỉnh sửa chúng (xóa 2 lần nhấn trên backspace)
• Notepad không thể xử lý chúng một cách chính xác (xóa 2 lần nhấn trên backspace)
• Chỉnh sửa tên tệp trong hộp thoại Window bị hỏng (xóa 2 lần nhấn trên backspace)
• Tất cả các ứng dụng QT3 không thể xử lý chúng - hiển thị hai ô vuông trống thay vì một biểu tượng.
• Python mã hóa các ký tự như vậy không chính xác khi được sử dụng trực tiếp u'X'!=unicode('X','utf-16')trên một số nền tảng khi X trong ký tự bên ngoài BMP.
• Python 2.5 unicodingata không nhận được các thuộc tính trên các ký tự như vậy khi python được biên dịch bằng chuỗi Unicode UTF-16.
• StackOverflow dường như loại bỏ các ký tự này khỏi văn bản nếu được chỉnh sửa trực tiếp dưới dạng các ký tự Unicode (các ký tự này được hiển thị bằng cách sử dụng mã HTML Unicode).
• WinForms TextBox có thể tạo chuỗi không hợp lệ khi bị giới hạn với MaxLạng.

Có vẻ như các lỗi như vậy cực kỳ dễ tìm thấy trong nhiều ứng dụng sử dụng UTF-16.

Vậy ... Bạn có nghĩ rằng UTF-16 nên được coi là có hại không?

Đây là một câu trả lời cũ.
Xem UTF-8 ở mọi nơi để cập nhật mới nhất.

Ý kiến: Có, UTF-16 nên được coi là có hại . Lý do chính nó tồn tại là bởi vì một thời gian trước đây đã từng có một niềm tin sai lầm rằng widechar sẽ là những gì UCS-4 bây giờ là.

Mặc dù "chủ nghĩa trung tâm" của UTF-8, nó nên được coi là mã hóa hữu ích duy nhất cho văn bản. Người ta có thể lập luận rằng mã nguồn của các chương trình, trang web và tệp XML, tên tệp hệ điều hành và các giao diện văn bản từ máy tính đến máy tính khác không bao giờ tồn tại. Nhưng khi họ làm, văn bản không chỉ dành cho độc giả của con người.

Mặt khác, chi phí UTF-8 là một cái giá nhỏ phải trả trong khi nó có lợi thế đáng kể. Các ưu điểm như khả năng tương thích với mã không biết chỉ chuyển qua chuỗi char*. Đây là một điều tuyệt vời. Có một vài ký tự hữu ích được SHORTER trong UTF-16 so với UTF-8.

Tôi tin rằng tất cả các mã hóa khác cuối cùng sẽ chết. Điều này liên quan đến việc MS-Windows, Java, ICU, python ngừng sử dụng nó làm mục ưa thích của họ. Sau thời gian dài nghiên cứu và thảo luận, các quy ước phát triển tại công ty của tôi cấm sử dụng UTF-16 ở bất cứ đâu ngoại trừ các lệnh gọi API OS và điều này mặc dù tầm quan trọng của hiệu suất trong các ứng dụng của chúng tôi và thực tế là chúng tôi sử dụng Windows. Các chức năng chuyển đổi đã được phát triển để chuyển đổi các UTF8 luôn được giả định std::stringthành UTF-16 gốc, bản thân Windows không hỗ trợ đúng cách .

Đối với những người nói " sử dụng những gì cần thiết khi cần thiết ", tôi nói: có một lợi thế rất lớn để sử dụng cùng một mã hóa ở mọi nơi và tôi thấy không có đủ lý do để làm khác. Cụ thể, tôi nghĩ rằng việc thêm wchar_tvào C ++ là một sai lầm và các bổ sung Unicode cho C ++ 0x cũng vậy. Điều phải được yêu cầu từ việc triển khai STL là mọi thông số std::stringhoặc char*tham số sẽ được coi là tương thích unicode.

Tôi cũng chống lại phương pháp " sử dụng những gì bạn muốn ". Tôi thấy không có lý do cho sự tự do như vậy. Có đủ sự nhầm lẫn về chủ đề của văn bản, dẫn đến tất cả các phần mềm bị hỏng này. Ở trên đã nói, tôi tin rằng các lập trình viên cuối cùng phải đạt được sự đồng thuận về UTF-8 như một cách thích hợp. (Tôi đến từ một quốc gia không nói tiếng ascii và lớn lên trên Windows, vì vậy tôi được mong đợi cuối cùng sẽ tấn công UTF-16 dựa trên cơ sở tôn giáo).

Tôi muốn chia sẻ thêm thông tin về cách tôi thực hiện văn bản trên Windows và những gì tôi khuyên mọi người khác để kiểm tra tính chính xác của unicode được kiểm tra thời gian biên dịch, dễ sử dụng và mã đa nền tảng tốt hơn. Gợi ý về cơ bản khác với những gì thường được đề xuất là cách sử dụng Unicode thích hợp trên các cửa sổ. Tuy nhiên, nghiên cứu sâu về các khuyến nghị này dẫn đến kết luận tương tự. Vì vậy, ở đây đi:

• Không sử dụng wchar_thoặc std::wstringở bất kỳ nơi nào khác ngoài điểm liền kề với API chấp nhận UTF-16.
• Không sử dụng _T("")hoặc L""UTF-16 lít (Những IMO này nên được đưa ra khỏi tiêu chuẩn, như là một phần của khấu hao UTF-16).
• Không sử dụng các loại, hàm hoặc các dẫn xuất của chúng nhạy với _UNICODEhằng số, chẳng hạn như LPTSTRhoặc CreateWindow().
• Tuy nhiên, _UNICODEluôn được xác định, để tránh truyền char*chuỗi cho WinAPI được biên dịch âm thầm
• std::stringsvà char*bất cứ nơi nào trong chương trình được coi là UTF-8 (nếu không nói khác)
• Tất cả các chuỗi của tôi là std::string, mặc dù bạn có thể chuyển char * hoặc chuỗi bằng chữ convert(const std::string &).

• chỉ sử dụng các hàm Win32 chấp nhận widechars ( LPWSTR). Không bao giờ những người chấp nhận LPTSTRhoặc LPSTR. Truyền tham số theo cách này:

  ::SetWindowTextW(Utils::convert(someStdString or "string litteral").c_str())
  

  (Chính sách sử dụng các chức năng chuyển đổi bên dưới.)

• Với dây MFC:

  CString someoneElse; // something that arrived from MFC. Converted as soon as possible, before passing any further away from the API call:
  
  std::string s = str(boost::format("Hello %s\n") % Convert(someoneElse));
  AfxMessageBox(MfcUtils::Convert(s), _T("Error"), MB_OK);
  

• Làm việc với các tệp, tên tệp và luồng trên Windows:

  • Không bao giờ vượt qua std::stringhoặc const char*tên tệp đối số cho fstreamgia đình. MSVC STL không hỗ trợ các đối số UTF-8, nhưng có phần mở rộng không chuẩn nên được sử dụng như sau:

  • Chuyển đổi std::stringđối số std::wstringvới Utils::Convert:

    std::ifstream ifs(Utils::Convert("hello"),
                      std::ios_base::in |
                      std::ios_base::binary);
    

    Chúng tôi sẽ phải xóa thủ công khi chuyển đổi khi thái độ của MSVC fstreamthay đổi.

  • Mã này không phải là đa nền tảng và có thể phải thay đổi bằng tay trong tương lai
  • Xem fstreamtrường hợp nghiên cứu / thảo luận unicode 4215 để biết thêm.
  • Không bao giờ tạo tệp xuất văn bản có nội dung không phải UTF8
  • Tránh sử dụng fopen()vì lý do RAII / OOD. Nếu cần thiết, sử dụng _wfopen()và các quy ước WinAPI ở trên.

// For interface to win32 API functions
std::string convert(const std::wstring& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

std::wstring convert(const std::string& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

// Interface to MFC
std::string convert(const CString &mfcString)
{
#ifdef UNICODE
    return Utils::convert(std::wstring(mfcString.GetString()));
#else
    return mfcString.GetString();   // This branch is deprecated.
#endif
}

CString convert(const std::string &s)
{
#ifdef UNICODE
    return CString(Utils::convert(s).c_str());
#else
    Exceptions::Assert(false, "Unicode policy violation. See W569"); // This branch is deprecated as it does not support unicode
    return s.c_str();   
#endif
}

Mật mã Unicode không phải là ký tự! Đôi khi chúng thậm chí không phải là glyphs (hình thức trực quan).

Vài ví dụ:

• Mật mã số La Mã như "". (Một ký tự đơn trông giống như "iii".)
• Các ký tự có dấu như "á", có thể được biểu thị dưới dạng một ký tự kết hợp duy nhất "\ u00e1" hoặc một ký tự và dấu phụ riêng biệt "\ u0061 \ u0301".
• Các ký tự như sigma chữ thường Hy Lạp, có các hình thức khác nhau cho giữa ("") và kết thúc ("") của các vị trí từ, nhưng nên được coi là từ đồng nghĩa cho tìm kiếm.
• Dấu gạch nối tùy ý Unicode U + 00AD, có thể hiển thị hoặc không hiển thị trực quan, tùy thuộc vào ngữ cảnh và được bỏ qua cho tìm kiếm ngữ nghĩa.

Cách duy nhất để có quyền chỉnh sửa Unicode là sử dụng thư viện được viết bởi một chuyên gia hoặc trở thành một chuyên gia và tự viết. Nếu bạn chỉ đang đếm mật mã, bạn đang sống trong tình trạng tội lỗi.

Có một quy tắc đơn giản về việc sử dụng Biểu mẫu chuyển đổi Unicode (UTF) nào: - utf-8 để lưu trữ và kết hợp - utf-16 để xử lý dữ liệu - bạn có thể sử dụng utf-32 nếu hầu hết API nền tảng bạn sử dụng là utf-32 (phổ biến trong thế giới UNIX).

Hầu hết các hệ thống ngày nay sử dụng utf-16 (Windows, Mac OS, Java, .NET, ICU, Qt). Cũng xem tài liệu này: http://unicode.org/notes/tn12/

Quay lại "UTF-16 là có hại", tôi sẽ nói: chắc chắn là không.

Những người sợ thay thế (nghĩ rằng họ chuyển đổi Unicode thành mã hóa có độ dài thay đổi) không hiểu được các phức tạp (cách lớn hơn) khác khiến việc ánh xạ giữa các ký tự và điểm mã Unicode rất phức tạp: kết hợp các ký tự, chữ ghép, bộ chọn biến thể , điều khiển nhân vật, v.v.

Chỉ cần đọc loạt bài này ở đây http://www.siao2.com/2009/06/29/9800913.aspx và xem UTF-16 trở thành một vấn đề dễ dàng như thế nào.

Chắc chắn rồi.

Tại sao? Nó phải làm với việc thực hiện mã .

Nếu bạn xem các số liệu thống kê sử dụng tiền mã hóa trên một kho dữ liệu lớn của Tom Christiansen, bạn sẽ thấy rằng các loại tiền mã hóa BMP 8 bit được sử dụng một số đơn đặt hàng nếu cường độ lớn hơn các loại tiền mã hóa không phải BMP:

 2663710 U+002013 ‹–›  GC=Pd    EN DASH
 1065594 U+0000A0 ‹ ›  GC=Zs    NO-BREAK SPACE
 1009762 U+0000B1 ‹±›  GC=Sm    PLUS-MINUS SIGN
  784139 U+002212 ‹−›  GC=Sm    MINUS SIGN
  602377 U+002003 ‹ ›  GC=Zs    EM SPACE

 544 U+01D49E ‹𝒞›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL C
 450 U+01D4AF ‹𝒯›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL T
 385 U+01D4AE ‹𝒮›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL S
 292 U+01D49F ‹𝒟›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL D
 285 U+01D4B3 ‹𝒳›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL X

Lấy câu lệnh TDD: "Mã chưa được kiểm tra là mã bị hỏng" và viết lại mã đó là "mã không được mã hóa là mã bị hỏng" và nghĩ rằng các lập trình viên thường phải xử lý các mật mã không phải BMP như thế nào.

Các lỗi liên quan đến việc không xử lý UTF-16 như một mã hóa có chiều rộng thay đổi có nhiều khả năng không được chú ý hơn các lỗi tương đương trong UTF-8 . Một số ngôn ngữ lập trình vẫn không đảm bảo cung cấp cho bạn UTF-16 thay vì UCS-2 và một số ngôn ngữ lập trình cấp cao cung cấp quyền truy cập vào các đơn vị mã thay vì điểm mã (thậm chí C được cho là cung cấp cho bạn quyền truy cập vào tiền mã hóa nếu bạn sử dụng wchar_t, bất kể một số nền tảng có thể làm gì).

Tôi muốn đề xuất rằng suy nghĩ UTF-16 có thể được coi là có hại nói rằng bạn cần hiểu rõ hơn về unicode .

Vì tôi đã bị hạ thấp vì trình bày ý kiến ​​của mình về một câu hỏi chủ quan, hãy để tôi giải thích. Chính xác thì điều gì làm phiền bạn về UTF-16? Bạn có thích nếu mọi thứ được mã hóa trong UTF-8? UTF-7? Hay làm thế nào về UCS-4? Tất nhiên một số ứng dụng nhất định không được thiết kế để xử lý mã ký tự everysingle ngoài kia - nhưng chúng là cần thiết, đặc biệt là trong miền thông tin toàn cầu ngày nay, để liên lạc giữa các ranh giới quốc tế.

Nhưng thực sự, nếu bạn cảm thấy UTF-16 nên được coi là có hại vì nó gây nhầm lẫn hoặc có thể được thực hiện không đúng cách (unicode chắc chắn có thể), vậy phương pháp mã hóa ký tự nào sẽ được coi là không có hại?

EDIT: Để làm rõ: Tại sao xem xét việc triển khai không đúng tiêu chuẩn phản ánh chất lượng của chính tiêu chuẩn? Như những người khác đã lưu ý sau đó, chỉ vì một ứng dụng sử dụng một công cụ không phù hợp, không có nghĩa là chính công cụ đó bị lỗi. Nếu đó là trường hợp, có lẽ chúng ta có thể nói những điều như "từ khóa var được coi là có hại" hoặc "luồng được coi là có hại". Tôi nghĩ rằng câu hỏi nhầm lẫn giữa chất lượng và bản chất của tiêu chuẩn với những khó khăn mà nhiều lập trình viên gặp phải khi thực hiện và sử dụng nó đúng cách, điều mà tôi cảm thấy xuất phát từ việc họ không hiểu cách thức hoạt động của unicode, thay vì unicode.

Không có gì sai với mã hóa Utf-16. Nhưng các ngôn ngữ coi các đơn vị 16 bit là ký tự có lẽ nên được coi là thiết kế tồi. Có một loại có tên ' char' mà không phải lúc nào cũng đại diện cho một nhân vật là khá khó hiểu. Vì hầu hết các nhà phát triển sẽ mong đợi một loại char đại diện cho một điểm mã hoặc ký tự, nhiều mã có thể sẽ bị phá vỡ khi tiếp xúc với các ký tự BMP.

Tuy nhiên, lưu ý rằng ngay cả khi sử dụng utf-32 không có nghĩa là mỗi điểm mã 32 bit sẽ luôn đại diện cho một ký tự. Do kết hợp các ký tự, một ký tự thực tế có thể bao gồm một số điểm mã. Unicode không bao giờ là tầm thường.

BTW. Có lẽ có cùng một loại lỗi với các nền tảng và ứng dụng dự kiến ​​các ký tự là 8 bit, được cho ăn Utf-8.

Lựa chọn cá nhân của tôi là luôn sử dụng UTF-8. Đó là tiêu chuẩn trên Linux cho hầu hết mọi thứ. Nó tương thích ngược với nhiều ứng dụng cũ. Có một chi phí rất nhỏ về không gian thêm được sử dụng cho các ký tự không phải là tiếng Latin so với các định dạng UTF khác và có một khoản tiết kiệm đáng kể trong không gian cho các ký tự Latin. Trên trang web, các ngôn ngữ Latin trị vì tối cao, và tôi nghĩ chúng sẽ cho tương lai gần. Và để giải quyết một trong những đối số chính trong bài viết gốc: gần như mọi lập trình viên đều biết rằng UTF-8 đôi khi sẽ có các ký tự nhiều byte trong đó. Không phải ai cũng giải quyết vấn đề này một cách chính xác, nhưng họ thường nhận thức được, điều này có thể nói nhiều hơn về UTF-16. Nhưng, tất nhiên, bạn cần chọn một ứng dụng phù hợp nhất cho ứng dụng của bạn. Đó là lý do tại sao có nhiều hơn một ở nơi đầu tiên.

Vâng, có một mã hóa sử dụng các ký hiệu kích thước cố định. Tôi chắc chắn có nghĩa là UTF-32. Nhưng 4 byte cho mỗi biểu tượng là quá nhiều không gian lãng phí, tại sao chúng ta sẽ sử dụng nó trong các tình huống hàng ngày?

Theo tôi, hầu hết các vấn đề xuất hiện từ thực tế là một số phần mềm nằm sau tiêu chuẩn Unicode, nhưng không nhanh chóng khắc phục tình trạng này. Opera, Windows, Python, Qt - tất cả chúng đều xuất hiện trước khi UTF-16 được biết đến rộng rãi hoặc thậm chí ra đời. Tuy nhiên, tôi có thể xác nhận rằng trong Opera, Windows Explorer và Notepad không có vấn đề gì với các nhân vật bên ngoài BMP nữa (ít nhất là trên PC của tôi). Nhưng dù sao, nếu các chương trình không nhận ra các cặp thay thế, thì chúng không sử dụng UTF-16. Bất cứ vấn đề nào phát sinh từ việc xử lý các chương trình như vậy, chúng không liên quan gì đến chính UTF-16.

Tuy nhiên, tôi nghĩ rằng các vấn đề của phần mềm cũ chỉ có hỗ trợ BMP là hơi cường điệu. Các nhân vật bên ngoài BMP chỉ gặp phải trong các trường hợp và khu vực rất cụ thể. Theo Câu hỏi thường gặp chính thức về Unicode , "ngay cả trong văn bản Đông Á, tỷ lệ các cặp thay thế phải ở mức trung bình dưới 1% của tất cả lưu trữ văn bản". Tất nhiên, các ký tự bên ngoài BMP không nên bị bỏ qua vì một chương trình không phù hợp với Unicode, nhưng hầu hết các chương trình không dành cho làm việc với các văn bản có chứa các ký tự đó. Đó là lý do tại sao nếu họ không ủng hộ nó, điều đó thật khó chịu, nhưng không phải là một thảm họa.

Bây giờ hãy xem xét sự thay thế. Nếu UTF-16 không tồn tại, thì chúng tôi sẽ không có mã hóa phù hợp với văn bản không phải ASCII và tất cả phần mềm được tạo cho UCS-2 sẽ phải được thiết kế lại hoàn toàn để vẫn tuân thủ Unicode. Cái sau rất có thể sẽ chỉ làm chậm việc áp dụng Unicode. Ngoài ra, chúng tôi sẽ không thể duy trì khả năng tương thích với văn bản trong UCS-2 giống như UTF-8 liên quan đến ASCII.

Bây giờ, đặt tất cả các vấn đề di sản sang một bên, các đối số chống lại chính mã hóa là gì? Tôi thực sự nghi ngờ rằng các nhà phát triển ngày nay không biết rằng UTF-16 có chiều dài thay đổi, nó được viết ở khắp mọi nơi với Wikipedia. UTF-16 khó phân tích cú pháp hơn nhiều so với UTF-8, nếu ai đó chỉ ra sự phức tạp là một vấn đề có thể xảy ra. Ngoài ra, thật sai lầm khi nghĩ rằng thật dễ gây rối khi xác định độ dài chuỗi chỉ trong UTF-16. Nếu bạn sử dụng UTF-8 hoặc UTF-32, bạn vẫn cần lưu ý rằng một điểm mã Unicode không nhất thiết phải có một ký tự. Ngoài ra, tôi không nghĩ rằng có bất cứ điều gì đáng kể chống lại mã hóa.

Vì vậy, tôi không nghĩ rằng bản thân mã hóa nên được coi là có hại. UTF-16 là một sự thỏa hiệp giữa đơn giản và gọn nhẹ, và không có hại trong việc sử dụng những gì cần thiết khi cần thiết . Trong một số trường hợp, bạn cần duy trì khả năng tương thích với ASCII và bạn cần UTF-8, trong một số trường hợp bạn muốn làm việc với các chữ tượng hình Han và bảo tồn không gian bằng UTF-16, trong một số trường hợp, bạn cần biểu diễn phổ biến các ký tự cho phép cố định- mã hóa chiều dài. Sử dụng những gì phù hợp hơn, chỉ cần làm đúng.

Nhiều năm hoạt động quốc tế hóa Windows đặc biệt là các ngôn ngữ Đông Á có thể đã làm hỏng tôi, nhưng tôi nghiêng về UTF-16 để thể hiện các chuỗi nội bộ trong chương trình và UTF-8 để lưu trữ mạng hoặc tệp tài liệu giống như văn bản. UTF-16 thường có thể được xử lý nhanh hơn trên Windows, do đó, đó là lợi ích chính của việc sử dụng UTF-16 trong Windows.

Bước nhảy vọt lên UTF-16 đã cải thiện đáng kể tính đầy đủ của các sản phẩm trung bình xử lý văn bản quốc tế. Chỉ có một vài trường hợp hẹp khi các cặp thay thế cần được xem xét (xóa, chèn và ngắt dòng, về cơ bản) và trường hợp trung bình chủ yếu là truyền thẳng. Và không giống như các mã hóa trước đó như các biến thể JIS, UTF-16 giới hạn các cặp thay thế trong phạm vi rất hẹp, do đó kiểm tra thực sự nhanh chóng và hoạt động tiến và lùi.

Cấp, nó cũng nhanh như vậy trong UTF-8 được mã hóa chính xác, quá. Nhưng cũng có nhiều ứng dụng UTF-8 bị hỏng mã hóa không chính xác các cặp thay thế thành hai chuỗi UTF-8. Vì vậy, UTF-8 cũng không đảm bảo sự cứu rỗi.

IE xử lý các cặp thay thế một cách hợp lý kể từ năm 2000 hoặc lâu hơn, mặc dù nó thường chuyển đổi chúng từ các trang UTF-8 sang một đại diện UTF-16 nội bộ; Tôi khá chắc chắn rằng Firefox cũng đã hiểu đúng, vì vậy tôi không thực sự quan tâm Opera làm gì.

UTF-32 (còn gọi là UCS4) là vô nghĩa đối với hầu hết các ứng dụng vì nó đòi hỏi nhiều không gian, do đó, nó gần như không thông minh.

UTF-8 chắc chắn là con đường để đi, có thể đi kèm với UTF-32 để sử dụng nội bộ trong các thuật toán cần truy cập ngẫu nhiên hiệu suất cao (nhưng bỏ qua việc kết hợp các ký tự).

Cả UTF-16 và UTF-32 (cũng như các biến thể LE / BE của chúng) đều gặp phải các vấn đề liên quan, vì vậy chúng không bao giờ được sử dụng bên ngoài.

UTF-16? chắc chắn có hại. Chỉ có hạt muối của tôi ở đây, nhưng có chính xác ba mã hóa được chấp nhận cho văn bản trong một chương trình:

• ASCII: khi xử lý những thứ cấp thấp (ví dụ: vi điều khiển) không thể mua được bất cứ thứ gì tốt hơn
• UTF8: lưu trữ trong phương tiện có chiều rộng cố định như tệp

• mã số nguyên ("CP"?): một mảng gồm các số nguyên lớn nhất thuận tiện cho ngôn ngữ lập trình và nền tảng của bạn (phân rã thành ASCII trong giới hạn độ phân giải thấp). Nên là int32 trên các máy tính cũ và int64 trên bất cứ thứ gì có địa chỉ 64 bit.

• Rõ ràng các giao diện cho mã kế thừa sử dụng mã hóa nào là cần thiết để làm cho mã cũ hoạt động đúng.

Unicode xác định các điểm mã lên tới 0x10FFFF (1.114.112 mã), tất cả các ứng dụng chạy trong môi trường đa ngôn ngữ xử lý các chuỗi / tên tệp, v.v. nên xử lý chính xác.

Utf-16 : chỉ bao gồm 1.112.064 mã. Mặc dù những người ở cuối Unicode là từ các mặt phẳng 15-16 (Khu vực sử dụng riêng). Nó không thể phát triển hơn nữa trong tương lai ngoại trừ phá vỡ khái niệm Utf-16 .

Utf-8 : bao gồm lý thuyết 2.216.757.376 mã. Phạm vi mã Unicode hiện tại có thể được biểu diễn bằng chuỗi 4 byte tối đa. Nó không gặp vấn đề với thứ tự byte , nó "tương thích" với ascii.

Utf-32 : bao gồm trên lý thuyết 2 ^ 32 = 4.294.967.296 mã. Hiện tại nó không được mã hóa chiều dài thay đổi và có thể sẽ không có trong tương lai.

Những sự thật là tự giải thích. Tôi không hiểu ủng hộ việc sử dụng chung của Utf-16 . Nó được mã hóa chiều dài thay đổi (không thể truy cập theo chỉ mục), nó có vấn đề để bao trùm toàn bộ phạm vi Unicode ngay cả hiện tại, thứ tự byte phải được xử lý, v.v. Tôi không thấy bất kỳ lợi thế nào ngoại trừ việc nó được sử dụng trong Windows và một số nơi khác. Mặc dù khi viết mã đa nền tảng, có lẽ tốt hơn là sử dụng Utf-8 nguyên bản và chỉ thực hiện chuyển đổi ở điểm cuối theo cách phụ thuộc nền tảng (như đã đề xuất). Khi cần truy cập trực tiếp theo chỉ mục và bộ nhớ không phải là vấn đề, nên sử dụng Utf-32 .

Vấn đề chính là nhiều lập trình viên xử lý Windows Unicode = Utf-16 thậm chí không biết hoặc bỏ qua thực tế rằng nó được mã hóa theo chiều dài thay đổi.

Cách thức thường có trong nền tảng * nix là khá tốt, chuỗi c (char *) được hiểu là mã hóa Utf-8 , chuỗi c rộng (wchar_t *) được hiểu là Utf-32 .

Thêm phần này vào danh sách:

Kịch bản được trình bày rất đơn giản (thậm chí đơn giản hơn vì tôi sẽ trình bày ở đây so với ban đầu!): 1.A WinForms TextBox nằm trên một Biểu mẫu, trống rỗng. Nó có MaxLpm được đặt thành 20 .

2. Người dùng nhập vào TextBox hoặc có thể dán văn bản vào đó.

3. Không có vấn đề gì khi bạn nhập hoặc dán vào TextBox, bạn bị giới hạn ở mức 20, mặc dù vậy nó sẽ phát ra tiếng bíp ở văn bản ngoài 20 (YMMV ở đây; tôi đã thay đổi sơ đồ âm thanh của mình để mang lại cho tôi hiệu ứng đó!).

4. Gói văn bản nhỏ sau đó được gửi đi nơi khác, để bắt đầu một cuộc phiêu lưu thú vị.

Bây giờ đây là một kịch bản dễ dàng, và bất cứ ai cũng có thể viết nó lên, trong thời gian rảnh rỗi. Tôi chỉ tự viết nó bằng nhiều ngôn ngữ lập trình bằng WinForms, vì tôi đã chán và chưa bao giờ thử nó trước đây. Và với văn bản bằng nhiều ngôn ngữ thực tế bởi vì tôi có dây theo cách đó và có nhiều bố cục bàn phím hơn bất kỳ ai trong toàn bộ vũ trụ kỳ dị.

Tôi thậm chí còn đặt tên cho hình thức Magic Thảm Ride , để giúp cải thiện sự nhàm chán.

Điều này đã không làm việc, cho những gì nó có giá trị.

Vì vậy, thay vào đó, tôi đã nhập 20 ký tự sau vào mẫu Magic Ride Ride của mình :

0123401234012340123

À ồ.

Ký tự cuối cùng đó là U + 20000, ký tự mở rộng B đầu tiên của Unicode (còn gọi là U + d840 U + dc00, với những người bạn thân của anh ta, người mà anh ta không xấu hổ khi bị loại bỏ, như trước đây) ....

Và bây giờ chúng tôi có một trò chơi bóng.

Bởi vì khi TextBox.MaxLpm nói về

Nhận hoặc đặt số lượng ký tự tối đa có thể được nhập thủ công vào hộp văn bản.

những gì nó thực sự có nghĩa là

Nhận hoặc đặt số lượng tối đa các đơn vị mã UTF-16 LE có thể được nhập thủ công vào hộp văn bản và sẽ cắt xén một cách không thương tiếc ra khỏi bất kỳ chuỗi nào cố gắng chơi các trò chơi dễ thương với khái niệm ngôn ngữ mà chỉ có ai đó bị ám ảnh như rằng đồng bào Kaplan sẽ thấy khó chịu (anh ta cần phải ra ngoài nhiều hơn!).

Tôi sẽ thử và xem về việc cập nhật tài liệu ....
Những độc giả thường xuyên nhớ sê-ri UCS-2 đến UTF-16 của tôi sẽ ghi nhận sự không vui của tôi với khái niệm đơn giản về TextBox.MaxLpm và cách xử lý tối thiểu trong trường hợp này trong đó hành vi hà khắc của nó tạo ra một chuỗi bất hợp pháp, một phần mà các phần khác của .Net Framework có thể tạo ra một

• System.Text.EncoderFallbackException: Không thể dịch ký tự Unicode \ uD850 tại chỉ mục 0 sang trang mã được chỉ định. *

ngoại lệ nếu bạn chuyển chuỗi này ở nơi khác trong .Net Framework (như đồng nghiệp của tôi Dan Thompson đang làm).

Bây giờ không sao, có lẽ loạt UCS-2 đến UTF-16 đầy đủ nằm ngoài tầm với của nhiều người.
Nhưng không hợp lý khi hy vọng rằng TextBox.Text sẽ không tạo ra System.Stringđiều đó sẽ không khiến một phần khác của .Net Framework bị ném? Ý tôi là, không có khả năng dưới dạng một sự kiện nào đó trên điều khiển cho bạn biết về việc cắt ngắn sắp tới nơi bạn có thể dễ dàng thêm xác thực thông minh hơn - xác thực mà chính điều khiển không bận tâm thực hiện. Tôi sẽ đi xa hơn để nói rằng sự kiểm soát punk này đang phá vỡ hợp đồng an toàn thậm chí có thể dẫn đến các vấn đề bảo mật nếu bạn có thể tạo ra các ngoại lệ không mong muốn để chấm dứt ứng dụng như một loại từ chối dịch vụ thô thiển. Tại sao bất kỳ quá trình hoặc phương pháp hoặc thuật toán hoặc kỹ thuật WinForms nào cũng tạo ra kết quả không hợp lệ?

Nguồn: Blog của Michael S. Kaplan MSDN

Tôi không nhất thiết phải nói rằng UTF-16 có hại. Nó không thanh lịch, nhưng nó phục vụ mục đích tương thích ngược với UCS-2, giống như GB18030 làm với GB2312 và UTF-8 làm với ASCII.

Nhưng thực hiện một thay đổi cơ bản đối với cấu trúc Unicode ở giữa dòng, sau khi Microsoft và Sun đã xây dựng các API khổng lồ xung quanh các ký tự 16 bit, là có hại. Việc không truyền bá nhận thức về sự thay đổi có hại hơn .

UTF-16 là sự thỏa hiệp tốt nhất giữa xử lý và không gian và đó là lý do tại sao hầu hết các nền tảng chính (Win32, Java, .NET) sử dụng nó để biểu diễn bên trong chuỗi.

Tôi chưa bao giờ hiểu quan điểm của UTF-16. Nếu bạn muốn đại diện hiệu quả nhất về không gian, hãy sử dụng UTF-8. Nếu bạn muốn có thể coi văn bản là độ dài cố định, hãy sử dụng UTF-32. Nếu bạn không muốn, hãy sử dụng UTF-16. Tệ hơn nữa, vì tất cả các ký tự phổ biến (mặt phẳng đa ngôn ngữ cơ bản) trong UTF-16 đều khớp với một điểm mã duy nhất, các lỗi cho rằng UTF-16 có độ dài cố định sẽ khó tìm và khó tìm, trong khi đó nếu bạn cố gắng thực hiện Điều này với UTF-8, mã của bạn sẽ thất bại nhanh và lớn ngay khi bạn cố gắng quốc tế hóa.

_{Vì tôi chưa thể bình luận, tôi đăng bài này như một câu trả lời, vì dường như tôi không thể liên lạc với các tác giả utf8everywhere.org. Thật xấu hổ khi tôi không tự động nhận được đặc quyền bình luận, vì tôi có đủ danh tiếng trên các stackexchanges khác.}

Điều này có nghĩa như là một nhận xét cho Ý kiến: Có, UTF-16 nên được coi là câu trả lời có hại .

Một chút điều chỉnh:

Để ngăn chặn việc vô tình đi qua một UTF-8 char*vào phiên bản ANSI-chuỗi các chức năng Windows API, ta nên xác định UNICODE, không _UNICODE. _UNICODEchức năng bản đồ như _tcslenđể wcslen, không MessageBoxđể MessageBoxW. Thay vào đó, UNICODEđịnh nghĩa sẽ chăm sóc cái sau. Để chứng minh, đây là từ WinUser.htiêu đề của MS Visual Studio 2005 :

#ifdef UNICODE
#define MessageBox  MessageBoxW
#else
#define MessageBox  MessageBoxA
#endif // !UNICODE

Ở mức tối thiểu, lỗi này cần được sửa utf8everywhere.org.

Lời đề nghị:

Có lẽ hướng dẫn nên chứa một ví dụ về việc sử dụng rõ ràng phiên bản Chuỗi rộng của cấu trúc dữ liệu, để làm cho nó dễ dàng bỏ lỡ / quên nó. Việc sử dụng các phiên bản chuỗi cấu trúc dữ liệu trên đầu sử dụng các phiên bản chức năng của chuỗi rộng khiến cho người ta vô tình gọi một phiên bản chuỗi ANSI của chức năng đó.

Ví dụ về ví dụ:

WIN32_FIND_DATAW data; // Note the W at the end.
HANDLE hSearch = FindFirstFileW(widen("*.txt").c_str(), &data);
if (hSearch != INVALID_HANDLE_VALUE)
{
    FindClose(hSearch);
    MessageBoxW(nullptr, data.cFileName, nullptr, MB_OK);
}

Có người nói UCS4 và UTF-32 giống nhau. Không như vậy, nhưng tôi biết ý của bạn. Một trong số đó là một mã hóa của người khác, mặc dù. Tôi ước họ đã nghĩ đến việc xác định sự tồn tại ngay từ đầu để chúng ta sẽ không có trận chiến cuối cùng ở đây. Họ không thể thấy điều đó sẽ đến sao? Ít nhất UTF-8 giống nhau ở mọi nơi (trừ khi có ai đó đang theo dõi thông số ban đầu với 6 byte).

Nếu bạn sử dụng UTF-16, bạn phải bao gồm việc xử lý các ký tự đa bào. Bạn không thể chuyển đến ký tự thứ N bằng cách lập chỉ mục 2N thành một mảng byte. Bạn phải đi bộ, hoặc có chỉ số nhân vật. Nếu không, bạn đã viết một lỗi.

Thông số dự thảo hiện tại của C ++ nói rằng UTF-32 và UTF-16 có thể có các biến thể nhỏ về cuối, cuối lớn và không xác định. Có thật không? Nếu Unicode đã chỉ định rằng tất cả mọi người phải làm endian nhỏ ngay từ đầu thì tất cả sẽ đơn giản hơn. (Tôi cũng sẽ ổn với người lớn cuối cùng.) Thay vào đó, một số người đã thực hiện nó theo cách này, cách khác, và bây giờ chúng tôi bị mắc kẹt với sự điên cuồng không vì điều gì. Đôi khi thật xấu hổ khi trở thành một kỹ sư phần mềm.

Tôi không nghĩ nó có hại nếu nhà phát triển đủ cẩn thận.
Và họ nên chấp nhận đánh đổi này nếu họ cũng biết rõ.

Là một nhà phát triển phần mềm Nhật Bản, tôi thấy UCS-2 đủ lớn và giới hạn không gian rõ ràng đơn giản hóa logic và giảm bộ nhớ thời gian chạy, vì vậy sử dụng utf-16 trong giới hạn UCS-2 là đủ tốt.

Có hệ thống tập tin hoặc ứng dụng khác giả định các điểm mã và byte theo tỷ lệ, do đó số lượng điểm mã thô có thể được đảm bảo phù hợp với một số lưu trữ kích thước cố định.

Một ví dụ là NTFS và VFAT chỉ định UCS-2 là mã hóa lưu trữ tên tệp của họ.

Nếu những ví dụ đó thực sự muốn mở rộng để hỗ trợ UCS-4, tôi có thể đồng ý sử dụng utf-8 cho mọi thứ, nhưng độ dài cố định có những điểm tốt như:

1. có thể đảm bảo kích thước theo chiều dài (kích thước dữ liệu và độ dài mã hóa tỷ lệ thuận)
2. có thể sử dụng số mã hóa để tra cứu băm
3. dữ liệu không nén có kích thước hợp lý (so với utf-32 / UCS-4)

Trong tương lai khi sức mạnh bộ nhớ / xử lý rẻ ngay cả trong bất kỳ thiết bị nhúng nào, chúng tôi có thể chấp nhận thiết bị bị chậm một chút do lỗi bộ nhớ cache thêm hoặc lỗi trang và sử dụng bộ nhớ thêm, nhưng điều này sẽ không xảy ra trong tương lai gần ...

"Một trong những mã hóa phổ biến nhất, UTF-16, có nên được coi là có hại không?"

Rất có thể, nhưng các lựa chọn thay thế không nhất thiết phải được xem là tốt hơn nhiều.

Vấn đề cơ bản là có nhiều khái niệm khác nhau về: glyphs, ký tự, điểm mã và chuỗi byte. Ánh xạ giữa mỗi cái này là không tầm thường, ngay cả với sự trợ giúp của một thư viện chuẩn hóa. (Ví dụ: một số ký tự trong các ngôn ngữ châu Âu được viết bằng chữ viết gốc Latinh không được viết bằng một bảng mã Unicode duy nhất. khó khăn; lỗi kỳ lạ sẽ được dự kiến ​​(và thay vì chỉ than vãn về chúng ở đây, hãy nói với những người bảo trì phần mềm liên quan).

Cách duy nhất mà UTF-16 có thể được coi là có hại trái ngược với UTF-8 là nó có một cách mã hóa điểm khác bên ngoài BMP (như một cặp thay thế). Nếu mã muốn truy cập hoặc lặp theo điểm mã, điều đó có nghĩa là nó cần phải nhận thức được sự khác biệt. OTOH, điều đó có nghĩa là một khối lượng đáng kể mã hiện có giả định "ký tự" luôn có thể phù hợp với số lượng hai byte - một giả định khá phổ biến, nếu sai, ít nhất có thể tiếp tục hoạt động mà không cần xây dựng lại tất cả. Nói cách khác, ít nhất bạn có thể thấy những nhân vật không được xử lý đúng!

Tôi đặt câu hỏi của bạn lên đầu và nói rằng toàn bộ shebang chết tiệt của Unicode nên được coi là có hại và mọi người nên sử dụng mã hóa 8 bit, ngoại trừ tôi đã thấy (trong 20 năm qua) dẫn đến điều đó: thật kinh khủng nhầm lẫn về các bảng mã ISO 8859 khác nhau, cộng với toàn bộ các bộ được sử dụng cho Cyrillic và bộ EBCDIC, và tốt, Unicode cho tất cả các lỗi của nó. Giá như đó không phải là một sự thỏa hiệp khó chịu giữa những hiểu lầm của các quốc gia khác nhau.