مطبات الخطوط والأحرف اليابانية ── معالجة JIS2004 وIVS وgaiji في تطبيقات الأعمال

«الاسم نفسه، لكن شكل الحرف يختلف بين الشاشة والنموذج المطبوع.» «بعد أن استبدلنا الحاسوب، صار حرف كان يُعرض □.» أنظمة الأعمال التي تعالج اليابانية تجذب استشارات كهذه.

أول ما يُؤكَّد هو ما إذا تغيّرت بيانات الحرف، أم تغيّر مظهر البيانات نفسها فقط. إن حاولت الإصلاح كـ «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، إلى نطاق الأحرف المقبولة وتصميم النماذج المطبوعة وPDF.

التشويه الذي يحدث في التحويل بين Shift_JIS وUTF-8 مشمول في مقالات قائمة، لذا تركّز هذه المقالة على المشكلة حيث تدور الرموز ذهاباً وإياباً بشكل صحيح لكن المظهر، أو ما إذا كان الحرف قابلاً للعرض أصلاً، منحرف.

1. الخلاصة أولاً

«أي تسلسل بايتات تُخزَّن» سؤال تصميم بيانات؛ «كيف يبدو» سؤال تصميم خطوط. عندما تقرر كيف تستجيب، افصل الأمور الثلاثة التالية.

أولاً، أكّد ما إذا كانت البيانات هي نفسها

«Mojibake» مشكلة طبقة بيانات: تسلسل بايتات يُفسَّر خطأ. بالمقابل، نقطة رمز Unicode نفسها يمكن أن يكون لها شكل مختلف في خط مختلف. غيّرت JIS2004 الأشكال النموذجية لـ 168 حرفاً، منها 葛 و辻 و飴، ومن Vista فصاعداً أشكال JIS2004 هي الافتراضي في MS Gothic وMS Mincho في Windows.¹²

لا تخلط تحديد شكل بحمل gaiji

IVS هو الوسيلة القياسية لتحديد شكل كبيانات. غير أنه يحتاج خطاً داعماً وتطبيقاً داعماً، وفي بيئة بلا ذلك السلوك الصحيح تجاهل المحدّد وعرض شكل حرف الأساس الافتراضي. ولأن ما يبدو حرفاً واحداً يمكن أن يبلغ أربع وحدات رمز UTF-16، يؤثر لا في العرض فحسب بل أيضاً في عدّ الأحرف واستخراج السلاسل الفرعية.³⁴

gaiji (EUDC، أحرف يعرّفها المستخدم النهائي) أمر منفصل: رقم منطقة استخدام خاص ليس له معنى مشترك عبر العالم. الشكل في eudc.tte لا ينتقل إلى الطرف الآخر مع البيانات، لذا يحتاج الترحيل مسحاً وتوافقاً إلى أحرف بديلة.⁵⁶

اكتب الأحرف المقبولة وبيئة الإخراج في المواصفة

نظام يعالج أسماء أشخاص يقرر مجموعة الأحرف التي يقبلها ويذكرها صراحة. حيث يتبادل النظام بيانات مع الحكومة، تابع أيضاً الأحرف القياسية للشؤون الإدارية، التي تُبنى على أحرف كوسيكي الموحَّدة ومنصة معلومات الأحرف.⁷⁸⁹ للنماذج المطبوعة وPDF، الخط الأساس استخدام الخط نفسه كالشاشة، وتأكيد الرخصة، وتضمين الخط. للاحتفاظ طويل الأمد، فكّر في PDF/A.¹⁰¹¹

كذلك، لا تطبّق تطبيع NFKC ببساطة على أصل اسم شخص. استبدال أشكال العرض الكامل والنصف وأحرف التوافق يفقد تمييزات ينبغي إبقاؤها.¹²

اختر أين تقرأ من عَرَضك أو هدفك

