Quản lý tương thích Unicode trên các thiết bị doanh nghiệp

Dưới đây là nội dung HTML đã được dịch sang tiếng Việt, giữ nguyên tất cả các thẻ HTML, thuộc tính, lớp, giá trị href, URL hình ảnh và ký tự biểu tượng cảm xúc. Chỉ dịch văn bản có thể đọc được của con người. Không dịch tên thương hiệu (Emojiguide, CLDR, Unicode, JoyPixels, Apple, Google, Samsung, Facebook, Twitter, Windows, Microsoft). Không dịch bất kỳ URL nào. Không thêm bình luận hoặc lời mở đầu; chỉ trả về HTML đã dịch.

Một phiếu yêu cầu hỗ trợ được gửi từ một máy MacBook bởi người dùng tên José đến bộ phận dịch vụ dưới dạng José, bị gán sai hàng đợi vì quy tắc định tuyến khớp với tên phòng ban, và sau đó không liên kết được với bản ghi tài sản vì tên máy chủ mà tác nhân khám phá báo cáo sử dụng một chuỗi byte khác cho cùng một ký tự có dấu. Ba lỗi riêng biệt, một nguyên nhân gốc rễ, và không lỗi nào trong số chúng sẽ xuất hiện trong môi trường thử nghiệm nơi mọi thiết bị đều là máy Windows en-US mới được cài đặt hình ảnh.

Khả năng tương thích Unicode trên các thiết bị doanh nghiệp không phải là vấn đề dịch thuật. Đó là vấn đề byte, và nó xuất hiện tại các điểm kết nối giữa các hệ thống, mỗi hệ thống đều được cấu hình riêng lẻ một cách chính xác.

Nơi mã hóa thực sự bị hỏng trong một đội thiết bị

Unicode 16.0 định nghĩa 154.998 ký tự. UTF-8 mã hóa tất cả chúng trong một đến bốn byte, và RFC 3629 giới hạn phạm vi ở U+10FFFF. Điều đó đã được giải quyết. Điều chưa được giải quyết là bất kỳ điểm cuối, tác nhân, cột cơ sở dữ liệu hoặc máy quét mã vạch nào trong môi trường của bạn sẽ làm gì khi gặp một byte trên 0x7F.

Sự cố hầu như không bao giờ xảy ra ở giữa một hệ thống. Nó xảy ra khi truyền tải: một tác nhân thu thập tên máy chủ, một tập lệnh ghi CSV, một API đăng JSON, một đồng bộ LDAP kéo tên hiển thị. Mỗi bước nhảy có thể mã hóa lại, và một bước nhảy mã hóa lại sai thường diễn ra âm thầm.

Bốn lớp lỗi đáng để phân biệt

Mojibake: sự không khớp ở cấp độ byte

Mẫu José cổ điển là các byte UTF-8 được đọc như CP1252. Hai byte, C3 A9, được giải thích từng cái một. Điều này có thể phục hồi được: các byte gốc còn nguyên vẹn, chúng chỉ bị gán nhãn sai, vì vậy việc giải mã lại sẽ sửa được dữ liệu. Đau đớn nhưng có thể sống sót.

Chuyển đổi mất mát

Trường hợp tệ hơn. Một cột VARCHAR của SQL Server với bảng mã Latin1_General chấp nhận một lệnh chèn chứa tên tiếng Cyrillic và lưu trữ các dấu hỏi. Không có lỗi, không có cảnh báo, và các byte gốc đã biến mất. Đây là chế độ lỗi khiến mọi người không tin tưởng vào CMDB của họ, vì sự hỏng hóc là vĩnh viễn và thao tác ghi dường như đã thành công.

Sự trôi dạt chuẩn hóa

