Jebakan font dan karakter Jepang — menangani JIS2004, IVS, dan gaiji di aplikasi bisnis

“Karakter 葛 di daftar pelanggan terlihat berbeda di layar dan di formulir cetak. Pelanggan mengeluh data pasti rusak.” — Dalam pemeliharaan sistem bisnis, konsultasi semacam ini tidak jarang. Yang lain yang umum adalah “karakter dalam nama orang tidak tampil di dokumen yang kami serahkan ke kantor pemerintah. Dulu tampil di PC lama; setelah kami ganti, ia menjadi □.”

Keduanya cenderung disebut “mojibake” di lapangan, tetapi itu masalah yang berbeda dari mojibake yang datang dari ketidakcocokan encoding. Di yang pertama, tidak satu bit pun dari data yang berubah dan hanya tampilan yang berubah; di yang kedua, “gaiji” yang hanya ada di PC itu telah hilang.

flowchart TB
        accTitle: Apa sebenarnya dua konsultasi umum itu
        accDescr: Konsultasi bahwa 葛 terlihat berbeda di layar dan di formulir adalah kasus di mana hanya tampilan yang berubah sementara data tetap sama; konsultasi bahwa karakter menjadi □ setelah penggantian PC adalah kasus di mana gaiji yang hanya ada di PC itu hilang; keduanya adalah masalah yang berbeda dari mojibake ketidakcocokan encoding
        c1["Konsultasi 1: bentuk berbeda di layar dan di formulir"] --> r1["Data tidak berubah; hanya tampilan yang berubah"]
        c2["Konsultasi 2: menjadi □ setelah penggantian"] --> r2["Gaiji yang hanya ada di PC itu hilang"]
        r1 --> diff["Masalah yang berbeda dari mojibake encoding"]
        r2 --> diff

Gambar 1: Dua konsultasi yang cenderung disebut “mojibake” keduanya adalah masalah yang berbeda dari ketidakcocokan encoding.

Janji artikel ini sederhana. Jika Anda memisahkan lapisan kode karakter (data) dari lapisan font (tampilan), sebagian besar masalah karakter Jepang menjadi dapat ditangani. Dari perubahan glif JIS2004, ideographic variation selector (IVS), dan gaiji (EUDC), lewat platform karakter pemerintah, sampai memilih dan menanam font, semuanya ditata dalam bentuk yang dapat dipakai pengembang sistem bisnis dan staf IT untuk keputusan.

“Mojibake” itu sendiri yang terjadi pada konversi Shift_JIS ↔ UTF-8 dibahas di artikel yang sudah ada, jadi artikel ini memusatkan diri pada masalah “kodenya bolak-balik dengan benar, tetapi tampilan atau kemampuan menampilkan menyimpang”.

1. Kesimpulan lebih dulu

• “Mojibake” dan “glifnya berbeda” adalah masalah yang berbeda. Mojibake adalah kecelakaan di lapisan data karena salah menafsirkan urutan byte; perbedaan glif adalah kecelakaan di lapisan tampilan karena perbedaan glif yang dipegang font; obatnya sama sekali berbeda.
• Bahkan dengan titik kode Unicode yang sama, glif yang ditampilkan bergantung pada font. JIS X 0213:2004 merevisi glif teladan 168 karakter seperti 葛, 辻, dan 飴 ke bentuk standar cetak, dan Windows pun menjadikan glif JIS2004 sebagai default di MS Gothic / MS Mincho sejak Vista.¹²
• Sarana standar untuk mengunci glif sebagai data adalah ideographic variation selector (IVS). Anda menentukan glif dengan urutan karakter dasar plus selector dari U+E0100 dan seterusnya; koleksi seperti Adobe-Japan1, Hanyo-Denshi, dan Moji_Joho (Character Information Platform) terdaftar di IVD Unicode.³⁴
• Di lingkungan yang tidak mendukung, perilaku yang ditentukan dari IVS adalah selector diabaikan dan glif default karakter dasar ditampilkan. Satu karakter ber-IVS, walaupun, bisa sampai empat unit kode di UTF-16, jadi implementasi penghitungan karakter dan pemotongan perlu hati-hati.⁵
• Gaiji (EUDC) punya nasib “hanya dapat tampil di PC itu”. Tidak ada makna yang disepakati untuk titik kode Private Use Area, dan glif yang didaftarkan di eudc.tte tidak ikut ke PC lain, ke surel, atau ke PDF.⁶⁷
• Sistem yang menangani nama orang harus memutuskan set karakter yang diterima dan menyatakannya. Di sisi pemerintah, membangun di atas Karakter Terpadu Koseki dan Character Information Platform, sistem yang menyesuaikan dengan standar bergerak ke pemakaian “Karakter Standar untuk Urusan Administratif”.⁸⁹¹⁰
• Untuk formulir dan PDF, “selaraskan font dengan layar, dan tanamkannya” adalah garis dasar. Apakah penanaman diizinkan ditentukan oleh lisensi font (fsType), dan PDF/A untuk retensi jangka panjang mensyaratkan penanaman font.¹¹¹²
• Jangan secara gegabah menerapkan normalisasi (NFKC) pada data nama orang. Menyatukan fullwidth dan halfwidth, serta mengganti karakter kompatibilitas, menghilangkan pembedaan yang harus Anda jaga.¹³

Dalam satu kalimat: “urutan byte mana yang Anda simpan” adalah masalah desain data; “bagaimana tampilannya” adalah masalah desain font. Jika Anda membahas keduanya tercampur, bahkan masalah yang bisa Anda perbaiki menjadi tidak dapat diperbaiki.

