Cạm bẫy font và ký tự Nhật — xử lý JIS2004, IVS và gaiji trong ứng dụng nghiệp vụ

“Ký tự 葛 trong danh sách khách hàng trông khác trên màn hình và trên biểu mẫu in. Khách phàn nàn dữ liệu chắc đã hỏng.” — Trong bảo trì hệ thống nghiệp vụ, kiểu tư vấn này không hiếm. Một kiểu phổ biến khác là “một ký tự trong tên người không hiện trên tài liệu chúng tôi nộp cho cơ quan. Trước đây nó hiện trên PC cũ; sau khi thay máy, nó thành □.”

Cả hai thường bị gọi là “mojibake” ngoài hiện trường, nhưng chúng khác vấn đề mojibake đến từ lệch mã hóa. Ở cái trước, không một bit dữ liệu nào đổi và chỉ diện mạo đổi; ở cái sau, một “gaiji” chỉ tồn tại trên PC đó đã mất.

flowchart TB
        accTitle: Hai cuộc tư vấn phổ biến thực sự là gì
        accDescr: Tư vấn rằng 葛 trông khác trên màn hình và trên biểu mẫu là trường hợp chỉ diện mạo đổi trong khi dữ liệu giữ nguyên; tư vấn rằng ký tự thành □ sau khi thay PC là trường hợp một gaiji chỉ tồn tại trên PC đó đã mất; cả hai đều khác vấn đề mojibake lệch mã hóa
        c1["Tư vấn 1: hình khác trên màn hình và trên biểu mẫu"] --> r1["Dữ liệu không đổi; chỉ diện mạo đổi"]
        c2["Tư vấn 2: thành □ sau khi thay máy"] --> r2["Một gaiji chỉ tồn tại trên PC đó đã mất"]
        r1 --> diff["Một vấn đề khác với mojibake mã hóa"]
        r2 --> diff

Hình 1: Hai cuộc tư vấn thường bị gọi là “mojibake” đều là vấn đề khác với lệch mã hóa.

Lời hứa của bài viết này đơn giản. Nếu bạn tách lớp mã ký tự (dữ liệu) khỏi lớp font (diện mạo), phần lớn rắc rối ký tự Nhật trở nên xử lý được. Từ thay đổi glyph JIS2004, ideographic variation selector (IVS), và gaiji (EUDC), qua nền tảng ký tự của chính phủ, tới chọn và nhúng font, được sắp xếp theo dạng nhà phát triển hệ thống nghiệp vụ và nhân viên IT có thể dùng để quyết.

Bản thân “mojibake” xảy ra khi chuyển Shift_JIS ↔ UTF-8 đã được các bài sẵn có trình bày, nên bài này tập trung vào vấn đề “mã đi vòng đúng, nhưng diện mạo hoặc khả năng hiển thị lệch”.

1. Kết luận trước

• “Mojibake” và “glyph khác” là hai vấn đề khác nhau. Mojibake là sự cố ở lớp dữ liệu vì hiểu sai dãy byte; khác glyph là sự cố ở lớp diện mạo vì khác glyph mà font giữ; cách chữa hoàn toàn khác.
• Dù cùng điểm mã Unicode, glyph được hiện phụ thuộc font. JIS X 0213:2004 đã sửa glyph mẫu của 168 ký tự như 葛, 辻, và 飴 về dạng chuẩn in, và Windows cũng lấy glyph JIS2004 làm mặc định trong MS Gothic / MS Mincho từ Vista trở đi.¹²
• Phương tiện chuẩn để khóa một glyph như dữ liệu là ideographic variation selector (IVS). Bạn chỉ định glyph bằng dãy ký tự gốc cộng bộ chọn từ U+E0100 trở đi; các bộ sưu tập như Adobe-Japan1, Hanyo-Denshi, và Moji_Joho (Character Information Platform) được đăng trong IVD của Unicode.³⁴
• Trong môi trường không hỗ trợ, hành vi quy định của IVS là bỏ qua bộ chọn và hiện glyph mặc định của ký tự gốc. Một ký tự mang IVS, tuy nhiên, có thể dài tới bốn đơn vị mã trong UTF-16, nên triển khai đếm ký tự và cắt chuỗi cần cẩn thận.⁵
• Gaiji (EUDC) có số phận “chỉ hiện được trên PC đó”. Không có nghĩa được thỏa thuận cho một điểm mã Private Use Area, và glyph đăng trong eudc.tte không đi sang PC khác, thư, hay PDF.⁶⁷
• Hệ thống xử lý tên người nên quyết bộ ký tự được chấp nhận và nêu rõ. Ở phía chính phủ, xây trên Ký tự Thống nhất Koseki và Character Information Platform, các hệ thống tuân chuẩn đang chuyển sang dùng “Ký tự Chuẩn cho Công vụ Hành chính”.⁸⁹¹⁰
• Với biểu mẫu và PDF, “khớp font với màn hình, và nhúng nó” là đường cơ sở. Việc nhúng có được phép không do giấy phép font (fsType) quyết, và PDF/A lưu trữ dài hạn bắt buộc nhúng font.¹¹¹²
• Đừng tùy tiện áp chuẩn hóa (NFKC) lên dữ liệu tên người. Thống nhất fullwidth và halfwidth, cùng thay ký tự tương thích, làm mất các phân biệt bạn phải giữ.¹³

Trong một câu: “bạn lưu dãy byte nào” là bài toán thiết kế dữ liệu; “nó trông thế nào” là bài toán thiết kế font. Nếu bàn hai thứ lẫn lộn, ngay cả vấn đề có thể sửa cũng trở nên không sửa được.

2. Nghĩ dữ liệu và diện mạo tách nhau — điểm mã và glyph