لفهم الصورة كلها، اقرأ من الفصل 2 بالترتيب؛ للتحقيق في العَرَض أمامك، ابدأ من القسم ذي الصلة في الجدول. عندما تنفّذ إجراء مضاداً، افحص أثره على الطبقات الأخرى في الفصل 9 في النهاية.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 14، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. فكّر في البيانات والمظهر منفصلين ── نقاط الرمز والأشكال

العدد والشكل المرسوم شيئان مختلفان

في يونيكود، يُمثَّل الحرف بعدد يُدعى نقطة رمز. 葛 هو U+845B، وهذا العدد نفسه على كل حاسوب.

أما كيف يُرسَم ذلك العدد على شاشة أو على ورق، فيقرره الشكل الذي يحمله الخط. من الطبيعي أن يختلف U+845B نفسه في تفاصيل شكله بين الخط أ والخط ب.

افصل الطبقة التي تُحقَّق حسب العَرَض

بهاتين الطبقتين مقدّمة، يمكن تقسيم الأعراض التي تلاقيها في الميدان كما يلي.

كدليل للتقسيم، يفيد تذكّر الفرق بين «�» و«□».

«�» أثر تحويل فاشل. متى استُبدل بـ 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 - أساسيات mojibake و CRLF/LF». من هنا فصاعداً الموضوع طبقة المظهر والمشكلات التي تقع عند حدودها.

3. من JIS90 إلى JIS2004 ── تغيّر الشكل وبقي الرمز نفسه

السبب الحقيقي وراء «葛 يبدو مختلفاً على الشاشة وعلى النموذج» في الافتتاح، في معظم الحالات، يوجد هنا.

ما تغيّر: الأشكال الافتراضية للخط

اتباعاً لـ Hyogai Kanji Jitaihyo (جدول أشكال الكانجي خارج قائمة الجويو) الذي أبلغه مجلس اللغة الوطني سنة 2000، غيّرت مراجعة 2004 ‏JIS X 0213:2004 (الشائعة JIS2004) الأشكال النموذجية لـ 168 كانجي إلى أشكال معيار الطباعة، القريبة مما يُدعى أشكال قاموس كانغشي. 葛 و辻 و飴 و芦 و溢 و餅 أمثلة نموذجية.¹

واكب Windows هذا وجعل أشكال JIS2004 الافتراضي في MS Gothic وMS Mincho (وMeiryo المُدخل حديثاً) من Windows Vista فصاعداً. ولـ MS Gothic الحالي أيضاً أشكال افتراضية قائمة على JIS2004، مع أشكال عصر JIS90 قابلة للبلوغ عبر ميزة OpenType jp90.²¹

flowchart TB
    accTitle: كيف تُنظَّم أشكال MS Gothic الحالي
    accDescr: لـ MS Gothic من Vista فصاعداً أشكال 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).³

توافق الأشكال يقرره تسجيل IVD

أي تسلسل «حرف أساس + محدّد» يشير إلى أي شكل يقرره سجل يُدعى IVD (Ideographic Variation Database)، تديره Unicode Consortium.

المجموعات الرئيسة كما يلي.¹³

على سبيل المثال، تعطي وثائق Microsoft ‏U+845B وحده (葛) كشكل مستخدم في اسم محطة Nishi-Kasai، وU+845B متبوعاً بـ U+E0100 (VS17) كشكل مستخدم في اسم مدينة Katsuragi في محافظة نارا. 葛 نفسه، غير أن البيانات تستطيع قول أي شكل مقصود.³

flowchart TB
    accTitle: مثال تمييز 葛 نفسه كبيانات بـ IVS
    accDescr: 葛 كـ U+845B وحده يُستخدم في اسم محطة Nishi-Kasai، وتسلسل U+845B متبوعاً بـ VS17 يُستخدم في اسم مدينة Katsuragi، وأي تسلسل يشير إلى أي شكل يقرره سجل IVD
    seq1["U+845B وحده"] --> gl1["الشكل المستخدم في اسم محطة Nishi-Kasai"]
    seq2["U+845B + VS17"] --> gl2["الشكل المستخدم في اسم مدينة Katsuragi"]
    ivd["IVD (السجل)"] -.-> gl1
    ivd -.-> gl2