Ký tự é có thể là U+00E9, một điểm mã duy nhất, hoặc U+0065 theo sau bởi U+0301, một chữ cái cơ bản cộng với một dấu phụ kết hợp. Cả hai đều hiển thị giống hệt nhau. Không cái nào bằng cái kia dưới phép so sánh byte hoặc kiểm tra bằng mặc định SQL. HFS+ thực thi dạng phân tách (NFD) trên tên tệp macOS, và mặc dù APFS không nhạy cảm với chuẩn hóa, các tệp và đường dẫn đã đi qua máy Mac tại bất kỳ thời điểm nào vẫn mang các chuỗi NFD. Windows và hầu hết các công cụ Linux tạo ra dạng kết hợp (NFC). Logic so sánh được định nghĩa trong Phụ lục Chuẩn Unicode số 15, và quy tắc thực tế là chuẩn hóa thành NFC khi nhập vào và không bao giờ so sánh các chuỗi thô từ hai nền tảng khác nhau.

Giới hạn lưu trữ đếm byte, không phải ký tự

Bộ ký tự có tên "utf8" của MySQL là utf8mb3: ba byte cho mỗi ký tự, bao phủ Mặt phẳng Đa ngữ Cơ bản và không có gì khác. Biểu tượng cảm xúc sống ở U+1F300 trở lên, vì vậy nội dung vé chứa một biểu tượng cảm xúc duy nhất sẽ kích hoạt lỗi 1366 và hủy bỏ lệnh chèn. MySQL 8.0 đã đặt utf8mb4 làm mặc định, nhưng nhiều lược đồ sản xuất được tạo trước đó và đã được nâng cấp tại chỗ. Java có một vấn đề liên quan: String là UTF-16, vì vậy một biểu tượng cảm xúc duy nhất là một cặp thay thế và String.length() trả về 2, có nghĩa là một trường xác thực ở "50 ký tự" có thể từ chối văn bản mà người dùng đếm là 48.

Hành vi mặc định trên một đội hỗn hợp

Bảng dưới đây là tài liệu tham khảo tôi sử dụng khi khách hàng báo cáo tên thiết bị bị hỏng và không ai có thể nói sự hỏng hóc xâm nhập ở đâu.

Hệ thống	Xử lý văn bản mặc định	Điều gì xảy ra với non-ASCII	Hậu quả thực tế
Windows 10/11 (ứng dụng kế thừa)	Trang mã ANSI, CP1252 trong en-US	Bất cứ thứ gì ngoài 0–255 đều bị mất hoặc được thay thế bằng "?"	Tên tài sản được thu thập bởi các tác nhân cũ hơn trả về bị hỏng; công tắc ngôn ngữ "Beta: Sử dụng Unicode UTF-8" khắc phục điều này nhưng làm hỏng một số ứng dụng kinh doanh
PowerShell 5.1	UTF-16LE cho chuyển hướng, ANSI cho Out-File	Mã hóa lại âm thầm giữa các giai đoạn đường ống	CSV kiểm kê được xuất bởi các tập lệnh trông ổn trong bảng điều khiển và sai trong cơ sở dữ liệu
PowerShell 7 / pwsh	UTF-8 không có BOM	Được bảo toàn	Chuẩn hóa các tập lệnh thu thập trên pwsh loại bỏ toàn bộ một lớp lỗi
macOS (di sản HFS+)	NFD cho tên tệp	Các ký tự kết hợp được tách thành chữ cái cơ bản + dấu phụ	Đường dẫn tệp từ máy Mac không khớp chuỗi với đường dẫn từ Windows ngay cả khi chúng trông giống hệt nhau
Linux (glibc, LANG=C)	ASCII	Các byte trên 0x7F bị từ chối hoặc được truyền qua không có kiểu	Các bộ thu thập chạy theo cron trên các máy chủ được bảo mật viết tên máy chủ bị hỏng cho đến khi LANG được đặt thành ngôn ngữ UTF-8
Bộ ký tự MySQL "utf8" (utf8mb3)	Tối đa 3 byte cho mỗi ký tự	Biểu tượng cảm xúc và một số phần mở rộng CJK bị từ chối hoàn toàn	Các bài gửi vé có biểu tượng cảm xúc thất bại với lỗi 1366 và toàn bộ lệnh chèn bị hủy bỏ
SQL Server VARCHAR + bảng mã không phải UTF8	Trang mã một byte	Các ký tự ngoài trang bảng mã trở thành "?"	Tên bị hỏng tại thời điểm ghi, vì vậy không có bản sửa lỗi hạ nguồn nào có thể khôi phục chúng
Máy quét mã vạch Code 128	ASCII / Latin-1 qua bàn phím giả	Các thẻ tài sản không phải Latin không thể được mã hóa	Việc gắn nhãn tài sản phải giữ nguyên ASCII bất kể CMDB hỗ trợ gì