Trong Unicode, một ký tự được biểu diễn bằng một số gọi là điểm mã. 葛 là U+845B, và số này giống nhau trên mọi PC. Cách số đó được vẽ trên màn hình hay trên giấy, mặt khác, do glyph mà font giữ quyết. Việc cùng U+845B khác chi tiết hình giữa font A và font B là hành vi bình thường.

Với hai lớp này làm tiền đề, triệu chứng hiện trường có thể tách như sau.

Làm manh mối tách, nên nhớ khác biệt giữa “�” và “□”. “�” của U+FFFD (REPLACEMENT CHARACTER) là dấu vết thất bại chuyển ở lớp dữ liệu, và ký tự gốc đã mất. “□”, mặt khác, trong nhiều trường hợp chỉ là dữ liệu vẫn còn nhưng font không có glyph, và đổi font có thể làm nó hiện được.

flowchart TB
        accTitle: Tách triệu chứng theo � versus □
        accDescr: Khi một ký tự không hiện đúng, � là dấu vết thất bại chuyển ở lớp dữ liệu trong đó ký tự gốc đã mất; □ chỉ là dữ liệu vẫn còn nhưng font không có glyph, và đổi font có thể làm nó hiện được
        symptom["Một ký tự không hiện đúng"] --> which{"Bạn thấy gì?"}
        which -->|Bạn thấy �| datalayer["Sự cố lớp dữ liệu"]
        datalayer -.-> lost["Dấu vết thất bại chuyển（ký tự gốc đã mất）"]
        which -->|Bạn thấy □| viewlayer["Sự cố lớp diện mạo"]
        viewlayer -.-> noglyph["Chỉ là font không có glyph"]
        noglyph --> fixable["Đổi font có thể làm nó hiện được"]

Hình 2: � là dấu sự cố lớp dữ liệu, □ là sự cố lớp diện mạo, và điểm vào điều tra đổi.

Cơ bản của bản thân mã hóa (CP932 và UTF-8, BOM, mã xuống dòng) được trình bày trong “Dẫn nhập mã hóa văn bản Windows - Mojibake xảy ra khi tích hợp với Linux” và “Mã hóa văn bản Windows và kết thúc dòng - Cơ bản của mojibake và CRLF/LF”. Từ đây trở đi là lớp diện mạo, và các vấn đề xảy ra ở ranh giới của nó.

3. Từ JIS90 tới JIS2004 — glyph đổi trong khi mã giữ nguyên

Danh tính của câu mở “葛 trông khác trên màn hình và trên biểu mẫu”, trong nhiều trường hợp, nằm ở đây.

Theo báo cáo năm 2000 của Hội đồng Ngôn ngữ Quốc gia “Hyogai Kanji Jitaihyo” (bảng dạng chữ cho kanji ngoài danh sách joyo), bản sửa 2004 JIS X 0213:2004 (thường gọi JIS2004) đã sửa glyph mẫu của 168 kanji về dạng chuẩn in, gần với cái gọi là dạng Từ điển Khang Hy. 葛, 辻, 飴, 芦, 溢, 餅 và tương tự là ví dụ điển hình.¹

Windows khớp với điều này và lấy glyph JIS2004 làm mặc định trong MS Gothic / MS Mincho (và Meiryo mới đưa vào) từ Windows Vista trở đi. MS Gothic hiện tại cũng có glyph mặc định dựa trên JIS2004, với cấu trúc là glyph thời JIS90 truy cập được qua tính năng OpenType jp90.²¹

flowchart TB
        accTitle: Cấu trúc glyph của MS Gothic hiện tại
        accDescr: Từ Vista trở đi, MS Gothic có glyph JIS2004 làm mặc định, và truy cập glyph thời JIS90 qua tính năng OpenType jp90 là cấu trúc
        msg["MS Gothic（Vista trở đi）"] --> def["Glyph mặc định: dựa trên JIS2004"]
        msg --> feat["Qua tính năng jp90"]
        feat --> old["Glyph thời JIS90"]

Hình 3: MS Gothic hiện tại có glyph JIS2004 làm mặc định, và có thể chuyển sang glyph JIS90 bằng tính năng jp90.

Điều quan trọng ở đây là chỉ font đổi; dữ liệu không đổi chút nào.

• Điểm mã của 葛 là U+845B cả trên XP lẫn Windows 11
• Trên XP (glyph JIS90) nó hiện dạng đơn giản hóa phần trong bộ thủ bao thành ヒ; từ Vista trở đi (glyph JIS2004) nó hiện dạng cũng viết 人 bên trong
• Vì thế ảnh quét của biểu mẫu in trên hệ thống cũ và hiển thị màn hình trên PC mới không khớp về hình ký tự. So dữ liệu thì khớp hoàn toàn

Việc bộ thủ shinnyo của 辻 có một chấm hay hai, dạng bộ thủ “ăn” của 飴, và tương tự cũng vậy. Nếu không biết lịch sử này, điều tra dễ đi sai hướng “dữ liệu bị hỏng khi di chuyển”. Khi được nói diện mạo ký tự khác trước và sau di chuyển, hãy so điểm mã trước, và nếu chúng khớp, hãy nghi khác glyph font — đó là thứ tự đúng.

flowchart TB
        accTitle: Cùng điểm mã, glyph khác tùy font
        accDescr: Điểm mã U+845B của 葛 giữ nguyên cả trên XP lẫn Windows 11; chỉ hình hiện ra đổi giữa font glyph JIS90 và font glyph JIS2004, và so dữ liệu thì khớp hoàn toàn
        cp["Điểm mã U+845B（葛）"] --> f90["Font glyph JIS90（XP）"]
        cp --> f04["Font glyph JIS2004（Vista trở đi）"]
        f90 --> g90["Dạng đơn giản hóa phần trong thành ヒ"]
        f04 --> g04["Dạng chuẩn in viết 人 bên trong"]
        g90 -.-> same["So dữ liệu khớp hoàn toàn"]
        g04 -.-> same