الشكل 5: حتى لـ 葛 نفسه، وجود المحدّد أو غيابه يتيح للبيانات قول أي شكل مقصود.

4.1. السلوك في بيئة لا تدعمه

من جانب الخط، يُنفَّذ التوافق بين IVS وشكل في جدول cmap لـ OpenType (format 14).⁴ عندما يكون خط داعم (مثل IPAmj Mincho) وتطبيقاً داعماً كلاهما حاضرين، يظهر الشكل المحدد.

عندما لا يكونان كذلك، الشكل المحدد غير مضمون البقاء. افصل الحالتين التاليتين.

• السلوك الصحيح حسب المواصفة: يُتجاهَل المحدّد ويُعرض شكل حرف الأساس الافتراضي (المحدّد نفسه غير مرئي)
• تطبيقات قديمة وبعض طبقات الرسم: يُعامَل المحدّد حرفاً مجهولاً مستقلاً، ويُعرض □ إضافي

بعبارة أخرى، IVS مصمَّم بحيث «حتى عندما يتدهور، يبقى حرف الأساس مقروءاً»، لكن ما إذا كان «يُعرض دائماً بالشكل المحدد» يعتمد على بيئة المستقبِل.

أنظمة سجلات السكان وسجلات الأسرة الحكومية تستخدم توليفة خط منصة معلومات الأحرف زائد IVS، لكن إن قبله نظام أعمال عام ببساطة، يسقط الشكل في مكان ما على مسار العرض أو الطباعة أو نظام لاحق.

flowchart TB
    accTitle: كيف تُعرض بيانات حاملة لـ IVS
    accDescr: عندما يكون خط داعم وتطبيقاً داعماً كلاهما حاضرين يُعرض بالشكل المحدد، وعندما لا يكونان يُتجاهَل المحدّد ويُعرض شكل حرف الأساس الافتراضي، وفي تطبيقات قديمة وبعض طبقات الرسم يُعامَل المحدّد حرفاً مجهولاً ويُعرض □ إضافي
    ivs["حرف أساس + محدّد تنويع أيديوغرافي"] --> env{"خط داعم وتطبيقاً داعماً كلاهما حاضر؟"}
    env -->|نعم| ok["يُعرض بالشكل المحدد"]
    env -->|لا| ignore["يُتجاهَل المحدّد؛ يُعرض الشكل الافتراضي"]
    env -->|تطبيقات قديمة أو بعض طبقات الرسم| tofu["يُعرض □ إضافي"]
    ignore -.-> spec["هذا السلوك الصحيح حسب المواصفة"]

الشكل 6: يبقى IVS مقروءاً كحرف الأساس حتى عندما يتدهور، لكن ما إذا ظهر الشكل المحدد يعتمد على بيئة المستقبِل.

4.2. محاذير التنفيذ ── «حرف واحد» يمكن أن يبلغ أربع وحدات رمز

محدّدات IVS من U+E0100 فصاعداً نقاط رمز في المستوى الإضافي، لذا في UTF-16 هي دائماً زوج بديل (وحدتا رمز). إن كان حرف الأساس نفسه كانجي مستوى إضافياً (مثلاً 𠮟 (U+20B9F)، المضاف في JIS2004)، فالأساس وحده وحدتا رمز، والتسلسل الذي يدركه المستخدم «حرفاً واحداً» يبلغ أربع وحدات رمز في UTF-16 وثمانية بايتات في UTF-8.

عدّ الأحرف والسلاسل الفرعية: لا تقسم الحرف الظاهر

في C#، "葛󠄀" (葛 + VS17) له 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["وحدتا رمز إن كان كانجي مستوى إضافياً"]
    vs -.-> vnote["دائماً زوج بديل (وحدتا رمز)"]
    base --> total["حتى أربع وحدات رمز في UTF-16"]
    vs --> total
    total -.-> risk["القص بطول ثابت يخاطر بفصلهما"]