Hai mục đáng được nhấn mạnh. PowerShell 5.1 đi kèm với Windows và âm thầm thay đổi mã hóa giữa bảng điều khiển, Out-File và các toán tử chuyển hướng, đó là lý do tại sao các tập lệnh thu thập hoạt động tương tác tạo ra CSV bị hỏng khi được lên lịch. Và Code 128, vẫn là ký hiệu thẻ tài sản thống trị, là một mã hóa 8-bit không có chế độ Unicode nào cả. Mã QR có thể mang UTF-8 qua chế độ ECI 26, nhưng hầu hết các máy quét bàn phím giả mặc định là ECI 3 (ISO-8859-1) và bỏ qua phần còn lại. Nếu thẻ tài sản của bạn phải tồn tại qua máy quét, hãy giữ chúng ở ASCII. Đó là một hạn chế phần cứng, không phải phần mềm.

Tại sao cơ sở dữ liệu thường là nút thắt cổ chai thực sự

Cấu hình điểm cuối nhận được sự chú ý vì nó có thể nhìn thấy. Lược đồ là nơi thiệt hại trở nên vĩnh viễn.

Một chuỗi phổ biến: CMDB được xây dựng trên MySQL 5.7 với các mặc định utf8mb3, bộ phận dịch vụ sau đó được mở cho một cổng tự phục vụ, người dùng bắt đầu dán văn bản từ Slack và Outlook, và các lỗi chèn xuất hiện trong nhật ký ứng dụng với tỷ lệ vài chục mỗi tuần. Giải pháp là chuyển đổi bộ ký tự, và nó không miễn phí.

Khắc phục	Nỗ lực điển hình	Thời gian chết	Ghi chú và sự đánh đổi
MySQL utf8mb3 sang utf8mb4	Vài giờ đến vài ngày tùy thuộc vào số lượng hàng	Vài phút với pt-online-schema-change, lâu hơn với ALTER tại chỗ	VARCHAR(255) tăng từ 765 lên 1020 byte, vượt quá tiền tố chỉ mục InnoDB 767 byte trên định dạng hàng COMPACT; chuyển đổi sang DYNAMIC trước hoặc rút ngắn các cột được lập chỉ mục xuống VARCHAR(191)
SQL Server VARCHAR sang NVARCHAR	Nhiều ngày, vì mã ứng dụng thay đổi theo nó	Xây dựng lại bảng cộng với kiểm thử hồi quy	Lưu trữ tăng gần gấp đôi cho văn bản Latin; các bảng mã UTF-8 SQL Server 2019 là một giải pháp thay thế rẻ hơn nếu dữ liệu chủ yếu là ASCII
Chuẩn hóa thành NFC khi ghi	Thấp, một đường dẫn mã nếu đầu vào được tập trung	Không có	Chỉ hoạt động nếu mọi đường dẫn nhập đều được bao phủ; một trình ghi cơ sở dữ liệu trực tiếp duy nhất sẽ giới thiệu lại các dạng hỗn hợp
Công tắc ngôn ngữ UTF-8 Windows	Thấp cho mỗi thiết bị, cao trong thử nghiệm	Một lần khởi động lại	Một số ứng dụng kế thừa giả định trang ANSI và bị hỏng; thử nghiệm trên 20 đến 30 máy trước khi triển khai toàn bộ đội
Thay thế máy quét bàn phím giả	Nhiều tuần, cộng với ngân sách phần cứng	Luân phiên	Chỉ hợp lý khi thẻ tài sản phải mang văn bản không phải Latin; thường rẻ hơn để giữ thẻ tài sản ở ASCII