Hình 4: Chỉ font đổi; điểm mã U+845B giữ nguyên ở mọi môi trường.

Lưu ý rằng vì bản thân ký tự không đổi, cả hai glyph đều là “cùng một ký tự”. Trong tên người, tuy nhiên, người đó hoặc cơ quan đôi khi khăng khăng một dạng cụ thể, và đáp yêu cầu phân biệt điều đó “như dữ liệu” là chủ đề tiếp theo, IVS.

4. Ideographic variation selector (IVS) — chỉ định glyph như dữ liệu

IVS (Ideographic Variation Sequence) là cơ chế đặt một điểm mã vô hình gọi là “ideographic variation selector” ngay sau một kanji, để chỉ định một biến thể glyph như dữ liệu. Các bộ chọn dùng là U+E0100–U+E01EF (VS17–VS256).³

Dãy “ký tự gốc + bộ chọn” nào trỏ tới glyph nào do một sổ đăng gọi là IVD (Ideographic Variation Database) quyết, do Unicode Consortium quản. Các bộ sưu tập chính như sau.⁴

Tài liệu của Microsoft, chẳng hạn, đưa ví dụ U+845B đơn (葛) được dùng trong cách viết Ga Nishi-Kasai, và U+845B+U+E0100 (VS17) được dùng trong cách viết Thành phố Katsuragi, Nara. Cùng 葛, nhưng glyph nào có thể phân biệt như dữ liệu.³

flowchart TB
        accTitle: Ví dụ phân biệt cùng 葛 như dữ liệu bằng IVS
        accDescr: 葛 như U+845B đơn được dùng trong cách viết Ga Nishi-Kasai; dãy U+845B theo sau VS17 được dùng trong cách viết Thành phố Katsuragi; dãy nào trỏ tới glyph nào do sổ đăng IVD quyết
        seq1["U+845B đơn"] --> gl1["Glyph dùng trong cách viết Ga Nishi-Kasai"]
        seq2["U+845B + VS17"] --> gl2["Glyph dùng trong cách viết Thành phố Katsuragi"]
        ivd["IVD（sổ đăng）"] -.-> gl1
        ivd -.-> gl2

Hình 5: Dù cùng 葛, có hay không bộ chọn cho phép bạn phân biệt glyph nào như dữ liệu.

4.1. Hành vi trong môi trường không hỗ trợ

Ở phía font, tương ứng giữa IVS và glyph được triển khai trong bảng cmap OpenType (định dạng 14).⁵ Khi vừa có font hỗ trợ (IPAmj Mincho và tương tự) vừa có ứng dụng hỗ trợ, glyph được chỉ định hiện ra; khi không, nó đi như sau.

• Hành vi đúng được quy định: bộ chọn bị bỏ qua và glyph mặc định của ký tự gốc được hiện (bản thân bộ chọn vô hình)
• Ứng dụng cũ và một số ngăn xếp vẽ: bộ chọn bị coi như ký tự lạ độc lập, và một □ thêm được hiện

Nói cách khác IVS được thiết kế để “dù xuống cấp, ký tự gốc vẫn đọc được”, nhưng bảo đảm rằng “nó luôn hiện đúng glyph được chỉ định” phụ thuộc môi trường phía nhận. Hệ thống hộ tịch và sổ hộ tịch chính phủ dùng kết hợp font Character Information Platform cộng IVS, nhưng nếu hệ thống nghiệp vụ thông thường nhận nó tùy tiện, glyph sẽ rơi ở đâu đó trên hiển thị, in, hoặc hệ thống hạ nguồn.

flowchart TB
        accTitle: Dữ liệu mang IVS được hiện thế nào
        accDescr: Khi vừa có font hỗ trợ vừa có ứng dụng hỗ trợ thì hiện đúng glyph được chỉ định; khi không, bộ chọn bị bỏ qua và glyph mặc định của ký tự gốc được hiện; ở ứng dụng cũ và một số ngăn xếp vẽ bộ chọn bị coi như ký tự lạ và một □ thêm được hiện
        ivs["Gốc + bộ chọn IVS"] --> env{"Font + ứng dụng hỗ trợ?"}
        env -->|Có| ok["Glyph được chỉ định"]
        env -->|Không| other{"Nó được vẽ thế nào?"}
        other -->|Bỏ qua| ignore["Glyph mặc định"]
        other -->|Cũ / một số ngăn xếp| tofu["Một □ thêm"]
        ignore -.-> spec["Đúng theo quy định"]

Hình 6: IVS vẫn đọc được như ký tự gốc dù xuống cấp, nhưng glyph được chỉ định có hiện hay không phụ thuộc môi trường phía nhận.

4.2. Lưu ý triển khai — “một ký tự” có thể dài tới bốn đơn vị mã

Các bộ chọn IVS từ U+E0100 trở đi là điểm mã trên supplementary plane, nên trong UTF-16 chúng luôn là cặp surrogate (hai đơn vị mã). Nếu ký tự gốc là kanji supplementary-plane (ví dụ 𠮟 (U+20B9F), thêm trong JIS2004), riêng gốc đã là hai đơn vị mã, và dãy mà người dùng nhận là “một ký tự” dài tới bốn đơn vị mã trong UTF-16, và tới tám byte trong UTF-8.

• "葛󠄀" của C# (葛+VS17) có string.Length == 3. Substring và cắt độ dài cố định có rủi ro tách ký tự gốc khỏi bộ chọn
• Kiểm tra số ký tự và cắt nên làm theo đơn vị grapheme (API như StringInfo), không theo đơn vị mã
• Với độ dài cột DB (nvarchar(n) của SQL Server tính theo đơn vị mã UTF-16), nếu chấp nhận IVS, hãy dự phòng gấp hai tới bốn lần số ký tự bề ngoài
• Trong tìm kiếm và so sánh, có hay không bộ chọn tạo thành chuỗi khác. Việc tìm “葛” có trúng “葛+VS17” hay không là điều bạn cần quyết như yêu cầu rồi triển khai