2. Memikirkan data dan tampilan secara terpisah — titik kode dan glif

Di Unicode, sebuah karakter diwakili oleh angka yang disebut titik kode. 葛 adalah U+845B, dan angka ini sama di setiap PC. Bagaimana angka itu digambar di layar atau di kertas, di sisi lain, diputuskan oleh glif yang dipegang font. Perilaku normal jika U+845B yang sama berbeda dalam detail bentuknya antara font A dan font B.

Dengan dua lapisan ini sebagai premis, gejala lapangan dapat dipisah sebagai berikut.

Sebagai petunjuk pemisahan, berguna mengingat perbedaan antara “�” dan “□”. “�” dari U+FFFD (REPLACEMENT CHARACTER) adalah jejak kegagalan konversi di lapisan data, dan karakter asli sudah hilang. “□”, di sisi lain, dalam banyak kasus hanya berarti data masih ada tetapi font tidak punya glif, dan mengganti font mungkin membuatnya dapat ditampilkan.

flowchart TB
        accTitle: Memisahkan gejala menurut � versus □
        accDescr: Ketika karakter tidak tampil dengan benar, � adalah jejak kegagalan konversi di lapisan data di mana karakter asli telah hilang; □ hanya berarti data masih ada tetapi font tidak punya glif, dan mengganti font mungkin membuatnya dapat ditampilkan
        symptom["Karakter tidak tampil dengan benar"] --> which{"Apa yang Anda lihat?"}
        which -->|Anda melihat �| datalayer["Kecelakaan lapisan data"]
        datalayer -.-> lost["Jejak kegagalan konversi（karakter asli hilang）"]
        which -->|Anda melihat □| viewlayer["Kecelakaan lapisan tampilan"]
        viewlayer -.-> noglyph["Hanya bahwa font tidak punya glif"]
        noglyph --> fixable["Mengganti font mungkin membuatnya dapat ditampilkan"]

Gambar 2: � adalah tanda kecelakaan lapisan data, □ kecelakaan lapisan tampilan, dan titik masuk investigasi berubah.

Dasar encoding itu sendiri (CP932 dan UTF-8, BOM, kode baris baru) dibahas di “Pengantar encoding teks Windows - Mojibake yang terjadi saat berintegrasi dengan Linux” dan “Encoding teks Windows dan akhir baris - Dasar mojibake dan CRLF/LF”. Mulai dari sini adalah lapisan tampilan, dan masalah yang terjadi di batasnya.

3. Dari JIS90 ke JIS2004 — glif berubah sementara kode tetap sama

Identitas “葛 terlihat berbeda di layar dan di formulir” di pembuka, dalam banyak kasus, ada di sini.

Mengikuti laporan Dewan Bahasa Nasional tahun 2000 “Hyogai Kanji Jitaihyo” (tabel bentuk karakter untuk kanji di luar daftar joyo), revisi 2004 JIS X 0213:2004 (umumnya JIS2004) merevisi glif teladan 168 kanji ke bentuk standar cetak, dekat dengan yang disebut bentuk Kamus Kangxi. 葛, 辻, 飴, 芦, 溢, 餅, dan sejenisnya adalah contoh representatif.¹

Windows menyesuaikan ini dan menjadikan glif JIS2004 sebagai default di MS Gothic / MS Mincho (dan Meiryo yang baru diperkenalkan) sejak Windows Vista. MS Gothic saat ini pun punya glif default berbasis JIS2004, dengan struktur bahwa glif era JIS90 dapat diakses lewat fitur OpenType jp90.²¹

flowchart TB
        accTitle: Struktur glif MS Gothic saat ini
        accDescr: Sejak Vista, MS Gothic punya glif JIS2004 sebagai default, dan mengakses glif era JIS90 lewat fitur OpenType jp90 adalah strukturnya
        msg["MS Gothic（Vista dan sesudahnya）"] --> def["Glif default: berbasis JIS2004"]
        msg --> feat["Lewat fitur jp90"]
        feat --> old["Glif era JIS90"]

Gambar 3: MS Gothic saat ini punya glif JIS2004 sebagai default, dan dapat beralih ke glif JIS90 dengan fitur jp90.

Yang penting di sini adalah bahwa hanya font yang berubah; data sama sekali tidak berubah.

• Titik kode 葛 adalah U+845B baik di XP maupun Windows 11
• Di XP (glif JIS90) ia ditampilkan dalam bentuk yang menyederhanakan bagian dalam radikal pembungkus menjadi ヒ; sejak Vista (glif JIS2004) ia ditampilkan dalam bentuk yang juga menulis 人 di dalam
• Karena itu citra pindaian formulir yang dicetak di sistem lama dan tampilan layar di PC baru tidak cocok pada bentuk karakter. Perbandingan data cocok sepenuhnya

Apakah radikal shinnyo 辻 punya satu titik atau dua, bentuk radikal “makan” 飴, dan sejenisnya sama. Jika Anda tidak tahu sejarah ini, investigasi cenderung ke arah yang salah yaitu “data rusak pada migrasi”. Ketika Anda diberitahu bahwa tampilan karakter berbeda sebelum dan sesudah migrasi, pertama bandingkan titik kodenya, dan jika cocok, curigai perbedaan glif font — itu urutan yang benar.