الشكل 7: حرف واحد حامل IVS يمكن أن يبلغ أربع وحدات رمز UTF-16، لذا القص بوحدة الرمز خطر.

5. Gaiji (EUDC) ── أحرف تظهر فقط على ذلك الحاسوب

Gaiji آلية يخصّص بها مستخدم شكلاً من صنعه لنقطة رمز في منطقة الاستخدام الخاص ليونيكود (PUA: U+E000 حتى U+F8FF ونطاقات أخرى). نقطة رمز منطقة استخدام خاص ليس لها معنى مشترك عبر العالم؛ يمكن تعيين الحرف نفسه U+E000 حرفاً مختلفاً على كل حاسوب وفي كل منظمة.⁵

الشكل يعيش في خط gaiji؛ الرقم وحده يبقى في البيانات

على Windows، تنشئ الشكل في محرر الأحرف الخاصة (eudcedit.exe)، ويُحفَظ في ملف خط يُدعى eudc.tte.

يُثبَّت هذا الملف خطاً مخفياً ويُربَط بكل خط عبر مفتاح السجل HKEY_CURRENT_USER\EUDC.⁶ في عصر Shift_JIS (CP932) كان نطاق gaiji من 0xF040 حتى 0xF9FC، والتحويل إلى يونيكود يقابله بمنطقة الاستخدام الخاص.

رقم في البيانات لا يعني أن الطرف الآخر يحمل الشكل نفسه. هذه الآلية تنتج المشكلات التالية.

• eudc.tte ملك ذلك الحاسوب (ذلك المستخدم) ولا ينتقل إلى الطرف الآخر مع البيانات
• في اللحظة التي تبلغ فيها البيانات بريداً أو PDF أو الويب أو نظاماً آخر، يصير الحرف □ أو يبدو gaiji مختلفاً على الجانب الآخر
• إن نسيت نقل eudc.tte أثناء ترحيل نظام تشغيل أو استبدال حاسوب، يحدث «حرف كان يُعرض على الحاسوب القديم لم يعد يُعرض»

هذا السبب الحقيقي وراء الاستشارة الثانية في الافتتاح.

flowchart TB
    accTitle: لماذا تظهر gaiji فقط على ذلك الحاسوب
    accDescr: شكل يُنشأ في محرر الأحرف الخاصة يُحفَظ في eudc.tte ويُربَط بالخطوط عبر سجل ذلك الحاسوب، لذا عندما ينتقل رمز منطقة الاستخدام الخاص وحده إلى بريد أو PDF أو نظام آخر، يصير □ أو يبدو حرفاً مختلفاً
    edit["أنشئ شكلاً في محرر الأحرف الخاصة"] --> tte["احفظ في eudc.tte"]
    tte --> reg["اربط بالخطوط عبر السجل"]
    reg --> local["يمكن العرض على ذلك الحاسوب"]
    tte -.-> stay["eudc.tte لا ينتقل مع البيانات"]
    send["رمز منطقة الاستخدام الخاص وحده يصل إلى الطرف الآخر"] --> dest["بريد وPDF ونظام آخر"]
    dest --> broken["يصير □ أو يبدو حرفاً مختلفاً"]

الشكل 8: الشكل في eudc.tte، والبيانات تحمل رقم منطقة الاستخدام الخاص فقط، لذا تبدو gaiji مكسورة متى خرجت من الحاسوب.

5.1. الحل الواقعي لنظام ورث gaiji

المشكلة عندما تكون gaiji مخلوطة أصلاً في بيانات وُرثت من نظام قديم. ما نوصي به في قضايا الترحيل مسح ← مطابقة ← استبدال ← قطع على أربع مراحل.

1. المسح: اجمع الأرقام المستخدمة والأشكال الأصلية

