ASN.1

تُقدّم توصيات ASN.1 عددًا من قواعد التشفير المُعرّفة مسبقًا. إذا لم تكن أيٌّ من قواعد التشفير الموجودة مناسبة، فإنّ تدوين التحكم في التشفير (ECN، X.692) يُتيح للمستخدم تعريف قواعد التشفير المُخصّصة الخاصة به.

إن ترميز البريد المحسن للخصوصية (PEM) لا علاقة له إطلاقاً بـ ASN.1 وبرامج الترميز الخاصة به، ولكن بيانات ASN.1 المشفرة، والتي غالباً ما تكون ثنائية، غالباً ما يتم ترميزها باستخدام PEM بحيث يمكن إرسالها كبيانات نصية، على سبيل المثال عبر خوادم SMTP، أو من خلال مخازن النسخ/اللصق.

هذا مثال على وحدة ASN.1 التي تحدد الرسائل (هياكل البيانات) لبروتوكول Foo وهمي :

تعريفات بروتوكول Foo ::= ابدأFooQuestion ::= SEQUENCE { trackingNumber INTEGER , question IA5String }FooAnswer ::= SEQUENCE { questionNumber INTEGER , answer BOOLEAN }نهاية

قد يكون هذا وصفًا منشورًا من قِبل مُنشئي بروتوكول Foo. لم تُحدد تدفقات المحادثة، وتبادل المعاملات، والحالات في ASN.1، بل تُركت لرموز أخرى ووصف نصي للبروتوكول.

يدعم معيار ASN.1 القيود المفروضة على القيم والأحجام، بالإضافة إلى إمكانية التوسع. يمكن تغيير المواصفات المذكورة أعلاه إلى:

تعريفات بروتوكول Foo ::= ابدأFooQuestion ::= SEQUENCE { trackingNumber INTEGER ( 0. . 199 ), question IA5String }FooAnswer ::= SEQUENCE { questionNumber INTEGER ( 10. . 20 ), answer BOOLEAN }FooHistory ::= SEQUENCE { questions SEQUENCE ( SIZE ( 0. . 10 )) OF FooQuestion , answers SEQUENCE ( SIZE ( 1. . 10 )) OF FooAnswer , anArray SEQUENCE ( SIZE ( 100 )) OF INTEGER ( 0. . 1000 ), ... }نهاية

يُقيد هذا التغيير قيمة trackingNumbers لتكون بين 0 و199 شاملةً، وقيمة questionNumbers لتكون بين 10 و20 شاملةً. يمكن أن يتراوح حجم مصفوفة الأسئلة بين 0 و10 عناصر، بينما يتراوح حجم مصفوفة الإجابات بين 1 و10 عناصر. حقل anArray عبارة عن مصفوفة ثابتة الطول مكونة من 100 عنصر من الأعداد الصحيحة، ويجب أن تكون ضمن النطاق من 0 إلى 1000. تشير علامة التوسعة '...' إلى أن مواصفات رسالة FooHistory قد تحتوي على حقول إضافية في الإصدارات المستقبلية؛ يجب أن تكون الأنظمة المتوافقة مع إصدار معين قادرة على استقبال وإرسال المعاملات من إصدار لاحق، مع قدرتها على معالجة الحقول المحددة في الإصدار السابق فقط. ستُنشئ مُجمِّعات ASN.1 الجيدة (بلغات C، C++، Java، إلخ) شفرة مصدرية تتحقق تلقائيًا من أن المعاملات تقع ضمن هذه القيود. لا ينبغي قبول المعاملات التي تُخالف هذه القيود من التطبيق أو عرضها عليه. إن إدارة القيود في هذه الطبقة تبسط بشكل كبير مواصفات البروتوكول لأن التطبيقات ستكون محمية من انتهاكات القيود، مما يقلل من المخاطر والتكاليف.

تستخدم الأمثلة المذكورة أعلاه فقط الصيغة من X.680. أما القيود الأكثر تقدماً من X.682 فلا يتم استخدامها.

بافتراض وجود رسالة تتوافق مع بروتوكول Foo وسيتم إرسالها إلى الطرف المتلقي، فإن هذه الرسالة المحددة ( وحدة بيانات البروتوكول (PDU)) هي:

myQuestion FooQuestion ::= { trackingNumber 5 , question "هل من أحد هناك؟" }