flowchart TB
        accTitle: Một ký tự mang IVS và đơn vị mã UTF-16
        accDescr: Dãy ký tự gốc và ideographic variation selector mà người dùng nhận là một ký tự luôn là cặp surrogate cho bộ chọn, và nếu ký tự gốc là kanji supplementary-plane thêm hai đơn vị mã nữa, tối đa bốn đơn vị mã trong UTF-16
        one["Một ký tự nhìn thấy"] --> base["Ký tự gốc"]
        one --> vs["Variation selector"]
        base -.-> bnote["+2 nếu supplementary"]
        vs -.-> vnote["Luôn 2 đơn vị mã"]
        base --> total["Tới 4 đơn vị UTF-16"]
        vs --> total
        total -.-> risk["Bị tách khi cắt cố định"]

Hình 7: Một ký tự mang IVS có thể dài tới bốn đơn vị mã trong UTF-16; cắt theo đơn vị mã thì nguy hiểm.

5. Gaiji (EUDC) — ký tự chỉ hiện trên PC đó

Gaiji là cơ chế người dùng gán một glyph của riêng họ cho một điểm mã trong Unicode Private Use Area (PUA: U+E000–U+F8FF và tương tự). Một điểm mã Private Use Area không có nghĩa được thỏa thuận toàn cầu; cùng U+E000 có thể được gán ký tự khác trên từng PC và từng tổ chức.⁶

Trên Windows bạn tạo glyph bằng Private Character Editor (eudcedit.exe), và nó được lưu trong tệp font tên eudc.tte. Tệp này được cài như font ẩn và gắn với từng font trong registry HKEY_CURRENT_USER\EUDC.⁷ Thời Shift_JIS (CP932) dải gaiji là 0xF040–0xF9FC, và khi chuyển sang Unicode nó được ánh xạ vào Private Use Area.

Hệ quả của cơ chế này rõ ràng.

• eudc.tte thuộc PC đó (người dùng đó) và không đi cùng dữ liệu sang phía kia
• Ngay khi chuyển sang thư, PDF, Web, hoặc hệ thống khác, nó thành □ hoặc trông như gaiji khác của phía kia
• Nếu quên di chuyển eudc.tte khi nâng OS hoặc thay PC, “một ký tự hiện trên PC cũ sẽ không hiện” xảy ra

Đó là danh tính của cuộc tư vấn thứ hai ở phần mở.

flowchart TB
        accTitle: Vì sao gaiji chỉ hiện trên PC đó
        accDescr: Một glyph tạo trong Private Character Editor được lưu trong eudc.tte và gắn với font trong registry của PC đó, nên nếu chỉ mã Private Use Area được chuyển sang thư, PDF, hoặc hệ thống khác thì nó thành □ hoặc trông như ký tự khác
        edit["Tạo một glyph PUA"] --> tte["Lưu trong eudc.tte"]
        edit -.-> editN["Private Char. Editor"]
        tte --> reg["Ánh xạ font registry"]
        reg --> local["Hiện trên PC đó"]
        tte -.-> stay["eudc.tte ở lại"]
        send["Chỉ mã PUA đi"] --> dest["Thư / PDF / hệ khác"]
        dest --> broken["□ hoặc ký tự sai"]
        local ~~~ send

Hình 8: Glyph sống trong eudc.tte; chỉ một số Private Use Area còn trong dữ liệu, nên gaiji trông hỏng khi rời PC.

5.1. Câu trả lời thực tế cho hệ thống đã nhận gaiji

Vấn đề là khi dữ liệu thừa kế từ hệ thống cũ đã lẫn gaiji. Thủ tục chúng tôi khuyến nghị trên các cuộc di chuyển như sau.

1. Điều tra: quét cơ sở dữ liệu và tệp bằng biểu thức chính quy cho Private Use Area (U+E000–U+F8FF), và kiểm kê mã gaiji đang dùng cùng số lượng. Thu thập eudc.tte từ PC tại từng địa điểm và xác nhận glyph
2. Nhận diện: với từng gaiji, điều tra “có thể biểu diễn như ký tự Unicode thông thường không”, “có thể biểu diễn bằng IVS không”, “có ký tự tương ứng trong Character Information Platform (MJ) không”, và lập bảng tương ứng ký tự thay thế. Trong thực tế đa số trường hợp chỉ là một dạng cũ đã được làm thành gaiji JIS
3. Thay: thay dữ liệu từ bảng tương ứng. Chỉ khi thật sự không có ký tự tương ứng, giữ như ảnh hoặc gắn ghi chú vào bản ghi đó
4. Cắt: trong hệ thống mới, từ chối nhập Private Use Area lúc kiểm tra, và không tạo gaiji mới

flowchart TB
        accTitle: Thủ tục di chuyển dữ liệu chứa gaiji
        accDescr: Kiểm kê gaiji đang dùng bằng cách quét Private Use Area và thu thập eudc.tte, lập bảng tương ứng ký tự thay thế rồi thay, và trong hệ thống mới từ chối nhập Private Use Area lúc kiểm tra và không tạo gaiji mới
        st1["Điều tra: quét PUA"] --> st2["Nhận diện: bảng thay"]
        st2 --> st3["Thay từ bảng"]
        st3 --> st4["Cắt: không gaiji mới"]
        st1 -.-> tte["Thu thập eudc.tte"]
        st2 -.-> nomap["Không có ánh xạ: ảnh hoặc ghi chú"]

Hình 9: Di chuyển gaiji theo bốn bước điều tra, nhận diện, thay, và cắt, và không tạo gaiji mới.