امسح قواعد البيانات والملفات بتعبير منتظم لمنطقة الاستخدام الخاص (U+E000 حتى U+F8FF)، واجرد رموز gaiji المستخدمة وعددها. استعد eudc.tte من حواسيب كل موقع وأكّد الأشكال.

2. المطابقة: اصنع جدول أحرف بديلة

لكل gaiji، افحص «هل يمكن تمثيله بحرف Unicode عادي» و«هل يمكن تمثيله بـ IVS» و«هل يوجد حرف مقابل في منصة معلومات الأحرف (MJ)»، واصنع جدول أحرف بديلة. في الواقع، معظم الحالات مجرد أشكال قديمة صُنعت كـ gaiji خارج JIS.

3. الاستبدال: استبدل البيانات وفق الجدول

استبدل البيانات وفق الجدول. فقط عندما لا يوجد حرف مقابل البتة، احتفظ بصورة أو ضع ملاحظة على ذلك السجل.

4. القطع: لا تزد gaiji جديدة

في النظام الجديد، ارفض إدخال منطقة الاستخدام الخاص بالتحقق، ولا تنشئ gaiji جديدة.

flowchart TB
    accTitle: إجراء ترحيل بيانات تحتوي gaiji
    accDescr: امسح منطقة الاستخدام الخاص واستعد eudc.tte لجرد gaiji المستخدمة، واصنع جدول أحرف بديلة واستبدل، وفي النظام الجديد ارفض إدخال منطقة الاستخدام الخاص بالتحقق ولا تنشئ gaiji جديدة
    st1["مسح: امسح منطقة الاستخدام الخاص"] --> st2["مطابقة: اصنع جدول أحرف بديلة"]
    st2 --> st3["استبدال: استبدل وفق الجدول"]
    st3 --> st4["قطع: لا تنشئ gaiji جديدة"]
    st1 -.-> tte["استعد eudc.tte من كل موقع"]
    st2 -.-> nomap["صورة أو ملاحظة فقط إن لم يوجد مقابل"]

الشكل 9: ترحيل gaiji يسير في أربع مراحل: مسح ومطابقة واستبدال وقطع، ولا تُنشأ gaiji جديدة.

على الجانب الحكومي الاتجاه نفسه، وقد بيّنت سياسة مطابقة gaiji التي صنعتها البلديات بنفسها (يُقال إنها نحو مليوني حرف على مستوى البلاد) فريداً إلى الأحرف القياسية للشؤون الإدارية المذكورة لاحقاً والتوقف عن استخدامها.⁹ «لا تزد gaiji، وطابقها إلى مجموعة أحرف موحَّدة» يصير القاعدة في الترحيل، حكومياً كان أم أهلياً.

6. المنصة الحكومية للأحرف ── من أحرف كوسيكي الموحَّدة إلى الأحرف القياسية للشؤون الإدارية

في تصميم نظام يعالج أسماء أشخاص، معرفة منصة الأحرف على الجانب الحكومي تصير مادة حكم لـ «إلى أي مدى نقبل».

أولاً، افصل أسماء المنصات وأدوارها

افصل التكامل داخل الإدارة عن التكامل مع بيئة خارجية عامة

في أنظمة الأعمال الأساسية للبلديات (الأنظمة المطابقة للمعيار)، صار استخدام الأحرف القياسية للشؤون الإدارية لتكامل معلومات أسماء الأشخاص وما شابه، والتكامل مع أنظمة خارجية بلا قواعد تكامل موحَّدة كالهواتف الذكية ضمن نطاق JIS X 0213:2012 بنياناً من درجتين في المواصفة القياسية.⁹

«احتفظ داخلياً بمجموعة أحرف واسعة، وتبادل مع الخارج ضمن نطاق يمكن عرضه في بيئة عامة» — هذا البناء نفسه مرجع لأنظمة أهلية أيضاً.