Chi tiết chỉ mục InnoDB làm mọi người bất ngờ hơn bất cứ thứ gì khác trong danh sách đó. Chuyển đổi VARCHAR(255) từ utf8mb3 sang utf8mb4 làm tăng độ dài khóa tối đa từ 765 lên 1020 byte, vượt quá giới hạn tiền tố 767 byte trên các định dạng hàng COMPACT và REDUNDANT. ALTER thất bại giữa chừng trong một cửa sổ bảo trì. Kiểm tra định dạng hàng và chiều rộng chỉ mục trước khi lên lịch thay đổi, không phải trong khi thực hiện.

Kiểm toán trước khi bạn thay đổi bất cứ điều gì

Trước khi chạm vào ngôn ngữ hoặc bảng mã, hãy tìm hiểu những gì thực sự có trong dữ liệu. Năm kiểm tra bao phủ hầu hết các môi trường:

• Truy vấn CMDB để tìm các bản ghi chứa các chuỗi ký tự é, ü, ’ và . Mỗi cái là một dấu hiệu của một lỗi giải mã cụ thể, và đếm chúng cho bạn biết đường ống nào bị lỗi.
• So sánh các dạng NFC và NFD của mọi trường tên máy chủ và tên người dùng. Một sự khác biệt khác không có nghĩa là ít nhất một bộ thu thập đang viết văn bản đã phân tách.
• Liệt kê bộ ký tự và bảng mã của mọi cột, không chỉ mặc định của cơ sở dữ liệu. Các bảng mã hỗn hợp trong một lược đồ là phổ biến sau nhiều năm tạo bảng tùy ý.
• Kiểm tra mã hóa mà trình kết nối email đến của bạn giả định cho các tiêu đề không được mã hóa RFC 2047, vì một số lượng đáng ngạc nhiên các tích hợp bộ phận trợ giúp đoán.
• Lấy mẫu đầu ra khám phá từ ít nhất một thiết bị cho mỗi họ hệ điều hành và ngôn ngữ, bao gồm bất kỳ phân đoạn cách ly hoặc tại chỗ nào nơi các tác nhân được cài đặt nhiều năm trước và không bao giờ được cập nhật.

Điều cuối cùng quan trọng hơn nó nghe có vẻ. Các môi trường được quản lý, bệnh viện, mạng lưới thành phố và đặc biệt là hàng không, có xu hướng chạy các tác nhân cũ hơn trên các chu kỳ làm mới dài hơn, đó chính xác là nơi các giả định thời CP1252 tồn tại.

Nơi công cụ quản lý tài sản và dịch vụ phù hợp

Tính đúng đắn của mã hóa là một thuộc tính của toàn bộ chuỗi: tác nhân khám phá, truyền tải, cơ sở dữ liệu, giao diện người dùng, xuất khẩu. Một ngăn xếp được lắp ráp từ bốn nhà cung cấp cho bạn bốn nơi để làm sai và bốn hàng đợi hỗ trợ để tranh luận về lớp nào đã làm hỏng tên.

Đây là lập luận thực tế cho một nền tảng tích hợp. Khi kiểm kê mạng, quản lý tài sản và bộ phận dịch vụ chia sẻ một lược đồ và một bảng mã, không có bước nhảy mã hóa lại giữa khám phá và vé tham chiếu đến máy đã được khám phá.

Đối với các nhóm đang hợp nhất khám phá và bộ phận dịch vụ trên một lược đồ duy nhất, Alloy Software là một trong các lựa chọn thị trường trung cấp nơi kiểm kê, bản ghi tài sản và vé nằm trong cùng một cơ sở dữ liệu thay vì được ghép lại với nhau thông qua tích hợp; AlloyScan bao phủ vai trò khám phá phía đám mây mà sản phẩm Alloy Discovery tại chỗ cũ hơn từng đảm nhiệm. Câu hỏi liên quan khi đánh giá bất kỳ nền tảng nào như vậy là hẹp: tác nhân có báo cáo UTF-8 không, cơ sở dữ liệu có lưu trữ utf8mb4 hoặc NVARCHAR không, và xuất khẩu có ghi BOM khi mục tiêu là Excel trên Windows không.

