الترميز النسبي

ترميز URL ، المعروف رسميًا باسم ترميز النسبة المئوية ، هو طريقة لتشفير بيانات عشوائية في معرف مورد موحد (URI) باستخدام أحرف US-ASCII القانونية فقط داخل URI. على الرغم من أنه يُعرف باسم ترميز URL ، إلا أنه يستخدم أيضًا بشكل أكثر عمومية داخل مجموعة معرفات الموارد الموحدة (URI) الرئيسية، والتي تتضمن كلًا من محدد الموارد الموحد (URL) واسم المورد الموحد (URN). وبالتالي، يتم استخدامه أيضًا في إعداد بيانات application/x-www-form-urlencoded نوع الوسائط ، كما هو مستخدم غالبًا في إرسال بيانات نموذج HTML في طلبات HTTP .

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

RFC 3986 القسم 2.2 الأحرف المحجوزة (يناير 2005)

!

#

$

&

'

(

)

*

+

,

/

:

;

=

?

@

[

]

RFC 3986 القسم 2.3 الأحرف غير المحجوزة (يناير 2005)

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

P

Q

R

S

T

U

V

W

X

Y

Z

a

b

c

d

e

f

g

h

i

j

k

l

m

n

o

p

q

r

s

t

u

v

w

x

y

z

0

1

2

3

4

5

6

7

8

9

-

.

_

~

يجب ترميز الأحرف الأخرى في عنوان URI بنسبة مئوية.

عندما يكون لحرف من المجموعة المحجوزة ("حرف محجوز") معنى خاص ("غرض محجوز") في سياق معين، ويقول مخطط URI أنه من الضروري استخدام هذا الحرف لغرض آخر ، فيجب ترميز الحرف بنسبة مئوية . يتضمن ترميز الحرف المحجوز بنسبة مئوية تحويل الحرف إلى قيمة البايت المقابلة له في ASCII ثم تمثيل هذه القيمة كزوج من الأرقام السداسية عشرية (إذا كان هناك رقم سداسي عشري واحد، تتم إضافة صفر بادئ ). ثم يتم استخدام الأرقام، التي تسبقها علامة النسبة المئوية ( %) كحرف إفلات ، في URI بدلاً من الحرف المحجوز. (يتم تحويل الحرف غير ASCII عادةً إلى تسلسل البايت الخاص به في UTF-8 ، ثم يتم تمثيل كل قيمة بايت كما هو موضح أعلاه.)

على سبيل المثال، إذا تم استخدام الحرف المحجوز /في مكون "المسار" من URI ، فإن له معنى خاصًا يتمثل في كونه فاصلًا بين أجزاء المسار. إذا كان من الضروري، وفقًا لمخطط URI معين، /أن يكون في جزء مسار، فيجب استخدام الأحرف الثلاثة %2Fأو %2fفي الجزء بدلاً من /.

الأحرف المحجوزة بعد ترميز النسبة المئوية

!

#

$

&

'

(

)

*

+

,

/

:

;

=

?

@

[

]

%21

%23

%24

%26

%27

%28

%29

%2A

%2B

%2C

%2F

%3A

%3B

%3D

%3F

%40

%5B

%5D

يمكن أيضًا ترميز الأحرف المحجوزة التي ليس لها غرض محجوز في سياق معين بنسبة مئوية ولكنها لا تختلف دلاليًا عن تلك التي ليست كذلك.

في مكون " الاستعلام " من URI (الجزء بعد ?حرف)، على سبيل المثال، /لا يزال يُعتبر حرفًا محجوزًا ولكنه لا يحتوي عادةً على غرض محجوز، ما لم ينص مخطط URI معين على خلاف ذلك. لا يلزم ترميز الحرف بنسبة مئوية عندما لا يحتوي على غرض محجوز.

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

لا يلزم ترميز الأحرف من المجموعة غير المحجوزة أبدًا بالنسبة المئوية.