Hướng cũng vậy ở phía chính phủ: đã nêu chính sách nhận diện duy nhất các gaiji mà đô thị tự tạo (nói là khoảng hai triệu ký tự trên cả nước) đối với Ký tự Chuẩn cho Công vụ Hành chính mô tả sau, và dừng dùng chúng.¹⁰ “Đừng tăng gaiji; nhận diện chúng đối với một bộ ký tự đã chuẩn hóa” đang trở thành mẫu di chuyển ổn định cả khu vực công lẫn tư.

6. Nền tảng ký tự chính phủ — từ Ký tự Thống nhất Koseki tới Ký tự Chuẩn cho Công vụ Hành chính

Trong thiết kế hệ thống xử lý tên người, biết nền tảng ký tự phía chính phủ trở thành tư liệu để quyết “chấp nhận tới đâu”.

Trong hệ thống nghiệp vụ cốt lõi đô thị (hệ thống tuân chuẩn), một cấu trúc hai tầng nằm trong đặc tả chuẩn: dùng Ký tự Chuẩn cho Công vụ Hành chính cho liên thông thông tin tên người và tương tự, và liên thông với hệ thống bên ngoài không có quy tắc liên thông thống nhất — điện thoại thông minh và tương tự — trong phạm vi JIS X 0213:2012.¹⁰ Bản thân cấu trúc “giữ bộ ký tự rộng bên trong, và trao đổi với bên ngoài trong phạm vi môi trường thông thường hiện được” cũng là tham chiếu cho hệ thống tư nhân.

flowchart TB
        accTitle: Liên thông hai tầng của hệ thống tuân chuẩn
        accDescr: Hệ thống đô thị tuân chuẩn dùng Ký tự Chuẩn cho Công vụ Hành chính cho liên thông thông tin tên người và tương tự, và liên thông với hệ thống bên ngoài như điện thoại thông minh không có quy tắc liên thông thống nhất trong phạm vi JIS X 0213:2012
        sys["Hệ thống chuẩn đô thị"] --> renkei["Liên thông tên"]
        sys --> gaibu["Hệ thống bên ngoài"]
        renkei --> mjp["Ký tự chuẩn hành chính"]
        mjp -.-> mjpN["Tên người v.v."]
        gaibu --> jis["Phạm vi JIS X 0213:2012"]
        gaibu -.-> sumaho["Không quy tắc（điện thoại thông minh）"]
        mjp -.-> naibu["Bộ rộng giữ bên trong"]

Hình 10: Cấu trúc hai tầng: liên thông chính phủ dùng Ký tự Chuẩn cho Công vụ Hành chính; liên thông bên ngoài không quy tắc dùng JIS X 0213:2012.

Làm hướng dẫn thực tế cho hệ thống nghiệp vụ thông thường, chúng tôi khuyến nghị như sau.

• Quyết bộ ký tự được chấp nhận và nêu cả trong đặc tả lẫn kiểm tra nhập. Ví dụ “phạm vi JIS X 0213:2012”, “Private Use Area và ký tự kết hợp không được phép”, “IVS không được chấp nhận (hoặc được chấp nhận, nhưng hiển thị chỉ được bảo đảm trong môi trường IPAmj Mincho)”
• Đừng chấp nhận không giới hạn. Thiết kế “đây là Unicode, nên cái gì cũng được” sẽ vỡ ở đâu đó trên hiển thị, in, hoặc liên thông
• Quyết vận hành cho ký tự ngoài phạm vi từ trước. Quy tắc thay biểu diễn thay thế (dạng mới, katakana) và lời bạn giải thích với người đó bản thân là đặc tả hệ thống
• Khi một hệ thống hạ nguồn như chính phủ hoặc tài chính có quy tắc bộ ký tự, lấy đó làm chuẩn và khớp theo

flowchart TB
        accTitle: Thiết kế và vận hành bộ ký tự được chấp nhận
        accDescr: Quyết bộ ký tự được chấp nhận và nêu cả trong đặc tả lẫn kiểm tra nhập; chấp nhận ký tự trong phạm vi; với ký tự ngoài phạm vi, quyết vận hành gồm quy tắc thay biểu diễn thay thế và lời bạn giải thích với người đó
        decide["Quyết bộ ký tự được chấp nhận"] --> spec["Nêu trong đặc tả"]
        decide --> valid["Nêu trong kiểm tra nhập"]
        valid --> range{"Trong phạm vi?"}
        range -->|Có| ok["Chấp nhận"]
        range -->|Không| alt["Thay bằng biểu diễn thay thế"]
        alt -.-> word["Lời bạn giải thích với người đó cũng là đặc tả"]

Hình 11: Nêu bộ ký tự được chấp nhận cả trong đặc tả lẫn kiểm tra nhập, và cũng quyết vận hành ngoài phạm vi.

7. Chọn và nhúng font — khớp màn hình và biểu mẫu

7.1. Tính cách của các font thông thường

Điều quan trọng khi chọn không phải sở thích mặt chữ mà là font đó có tồn tại trên mọi môi trường liên quan tới hiển thị, in, và tạo PDF không. Font bổ sung tiếng Nhật trên Windows 10/11 (BIZ UD và tương tự) đôi khi không có tùy cấu hình, và trong cấu hình tạo PDF phía máy chủ, có hay không font trên máy chủ tác động trực tiếp.

flowchart TB
        accTitle: Các môi trường cần xác nhận khi chọn font
        accDescr: Khi chọn font, điều quan trọng không phải sở thích mặt chữ mà là font đó có tồn tại trên mọi môi trường liên quan tới hiển thị, in, và tạo PDF không; cấu hình font bổ sung và có hay không font trên máy chủ tác động trực tiếp
        cand["Một font ứng viên"] --> exist["Trên mọi môi trường?"]
        exist --> scr["Môi trường hiển thị"]
        exist --> more{"Máy in hoặc máy chủ PDF?"}
        more --> prn["Môi trường in"]
        more --> srv["Máy chủ tạo PDF"]
        scr -.-> hojo["Font bổ sung?"]
        hojo -.-> hojoN["Có thể vắng"]
        srv -.-> eikyo["Font trên máy chủ quan trọng"]