لإرسال رسالة myQuestion عبر الشبكة، تُحوّل الرسالة إلى سلسلة من البايتات باستخدام إحدى قواعد التشفير . يجب أن يحدد بروتوكول Foo صراحةً مجموعة واحدة من قواعد التشفير المستخدمة، لكي يعرف مستخدمو بروتوكول Foo أي قاعدة يجب عليهم استخدامها وتوقعها.

ما سبق هو مثال على X.681، وتحديداً على بنية ObjectAssignment .

فيما يلي بنية البيانات الموضحة أعلاه بصيغة myQuestion المشفرة بتنسيق DER (جميع الأرقام بالنظام الست عشري):

30 13 02 01 05 16 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

يُعد DER ترميزًا من نوع-طول-قيمة ، لذا يمكن تفسير التسلسل أعلاه، بالرجوع إلى أنواع SEQUENCE وINTEGER وIA5String القياسية، على النحو التالي:

30 — نوع الوسم الذي يشير إلى التسلسل 13 — طول القيمة التي تلي ذلك بالوحدات الثمانية 02 — نوع الوسم الذي يشير إلى عدد صحيح 01 — طول القيمة التي تلي ذلك بالوحدات الثمانية 05 — القيمة (5) 16 — علامة النوع التي تشير إلى IA5String (تعني IA5 مجموعة ISO 646 الكاملة ذات 7 بت، بما في ذلك المتغيرات، لكنها عمومًا من نوع US-ASCII) 0e — طول القيمة التي تلي ذلك بالوحدات الثمانية 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f — قيمة ("هل من أحد هناك؟")

بدلاً من ذلك، يمكن ترميز بنية بيانات ASN.1 نفسها باستخدام قواعد ترميز XML (XER) لتحقيق سهولة قراءة أكبر من قِبل المستخدم أثناء نقل البيانات عبر الشبكة. ستظهر حينها على شكل 108 بايتات التالية (يشمل عدد المسافات المسافات المستخدمة للمسافة البادئة):

<FooQuestion> <trackingNumber> 5 </trackingNumber> <question> هل يوجد أحد هنا؟ </question> </FooQuestion>

بدلاً من ذلك، إذا تم استخدام قواعد التشفير المعبأة غير المحاذية، فسيتم إنتاج الـ 122 بت التالية (16 بايت تساوي 128 بت، ولكن هنا 122 بت فقط تحمل المعلومات والـ 6 بتات الأخيرة هي مجرد حشو):

01 05 0e 83 ب سي 2d f9 3c a0 e9 a3 2f 2c af c0

في هذا التنسيق، لا تُشفّر علامات النوع للعناصر المطلوبة، لذا لا يمكن تحليله دون معرفة المخططات المتوقعة المستخدمة في التشفير. بالإضافة إلى ذلك، تُعبأ بايتات قيمة IA5String باستخدام وحدات 7 بت بدلاً من 8 بت، لأن المُشفّر يعلم أن تشفير قيمة بايت IA5String يتطلب 7 بتات فقط. مع ذلك، لا تزال بايتات الطول مُشفّرة هنا، حتى بالنسبة لعلامة العدد الصحيح الأولى 01 (لكن يمكن لمُعبّئ PER حذفها إذا كان يعلم أن نطاق القيم المسموح به يتناسب مع 8 بتات، ويمكنه حتى ضغط بايت القيمة المفردة 05 بأقل من 8 بتات، إذا كان يعلم أن القيم المسموح بها لا تتناسب إلا مع نطاق أصغر).

يتم حشو آخر 6 بتات في PER المشفر ببتات فارغة في أقل 6 بتات أهمية من البايت الأخير c0  : قد لا يتم إرسال هذه البتات الإضافية أو استخدامها لتشفير شيء آخر إذا تم إدخال هذا التسلسل كجزء من تسلسل PER غير محاذي أطول.