إن عناوين URI التي تختلف فقط في كون الحرف غير المحجوز مشفرًا بنسبة مئوية أو يظهر حرفيًا تكون متكافئة بحكم التعريف، ولكن معالجات عناوين URI، في الممارسة العملية، قد لا تتعرف دائمًا على هذا التكافؤ. على سبيل المثال، لا ينبغي لمستهلكي عناوين URI التعامل %41بشكل مختلف عن Aأو %7Eبشكل مختلف عن ~، ولكن البعض يفعل ذلك. لتحقيق أقصى قدر من التوافق، لا يُنصح منتجي عناوين URI بترميز الأحرف غير المحجوزة بنسبة مئوية.

نظرًا لأن حرف النسبة المئوية ( %) يعمل على الإشارة إلى الثمانية بتات المشفرة بالنسبة المئوية، فيجب أن يتم تشفيرها بنسبة مئوية حتى %25يتم استخدامها كبيانات داخل URI.

تتضمن معظم مخططات URI تمثيل بيانات عشوائية، مثل عنوان IP أو مسار نظام الملفات ، كمكونات لـ URI. يجب أن توفر مواصفات مخطط URI، ولكن غالبًا لا توفر، تعيينًا صريحًا بين أحرف URI وجميع قيم البيانات المحتملة التي تمثلها تلك الأحرف.

منذ نشر RFC 1738 في عام 1994، تم تحديد أن المخططات التي توفر تمثيل البيانات الثنائية في URI يجب أن تقسم البيانات إلى بايتات مكونة من 8 بتات وترميز كل بايت بنسبة مئوية بنفس الطريقة المذكورة أعلاه. ^[1] على سبيل المثال، يجب تمثيل قيمة البايت 0x0F بواسطة %0F، ولكن يمكن تمثيل قيمة البايت 0x41 بواسطة A، أو %41. عادةً ما يُفضل استخدام الأحرف غير المشفرة للأحرف الأبجدية الرقمية وغيرها من الأحرف غير المحجوزة، حيث يؤدي ذلك إلى عناوين URL أقصر.

غالبًا ما تم استقراء إجراء ترميز البيانات الثنائية بنسبة مئوية، وأحيانًا بشكل غير مناسب أو بدون تحديد كامل، لتطبيقه على البيانات القائمة على الأحرف. في السنوات التكوينية للويب العالمي ، عند التعامل مع أحرف البيانات في ذخيرة ASCII واستخدام البايتات المقابلة لها في ASCII كأساس لتحديد التسلسلات المشفرة بنسبة مئوية، كانت هذه الممارسة غير ضارة نسبيًا؛ كان من المفترض فقط أن الأحرف والبايتات يتم تعيينها واحدًا لواحد وقابلة للتبادل. ومع ذلك، نمت الحاجة إلى تمثيل الأحرف خارج نطاق ASCII بسرعة، وغالبًا ما فشلت مخططات وبروتوكولات URI في توفير قواعد قياسية لإعداد بيانات الأحرف للتضمين في URI. وبالتالي بدأت تطبيقات الويب في استخدام ترميزات مختلفة متعددة البايتات، وحالة ، وغيرها من الترميزات غير المتوافقة مع ASCII كأساس للترميز بنسبة مئوية، مما أدى إلى الغموض وصعوبة تفسير URIs بشكل موثوق.

على سبيل المثال، تفترض العديد من مخططات وبروتوكولات URI المستندة إلى RFCs 1738 و2396 أن أحرف البيانات سيتم تحويلها إلى بايتات وفقًا لبعض ترميز الأحرف غير المحدد قبل تمثيلها في URI بأحرف غير محجوزة أو بايتات مشفرة بنسبة مئوية. إذا لم يسمح المخطط لـ URI بتقديم تلميح حول الترميز المستخدم، أو إذا تعارض الترميز مع استخدام ASCII لترميز الأحرف المحجوزة وغير المحجوزة بنسبة مئوية، فلا يمكن تفسير URI بشكل موثوق. تفشل بعض المخططات في مراعاة الترميز على الإطلاق وبدلاً من ذلك تقترح فقط أن أحرف البيانات تتطابق مباشرة مع أحرف URI، مما يترك الأمر للتطبيقات لتقرر ما إذا كانت ستشفر أحرف البيانات التي لا توجد في المجموعات المحجوزة أو غير المحجوزة بنسبة مئوية وكيف تفعل ذلك.