Hình 12: Chọn font ít theo sở thích mặt chữ hơn là theo việc nó có mặt trên mọi môi trường hiển thị, in, và tạo PDF.

7.2. Cơ bản thiết kế biểu mẫu — khớp, và nhúng

• Chỉ định cùng font trên màn hình và trên biểu mẫu. Nếu font khác, cùng dữ liệu có thể trông như glyph khác, và bạn nhận lời phàn nàn ở phần mở. Cấu hình như “Meiryo trên màn hình, MS Mincho trên biểu mẫu” ít nhất nên được kiểm xem có khác glyph trên 168 ký tự JIS2004 không
• Nhúng font vào PDF. Nếu không nhúng, phía xem vẽ thay bằng font sẵn có, và không chỉ glyph mà cả bố cục có thể đổi
• Việc nhúng có được phép không do giấy phép quyết. Font OpenType khai báo quyền nhúng trong trường fsType (Installable / Restricted / Preview & Print / Editable, no-subsetting, và tương tự), và bạn không được nhúng font mà việc nhúng không được cấp phép.¹¹ Với font thương mại, xác nhận hợp đồng là bắt buộc
• Lấy nhúng tập con làm đường cơ sở. Nếu chỉ nhúng glyph của các ký tự được dùng, bạn không phải gánh cả một font Nhật (vài MB tới hàng chục MB)
• Nếu có yêu cầu lưu trữ dài hạn, PDF/A. PDF/A (ISO 19005) là chuẩn hoàn tất các tài nguyên cần để hiển thị bên trong tệp, và nhúng font là bắt buộc.¹² Đó cũng là cách đáng tin nhất để ngăn “mười năm sau tôi mở ra và glyph đã đổi”

flowchart TB
        accTitle: Luồng quyết định nhúng font
        accDescr: Trước khi nhúng font vào PDF, xác nhận giấy phép nhúng fsType; nếu được cấp phép, lấy nhúng tập con làm đường cơ sở; nếu có yêu cầu lưu trữ dài hạn, cân nhắc PDF/A, vốn bắt buộc nhúng
        emb["Nhúng font vào PDF"] --> lic{"Nhúng có được fsType cấp phép?"}
        lic -->|Được cấp phép| sub["Nhúng tập con là đường cơ sở"]
        lic -->|Không được cấp phép| ng["Bạn không được nhúng"]
        sub -.-> gly["Chỉ glyph của các ký tự được dùng"]
        sub -->|Yêu cầu lưu trữ dài hạn| pdfa["Cân nhắc PDF/A"]
        pdfa -.-> must["Nhúng font là bắt buộc"]

Hình 13: Nhúng giả định xác nhận giấy phép fsType; nhúng tập con và PDF/A là đường cơ sở.

Cách chọn phương tiện triển khai cho in và xuất PDF được trình bày sâu trong “In và xuất PDF trong ứng dụng nghiệp vụ Windows”.

8. Font linking và fallback — hiện tượng “một font khác lẫn vào”

Một ký tự mà font được chỉ định không có glyph không được hiện thành trống; vẽ thay bằng font khác là hành vi mặc định của các ngăn xếp vẽ hiện đại. Trong GDI, “font linking” định nghĩa trong registry (FontLink\SystemLink) làm việc này; trong DirectWrite, WPF, và trình duyệt, “font fallback” làm.¹⁵

flowchart TB
        accTitle: Luồng font linking và fallback
        accDescr: Nếu font được chỉ định có glyph thì hiện nguyên; nếu không, nó được vẽ thay bằng font liên kết hoặc fallback; nếu không có glyph ở đâu thì thành □, nhưng dữ liệu thường vẫn còn
        disp["Hiện một ký tự"] --> has{"Font được chỉ định có glyph?"}
        has -->|Có| draw["Hiện bằng font được chỉ định"]
        has -->|Không| fb{"Có trong mục tiêu liên kết hoặc fallback?"}
        fb -->|Có| alt["Vẽ thay bằng font khác"]
        alt -.-> mixed["Nguyên nhân cảm giác mặt chữ lẫn"]
        fb -->|Không| tofu["□（tofu） được hiện"]
        tofu -.-> alive["Dữ liệu thường vẫn còn"]

Hình 14: □ là dấu vết thất bại fallback; việc vẽ thay có thành công không là ngã rẽ giữa “lẫn” và “tofu”.

Biết cơ chế này cho phép bạn giải thích các trường hợp phổ biến sau.

• Cảm giác mặt chữ khác giữa Latin và Nhật: vì một font Latin được chỉ định trước, chỉ phần tiếng Nhật được vẽ bằng font Nhật liên kết hoặc fallback
• Chỉ kanji trong câu tiếng Nhật thành glyph kiểu Trung Quốc: mục tiêu fallback phân giải thành font Trung Quốc. Dễ xảy ra trên trang Web hoặc ứng dụng không truyền thông tin ngôn ngữ (thuộc tính lang hoặc locale) đúng
• Tofu (□) xuất hiện: cả font được chỉ định lẫn mục tiêu fallback đều không có glyph. Nói cách khác □ là “dấu vết thất bại fallback”, và dữ liệu thường vẫn còn

Fallback là cơ chế cứu; nó không thay cho việc chọn đúng font từ đầu.¹⁵ Trong ứng dụng nghiệp vụ vị trí lành mạnh là “trên đường hiển thị và in chính, hoàn tất chỉ bằng các font đã thiết kế; fallback là bảo hiểm cho ký tự bất ngờ”. Về tư duy chọn font trong UI đa ngôn ngữ, xem thêm “Bản địa hóa ứng dụng WinForms/WPF”.

