קידוד URL

קידוד URL או קידוד באחוזים (באנגלית: URL Encoding) הוא שיטת קידוד תווים שמאפשרת להמיר כל מחרוזת טקסט למחרוזת שמכילה תווי ASCII חוקיים בלבד, בצורה שיתאפשר להשתמש בה בתור URI תקין, כגון כ-URL על גבי האינטרנט או כמזהה משאב אחיד (URN).

קידוד באחוזים מחליף תווי ASCII לא בטוחים, כדוגמת תווים ביוניקוד שאינם מופיעים ב-ASCII, עם הסימן "%" (אחוז) ולאחריו שתי ספרות הקסדצימליות. בנוסף, URL לא יכול להכיל רווחים, ולכן הקידוד יחליף אותם עם הסימן "+" (פלוס) או עם התווים "%20".

כך למשל, המילים "קידוד URL" יוחלפו במחרוזת %D7%A7%D7%99%D7%93%D7%95%D7%93_URL.

קידוד אחוזים ב-URI

סוגים של תווים URI

התווים המותרים ב-URI הם שמורים או לא שמורים (או תו אחוז כחלק מהקידוד). תווים שמורים הן תווים שלפעמים יש להן משמעות מיוחדת. לדוגמה, התו לוכסן (/) משמש להפרדה בין חלקים שונים של כתובת URL (או באופן כללי יותר, URI). לתווים לא שמורים אין משמעויות מיוחדת, ובאמצעות קידוד אחוזים תווים שמורים מיוצגים באמצעות רצפי תווים מיוחדים. קבוצות התווים השמורים והלא שמורים והנסיבות שבהן יש משמעות מיוחדת לתווים שמורים מסוימים השתנו מעט עם כל עדכון של מפרטים השולטים ב-URI ובסכימות 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 בקטע במקום בתו /.

תווים שמורים לאחר קידוד אחוז

␣

!

#

$

%

&

'

(

)

*

+

,

/

:

;

=

?

@

[

]

%20

%21

%23

%24

%25

%26

%27

%28

%29

%2A

%2B

%2C

%2F

%3A

%3B

%3D

%3F

%40

%5B

%5D

תווים שמורים שאין להם מטרה שמורה בהקשר מסוים עשויים להיות מקודדים באחוזים אך אינם שונים מבחינה סמנטית מאלה שאינם.

ברכיב "שאילתה" של URI (החלק שאחרי תו ?), למשל, / עדיין נחשב לתו שמור אך בדרך כלל אין לו מטרה שמורה, אלא אם סכימת URI מסוימת אומרת אחרת. התו אינו צריך להיות מקודד באחוזים כאשר אין לו מטרה שמורה.

כתובות URI שההבדל היחידי שלהם הוא האם תו שמור מקודד באחוזים או מופיע באופן מילולי, נחשבים בדרך כלל לא שווים (המציינים את אותו משאב), אלא אם כן ניתן לקבוע שלתווים השמורים המדוברים אין מטרה שמורה. קביעה זו תלויה בכללים שנקבעו עבור תווים שמורים על ידי סכימות URI בודדות.^{[דרוש מקור][מפני ש...]}

תווים לא שמורים

לעולם אין צורך בקידוד אחוזים של תווים מהקבוצה הבלתי שמורה.

URIs שנבדלים רק אם תו לא שמור מקודד באחוזים או מופיע באופן מילולי הם שווים בהגדרה, אך מעבדי URI, בפועל, עשויים שלא תמיד לזהות את השקילות הזו. לדוגמה, צרכני URI לא צריכים להתייחס ל-%41 בצורה אחרת מהתו Aאו ל-%7E בצורה אחרת מ ~, אבל יש כאלה שכן. למען יכולת פעולה הדדית מרבית, מפיקי URI אינם מעודדים קידוד אחוזים של תווים לא שמורים.

תו אחוז

מכיוון שתו האחוז ( %) משמש כסימן לספרות שקודדו באחוזים, עליו להיות מקודד באחוזים כמו %25כדי שתו זה ישמש כנתונים בתוך URI.

נתונים שרירותיים

רוב סכימות URI כוללות ייצוג של נתונים שרירותיים, כגון כתובת IP או נתיב מערכת קבצים, כרכיבים של URI. מפרטי סכימת URI צריכים, אך לרוב לא עושים זאת בפועל, לספק מיפוי מפורש בין תווי URI וכל ערכי הנתונים האפשריים המיוצגים על ידי התווים הללו.^{[דרושה הבהרה]}

נתונים בינאריים

מאז פרסום RFC 1738 בשנת 1994 צוין כי סכמות המספקות ייצוג של נתונים בינאריים ב-URI חייבות לחלק את הנתונים לבייטים של 8 סיביות ולקודד באחוזים של כל בייט באותו אופן כמו לעיל. ערך בתים 0x0F, למשל, צריך להיות מיוצג על ידי %0F, אבל ערך בתים 0x41 יכול להיות מיוצג על ידי A, או %41. השימוש בתווים לא מקודדים עבור תווים אלפאנומריים ותווים אחרים שאינם שמורים מועדף בדרך כלל מכיוון שהוא גורם לכתובות URL קצרות יותר.

נתוני תווים