الأحرف الشائعة بعد ترميز النسبة المئوية (بناءً على ASCII أو UTF-8)

␣

"

%

-

.

<

>

\

^

_

`

{

|

}

~

£

€

%20

%22

%25

%2D

%2E

%3C

%3E

%5C

%5E

%5F

%60

%7B

%7C

%7D

%7E

%C2%A3

%E2%82%AC

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

توصي قواعد بناء جملة URI العامة بأن مخططات URI الجديدة التي توفر تمثيل بيانات الأحرف في URI يجب أن تمثل في الواقع أحرفًا من المجموعة غير المحجوزة دون ترجمة ويجب تحويل جميع الأحرف الأخرى إلى بايتات وفقًا لـ UTF-8 ، ثم ترميز هذه القيم بنسبة مئوية. تم تقديم هذا الاقتراح في يناير 2005 مع نشر RFC 3986. مخططات URI التي تم تقديمها قبل هذا التاريخ لا تتأثر.

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

يوجد ترميز غير قياسي لأحرف Unicode: حيث xxxx هي وحدة ترميز UTF-16 ممثلة بأربعة أرقام سداسية عشرية. هذا السلوك غير محدد بواسطة أي RFC وقد تم رفضه من قبل W3C. لا تزال النسخة الثالثة عشر من ECMA-262 تتضمن وظيفة تستخدم هذا النحو، والتي تطبق ترميز UTF-8 على سلسلة، ثم تهرب النسبة المئوية للبايتات الناتجة. ^[2]%uxxxxescape

عند إرسال البيانات التي تم إدخالها في نماذج HTML ، يتم ترميز أسماء حقول النموذج وقيمها وإرسالها إلى الخادم في رسالة طلب HTTP باستخدام طريقة GET أو POST ، أو تاريخيًا، عبر البريد الإلكتروني . ^[3] يعتمد الترميز المستخدم افتراضيًا على إصدار مبكر من قواعد ترميز النسبة المئوية العامة لـ URI، ^[4] مع عدد من التعديلات مثل تطبيع السطر الجديد واستبدال المسافات بـ +بدلاً من %20. نوع الوسائط للبيانات المشفرة بهذه الطريقة هو application/x-www-form-urlencoded، وهو محدد حاليًا في مواصفات HTML و XForms . بالإضافة إلى ذلك، تحتوي مواصفات CGI على قواعد لكيفية فك تشفير خوادم الويب لبيانات من هذا النوع وإتاحتها للتطبيقات.

عند إرسال بيانات نموذج HTML في طلب HTTP GET، يتم تضمينها في مكون الاستعلام الخاص بـ URI الخاص بالطلب باستخدام نفس الصيغة الموضحة أعلاه. عند إرسالها في طلب HTTP POST أو عبر البريد الإلكتروني، يتم وضع البيانات في نص الرسالة، ويتم application/x-www-form-urlencodedتضمينها في رأس Content-Type الخاص بالرسالة.

• معرف الموارد الدولي
• بونيكود
• الترميز الثنائي إلى نص للمقارنة بين خوارزميات الترميز المختلفة
• كود الشل
• قاعدة 64

تناقش المواصفات التالية وتحدد الأحرف المحجوزة، والأحرف غير المحجوزة، وترميز النسبة المئوية، في شكل أو آخر:

• RFC 3986 / STD 66 (بالإضافة إلى الأخطاء المطبعية)، مواصفات بناء جملة URI العامة الحالية.
• شكلت RFC 2396 (قديم، بالإضافة إلى الأخطاء المطبعية) وRFC 2732 (بالإضافة إلى الأخطاء المطبعية) معًا الإصدار السابق من مواصفات بناء جملة URI العامة.
• RFC 1738 (قديم في الغالب) وRFC 1808 (قديم)، والتي تحدد عناوين URL .
• RFC 1630 (قديم)، أول مواصفات بناء جملة URI عامة.
• إرشادات W3C بشأن التسمية والتوجيه: URIs وعناوين URL و ...
• شرح W3C لـ UTF-8 في URIs
• أنواع محتوى نموذج HTML الخاص بـ W3C