flowchart TB
        accTitle: Titik kode sama, glif berbeda tergantung font
        accDescr: Titik kode U+845B dari 葛 tetap sama baik di XP maupun Windows 11; hanya bentuk yang ditampilkan yang berubah antara font glif JIS90 dan font glif JIS2004, dan perbandingan data cocok sepenuhnya
        cp["Titik kode U+845B（葛）"] --> f90["Font glif JIS90（XP）"]
        cp --> f04["Font glif JIS2004（Vista dan sesudahnya）"]
        f90 --> g90["Bentuk yang menyederhanakan bagian dalam menjadi ヒ"]
        f04 --> g04["Bentuk standar cetak yang menulis 人 di dalam"]
        g90 -.-> same["Perbandingan data cocok sepenuhnya"]
        g04 -.-> same

Gambar 4: Hanya font yang berubah; titik kode U+845B tetap sama di setiap lingkungan.

Catat bahwa karena karakter itu sendiri tidak berubah, kedua glif adalah “karakter yang sama”. Dalam nama orang, walaupun, orang atau kantor pemerintah kadang bersikeras pada bentuk tertentu, dan menjawab tuntutan untuk membedakan itu “sebagai data” adalah topik berikutnya, IVS.

4. Ideographic variation selector (IVS) — menentukan glif sebagai data

IVS (Ideographic Variation Sequence) adalah mekanisme yang menempatkan titik kode tak terlihat yang disebut “ideographic variation selector” tepat setelah sebuah kanji, untuk menentukan varian glif sebagai data. Selector yang dipakai adalah U+E0100–U+E01EF (VS17–VS256).³

Urutan “karakter dasar + selector” mana merujuk ke glif mana diputuskan oleh registri yang disebut IVD (Ideographic Variation Database), dikelola oleh Unicode Consortium. Koleksi utamanya sebagai berikut.⁴

Dokumentasi Microsoft, misalnya, memberi contoh U+845B saja (葛) dipakai dalam penulisan Stasiun Nishi-Kasai, dan U+845B+U+E0100 (VS17) dipakai dalam penulisan Kota Katsuragi, Nara. 葛 yang sama, tetapi glif mana yang dipakai dapat dibedakan sebagai data.³

flowchart TB
        accTitle: Contoh membedakan 葛 yang sama sebagai data dengan IVS
        accDescr: 葛 sebagai U+845B saja dipakai dalam penulisan Stasiun Nishi-Kasai; urutan U+845B diikuti VS17 dipakai dalam penulisan Kota Katsuragi; urutan mana merujuk ke glif mana diputuskan oleh registri IVD
        seq1["U+845B saja"] --> gl1["Glif yang dipakai dalam penulisan Stasiun Nishi-Kasai"]
        seq2["U+845B + VS17"] --> gl2["Glif yang dipakai dalam penulisan Kota Katsuragi"]
        ivd["IVD（registri）"] -.-> gl1
        ivd -.-> gl2

Gambar 5: Bahkan dengan 葛 yang sama, ada atau tidaknya selector memungkinkan Anda membedakan glif mana sebagai data.

4.1. Perilaku di lingkungan yang tidak mendukungnya

Di sisi font, korespondensi antara IVS dan glif diimplementasikan di tabel cmap OpenType (format 14).⁵ Ketika font yang mendukung (IPAmj Mincho dan sejenisnya) dan aplikasi yang mendukung keduanya ada, glif yang ditentukan muncul; ketika tidak, ia berjalan sebagai berikut.

• Perilaku benar yang ditentukan: selector diabaikan dan glif default karakter dasar ditampilkan (selector itu sendiri tak terlihat)
• Aplikasi lama dan beberapa tumpukan gambar: selector diperlakukan sebagai karakter tidak dikenal yang mandiri, dan □ tambahan ditampilkan

Dengan kata lain IVS dirancang agar “meski terdegradasi, karakter dasar tetap dapat dibaca”, tetapi jaminan bahwa “ia akan selalu tampil dalam glif yang ditentukan” bergantung pada lingkungan penerima. Sistem catatan penduduk dan register keluarga pemerintah memakai kombinasi font Character Information Platform plus IVS, tetapi jika sistem bisnis umum menerimanya secara gegabah, glif akan jatuh di suatu tempat pada tampilan, cetak, atau sistem hilir.

flowchart TB
        accTitle: Bagaimana data ber-IVS ditampilkan
        accDescr: Ketika font yang mendukung dan aplikasi yang mendukung keduanya ada, ia tampil dalam glif yang ditentukan; ketika tidak, selector diabaikan dan glif default karakter dasar ditampilkan; di aplikasi lama dan beberapa tumpukan gambar selector diperlakukan sebagai karakter tidak dikenal dan □ tambahan ditampilkan
        ivs["Dasar + selector IVS"] --> env{"Font + aplikasi yang mendukung?"}
        env -->|Ya| ok["Glif yang ditentukan"]
        env -->|Tidak| other{"Bagaimana ia digambar?"}
        other -->|Diabaikan| ignore["Glif default"]
        other -->|Lama / beberapa tumpukan| tofu["□ tambahan"]
        ignore -.-> spec["Benar menurut spesifikasi"]

Gambar 6: IVS tetap dapat dibaca sebagai karakter dasar meski terdegradasi, tetapi apakah glif yang ditentukan muncul bergantung pada lingkungan penerima.

4.2. Catatan implementasi — “satu karakter” bisa sampai empat unit kode

Selector IVS dari U+E0100 dan seterusnya adalah titik kode di supplementary plane, jadi di UTF-16 mereka selalu pasangan surrogate (dua unit kode). Jika karakter dasar adalah kanji supplementary-plane (misalnya 𠮟 (U+20B9F), ditambahkan di JIS2004), dasarnya saja sudah dua unit kode, dan urutan yang dikenali pengguna sebagai “satu karakter” adalah sampai empat unit kode di UTF-16, dan sampai delapan byte di UTF-8.