Điểm cuối cùng đó đáng để kiểm tra trong một bản dùng thử. Excel trên Windows mở tệp CSV UTF-8 không có dấu thứ tự byte dưới dạng CP1252, biến một xuất khẩu sạch thành mojibake cho bất kỳ ai nhấp đúp vào nó. Một công cụ ghi BOM tránh được một vé hỗ trợ cho mỗi lần xuất khẩu; một công cụ luôn ghi nó sẽ làm hỏng các trình phân tích Unix đơn giản. Kiểm tra hành vi nào bạn nhận được và liệu nó có thể cấu hình được không.

Góc độ bảo mật mà không ai dự trù ngân sách

Khả năng tương thích Unicode trên các thiết bị doanh nghiệp cũng là một bề mặt tấn công. Chữ Cyrillic а (U+0430) và chữ Latin a (U+0061) giống hệt nhau về mặt thị giác trong hầu hết các phông chữ. Một tên máy chủ hoặc một tài khoản dịch vụ khác với một tài khoản hợp pháp bởi một homoglyph duy nhất sẽ vượt qua đánh giá của con người và sẽ không xung đột trong cơ sở dữ liệu coi hai cái là khác biệt. Các cuộc tấn công homograph IDN trên tên miền là phiên bản nổi tiếng; phiên bản nội bộ, nơi một bản ghi tài sản giả mạo che khuất một bản ghi thực, nhận được ít sự chú ý hơn nhiều.

Biện pháp đối phó là phát hiện tập lệnh hỗn hợp khi nhập. Đánh dấu bất kỳ tên máy chủ, tên người dùng hoặc thẻ tài sản nào có ký tự trải dài trên nhiều hơn một khối tập lệnh Unicode, trừ khi bản ghi thuộc hợp pháp về một ngôn ngữ pha trộn các tập lệnh. Đó là một kiểm tra rẻ và nó bắt được cả các cuộc tấn công và tai nạn sao chép-dán trung thực.

Những gì cần sửa trước

Thứ tự quan trọng, vì một số bản sửa làm cho những bản khác không cần thiết. Bắt đầu ở lớp lưu trữ: một cơ sở dữ liệu không thể chứa dữ liệu làm cho mọi bản sửa thượng nguồn trở nên mỹ phẩm. Sau đó chuẩn hóa khi ghi, vì sự trôi dạt chuẩn hóa là vô hình cho đến khi một phép nối thất bại. Sau đó chuẩn hóa các tập lệnh thu thập, di chuyển bất cứ thứ gì trên PowerShell 5.1 sang pwsh với một -Encoding utf8 rõ ràng trên mọi thao tác tệp. Các thay đổi ngôn ngữ điểm cuối đến cuối cùng và chỉ ở nơi một ứng dụng kế thừa thực sự yêu cầu trang ANSI.

Một lưu ý về tùy chọn ngôn ngữ UTF-8 Windows: nó vẫn được gắn nhãn beta trong Windows 11 và nó làm hỏng các ứng dụng gọi các API Win32 ANSI với các giả định trang mã được mã hóa cứng. Thử nghiệm nó trên 20 đến 30 máy qua các phòng ban trong một tháng đầy đủ trước bất kỳ triển khai toàn bộ đội nào, và giữ một đường dẫn khôi phục, vì chế độ lỗi là một ứng dụng sẽ không khởi động thay vì một ứng dụng hiển thị văn bản kỳ quặc.

Và chấp nhận rằng một số dữ liệu là không thể phục hồi. Các hàng được ghi qua một cột một byte nhiều năm trước chứa các dấu hỏi nơi tên từng tồn tại. Không có di chuyển nào mang chúng trở lại; chúng phải được thu thập lại từ thiết bị nguồn hoặc được sửa bằng tay.