Jebakan font dan karakter Jepang — menangani JIS2004, selector variasi ideografis, dan gaiji di aplikasi bisnis

“Karakter 葛 di daftar pelanggan terlihat berbeda di layar dan di formulir yang dicetak. Pelanggan mengeluh datanya rusak.” — Dalam pemeliharaan sistem bisnis, konsultasi semacam ini tidak jarang. Yang juga sering muncul: “Karakter nama orang tidak tampil di dokumen yang diserahkan ke kantor pemerintah. Dulu tampil di PC lama; setelah diganti, menjadi □.”

Keduanya di lapangan sering disebut “mojibake”, padahal itu masalah yang berbeda dari mojibake akibat ketidakcocokan encoding. Pada kasus pertama, data tidak berubah satu bit pun; yang berubah hanya tampilan. Pada kasus kedua, “gaiji” yang hanya ada di PC itu hilang.

flowchart TB
    accTitle: Apa sebenarnya dua konsultasi yang sering muncul
    accDescr: Konsultasi bahwa bentuk 葛 berbeda di layar dan di formulir adalah kasus tampilan yang berubah sementara data tetap sama; konsultasi bahwa karakter menjadi □ setelah PC diganti adalah kasus gaiji yang hanya ada di PC itu hilang; keduanya masalah yang berbeda dari mojibake akibat 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 PC diganti"] --> r2["Gaiji yang hanya ada di PC itu hilang"]
    r1 --> diff["Masalah yang berbeda dari mojibake encoding"]
    r2 --> diff

Gambar 1: Dua konsultasi yang sering disebut “mojibake” keduanya bukan masalah ketidakcocokan encoding.

Janji artikel ini sederhana. Jika lapisan kode karakter (data) dipisahkan dari lapisan font (tampilan), sebagian besar masalah karakter Jepang bisa ditata. Dari perubahan glif JIS2004, selector variasi ideografis (IVS), dan gaiji (EUDC), sampai fondasi karakter administrasi, pemilihan font, dan penanaman font, isinya disusun dalam bentuk yang dapat dipakai pengembang sistem bisnis dan staf IT untuk mengambil keputusan.

“Mojibake” yang terjadi pada konversi Shift_JIS dan UTF-8 sudah dibahas di artikel yang ada, jadi artikel ini berfokus pada masalah “kodenya bolak-balik dengan benar, tetapi tampilan atau bisa-tidaknya karakter ditampilkan tidak selaras”.

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 selisih glif yang dimiliki font. Penanganannya sama sekali berbeda.
• Meskipun titik kode Unicode sama, glif yang tampil bergantung pada font. JIS X 0213:2004 mengubah glif contoh 168 karakter seperti 葛, 辻, dan 飴 menjadi bentuk standar cetak, dan Windows pun, sejak Vista, menjadikan glif JIS2004 sebagai default di MSゴシック/MS明朝.¹²
• Sarana standar untuk mengunci glif sebagai data adalah selector variasi ideografis (IVS). Glif ditentukan 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 IVS yang benar adalah selector diabaikan dan glif default karakter dasar yang ditampilkan. Namun satu karakter ber-IVS bisa mencapai empat unit kode di UTF-16, jadi implementasi penghitungan karakter dan pemotongan perlu hati-hati.⁵
• Gaiji (EUDC) punya nasib “hanya bisa tampil di PC itu”. Titik kode Private Use Area tidak punya makna yang disepakati secara global, dan glif yang didaftarkan di eudc.tte tidak ikut ke PC lain, surel, atau PDF.⁶⁷
• Sistem yang menangani nama orang harus memutuskan himpunan karakter yang diterima dan menyatakannya. Di sisi administrasi, dengan fondasi karakter terpadu koseki dan Character Information Platform, sistem yang menyesuaikan standar bergerak ke pemakaian “Karakter Standar Urusan Administratif”.⁸⁹¹⁰
• Untuk formulir dan PDF, “samakan font dengan layar, lalu tanamkan” adalah dasar. Apakah penanaman diizinkan ditentukan oleh lisensi font (fsType), dan PDF/A untuk penyimpanan jangka panjang mensyaratkan penanaman font.¹¹¹²
• Jangan gegabah menerapkan normalisasi (NFKC) pada data nama orang. Penyatuan fullwidth/halfwidth dan penggantian karakter kompatibilitas menghilangkan pembedaan yang harus dijaga.¹³

Dalam satu kalimat: “urutan byte mana yang disimpan” adalah masalah desain data; “bagaimana tampilannya” adalah masalah desain font. Jika keduanya dibahas tercampur, masalah yang seharusnya bisa diperbaiki pun menjadi tidak bisa diperbaiki.

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 14, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Memisahkan data dan tampilan — titik kode dan glif

Dalam Unicode, karakter dinyatakan sebagai nomor yang disebut titik kode (code point). 葛 adalah U+845B, dan nomor ini sama di PC mana pun. Sementara itu, bagaimana nomor itu digambar di layar atau di kertas ditentukan oleh glif (bentuk karakter) yang dimiliki font. Wajar jika U+845B yang sama memiliki detail bentuk yang berbeda di font A dan font B.