• "葛󠄀" C# (葛+VS17) punya string.Length == 3. Substring dan pemotongan panjang tetap berisiko memisahkan karakter dasar dari selector
• Validasi jumlah karakter dan pemotongan harus dilakukan dalam unit grapheme (API seperti StringInfo), bukan unit kode
• Untuk panjang kolom DB (nvarchar(n) SQL Server dalam unit kode UTF-16), jika Anda menerima IVS, sediakan dua sampai empat kali jumlah karakter yang tampak
• Dalam pencarian dan perbandingan, ada atau tidaknya selector membuat string yang berbeda. Apakah pencarian “葛” mengenai “葛+VS17” adalah sesuatu yang perlu Anda putuskan sebagai persyaratan dan implementasikan

flowchart TB
        accTitle: Satu karakter ber-IVS dan unit kode UTF-16
        accDescr: Urutan karakter dasar dan ideographic variation selector yang dikenali pengguna sebagai satu karakter selalu pasangan surrogate untuk selector, dan jika karakter dasar adalah kanji supplementary-plane dua unit kode lagi, untuk maksimum empat unit kode di UTF-16
        one["Satu karakter yang terlihat"] --> base["Karakter dasar"]
        one --> vs["Variation selector"]
        base -.-> bnote["+2 jika supplementary"]
        vs -.-> vnote["Selalu 2 unit kode"]
        base --> total["Sampai 4 unit UTF-16"]
        vs --> total
        total -.-> risk["Terpisah pada pemotongan tetap"]

Gambar 7: Satu karakter ber-IVS bisa sampai empat unit kode di UTF-16; memotong menurut unit kode berbahaya.

5. Gaiji (EUDC) — karakter yang hanya tampil di PC itu

Gaiji adalah mekanisme di mana pengguna menetapkan glif sendiri ke titik kode di Unicode Private Use Area (PUA: U+E000–U+F8FF dan sejenisnya). Titik kode Private Use Area tidak punya makna yang disepakati di seluruh dunia; U+E000 yang sama dapat diberi karakter berbeda per PC dan per organisasi.⁶

Di Windows Anda membuat glif dengan Private Character Editor (eudcedit.exe), dan ia disimpan di berkas font bernama eudc.tte. Berkas ini dipasang sebagai font tersembunyi dan dikaitkan dengan setiap font di registry HKEY_CURRENT_USER\EUDC.⁷ Di era Shift_JIS (CP932) rentang gaiji adalah 0xF040–0xF9FC, dan pada konversi ke Unicode ia dipetakan ke Private Use Area.

Konsekuensi mekanisme ini jelas.

• eudc.tte milik PC itu (pengguna itu) dan tidak ikut ke pihak lain bersama data
• Begitu diteruskan ke surel, PDF, Web, atau sistem lain, ia menjadi □ atau terlihat seperti gaiji berbeda milik pihak lain
• Jika Anda lupa memigrasikan eudc.tte pada migrasi OS atau penggantian PC, “karakter yang tampil di PC lama tidak akan tampil” terjadi

Ini identitas konsultasi kedua di pembuka.

flowchart TB
        accTitle: Mengapa gaiji hanya tampil di PC itu
        accDescr: Glif yang dibuat di Private Character Editor disimpan di eudc.tte dan dikaitkan dengan font di registry PC itu, jadi jika hanya kode Private Use Area yang diteruskan ke surel, PDF, atau sistem lain ia menjadi □ atau terlihat seperti karakter berbeda
        edit["Buat glif PUA"] --> tte["Simpan di eudc.tte"]
        edit -.-> editN["Private Char. Editor"]
        tte --> reg["Pemetaan font registry"]
        reg --> local["Tampil di PC itu"]
        tte -.-> stay["eudc.tte tertinggal"]
        send["Hanya kode PUA yang pergi"] --> dest["Surel / PDF / sistem lain"]
        dest --> broken["□ atau karakter salah"]
        local ~~~ send

Gambar 8: Glif tinggal di eudc.tte; hanya nomor Private Use Area yang tersisa di data, jadi gaiji terlihat rusak begitu meninggalkan PC.

5.1. Jawaban realistis untuk sistem yang sudah menerima gaiji

Masalahnya adalah ketika data yang diwarisi dari sistem lama sudah mencampur gaiji. Prosedur yang kami rekomendasikan pada keterlibatan migrasi adalah sebagai berikut.

1. Selidiki: pindai basis data dan berkas dengan ekspresi reguler untuk Private Use Area (U+E000–U+F8FF), dan inventarisasi kode gaiji yang dipakai beserta jumlahnya. Kumpulkan eudc.tte dari PC di setiap situs dan konfirmasi glifnya
2. Identifikasi: untuk setiap gaiji, selidiki “dapatkah ia diwakili sebagai karakter Unicode biasa”, “dapatkah ia diwakili dengan IVS”, “adakah karakter yang berkorespondensi di Character Information Platform (MJ)”, dan bangun tabel korespondensi karakter pengganti. Dalam praktik mayoritas kasus hanyalah bahwa bentuk lama telah dibuat sebagai gaiji JIS
3. Ganti: ganti data dari tabel korespondensi. Hanya ketika benar-benar tidak ada karakter yang berkorespondensi, simpan sebagai gambar atau lampirkan catatan pada rekaman itu
4. Putuskan: di sistem baru, tolak input Private Use Area pada validasi, dan jangan buat gaiji baru

