Why do spaces turn into %20 sometimes and + other times?

Two different specs. RFC 3986, which governs URLs themselves, encodes a space as %20. The application/x-www-form-urlencoded format used by HTML form submissions, defined in the WHATWG URL Standard, encodes a space as +. Both are valid in their own context, which is why + in a query string is ambiguous. The safe practice: always produce %20 for spaces and %2B for literal plus signs — every parser handles those correctly.

What is the difference between encodeURI and encodeURIComponent?

encodeURIComponent encodes nearly everything, including /, ?, &, and =, making it safe for individual values placed inside a URL. encodeURI preserves those reserved characters so a complete URL keeps its structure. Use encodeURIComponent for parameter values and path segments — which is almost every real-world case — and encodeURI only when sanitizing a full URL without restructuring it. Using encodeURI on a value containing & will silently break your query string.

How do I fix a double-encoded URL?

Double encoding happens when an already-encoded string gets encoded again — %20 becomes %2520 because the % itself turns into %25. To fix it, decode the string repeatedly until no %XX sequences remain and the output stops changing. Then find which layer of your system encoded twice — commonly your code plus a proxy, redirect service, or email link-wrapper — and remove one of the encoding steps. The rule: encode exactly once, at the last moment before the value enters the URL.

Is it safe to decode URLs in an online tool?

Only if the tool runs client-side. URLs frequently contain OAuth codes, password-reset tokens, session IDs, and email addresses. A server-side tool receives all of that and may keep it in access logs indefinitely. The toolz.dev URL Encoder/Decoder performs all conversion in your browser with JavaScript — no data is transmitted anywhere, which you can verify in your browser's network tab. For anything containing credentials or tokens, client-side processing should be non-negotiable.

Do I need to encode the whole URL or just the parameters?