Dengan dua lapisan itu sebagai prasyarat, gejala di lapangan bisa diisolasi sebagai berikut.

Sebagai petunjuk pemisahan, berguna mengingat perbedaan 「�」 dan 「□」. 「�」 (U+FFFD, REPLACEMENT CHARACTER) adalah jejak kegagalan konversi di lapisan data; karakter aslinya sudah hilang. Sebaliknya 「□」 dalam banyak kasus berarti data masih ada, hanya font tidak punya glif — jadi ada kemungkinan tampil jika font diganti.

flowchart TB
    accTitle: Memisahkan gejala lewat � dan □
    accDescr: Ketika karakter tidak tampil dengan benar, � adalah jejak kegagalan konversi di lapisan data sehingga karakter asli hilang, sedangkan □ berarti data masih ada tetapi font tidak punya glif sehingga ada kemungkinan tampil jika font diganti
    symptom["Karakter tidak tampil dengan benar"] --> which{"Apa yang terlihat?"}
    which -->|terlihat �| datalayer["Kecelakaan lapisan data"]
    datalayer -.-> lost["Jejak gagal konversi (karakter asli sudah hilang)"]
    which -->|terlihat □| viewlayer["Kecelakaan lapisan tampilan"]
    viewlayer -.-> noglyph["Hanya font yang tidak punya glif"]
    noglyph --> fixable["Ada kemungkinan tampil jika font diganti"]

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

Dasar encoding itu sendiri (CP932 dan UTF-8, BOM, kode baris baru) dibahas di “Windows文字コード入門 - Linux連携で起きる文字化け” dan “Windowsの文字コードと改行コード - 文字化けとCRLF/LFの基本”. Selanjutnya adalah lapisan tampilan, dan masalah yang terjadi di batas antara keduanya.

3. Dari JIS90 ke JIS2004 — glif berubah, kodenya tetap

Penyebab sebenarnya keluhan di pembuka, “bentuk 葛 berbeda di layar dan di formulir”, dalam banyak kasus ada di sini.

Menindaklanjuti “Tabel Bentuk Karakter Kanji di Luar Daftar Resmi” (表外漢字字体表) yang disampaikan Dewan Bahasa Nasional pada 2000, JIS X 0213:2004 (biasa disebut JIS2004) yang diamandemen 2004 mengubah glif contoh 168 kanji menjadi bentuk standar cetak yang dekat dengan apa yang disebut bentuk Kangxi. 葛, 辻, 飴, 芦, 溢, 餅, dan sejenisnya adalah contoh khas.¹

Windows menyesuaikan diri: sejak Windows Vista, MSゴシック/MS明朝 (dan メイリオ yang baru ditambahkan) menjadikan glif JIS2004 sebagai default. MSゴシック saat ini juga memakai glif default berbasis JIS2004, dengan akses ke glif era JIS90 lewat fitur OpenType jp90.²¹

flowchart TB
    accTitle: Susunan glif MSゴシック saat ini
    accDescr: MSゴシック sejak Vista menjadikan glif JIS2004 sebagai default, dan glif era JIS90 dapat diakses lewat fitur OpenType jp90
    msg["MSゴシック (sejak Vista)"] --> def["Glif default: berbasis JIS2004"]
    msg --> feat["Lewat fitur jp90"]
    feat --> old["Glif era JIS90"]

Gambar 3: MSゴシック saat ini memakai glif JIS2004 sebagai default, dan dapat dialihkan ke glif JIS90 dengan fitur jp90.

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

• Titik kode 葛 tetap U+845B, baik di XP maupun di Windows 11
• Di XP (glif JIS90) bagian dalam 勹 disederhanakan menjadi bentuk 「ヒ」; sejak Vista (glif JIS2004) bentuknya ditulis sampai 「人」 di dalamnya
• Karena itu, citra pindaian formulir yang dicetak di sistem lama dan tampilan layar PC baru tidak cocok. Perbandingan data sepenuhnya cocok

Hal yang sama berlaku untuk apakah titik pada しんにょう (kaki 辶) karakter 辻 ada satu atau dua, serta bentuk radikal 食 pada 飴. Jika sejarah ini tidak diketahui, investigasi mudah salah arah ke “data rusak saat migrasi”. Jika dikatakan tampilan karakter berbeda sebelum dan sesudah migrasi, bandingkan dulu titik kodenya; jika cocok, curigai selisih glif font — itu urutan yang benar.

flowchart TB
    accTitle: Titik kode sama, glif berubah menurut font
    accDescr: Titik kode 葛 U+845B tetap sama di XP maupun Windows 11; hanya bentuk yang ditampilkan yang berubah antara font glif JIS90 dan font glif JIS2004, dan perbandingan data sepenuhnya cocok
    cp["Titik kode U+845B (葛)"] --> f90["Font glif JIS90 (XP)"]
    cp --> f04["Font glif JIS2004 (sejak Vista)"]
    f90 --> g90["Bentuk dalam 勹 disederhanakan menjadi ヒ"]
    f04 --> g04["Bentuk standar cetak yang menulis sampai 人 di dalam"]
    g90 -.-> same["Perbandingan data sepenuhnya cocok"]
    g04 -.-> same