flowchart TB
        accTitle: Prosedur memigrasikan data yang berisi gaiji
        accDescr: Inventarisasi gaiji yang dipakai dengan memindai Private Use Area dan mengumpulkan eudc.tte, bangun tabel korespondensi karakter pengganti dan ganti, dan di sistem baru tolak input Private Use Area pada validasi dan jangan buat gaiji baru
        st1["Selidiki: pindai PUA"] --> st2["Identifikasi: tabel pengganti"]
        st2 --> st3["Ganti dari tabel"]
        st3 --> st4["Putuskan: tidak ada gaiji baru"]
        st1 -.-> tte["Kumpulkan eudc.tte"]
        st2 -.-> nomap["Tidak ada peta: gambar atau catatan"]

Gambar 9: Migrasikan gaiji dalam empat tahap selidiki, identifikasi, ganti, dan putuskan, dan jangan buat gaiji baru.

Arahnya sama di sisi pemerintah: kebijakan telah dinyatakan untuk mengidentifikasi secara unik gaiji yang dibuat kota sendiri (dikatakan sekitar dua juta karakter di seluruh negeri) terhadap Karakter Standar untuk Urusan Administratif yang dijelaskan kemudian, dan menghentikan pemakaiannya.¹⁰ “Jangan menambah gaiji; identifikasikan terhadap set karakter yang distandarkan” menjadi pola migrasi yang mapan baik di sektor publik maupun swasta.

6. Platform karakter pemerintah — dari Karakter Terpadu Koseki ke Karakter Standar untuk Urusan Administratif

Dalam desain sistem yang menangani nama orang, mengetahui platform karakter sisi pemerintah menjadi bahan untuk memutuskan “sejauh mana menerima”.

Di sistem bisnis inti kota (sistem yang menyesuaikan dengan standar), struktur dua tingkat ada di spesifikasi standar: pakai Karakter Standar untuk Urusan Administratif untuk interoperasi informasi nama orang dan sejenisnya, dan berinteroperasi dengan sistem eksternal yang tidak punya aturan interoperasi terpadu — ponsel pintar dan sejenisnya — dalam cakupan JIS X 0213:2012.¹⁰ Struktur itu sendiri “pegang set karakter yang luas di dalam, dan tukar dengan luar dalam rentang yang dapat ditampilkan lingkungan umum” juga menjadi rujukan untuk sistem swasta.

flowchart TB
        accTitle: Interoperasi dua tingkat sistem yang menyesuaikan standar
        accDescr: Sistem kota yang menyesuaikan standar memakai Karakter Standar untuk Urusan Administratif untuk interoperasi informasi nama orang dan sejenisnya, dan berinteroperasi dengan sistem eksternal seperti ponsel pintar yang tidak punya aturan interoperasi terpadu dalam cakupan JIS X 0213:2012
        sys["Sistem standar kota"] --> renkei["Interoperasi nama"]
        sys --> gaibu["Sistem eksternal"]
        renkei --> mjp["Karakter standar administratif"]
        mjp -.-> mjpN["Nama orang dll."]
        gaibu --> jis["Cakupan JIS X 0213:2012"]
        gaibu -.-> sumaho["Tanpa aturan（ponsel pintar）"]
        mjp -.-> naibu["Set luas dipegang di dalam"]

Gambar 10: Struktur dua tingkat: interoperasi pemerintah memakai Karakter Standar untuk Urusan Administratif; interoperasi eksternal tanpa aturan memakai JIS X 0213:2012.

Sebagai panduan praktis untuk sistem bisnis umum, kami merekomendasikan berikut.

• Putuskan set karakter yang diterima dan nyatakan baik di spesifikasi maupun validasi input. Misalnya “cakupan JIS X 0213:2012”, “Private Use Area dan karakter penggabung tidak diizinkan”, “IVS tidak diterima (atau diterima, tetapi tampilan dijamin hanya di lingkungan IPAmj Mincho)”
• Jangan terima tanpa batas. Desain “ini Unicode, jadi apa pun boleh” akan rusak di suatu tempat pada tampilan, cetak, atau interoperasi
• Putuskan operasi untuk karakter di luar rentang di muka. Aturan mengganti representasi alternatif (bentuk baru, katakana) dan kata-kata yang Anda jelaskan kepada orang itu sendiri adalah spesifikasi sistem
• Ketika sistem hilir seperti pemerintah atau keuangan punya aturan set karakter, ambil itu sebagai otoritatif dan selaraskan dengannya

flowchart TB
        accTitle: Mendesain dan mengoperasikan set karakter yang diterima
        accDescr: Putuskan set karakter yang diterima dan nyatakan baik di spesifikasi maupun validasi input; terima karakter dalam rentang; untuk karakter di luar rentang, putuskan operasi termasuk aturan mengganti representasi alternatif dan kata-kata yang Anda jelaskan kepada orang itu
        decide["Putuskan set karakter yang diterima"] --> spec["Nyatakan di spesifikasi"]
        decide --> valid["Nyatakan di validasi input"]
        valid --> range{"Dalam rentang?"}
        range -->|Ya| ok["Terima"]
        range -->|Tidak| alt["Ganti dengan representasi alternatif"]
        alt -.-> word["Kata-kata yang Anda jelaskan kepada orang itu juga spesifikasi"]

Gambar 11: Nyatakan set karakter yang diterima baik di spesifikasi maupun validasi input, dan putuskan juga operasi di luar rentang.

7. Memilih dan menanam font — menyelaraskan layar dan formulir

7.1. Karakter font yang biasa

Yang penting dalam pilihan bukan selera huruf melainkan apakah font itu ada di setiap lingkungan yang terlibat dalam tampilan, cetak, dan pembuatan PDF. Font pelengkap Jepang di Windows 10/11 (BIZ UD dan sejenisnya) kadang tidak ada tergantung konfigurasi, dan dalam konfigurasi yang membuat PDF di sisi server, ada atau tidaknya font di server berdampak langsung.