flowchart TB
    accTitle: تكامل النظام المطابق للمعيار على درجتين
    accDescr: يستخدم النظام المطابق للمعيار في البلدية الأحرف القياسية للشؤون الإدارية لتكامل معلومات أسماء الأشخاص وما شابه، ويتكامل مع أنظمة خارجية بلا قواعد موحَّدة كالهواتف الذكية ضمن نطاق JIS X 0213:2012
    sys["النظام المطابق للمعيار في البلدية"] --> renkei["تكامل معلومات أسماء الأشخاص وما شابه"]
    sys --> gaibu["التكامل مع أنظمة خارجية"]
    renkei --> mjp["الأحرف القياسية للشؤون الإدارية"]
    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. اختيار الخطوط والتضمين ── حاذِ الشاشة والنموذج

هنا فكّر بالترتيب أكّد أن الخط موجود في البيئة المستخدمة ← حاذِ الشاشة والنموذج ← أكّد الإذن وضمّن في PDF.

7.1. طبع الخطوط الشائعة

أكّد البيئة المستخدمة، لا اسم الخط فقط

ما يهم في الاختيار أكثر من ذوق الأسلوب هو «ما إذا كان ذلك الخط موجوداً في كل بيئة تتصل بالعرض والطباعة وتوليد PDF».

خطوط Windows 10/11 اليابانية المساعدة (BIZ UD وغيرها) قد لا تكون مثبَّتة حسب التكوين، وفي تكوين يولّد PDF من جانب الخادم يؤثر وجود الخط على الخادم مباشرة.

flowchart TB
    accTitle: البيئات التي ينبغي تأكيدها عند اختيار خط
    accDescr: في اختيار الخط ما يهم أكثر من ذوق الأسلوب هو ما إذا كان ذلك الخط موجوداً في كل بيئة تتصل بالعرض والطباعة وتوليد PDF، وتكوين الخطوط المساعدة ووجود الخط على الخادم يؤثران مباشرة
    cand["خط مرشح"] --> exist["هل يوجد في كل بيئة؟"]
    exist --> scr["بيئة العرض"]
    exist --> prn["بيئة الطباعة"]
    exist --> srv["خادم توليد PDF"]
    scr -.-> hojo["الخطوط المساعدة قد تغيب حسب التكوين"]
    srv -.-> eikyo["وجود الخط على الخادم يؤثر مباشرة"]

الشكل 12: اختر الخط بما إذا كان موجوداً في كل بيئة عرض وطباعة وتوليد PDF، لا بذوق الأسلوب.

7.2. أساس تصميم النماذج ── حاذِ وضمّن

حاذِ خط الشاشة وخط النموذج

حدّد الخط نفسه على الشاشة وعلى النموذج. إن اختلفت الخطوط، يمكن للبيانات نفسها أن تبدو بأشكال مختلفة، وتصير شكوى الافتتاح. تكوين مثل «الشاشة Meiryo والنموذج MS Mincho» ينبغي على الأقل تأكيد ما إذا كان هناك فرق شكل لـ 168 حرف JIS2004.

في PDF، أكّد الإذن وضمّن

ضمّن الخط في PDF. بلا تضمين، يرسم جانب العارض بخط محلي بديل، ويمكن أن يتغيّر لا الشكل فحسب بل التخطيط أيضاً.

جواز التضمين تقرره الرخصة. تعلن خطوط OpenType صلاحية التضمين في حقل fsType (Installable / Restricted / Preview & Print / Editable، وحظر الجزئي، وما شابه)، ولا تضمّن خطاً لم يُؤذَن تضمينه.¹⁰ الخطوط التجارية تتطلب تأكيد العقد.

اجعل التضمين الجزئي أساساً. إن ضمّنت أشكال الأحرف المستخدمة فقط، تتجنب حمل خط ياباني كامل (عدة ميغابايت إلى عشرات).

للاحتفاظ طويل الأمد فكّر في PDF/A