Gambar 4: Yang berubah hanya font; titik kode U+845B tetap sama di lingkungan mana pun.

Perlu dicatat, bentuk karakter itu sendiri tidak berubah menjadi karakter lain, jadi kedua glif adalah “karakter yang sama”. Namun pada nama orang, ada kasus di mana yang bersangkutan atau kantor pemerintah bersikeras pada bentuk tertentu. IVS di bagian berikutnya menjawab kebutuhan untuk membedakan itu “sebagai data”.

4. Selector variasi ideografis (IVS) — menentukan glif lewat data

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

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

Misalnya, dokumentasi Microsoft menyebutkan 葛 sebagai U+845B saja dipakai pada notasi Stasiun Nishi-Kasai, sedangkan U+845B+U+E0100 (VS17) dipakai pada notasi Kota Katsuragi, Prefektur Nara. Meskipun sama-sama 葛, glif mana yang dimaksud dapat dibedakan sebagai data.³

flowchart TB
    accTitle: Contoh membedakan 葛 yang sama sebagai data dengan IVS
    accDescr: 葛 sebagai U+845B saja dipakai pada notasi Stasiun Nishi-Kasai; urutan U+845B diikuti VS17 dipakai pada notasi Kota Katsuragi; urutan mana merujuk glif mana ditentukan oleh register IVD
    seq1["U+845B saja"] --> gl1["Glif notasi Stasiun Nishi-Kasai"]
    seq2["U+845B + VS17"] --> gl2["Glif notasi Kota Katsuragi"]
    ivd["IVD (register)"] -.-> gl1
    ivd -.-> gl2

Gambar 5: Meskipun sama-sama 「葛」, ada-tidaknya selector membedakan glif mana sebagai data.

4.1. Perilaku di lingkungan yang tidak mendukung

Di sisi font, korespondensi IVS dan glif diimplementasikan di tabel cmap OpenType (format 14).⁵ Jika font yang mendukung (IPAmj明朝 dan sejenisnya) dan aplikasi yang mendukung keduanya ada, glif tampil sesuai penetapan. Jika tidak, hasilnya sebagai berikut.

• Perilaku yang benar menurut spesifikasi: selector diabaikan, dan glif default karakter dasar yang ditampilkan (selector itu sendiri tidak terlihat)
• Aplikasi lama atau sebagian pipeline rendering: selector diperlakukan sebagai karakter tidak dikenal yang berdiri sendiri, sehingga □ tampil tambahan

Dengan kata lain IVS dirancang agar “meski terdegradasi, karakter dasar masih bisa dibaca”, tetapi jaminan “pasti tampil dengan glif yang ditetapkan” bergantung pada lingkungan penerima. Di sistem catatan penduduk dan koseki administrasi, kombinasi font keluarga Character Information Platform + IVS dipakai, tetapi jika sistem bisnis umum menerimanya secara gegabah, glif hilang di tampilan, cetak, atau sistem tujuan.

flowchart TB
    accTitle: Cara data ber-IVS ditampilkan
    accDescr: Jika font dan aplikasi yang mendukung keduanya ada, glif tampil sesuai penetapan; jika tidak, selector diabaikan dan glif default karakter dasar yang tampil; di aplikasi lama atau sebagian pipeline rendering, selector diperlakukan sebagai karakter tidak dikenal dan □ tampil tambahan
    ivs["Karakter dasar + selector variasi ideografis"] --> env{"Font dan aplikasi yang mendukung keduanya ada?"}
    env -->|ya| ok["Tampil dengan glif sesuai penetapan"]
    env -->|tidak| ignore["Selector diabaikan; tampil glif default"]
    env -->|aplikasi lama atau sebagian pipeline rendering| tofu["□ tampil tambahan"]
    ignore -.-> spec["Menurut spesifikasi, ini perilaku yang benar"]

Gambar 6: IVS tetap membuat karakter dasar bisa dibaca meski terdegradasi, tetapi apakah glif yang ditetapkan tampil bergantung pada lingkungan penerima.

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

Selector IVS dari U+E0100 ke atas adalah titik kode di supplementary plane, jadi di UTF-16 selalu surrogate pair (2 unit kode). Jika karakter dasar adalah kanji di supplementary plane (misalnya 𠮟 (U+20B9F) yang ditambahkan di JIS2004), karakter dasar saja sudah 2 unit kode, sehingga urutan yang pengguna anggap “satu karakter” menjadi paling banyak 4 unit kode di UTF-16, dan paling banyak 8 byte di UTF-8.

• Di C#, "葛󠄀" (葛+VS17) menghasilkan string.Length == 3. Substring atau pemotongan panjang tetap berisiko memisahkan karakter dasar dari selector
• Validasi jumlah karakter dan pemotongan dilakukan per grafem (StringInfo dan API sejenis), bukan per unit kode
• Panjang kolom DB (nvarchar(n) di SQL Server dihitung dalam unit kode UTF-16): jika IVS diterima, perkirakan 2–4 kali jumlah karakter yang terlihat
• Pencarian dan perbandingan memperlakukan ada-tidaknya selector sebagai string yang berbeda. Apakah pencarian 「葛」 mengenai 「葛+VS17」 harus diputuskan sebagai persyaratan lalu diimplementasikan

