“ตัว 葛 ในรายชื่อลูกค้าบนจอและบนแบบพิมพ์ดูต่างกัน ลูกค้าร้องว่าข้อมูลต้องเสีย” — ในการบำรุงรักษาระบบธุรกิจ คำปรึกษาแบบนี้ไม่หายาก อีกอย่างที่พบบ่อยคือ “อักขระในชื่อบุคคลแสดงไม่ได้บนเอกสารที่ยื่นต่อหน่วยงานราชการ เมื่อก่อนบนเครื่องเก่าแสดงได้ หลังเปลี่ยนเครื่องกลายเป็น □”
ทั้งคู่ในสนามมักถูกเรียก “โมจิบาเกะ” แต่เป็นปัญหาต่างจากโมจิบาเกะที่มาจากความไม่ตรงของการเข้ารหัส ในกรณีแรก ข้อมูลไม่เปลี่ยนแม้บิตเดียว มีเพียงลักษณะที่เปลี่ยน ในกรณีหลัง “ไกจิ” ที่มีอยู่เฉพาะบนเครื่องนั้นหายไป
flowchart TB
accTitle: สองคำปรึกษาที่พบบ่อยคืออะไรจริง ๆ
accDescr: คำปรึกษาที่ 葛 บนจอและบนแบบพิมพ์ดูต่างกันคือกรณีที่ข้อมูลคงเดิมมีเพียงลักษณะที่เปลี่ยน คำปรึกษาที่อักขระกลายเป็น □ หลังเปลี่ยนเครื่องคือกรณีที่ไกจิที่มีอยู่เฉพาะบนเครื่องนั้นหายไป ทั้งคู่เป็นปัญหาต่างจากโมจิบาเกะจากการเข้ารหัสไม่ตรง
c1["คำปรึกษา 1: รูปต่างบนจอและบนแบบพิมพ์"] --> r1["ข้อมูลไม่เปลี่ยน มีเพียงลักษณะที่เปลี่ยน"]
c2["คำปรึกษา 2: กลายเป็น □ หลังเปลี่ยนเครื่อง"] --> r2["ไกจิที่มีอยู่เฉพาะบนเครื่องนั้นหายไป"]
r1 --> diff["ปัญหาต่างจากโมจิบาเกะการเข้ารหัส"]
r2 --> diff
ภาพ 1: สองคำปรึกษาที่มักถูกเรียก “โมจิบาเกะ” ทั้งคู่เป็นปัญหาต่างจากความไม่ตรงของการเข้ารหัส
คำสัญญาของบทความนี้เรียบง่าย หากแยกชั้นรหัสอักขระ (ข้อมูล) ออกจากชั้นแบบอักษร (ลักษณะ) ปัญหาอักขระญี่ปุ่นส่วนใหญ่จัดการได้ จากการเปลี่ยนรูปอักษร JIS2004 ตัวเลือกผันอักษร (IVS) และไกจิ (EUDC) ผ่านแพลตฟอร์มอักขระของรัฐ ไปถึงการเลือกและฝังแบบอักษร จัดในรูปแบบที่นักพัฒนาระบบธุรกิจและเจ้าหน้าที่ไอทีใช้ตัดสินใจได้
โมจิบาเกะที่เกิดในการแปลง Shift_JIS ↔ UTF-8 ครอบคลุมในบทความที่มีอยู่แล้ว ดังนั้นบทความนี้มุ่งที่ปัญหา “รหัสวนกลับถูกต้อง แต่ลักษณะหรือความสามารถแสดงคลาด”
1. สรุปก่อนเลย
- “โมจิบาเกะ” กับ “รูปอักษรต่างกัน” เป็นปัญหาคนละอย่าง โมจิบาเกะคืออุบัติเหตุที่ชั้นข้อมูลของการตีความลำดับไบต์ผิด ความต่างของรูปคืออุบัติเหตุที่ชั้นลักษณะของความต่างของรูปที่แบบอักษรถือ ทางแก้ต่างกันโดยสิ้นเชิง
- แม้จุดรหัส Unicode เดียวกัน รูปที่แสดงขึ้นกับแบบอักษร JIS X 0213:2004 แก้รูปตัวอย่างของอักขระ 168 ตัวเช่น 葛, 辻 และ 飴 ให้เป็นรูปมาตรฐานการพิมพ์ และ Windows ก็ทำให้รูป JIS2004 เป็นค่าเริ่มต้นใน MS Gothic / MS Mincho ตั้งแต่ Vista เป็นต้นไป12
- ทางมาตรฐานของการตรึงรูปเป็นข้อมูลคือตัวเลือกผันอักษร (IVS) คุณระบุรูปด้วยลำดับของอักขระฐานบวกตัวเลือกตั้งแต่ U+E0100 เป็นต้นไป คอลเลกชันอย่าง Adobe-Japan1, Hanyo-Denshi และ Moji_Joho (แพลตฟอร์มข้อมูลอักขระ) ลงทะเบียนใน IVD ของ Unicode34
- ในสภาพแวดล้อมที่ไม่รองรับ พฤติกรรมที่ระบุของ IVS คือละเว้นตัวเลือกแล้วแสดงรูปเริ่มต้นของอักขระฐาน อย่างไรก็ตาม อักขระที่มี IVS หนึ่งตัวยาวได้ถึงสี่หน่วยรหัสใน UTF-16 ดังนั้นการอิมพลีเมนต์การนับอักขระและการตัดต้องระวัง5
- ไกจิ (EUDC) มีชะตากรรม “แสดงได้เฉพาะบนเครื่องนั้น” จุดรหัสพื้นที่ใช้ส่วนตัวไม่มีความหมายที่ตกลงกัน และรูปที่ลงใน eudc.tte ไม่เดินทางไปเครื่องอื่น เมล หรือ PDF67
- ระบบที่จัดการชื่อบุคคลควรตัดสินชุดอักขระที่ยอมรับแล้วระบุ ฝั่งรัฐ สร้างบนอักขระรวมโคเซกิและแพลตฟอร์มข้อมูลอักขระ ระบบที่สอดคล้องมาตรฐานกำลังมุ่งใช้ “มาตรฐานอักขระราชการ”8910
- สำหรับแบบพิมพ์และ PDF “จัดแบบอักษรให้ตรงกับจอ แล้วฝัง” คือเส้นฐาน ว่าฝังได้หรือไม่ถูกกำหนดโดยสัญญาอนุญาตของแบบอักษร (fsType) และ PDF/A สำหรับการเก็บระยะยาวต้องการการฝังแบบอักษร1112
- อย่าใช้การทำให้เป็นบรรทัดฐาน (NFKC) กับข้อมูลชื่อบุคคลอย่างไม่คิด การรวมความกว้างเต็มกับครึ่ง และการแทนอักขระความเข้ากันได้ ทำให้เสียความต่างที่ควรเก็บ13
ในหนึ่งประโยค “ลำดับไบต์ใดที่คุณเก็บ” คือปัญหาออกแบบข้อมูล “มันดูอย่างไร” คือปัญหาออกแบบแบบอักษร หากคุยสองอย่างปนกัน แม้ปัญหาที่แก้ได้ก็กลายเป็นแก้ไม่ได้
2. คิดข้อมูลกับลักษณะแยกกัน — จุดรหัสและรูปอักษร
ใน Unicode อักขระถูกแทนด้วยจำนวนที่เรียก จุดรหัส 葛 คือ U+845B และจำนวนนี้เหมือนกันบนทุกเครื่อง ว่าจำนวนนั้นถูกวาดบนจอหรือบนกระดาษอย่างไร ในทางกลับกัน ถูกตัดสินโดย รูปอักษร ที่แบบอักษรถือ เป็นพฤติกรรมปกติที่ U+845B เดียวกันต่างในรายละเอียดของรูประหว่างแบบอักษร A กับแบบอักษร B
ด้วยสองชั้นนี้เป็นข้อสมมติ อาการในสนามแยกได้ดังนี้
| ชั้น | อุบัติเหตุที่เกิด | อาการตัวแทน | ทางแก้หลัก |
|---|---|---|---|
| ชั้นข้อมูล (การเข้ารหัสอักขระ) | การตีความการเข้ารหัสผิด การสูญในการแปลง | โมจิบาเกะอย่าง 縺ｯ การแทนด้วย ? หรือ 〓 U+FFFD (�) |
ระบุและแก้เส้นทางแปลง |
| ชั้นลักษณะ (แบบอักษร) | ความต่างของรูปตามแบบอักษร รูปหาย | ข้อมูลเดียวกันแต่รูปต่าง กลายเป็น □ (เต้าหู้) | รวมหรือเปลี่ยนแบบอักษร แล้วฝัง |
เป็นเบาะแสของการแยก การจำ ความต่างระหว่าง “�” กับ “□” มีประโยชน์ “�” ของ U+FFFD (REPLACEMENT CHARACTER) คือร่องรอยของความล้มเหลวในการแปลงที่ชั้นข้อมูล และอักขระต้นฉบับหายไปแล้ว “□” ในทางกลับกัน ในหลายกรณีมีเพียงว่าข้อมูลยังอยู่แต่แบบอักษรไม่มีรูป และการเปลี่ยนแบบอักษรอาจทำให้แสดงได้
flowchart TB
accTitle: แยกอาการด้วย � กับ □
accDescr: เมื่ออักขระแสดงไม่ถูกต้อง � คือร่องรอยของความล้มเหลวในการแปลงที่ชั้นข้อมูลซึ่งอักขระต้นฉบับหายแล้ว □ มีเพียงว่าข้อมูลยังอยู่แต่แบบอักษรไม่มีรูป และการเปลี่ยนแบบอักษรอาจทำให้แสดงได้
symptom["อักขระแสดงไม่ถูกต้อง"] --> which{"เห็นอะไร"}
which -->|เห็น �| datalayer["อุบัติเหตุชั้นข้อมูล"]
datalayer -.-> lost["ร่องรอยแปลงล้มเหลว （อักขระต้นฉบับหาย）"]
which -->|เห็น □| viewlayer["อุบัติเหตุชั้นลักษณะ"]
viewlayer -.-> noglyph["มีเพียงว่าแบบอักษรไม่มีรูป"]
noglyph --> fixable["เปลี่ยนแบบอักษรอาจแสดงได้"]
ภาพ 2: � คือสัญญาณของอุบัติเหตุชั้นข้อมูล □ ของอุบัติเหตุชั้นลักษณะ และจุดเข้าของการสอบสวนเปลี่ยน
พื้นฐานของการเข้ารหัสเอง (CP932 และ UTF-8, BOM, รหัสขึ้นบรรทัดใหม่) ครอบคลุมใน “บทนำการเข้ารหัสข้อความ Windows - โมจิบาเกะที่เกิดเมื่อรวมกับ Linux” และ “การเข้ารหัสข้อความและส่วนท้ายบรรทัดของ Windows - พื้นฐานของโมจิบาเกะและ CRLF/LF” จากที่นี่เป็นชั้นลักษณะ และปัญหาที่เกิดที่ขอบของมัน
3. จาก JIS90 สู่ JIS2004 — รูปเปลี่ยนขณะรหัสคงเดิม
ตัวตนของ “葛 บนจอและบนแบบพิมพ์ดูต่างกัน” ตอนเปิด ในหลายกรณีอยู่ที่นี่
ตามรายงานปี 2000 ของสภากาษาแห่งชาติ “Hyogai Kanji Jitaihyo” (ตารางรูปอักษรของคันจินอกบัญชีโจโย) การแก้ไขปี 2004 JIS X 0213:2004 (มักเรียก JIS2004) แก้รูปตัวอย่างของคันจิ 168 ตัวให้เป็นรูปมาตรฐานการพิมพ์ ใกล้รูปพจนานุกรมคังซีที่เรียกกัน 葛, 辻, 飴, 芦, 溢, 餅 และคล้ายกันเป็นตัวอย่างตัวแทน1
Windows จัดให้ตรงและทำให้รูป JIS2004 เป็นค่าเริ่มต้นใน MS Gothic / MS Mincho (และ Meiryo ที่นำเข้าใหม่) ตั้งแต่ Windows Vista เป็นต้นไป MS Gothic ปัจจุบันก็มีรูปเริ่มต้นฐาน JIS2004 โดยโครงที่รูปยุค JIS90 เข้าถึงได้ผ่านคุณลักษณะ OpenType jp9021
flowchart TB
accTitle: โครงรูปของ MS Gothic ปัจจุบัน
accDescr: ตั้งแต่ Vista เป็นต้นไป MS Gothic มีรูป JIS2004 เป็นค่าเริ่มต้น และการเข้าถึงรูปยุค JIS90 ผ่านคุณลักษณะ OpenType jp90 คือโครง
msg["MS Gothic （ตั้งแต่ Vista）"] --> def["รูปเริ่มต้น: ฐาน JIS2004"]
msg --> feat["ผ่านคุณลักษณะ jp90"]
feat --> old["รูปยุค JIS90"]
ภาพ 3: MS Gothic ปัจจุบันมีรูป JIS2004 เป็นค่าเริ่มต้น และสลับไปรูป JIS90 ด้วยคุณลักษณะ jp90 ได้
ที่สำคัญที่นี่คือ มีเพียงแบบอักษรที่เปลี่ยน ข้อมูลไม่เปลี่ยนเลย
- จุดรหัสของ 葛 คือ U+845B ทั้งบน XP และ Windows 11
- บน XP (รูป JIS90) แสดงในรูปที่ทำให้ง่ายด้านในของอักขระหุ้มเป็น ヒ ตั้งแต่ Vista เป็นต้นไป (รูป JIS2004) แสดงในรูปที่เขียน 人 ด้านในด้วย
- ดังนั้นภาพสแกนของแบบพิมพ์ที่พิมพ์บนระบบเก่ากับการแสดงบนจอของเครื่องใหม่ไม่ตรงในรูปของอักขระ การเทียบข้อมูลตรงกันโดยสมบูรณ์
ว่าอักขระชินเนียวของ 辻 มีจุดหนึ่งหรือสอง จุดของอักขระ “กิน” ของ 飴 และคล้ายกันก็เช่นกัน หากไม่รู้ประวัตินี้ การสอบสวนมักไปทิศผิดของ “ข้อมูลเสียในการโยกย้าย” เมื่อถูกบอกว่ารูปอักขระต่างก่อนและหลังการโยกย้าย ก่อนอื่นเทียบจุดรหัส หากตรง ให้สงสัยความต่างของรูปในแบบอักษร — นั่นคือลำดับที่ถูก
flowchart TB
accTitle: จุดรหัสเดียวกัน รูปต่างตามแบบอักษร
accDescr: จุดรหัส U+845B ของ 葛 คงเดิมทั้งบน XP และ Windows 11 มีเพียงรูปที่แสดงที่เปลี่ยนระหว่างแบบอักษรรูป JIS90 กับแบบอักษรรูป JIS2004 และการเทียบข้อมูลตรงกันโดยสมบูรณ์
cp["จุดรหัส U+845B （葛）"] --> f90["แบบอักษรรูป JIS90 （XP）"]
cp --> f04["แบบอักษรรูป JIS2004 （ตั้งแต่ Vista）"]
f90 --> g90["รูปที่ทำให้ง่ายด้านในเป็น ヒ"]
f04 --> g04["รูปมาตรฐานการพิมพ์ที่เขียน 人 ด้านใน"]
g90 -.-> same["การเทียบข้อมูลตรงกันโดยสมบูรณ์"]
g04 -.-> same
ภาพ 4: มีเพียงแบบอักษรที่เปลี่ยน จุดรหัส U+845B คงเดิมในทุกสภาพแวดล้อม
โปรดทราบว่าเพราะอักขระเองไม่เปลี่ยน ทั้งสองรูปคือ “อักขระเดียวกัน” ในชื่อบุคคล อย่างไรก็ตาม บุคคลหรือหน่วยงานราชการบางครั้งยืนกรานรูปเฉพาะ และการตอบความต้องการแยกนั้น “เป็นข้อมูล” คือหัวข้อถัดไป IVS
4. ตัวเลือกผันอักษร (IVS) — การระบุรูปเป็นข้อมูล
IVS (Ideographic Variation Sequence) คือกลไกที่วางจุดรหัสที่มองไม่เห็นเรียก “ตัวเลือกผันอักษร” ทันทีหลังคันจิ เพื่อระบุรูปผันแปรเป็นข้อมูล ตัวเลือกที่ใช้คือ U+E0100–U+E01EF (VS17–VS256)3
ลำดับ “อักขระฐาน + ตัวเลือก” ใดชี้รูปใดถูกตัดสินโดยทะเบียนเรียก IVD (Ideographic Variation Database) ซึ่ง Unicode Consortium จัดการ คอลเลกชันหลักมีดังนี้4
| คอลเลกชัน | ลงทะเบียน | ที่มาและการใช้ |
|---|---|---|
| Adobe-Japan1 | 2007 | คอลเลกชันอักขระญี่ปุ่นของ Adobe รากฐานของการสลับรูปผันในแบบอักษรเชิงพาณิชย์ |
| Hanyo-Denshi | 2010 | โครงการพัฒนาสภาพแวดล้อมแลกเปลี่ยนข้อมูลฮันโย-เด็นชิ ตรงกับอักขระรัฐอย่างอักขระทะเบียนบ้านและทะเบียนผู้อยู่อาศัยพื้นฐาน |
| Moji_Joho | 2014 | ตรงกับแพลตฟอร์มข้อมูลอักขระ (MJ) ใช้กับ IPAmj Mincho มีการลงทะเบียนเพิ่มในสิงหาคม 2026 ด้วย |
เอกสารของ Microsoft ตัวอย่างเช่น ให้ตัวอย่างว่า U+845B อย่างเดียว (葛) ใช้ในการเขียนสถานีนิชิ-คาไซ และ U+845B+U+E0100 (VS17) ใช้ในการเขียนนครคัตสึรางิ นาระ 葛 เดียวกัน แต่รูปใดแยกเป็นข้อมูลได้3
flowchart TB
accTitle: ตัวอย่างการแยก 葛 เดียวกันเป็นข้อมูลด้วย IVS
accDescr: 葛 เป็น U+845B อย่างเดียวใช้ในการเขียนสถานีนิชิ-คาไซ ลำดับของ U+845B ตามด้วย VS17 ใช้ในการเขียนนครคัตสึรางิ ลำดับใดชี้รูปใดถูกตัดสินโดยทะเบียน IVD
seq1["U+845B อย่างเดียว"] --> gl1["รูปที่ใช้ในการเขียนสถานีนิชิ-คาไซ"]
seq2["U+845B + VS17"] --> gl2["รูปที่ใช้ในการเขียนนครคัตสึรางิ"]
ivd["IVD （ทะเบียน）"] -.-> gl1
ivd -.-> gl2
ภาพ 5: แม้ 葛 เดียวกัน การมีหรือไม่มีตัวเลือกให้แยกรูปใดเป็นข้อมูลได้
4.1. พฤติกรรมในสภาพแวดล้อมที่ไม่รองรับ
ฝั่งแบบอักษร ความตรงระหว่าง IVS กับรูปถูกอิมพลีเมนต์ในตาราง OpenType cmap (รูปแบบ 14)5 เมื่อมีแบบอักษรรองรับ (IPAmj Mincho และคล้ายกัน) และแอปรองรับทั้งคู่ รูปที่ระบุปรากฏ เมื่อไม่มี เป็นดังนี้
- พฤติกรรมที่ระบุถูกต้อง: ละเว้นตัวเลือกแล้วแสดงรูปเริ่มต้นของอักขระฐาน (ตัวเลือกเองมองไม่เห็น)
- แอปเก่าและกองวาดบางกอง: ตัวเลือกถูกถือเป็นอักขระไม่รู้จักอิสระ และมี □ เพิ่มแสดง
กล่าวคือ IVS ถูกออกแบบให้ “แม้เสื่อม อักขระฐานยังอ่านได้” แต่ การรับประกันว่า “จะแสดงในรูปที่ระบุเสมอ” ขึ้นกับสภาพแวดล้อมของผู้รับ ระบบบันทึกผู้อยู่อาศัยและทะเบียนบ้านของรัฐใช้การรวมแบบอักษรแพลตฟอร์มข้อมูลอักขระบวก IVS แต่หากระบบธุรกิจทั่วไปรับอย่างไม่คิด รูปจะตกที่ใดที่หนึ่งในการแสดง การพิมพ์ หรือระบบปลายทาง
flowchart TB
accTitle: ข้อมูลที่มี IVS ถูกแสดงอย่างไร
accDescr: เมื่อมีแบบอักษรรองรับและแอปรองรับทั้งคู่จะแสดงในรูปที่ระบุ เมื่อไม่มี ตัวเลือกถูกละเว้นและแสดงรูปเริ่มต้นของอักขระฐาน ในแอปเก่าและกองวาดบางกอง ตัวเลือกถูกถือเป็นอักขระไม่รู้จักและมี □ เพิ่มแสดง
ivs["ฐาน + ตัวเลือก IVS"] --> env{"แบบอักษรและแอปรองรับ?"}
env -->|ใช่| ok["รูปที่ระบุ"]
env -->|ไม่| other{"วาดอย่างไร"}
other -->|ละเว้น| ignore["รูปเริ่มต้น"]
other -->|เก่า / กองบางกอง| tofu["□ เพิ่ม"]
ignore -.-> spec["ระบุถูกต้อง"]
ภาพ 6: IVS ยังอ่านได้เป็นอักขระฐานแม้เสื่อม แต่รูปที่ระบุจะปรากฏหรือไม่ขึ้นกับสภาพแวดล้อมของผู้รับ
4.2. ข้อควรระวังในการอิมพลีเมนต์ — “อักขระหนึ่งตัว” ยาวได้ถึงสี่หน่วยรหัส
ตัวเลือก IVS ตั้งแต่ U+E0100 เป็นต้นไปเป็นจุดรหัสบนระนาบเสริม ดังนั้นใน UTF-16 จึงเป็นคู่เซอร์โรเกตเสมอ (สองหน่วยรหัส) หากอักขระฐานเป็นคันจิระนาบเสริม (เช่น 𠮟 (U+20B9F) ที่เพิ่มใน JIS2004) ฐานอย่างเดียวก็สองหน่วยรหัสแล้ว และ ลำดับที่ผู้ใช้รับรู้เป็น “อักขระหนึ่งตัว” ยาวได้ถึงสี่หน่วยรหัสใน UTF-16 และถึงแปดไบต์ใน UTF-8
"葛󠄀"(葛+VS17) ของ C# มีstring.Length == 3Substringและการตัดความยาวคงที่เสี่ยงแยกอักขระฐานจากตัวเลือก- การตรวจจำนวนอักขระและการตัดควรทำในหน่วยกราฟีม (API อย่าง
StringInfo) ไม่ใช่หน่วยรหัส - สำหรับความยาวคอลัมน์ฐานข้อมูล (
nvarchar(n)ของ SQL Server นับเป็นหน่วยรหัส UTF-16) หากรับ IVS ให้เผื่อสองถึงสี่เท่าของจำนวนอักขระที่เห็น - ในการค้นหาและเทียบ การมีหรือไม่มีตัวเลือกทำให้เป็นสตริงต่างกัน ว่าการค้นหา “葛” จะโดน “葛+VS17” หรือไม่คือสิ่งที่ต้องตัดสินเป็นข้อกำหนดแล้วอิมพลีเมนต์
flowchart TB
accTitle: อักขระที่มี IVS หนึ่งตัวและหน่วยรหัส UTF-16
accDescr: ลำดับของอักขระฐานและตัวเลือกผันอักษรที่ผู้ใช้รับรู้เป็นอักขระหนึ่งตัวเป็นคู่เซอร์โรเกตเสมอสำหรับตัวเลือก และหากอักขระฐานเป็นคันจิระนาบเสริมอีกสองหน่วยรหัส รวมสูงสุดสี่หน่วยรหัสใน UTF-16
one["อักขระที่เห็นหนึ่งตัว"] --> base["อักขระฐาน"]
one --> vs["ตัวเลือกผันแปร"]
base -.-> bnote["+2 หากเป็นระนาบเสริม"]
vs -.-> vnote["เสมอ 2 หน่วยรหัส"]
base --> total["สูงสุด 4 หน่วย UTF-16"]
vs --> total
total -.-> risk["แยกในการตัดคงที่"]
ภาพ 7: อักขระที่มี IVS หนึ่งตัวยาวได้ถึงสี่หน่วยรหัสใน UTF-16 การตัดตามหน่วยรหัสอันตราย
5. ไกจิ (EUDC) — อักขระที่แสดงได้เฉพาะบนเครื่องนั้น
ไกจิคือกลไกที่ผู้ใช้กำหนดรูปของตนให้จุดรหัสในพื้นที่ใช้ส่วนตัวของ Unicode (PUA: U+E000–U+F8FF และคล้ายกัน) จุดรหัสพื้นที่ใช้ส่วนตัวไม่มีความหมายที่ตกลงทั่วโลก U+E000 เดียวกันอาจถูกกำหนดอักขระต่างกันต่อเครื่องและต่อองค์กร6
บน Windows คุณสร้างรูปด้วยตัวแก้ไขอักขระส่วนตัว (eudcedit.exe) และถูกบันทึกในไฟล์แบบอักษรเรียก eudc.tte ไฟล์นี้ถูกติดตั้งเป็นแบบอักษรซ่อนและผูกกับแต่ละแบบอักษรในรีจิสทรี HKEY_CURRENT_USER\EUDC7 ในยุค Shift_JIS (CP932) ช่วงไกจิคือ 0xF040–0xF9FC และเมื่อแปลงเป็น Unicode จะถูกแมปไปพื้นที่ใช้ส่วนตัว
ผลของกลไกนี้ชัด
- eudc.tte เป็นของเครื่องนั้น (ผู้ใช้นั้น) และไม่เดินทางไปอีกฝ่ายกับข้อมูล
- วินาทีที่ส่งไปเมล PDF เว็บ หรือระบบอื่น กลายเป็น □ หรือดูเป็นไกจิต่างของอีกฝ่าย
- หากลืมโยกย้าย eudc.tte ในการโยกย้ายระบบปฏิบัติการหรือการเปลี่ยนเครื่อง จะเกิด “อักขระที่แสดงบนเครื่องเก่าแสดงไม่ได้”
นี่คือตัวตนของคำปรึกษาที่สองตอนเปิด
flowchart TB
accTitle: ทำไมไกจิจึงแสดงได้เฉพาะบนเครื่องนั้น
accDescr: รูปที่สร้างในตัวแก้ไขอักขระส่วนตัวถูกบันทึกใน eudc.tte และผูกกับแบบอักษรในรีจิสทรีของเครื่องนั้น ดังนั้นหากส่งเฉพาะรหัสพื้นที่ใช้ส่วนตัวไปเมล PDF หรือระบบอื่น จะกลายเป็น □ หรือดูเป็นอักขระอื่น
edit["สร้างรูป PUA"] --> tte["บันทึกใน eudc.tte"]
edit -.-> editN["ตัวแก้ไขอักขระส่วนตัว"]
tte --> reg["การแมปแบบอักษรในรีจิสทรี"]
reg --> local["แสดงบนเครื่องนั้น"]
tte -.-> stay["eudc.tte อยู่ข้างหลัง"]
send["มีเพียงรหัส PUA ที่ไป"] --> dest["เมล / PDF / ระบบอื่น"]
dest --> broken["□ หรืออักขระผิด"]
local ~~~ send
ภาพ 8: รูปอยู่ใน eudc.tte มีเพียงหมายเลขพื้นที่ใช้ส่วนตัวที่เหลือในข้อมูล ดังนั้นไกจิดูพังเมื่อออกจากเครื่อง
5.1. คำตอบสมจริงสำหรับระบบที่รับไกจิไปแล้ว
ปัญหาคือเมื่อข้อมูลที่สืบทอดจากระบบเดิมมีไกจิปนอยู่แล้ว ขั้นตอนที่เราแนะนำในงานโยกย้ายมีดังนี้
- สอบสวน: สแกนฐานข้อมูลและไฟล์ด้วยนิพจน์ปรกติสำหรับพื้นที่ใช้ส่วนตัว (U+E000–U+F8FF) และทำรายการรหัสไกจิที่ใช้กับจำนวน เก็บ eudc.tte จากเครื่องในแต่ละไซต์แล้วยืนยันรูป
- ระบุ: สำหรับแต่ละไกจิ สอบสวน “แทนเป็นอักขระ Unicode ปกติได้ไหม” “แทนด้วย IVS ได้ไหม” “มีอักขระตรงในแพลตฟอร์มข้อมูลอักขระ (MJ) ไหม” แล้วสร้าง ตารางคู่ตัวแทน ในทางปฏิบัติกรณีส่วนใหญ่เป็นเพียงว่ารูปเก่าถูกทำให้เป็นไกจิ JIS
- แทนที่: แทนที่ข้อมูลจากตารางคู่ เฉพาะเมื่อไม่มีอักขระตรงจริง ๆ ให้เก็บเป็นภาพหรือแนบบันทึกกับระเบียนนั้น
- ตัดขาด: ในระบบใหม่ ปฏิเสธการป้อนพื้นที่ใช้ส่วนตัวในการตรวจ และอย่าสร้างไกจิใหม่
flowchart TB
accTitle: ขั้นตอนการโยกย้ายข้อมูลที่มีไกจิ
accDescr: ทำรายการไกจิที่ใช้โดยสแกนพื้นที่ใช้ส่วนตัวและเก็บ eudc.tte สร้างตารางคู่ตัวแทนแล้วแทนที่ และในระบบใหม่ปฏิเสธการป้อนพื้นที่ใช้ส่วนตัวในการตรวจและอย่าสร้างไกจิใหม่
st1["สอบสวน: สแกน PUA"] --> st2["ระบุ: ตารางแทน"]
st2 --> st3["แทนที่จากตาราง"]
st3 --> st4["ตัดขาด: ไม่มีไกจิใหม่"]
st1 -.-> tte["เก็บ eudc.tte"]
st2 -.-> nomap["ไม่มีแผนที่: ภาพหรือบันทึก"]
ภาพ 9: โยกย้ายไกจิในสี่ขั้นสอบสวน ระบุ แทนที่ และตัดขาด และอย่าสร้างไกจิใหม่
ทิศทางฝั่งรัฐก็เช่นกัน มีนโยบายระบุตัวตนไกจิที่เทศบาลสร้างเอง (กล่าวว่าประมาณสองล้านอักขระทั่วประเทศ) กับมาตรฐานอักขระราชการที่อธิบายต่อไป และหยุดการใช้10 “อย่าเพิ่มไกจิ ระบุตัวตนกับชุดอักขระมาตรฐาน” กำลังกลายเป็นรูปแบบโยกย้ายที่ยึดทั้งภาครัฐและเอกชน
6. แพลตฟอร์มอักขระของรัฐ — จากอักขระรวมโคเซกิสู่มาตรฐานอักขระราชการ
ในการออกแบบระบบที่จัดการชื่อบุคคล การรู้แพลตฟอร์มอักขระฝั่งรัฐกลายเป็นวัสดุตัดสิน “รับได้ไกลแค่ไหน”
| ชื่อ | ผู้ดูแล | ภาพรวม |
|---|---|---|
| อักขระรวมโคเซกิ | กระทรวงยุติธรรม | ประมาณ 56,000 อักขระที่จัดสำหรับคอมพิวเตอร์ของทะเบียนบ้าน ค้นหาได้บนไซต์กระทรวงยุติธรรม8 |
| อักขระรวมจูกิเน็ต | J-LIS (หน่วยงานระบบสารสนเทศองค์กรปกครองท้องถิ่นญี่ปุ่น) | ประมาณ 21,000 อักขระที่ใช้บนเครือข่ายทะเบียนผู้อยู่อาศัยพื้นฐาน |
| แพลตฟอร์มข้อมูลอักขระ (MJ) | สภาส่งเสริมเทคโนโลยีข้อมูลอักขระ | ประมาณ 60,000 อักขระที่ใช้ในงานบริหาร จัดแล้ว จัดการด้วยชื่อรูปอักษร MJ แบบอักษร IPAmj Mincho และรายการข้อมูลอักขระ MJ ถูกเผยแพร่ จัดเป็นโครงการ IPA และตอนนี้โอนไปสภา9 |
| มาตรฐานอักขระราชการ (MJ+) | สำนักงานดิจิทัล | ชุดอักขระที่ขยายแพลตฟอร์มข้อมูลอักขระด้วยอักขระทะเบียนบ้านที่ระบุกับ MJ ไม่ได้ และคล้ายกัน ชื่อบุคคลและคล้ายกันในระบบที่สอดคล้องมาตรฐานใช้ชุดนี้ การเข้ารหัสอักขระคือ JIS X 0221:202010 |
ในระบบธุรกิจหลักของเทศบาล (ระบบที่สอดคล้องมาตรฐาน) โครงสองชั้นอยู่ในข้อกำหนดมาตรฐาน: ใช้มาตรฐานอักขระราชการสำหรับการทำงานร่วมข้อมูลของชื่อบุคคลและคล้ายกัน และทำงานร่วมกับระบบภายนอกที่ไม่มีกฎการทำงานร่วมรวม — สมาร์ตโฟนและคล้ายกัน — ในขอบของ JIS X 0213:201210 โครงเองของ “ถือชุดอักขระกว้างภายใน และแลกกับภายนอกในช่วงที่สภาพแวดล้อมทั่วไปแสดงได้” ก็เป็นอ้างอิงสำหรับระบบเอกชนด้วย
flowchart TB
accTitle: การทำงานร่วมสองชั้นของระบบที่สอดคล้องมาตรฐาน
accDescr: ระบบเทศบาลที่สอดคล้องมาตรฐานใช้มาตรฐานอักขระราชการสำหรับการทำงานร่วมข้อมูลของชื่อบุคคลและคล้ายกัน และทำงานร่วมกับระบบภายนอกอย่างสมาร์ตโฟนที่ไม่มีกฎการทำงานร่วมรวมในขอบของ JIS X 0213:2012
sys["ระบบมาตรฐานเทศบาล"] --> renkei["การทำงานร่วมชื่อ"]
sys --> gaibu["ระบบภายนอก"]
renkei --> mjp["อักขระมาตรฐานราชการ"]
mjp -.-> mjpN["ชื่อบุคคล ฯลฯ"]
gaibu --> jis["ขอบ JIS X 0213:2012"]
gaibu -.-> sumaho["ไม่มีกฎ （สมาร์ตโฟน）"]
mjp -.-> naibu["ชุดกว้างถือภายใน"]
ภาพ 10: โครงสองชั้น การทำงานร่วมกับรัฐใช้มาตรฐานอักขระราชการ การทำงานร่วมภายนอกที่ไม่มีกฎใช้ JIS X 0213:2012
เป็นแนวทางปฏิบัติสำหรับระบบธุรกิจทั่วไป เราแนะนำดังนี้
- ตัดสินชุดอักขระที่ยอมรับแล้วระบุทั้งในข้อกำหนดและการตรวจตอนป้อน เช่น “ขอบของ JIS X 0213:2012” “พื้นที่ใช้ส่วนตัวและอักขระรวมไม่อนุญาต” “ไม่รับ IVS (หรือรับ แต่การแสดงรับประกันเฉพาะในสภาพแวดล้อม IPAmj Mincho)”
- อย่ารับอย่างไร้ขีด การออกแบบ “เป็น Unicode จึงอะไรก็ได้” จะพังที่ใดที่หนึ่งในการแสดง การพิมพ์ หรือการทำงานร่วม
- ตัดสินการดำเนินการสำหรับอักขระนอกช่วงล่วงหน้า กฎของการแทนทางเลือก (รูปใหม่ คาตากานะ) และถ้อยคำที่คุณอธิบายกับบุคคลนั้นเองคือข้อกำหนดระบบ
- เมื่อระบบปลายทางอย่างรัฐหรือการเงินมีกฎชุดอักขระ ให้ถือเป็นหลักแล้วจัดให้ตรง
flowchart TB
accTitle: การออกแบบและดำเนินการชุดอักขระที่ยอมรับ
accDescr: ตัดสินชุดอักขระที่ยอมรับแล้วระบุทั้งในข้อกำหนดและการตรวจตอนป้อน รับอักขระในช่วง สำหรับอักขระนอกช่วง ตัดสินการดำเนินการรวมกฎการแทนทางเลือกและถ้อยคำที่อธิบายกับบุคคล
decide["ตัดสินชุดอักขระที่ยอมรับ"] --> spec["ระบุในข้อกำหนด"]
decide --> valid["ระบุในการตรวจตอนป้อน"]
valid --> range{"ในช่วง?"}
range -->|ใช่| ok["รับ"]
range -->|ไม่| alt["แทนทางเลือก"]
alt -.-> word["ถ้อยคำที่อธิบายกับบุคคลก็เป็นข้อกำหนด"]
ภาพ 11: ระบุชุดอักขระที่ยอมรับทั้งในข้อกำหนดและการตรวจตอนป้อน และตัดสินการดำเนินการนอกช่วงด้วย
7. การเลือกและฝังแบบอักษร — จัดจอกับแบบพิมพ์ให้ตรง
7.1. ลักษณะของแบบอักษรที่ใช้กัน
| แบบอักษร | ความครอบคลุม | ลักษณะและที่ควรใช้ |
|---|---|---|
| MS Gothic / MS Mincho | มาตรฐาน Windows | มือเก่าที่ออกแบบสำหรับจอความละเอียดต่ำ รูปเริ่มต้นฐาน JIS20042 ยังใช้เพื่อรักษาความเข้ากันได้กับแบบพิมพ์เดิม |
| Meiryo | ตั้งแต่ Vista | แบบจอสมัยใหม่ที่สมมติ ClearType ปรากฏพร้อมกับการโยกย้าย JIS2004 รุ่น Vista1 |
| Yu Gothic / Yu Mincho | ตั้งแต่ Windows 8.1 | ตระกูลที่ส่งทั้งบน Windows และ macOS ทำให้จัดลักษณะเอกสารให้ง่ายขึ้น |
| BIZ UD Gothic / BIZ UD Mincho | ตั้งแต่ Windows 10 1809 | แบบออกแบบสากลของ Morisawa ผู้สมัครแรกในงานที่เน้นความอ่านได้ของแบบพิมพ์และจอ14 |
| Noto Sans JP | ติดตั้งแยก | ให้เป็นโอเพนซอร์ส และง่ายที่จะรวมบนเซิร์ฟเวอร์หรือสภาพแวดล้อม Linux และส่งบนเว็บ |
ที่สำคัญในการเลือกไม่ใช่ความชอบของแบบตัวอักษรเท่ากับ ว่าแบบอักษรนั้นมีในทุกสภาพแวดล้อมที่เกี่ยวข้องกับการแสดง การพิมพ์ และการสร้าง PDF หรือไม่ แบบอักษรเสริมญี่ปุ่นบน Windows 10/11 (BIZ UD และคล้ายกัน) บางครั้งไม่มีตามการกำหนดค่า และในการกำหนดค่าที่สร้าง PDF ฝั่งเซิร์ฟเวอร์ การมีหรือไม่มีแบบอักษรบนเซิร์ฟเวอร์มีผลโดยตรง
flowchart TB
accTitle: สภาพแวดล้อมที่ต้องยืนยันเมื่อเลือกแบบอักษร
accDescr: ในการเลือกแบบอักษร ที่สำคัญไม่ใช่ความชอบของแบบตัวอักษรเท่ากับว่าแบบอักษรนั้นมีในทุกสภาพแวดล้อมที่เกี่ยวข้องกับการแสดง การพิมพ์ และการสร้าง PDF หรือไม่ การกำหนดค่าแบบอักษรเสริมและการมีหรือไม่มีแบบอักษรบนเซิร์ฟเวอร์มีผลโดยตรง
cand["แบบอักษรผู้สมัคร"] --> exist["มีในทุกสภาพแวดล้อม?"]
exist --> scr["สภาพแวดล้อมแสดง"]
exist --> more{"เซิร์ฟเวอร์พิมพ์หรือ PDF?"}
more --> prn["สภาพแวดล้อมพิมพ์"]
more --> srv["เซิร์ฟเวอร์สร้าง PDF"]
scr -.-> hojo["แบบอักษรเสริม?"]
hojo -.-> hojoN["อาจไม่มี"]
srv -.-> eikyo["แบบอักษรบนเซิร์ฟเวอร์สำคัญ"]
ภาพ 12: เลือกแบบอักษรน้อยด้วยความชอบของแบบตัวอักษรมากด้วยว่ามีในทุกสภาพแวดล้อมของการแสดง การพิมพ์ และการสร้าง PDF
7.2. พื้นฐานของการออกแบบแบบพิมพ์ — จัดให้ตรง แล้วฝัง
- ระบุแบบอักษรเดียวกันบนจอและบนแบบพิมพ์ หากแบบอักษรต่างกัน ข้อมูลเดียวกันอาจดูเป็นรูปต่าง และคุณได้คำร้องตอนเปิด การกำหนดค่าอย่าง “Meiryo บนจอ MS Mincho บนแบบพิมพ์” อย่างน้อยควรตรวจว่ามีความต่างของรูปบนอักขระ JIS2004 ทั้ง 168 ตัวหรือไม่
- ฝังแบบอักษรใน PDF หากไม่ฝัง ฝั่งที่เปิดดูจะวาดทดแทนด้วยแบบอักษรที่มี และไม่เพียงรูปแต่เลย์เอาต์อาจเปลี่ยน
- ว่าฝังได้หรือไม่ถูกกำหนดโดยสัญญาอนุญาต แบบอักษร OpenType ประกาศสิทธิ์การฝังในฟิลด์
fsType(Installable / Restricted / Preview & Print / Editable, no-subsetting และคล้ายกัน) และคุณต้องไม่ฝังแบบอักษรที่การฝังไม่ได้รับอนุญาต11 สำหรับแบบอักษรเชิงพาณิชย์ การยืนยันสัญญาจำเป็น - ทำให้การฝังชุดย่อยเป็นเส้นฐาน หากฝังเฉพาะรูปของอักขระที่ใช้ คุณไม่ต้องรับแบบอักษรญี่ปุ่นทั้งก้อน (หลาย MB ถึงหลายสิบ MB)
- หากมีข้อกำหนดการเก็บระยะยาว ใช้ PDF/A PDF/A (ISO 19005) คือมาตรฐานที่ทำทรัพยากรที่จำเป็นสำหรับการแสดงให้ครบในไฟล์ และการฝังแบบอักษรจำเป็น12 ยังเป็นทางที่เชื่อถือได้ที่สุดในการป้องกัน “สิบปีหลังเปิดแล้วรูปเปลี่ยน”
flowchart TB
accTitle: ไหลการตัดสินของการฝังแบบอักษร
accDescr: ก่อนฝังแบบอักษรใน PDF ยืนยันสัญญาอนุญาตการฝัง fsType หากได้รับอนุญาต ทำให้การฝังชุดย่อยเป็นเส้นฐาน หากมีข้อกำหนดการเก็บระยะยาว พิจารณา PDF/A ซึ่งต้องการการฝัง
emb["ฝังแบบอักษรใน PDF"] --> lic{"การฝังได้รับอนุญาตโดย fsType?"}
lic -->|ได้รับอนุญาต| sub["การฝังชุดย่อยคือเส้นฐาน"]
lic -->|ไม่ได้รับอนุญาต| ng["ต้องไม่ฝัง"]
sub -.-> gly["เฉพาะรูปของอักขระที่ใช้"]
sub -->|ข้อกำหนดการเก็บระยะยาว| pdfa["พิจารณา PDF/A"]
pdfa -.-> must["การฝังแบบอักษรจำเป็น"]
ภาพ 13: การฝังสมมติการยืนยันสัญญาอนุญาต fsType การฝังชุดย่อยและ PDF/A คือเส้นฐาน
วิธีเลือกทางอิมพลีเมนต์สำหรับการพิมพ์และเอาต์พุต PDF ครอบคลุมลึกใน “การพิมพ์และเอาต์พุต PDF ในแอปธุรกิจ Windows”
8. การเชื่อมแบบอักษรและการสำรอง — ปรากฏการณ์ “แบบอักษรอื่นปนเข้ามา”
อักขระที่แบบอักษรที่ระบุไม่มีรูปไม่ได้แสดงเป็นความว่าง การวาดทดแทนในแบบอักษรอื่น คือพฤติกรรมเริ่มต้นของกองวาดสมัยใหม่ ใน GDI “การเชื่อมแบบอักษร” ที่นิยามในรีจิสทรี (FontLink\SystemLink) ทำสิ่งนี้ ใน DirectWrite, WPF และเบราว์เซอร์ “การสำรองแบบอักษร” ทำ15
flowchart TB
accTitle: ไหลของการเชื่อมแบบอักษรและการสำรอง
accDescr: หากแบบอักษรที่ระบุมีรูปจะแสดงตามที่เป็น หากไม่มี จะถูกวาดทดแทนในแบบอักษรเชื่อมหรือสำรอง หากไม่มีรูปที่ไหนจะกลายเป็น □ แต่ข้อมูลมักยังมีชีวิต
disp["แสดงอักขระ"] --> has{"แบบอักษรที่ระบุมีรูป?"}
has -->|ใช่| draw["แสดงในแบบอักษรที่ระบุ"]
has -->|ไม่| fb{"มีในเป้าหมายเชื่อมหรือสำรอง?"}
fb -->|ใช่| alt["วาดทดแทนในแบบอักษรอื่น"]
alt -.-> mixed["สาเหตุของความรู้สึกแบบตัวอักษรปน"]
fb -->|ไม่| tofu["แสดง □ （เต้าหู้）"]
tofu -.-> alive["ข้อมูลมักยังมีชีวิต"]
ภาพ 14: □ คือร่องรอยของความล้มเหลวในการสำรอง ว่าการวาดทดแทนสำเร็จหรือไม่คือทางแยกระหว่าง “ปน” กับ “เต้าหู้”
การรู้กลไกนี้ให้คุณอธิบายกรณีที่พบบ่อยต่อไปนี้
- ความรู้สึกแบบตัวอักษรต่างระหว่างละตินกับญี่ปุ่น: เพราะระบุแบบอักษรละตินก่อน มีเพียงส่วนญี่ปุ่นที่ถูกวาดในแบบอักษรญี่ปุ่นที่เชื่อมหรือสำรอง
- เฉพาะคันจิในประโยคญี่ปุ่นกลายเป็นรูปสไตล์จีน: เป้าหมายสำรองไปลงที่แบบอักษรจีน เกิดง่ายในหน้าเว็บหรือแอปที่ไม่ได้ส่งข้อมูลภาษา (แอตทริบิวต์ lang หรือโลเคล) ถูกต้อง
- เต้าหู้ (□) ปรากฏ: ทั้งแบบอักษรที่ระบุและเป้าหมายสำรองไม่มีรูป กล่าวคือ □ คือ “ร่องรอยของความล้มเหลวในการสำรอง” และข้อมูลมักยังมีชีวิต
การสำรองคือกลไกบรรเทา ไม่ใช่การแทนของการเลือกแบบอักษรที่ถูกตั้งแต่ต้น15 ในแอปธุรกิจ ตำแหน่งที่แข็งแรงคือ “บนเส้นทางแสดงและพิมพ์หลัก ให้ครบด้วยแบบอักษรที่ออกแบบอย่างเดียว การสำรองคือประกันสำหรับอักขระไม่คาดคิด” สำหรับความคิดของการเลือกแบบอักษรใน UI หลายภาษา ดู “การทำให้แอป WinForms/WPF เป็นท้องถิ่น” ด้วย
9. เช็กลิสต์การอิมพลีเมนต์สำหรับแอปธุรกิจ
สุดท้าย จุดที่ต้องยืนยันในแต่ละชั้นจากการป้อนผ่านการทำงานร่วมถูกสรุปในตาราง
| ชั้น | อุบัติเหตุตัวแทน | จุดออกแบบและอิมพลีเมนต์ |
|---|---|---|
| การป้อน | อักขระขึ้นกับสภาพแวดล้อม อักขระที่มี IVS และอักขระพื้นที่ใช้ส่วนตัวเข้ามาจาก IME | ตัดสินชุดอักขระที่ยอมรับแล้วตรวจ สำหรับนอกช่วง คำแนะนำ (เสนอทางเลือก) แทนข้อผิดพลาดทำให้งานเคาน์เตอร์เดินต่อ |
| การทำให้เป็นบรรทัดฐาน | การแปลงไม่ตั้งใจอย่าง NFKC เปลี่ยน ㈱ เป็น (株) รวมความกว้างเต็มกับครึ่ง ① เป็น 1 แม้ NFC แทนอักขระคันจิความเข้ากันได้ (เช่น U+FA19 神) ด้วยอักขระรวม U+795E | อย่าใช้ NFKC กับชื่อบุคคลและที่อยู่ จำกัดการทำให้เป็นบรรทัดฐานตามการใช้ (สร้างคีย์ค้นหา และคล้ายกัน) และเก็บต้นฉบับตามที่ป้อน13 |
| การเก็บ | ความยาวคอลัมน์ไม่พอจากคู่เซอร์โรเกตและ IVS การตัดตามหน่วยรหัส | เก็บใน UTF-8/UTF-16 และให้ความยาวคอลัมน์เผื่อเป็นหน่วยรหัส ตัดในหน่วยกราฟีม |
| การแสดง | □ เพราะแบบอักษรไม่มีรูป รูปเปลี่ยนผ่านการสำรอง | ระบุแบบอักษรที่แสดงชุดอักขระเป้าหมายได้อย่างชัด และยืนยันความครอบคลุมมาตรฐานบนระบบปฏิบัติการเป้าหมาย |
| การพิมพ์และ PDF | ความต่างของรูประหว่างจอกับแบบพิมพ์ การวาดทดแทนฝั่งที่เปิดดู | จัดแบบอักษรบนจอและบนแบบพิมพ์ให้ตรง และฝังชุดย่อยใน PDF หลังยืนยันสัญญาอนุญาต11 |
| การทำงานร่วมกับระบบอื่น | คันจิเพิ่มของ JIS X 0213, IVS และไกจิกลายเป็น ? หรือ 〓 ในการแปลง Shift_JIS (CP932) |
ระบุการเข้ารหัสอักขระและชุดอักขระในข้อกำหนดการทำงานร่วม หากการทำงานร่วม CP932 ยังอยู่ ให้อิมพลีเมนต์การตรวจอักขระแปลงไม่ได้และกฎการแทน |
การทำให้เป็นบรรทัดฐานโดยเฉพาะคือกับดักที่เป็นธีมของบทความนี้เอง กระบวนการที่ใช้ “ด้วยเจตนาดี” ที่บดความต่างของอักขระผันแปรและความกว้างเต็มกับครึ่ง ต้นฉบับตามที่เป็น การประมวลผลบนสำเนา คือหลัก อุบัติเหตุการเข้ารหัสอักขระในการทำงานร่วม CSV ครอบคลุมลึกใน “CSV ไม่ใช่ "แค่ข้อความ"”
flowchart TB
accTitle: ต้นฉบับตามที่เป็น การประมวลผลบนสำเนา
accDescr: เก็บสตริงที่ป้อนตามที่เป็นเป็นต้นฉบับ ใช้การทำให้เป็นบรรทัดฐานกับสำเนาที่จำกัดตามการใช้อย่างการสร้างคีย์ค้นหา การใช้ NFKC กับต้นฉบับทำให้เสียความต่างของอักขระผันแปรและความกว้างเต็มกับครึ่ง
input["สตริงที่ป้อน"] --> orig["ต้นฉบับ: เก็บตามที่ป้อน"]
input --> copy["สำเนา: ทำให้เป็นบรรทัดฐาน จำกัดตามการใช้"]
copy -.-> use["การสร้างคีย์ค้นหา และคล้ายกัน"]
orig -.-> ng["NFKC บนต้นฉบับบดความต่าง"]
ภาพ 15: จำกัดการทำให้เป็นบรรทัดฐานตามการใช้แล้วใช้กับสำเนา เก็บต้นฉบับตามที่ป้อน
10. สรุป
- แยกปัญหาอักขระก่อนเป็น “ชั้นข้อมูล (การเข้ารหัสอักขระ)” กับ “ชั้นลักษณะ (แบบอักษร)” � คือสัญญาณของอุบัติเหตุชั้นข้อมูล □ ของอุบัติเหตุชั้นลักษณะ
- JIS X 0213:2004 เปลี่ยนรูปตัวอย่างของอักขระ 168 ตัว และ Windows มีรูป JIS2004 เป็นค่าเริ่มต้นตั้งแต่ Vista เป็นต้นไป 葛, 辻 และ 飴 ที่ดูต่างตามสภาพแวดล้อมคือประวัติของแบบอักษร ไม่ใช่ข้อมูลเสีย
- ทางมาตรฐานของการตรึงรูปเป็นข้อมูลคือ IVS แต่หากไม่มีแบบอักษรรองรับและแอปรองรับ จะสำรองไปรูปเริ่มต้น อย่าลืมผลกระทบการอิมพลีเมนต์ที่อักขระหนึ่งตัวยาวได้ถึงสี่หน่วยรหัส UTF-16
- ไกจิ (EUDC) คือสินทรัพย์เฉพาะเครื่องนั้นและเดินทางกับข้อมูลไม่ได้ คำตอบสมจริงคือทำรายการตอนโยกย้าย แทนที่จากตารางคู่ไปอักขระปกติหรือ IVS และหยุดสร้างใหม่
- ระบบที่จัดการชื่อบุคคลตัดสินชุดอักขระที่ยอมรับแล้วระบุ รัฐกำลังมาตรฐานสู่มาตรฐานอักขระราชการบนรากฐานของอักขระรวมโคเซกิและแพลตฟอร์มข้อมูลอักขระ และระบบที่ทำงานร่วมต้องตามการเคลื่อนนั้น
- สำหรับแบบพิมพ์และ PDF “จัดแบบอักษรให้ตรงกับจอ ยืนยันสัญญาอนุญาต แล้วฝัง” คือเส้นฐาน สำหรับการเก็บระยะยาว พิจารณา PDF/A
- การทำให้เป็นบรรทัดฐาน NFKC การตัดตามหน่วยรหัส และการแปลง CP932 คือสามจุดที่เงียบ ๆ ทำให้เสียอักขระผันแปรและไกจิ ทำให้การเก็บต้นฉบับและการประมวลผลในหน่วยกราฟีมเป็นหลัก
ครั้งถัดไปที่ถูกบอกว่า “อักขระต่าง” ก่อนอื่นจัดคำถามใหม่แบบนี้ จุดรหัสเหมือนกันหรือต่างกัน หากเหมือนกันคือปัญหาแบบอักษร หากต่างกันคือปัญหาข้อมูล การเคลื่อนหนึ่งนั้นกันคุณจากจุดเข้าสอบสวนที่ผิด
flowchart TB
accTitle: คำถามแรกที่ตัดสินจุดเข้าของการสอบสวน
accDescr: เมื่อถูกบอกว่าอักขระต่าง ก่อนอื่นเทียบว่าจุดรหัสเหมือนกันหรือต่างกัน หากเหมือนกันเริ่มสอบสวนเป็นปัญหาแบบอักษร หากต่างกันเป็นปัญหาข้อมูล
said["ถูกบอกว่าอักขระต่าง"] --> cmp{"จุดรหัสเหมือนกัน?"}
cmp -->|เหมือนกัน| fontp["ปัญหาแบบอักษร"]
cmp -->|ต่างกัน| datap["ปัญหาข้อมูล"]
ภาพ 16: หากจุดรหัสเหมือนกัน เริ่มสอบสวนเป็นปัญหาแบบอักษร หากต่างกันเป็นปัญหาข้อมูล
บทความที่เกี่ยวข้อง
- บทนำการเข้ารหัสข้อความ Windows - โมจิบาเกะที่เกิดเมื่อรวมกับ Linux
- การเข้ารหัสข้อความและส่วนท้ายบรรทัดของ Windows - พื้นฐานของโมจิบาเกะและ CRLF/LF
- การพิมพ์และเอาต์พุต PDF ในแอปธุรกิจ Windows — การเลือกระหว่าง System.Drawing.Printing, WPF และไลบรารีรายงาน
- การทำให้แอป WinForms/WPF เป็นท้องถิ่น — resx, แอสเซมบลีดาวเทียม และการสลับวัฒนธรรมในทางปฏิบัติ
- CSV ไม่ใช่ “แค่ข้อความ”: คู่มือปฏิบัติการจัดการ CSV ในแอปธุรกิจ C# (การเข้ารหัส ความเข้ากันได้กับ Excel การป้องกันการฉีด)
- บทนำการเข้าถึงแอป Windows — เตรียม UI Automation และข้อกำหนดการปรับที่สมเหตุสมผล
ด้านให้คำปรึกษาที่เกี่ยวข้อง
KomuraSoft LLC รับการออกแบบและการสอบสวนรอบอักขระในระบบธุรกิจ จากการแยกสาเหตุของอาการอย่าง “อักขระต่างบนจอและบนแบบพิมพ์” หรือ “หลังโยกย้ายชื่อบุคคลกลายเป็น □” ผ่านการทำรายการไกจิและการสร้างตารางตัวแทนตอนโยกย้ายจากระบบเดิม การออกแบบชุดอักขระที่ยอมรับของระบบที่จัดการชื่อบุคคล และการตรวจทานการกำหนดค่าการฝังแบบอักษรของแบบพิมพ์และ PDF เราครอบคลุมทั้งชั้นรหัสและชั้นแบบอักษร
- การพัฒนาแอปพลิเคชัน Windows
- การใช้ประโยชน์และโยกย้ายสินทรัพย์ซอฟต์แวร์เดิม
- ที่ปรึกษาด้านเทคนิคและการตรวจทานการออกแบบ
- ติดต่อเรา
ลิงก์อ้างอิง
-
Morisawa Inc., JIS X 0213:2004 (JIS2004) | Font glossary. ว่าด้วยรูปตัวอย่างของคันจิ 168 ตัวถูกแก้ใน JIS X 0213:2004 ตาม Hyogai Kanji Jitaihyo ให้เป็นรูปมาตรฐานการพิมพ์ (ที่เรียกรูพจนานุกรมคังซี) และว่าด้วยแบบอักษรที่รองรับ JIS2004 ถูกใส่เป็นมาตรฐานใน Windows Vista ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, MS Gothic font family. ว่าด้วยรูปเริ่มต้นของตระกูล MS Gothic เป็นฐาน JIS2004 และการเข้าถึงรูปมรดก JIS90 ผ่านคุณลักษณะ OpenType ‘jp90’ ↩ ↩2 ↩3
-
Microsoft Learn, The Unicode standard. ว่าด้วยลำดับผันแปรประกอบด้วยอักขระฐานบวกตัวเลือกผันอักษร (VS1–VS256, U+FE00–U+FE0F และ U+E0100–U+E01EF) ว่าด้วยตัวอย่างการแยก U+845B 葛 จาก U+845B+U+E0100 (VS17) (สถานีนิชิ-คาไซและนครคัตสึรางิ) และว่าด้วยแบบอักษรรองรับจำเป็นสำหรับการแสดง ↩ ↩2 ↩3
-
Unicode Consortium, Ideographic Variation Database. ทะเบียน IVS ตาม UTS #37 ว่าด้วยคอลเลกชันอย่าง Adobe-Japan1 (2007), Hanyo-Denshi (2010) และ Moji_Joho (2014) ที่ลงทะเบียน และการลงทะเบียนเพิ่มในคอลเลกชัน Moji_Joho ในฉบับสิงหาคม 2026 ด้วย ↩ ↩2
-
Microsoft Learn, cmap — Character to Glyph Index Mapping Table (OpenType spec). ว่าด้วยแบบอักษร OpenType อิมพลีเมนต์ลำดับผันแปร Unicode ในตารางย่อย cmap รูปแบบ 14 ว่าด้วยความต่างระหว่าง UVS เริ่มต้นกับไม่เริ่มต้น และว่าด้วยตัวอย่างการใช้ในแบบอักษรที่รองรับ JIS2004 ↩ ↩2
-
Microsoft Learn, End-User-Defined and Private Use Area Characters. ว่าด้วยไกจิ (EUDC) และอักขระพื้นที่ใช้ส่วนตัว (PUA) ถูกนิยามอิสระโดยผู้ใช้หรือองค์กร และว่าด้วยจุดรหัสเดียวกันอาจมีการกำหนดต่าง — และชนกัน — ตามคอมพิวเตอร์ ↩ ↩2
-
Microsoft Learn, Character Sets and Fonts. ว่าด้วย PUA (U+E000–U+F8FF และคล้ายกัน) ถูกใช้เพื่อวัตถุประสงค์ EUDC ของ Unicode ว่าด้วยการสร้างรูปในตัวแก้ไขอักขระส่วนตัว และว่าด้วยแบบอักษร EUDC ถูกติดตั้งซ่อนเป็นไฟล์ .tte และผูกกับแบบอักษรในรีจิสทรี HKEY_CURRENT_USER\EUDC ↩ ↩2
-
Ministry of Justice, Koseki Unified Character Information — search-condition input. ไซต์ค้นหาอย่างเป็นทางการของอักขระรวมโคเซกิที่กระทรวงยุติธรรมให้ ว่าด้วยการค้นหารูป การอ่าน และข้อมูลที่เกี่ยวข้องของอักขระที่ใช้ในทะเบียนบ้าน ↩ ↩2
-
Character Information Technology Promotion Council, Character Information Platform project. ว่าด้วยแพลตฟอร์มข้อมูลอักขระ (รูปอักษร MJ รายการข้อมูลอักขระ MJ และแบบอักษร IPAmj Mincho) ที่ IPA จัดโดยการสนับสนุนจากกระทรวงเศรษฐกิจ การค้า และอุตสาหกรรมและอื่น ๆ และครอบคลุมคันจิประมาณ 60,000 ตัวที่ใช้ในงานบริหาร ตอนนี้โอนไปสภาและเผยแพร่ ↩ ↩2
-
Digital Agency, Report of the Study Group on the Operation of Character Requirements in Local-Government Information Systems (July 2024). ว่าด้วยไกจิที่ใช้ในเทศบาลกล่าวว่าประมาณสองล้านอักขระ ว่าด้วย “มาตรฐานอักขระราชการ” (มักเรียก MJ+) ซึ่งเป็นการขยายแพลตฟอร์มข้อมูลอักขระ เป็นชุดอักขระสำหรับชื่อบุคคลและคล้ายกันในระบบที่สอดคล้องมาตรฐาน โดยการเข้ารหัสอักขระ JIS X 0221:2020 ว่าด้วยการใช้มาตรฐานอักขระราชการสำหรับการทำงานร่วมข้อมูลของชื่อบุคคลและคล้ายกัน และ JIS X 0213:2012 สำหรับการทำงานร่วมกับสมาร์ตโฟนและคล้ายกัน และว่าด้วยนโยบายระบุตัวตนไกจิแบบเดิมกับมาตรฐานอักขระราชการและไม่ใช้ ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, OS/2 — OS/2 and Windows Metrics (OpenType spec). ว่าด้วยฟิลด์ fsType ของแบบอักษรนิยามสัญญาอนุญาตการฝัง (Installable / Restricted License / Preview & Print / Editable บิตห้ามชุดย่อย และคล้ายกัน) และว่าด้วยแอปพลิเคชันไม่ได้รับอนุญาตให้ฝังแบบอักษรที่การฝังไม่ได้รับอนุญาต ↩ ↩2 ↩3
-
PDF Association, PDF/A Basics. ว่าด้วย PDF/A สำหรับการเก็บระยะยาว (ISO 19005) ต้องการให้องค์ประกอบที่จำเป็นในการแสดงเอกสารอยู่ในไฟล์ โดยการฝังแบบอักษรเป็นตัวอย่างที่ต้องการตัวแทน ↩ ↩2
-
Microsoft Learn, Using Unicode Normalization to Represent Strings. ว่าด้วยสี่รูปแบบการทำให้เป็นบรรทัดฐาน Unicode NFC/NFD/NFKC/NFKD และว่าด้วยรูปแบบ KC/KD รวมอักขระความเข้ากันได้อย่างอักขระความกว้างเต็มกับครึ่งและทำให้เสียข้อมูล จึงโดยทั่วไปไม่เหมาะเป็นรูปแบบเก็บต้นฉบับของสตริง ↩ ↩2
-
Microsoft Learn, BIZ UDGothic font family. ว่าด้วยแบบออกแบบสากลของ Morisawa BIZ UD Gothic ถูกใส่เป็นแบบอักษรเสริมญี่ปุ่นตั้งแต่ Windows 10 เวอร์ชัน 1809 เป็นต้นไป ↩
-
Microsoft Learn, Fonts (Globalization documentation). ว่าด้วยกลไกการสำรองแบบอักษร ว่าด้วยการเชื่อมแบบอักษร GDI (รีจิสทรี FontLink\SystemLink) ว่าด้วยความหมายของรูปเริ่มต้น (เต้าหู้) และว่าด้วยการเชื่อมแบบอักษรไม่ใช่การแทนของการเลือกแบบอักษรที่ถูก ↩ ↩2
บทความที่เกี่ยวข้อง
บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง
เชิงลึกของการจำลองเสมือนบน Windows (ตอนที่ 3) — เครื่องเสมือนที่บูตในไม่กี่วินาที: ทำไม WSL2, Windows Sandbox และคอนเทนเนอร์จึงเบา
ทำไม WSL2 และ Windows Sandbox จึงเริ่มในไม่กี่วินาทีและรู้สึกเบา? บทความนี้อธิบายกลไก ตั้งแต่ dynamic base image และ direct map ไปจนถึงกา...
เชิงลึกของการจำลองเสมือนบน Windows (ตอนที่ 2) — หน่วยความจำที่แม้เคอร์เนลก็มองไม่เห็น: กลไกของ VBS, HVCI และ Credential Guard
เมื่อติดตั้งใหม่บนฮาร์ดแวร์ที่รองรับ VBS จะเปิดตามค่าเริ่มต้น และใช้ hypervisor กับ SLAT สร้างการแยกที่แข็งกว่าเคอร์เนล บทความนี้อธิบายโค...
เชิงลึกของการจำลองเสมือนบน Windows (ตอนที่ 1) — Windows ของคุณรันอยู่ที่ไหนจริง ๆ? Hypervisor และพาร์ติชัน
เมื่อเปิด Hyper-V แล้ว Windows ฝั่งโฮสต์เองก็รันบน hypervisor ในฐานะ root partition บทความนี้อธิบายรากฐานของการจำลองเสมือนผ่านบทบาทของ VT...
Win32 Thread Pool API — คอนเคอร์เรนซีโดยไม่สร้างเธรดเอง ด้วย CreateThreadpoolWork
โค้ดเนทีฟของคุณกระจายการเรียก CreateThread ไปทั่วหรือไม่ บทความนี้อธิบาย Win32 thread pool API ที่ออกแบบใหม่ใน Vista — ออบเจ็กต์สี่ชนิด w...
Named Pipe ในทางปฏิบัติ — IPC มาตรฐานของ Windows ตั้งแต่การออกแบบถึงความปลอดภัย
คู่มือเชิงปฏิบัติเรื่อง named pipe ซึ่งเป็นการสื่อสารระหว่างโปรเซสมาตรฐานของ Windows บทความนี้จัดระเบียบจากแหล่งปฐมภูมิ ทั้งการเลือกระหว่...
หัวข้อที่เกี่ยวข้อง
หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ
หัวข้อเทคนิคของ Windows
ประตูสู่การพัฒนา Windows การตรวจสอบบั๊ก และการใช้ประโยชน์จากสินทรัพย์เดิม
บริการที่เกี่ยวข้องกับหัวข้อนี้
บทความนี้เกี่ยวข้องโดยตรงกับบริการต่อไปนี้
พัฒนาแอป Windows
แอปธุรกิจ การเชื่อมต่ออุปกรณ์ และเครื่องมือสื่อสาร ตั้งแต่ความต้องการจนถึงการพัฒนา
คำถามที่พบบ่อย
คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้
- ทำไมตัว 葛 เดียวกันจึงดูต่างกันตามเครื่องหรือแบบพิมพ์
- มีแนวโน้มเป็นความต่างของรูปอักษรในแบบอักษรมากกว่าโมจิบาเกะ JIS X 0213:2004 (JIS2004) แก้รูปตัวอย่างของคันจิ 168 ตัวให้เป็นรูปมาตรฐานการพิมพ์ และ Windows ก็ทำให้รูป JIS2004 เป็นค่าเริ่มต้นใน MS Gothic / MS Mincho และอื่น ๆ ตั้งแต่ Vista เป็นต้นไป 葛, 辻, 飴 และคล้ายกันเป็นตัวอย่างตัวแทน จุดรหัส Unicode (ข้อมูล) ยังคงเดิม มีเพียงรูปที่แบบอักษรถือ (ลักษณะ) ที่เปลี่ยน เทียบข้อมูลแล้วตรงกัน ความไม่ตรงของรูประหว่างภาพแบบพิมพ์ยุค XP กับจอของเครื่องใหม่คือพฤติกรรมที่ระบุ หากอยากจัดรูปให้ตรงด้วย ใช้แบบอักษรเดียวกันบนจอและบนแบบพิมพ์ หรือระบุรูปด้วยตัวเลือกผันอักษร
- ถ้าใช้ตัวเลือกผันอักษร (IVS) จะแก้ปัญหาทุกรูปในชื่อบุคคลไหม
- ไม่แก้ IVS คือกลไกที่วางตัวเลือกจาก U+E0100 เป็นต้นไปทันทีหลังอักขระฐานเพื่อระบุรูปเป็นข้อมูล และรูปที่ระบุแสดงได้เฉพาะเมื่อมีแบบอักษรรองรับอย่าง IPAmj Mincho และแอปรองรับทั้งคู่ ในสภาพแวดล้อมที่ไม่รองรับ พฤติกรรมที่ระบุคือละเว้นตัวเลือกแล้วแสดงรูปเริ่มต้นของอักขระฐาน ในบางสภาพแวดล้อมตัวเลือกอาจปรากฏเป็น □ ด้วย ต่อไป อักขระที่มี IVS หนึ่งตัวยาวได้ถึงสี่หน่วยรหัสใน UTF-16 ซึ่งกระทบการนับอักขระ การตัด และการออกแบบความยาวคอลัมน์ฐานข้อมูล หากนำเข้ามา ให้ยืนยันขอบการรองรับผ่านการแสดง การพิมพ์ และระบบปลายทางก่อนใช้
- อักขระที่ลงทะเบียนเป็นไกจิ (EUDC) แสดงบนเครื่องอื่นหรือใน PDF ได้ไหม
- โดยหลักการไม่ได้ ไกจิคือกลไกที่ผู้ใช้ลงทะเบียนรูปเข้าไฟล์ eudc.tte ของเครื่องนั้นที่จุดรหัสในพื้นที่ใช้ส่วนตัวของ Unicode (ตั้งแต่ U+E000) จุดรหัสเดียวกันบนเครื่องอื่นไม่นิยามหรือเป็นรูปอื่น ชะตากรรมของการส่งไปเมล PDF หรือระบบอื่นจึงเป็น □ หรือดูเป็นอักขระอื่น หากสืบทอดข้อมูลที่มีไกจิอยู่แล้ว เส้นทางสมจริงตอนโยกย้ายคือทำรายการการใช้พื้นที่ใช้ส่วนตัว สร้างตารางคู่กับอักขระ Unicode ปกติหรือตัวเลือกผันอักษร แล้วแทนที่ ควรหลีกเลี่ยงการสร้างไกจิใหม่ในระบบใหม่
- ระบบธุรกิจควรรับอักขระในชื่อบุคคลได้ไกลแค่ไหน
- สิ่งแรกคือ "ตัดสินชุดอักขระที่ยอมรับแล้วระบุเป็นข้อกำหนด" ทะเบียนบ้านมีอักขระรวมโคเซกิประมาณ 56,000 ตัว และระบบที่สอดคล้องมาตรฐานรัฐกำลังมุ่งใช้มาตรฐานอักขระราชการ ซึ่งเป็นการขยายแพลตฟอร์มข้อมูลอักขระ แต่ระบบธุรกิจทั่วไปไม่มีข้อผูกพันต้องรับระดับเดียวกันอย่างไร้ขีด ออกแบบสมจริงคือตัดสินช่วงเช่น "ถึงขอบของ JIS X 0213" หรือ "ไม่รับตัวเลือกผันอักษรหรือพื้นที่ใช้ส่วนตัว" ตรวจตอนป้อน และดำเนินการกรณีนอกช่วงด้วยการเตือนหรือการแทนทางเลือก เฉพาะระบบที่ทำงานร่วมกับระบบรัฐหรือเทศบาลต้องตามการเคลื่อนของมาตรฐานอักขระราชการและข้อกำหนดการทำงานร่วมบน JIS X 0221
- จะทำให้แบบพิมพ์หรือ PDF แสดงอักขระเดียวกับจอได้อย่างไร
- เส้นฐานคือระบุแบบอักษรเดียวกันบนจอและบนแบบพิมพ์ และฝังแบบอักษรใน PDF หากแบบอักษรต่างกัน ข้อมูลเดียวกันอาจเปลี่ยนรูป หากเครื่องที่เปิดดูไม่มีแบบอักษร จะใช้แบบอักษรทดแทนวาดและลักษณะพัง ว่าฝังได้หรือไม่ถูกกำหนดโดยสัญญาอนุญาตของแบบอักษร (OpenType fsType) จึงยืนยัน อย่าปล่อยให้ไลบรารีรายงานตัดสิน การฝังชุดย่อยซึ่งฝังเฉพาะอักขระที่ใช้ยังทำให้ขนาดไฟล์ลงได้ หากการเก็บระยะยาวเป็นข้อกำหนด พิจารณา PDF/A ซึ่งต้องการการฝังแบบอักษร