Just the data parts — individual parameter values and, occasionally, path segments. The structural characters of the URL itself (the :// after the scheme, the ? starting the query, the & between parameters) must stay unencoded or the URL stops working. Encode each value separately with component-style encoding, then assemble the URL around them. Encoding a complete URL end-to-end is only correct when that URL is itself becoming a value inside another URL, like an OAuth redirect_uri.

Can URL encoding handle emoji and non-English characters?

Yes — modern percent-encoding operates on UTF-8 bytes, so any Unicode character works. A two-byte character like é becomes %C3%A9, and a four-byte emoji becomes four percent-sequences, such as %F0%9F%9A%80. Problems only arise with legacy tools or JavaScript's deprecated escape() function, which assume single-byte encodings and produce invalid output. The toolz.dev encoder handles full UTF-8 correctly in both directions.

Why does my URL break when a parameter contains an ampersand?

Because & is the delimiter between parameters. If a value contains a raw ampersand — say utm_campaign=black&friday — the server parses it as a parameter named utm_campaign with value black, plus a second parameter named friday. No error is raised; your data is just silently wrong. Encode the ampersand as %26 inside the value and the parameter arrives intact. This is one of the most common and least visible URL bugs.

What does %2F mean in a URL?

%2F is the percent-encoded forward slash. You'll see it when a value that happens to contain a slash — a file path, a date like 07/07, or a nested URL — is correctly encoded before being placed in a query parameter or path segment. Be aware that some servers and proxies (Apache, older Tomcat versions, various API gateways) reject or silently decode %2F in the path for security reasons, so if a request with an encoded slash returns a 404, the server-side configuration is usually the culprit, not your encoding.

How do I URL encode in Python, PHP, or on the command line?

Python: urllib.parse.quote() for path segments and quote_plus() for form-style query values. PHP: rawurlencode() produces RFC 3986 output with %20 for spaces, while urlencode() produces form-style output with +. Command line: jq -rR @uri or curl's --data-urlencode flag. Every one of these matches the component-style behavior of this tool, so you can prototype the encoding here and verify your code produces byte-identical output.

קידוד ופענוח כתובת URL באינטרנט: המדריך המלא לאחוז קידוד מבלי לשבור את הקישורים שלך

הבאג שלימד אותי לכבד קידוד אחוזים היה הפניה מחדש של OAuth שנכשלה עבור לקוח אחד בדיוק. ל-WP Adminify הייתה אינטגרציה של Google Fonts שאומתה דרך OAuth, ומשתמש אחד - משווק אירוח שמריץ איזו הגדרת פרוקסי הפוך שאני עדיין עושה ' לא מבין לגמרי - המשיך לקבל redirect_uri_mismatch שגיאות כל השאר היו בסדר ביליתי את החלק הטוב ביותר של יומיים בהאשמת תצורת השרת שלו ואז סוף סוף הסתכלתי על כתובת האתר האמיתית שהדפדפן שלו שולח, תו אחר תו, והנה זה היה: %2520 איפה רווח היה צריך להיות. proxy שלו היה קידוד redirect_uri. התוסף שלי היה גם קידוד זה. Google קיבלה כתובת URL שבה השטח קודד פעמיים - %20 הפך %2520- ודחה את כל לחיצת היד שתי שורות קוד תיקנו את זה יומיים למצוא את זה.

זה היה 't אפילו אסון הקידוד הראשון שלי.Years earlier I'd בנה קישור לקמפיין להשקת תוסף עם פרמטר UTM שהכיל אמפרסנד גולמי - משהו כמו utm_campaign=black&friday. לוח המחוונים של הניתוח הראה קמפיין מסתורי שנקרא black ופרמטר פנטום שנקרא friday זה לא התאים לכלום האמפרסנד חילק בשקט את הפרמטר שלי לשניים אין שגיאה אין אזהרה פשוט נתונים שגויים בשקט במשך אחד עשר ימים לפני ששמתי לב שהמספרים עשו 't מסתכמים.

Here's העניין בקידוד כתובת URL: it's אחת מאותן בעיות שנראות טריוויאליות עד שהיא 't. הכללים חיים במפרט משנת 2005 (RFC 3986), מציאות הדפדפן חיה במפרט אחר (ה WHATWG תקן URL), JavaScript נותן לך שלוש פונקציות שונות שכולן עושות דברים מעט שונים, ו-PHP נותן לך שתיים נוספות. תטעה ואתה עושה ' t get a crash - אתה מקבל פרמטרים קטועים, זרימות OAuth שבורות וקישורים שעובדים ב-Chrome אבל מתים בלקוח דואר אלקטרוני.

אז בניתי את המקודד/מפענח שתמיד רציתי להיכנס אליו Toolz.dev. מדריך זה מכסה כיצד להשתמש בו, וחשוב מכך - כיצד קידוד אחוזים עובד בפועל, אז הבא %2520 ביומנים שלך לוקח לך שתי דקות במקום יומיים.

TL;DR: כדי לקודד או לפענח כתובת URL באופן מקוון, הדבק את המחרוזת שלך ב- Toolz.dev URL מקודד/מפענח, בחר מצב ולחץ על Encode או Decode. הוא מטפל ב-UTF-8 ובאימוג'י בצורה נכונה, וכפתור ההחלפה מזין את הפלט בחזרה לקלט כדי שתוכל לקלף ערכים מקודדים כפולים (%2520) מלבד שכבה אחת בכל פעם. הכל פועל בצד הלקוח, כך שאסימונים ומזהי הפעלה בכתובות האתרים שלך לעולם לא נוגעים בשרת. פרמטר קידוד ערכים עם מצב רכיב; מקודד כתובות URL מלאות רק כאשר אתה יודע מדוע.

תכונות מפתח

קידוד ופענוח בכלי אחד

חצי מהזמן אני צריך לקודד ערך החצי השני I'm בוהה בכתובת URL מסוקסת מקובץ יומן וצריך לפענח אותה למשהו קריא הכלי עושה את שניהם מתיבת קלט אחת - קידוד ופענוח יושבים זה ליד זה כשני כפתורים, אז there's לא מחפש דף נפרד. הדבק מחרוזת מקודדת והקש על פענוח; הקלד ערך שאילתה גולמי והקש על קידוד. זה גם הלוך ושוב בצורה נקייה: מקודד, פענח, ואתה מקבל את המחרוזת המקורית שלך בחזרה, בייט עבור בייט. זה נשמע ברור, אבל I' השתמש בכלים מקוונים שהשתבשו בתוספת שלטים בנסיעה הלוך ושוב כי הם יכלו ' לא להחליט באיזה מפרט הם עקבו. זה מפורש לגבי מה זה 's עושים בכל שלב, וזה בדיוק מה שאתה רוצה כאשר אתה're איתור באגים.

מצבי קידוד רכיב לעומת כתובת אתר מלאה

הבחנה זו היא המקום שבו נולדים רוב באגי הקידוד. מצב רכיב מקודד את כל מה ש- 't ללא סייג - כולל /, ?, &, ו =- וזה מה שאתה רוצה עבור ערך פרמטר בודד. מצב כתובת URL מלאה משאיר את התווים המבניים לבד כך שכתובת האתר עדיין עובדת ככתובת URL, וזה מה שאתה רוצה כאשר אתה' מנקה כתובת מלאה. שימוש בכתובת הלא נכונה שובר את מבנה כתובת האתר שלך או משאיר תווים מסוכנים לא מקודדים. הכלי שם את שני המצבים במרחק לחיצה אחת זה מזה בתפריט נפתח אחד, המסומן בפונקציית JavaScript שכל אחד מהם מתאים לה - encodeURIComponent, encodeURI, application/x-www-form-urlencoded. הלכתי הלוך ושוב על השם הזה. תוויות כוונות ("מקודדות ערך", "מקודדות כתובת URL&quot שלמה;) יקראו קר טוב יותר, אבל שמות פונקציות פירושם שחלונית ההפניה שמתחת ממפה אחד לאחד על הקוד שאתה ' עומדים לכתוב, וזה ' זה הרגע שבו רוב האנשים נמצאים בפועל. אם אתה ' אי פעם הקלדת encodeURI כשהתכוונת encodeURIComponent- יש לי, יותר מפעם אחת - הפאנל שם כדי לתפוס אותו לפני שאתה שולח.

מטפל בדמויות UTF-8, Emoji ודמויות בינלאומיות

סוג café ואתה מקבל caf%C3%A9- ה é מורחבת נכונה לשני בתים UTF-8 שלה הקלד אימוג'י ואתה מקבל בתים מקודדים בארבעה אחוזים זה המקום שבו כלים ישנים יותר ו-JavaScript שהוצא משימוש escape() פונקציה מתפרקת: הם מניחים לטינית-1 או מייצרים לא סטנדרטיים %uXXXX רצפים שאף שרת לא יכול לנתח. If you're בניית כתובות URL עם תוכן שנוצר על ידי משתמשים - שמות, שאילתות חיפוש, שמות ערים בכל שפה שהיא't English - טיפול נכון ב-UTF-8 isn't a nice-to-have.טקסט בנגלי, שבלולים בערבית, מונחי חיפוש סיניים: כולם מקודדים לרצפים חוקיים של RFC 3986 אחוזים שמפענחים באופן זהה בצד השני.

לחצן החלפה עבור ערכים מקודדים כפולים

ה %2520 מלכודת - כבר מקודדת %20 מקבל מקודד שוב - עלה לי יומיים פעם אחת, אז זה אחד הוא אישי פענוח הוא פעולה חד-שכבתית: %2520 מפענח ל %20, לא לחלל, כי %25 הוא הקידוד של %. מעבר אחד מביא לך שכבה אחת. כפתור ההחלפה (⇄) מעביר את הפלט בחזרה לתוך תיבת הקלט כך המעבר הבא הוא במרחק קליק אחד. I've uncrapped URLs שלוש שכבות עמוק לאחר שהם עברו דרך פרוקסי, שירות ניתוב מחדש, ו-email link-wrapper - swap, decode, swap, decode, עד שהמחרוזת מפסיקה להשתנות. That "stops changing" moment is the actual signal you're looking for.Be honest about what this is: it's a manual loop, not a detector.The tool doesn't flag %25XX בשבילך, ואני הולך הלוך ושוב אם זה צריך - פענוח אוטומטי עד יציב יהיה נוח ממש עד שהוא הורס בשקט ערך שהכיל באופן לגיטימי סימן אחוז.

שלושה מצבים, לוח התייחסות מפורש אחד

בורר המצבים נושא שלוש אפשרויות - רכיב, כתובת URL מלאה ומעודן טפסים - והפאנל שמתחתיו מפרט בדיוק אילו תווים המצב הזה בורח, אותם הוא משמר, ומציג דוגמה עובדת. הוספתי את זה כי אף פעם לא יכולתי לזכור אם encodeURIComponent עלים ~ לבד (זה כן) או אם ! ו * לשרוד (הם עושים זאת, מה שמפתיע אנשים, מכיוון ש-RFC 3986 מסווג אותם כתתי-תחימות ולא בלתי מסויגים). במקום לשנן שלוש פונקציות JavaScript ' מוזרויות, אתה בוחר את המצב מתוך כוונה וקורא בחזרה את מה שהוא ' עומד לעשות. טקסט ההתייחסות הזה הוא החלק שאני משתמש בו הכי הרבה, והוא ' זה הדבר I' הייתי רוצה אם הייתי נוחת על הדף קר ב-1 לפנות בוקר.

100% צד לקוח - שום דבר לא עוזב את הדפדפן שלך

תחשוב על מה 's למעשה בתוך כתובות האתרים שאתה מפענח: קודי הרשאות OAuth, אסימונים לאיפוס סיסמה, מזהי הפעלה, כתובות דואל בקישורים לביטול הרשמה, מפתחות API מסגרת כלשהי ממולאת בצורה מועילה במחרוזת שאילתה. הדבק אותם בכלי בצד השרת והם נוחתים ב- someone's יומני גישה, קשורים ל-IP שלך, נשמרים למי יודע כמה זמן. מקודד Toolz.dev פועל כולו בדפדפן שלך - ההמרה היא כמה שורות של JavaScript המופעלות באופן מקומי, ולא מוגשת בקשה עם הנתונים שלך. פתח את DevTools וצפה בכרטיסיית הרשת אם אתה עושה ' אל תאמין לי. לכל דבר סמוך לאבטחה, צד הלקוח הוא ' t תכונה, it' הוא סרגל המינימום.

חינם, ללא כניסה, ללא מגבלות

אין קיר חשבון, אין לנדנד מכסה יומית עבור כלי שעושה טרנספורמציה מחרוזת, אין " לשדרג ל - Pro לפענח יותר מ -1,000 תווים." בניתי Toolz.dev כי נמאס לי אתרי שירות חנוק מודעה כי להפריע משימה של עשר שניות עם קופץ עלון.סימני את זה, השתמש בו חמישים פעמים ביום, בוצע.

כיצד להשתמש במקודד ובמפענח כתובת האתר

שלב 1: פתח את הכלי ובחר את הכיוון שלך

עבור אל Toolz.dev/tools/url-encoder ושחרר את המחרוזת שלך לתיבה השמאלית. ישנם שני לחצני פעולה, קידוד ופענוח, ואתה בוחר אחד לאחר הדבקה במקום להגדיר כיוון תחילה. אם אתה ' מתחילים ממשהו קריא (שאילתת חיפוש, כתובת URL להפניה מחדש שאתה ' עומדים להטמיע), לחץ על Encode. אם אתה ' מתחילים ממשהו מלא בסימני אחוזים (ערך יומן, כותרת מפנה), לחץ על פענוח. פלט נוחת בחלונית הימנית עם כפתור העתקה בכותרת שלה, והחלפה וניקוי יושבים ליד שני לחצני הפעולה.

שלב 2: בחר רכיב, כתובת אתר מלאה או מצב טופס

קידוד א ערך שישב בתוך פרמטר - redirect_uri, מונח חיפוש, כל דבר אחרי an = סימן? השתמש במצב רכיב. זה מקודד /, ?, &, ו = אז הערך שלך יכול 't לשבור את כתובת האתר שמסביב. קידוד א כתובת אתר מלאה זה רק צריך לנקות רווחים ותווים שאינם ASCII? השתמש במצב כתובת URL מלאה, המשמר את התווים המבניים. המצב השלישי, מקודד בצורת כתובת אתר, הוא קידוד רכיבים עם רווחים שנכתבו כ + במקום %20- בחר את זה כשאתה ' מחדש בניית יד application/x-www-form-urlencoded גוף שים לב שהמצב משפיע גם על הפענוח: במצב צורה, + מומר בחזרה לחלל לפני הפענוח; בשני האחרים זה נשאר פלוס מילולי. כאשר יש ספק: מצב רכיב עבור חלקים, מצב כתובת URL מלאה עבור שלמים.

שלב 3: קרא את הפלט וצפה בשאריות של סימני אחוז

פלט מופיע בחלונית הימנית לפענוח, בדוק אם התוצאה עדיין מכילה %XX רצפים - אם כן, הערך היה מקודד יותר מפעם אחת. לחץ על החלפה כדי להעביר את הפלט הזה בחזרה לקלט, פענח שוב וחזור עד שהמחרוזת תפסיק להשתנות. אם הקלט פגום (תועה % לא אחריו שתי ספרות משושה, כמו מילולית 100%), אתה ' תקבל שגיאה מפורשת ולא חצי פענוח שקט, שזו ההתנהגות שאתה רוצה כאשר אתה 'מחפש באגים.

שלב 4: העתק ואמת

לחץ על כפתור ההעתקה והדבק את התוצאה היכן שהיא שייכת לכל דבר חשוב - OAuth מפנה במיוחד - בצע בדיקת שפיות אחת אחרונה: הדבק את הערך המקודד בחזרה במצב פענוח ואשר אותו הלוך ושוב בדיוק למה שהתחלת איתו שלושים שניות של אימות פעימות יומיים של redirect_uri_mismatch.

אחוז קידוד, RFC 3986 ומדוע רווחים הופכים ל-% 20 או +

כתובות אתרים יכולות להכיל בבטחה רק קבוצה מוגבלת של תווים. יש להבריח את כל השאר בתור בתים מקודדים באחוזים. ספר החוקים הוא RFC 3986 (2005), והוא מפצל דמויות לשני מחנות.

תווים לא שמורים לעולם לא צריך קידוד: האותיות A–Z ו a–z, ספרות 0–9, וארבעה סמלים - מקף -, נקודה ., קו תחתון _וטילדה ~. קידוד אלה הוא חוקי אך חסר טעם.

תווים שמורים יש עבודות מבניות בתוך כתובת URL: : / ? # [ ] @ (המפרידים הכלליים) ו ! $ & ' ( ) * + , ; = (תתי המפרידים) נקודתיים מפרידה סכימה ממארח סימן השאלה מתחיל את מחרוזת השאילתה האמפרסנד מפריד פרמטרים האם תו שמור צריך קידוד תלוי לחלוטין ב איפה זה מופיע. א / בשביל מבנה; א / בתוך ערך פרמטר redirect_uri יש נתונים, והם חייבים להפוך %2F או שהשרת ינתח את כתובת האתר שלך בצורה שגויה.

המכניקה: קח את הדמות, קבל את ה-UTF-8 בתים (ים) שלה, וכתוב כל בייט בתור % ואחריו שתי ספרות hex. ASCII תווים הם בית אחד - רווח הוא %20אמפרסנד היא %26. אבל UTF-8 הוא קידוד מרובה בתים, אז é הוא שני בתים: %C3%A9. אימוג'י טיפוסי הוא ארבעה בתים - A מקודד כ %F0%9F%9A%80. זו הסיבה שכלים המניחים תו אחד שווה בייט אחד משחיתים כל דבר מחוץ לאנגלית פשוטה.

עכשיו, בעיית המרחב - הדבר הכי מבלבל בקידוד URL. לפי RFC 3986, רווח הופך %20. אבל הגשת טפסי HTML משתמשת בסידרה אחרת, application/x-www-form-urlencoded, מוגדר היום ב תקן כתובת URL של WHATWG, ו שֶׁז פורמט מקודד רווחים כ +. שניהם נכונים - בהקשרים שלהם. מה שאומר + במחרוזת שאילתה הוא מעורפל: זה עשוי להיות סימן פלוס מילולי (קריאת RFC 3986) או רווח מקודד (קריאת קידוד צורות). אם אתה ' אי פעם ראית מספר טלפון מגיע כמו 1234 5678 כשמישהו שלח +1234..., you'פגשת את הבאג הזה. העצה שלי: תמיד פולט %20 לחללים ו %2B לסימני פלוס מילוליים. אף אחד לא מנתח אותם בצורה שגויה.

JavaScript נותן לך שלוש פונקציות, והן אינן ניתנות להחלפה בהינתן המחרוזת a=b&c d:

const s = "a=b&c d";

encodeURIComponent(s); // "a%3Db%26c%20d"  — encodes =, &, and space
encodeURI(s);          // "a=b&c%20d"      — leaves = and & alone
escape(s);             // "a%3Db%26c%20d"  — deprecated; breaks on Unicode

encodeURIComponent מקודד הכל מלבד תווים לא שמורים (פלוס !'()*- מוזרות מורשת), מה שהופך אותו בטוח לערכי פרמטרים. encodeURI שומר על תווים שמורים כך שכתובת URL מלאה נשארת פונקציונלית - אבל זה גם אומר את זה won't להגן על & בתוך הנתונים שלך. ו escape() הוצא משימוש מסיבה טובה: הוא מייצר לא סטנדרטי %uXXXX רצפים עבור תווים שאינם לטיניים-1. לעולם אל תשתמש בו בקוד חדש.

PHP משקף את אותו פיצול עם טוויסט: urlencode() מייצר קידוד בסגנון צורה (רווחים הופכים +), בעוד rawurlencode() עוקב אחר RFC 3986 (החללים הופכים %20). אם אתה ' בונים כתובות URL עבור כל דבר אחר מלבד גוף POST של טופס, rawurlencode() הוא זה שאתה רוצה שלחתי קוד WP Adminify עם הלא נכון בשלב מוקדם; וורדפרס' משלו add_query_arg() חסך לי יותר פעמים מאשר I' רוצה להודות.

לבסוף, מלכודת הקידוד הכפול. %20 הוא מרחב, מקודד. Encode המחרוזת הזאת שוב וה % עצמו הופך %25, נותן לך %2520. פענח את זה פעם אחת ותקבל %20 חזרה - עדיין מקודד זה קורה בכל פעם ששתי שכבות של מערכת כל אחת " helpfully" לקודד: הקוד שלך בתוספת פרוקסי, שירות הפניה מחדש בתוספת עטיפת קישור בדואל הכלל שמונע את זה: לקודד בדיוק פעם אחת, ברגע האחרון האפשרי לפני הערך נכנס לכתובת האתר, ולעולם לא לקודד משהו שעשית ' לא רק לפענח או ליצור גלם.

מקרי שימוש נפוצים

בניית מחרוזות שאילתות עם קלט משתמש

בכל פעם שטקסט מסוג משתמש נכנס לכתובת URL - תיבות חיפוש, מסננים, ערכי טופס המועברים באמצעות GET - הוא חייב להיות מקודד ברכיבים. משתמש שמחפש Q&A tips הופך ?q=Q%26A%20tips; לא מקודד, השרת רואה חיפוש Q ופרמטר מסתורין A tips. במהלך הפיתוח, אני משתמש ב מקודד URL כדי ליצור ערכים צפויים לפני כתיבת הקוד, אז יש לי הפניה ידועה-נכונה לבדיקה נגד.It's גם הדרך המהירה ביותר ליישב "האם תו זה צריך להיות מקודד?" ארגומנטים בסקירת קוד: הדבק אותו במצב רכיב ותראה. ממשקי API מודרניים כמו JavaScript's URLSearchParams טפל בזה באופן אוטומטי, וכדאי להשתמש בהם - אבל אתה עדיין צריך לאמת הפלט שלהם כשמשהו נשבר, וזה ' הוא עבודת פענוח.

איתור באגים בקישורי UTM ומסע פרסום

קישורים שיווקיים הם קידוד שדות מוקשים.UTM ערכים עם רווחים, צינורות, או אמפרסנדים; קישורים שעוברים דרך מקצר URL, ואז שירות דואר אלקטרוני's click tracker, ואז הפניה מחדש - כל שכבה הזדמנות לקידוד להתווסף או mangled.כאשר קמפיין מופיע לא נכון ב analytics, המהלך הראשון שלי הוא תמיד אותו הדבר: הדבק את הקישור המלא למצב פענוח וקרא מה שרת האנליטיקה קיבל בפועל תשע פעמים מתוך עשר האשם גלוי בשניות - גלם & פיצול פרמטר, א + זה היה אמור להיות פלוס מילולי, או א %2520 בגידה בקידוד כפול. שֶׁלִי black&friday התקרית הייתה תיקון של אחת עשרה שניות במקום חור נתונים של אחד עשר ימים אם I' עשה זאת ביום הראשון.

OAuth redirect_uri וכתובות URL של התקשרות חוזרת

OAuth הוא המקום שבו טעויות קידוד מתייקרות, כי ספקים כן התאמת מחרוזת מדויקת על URIs להפניה מחדש. redirect_uri הוא כתובת URL מלאה המוטמעת כערך פרמטר בתוך כתובת URL אחרת - כך שהוא חייב להיות מקודד ברכיבים, בדיוק פעם אחת. תת-קודד אותו ואת ? או & בתוכו נשברת כתובת ה-URL של ההרשאה החיצונית. מקודד אותו פעמיים והספק משווה https%3A%2F%2F... נגד הרשום שלך https://... וחוזר redirect_uri_mismatch עם אפס פרטים נוספים. כאשר שגיאה זו מופיעה, פענח את כתובת האתר של ההרשאה בפועל מהדפדפן שלך 's שורת הכתובת והשווה את ה-redirect_uri תו אחר תו מול הערך הרשום של app's. חבר אותו ל- מפענח JWT לבדיקת האסימונים שחוזרים, ותוכל לנפות באגים בזרימת OAuth שלמה מבלי לעזוב את הדפדפן.

פענוח כתובות URL של Gnarly מיומנים וכותרות מפנה

יומני שרת וכותרות מפנה מלאות במרק מקודד באחוזים: %D0%9F%D1%80%D0%B8%D0%B2%D0%B5%D1%82 במפנה חיפוש, נתיבים מקודדים משולשים מתעבורת בוטים, מטענים מקודדים בבקשות חשודות. פענוח אלה הוא איך אתה מגלה מה באמת קרה - בין אם ה-404 המוזר הזה היה משתמש עם שאילתה קירילית או סקריפט שחיפש ../../etc/passwd מאחורי שלוש שכבות של קידוד זה גם בדיוק המצב שבו זווית הפרטיות חשובה ביותר: כתובות אתרים של יומן רישום מכילות באופן שגרתי אסימוני הפעלה וכתובות דואל. Decode them in a client-side tool, not on some random server that keeps its own logs.I wrote more about this workflow in the מדריך כלים לניפוי באגים ב-API.

בדיקת API עם תלתל

המעטפת והתלתל שלך יוצרים שדה מוקשים שני על גבי קידוד כתובת האתר. & רקע תהליך בבאש, ? מפעיל הרחבת גלוב ב-zsh - כך שכתובת URL לא מצוטטת ולא מקודדת נכשלת בדרכים מבלבלות עוד לפני שהיא מגיעה לרשת זרימת העבודה שלי: קודד כל ערך פרמטר בכלי, הרכיב את כתובת האתר, עטוף אותה במרכאות בודדות, ואז הפעל curl.When a API reports a 400 for a request that "looks right," I decode the exact URL from the verbose output (curl -v) כדי לראות מה באמת נשלח - יותר מפעם אחת הבאג היה המסוף שלי, לא ה-API שלי. curl's --data-urlencode דגל מטפל בקידוד עבור גופי POST, אבל עבור מחרוזות שאילתות GET אתה ' נמצאים בעיקר לבד, ומקודד אמין מנצח ניחוש.

שיתוף קישורים עם טקסט שאינו ASCII

מאמרי ויקיפדיה בשפות אחרות, מפות גוגל מקשרות עם שמות מקומות מקומיים, כתובות אתרים עם שבלולים בנגליים או ערביים - העתק אחד משורת הכתובת שלך וייתכן שתקבל את היפה יוניקוד צורה או קיר של %E0%A6%AC-סטייל בתים, בהתאם לדפדפן's מצב רוח. אפליקציות צ'אט ולקוחות דואל מסוימים חותכים או מעוותים את טופס Unicode הגולמי. קידוד כתובת האתר לפני השיתוף מייצר מחרוזת ASCII טהורה ששורדת כל שליח, רשימת תפוצה ומעבד Markdown I' ניסית. אם הולכים לכיוון השני, פענוח הופך קישור משותף בלתי קריא בחזרה למשהו שאדם יכול לאמת לפני לחיצה - שווה לעשות לפני שאתה מעביר כל דבר שהגיע ונראה כמו רעש קו.

encodeURIComponent לעומת encodeURI לעומת בריחה (): באיזה מהם כדאי להשתמש?

שלוש פונקציות, ברירת מחדל אחת נכונה. Here's ההשוואה הכנה:

	`encodeURIComponent()`	`encodeURI()`	`escape()`
מקודד	הכל חוץ מ `A-Z a-z 0-9 - . _ ~ ! ' ( ) *`	הכל למעט ללא הזמנה + כל התווים השמורים (`: / ? # [ ] @ ! $ & ' ( ) * + , ; =`)	הכל חוץ מ `A-Z a-z 0-9 @ * _ + - . /`
החלל הופך	`%20`	`%20`	`%20`
`&` ו `=`	מקודד (`%26`, `%3D`)	לא מקודד	מקודד
טיפול ביוניקוד	UTF-8 בתים נכונים	UTF-8 בתים נכונים	שבור - לא סטנדרטי `%uXXXX`
השתמש עבור	ערכי פרמטרים, מקטעי נתיב, כל דבר בתוך כתובת URL	כתובת URL מלאה שאתה עושה 't רוצה לבנות מחדש	שום דבר
סטטוס	סטנדרטי, מומלץ	סטנדרטי, נישה	הוצא משימוש

העמדה שלי, ו-I' ימות על הגבעה הזו: להשתמש encodeURIComponent לערכים, כמעט תמיד. המודל המנטלי פשוט - אם המחרוזת הולכת בתוך כתובת URL (ערך שאילתה, קטע נתיב, redirect_uri), it' הוא רכיב, והוא מקבל encodeURIComponent. המקרים שבהם encodeURI האם באמת צודק הם נדירים: יש לך כתובת URL מלאה, שכבר מובנית, המכילה רווחים או תווים שאינם ASCII, ואתה רוצה לחטא אותה מבלי לגעת במבנה שלה. That's אולי 5% משיחות הקידוד בעולם האמיתי. ו escape() פשוט לעולם לא להופיע בקוד שנכתב אחרי 2010 בערך - פלט ה-Unicode שלו הוא 't קידוד אחוז חוקי, וכל לינטר מודרני יסמן אותו בכל מקרה.

עוד ניואנס אחד: encodeURIComponent עלים ! ' ( ) * לא מקודדים מסיבות היסטוריות, למרות ש-RFC 3986 מפרט אותם כמפרידי משנה שמורים. עבור ממשקי API של OAuth וניתוח קפדני, ספריות מסוימות מוסיפות מעבר שני כדי לקודד גם את חמשת אלה. אם API בררן דוחה את הערכים שלך, זה ' זה מקום לחפש בו - וה מקודד כתובת URL's מצב רכיב מראה לך בדיוק אילו תווים הומרו כדי שתוכל להשוות.

שאלות נפוצות

מהו קידוד URL?

קידוד URL (אחוז קידוד) הוא המנגנון לייצוג תווים בכתובת URL שאחרת לא תהיה בטוחה או בעלת משמעות מבנית כל תו בעייתי מומר לבייטים UTF-8 שלו, וכל בית נכתב כסימן אחוז ואחריו שתי ספרות הקסדצימליות - רווח הופך ל% 20, אמפרסנד הופך ל% 26 הכללים מוגדרים בRFC 3986 הוא קיים מכיוון שכתובות URL מאפשרות רק ערכת תווים מוגבלת, ותווים כמו ? ו & יש עבודות לעשות בתוך מבנה כתובת האתר.

מדוע רווחים הופכים ל - % 20 לפעמים ו - + פעמים אחרות?

שני מפרטים שונים.RFC 3986, השולט בכתובות URL עצמן, מקודד רווח כ% 20. הפורמט המקודד של application/x-www-form המשמש את הגשת טפסי HTML, המוגדר בתקן ה - URL של WHATWG, מקודד רווח כ - +. שניהם תקפים בהקשר שלהם, וזו הסיבה ש - + במחרוזת שאילתה אינו חד משמעי התרגול הבטוח: תמיד לייצר% 20 עבור רווחים ו -% 2B עבור סימני פלוס מילוליים - כל מנתח מטפל בהם בצורה נכונה.

מה ההבדל בין encodeURI ל-encodeURIComponent?

encodeURIComponent מקודד כמעט הכל, כולל /, ?, &, ו =, מה שהופך אותו בטוח עבור ערכים בודדים הממוקמים בתוך כתובת URL. encodeURI משמר את התווים השמורים כך שכתובת URL מלאה שומרת על המבנה שלה. השתמש ב-encodeURIComponent עבור ערכי פרמטרים וקטעי נתיב - שזה כמעט כל מקרה בעולם האמיתי - וקודדURI רק בעת חיטוי כתובת URL מלאה מבלי לשנות אותה. שימוש ב-encodeURI על ערך המכיל & ישבור בשקט את מחרוזת השאילתה שלך.

כיצד אוכל לתקן כתובת URL מקודדת כפולה?

קידוד כפול מתרחש כאשר מחרוזת שכבר מקודדת מקודדת שוב - % 20 הופך ל - % 2520 מכיוון שה - % עצמו הופך ל - % 25. כדי לתקן אותה, פענח את המחרוזת שוב ושוב עד שלא יישארו רצפי % XX והפלט מפסיק להשתנות לאחר מכן מצא איזו שכבה של המערכת שלך מקודדת פעמיים - בדרך כלל הקוד שלך בתוספת פרוקסי, שירות הפניה מחדש או עטיפת קישור בדואל - והסר את אחד משלבי הקידוד הכלל: מקודד בדיוק פעם אחת, ברגע האחרון לפני שהערך נכנס לכתובת האתר.

האם זה בטוח לפענח כתובות אתרים בכלי מקוון?

רק אם הכלי פועל בצד הלקוח כתובות URL מכילות לעתים קרובות קודי OAuth, אסימונים לאיפוס סיסמה, מזהי הפעלה וכתובות דואר אלקטרוני כלי בצד השרת מקבל את כל זה ועשוי לשמור אותו ביומני גישה ללא הגבלת זמן.Toolz.dev URL Encoder/Decoder מבצע את כל ההמרה בדפדפן שלך עם JavaScript - אין נתונים מועברים לשום מקום, אותם תוכל לאמת בדפדפן שלך's כרטיסיית רשת עבור כל דבר המכיל אישורים או אסימונים, עיבוד בצד הלקוח צריך להיות בלתי ניתן למשא ומתן.

האם אני צריך לקודד את כל כתובת האתר או רק את הפרמטרים?

רק חלקי הנתונים - ערכי פרמטרים בודדים ומדי פעם, מקטעי נתיב. התווים המבניים של כתובת האתר עצמה (ה-:// אחרי הסכימה, ה-? התחלת השאילתה, ה-& בין פרמטרים) חייבים להישאר לא מקודדים או שכתובת האתר מפסיקה לעבוד. מקודד כל ערך בנפרד עם קידוד בסגנון רכיב, ואז הרכיב את כתובת האתר סביבם. קידוד כתובת URL מלאה מקצה לקצה נכון רק כאשר כתובת האתר הזו הופכת בעצמה לערך בתוך כתובת URL אחרת, כמו OAuth redirect_uri.

האם קידוד כתובת URL יכול להתמודד עם אימוג'י ותווים שאינם באנגלית?

כן - קידוד אחוזים מודרני פועל על UTF-8 בתים, כך שכל תו Unicode עובד תו של שני בתים כמו é הופך ל-% C3% A9, ואימוג'י של ארבעה בתים הופך לארבעה אחוזים רצפים, כגון% F0%9F%9A% 80. בעיות מתעוררות רק עם כלים מדור קודם או פונקציית JavaScript's escape() שהוצאה משימוש, המניחות קידודים של בתים בודדים ומייצרות פלט לא חוקי מקודד Toolz.dev מטפל ב-UTF-8 המלא בצורה נכונה בשני הכיוונים.

מדוע כתובת האתר שלי נשברת כאשר פרמטר מכיל אמפרסנד?

כי & הוא המפריד בין פרמטרים אם ערך מכיל אמפרסנד גולמי - נגיד utm_campaign=black&friday - השרת מנתח אותו כפרמטר בשם utm_campaign עם ערך שחור, בתוספת פרמטר שני בשם friday.לא מועלית שגיאה; הנתונים שלך פשוט שגויים בשקט.Code את האמפרסנד כ-% 26 בתוך הערך והפרמטר מגיע שלם זהו אחד מבאגי ה-URL הנפוצים והפחות גלויים.

מה המשמעות של% 2F בכתובת URL?

% 2F הוא ה-forward slash המקודד באחוזים.You' יראה זאת כאשר ערך שבמקרה מכיל slash - נתיב קובץ, תאריך כמו 07/07, או כתובת URL מקוננת - מקודד כהלכה לפני שהוא ממוקם בפרמטר שאילתה או בקטע נתיב. שים לב ששרתים ופרוקסי מסוימים (Apache, גרסאות ישנות יותר של Tomcat, שערי API שונים) דוחים או מפענחים בשקט את% 2F בנתיב מסיבות אבטחה, כך שאם בקשה עם קו נטוי מקודד מחזירה 404, התצורה בצד השרת היא בדרך כלל האשם, לא הקידוד שלך.

כיצד אוכל לקודד כתובת URL ב-Python, PHP או בשורת הפקודה?

Python: urllib.parse.quote () עבור מקטעי נתיב ו-quote_plus () עבור ערכי שאילתה בסגנון טופס. PHP: rawurlencode () מייצר פלט RFC 3986 עם% 20 עבור רווחים, בעוד ש-urlencode () מייצר פלט בסגנון טופס עם +. שורת פקודה: jq -rR @uri או curl's --data-urlencode flag. כל אחד מאלה תואם להתנהגות בסגנון הרכיב של כלי זה, כך שתוכל ליצור אב טיפוס של הקידוד כאן ולאמת שהקוד שלך מייצר פלט זהה בתים.

עוטף

קידוד כתובת אתר הוא מיומנות קטנה עם תמורה גדולה מדי. ברגע שאתה יכול לקרוא %C3%A9 בתור é ונקודה %2520 כריח קידוד כפול, קטגוריה שלמה של " זה עובד על המכונה שלי" באגים - זרימות OAuth שבורות, קמפיינים פנטומים של UTM, ממשקי API הדוחים בקשות בעלות מראה סביר לחלוטין - הופכים ממסתוריים למכניים הכללים מתאימים לכרטיס אינדקס: תווים לא שמורים עוברים, כל השאר הופך ל-UTF-8 בתים כ-%HH, ערכי קידוד לא מבנה, ומקודדים בדיוק פעם אחת.

שמור את מקודד/מפענח כתובת URL מסומן ליד אחיו - ה ממיר Base64 עבור ערכת הקידוד האחרת אתה ' תיפגש בכל כותרת אישור (I'כתבתי מלא מדריך קידוד Base64 על מתי להשתמש באיזה), ה מקודד/מפענח ישויות HTML עבור שכבת הקידוד השלישית שתוכן אינטרנט אוהב לערום למעלה (ה מדריך ישות HTML מכסה את גרסת הבריחה הכפולה של אותה מלכודת שבה פגעתי %2520), וה פורמט JSON לכל מה שכתובת האתר המפוענחת מצביעה עליו.

ואם אתה ' מרכיבים ערכת ניפוי באגים רחבה יותר מבוססת דפדפן, ה מדריך כלי קידוד עובר על איך הכלים האלה משתלבים יחד בזרימת עבודה אמיתית הכל בToolz.dev פועל בצד הלקוח, לא עולה כלום, ועושה עבודה אחת טוב.That's כל המגרש - אותו אחד שהלוואי שמישהו היה עושה לי לפני שביליתי יומיים על% 25 אחד שלא במקום.

Frequently Asked Questions

URL encoding (percent-encoding) is the mechanism for representing characters in a URL that would otherwise be unsafe or structurally meaningful. Each problematic character is converted to its UTF-8 bytes, and each byte is written as a percent sign followed by two hexadecimal digits — a space becomes %20, an ampersand becomes %26. The rules are defined in RFC 3986. It exists because URLs only permit a limited character set, and characters like ? and & have jobs to do inside URL structure.

Command Palette