flowchart TB
    accTitle: Satu karakter ber-IVS dan unit kode UTF-16
    accDescr: Urutan karakter dasar plus selector variasi ideografis yang pengguna anggap satu karakter selalu memakai surrogate pair untuk selector, dan jika karakter dasar adalah kanji supplementary plane ada tambahan 2 unit kode, sehingga paling banyak 4 unit kode di UTF-16
    one["Satu karakter menurut pengguna"] --> base["Karakter dasar"]
    one --> vs["Selector variasi ideografis"]
    base -.-> bnote["2 unit kode jika kanji supplementary plane"]
    vs -.-> vnote["Selalu surrogate pair (2 unit kode)"]
    base --> total["Paling banyak 4 unit kode di UTF-16"]
    vs --> total
    total -.-> risk["Risiko terpisah jika dipotong dengan panjang tetap"]

Gambar 7: Satu karakter ber-IVS bisa mencapai empat unit kode UTF-16; pemotongan per unit kode berbahaya.

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

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

Di Windows, glif dibuat dengan Editor Gaiji (eudcedit.exe) dan disimpan ke berkas font eudc.tte. Berkas ini diinstal sebagai font tersembunyi, dan dihubungkan ke masing-masing font lewat registri HKEY_CURRENT_USER\EUDC.⁷ Di era Shift_JIS (CP932), wilayah gaiji adalah 0xF040–0xF9FC, dan saat dikonversi ke Unicode 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 dikirim ke surel, PDF, Web, atau sistem lain, menjadi □ atau terlihat sebagai gaiji lain di sisi penerima
• Jika eudc.tte lupa dipindahkan saat migrasi OS atau penggantian PC, muncul “karakter yang tampil di PC lama tidak tampil”

Itulah penyebab sebenarnya konsultasi kedua di pembuka.

flowchart TB
    accTitle: Mengapa gaiji hanya tampil di PC itu
    accDescr: Glif yang dibuat di Editor Gaiji disimpan ke eudc.tte dan dihubungkan ke font lewat registri PC itu, sehingga jika hanya kode Private Use Area yang dikirim ke surel, PDF, atau sistem lain, hasilnya menjadi □ atau terlihat sebagai karakter lain
    edit["Buat glif di Editor Gaiji"] --> tte["Simpan ke eudc.tte"]
    tte --> reg["Hubungkan ke font lewat registri"]
    reg --> local["Bisa ditampilkan di PC itu"]
    tte -.-> stay["eudc.tte tidak ikut bersama data"]
    send["Hanya kode Private Use Area yang sampai ke penerima"] --> dest["Surel, PDF, sistem lain"]
    dest --> broken["Menjadi □ atau terlihat sebagai karakter lain"]

Gambar 8: Glif ada di eudc.tte, sedangkan di data hanya tersisa nomor Private Use Area, jadi gaiji terlihat rusak begitu keluar dari PC.

5.1. Solusi realistis jika sistem sudah menerima gaiji

Masalahnya adalah ketika data yang diwarisi dari sistem legacy sudah tercampur gaiji. Prosedur yang kami rekomendasikan dalam proyek migrasi adalah sebagai berikut.

1. Inventarisasi: pindai basis data dan berkas dengan ekspresi reguler Private Use Area (U+E000–U+F8FF), lalu daftar kode gaiji yang dipakai beserta jumlahnya. Kumpulkan eudc.tte dari PC di setiap lokasi dan konfirmasi glifnya
2. Identifikasi: untuk setiap gaiji, periksa “apakah bisa dinyatakan dengan karakter Unicode resmi”, “apakah bisa dinyatakan dengan IVS”, “apakah ada karakter yang sesuai di Character Information Platform (MJ)”, lalu buat tabel korespondensi karakter pengganti. Pada praktiknya, sebagian besar kasus hanyalah bentuk lama yang dibuat sebagai gaiji di luar JIS
3. Penggantian: ganti data berdasarkan tabel korespondensi. Hanya jika sama sekali tidak ada karakter yang sesuai, simpan sebagai gambar atau beri catatan pada rekaman tersebut
4. Pemutusan: di sistem baru, tolak input Private Use Area lewat validasi, dan jangan membuat gaiji baru

flowchart TB
    accTitle: Prosedur migrasi data yang berisi gaiji
    accDescr: Inventarisasi gaiji yang dipakai lewat pemindaian Private Use Area dan pengumpulan eudc.tte, buat tabel korespondensi karakter pengganti lalu ganti, dan di sistem baru tolak input Private Use Area lewat validasi serta jangan membuat gaiji baru
    st1["Inventarisasi: pindai Private Use Area"] --> st2["Identifikasi: buat tabel korespondensi pengganti"]
    st2 --> st3["Penggantian: ganti menurut tabel"]
    st3 --> st4["Pemutusan: jangan membuat gaiji baru"]
    st1 -.-> tte["Kumpulkan eudc.tte dari setiap lokasi"]
    st2 -.-> nomap["Hanya jika tidak ada korespondensi: gambar atau catatan"]