flowchart TB
        accTitle: Lingkungan yang dikonfirmasi saat memilih font
        accDescr: Dalam memilih font, yang penting bukan selera huruf melainkan apakah font itu ada di setiap lingkungan yang terlibat dalam tampilan, cetak, dan pembuatan PDF; konfigurasi font pelengkap dan ada atau tidaknya font di server berdampak langsung
        cand["Font kandidat"] --> exist["Di setiap lingkungan?"]
        exist --> scr["Lingkungan tampilan"]
        exist --> more{"Printer atau server PDF?"}
        more --> prn["Lingkungan cetak"]
        more --> srv["Server pembuatan PDF"]
        scr -.-> hojo["Font pelengkap?"]
        hojo -.-> hojoN["Mungkin tidak ada"]
        srv -.-> eikyo["Font di server penting"]

Gambar 12: Pilih font kurang menurut selera huruf daripada menurut apakah ia ada di setiap lingkungan tampilan, cetak, dan pembuatan PDF.

7.2. Dasar desain formulir — selaraskan, dan tanam

• Tentukan font yang sama di layar dan di formulir. Jika fontnya berbeda, data yang sama bisa terlihat seperti glif berbeda, dan Anda mendapat keluhan di pembuka. Konfigurasi seperti “Meiryo di layar, MS Mincho di formulir” setidaknya harus dicek apakah ada perbedaan glif pada 168 karakter JIS2004
• Tanam font di PDF. Jika Anda tidak menanam, sisi yang melihat menggambar pengganti dengan font yang ada di tangan, dan bukan hanya glif tetapi tata letak bisa berubah
• Apakah penanaman diizinkan ditentukan oleh lisensi. Font OpenType menyatakan izin penanaman di field fsType (Installable / Restricted / Preview & Print / Editable, no-subsetting, dan sejenisnya), dan Anda tidak boleh menanam font yang penanamannya tidak dilisensikan.¹¹ Untuk font komersial, mengonfirmasi kontrak diperlukan
• Jadikan subset embedding sebagai garis dasar. Jika Anda hanya menanam glif karakter yang dipakai, Anda tidak harus menanggung seluruh font Jepang (beberapa MB sampai puluhan MB)
• Jika ada persyaratan retensi jangka panjang, PDF/A. PDF/A (ISO 19005) adalah standar yang menyelesaikan sumber daya yang dibutuhkan untuk tampilan di dalam berkas, dan penanaman font diwajibkan.¹² Itu juga cara paling andal untuk mencegah “sepuluh tahun kemudian saya membukanya dan glifnya sudah berubah”

flowchart TB
        accTitle: Alur keputusan penanaman font
        accDescr: Sebelum menanam font di PDF, konfirmasi lisensi penanaman fsType; jika dilisensikan, jadikan subset embedding sebagai garis dasar; jika ada persyaratan retensi jangka panjang, pertimbangkan PDF/A, yang mensyaratkan penanaman
        emb["Tanam font di PDF"] --> lic{"Apakah penanaman dilisensikan oleh fsType?"}
        lic -->|Dilisensikan| sub["Subset embedding adalah garis dasar"]
        lic -->|Tidak dilisensikan| ng["Anda tidak boleh menanam"]
        sub -.-> gly["Hanya glif karakter yang dipakai"]
        sub -->|Persyaratan retensi jangka panjang| pdfa["Pertimbangkan PDF/A"]
        pdfa -.-> must["Penanaman font diwajibkan"]

Gambar 13: Penanaman mengasumsikan mengonfirmasi lisensi fsType; subset embedding dan PDF/A adalah garis dasar.

Cara memilih sarana implementasi untuk cetak dan keluaran PDF dibahas mendalam di “Pencetakan dan keluaran PDF di aplikasi bisnis Windows”.

8. Font linking dan fallback — fenomena “font lain tercampur”

Karakter yang font yang ditentukan tidak punya glifnya tidak ditampilkan sebagai kosong; menggambar pengganti di font lain adalah perilaku default tumpukan gambar modern. Di GDI, “font linking” yang didefinisikan di registry (FontLink\SystemLink) melakukan ini; di DirectWrite, WPF, dan peramban, “font fallback” yang melakukannya.¹⁵

flowchart TB
        accTitle: Alur font linking dan fallback
        accDescr: Jika font yang ditentukan punya glif ia ditampilkan apa adanya; jika tidak, ia digambar pengganti di font tautan atau fallback; jika tidak ada glif di mana pun ia menjadi □, tetapi data sering masih hidup
        disp["Tampilkan karakter"] --> has{"Apakah font yang ditentukan punya glif?"}
        has -->|Ya| draw["Tampilkan di font yang ditentukan"]
        has -->|Tidak| fb{"Ada di target tautan atau fallback?"}
        fb -->|Ya| alt["Gambar pengganti di font lain"]
        alt -.-> mixed["Penyebab rasa huruf tercampur"]
        fb -->|Tidak| tofu["□（tofu） ditampilkan"]
        tofu -.-> alive["Data sering masih hidup"]

Gambar 14: □ adalah jejak kegagalan fallback; apakah menggambar pengganti berhasil adalah cabang antara “tercampur” dan “tofu”.

Mengetahui mekanisme ini memungkinkan Anda menjelaskan kasus umum berikut.