9. Danh sách kiểm triển khai cho ứng dụng nghiệp vụ

Cuối cùng, các điểm cần xác nhận ở từng lớp từ nhập tới liên thông được tóm trong bảng.

Chuẩn hóa đặc biệt là cái bẫy đúng chủ đề bài này: một xử lý áp “với thiện ý” mà nghiền nát phân biệt ký tự biến thể và fullwidth versus halfwidth. Bản gốc nguyên vậy; xử lý trên bản sao là nguyên tắc. Sự cố mã hóa ký tự trong liên thông CSV được trình bày sâu trong “CSV không phải "chỉ là văn bản"”.

flowchart TB
        accTitle: Bản gốc nguyên vậy; xử lý trên bản sao
        accDescr: Lưu chuỗi đã nhập nguyên vậy làm bản gốc; áp chuẩn hóa trên bản sao giới hạn vào một chỗ dùng như tạo khóa tìm; áp NFKC lên bản gốc làm mất phân biệt ký tự biến thể và fullwidth versus halfwidth
        input["Chuỗi đã nhập"] --> orig["Gốc: lưu như đã nhập"]
        input --> copy["Bản sao: chuẩn hóa, giới hạn vào một chỗ dùng"]
        copy -.-> use["Tạo khóa tìm, và tương tự"]
        orig -.-> ng["NFKC trên bản gốc nghiền nát phân biệt"]

Hình 15: Giới hạn chuẩn hóa vào một chỗ dùng và áp trên bản sao; lưu bản gốc như đã nhập.

10. Tóm tắt

• Tách rắc rối ký tự trước hết thành “lớp dữ liệu (mã hóa ký tự)” và “lớp diện mạo (font)”. � là dấu sự cố lớp dữ liệu, □ là sự cố lớp diện mạo.
• JIS X 0213:2004 đã đổi glyph mẫu của 168 ký tự, và Windows có glyph JIS2004 làm mặc định từ Vista trở đi. 葛, 辻, và 飴 trông khác theo môi trường là lịch sử font, không phải dữ liệu hỏng.
• Phương tiện chuẩn để khóa glyph như dữ liệu là IVS, nhưng không có font hỗ trợ và ứng dụng hỗ trợ thì nó rơi về glyph mặc định. Đừng quên tác động triển khai rằng một ký tự có thể dài tới bốn đơn vị mã UTF-16.
• Gaiji (EUDC) là tài sản riêng PC đó và không đi cùng dữ liệu. Câu trả lời thực tế là kiểm kê lúc di chuyển, thay từ bảng tương ứng sang ký tự thông thường hoặc IVS, và dừng tạo cái mới.
• Hệ thống xử lý tên người quyết bộ ký tự được chấp nhận và nêu rõ. Chính phủ đang chuẩn hóa về Ký tự Chuẩn cho Công vụ Hành chính trên nền Ký tự Thống nhất Koseki và Character Information Platform, và hệ thống liên thông cần theo chuyển động đó.
• Với biểu mẫu và PDF, “khớp font với màn hình, xác nhận giấy phép, và nhúng” là đường cơ sở. Với lưu trữ dài hạn, cân nhắc PDF/A.
• Chuẩn hóa NFKC, cắt theo đơn vị mã, và chuyển CP932 là ba điểm lặng lẽ làm hỏng ký tự biến thể và gaiji. Lấy việc lưu bản gốc và xử lý theo đơn vị grapheme làm nguyên tắc.

Lần tới khi được nói “ký tự khác”, hãy đặt lại câu hỏi thế này trước. Điểm mã giống nhau, hay khác? Nếu giống là vấn đề font; nếu khác là vấn đề dữ liệu. Một bước đó giữ bạn khỏi lấy sai điểm vào điều tra.

flowchart TB
        accTitle: Câu hỏi đầu tiên quyết điểm vào điều tra
        accDescr: Khi được nói ký tự khác, hãy so trước điểm mã giống hay khác; nếu giống bắt đầu điều tra như vấn đề font, nếu khác như vấn đề dữ liệu
        said["Bạn được nói ký tự khác"] --> cmp{"Điểm mã giống nhau?"}
        cmp -->|Giống| fontp["Vấn đề font"]
        cmp -->|Khác| datap["Vấn đề dữ liệu"]

Hình 16: Nếu điểm mã giống, bắt đầu điều tra như vấn đề font; nếu khác, như vấn đề dữ liệu.

Bài viết liên quan

• Dẫn nhập mã hóa văn bản Windows - Mojibake xảy ra khi tích hợp với Linux
• Mã hóa văn bản Windows và kết thúc dòng - Cơ bản của mojibake và CRLF/LF
• In và xuất PDF trong ứng dụng nghiệp vụ Windows — chọn giữa System.Drawing.Printing, WPF, và thư viện báo cáo
• Bản địa hóa ứng dụng WinForms/WPF — resx, assembly vệ tinh, và chuyển culture trong thực tế
• CSV không phải “chỉ là văn bản”: hướng dẫn thực tế xử lý CSV trong ứng dụng nghiệp vụ C# (mã hóa, tương thích Excel, phòng thủ tiêm)
• Dẫn nhập khả năng tiếp cận ứng dụng Windows — chuẩn bị cho UI Automation và yêu cầu điều chỉnh hợp lý

Lĩnh vực tư vấn liên quan

KomuraSoft LLC đảm nhận thiết kế và điều tra quanh ký tự trong hệ thống nghiệp vụ. Từ cô lập nguyên nhân các triệu chứng như “ký tự khác trên màn hình và trên biểu mẫu” hoặc “sau di chuyển một tên người thành □”, qua kiểm kê gaiji và lập bảng ký tự thay thế lúc di chuyển từ hệ thống cũ, thiết kế bộ ký tự được chấp nhận của hệ thống xử lý tên người, và rà soát cấu hình nhúng font của biểu mẫu và PDF, chúng tôi phủ cả lớp mã lẫn lớp font.