Gambar 9: Migrasi gaiji dijalankan dalam empat tahap inventarisasi, identifikasi, penggantian, dan pemutusan; jangan membuat gaiji baru.

Arah di sisi administrasi pun sama: kebijakan yang ditunjukkan adalah mengidentifikasi secara unik gaiji yang dibuat sendiri oleh pemerintah daerah (ada yang mengatakan sekitar 2 juta karakter di seluruh negeri) ke Karakter Standar Urusan Administratif yang dibahas nanti, lalu menghentikan pemakaiannya.¹⁰ “Jangan menambah gaiji; identifikasikan ke himpunan karakter yang distandarkan” semakin menjadi pola baku migrasi, baik di sektor publik maupun swasta.

6. Fondasi karakter administrasi — dari karakter terpadu koseki ke Karakter Standar Urusan Administratif

Saat merancang sistem yang menangani nama orang, mengetahui fondasi karakter di sisi administrasi menjadi bahan keputusan “sejauh mana diterima”.

Di sistem tugas pokok pemerintah daerah (sistem yang menyesuaikan standar), informasi nama orang dan sejenisnya diinteroperasikan dengan Karakter Standar Urusan Administratif, sedangkan dengan sistem eksternal yang tidak punya ketentuan interoperasi seragam — misalnya smartphone — diinteroperasikan dalam cakupan JIS X 0213:2012; dua tingkat itu menjadi spesifikasi standar.¹⁰ Pola “di dalam, himpunan karakter yang luas disimpan; ke luar, pertukaran dibatasi pada rentang yang bisa ditampilkan di lingkungan umum” itu sendiri juga berguna sebagai rujukan bagi sistem swasta.

flowchart TB
    accTitle: Interoperasi dua tingkat pada sistem yang menyesuaikan standar
    accDescr: Sistem pemerintah daerah yang menyesuaikan standar memakai Karakter Standar Urusan Administratif untuk interoperasi informasi nama orang dan sejenisnya, dan memakai cakupan JIS X 0213:2012 untuk interoperasi dengan sistem eksternal seperti smartphone yang tidak punya ketentuan interoperasi seragam
    sys["Sistem pemerintah daerah yang menyesuaikan standar"] --> renkei["Interoperasi informasi nama orang dll."]
    sys --> gaibu["Interoperasi dengan sistem eksternal"]
    renkei --> mjp["Karakter Standar Urusan Administratif"]
    gaibu --> jis["Cakupan JIS X 0213:2012"]
    gaibu -.-> sumaho["Penerima tanpa ketentuan, misalnya smartphone"]
    mjp -.-> naibu["Di dalam, himpunan karakter yang luas disimpan"]

Gambar 10: Interoperasi administrasi memakai Karakter Standar Urusan Administratif; interoperasi eksternal tanpa ketentuan memakai JIS X 0213:2012 — dua tingkat.

Sebagai panduan praktis untuk sistem bisnis umum, berikut yang kami sarankan.

• Putuskan himpunan karakter yang diterima, dan nyatakan baik di spesifikasi maupun di validasi input. Misalnya “cakupan JIS X 0213:2012”, “Private Use Area dan combining character tidak diizinkan”, “IVS tidak diterima (atau diterima, tetapi jaminan tampilan hanya di lingkungan IPAmj明朝)”
• Jangan menerima tanpa batas. Desain “karena Unicode, apa pun bisa masuk” pasti gagal di tampilan, cetak, atau interoperasi
• Tentukan operasi untuk karakter di luar rentang. Aturan penggantian ke notasi alternatif (bentuk baru, katakana) dan kalimat penjelasan kepada yang bersangkutan termasuk spesifikasi sistem
• Jika pihak tujuan (administrasi, keuangan, dan sejenisnya) punya ketentuan himpunan karakter, anggap itu yang benar dan sesuaikan

flowchart TB
    accTitle: Desain dan operasi himpunan karakter yang diterima
    accDescr: Putuskan himpunan karakter yang diterima dan nyatakan baik di spesifikasi maupun di validasi input; karakter dalam rentang diterima, karakter di luar rentang dioperasikan termasuk aturan penggantian ke notasi alternatif dan kalimat penjelasan kepada yang bersangkutan
    decide["Putuskan himpunan 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 ke notasi alternatif"]
    alt -.-> word["Kalimat penjelasan kepada yang bersangkutan juga spesifikasi"]

Gambar 11: Himpunan karakter yang diterima dinyatakan baik di spesifikasi maupun di validasi input, termasuk operasi untuk kasus di luar rentang.

7. Pemilihan font dan penanaman — menyamakan layar dan formulir

7.1. Karakter font yang sering dipakai

Yang penting saat memilih bukan selera jenis huruf, melainkan “apakah font itu ada di semua lingkungan yang terkait tampilan, cetak, dan pembuatan PDF”. Font tambahan Jepang Windows 10/11 (BIZ UD dan sejenisnya) bisa tidak terpasang tergantung konfigurasi, dan pada arsitektur yang membuat PDF di sisi server, ada-tidaknya font di server langsung berpengaruh.

