مطبات الخطوط والأحرف اليابانيّة ── معالجة JIS2004 وIVS وgaiji في تطبيقات الأعمال
· غو كومورا · الخطوط اليابانيّة, JIS2004, أحرف متغيّرة, Gaiji, ترميز الأحرف, Unicode, تطبيقات الأعمال, التقارير, Windows
«حرف 葛 في قائمة العملاء يبدو مختلفاً على الشاشة وعلى النموذج المطبوع. اشتكى العميل أنّ البيانات لا بدّ فاسدة.» ── في صيانة أنظمة الأعمال، استشارة من هذا النوع ليست نادرة. وأخرى شائعة: «حرف في اسم شخص لا يظهر على مستند نقدِّمه إلى الدائرة الحكوميّة. كان يظهر على الحاسوب القديم؛ بعد الاستبدال صار □.»
كلاهما يُدعى في الميدان «mojibake»، لكنّهما مشكلة مختلفة عن mojibake الناتج عن عدم تطابق الترميز. في الأولى، لم يتغيّر بتّ واحد من البيانات وتغيّر المظهر فقط؛ في الثانية، ضاعت «gaiji» كانت موجودة على ذلك الحاسوب وحده.
flowchart TB
accTitle: ما الاستشارتان الشائعتان حقّاً
accDescr: الاستشارة أنّ 葛 يبدو مختلفاً على الشاشة وعلى النموذج حالة تغيّر فيها المظهر فقط وبقيت البيانات نفسها؛ الاستشارة أنّ حرفاً صار □ بعد استبدال حاسوب حالة ضاعت فيها gaiji كانت على ذلك الحاسوب وحده؛ كلاهما مشكلة مختلفة عن mojibake عدم تطابق الترميز
c1["استشارة 1: الشكل يختلف على الشاشة والنموذج"] --> r1["البيانات لم تتغيّر؛ المظهر فقط تغيّر"]
c2["استشارة 2: صار □ بعد استبدال"] --> r2["gaiji كانت على ذلك الحاسوب وحده ضاعت"]
r1 --> diff["مشكلة مختلفة عن mojibake الترميز"]
r2 --> diff
الشكل 1: الاستشارتان اللتان تُدعيان «mojibake» كلتاهما مشكلة مختلفة عن عدم تطابق الترميز.
وعد هذا المقال بسيط. إن فصلت طبقة رمز الحرف (البيانات) عن طبقة الخطّ (المظهر)، صارت معظم متاعب الأحرف اليابانيّة قابلة للمعالجة. من تغيير شكل JIS2004، ومحدِّدات التنويع الأيديوغرافيّ (IVS)، وgaiji (EUDC)، عبر منصّة أحرف الحكومة، إلى اختيار الخطوط وتضمينها، منظَّم بشكل يستطيع مطوِّرو أنظمة الأعمال وموظّفو تقنيّة المعلومات استخدامه للقرار.
أمّا «mojibake» نفسه الذي يحدث في تحويل Shift_JIS ↔ UTF-8 فمشمول في مقالات قائمة، لذا يركِّز هذا المقال على مشكلة «الرموز تدور ذهاباً وإياباً بشكل صحيح، لكنّ المظهر أو قابليّة العرض منحرفة».
1. الخلاصة أوّلاً
- «Mojibake» و«الشكل مختلف» مشكلتان مختلفتان. Mojibake حادث في طبقة البيانات بسوء تفسير تسلسل بايتات؛ فرق الشكل حادث في طبقة المظهر بفرق في الأشكال التي يحملها الخطّ؛ والعلاجات مختلفة تماماً.
- حتّى مع نقطة رمز Unicode نفسها، الشكل المعروض يعتمد على الخطّ. راجع JIS X 0213:2004 الأشكال النموذجيّة لـ 168 حرفاً مثل 葛 و辻 و飴 إلى أشكال معيار الطباعة، وجعل Windows أيضاً أشكال JIS2004 الافتراضيّ في MS Gothic / MS Mincho من Vista فصاعداً.12
- الوسيلة القياسيّة لتثبيت شكل كبيانات محدِّد تنويع أيديوغرافيّ (IVS). تحدِّد شكلاً بتسلسل حرف أساس زائد محدِّد من U+E0100 فصاعداً؛ مجموعات مثل Adobe-Japan1 وHanyo-Denshi وMoji_Joho (منصّة معلومات الأحرف) مسجَّلة في IVD ليونيكود.34
- في بيئة غير داعمة السلوك المحدَّد لـ IVS أن يُتجاهَل المحدِّد ويُعرض شكل حرف الأساس الافتراضيّ. غير أنّ حرفاً حامل IVS يمكن أن يبلغ أربع وحدات رمز في UTF-16، لذا تحتاج تطبيقات العدّ والقصّ انتباهاً.5
- لـ gaiji (EUDC) مصير «لا يمكن أن تظهر إلا على ذلك الحاسوب». لا معنى متَّفق عليه لنقطة رمز في منطقة الاستخدام الخاصّ، وشكل مسجَّل في eudc.tte لا ينتقل إلى حاسوب آخر ولا إلى بريد ولا إلى PDF.67
- نظام يعالج أسماء أشخاص ينبغي أن يقرّر مجموعة الأحرف المقبولة ويذكرها. في الجانب الحكوميّ، بناءً على أحرف كوسيكي الموحَّدة ومنصّة معلومات الأحرف، تتّجه الأنظمة المطابقة للمعيار إلى استخدام «الأحرف القياسيّة للشؤون الإداريّة».8910
- للنماذج وPDF، «حاذِ الخطّ مع الشاشة، وضمِّنه» هو الأساس. جواز التضمين تحدّده رخصة الخطّ (fsType)، وPDF/A للاحتفاظ طويل الأمد يتطلّب تضمين الخطّ.1112
- لا تطبِّق التطبيع (NFKC) ببساطة على بيانات أسماء الأشخاص. توحيد العرض الكامل ونصفه، واستبدال أحرف التوافق، يفقدان تمييزات ينبغي إبقاؤها.13
بجملة واحدة: «أيّ تسلسل بايتات تخزِّن» مشكلة تصميم بيانات؛ «كيف يبدو» مشكلة تصميم خطوط. إن ناقشت الاثنتين مختلطتين، حتّى المشكلات التي كان يمكن إصلاحها تصبح غير قابلة للإصلاح.
2. التفكير في البيانات والمظهر منفصلين ── نقاط الرمز والأشكال
في يونيكود، يُمثَّل الحرف بعدد يُدعى نقطة رمز. 葛 هو U+845B، وهذا العدد نفسه على كلّ حاسوب. أمّا كيف يُرسَم ذلك العدد على شاشة أو على ورق فيقرّره الشكل الذي يحمله الخطّ. سلوك عاديّ أن يختلف U+845B نفسه في تفاصيل شكله بين الخطّ أ والخطّ ب.
بهاتين الطبقتين مقدِّمةً، يمكن تقسيم أعراض الميدان كالتالي.
| الطبقة | الحادث الذي يقع | أعراض نموذجيّة | العلاج الرئيس |
|---|---|---|---|
| طبقة البيانات (ترميز الأحرف) | سوء تفسير ترميز، فقدان في التحويل | Mojibake مثل 縺ｯ، استبدال بـ ? أو 〓، 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 - mojibake الذي يحدث عند التكامل مع Linux» و«ترميزات النصّ ونهايات السطور في Windows - أساسيّات mojibake و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 jp90.21
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) يُعرض بالشكل الذي يكتب 人 في الداخل أيضاً
- لذلك صورة ممسوحة لنموذج طُبع على النظام القديم وعرض الشاشة على حاسوب جديد يختلفان في شكل الحرف. مقارنة بيانات تتطابق تماماً
ما إذا كان جذر shinnyo لـ 辻 نقطة واحدة أم اثنتين، وشكل جذر «أكل» لـ 飴، وما شابه الأمر نفسه. إن لم تعرف هذا التاريخ، يميل التحقيق إلى الاتّجاه الخاطئ «فُسدت البيانات في الترحيل». عندما يُقال إنّ مظهر حرف يختلف قبل ترحيل وبعده، قارن أوّلاً نقاط الرمز، وإن تطابقت فاشكّ في فرق شكل الخطّ ── هذا الترتيب الصحيح.
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 | برنامج تطوير بيئة تبادل معلومات Hanyo-Denshi. يقابل أحرفاً حكوميّة كأحرف سجلّ الأسرة وسجلّ السكّان الأساسيّ |
| Moji_Joho | 2014 | يقابل منصّة معلومات الأحرف (MJ). يُستخدم مع IPAmj Mincho. تسجيلات إضافيّة أيضاً في أغسطس 2026 |
توثيق مايكروسوفت، مثلاً، يعطي مثال 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 == 3. Substringوالقصّ بطول ثابت يخاطران بفصل حرف الأساس عن المحدِّد- تحقّق عدّ الأحرف والقصّ ينبغي أن يكونا بوحدات الغرافيم (واجهات مثل
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["وحدتا رمز دائماً"]
base --> total["حتّى 4 وحدات UTF-16"]
vs --> total
total -.-> risk["انقسام في قصّ ثابت"]
الشكل 7: حرف حامل IVS يمكن أن يبلغ أربع وحدات رمز في UTF-16؛ القصّ بوحدة الرمز خطر.
5. Gaiji (EUDC) ── أحرف تظهر على ذلك الحاسوب وحده
Gaiji آليّة يعيِّن فيها مستخدم شكلاً من صنعه إلى نقطة رمز في منطقة الاستخدام الخاصّ ليونيكود (PUA: U+E000–U+F8FF وما شابه). نقطة رمز منطقة استخدام خاصّ لا معنى متَّفقاً عليه عالميّاً؛ يمكن تعيين U+E000 نفسه حرفاً مختلفاً لكلّ حاسوب ولكلّ منظّمة.6
على Windows تنشئ الشكل بمحرِّر الأحرف الخاصّة (eudcedit.exe)، ويُحفَظ في ملفّ خطّ يُدعى eudc.tte. يُثبَّت هذا الملفّ خطاً مخفيّاً ويُربَط بكلّ خطّ في سجلّ HKEY_CURRENT_USER\EUDC.7 في عصر Shift_JIS (CP932) كان نطاق gaiji 0xF040–0xF9FC، وعند التحويل إلى يونيكود يُربَط بمنطقة الاستخدام الخاصّ.
عاقبة هذه الآليّة واضحة.
- eudc.tte يخصّ ذلك الحاسوب (ذلك المستخدم) ولا ينتقل إلى الطرف الآخر مع البيانات
- لحظة تمريره إلى بريد أو PDF أو الويب أو نظام آخر يصبح □ أو يبدو gaiji مختلفة للطرف الآخر
- إن نسيت ترحيل eudc.tte في ترحيل نظام تشغيل أو استبدال حاسوب، يحدث «حرف كان يظهر على الحاسوب القديم لن يظهر»
هذه هويّة الاستشارة الثانية في الافتتاح.
flowchart TB
accTitle: لماذا تظهر gaiji على ذلك الحاسوب وحده
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؛ لا يبقى في البيانات إلا رقم منطقة استخدام خاصّ، لذا تبدو gaiji مكسورة متى غادرت الحاسوب.
5.1. جواب واقعيّ لنظام استقبل gaiji أصلاً
المشكلة عندما تكون بيانات موروثة من نظام قديم فيها gaiji مختلطة أصلاً. الإجراء الذي نوصي به في ارتباطات الترحيل كالتالي.
- حقِّق: امسح قواعد البيانات والملفّات بتعبير نمطيّ لمنطقة الاستخدام الخاصّ (U+E000–U+F8FF)، وجرِّد رموز gaiji المستخدمة وأعدادها. اجمع eudc.tte من حواسيب كلّ موقع وأكِّد الأشكال
- حدِّد: لكلّ gaiji، حقِّق «هل يمكن تمثيلها كحرف يونيكود عاديّ»، «هل يمكن تمثيلها بـ IVS»، «هل يوجد حرف مقابل في منصّة معلومات الأحرف (MJ)»، وابنِ جدول توافق أحرف بديلة. عمليّاً أكثريّة الحالات أنّ شكلاً قديماً صُنع كـ gaiji من JIS فحسب
- استبدل: استبدل البيانات من جدول التوافق. فقط عندما لا يوجد حرف مقابل حقّاً، أبقها صورة أو أرفق ملاحظة لذلك السجلّ
- اقطع: في النظام الجديد، ارفض إدخال منطقة الاستخدام الخاصّ في التحقّق، ولا تنشئ gaiji جديدة
flowchart TB
accTitle: إجراء ترحيل بيانات فيها gaiji
accDescr: جرِّد gaiji المستخدمة بمسح منطقة الاستخدام الخاصّ وجمع eudc.tte، وابنِ جدول توافق أحرف بديلة واستبدل، وفي النظام الجديد ارفض إدخال منطقة الاستخدام الخاصّ في التحقّق ولا تنشئ gaiji جديدة
st1["حقِّق: امسح PUA"] --> st2["حدِّد: جدول بدائل"]
st2 --> st3["استبدل من الجدول"]
st3 --> st4["اقطع: بلا gaiji جديدة"]
st1 -.-> tte["اجمع eudc.tte"]
st2 -.-> nomap["بلا خريطة: صورة أو ملاحظة"]
الشكل 9: رحِّل gaiji في أربع مراحل حقِّق وحدِّد واستبدل واقطع، ولا تنشئ gaiji جديدة.
الاتّجاه نفسه في الجانب الحكوميّ: صُرِّح بسياسة تحديد gaiji التي أنشأتها البلديّات بنفسها (يُقال نحو مليوني حرف على مستوى البلاد) فريداً مقابل الأحرف القياسيّة للشؤون الإداريّة المذكورة لاحقاً، وإيقاف استخدامها.10 «لا تزد gaiji؛ حدِّدها مقابل مجموعة أحرف موحَّدة» يصير نمط الترحيل المستقرّ في القطاعين العامّ والخاصّ.
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:2012.10 بنية «احتفظ بمجموعة أحرف واسعة داخليّاً، وتبادل مع الخارج في نطاق تستطيع بيئة عامّة عرضه» نفسها مرجع أيضاً لأنظمة القطاع الخاصّ.
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)»
- لا تقبل بلا حدّ. تصميم «إنّه يونيكود، فكلّ شيء جائز» سينكسر في مكان ما في العرض أو الطباعة أو التبادل
- قرّر تشغيل الأحرف خارج النطاق مسبقاً. قاعدة استبدال تمثيل بديل (شكل جديد، كاتاكانا) والصياغة التي تشرحها للشخص نفسها مواصفة نظام
- عندما يكون لنظام لاحق كالحكومة أو الماليّة قاعدة مجموعة أحرف، خذ تلك سلطة وحاذِ معها
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، منع الجزئيّ، وما شابه)، ويجب ألا تضمِّن خطاً تضمينه غير مرخَّص.11 لخطّ تجاريّ، تأكيد العقد مطلوب - اجعل التضمين الجزئيّ الأساس. إن ضمَّنت أشكال الأحرف المستخدمة فقط، لا تضطرّ إلى تحمّل خطّ يابانيّ كامل (عدّة ميغابايت إلى عشرات)
- إن كان هناك متطلَّب احتفاظ طويل الأمد، 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 في تطبيق أعمال الموقف السليم «على مسارات العرض والطباعة الرئيسة، أكمل بالخطوط المصمَّمة وحدها؛ الاحتياط تأمين لأحرف غير متوقَّعة». لتفكير اختيار الخطّ في واجهة متعدّدة اللغات، انظر أيضاً «تعدد اللغات في تطبيقات 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 وgaiji تصير ? أو 〓 في تحويل 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.
- Gaiji (EUDC) أصل يخصّ ذلك الحاسوب ولا يستطيع السفر مع البيانات. الجواب الواقعيّ الجرد عند الترحيل، والاستبدال من جدول توافق إلى أحرف عاديّة أو IVS، وإيقاف إنشاء جديدة.
- نظام يعالج أسماء أشخاص يقرّر مجموعة الأحرف المقبولة ويذكرها. الحكومة توحِّد نحو الأحرف القياسيّة للشؤون الإداريّة على أساس أحرف كوسيكي الموحَّدة ومنصّة معلومات الأحرف، ونظام يتبادل يحتاج إلى متابعة تلك الحركة.
- للنماذج وPDF، «حاذِ الخطّ مع الشاشة، أكِّد الرخصة، وضمِّن» هو الأساس. للاحتفاظ طويل الأمد، انظر PDF/A.
- تطبيع NFKC، والقصّ بوحدة الرمز، وتحويل CP932 النقاط الثلاث التي تكسر بهدوء الأحرف المتغيّرة وgaiji. اجعل تخزين الأصل والمعالجة بوحدات الغرافيم المبدأ.
في المرّة التالية التي يُقال لك «الحرف مختلف»، أعد صياغة السؤال أوّلاً هكذا. هل نقاط الرمز نفسها، أم مختلفة؟ إن كانت نفسها فمشكلة خطّ؛ إن كانت مختلفة فمشكلة بيانات. تلك الحركة الواحدة تمنعك من أخذ المدخل الخاطئ للتحقيق.
flowchart TB
accTitle: السؤال الأوّل الذي يقرّر مدخل التحقيق
accDescr: عندما يُقال إنّ الحرف مختلف، قارن أوّلاً ما إذا كانت نقاط الرمز نفسها أم مختلفة؛ إن كانت نفسها ابدأ التحقيق كمشكلة خطّ، إن كانت مختلفة كمشكلة بيانات
said["قيل لك إنّ الحرف مختلف"] --> cmp{"هل نقاط الرمز نفسها؟"}
cmp -->|"نفسها"| fontp["مشكلة خطّ"]
cmp -->|"مختلفة"| datap["مشكلة بيانات"]
الشكل 16: إن كانت نقاط الرمز نفسها، ابدأ التحقيق كمشكلة خطّ؛ إن كانت مختلفة، كمشكلة بيانات.
مقالات ذات صلة
- فهم ترميزات النصّ على Windows - لماذا يحدث mojibake وما الذي ينكسر عند دخول Linux إلى المعادلة
- شرح ترميزات النصّ ونهايات السطور في Windows - Shift_JIS و UTF-8 و UTF-16 و mojibake و CRLF و LF
- الطباعة وإخراج PDF في تطبيقات أعمال Windows ── كيفيّة الاختيار بين System.Drawing.Printing وWPF ومكتبات التقارير
- تعدد اللغات في تطبيقات WinForms/WPF ── الممارسة العملية لملفات resx وتجميعات الأقمار الصناعية (Satellite Assemblies) وتبديل الثقافة (Culture)
- ملف CSV ليس مجرد نص عادي ── الممارسة العملية لملفات CSV في تطبيقات C# (ترميز الأحرف وتوافق Excel والحماية من الحقن)
- مدخل إلى إمكان الوصول في تطبيقات Windows ── الاستعداد لأتمتة الواجهة ومتطلّبات الترتيبات التيسيرية
مجالات الاستشارة ذات الصلة
تتعامل شركة كومورا سوفت ذ.م.م. مع التصميم والتحقيق حول الأحرف في أنظمة الأعمال. من عزل سبب أعراض مثل «الحرف يختلف على الشاشة وعلى النموذج» أو «بعد الترحيل صار اسم شخص □»، عبر جرد gaiji وبناء جدول أحرف بديلة عند الترحيل من نظام قديم، وتصميم مجموعة الأحرف المقبولة لنظام يعالج أسماء أشخاص، ومراجعة إعداد تضمين الخطوط للنماذج و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 لتسلسلات تنويع يونيكود في جدول cmap الفرعيّ التنسيق 14؛ وحول التمييز بين UVS افتراضيّ وغير افتراضيّ؛ وأمثلة استخدام في خطوط قادرة على JIS2004. ↩ ↩2
-
Microsoft Learn, End-User-Defined and Private Use Area Characters. حول تعريف gaiji (EUDC) وأحرف منطقة الاستخدام الخاصّ (PUA) مستقلّاً من مستخدم أو منظّمة، وحول إمكان أن يكون لنقطة الرمز نفسها تعيين مختلف ── وأن تتصادم ── حسب الحاسوب. ↩ ↩2
-
Microsoft Learn, Character Sets and Fonts. حول استخدام PUA (U+E000–U+F8FF وما شابه) لأغراض EUDC ليونيكود؛ وحول إنشاء شكل في محرِّر الأحرف الخاصّة؛ وحول تثبيت خطّ 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). حول كون gaiji المستخدمة في البلديّات يُقال إنّها نحو مليوني حرف؛ وحول «Standard Characters for Administrative Affairs» (الشائعة MJ+)، امتداد منصّة معلومات الأحرف، كونها مجموعة أحرف أسماء الأشخاص وما شابه في الأنظمة المطابقة للمعيار، بترميز أحرف JIS X 0221:2020؛ وحول استخدام الأحرف القياسيّة للشؤون الإداريّة لتبادل معلومات أسماء الأشخاص وما شابه، وJIS X 0213:2012 للتبادل مع الهواتف الذكيّة وما شابه؛ وحول سياسة تحديد gaiji التقليديّة فريداً مقابل الأحرف القياسيّة للشؤون الإداريّة وعدم استخدامها. ↩ ↩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. حول أشكال تطبيع يونيكود الأربعة 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 وكيف تبني تطبيقات أعمال تصمد أمامها
فتحت الحاسوب المحمول فوجدت اتّصالات تطبيق الأعمال ميّتة ── السبب تصميم لم يحسب حساب السكون. يغطّي المقال تدفّق إشعار WM_POWERBROADCAST، و...
مدخل إلى إمكان الوصول في تطبيقات Windows ── الاستعداد لأتمتة الواجهة ومتطلّبات الترتيبات التيسيرية
على خلفيّة تعديل قانون القضاء على التمييز ضدّ ذوي الإعاقة الذي دخل حيّز التنفيذ في أبريل 2024، ينظِّم المقال التسمية في WinForms/WPF، وتش...
شرح ترميزات النصّ ونهايات السطور في Windows - Shift_JIS و UTF-8 و UTF-16 و mojibake و CRLF و LF
دليل عمليّ يوضّح كيف تتعايش UTF-8 و CP932 و UTF-16 و BOM ونهايات CRLF/LF في Windows، وكيف تشخّص mojibake وتمنع تلف البيانات.
فهم ترميزات النصّ على Windows - لماذا يحدث mojibake وما الذي ينكسر عند دخول Linux إلى المعادلة
يشرح المقال لماذا يحدث mojibake على Windows عند تبادل الملفّات مع Linux، ويوضّح طبقات الترميز المنفصلة (CP932، UTF-8، PowerShell) لتشخيصه...
أعماق الافتراضيّة في Windows（الجزء 3）── آلات افتراضيّة تقلع في ثوانٍ: لماذا WSL2 وWindows Sandbox والحاويات خفيفة هكذا
لماذا يبدأ WSL2 وWindows Sandbox في ثوانٍ ويبدوان خفيفَين هكذا؟ يشرح هذا المقال الآليّات، من الصور الأساسيّة الديناميّة والـ direct map ع...
أين يتصل هذا الموضوع
ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.
تطوير تطبيقات ويندوز
ندعم تطوير برامج ويندوز للأعمال، وتكامل الأجهزة، وأدوات التواصل.
الأسئلة الشائعة
أسئلة شائعة حول موضوع هذه المقالة.
- لماذا يبدو حرف 葛 نفسه مختلفاً حسب الحاسوب أو النموذج المطبوع؟
- الأرجح أنّه فرق في أشكال الخطّ لا mojibake. راجع JIS X 0213:2004 (JIS2004) الأشكال النموذجيّة لـ 168 كانجي إلى أشكال معيار الطباعة، وجعل Windows أيضاً أشكال JIS2004 الافتراضيّ في MS Gothic / MS Mincho وغيرهما من Vista فصاعداً. 葛 و辻 و飴 وما شابه أمثلة نموذجيّة: نقطة رمز Unicode (البيانات) تبقى نفسها، وما تغيّر هو الشكل الذي يحمله الخطّ (المظهر) فقط. قارن البيانات فتتطابق؛ اختلاف الشكل بين صورة نموذج من عصر XP وشاشة حاسوب جديد سلوك محدَّد. إن أردت محاذاة الأشكال أيضاً، استخدم الخطّ نفسه على الشاشة وعلى النموذج، أو حدِّد الشكل بمحدِّد تنويع أيديوغرافيّ.
- إن استخدمنا محدِّدات التنويع الأيديوغرافيّ (IVS)، هل يُحلّ كلّ مشكل شكل في أسماء الأشخاص؟
- لا. IVS آليّة تضع محدِّداً من U+E0100 فصاعداً مباشرةً بعد حرف أساس لتحديد شكل كبيانات، والشكل المحدَّد يظهر فقط عندما يكون خطّ داعم مثل IPAmj Mincho وتطبيقاً داعماً كلاهما حاضرين. في بيئة غير داعمة السلوك المحدَّد أن يُتجاهَل المحدِّد ويُعرض شكل حرف الأساس الافتراضيّ؛ وفي بعض البيئات قد يظهر المحدِّد أيضاً □. كذلك، حرف حامل IVS يمكن أن يبلغ أربع وحدات رمز في UTF-16، وهذا يؤثّر في عدّ الأحرف والقصّ وتصميم أطوال أعمدة قاعدة البيانات. إن أدخلته، أكِّد نطاق الدعم عبر العرض والطباعة والأنظمة اللاحقة قبل الاستخدام.
- هل يستطيع حرف مسجَّل كـ gaiji (EUDC) أن يظهر على حاسوب آخر أو في PDF؟
- من حيث المبدأ لا. gaiji آليّة يسجِّل فيها مستخدم شكلاً في ملفّ eudc.tte لذلك الحاسوب عند نقطة رمز في منطقة الاستخدام الخاصّ لـ Unicode (من U+E000 فصاعداً)؛ نقطة الرمز نفسها غير معرَّفة أو شكل مختلف على حاسوب آخر. مصير تمريره إلى بريد أو PDF أو نظام آخر إذن أن يصبح □ أو يبدو حرفاً مختلفاً. إن ورثت أصلاً بيانات فيها gaiji، المسار الواقعيّ عند الترحيل جرد استخدامات منطقة الاستخدام الخاصّ، وبناء جدول توافق إلى أحرف Unicode عاديّة أو محدِّدات تنويع أيديوغرافيّ، والاستبدال. ينبغي تجنّب إنشاء gaiji جديدة في نظام جديد.
- إلى أيّ مدى ينبغي لنظام أعمال أن يقبل أحرفاً في أسماء الأشخاص؟
- أوّل شيء «قرّر مجموعة الأحرف المقبولة واذكرها كمواصفة». سجلات الأسرة نحو 56,000 حرف موحَّد كوسيكي، والأنظمة المطابقة للمعيار الحكوميّ تتّجه إلى استخدام الأحرف القياسيّة للشؤون الإداريّة، امتداداً لمنصّة معلومات الأحرف ── لكنّ نظام أعمال عامّاً ليس ملزَماً بقبول المستوى نفسه بلا حدّ. تصميم واقعيّ أن تقرّر نطاقاً مثل «حتّى نطاق JIS X 0213» أو «لا نقبل محدِّدات التنويع الأيديوغرافيّ ولا منطقة الاستخدام الخاصّ»، وتتحقّق عند الإدخال، وتعالج الحالات خارج النطاق بتنبيه أو تمثيل بديل. الأنظمة التي تتبادل مع أنظمة حكوميّة أو بلديّات وحدها تحتاج إلى متابعة حركة الأحرف القياسيّة للشؤون الإداريّة ومتطلّبات التبادل القائمة على JIS X 0221.
- كيف نجعل نموذجاً أو PDF يعرض الأحرف نفسها التي على الشاشة؟
- الأساس تحديد الخطّ نفسه على الشاشة وعلى النموذج، وتضمين الخطّ في PDF. إن اختلفت الخطوط، يمكن أن تغيّر البيانات نفسها شكلها؛ إن لم يكن لحاسوب المشاهدة الخطّ، يُستخدم خطّ بديل للرسم وينكسر المظهر. جواز التضمين تحدّده رخصة الخطّ (OpenType fsType)، فأكِّدها بدل ترك الأمر لمكتبة التقارير. التضمين الجزئيّ، الذي يضمِّن الأحرف المستخدمة فقط، يُبقي أيضاً حجم الملفّ منخفضاً. إن كان الاحتفاظ طويل الأمد متطلَّباً، انظر PDF/A الذي يتطلّب تضمين الخطّ.
الملف الشخصي للمؤلف
صفحة الملف الشخصي لمؤلف المقالة.
غو كومورا
مؤسّس شركة كومورا سوفت ذ.م.م.
يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.