هذا يعني أن بيانات PER غير المحاذية هي في الأساس سلسلة مرتبة من البتات، وليست سلسلة مرتبة من البايتات كما هو الحال مع بيانات PER المحاذية، وأن فك تشفيرها بواسطة البرامج على المعالجات التقليدية سيكون أكثر تعقيدًا بعض الشيء، لأنه سيتطلب إزاحة بتات سياقية إضافية وإخفاءً، وليس عنونة مباشرة للبايتات (لكن الملاحظة نفسها تنطبق على المعالجات الحديثة ووحدات الذاكرة/التخزين التي يزيد الحد الأدنى لوحدة العنونة فيها عن ثمانية بتات). مع ذلك، تتضمن المعالجات الحديثة ومعالجات الإشارات دعمًا ماديًا لفك التشفير الداخلي السريع لسلاسل البتات مع معالجة تلقائية لوحدات الحوسبة التي تتجاوز حدود وحدات التخزين القابلة للعنونة (وهذا ضروري للمعالجة الفعالة في برامج ترميز البيانات للضغط/فك الضغط أو مع بعض خوارزميات التشفير/فك التشفير).

للمقارنة، ينتج برنامج Packed Encoding Rules Aligned بدلاً من ذلك ما يلي:

01 05 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

هذا التنسيق مُحاذي للثمانيات. في هذه الحالة، يتم ملء كل ثماني بشكل فردي ببتات فارغة على البتات الأكثر أهمية غير المستخدمة.

• تشغيل ASN1
• أداة ASN1 على الويب (محدودة للغاية)
• ملعب ASN1 (صندوق الرمل)
• مُفكِّك شفرة جافا سكريبت ASN.1

تستطيع بعض أدوات ASN.1 الترجمة بين ASN.1 ومخطط XML (XSD). وتُوحّد هذه الترجمة من قِبل الاتحاد الدولي للاتصالات (ITU). وهذا يُتيح تعريف البروتوكول باستخدام ASN.1، وكذلك تلقائيًا باستخدام XSD. وبالتالي، يُمكن (وإن كان غير مُستحسن) تضمين مخطط XSD في مشروع ما، حيث تُجمّع أدوات ASN.1 هذا المخطط لإنتاج شفرة مصدرية تُحوّل الكائنات من وإلى تنسيق JSON. أما الاستخدام الأكثر عمليةً فهو السماح للمشاريع الفرعية الأخرى باستخدام مخطط XSD بدلًا من مخطط ASN.1، بما يتناسب مع توافر الأدوات للغة المُختارة في المشروع الفرعي، مع استخدام XER كتنسيق للبروتوكول.

توفر مكتبة نوكالفا مفتوحة المصدر أداةً لتحويل كائن بيانات JSON أو مخطط JSON إلى تعريف ASN.1. ^{[ 23 ]} ولا توجد حتى الآن أداة لإنشاء مخطط JSON يصف بنية بيانات ASN.1 المشفرة بصيغة JER.

كما يوفر برنامج نوكالفا مفتوح المصدر أداة لتحويل مخطط بروتوكول بافرز إلى تعريف ASN.1. ^{[ 24 ]}

تُعرّف العديد من لغات البرمجة صيغ تسلسل خاصة بها. على سبيل المثال، وحدة "pickle" في بايثون ووحدة "Marshal" في روبي. لا تتطلب هذه الصيغ مخططًا. وهي عادةً خاصة بكل لغة، مما يُسهّل استخدامها في سيناريوهات التخزين المخصصة، لكنها غير مناسبة لبروتوكولات الاتصالات.

لا يتطلب كل من JSON و XML مخططًا، مما يجعلهما سهلي الاستخدام. كما أنهما معياران متعددا المنصات يحظيان بشعبية واسعة في بروتوكولات الاتصالات، لا سيما عند دمجهما مع مخطط JSON أو مخطط XML .

يُشابه ASN.1 ظاهريًا صيغة باكوس-ناور المُعززة (ABNF)، المُستخدمة لتعريف العديد من بروتوكولات الإنترنت مثل HTTP و SMTP . مع ذلك، يختلفان عمليًا اختلافًا كبيرًا: يُعرّف ASN.1 بنية بيانات يُمكن ترميزها بطرق مُتعددة (مثل JSON وXML والثنائي). بينما تُعرّف ABNF الترميز ("البنية النحوية") في الوقت نفسه الذي تُعرّف فيه بنية البيانات ("الدلالات"). يُستخدم ABNF غالبًا لتعريف البروتوكولات النصية سهلة القراءة، ولا يُستخدم عادةً لتعريف ترميزات النوع-الطول-القيمة.

يتشابه ASN.1 بصريًا مع CSN.1 . ومع ذلك، يحدد CSN.1 أيضًا ترميز الكائن، وتحديدًا على مستوى البت.