flowchart TB
    accTitle: Lingkungan yang harus dicek saat memilih font
    accDescr: Saat memilih font, yang penting bukan selera jenis huruf melainkan apakah font itu ada di semua lingkungan yang terkait tampilan, cetak, dan pembuatan PDF; konfigurasi font tambahan dan ada-tidaknya font di server langsung berpengaruh
    cand["Font kandidat"] --> exist["Apakah ada di semua lingkungan"]
    exist --> scr["Lingkungan tampilan"]
    exist --> prn["Lingkungan cetak"]
    exist --> srv["Server pembuatan PDF"]
    scr -.-> hojo["Font tambahan bisa tidak ada tergantung konfigurasi"]
    srv -.-> eikyo["Ada-tidaknya font di server langsung berpengaruh"]

Gambar 12: Font dipilih bukan menurut selera jenis huruf, melainkan apakah ada di semua lingkungan tampilan, cetak, dan pembuatan PDF.

7.2. Dasar desain formulir — samakan, lalu tanamkan

• Tentukan font yang sama di layar dan di formulir. Jika fontnya berbeda, data yang sama bisa terlihat dengan glif berbeda, dan itu menjadi keluhan di pembuka. Konfigurasi seperti “layar メイリオ, formulir MS明朝” setidaknya harus dicek apakah tidak ada selisih glif pada 168 karakter JIS2004
• Tanamkan font ke PDF. Jika tidak ditanamkan, sisi yang membuka memakai font di mesinnya untuk menggambar pengganti, dan bukan hanya glif — tata letak pun bisa berubah
• Apakah penanaman diizinkan ditentukan oleh lisensi. Font OpenType menyatakan hak penanaman di bidang fsType (Installable / Restricted / Preview & Print / Editable, larangan subset, dan sejenisnya); font yang penanamannya tidak diizinkan tidak boleh ditanamkan.¹¹ Font komersial wajib dicek kontraknya
• Jadikan subset embedding sebagai dasar. Jika hanya glif karakter yang dipakai yang ditanamkan, tidak perlu menanggung seluruh font Jepang (beberapa MB hingga puluhan MB)
• Jika ada persyaratan penyimpanan jangka panjang, PDF/A. PDF/A (ISO 19005) adalah standar yang menyelesaikan sumber daya yang diperlukan untuk tampilan di dalam berkas, dan penanaman font wajib.¹² Itu juga cara paling andal untuk mencegah “dibuka 10 tahun kemudian, glifnya sudah berubah”

flowchart TB
    accTitle: Alur keputusan penanaman font
    accDescr: Sebelum menanamkan font ke PDF, periksa lisensi penanaman fsType; jika diizinkan, subset embedding menjadi dasar; jika ada persyaratan penyimpanan jangka panjang, pertimbangkan PDF/A yang mewajibkan penanaman
    emb["Tanamkan font ke PDF"] --> lic{"Penanaman diizinkan menurut fsType?"}
    lic -->|diizinkan| sub["Subset embedding sebagai dasar"]
    lic -->|tidak diizinkan| ng["Tidak boleh ditanamkan"]
    sub -.-> gly["Hanya glif karakter yang dipakai"]
    sub -->|persyaratan penyimpanan jangka panjang| pdfa["Pertimbangkan PDF/A"]
    pdfa -.-> must["Penanaman font wajib"]

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

Cara memilih sarana implementasi cetak dan keluaran PDF dibahas lebih rinci di “Windows業務アプリの印刷とPDF出力”.

8. Font link dan fallback — fenomena “font berbeda tercampur”

Karakter yang glifnya tidak ada di font yang ditentukan tidak lalu tidak ditampilkan sama sekali; penggambaran pengganti dengan font lain adalah perilaku default pipeline rendering modern. Di GDI, “font link” yang didefinisikan di registri (FontLink\SystemLink) yang menanganinya; di DirectWrite, WPF, dan peramban, “font fallback” yang menanganinya.¹⁵

flowchart TB
    accTitle: Alur font link dan fallback
    accDescr: Jika glif ada di font yang ditentukan, ditampilkan dengan font itu; jika tidak, digambar pengganti dengan font tujuan font link atau fallback; jika glif tidak ada di mana pun, menjadi □, tetapi data sering masih utuh
    disp["Tampilkan karakter"] --> has{"Glif ada di font yang ditentukan?"}
    has -->|ya| draw["Tampil dengan font yang ditentukan"]
    has -->|tidak| fb{"Ada di tujuan link atau fallback?"}
    fb -->|ya| alt["Penggambaran pengganti dengan font lain"]
    alt -.-> mixed["Penyebab suasana jenis huruf terlihat tercampur"]
    fb -->|tidak| tofu["□ (tofu) ditampilkan"]
    tofu -.-> alive["Data sering masih utuh"]

Gambar 14: □ adalah jejak gagalnya fallback; berhasil-tidaknya penggambaran pengganti memisahkan “tercampur” dan “tofu”.