إن وُجد متطلب احتفاظ طويل الأمد، PDF/A. PDF/A (ISO 19005) مواصفة تُكمل موارد العرض داخل الملف، وتضمين الخط إلزامي.¹¹ وهو أيضاً أوثق طريقة لمنع «فتحته بعد عشر سنوات فتغيّر الشكل».

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 والمتصفحات «احتياط الخطوط».¹⁵

flowchart TB
    accTitle: تدفّق ربط الخطوط والاحتياط
    accDescr: إن وُجد شكل في الخط المحدد يُعرض كما هو، وإلا يُرسَم بخط ربط أو احتياط، وإن لم يوجد شكل في أي مكان يظهر □ لكن البيانات غالباً حيّة
    disp["اعرض حرفاً"] --> has{"هل يوجد شكل في الخط المحدد؟"}
    has -->|نعم| draw["اعرض بالخط المحدد"]
    has -->|لا| fb{"موجود في الربط أو الاحتياط؟"}
    fb -->|نعم| alt["ارسم بخط آخر بديلاً"]
    alt -.-> mixed["سبب اختلاط جوّ الأسلوب"]
    fb -->|لا| tofu["يُعرض □ (توفو)"]
    tofu -.-> alive["البيانات غالباً حيّة"]

الشكل 14: □ أثر فشل احتياط، ونجاح الرسم البديل أو فشله هو مفترق «اختلاط» و«توفو».

اقرأ نتيجة الرسم البديل من العَرَض

معرفة هذه الآلية تفسّر «المألوف» التالي.

• جوّ الأسلوب يختلف بين اللاتينية واليابانية: لأن خطاً لاتينياً وُضع أولاً، يُرسَم الجزء الياباني فقط بخط ياباني من الربط أو الاحتياط
• في جملة يابانية تصير الكانجي وحدها أشكالاً صينية الطابع: حُلّ الاحتياط إلى خط صيني. يحدث بسهولة في ويب أو تطبيق لا يمرّر معلومات اللغة (سمة lang أو الإعدادات المحلية) بشكل صحيح
• يظهر توفو (□): لا شكل في الخط المحدد ولا في الاحتياط. أي أن □ «أثر فشل» الاحتياط، والبيانات غالباً حيّة

الاحتياط ليس بديلاً عن التصميم

الاحتياط جهاز إنقاذ، وليس بديلاً عن اختيار الخط الصحيح من البداية.¹⁵

في تطبيقات الأعمال، الموقف السليم «المسارات الرئيسة للعرض والطباعة تكتمل بالخط المصمَّم وحده، والاحتياط تأمين لأحرف غير متوقعة». لفكرة اختيار الخط في واجهة متعددة اللغات انظر أيضاً «تعدد اللغات في تطبيقات WinForms/WPF».

9. قائمة تحقق تنفيذ تطبيقات الأعمال

أخيراً، نلخّص في جدول النقاط التي ينبغي تأكيدها في كل طبقة من الإدخال إلى التكامل. لا تتوقف عند ما إذا أمكن العرض على الشاشة؛ أكّد حتى الحفظ والطباعة والتكامل.

افصل حفظ الأصل عن معالجة البحث

التطبيع خصوصاً فخ موضوع هذه المقالة نفسه: معالجة «بحسن نية» تسحق تمييز الأشكال المتغيرة والعرض الكامل والنصف. المبدأ الأصل كما هو، والمعالجة على نسخة.