• Phát triển ứng dụng Windows
• Di chuyển tài sản kế thừa
• Tư vấn kỹ thuật và rà soát thiết kế
• Liên hệ với chúng tôi

Liên kết tham khảo

Bài viết liên quan

Các bài viết gần đây có cùng thẻ để tìm hiểu sâu hơn những chủ đề lân cận.

Chủ đề liên quan

Các trang này đặt chủ đề trong bối cảnh rộng hơn của dịch vụ và quyết định.

Dịch vụ liên quan đến chủ đề này

Bài viết liên quan trực tiếp đến các dịch vụ sau.

Câu hỏi thường gặp

Các câu hỏi thường gặp khi tư vấn về chủ đề của bài viết.

Vì sao cùng ký tự 葛 lại trông khác tùy PC hoặc biểu mẫu in?

Khả năng cao hơn là khác biệt glyph của font, chứ không phải mojibake. JIS X 0213:2004 (JIS2004) đã sửa glyph mẫu của 168 kanji về dạng chuẩn in, và Windows cũng lấy glyph JIS2004 làm mặc định trong MS Gothic / MS Mincho và các font khác từ Vista trở đi. 葛, 辻, 飴 và tương tự là ví dụ điển hình: điểm mã Unicode (dữ liệu) giữ nguyên, và chỉ glyph mà font giữ (diện mạo) đã đổi. So dữ liệu thì chúng khớp; lệch hình giữa ảnh biểu mẫu thời XP và màn hình PC mới là hành vi được quy định. Nếu bạn muốn glyph cũng khớp, hãy dùng cùng font trên màn hình và trên biểu mẫu, hoặc chỉ định glyph bằng ideographic variation selector.

Nếu dùng ideographic variation selector (IVS) thì có giải quyết mọi vấn đề glyph tên người không?

Không. IVS là cơ chế đặt một bộ chọn từ U+E0100 trở đi ngay sau ký tự gốc để chỉ định glyph như dữ liệu, và glyph được chỉ định chỉ hiển thị khi vừa có font hỗ trợ như IPAmj Mincho vừa có ứng dụng hỗ trợ. Trong môi trường không hỗ trợ, hành vi quy định là bỏ qua bộ chọn và hiện glyph mặc định của ký tự gốc; ở một số môi trường bộ chọn cũng có thể hiện thành □. Thêm nữa, một ký tự mang IVS có thể dài tới bốn đơn vị mã trong UTF-16, ảnh hưởng đến đếm ký tự, cắt chuỗi, và thiết kế độ dài cột DB. Nếu đưa vào, hãy xác nhận phạm vi hỗ trợ qua hiển thị, in, và hệ thống hạ nguồn trước khi dùng.

Ký tự đăng ký như gaiji (EUDC) có hiện trên PC khác hoặc trong PDF không?

Về nguyên tắc thì không. Gaiji là cơ chế người dùng đăng một glyph vào tệp eudc.tte của PC đó tại một điểm mã trong Unicode Private Use Area (U+E000 trở đi); cùng điểm mã là không xác định hoặc là glyph khác trên PC khác. Số phận khi chuyển sang thư, PDF, hoặc hệ thống khác vì thế là thành □ hoặc trông như ký tự khác. Nếu đã thừa kế dữ liệu chứa gaiji, đường thực tế lúc di chuyển là kiểm kê chỗ dùng Private Use Area, lập bảng tương ứng sang ký tự Unicode thông thường hoặc ideographic variation selector, rồi thay. Bạn nên tránh tạo gaiji mới trong hệ thống mới.

Hệ thống nghiệp vụ nên chấp nhận ký tự trong tên người tới đâu?

Việc đầu tiên là "quyết định bộ ký tự được chấp nhận và nêu nó như đặc tả". Sổ hộ tịch có khoảng 56.000 Ký tự Thống nhất Koseki, và các hệ thống tuân chuẩn chính phủ đang chuyển sang dùng Ký tự Chuẩn cho Công vụ Hành chính, phần mở rộng của Character Information Platform — nhưng hệ thống nghiệp vụ thông thường không bắt buộc chấp nhận cùng mức không giới hạn. Thiết kế thực tế là quyết một phạm vi như "tới phạm vi JIS X 0213" hoặc "không chấp nhận ideographic variation selector hay Private Use Area", kiểm tra lúc nhập, và vận hành trường hợp ngoài phạm vi bằng cảnh báo hoặc biểu diễn thay thế. Chỉ hệ thống liên thông với hệ thống chính phủ hoặc đô thị mới cần theo chuyển động của Ký tự Chuẩn cho Công vụ Hành chính và yêu cầu liên thông dựa trên JIS X 0221.

Làm sao để biểu mẫu hoặc PDF hiện cùng ký tự với màn hình?

Đường cơ sở là chỉ định cùng font trên màn hình và trên biểu mẫu, và nhúng font vào PDF. Nếu font khác nhau, cùng dữ liệu có thể đổi glyph; nếu PC xem không có font, một font thay thế được dùng để vẽ và diện mạo hỏng. Việc nhúng có được phép không do giấy phép của font quyết (OpenType fsType), nên hãy xác nhận chứ đừng phó mặc thư viện báo cáo. Nhúng tập con, chỉ nhúng các ký tự được dùng, cũng giữ kích thước tệp thấp. Nếu lưu trữ dài hạn là yêu cầu, hãy cân nhắc PDF/A, vốn bắt buộc nhúng font.

Hồ sơ tác giả

Trang giới thiệu tác giả bài viết.

Go Komura

Đại diện của KomuraSoft LLC

Chuyên về phát triển phần mềm Windows, tư vấn kỹ thuật và điều tra lỗi, đặc biệt trong các dự án có hệ thống hiện hữu và lỗi khó tái hiện.