Jika mekanisme ini diketahui, “gejala yang sering terjadi” berikut bisa dijelaskan.

• Suasana jenis huruf berbeda antara alfanumerik dan Jepang: font Latin diletakkan di depan, sehingga hanya bagian Jepang yang digambar dengan font Jepang di tujuan link/fallback
• Hanya kanji di tengah kalimat Jepang yang menjadi glif bergaya Tionghoa: tujuan fallback terselesaikan ke font Tionghoa. Mudah terjadi di Web atau aplikasi yang tidak meneruskan informasi bahasa (atribut lang atau locale) dengan benar
• Tofu (□) tampil: glif tidak ada baik di font yang ditentukan maupun di tujuan fallback. Dengan kata lain □ adalah “jejak kegagalan” fallback, dan data sering masih utuh

Fallback adalah perangkat penyelamat, bukan pengganti memilih font yang benar sejak awal.¹⁵ Di aplikasi bisnis, posisi yang sehat adalah “pada jalur tampilan dan cetak utama, selesai hanya dengan font yang dirancang; fallback adalah asuransi untuk karakter di luar perkiraan”. Cara berpikir pemilihan font pada UI multibahasa juga dibahas di “WinForms/WPFアプリの多言語化”.

9. Daftar periksa implementasi aplikasi bisnis

Terakhir, poin yang harus dicek di setiap lapisan dari input sampai interoperasi dirangkum dalam tabel.

Normalisasi khususnya adalah jebakan yang tepat menjadi tema artikel ini: pemrosesan yang “diterapkan dengan niat baik” menghapus pembedaan glif varian dan fullwidth/halfwidth. Prinsipnya naskah asli tetap utuh; pemrosesan dilakukan pada salinan. Kecelakaan kode karakter pada interoperasi CSV dibahas lebih rinci di “CSVは「ただのテキスト」ではない”.

flowchart TB
    accTitle: Naskah asli tetap utuh; pemrosesan pada salinan
    accDescr: String yang diinput disimpan apa adanya sebagai naskah asli; normalisasi diterapkan pada salinan terbatas pada tujuan seperti pembuatan kunci pencarian; NFKC pada naskah asli menghapus pembedaan glif varian dan fullwidth/halfwidth
    input["String yang diinput"] --> orig["Naskah asli: simpan sesuai input"]
    input --> copy["Salinan: normalisasi terbatas pada tujuan"]
    copy -.-> use["Pembuatan kunci pencarian, dll."]
    orig -.-> ng["NFKC pada naskah asli menghapus pembedaan"]

Gambar 15: Normalisasi diterapkan pada salinan dengan tujuan terbatas; naskah asli disimpan sesuai input.

10. Ringkasan

• Masalah karakter dipisahkan dulu ke “lapisan data (kode karakter)” dan “lapisan tampilan (font)”. � adalah tanda kecelakaan lapisan data, □ tanda kecelakaan lapisan tampilan.
• Glif contoh 168 karakter berubah di JIS X 0213:2004, dan Windows sejak Vista memakai glif JIS2004 sebagai default. Bentuk 葛, 辻, 飴 yang berbeda antarlingkungan bukan kerusakan data, melainkan sejarah font.
• Sarana standar untuk mengunci glif sebagai data adalah IVS, tetapi jika font dan aplikasi yang mendukung tidak lengkap, kembali ke glif default. Jangan lupa dampak implementasi bahwa satu karakter bisa mencapai 4 unit kode UTF-16.
• Gaiji (EUDC) adalah aset khusus PC itu, dan tidak bisa bepergian bersama data. Solusi realistis adalah menginventarisasi saat migrasi, mengganti dengan tabel korespondensi ke karakter resmi atau IVS, dan berhenti membuat yang baru.
• Sistem yang menangani nama orang memutuskan himpunan karakter yang diterima dan menyatakannya. Administrasi menstandarkan ke Karakter Standar Urusan Administratif dengan fondasi karakter terpadu koseki dan Character Information Platform; sistem yang berinteroperasi perlu mengikuti perkembangannya.
• Formulir dan PDF dasarnya “samakan font dengan layar, periksa lisensi, lalu tanamkan”. Untuk penyimpanan jangka panjang, pertimbangkan PDF/A.
• Normalisasi NFKC, pemotongan per unit kode, dan konversi CP932 adalah tiga titik yang diam-diam merusak glif varian dan gaiji. Jadikan penyimpanan naskah asli dan pemrosesan per grafem sebagai prinsip.

Lain kali, jika dikatakan “karakternya berbeda”, tanyakan dulu ini. Titik kodenya sama, atau berbeda? Jika sama, masalah font; jika berbeda, masalah data. Satu langkah itu membuat pintu masuk investigasi tidak salah.

flowchart TB
    accTitle: Pertanyaan pertama yang menentukan pintu masuk investigasi
    accDescr: Jika dikatakan karakternya berbeda, bandingkan dulu apakah titik kodenya sama atau berbeda; jika sama, mulai investigasi sebagai masalah font; jika berbeda, sebagai masalah data
    said["Dikatakan karakternya berbeda"] --> cmp{"Titik kodenya sama?"}
    cmp -->|sama| fontp["Masalah font"]
    cmp -->|berbeda| datap["Masalah data"]