حوادث ترميز تكامل 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 - تشوّه النص عند التعامل مع Linux
• ترميز النص ونهاية السطر في Windows - أساسيات mojibake و CRLF/LF
• الطباعة وإخراج PDF في تطبيقات أعمال Windows ── التمييز بين System.Drawing.Printing وWPF ومكتبات التقارير
• تعدد اللغات في تطبيقات WinForms/WPF ── الممارسة العملية لملفات resx وتجميعات الأقمار الصناعية وتبديل الثقافة
• ملف CSV ليس «مجرد نص» ── الممارسة العملية لـ CSV في تطبيقات C# للأعمال (ترميز الأحرف وتوافق Excel والحماية من الحقن)
• أساسيات إمكان الوصول في تطبيقات Windows ── UI Automation والاستعداد لإلزام الترتيبات التيسيرية

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع تصميم وتحقيق ما حول الأحرف في أنظمة الأعمال. من فصل سبب أعراض مثل «الحرف مختلف على الشاشة وعلى النموذج» و«بعد الترحيل صارت الأسماء □»، عبر مسح gaiji عند الترحيل من نظام قديم وصنع جداول أحرف بديلة، وتصميم مجموعة الأحرف المقبولة لنظام يعالج أسماء أشخاص، إلى مراجعة تكوين تضمين الخط في النماذج وPDF، نستجيب من طبقتي الرمز والخطوط كلتيهما.

• تطوير تطبيقات Windows
• الاستفادة من الأصول القائمة ودعم الترحيل
• الاستشارة التقنية ومراجعة التصميم
• التواصل معنا

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

لماذا يبدو حرف 葛 نفسه مختلفاً حسب الحاسوب أو النموذج المطبوع؟

الأرجح أنه فرق في أشكال الخط لا 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 لذلك الحاسوب عند نقطة رمز في منطقة الاستخدام الخاص ليونيكود (من U+E000 فصاعداً)، لذا على حاسوب آخر نقطة الرمز نفسها غير معرَّفة أو شكل مختلف. مصير gaiji إذن أن يصير □ أو يبدو حرفاً مختلفاً متى بلغ بريداً أو PDF أو نظاماً آخر. إن كنت تحمل أصلاً بيانات فيها gaiji، المسار الواقعي عند الترحيل جرد كل استخدام لمنطقة الاستخدام الخاص، وبناء جدول توافق إلى أحرف Unicode عادية أو محدّدات تنويع أيديوغرافي، والاستبدال. ينبغي تجنّب إنشاء gaiji جديدة في نظام جديد.

إلى أي مدى ينبغي لنظام أعمال أن يقبل أحرف أسماء الأشخاص؟

الخطوة الأولى تقرير مجموعة الأحرف التي تقبلها وذكرها صراحة كمواصفة. سجلات الأسرة تحمل نحو 56 ألف حرف كوسيكي موحَّد، وأنظمة الحكومة المطابقة للمعيار تتجه نحو الأحرف القياسية للشؤون الإدارية، امتداداً لمنصة معلومات الأحرف، لكن نظام أعمال عام ليس ملزماً بقبول المستوى نفسه بلا حد. تصميم واقعي يقرر نطاقاً مثل «حتى نطاق JIS X 0213» أو «لا محدّدات تنويع أيديوغرافي ولا منطقة استخدام خاص»، يتحقق عند الإدخال، ويعالج الأحرف خارج النطاق بتنبيه أو تمثيل بديل. الأنظمة التي تتبادل بيانات مع أنظمة حكومية أو بلديات وحدها تحتاج متابعة تطورات الأحرف القياسية للشؤون الإدارية ومتطلبات التبادل القائمة على JIS X 0221.

كيف نجعل نموذجاً مطبوعاً أو PDF يعرض الأحرف نفسها التي على الشاشة؟

الأساس تحديد الخط نفسه على الشاشة وعلى النموذج، وتضمين الخط في PDF. إن اختلفت الخطوط، يمكن للبيانات نفسها أن تنتج أشكالاً مختلفة، وإن افتقد حاسوب العارض الخط، يُستخدم خط بديل للرسم وينكسر المظهر. جواز التضمين تقرره رخصة الخط (OpenType fsType)، لذا تحقّق بنفسك بدل تركه لمكتبة التقارير. التضمين الجزئي، الذي يضمّن الأحرف المستخدمة فقط، يُبقي حجم الملف أيضاً منخفضاً. إن كان الاحتفاظ طويل الأمد متطلباً، فكّر في PDF/A، حيث تضمين الخط إلزامي.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.