• Rasa huruf berbeda antara Latin dan Jepang: karena font Latin ditentukan lebih dulu, hanya porsi Jepang yang digambar di font Jepang yang ditautkan atau fallback
• Hanya kanji dalam kalimat Jepang yang menjadi glif bergaya Tionghoa: target fallback terselesaikan ke font Tionghoa. Mudah terjadi di halaman Web atau aplikasi yang tidak meneruskan informasi bahasa (atribut lang atau locale) dengan benar
• Tofu (□) muncul: baik font yang ditentukan maupun target fallback tidak punya glif. Dengan kata lain □ adalah “jejak kegagalan fallback”, dan data sering masih hidup

Fallback adalah mekanisme bantuan; bukan pengganti memilih font yang benar dari awal.¹⁵ Di aplikasi bisnis posisi yang sehat adalah “pada jalur tampilan dan cetak utama, selesaikan dengan font yang dirancang saja; fallback adalah asuransi untuk karakter tak terduga”. Untuk pemikiran pemilihan font di UI multibahasa, lihat juga “Melokalkan aplikasi WinForms/WPF”.

9. Daftar periksa implementasi untuk aplikasi bisnis

Akhirnya, poin yang dikonfirmasi di setiap lapisan dari input sampai interoperasi dirangkum dalam tabel.

Normalisasi khususnya adalah jebakan yang merupakan tema artikel ini sendiri: proses yang diterapkan “dengan niat baik” yang meremukkan pembedaan karakter varian dan fullwidth versus halfwidth. Yang asli apa adanya; pemrosesan pada salinan adalah prinsipnya. Kecelakaan encoding karakter pada interoperasi CSV dibahas mendalam di “CSV bukan "sekadar teks"”.

flowchart TB
        accTitle: Yang asli apa adanya; pemrosesan pada salinan
        accDescr: Simpan string yang dimasukkan apa adanya sebagai yang asli; terapkan normalisasi pada salinan yang dibatasi pada suatu pemakaian seperti menghasilkan kunci pencarian; menerapkan NFKC pada yang asli menghilangkan pembedaan karakter varian dan fullwidth versus halfwidth
        input["String yang dimasukkan"] --> orig["Asli: simpan sebagaimana dimasukkan"]
        input --> copy["Salinan: normalkan, dibatasi pada suatu pemakaian"]
        copy -.-> use["Menghasilkan kunci pencarian, dan sejenisnya"]
        orig -.-> ng["NFKC pada yang asli meremukkan pembedaan"]

Gambar 15: Batasi normalisasi pada suatu pemakaian dan terapkan pada salinan; simpan yang asli sebagaimana dimasukkan.

10. Ringkasan

• Pisahkan masalah karakter pertama-tama ke “lapisan data (encoding karakter)” dan “lapisan tampilan (font)”. � adalah tanda kecelakaan lapisan data, □ kecelakaan lapisan tampilan.
• JIS X 0213:2004 mengubah glif teladan 168 karakter, dan Windows punya glif JIS2004 sebagai default sejak Vista. 葛, 辻, dan 飴 terlihat berbeda menurut lingkungan adalah sejarah font, bukan kerusakan data.
• Sarana standar untuk mengunci glif sebagai data adalah IVS, tetapi tanpa font yang mendukung dan aplikasi yang mendukung ia jatuh ke glif default. Jangan lupa dampak implementasi bahwa satu karakter bisa sampai empat unit kode UTF-16.
• Gaiji (EUDC) adalah aset khusus PC itu dan tidak dapat ikut bersama data. Jawaban realistis adalah menginventarisasi saat migrasi, mengganti dari tabel korespondensi ke karakter biasa atau IVS, dan berhenti membuat yang baru.
• Sistem yang menangani nama orang memutuskan set karakter yang diterima dan menyatakannya. Pemerintah distandarkan ke Karakter Standar untuk Urusan Administratif di atas fondasi Karakter Terpadu Koseki dan Character Information Platform, dan sistem yang berinteroperasi perlu mengikuti pergerakan itu.
• Untuk formulir dan PDF, “selaraskan font dengan layar, konfirmasi lisensi, dan tanam” adalah garis dasar. Untuk retensi jangka panjang, pertimbangkan PDF/A.
• Normalisasi NFKC, pemotongan menurut unit kode, dan konversi CP932 adalah tiga titik yang diam-diam merusak karakter varian dan gaiji. Jadikan menyimpan yang asli dan memproses dalam unit grapheme sebagai prinsip.

Lain kali Anda diberitahu “karakternya berbeda”, pertama rumuskan ulang pertanyaan ini. Apakah titik kodenya sama, atau berbeda? Jika sama itu masalah font; jika berbeda itu masalah data. Satu langkah itu mencegah Anda mengambil titik masuk investigasi yang salah.

flowchart TB
        accTitle: Pertanyaan pertama yang memutuskan titik masuk investigasi
        accDescr: Ketika Anda diberitahu karakternya berbeda, pertama bandingkan apakah titik kodenya sama atau berbeda; jika sama mulai investigasi sebagai masalah font, jika berbeda sebagai masalah data
        said["Anda diberitahu karakternya berbeda"] --> cmp{"Apakah titik kodenya sama?"}
        cmp -->|Sama| fontp["Masalah font"]
        cmp -->|Berbeda| datap["Masalah data"]

Gambar 16: Jika titik kodenya sama, mulai investigasi sebagai masalah font; jika berbeda, sebagai masalah data.

Artikel terkait

• Pengantar encoding teks Windows - Mojibake yang terjadi saat berintegrasi dengan Linux
• Encoding teks Windows dan akhir baris - Dasar mojibake dan CRLF/LF
• Pencetakan dan keluaran PDF di aplikasi bisnis Windows — memilih antara System.Drawing.Printing, WPF, dan pustaka laporan
• Melokalkan aplikasi WinForms/WPF — resx, assembly satelit, dan peralihan kultur dalam praktik
• CSV bukan “sekadar teks”: panduan praktis penanganan CSV di aplikasi bisnis C# (encoding, kompatibilitas Excel, pertahanan injeksi)
• Pengantar aksesibilitas aplikasi Windows — bersiap untuk UI Automation dan persyaratan akomodasi wajar