Gambar 16: Jika titik kode 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

Di Komura Soft LLC, kami menangani desain dan investigasi seputar karakter pada sistem bisnis. Dari isolasi penyebab gejala seperti “karakter berbeda di layar dan di formulir” atau “nama orang menjadi □ setelah migrasi”, inventarisasi gaiji dan penyusunan tabel karakter pengganti saat migrasi dari sistem legacy, desain himpunan karakter yang diterima pada sistem yang menangani nama orang, sampai tinjauan konfigurasi penanaman font pada formulir dan PDF — kami menangani baik lapisan kode maupun lapisan font.

• Pengembangan aplikasi Windows
• Pemanfaatan aset yang ada dan dukungan migrasi
• Konsultasi teknis dan tinjauan desain
• Hubungi kami

Tautan rujukan

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) mengubah glif contoh 168 kanji menjadi bentuk standar cetak, dan Windows pun, sejak Vista, menjadikan glif JIS2004 sebagai default di MSゴシック/MS明朝 dan font sejenis. 葛, 辻, 飴, dan sejenisnya adalah contoh khas: titik kode Unicode (data) tetap sama; yang berubah hanya glif yang dimiliki font (tampilan). Jika datanya dibandingkan, keduanya cocok. Bentuk yang tidak sama antara citra formulir era XP dan layar PC baru adalah perilaku sesuai spesifikasi. Jika glif juga harus diseragamkan, pakai font yang sama di layar dan di formulir, atau tentukan glif dengan selector variasi ideografis.

Jika memakai selector variasi ideografis (IVS), apakah semua masalah glif pada nama orang selesai?

Tidak. IVS adalah mekanisme yang menempatkan selector dari U+E0100 dan seterusnya tepat setelah karakter dasar untuk menentukan glif sebagai data. Glif yang ditentukan hanya tampil jika font yang mendukung (misalnya IPAmj明朝) dan aplikasi yang mendukung keduanya ada. Di lingkungan yang tidak mendukung, perilaku yang benar adalah selector diabaikan dan glif default karakter dasar yang ditampilkan; di beberapa lingkungan selector juga bisa terlihat sebagai □. Selain itu, satu karakter ber-IVS bisa mencapai empat unit kode di UTF-16, sehingga memengaruhi penghitungan karakter, pemotongan, dan desain panjang kolom DB. Jika akan dipakai, pastikan cakupan dukungan sampai tampilan, cetak, dan sistem yang menerima data.

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

Pada prinsipnya tidak. Gaiji adalah mekanisme di mana pengguna mendaftarkan glif ke berkas eudc.tte PC tersebut pada titik kode Unicode Private Use Area (U+E000 dan seterusnya). Titik kode yang sama tidak terdefinisi atau menjadi glif lain di PC lain. Karena itu, begitu data dikirim ke surel, PDF, atau sistem lain, nasibnya adalah menjadi □ atau terlihat sebagai karakter berbeda. Jika data yang sudah berisi gaiji harus diwarisi, langkah realistis saat migrasi adalah menginventarisasi pemakaian Private Use Area, membuat tabel korespondensi ke karakter Unicode resmi atau selector variasi ideografis, lalu mengganti. Di sistem baru, jangan membuat gaiji baru.

Sejauh mana sistem bisnis harus menerima karakter dalam nama orang?

Yang pertama adalah memutuskan himpunan karakter yang diterima dan menyatakannya sebagai spesifikasi. Register keluarga (koseki) memiliki sekitar 56.000 karakter terpadu koseki, dan sistem yang menyesuaikan standar administrasi bergerak ke pemakaian Karakter Standar Urusan Administratif, perluasan dari Character Information Platform — tetapi sistem bisnis umum tidak wajib menerima tingkat yang sama tanpa batas. Desain yang realistis adalah menetapkan rentang seperti "sampai cakupan JIS X 0213" atau "selector variasi ideografis dan Private Use Area tidak diterima", memvalidasi saat input, dan mengoperasikan kasus di luar rentang dengan peringatan atau notasi pengganti. Hanya sistem yang berinteroperasi dengan sistem administrasi atau pemerintah daerah yang perlu mengikuti perkembangan Karakter Standar Urusan Administratif dan persyaratan interoperasi berbasis JIS X 0221.

Bagaimana agar formulir atau PDF menampilkan karakter yang sama dengan layar?

Dasarnya adalah menentukan font yang sama di layar dan di formulir, serta menanamkan font ke PDF. Jika fontnya berbeda, data yang sama bisa tampil dengan glif berbeda; jika PC yang membuka berkas tidak punya font itu, font pengganti dipakai untuk menggambar dan tampilan rusak. Apakah penanaman diizinkan ditentukan oleh lisensi font (OpenType fsType), jadi periksa sendiri, jangan menyerahkannya pada pustaka laporan. Subset embedding, yang hanya menanamkan karakter yang dipakai, juga menekan ukuran berkas. Jika penyimpanan jangka panjang menjadi 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.