הפרוצדורה של קידוד נתונים בינאריים באחוזים הוחלפה לעיתים קרובות, לעיתים באופן לא הולם או מבלי שצוין במלואו, כדי להחיל על מחרוזות תווים. בשנות היצירה של ה-World Wide Web, כאשר עסקו בתווי נתונים בטבלת ה-ASCII והשתמשו בבתים המתאימים להם ב-ASCII כבסיס לקביעת רצפים שמקודדים באחוזים, תרגול זה היה יחסית לא מזיק; רק ההנחה הייתה שתווים ובייטים ממופים אחד לאחד וניתנים להחלפה. הצורך לייצג תווים מחוץ לטווח ASCII, לעומת זאת, גדל במהירות ותוכניות URI ופרוטוקולים לא הצליחו לספק כללים סטנדרטיים להכנת נתוני תווים להכללה ב-URI. כתוצאה מכך, יישומי אינטרנט החלו להשתמש במספר בתים שונים, תלויי מצב, וקידודים אחרים שאינם תואמים ASCII כבסיס לקידוד אחוזים, מה שמוביל לעמימות ולקושי לפרש URIs בצורה מהימנה.

לדוגמה, סכימות ופרוטוקולים רבים של URI המבוססים על RFCs 1738 ו-2396 מניחים שתווי הנתונים יומרו לבייטים לפי קידוד תווים לא מוגדר לפני ייצוג ב-URI על ידי תווים לא שמורים או בתים מקודדים באחוזים. אם הסכימה אינה מאפשרת ל-URI לספק רמז לגבי הקידוד שבו נעשה שימוש, או אם הקידוד מתנגש עם השימוש ב-ASCII לקידוד אחוזים שמורים ולא שמורים, אזי לא ניתן לפרש את ה-URI בצורה מהימנה. סכימות מסוימות אינן מסוגלות כלל להתייחס לקידוד, ובמקום זאת פשוט מציעות שתווי נתונים ממפות ישירות לתווי URI, מה שמותיר את המימושים להחליט אם וכיצד לקודד באחוזים תווי נתונים שאינם בסט השמורים או הלא-שמורים.

תווים נפוצים לאחר קידוד אחוז (מבוסס ASCII או UTF-8)

newline

space

"

%

-

־

.

<

>

\

^

_

`

{

|

}

~

£

円

%0A או %0D או %0D%0A

%20

%22

%25

%2D

%D6%BE

%2E

%3C

%3E

%5C

%5E

%5F

%60

%7B

%7C

%7D

%7E

%C2%A3

%E5%86%86

נתוני תווים שרירותיים מקודדים לפעמים באחוזים ומשמשים במצבים שאינם URI, כגון עבור תוכניות ערפול סיסמאות, או פרוטוקולי תרגום אחרים ספציפיים למערכת.

תקן נוכחי

תחביר ה-URI הגנרי ממליץ שסכימות URI חדשות המספקות ייצוג של נתוני תווים ב-URI צריכות, למעשה, לייצג תווים מהקבוצה הבלתי שמורה ללא תרגום, ועליו להמיר את כל שאר התווים לבייטים לפי UTF-8, ולאחר מכן לקודד באחוזים את הערכים האלה. הצעה זו הוצגה בינואר 2005 עם פרסום RFC 3986. סכמות URI שהוצגו לפני תאריך זה אינן מושפעות.

המפרט הנוכחי לא מטפל במה לעשות עם נתוני תווים המקודדים. לדוגמה, במחשבים, נתוני תווים באים לידי ביטוי בצורה מקודדת, ברמה מסוימת, ולכן ניתן להתייחס אליהם כאל נתוני בינארי או תווים בעת מיפוי לתווי URI. ככל הנראה, זה תלוי במפרטי סכימת ה-URI לתת את הדעת על אפשרות זו ולדרוש כזו או אחרת, אבל בפועל, מעטים, אם בכלל, עושים זאת.

יישומים לא סטנדרטיים

קיים קידוד לא סטנדרטי עבור תווי יוניקוד:, כאשר xxxx היא יחידת קוד UTF-16 המיוצגת כארבע ספרות הקסדצימליות. התנהגות זו אינה מוגדרת על ידי אף RFC ונדחתה על ידי W3C, המהדורה השמינית של ECMA-262 עדיין כוללת פונקציית escape שמשתמשת בתחביר זה, יחד עם encodeURI ו-encodeURIComponent, אשר מיישמות קידוד UTF-8 למחרוזת, ואז קידוד-באחוזים של הבתים המתקבלים.

בטפסי HTML

כאשר נתונים שהוזנו לטפסי HTML נשלחים, השמות והערכים של שדות הטופס מקודדים ונשלחים לשרת בהודעת בקשת HTTP באמצעות שיטות GET או POST. הקידוד המשמש כברירת מחדל מבוסס על גרסה מוקדמת של כללי הקידוד האחוזים הכלליים של URI, עם מספר שינויים כגון נורמליזציה של שורה חדשה והחלפת רווחים ב-+ במקום %20. סוג המדיה של הנתונים המקודדים בדרך זו הוא application/x-www-form-urlencoded, והוא מוגדר כעת במפרטי HTML ו- XForms. בנוסף, הדרישות של ה-CGI מכילים כללים לאופן שבו שרתי אינטרנט מפענחים נתונים מסוג זה והופכים אותם לזמינים ליישומים.

כאשר נתוני טופס HTML נשלחים בבקשת HTTP GET, הם נכללים ברכיב השאילתה של URI הבקשה באמצעות אותו תחביר שתואר לעיל. כאשר נשלח בבקשת HTTP POST או בדוא"ל, הנתונים ממוקמים בגוף ההודעה, והתגית application/x-www-form-urlencoded נכתבת ב-Content-Type של ה-header של ההודעה.

קישורים חיצוניים

• URL Decoder/Encoder, כלי לקידוד ופענוח של מחרוזות כתובות רשת (URL) מקידוד אחוזים לשפת מקור בה נכתב הקישור.
• RFC3986, המפרט הטכני (RFC) של URI, ובתוכו המפרט של קידוד אחוזים.