Area konsultasi terkait

KomuraSoft LLC menangani desain dan investigasi seputar karakter di sistem bisnis. Dari mengisolasi penyebab gejala seperti “karakter berbeda di layar dan di formulir” atau “setelah migrasi nama orang menjadi □”, lewat menginventarisasi gaiji dan membangun tabel karakter pengganti saat migrasi dari sistem lama, merancang set karakter yang diterima dari sistem yang menangani nama orang, dan meninjau konfigurasi penanaman font formulir dan PDF, kami mencakup baik lapisan kode maupun lapisan font.

• Pengembangan aplikasi Windows
• Migrasi aset warisan
• Konsultasi teknis dan tinjauan desain
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Mengapa karakter 葛 yang sama terlihat berbeda tergantung PC atau formulir cetak?

Kemungkinan besar itu perbedaan glif font, bukan mojibake. JIS X 0213:2004 (JIS2004) merevisi glif teladan 168 kanji ke bentuk standar cetak, dan Windows pun menjadikan glif JIS2004 sebagai default di MS Gothic / MS Mincho dan lainnya sejak Vista. 葛, 辻, 飴, dan sejenisnya adalah contoh representatif: titik kode Unicode (data) tetap sama, dan hanya glif yang dipegang font (tampilan) yang berubah. Bandingkan datanya dan keduanya cocok; ketidakcocokan bentuk antara citra formulir era XP dan layar PC baru adalah perilaku yang ditentukan. Jika Anda ingin glifnya juga selaras, pakai font yang sama di layar dan di formulir, atau tentukan glif dengan ideographic variation selector.

Jika kita memakai ideographic variation selector (IVS), apakah itu menyelesaikan setiap masalah glif nama orang?

Tidak. IVS adalah mekanisme yang menempatkan selector dari U+E0100 dan seterusnya tepat setelah karakter dasar untuk menentukan glif sebagai data, dan glif yang ditentukan hanya ditampilkan ketika font yang mendukung seperti IPAmj Mincho dan aplikasi yang mendukung keduanya ada. Di lingkungan yang tidak mendukung, perilaku yang ditentukan adalah selector diabaikan dan glif default karakter dasar ditampilkan; di beberapa lingkungan selector juga bisa muncul sebagai □. Lebih jauh, satu karakter ber-IVS bisa sampai empat unit kode di UTF-16, yang memengaruhi penghitungan karakter, pemotongan, dan desain panjang kolom DB. Jika Anda memperkenalkannya, konfirmasi cakupan dukungan lewat tampilan, cetak, dan sistem hilir sebelum memakainya.

Bisakah karakter yang didaftarkan sebagai gaiji (EUDC) tampil di PC lain atau di PDF?

Pada prinsipnya tidak. Gaiji adalah mekanisme di mana pengguna mendaftarkan glif ke berkas eudc.tte PC itu pada titik kode di Unicode Private Use Area (U+E000 dan seterusnya); titik kode yang sama tidak terdefinisi atau menjadi glif berbeda di PC lain. Nasib meneruskannya ke surel, PDF, atau sistem lain karenanya adalah menjadi □ atau terlihat seperti karakter berbeda. Jika Anda sudah mewarisi data yang berisi gaiji, jalur realistis saat migrasi adalah menginventarisasi pemakaian Private Use Area, membangun tabel korespondensi ke karakter Unicode biasa atau ideographic variation selector, lalu mengganti. Anda sebaiknya menghindari membuat gaiji baru di sistem baru.

Sejauh mana sistem bisnis harus menerima karakter dalam nama orang?

Yang pertama adalah "memutuskan set karakter yang diterima dan menyatakannya sebagai spesifikasi". Register keluarga punya sekitar 56.000 Karakter Terpadu Koseki, dan sistem yang menyesuaikan dengan standar pemerintah bergerak ke pemakaian Karakter Standar untuk Urusan Administratif, perluasan dari Character Information Platform — tetapi sistem bisnis umum tidak wajib menerima tingkat yang sama tanpa batas. Desain yang realistis adalah memutuskan rentang seperti "sampai cakupan JIS X 0213" atau "tidak menerima ideographic variation selector atau Private Use Area", memvalidasi saat input, dan mengoperasikan kasus di luar rentang dengan peringatan atau representasi alternatif. Hanya sistem yang berinteroperasi dengan sistem pemerintah atau kota yang perlu mengikuti pergerakan Karakter Standar untuk Urusan Administratif dan persyaratan interoperasi berbasis JIS X 0221.

Bagaimana kita membuat formulir atau PDF menampilkan karakter yang sama dengan layar?

Garis dasarnya adalah menentukan font yang sama di layar dan di formulir, serta menanam font di PDF. Jika fontnya berbeda, data yang sama bisa mengubah glif; jika PC yang melihat tidak punya font itu, font pengganti dipakai untuk menggambar dan tampilan rusak. Apakah penanaman diizinkan ditentukan oleh lisensi font (OpenType fsType), jadi konfirmasikan, jangan menyerahkannya pada pustaka laporan. Subset embedding, yang hanya menanam karakter yang dipakai, juga menekan ukuran berkas. Jika retensi jangka panjang adalah persyaratan, pertimbangkan PDF/A, yang mensyaratkan penanaman font.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.