הפסדתי שעה פעם אחת למחרוזת שאילתה. webhook של צד שלישי נשלח filter[status]=open&filter[assignee]=me, המטפל שלי קרא filter כמחרוזת שטוחה, ולא הצלחתי להבין מדוע כל בקשה עברה ללא סינון. ברגע שהדבקתי את כתובת האתר הגולמית במנתח מחרוזת שאילתות וראיתי שהיא נפתרת לאובייקט מקונן, הבאג היה ברור: השולח השתמש בסימון סוגר והמנתח שלי לא. מדריך זה מכסה כיצד אני משתמש ב מנתח מחרוזת שאילתה ב-Toolz.dev, מהם בעצם החלקים המסובכים של מחרוזות שאילתות, ומדוע אותו מפתח מקודד בשתי דרכים שונות יכול לשבור בשקט אינטגרציה.
TL;DR: מחרוזת שאילתה היא החלק של כתובת URL אחרי סימן השאלה הנושא פרמטרים כצמדי מפתח-ערך מנתח מחרוזת שאילתה ממיר את זה ל-JSON מובנה, מפענח קידוד אחוז ומטפל במפתחות ומערכי סוגריים חוזרים, ויכול לבנות מחרוזת שאילתה מקודדת כהלכה בחזרה מ-JSON. ה מנתח מחרוזת שאילתה עושה את שני הכיוונים בדפדפן שלך, כך שתוכל לבדוק כתובת URL מבולגנת או להרכיב כתובת נקייה מבלי לעזוב את הדף.
מהי מחרוזת שאילתה?
מחרוזת שאילתה היא הקטע של כתובת URL שמתחיל אחרי סימן השאלה הראשון ומסתיים בפרגמנט, החלק שאחרי hash. זה נושא פרמטרים כמו key=value זוגות שהצטרפו אליהם אמפרסנדים, אז ?q=json&page=2 מעביר שני פרמטרים שרתים וקוד לקוח קוראים את אלה כדי לסנן חיפוש, לעקוב אחר מסע פרסום, לעגל רשימה או לשאת מצב בין דפים. הכללים הגנריים למה שהוא ואינו חוקי באותו רכיב מגיעים RFC 3986, תקן URI, והכללים הספציפיים שדפדפנים פועלים לפיהם עבור פרמטרים בסגנון טופס מגיעים מה- תקן כתובת URL של WHATWG.
המלכוד הוא ש-RFC 3986 מגדיר את התחביר של רכיב השאילתה אבל לא את המשמעות שלו. הוא אומר אילו תווים מותרים וכיצד הם חייבים להיות מקודדים באחוזים, אבל הוא לא אומר דבר על איך key=value זוגות ממפים למבנה נתונים הפרשנות הזו עברה בירושה מהגשת טפסי HTML, ופלטפורמות שונות הרחיבו אותה בדרכים לא תואמות. זו הסיבה שאותה מחרוזת שאילתה יכולה להיות משמעות מעט שונה לקצה האחורי של PHP, לבקר Rails ולחזית JavaScript, ומדוע מנתח צריך להבהיר את המוסכמות שלו.
כל מפתח וערך במחרוזת שאילתה מקודדים ב-URL כך שתווים שמורים שורדים. רווח הופך %20 או סימן פלוס, אמפרסנד בתוך ערך הופך %26 אז זה לא טועה כמפריד, ולוכסן הופך %2F. ניתוח פירושו פיצול הזוגות ולאחר מכן פענוח כל צד, ובניית אמצעי קידוד כל צד והצטרפות לזוגות. קבל את הקידוד שגוי בכל כיוון והערכים מושחתים בשקט.
מה עושה למעשה מנתח מחרוזת שאילתות?
מנתח לוקח כתובת URL או מחרוזת שאילתה חשופה והופך אותה לנתונים מובנים וניתנים לקריאה בדרך הוא מפשיט הכל עד וכולל סימן השאלה, מתעלם מהקטע שאחרי ה-hash, מפצל את הזוגות, מפענח כל מפתח וערך, ומחליט כיצד לייצג מפתחות חוזרים ומפתחות בסוגריים הפלט הוא אובייקט JSON שאתה יכול לקרוא ולהעתיק, בתוספת טבלה שטוחה של כל זוג מפוענח כך שכפולים וערכים ריקים ברורים.
על Toolz.dev הכלי פועל בשני כיוונים במצב ניתוח אתה מדביק כתובת URL מלאה או רק מחרוזת השאילתה שלה ומקבל את JSON ואת טבלת הפרמטרים במצב build אתה מדביק אובייקט JSON ומקבל מחרוזת שאילתה מקודדת כהלכה, עם בחירה של אופן ייצוג המערכים טען את המדגם ותוכל לצפות בכתובת URL אמיתית עם קטע, מערך בסגנון חוזר ומרחב מקודד לפתור לתוך JSON נקי, ואז לבנות אותו מחדש.
הסיבה להשתמש במנתח ייעודי במקום לגלגל את כתובת האתר היא שמחרוזות שאילתות מסתירות את המבנה שלהן. כתובת URL ארוכה עם תווים מקודדים, מקשים חוזרים וסימון סוגריים כמעט בלתי אפשרי לקריאה נכונה על ידי סריקתו, והחלקים שהכי קשה לקרוא, הקידוד והכפילויות, הם בדיוק החלקים שגורמים לבאגים. לראות את הטבלה המפוענחת ליד ה-JSON מסיר את הניחוש.
כיצד מטפלים במפתחות חוזרים?
אותו מפתח יכול להופיע באופן חוקי יותר מפעם אחת במחרוזת שאילתה, כמו ב tags=react&tags=laravel, ואין דרך אחת נכונה לפרש את זה, וזה השורש של הרבה בלבול. מערכות שונות פותרות כפילויות בצורה שונה, אז מנתח צריך לתת לך לבחור.
המוסכמה הנפוצה ביותר, וברירת המחדל בכלי Toolz.dev, היא לאסוף מפתחות חוזרים למערך, אז tags=react&tags=laravel הופך {"tags":["react","laravel"]}. זה תואם את האופן שבו הדפדפן 's משלו URLSearchParams.getAll חושף את הערכים וכיצד מתנהגים רוב הקצוות האחוריים המודרניים. אבל מסגרות מסוימות שומרות רק על ההתרחשות הראשונה וחלקן שומרות רק על האחרונה, כך שהכלי מציע אפשרויות שמירה ראשונה ואחרונה גם כן. כאשר אתה מאתר באגים באינטגרציה, התאמת ה-parser's התנהגות למערכת שייצרה או צורכת את כתובת האתר היא מה שהופך את ה-JSON למשמעותי.
עמימות זו אינה אקדמית בעיית אבטחה ונכונות קלאסית הנקראת זיהום פרמטר HTTP קיימת בדיוק בגלל ששתי מערכות בנתיב בקשה יכולות לפתור id=1&id=2 אחרת, אחד רואה 1 והשני רואה 2. היכולת לראות, במפורש, כיצד מנתח נתון פותר כפילויות היא הדרך המהירה ביותר לנמק לגבי סוג הבאג הזה.
מה המשמעות של סוגריים כמו תגיות[] או פילטר[צבע]?
סימון סוגר הוא מוסכמה לקידוד מערכים ואובייקטים מקוננים בתוך מחרוזת שאילתה שטוחה, וזה המקום שבו המנתחים לא מסכימים ביותר. סוגר ריק נגרר מסמן מערך, אז tags[]=react&tags[]=laravel בונה {"tags":["react","laravel"]}. סוגר בשם מסמן אובייקט מקונן, אז filter[color]=red&filter[size]=l בונה {"filter":{"color":"red","size":"l"}}. סוגריים יכולים לקנן, אז a[b][c]=1 בונה {"a":{"b":{"c":"1"}}}.
תחביר זה מגיע מהאופן שבו PHP ו-Ruby on Rails מסדרות נתוני טופס, וספריות JavaScript רבות כגון qs עקוב אחריו זה לא חלק מכל תקן URL ליבה, וזו בדיוק הסיבה שפשוט URLSearchParams בדפדפן לא ירחיב אותו, נותן לך מפתח מילולי של tags[] במקום מערך מנתח Toolz.dev מבין את הקונבנציה ומרחיב אותה למבנה התואם, והוא מאפשר לך לכבות את ההתנהגות הזו כאשר אתה רוצה את המפתחות המילוליים במקום זאת.
הנה איך המוסכמות העיקריות מסתדרות, גם בעת ניתוח וגם בעת בנייה:
| סגנון מערך | מקודד כ | מנתח ל | נפוץ ב |
|---|---|---|---|
| מפתח חוזר | tags=a&tags=b |
["a","b"] |
דפדפנים, רוב הקצוות האחוריים |
| סוגר ריק | tags[]=a&tags[]=b |
["a","b"] |
PHP, Rails, ספריית qs |
| סוגר אינדקס | tags[0]=a&tags[1]=b |
["a","b"] |
ספריית Qs, נתונים שהוזמנו |
| פסיק מצטרף | tags=a,b |
מחרוזת אחת לפיצול | כמה ממשקי API, כתובות URL קומפקטיות |
כאשר אתה בונה מחרוזת שאילתה עם הכלי, אתה בוחר איזה מהם לפלוט, כך שהפלט תואם לכל מה שהמערכת המקבלת מצפה. כאשר אתה מנתח, הכלי מזהה עבורך מקשים חוזרים וסימון סוגריים, וערכים המחוברים לפסיק נשארים כמחרוזת בודדת מכיוון שרק אתה יודע אם פסיק הוא מפריד או חלק מהנתונים.
מדוע שלטי פלוס הופכים למרחבים?
במחרוזת השאילתה של כתובת URL, רווח מילולי מקודד לעתים קרובות מאוד כסימן פלוס ולא %20. זהו כלל שירש מה- application/x-www-form-urlencoded פורמט שבו משתמשים טפסי HTML, וה- תקן כתובת URL של WHATWG מקודד אותו: בעת ניתוח נתונים מקודדים בטופס, א + מפוענח למרחב. כך q=json+parser צריך לנתח ל json parser, והכלי Toolz.dev עושה זאת כברירת מחדל.
העדינות היא שכלל זה חל על רכיב השאילתה, לא על הנתיב. א + בקטע נתיב יש פלוס מילולי. ומדי פעם הנתונים שלך באמת מכילים סימני פלוס שצריך לשמר, כגון מספר טלפון או חיפוש C++. עבור אותם מקרים לכלי יש מתג לכיבוי פלוס-כמרחב, כך שהפלוס שורד את הנסיעה הלוך ושוב. זה סוג הפרטים שמטרה כללית מקודד URL לא יחליט עבורך, כי הוא לא יודע אם הוא מסתכל על שאילתה או נתיב.
ביצוע זה נכון חשוב גם בעת הבנייה. כאשר הכלי מקודד ערך, הוא מקודד באחוזים תווים שמורים וכברירת מחדל משתמש בפלוס עבור רווחים בסגנון מקודד צורה, כך שהמחרוזת שהוא מייצר היא כזו שדפדפנים וקצוות אחוריים יפענחו את הדרך אליה התכוונת.
במה זה שונה ממנתח כתובות אתרים מלא?
מנתח מחרוזת שאילתות ומנתח כתובות URL מלא חופפים אך עונים על שאלות שונות, ובאמצעות הנכון שומר שלב מנתח כתובות אתרים שובר קישור שלם לרכיבים שלו, הסכימה, המארח, היציאה, הנתיב, השאילתה והפרגמנט, וזה מה שאתה רוצה כשאתה מאתר באגים לאן הולכת בקשה או מדוע הפניה מחדש או בדיקת CORS מתנהגים בצורה מוזרה מנתח מחרוזת שאילתות מתמקד בשאילתה בלבד והופך אותה ל-JSON מובנה וניתן לעריכה, כולל מערכים ומפתחות מקוננים, ויכול לבנות את השאילתה בחזרה.
ה מנתח כתובת URL על Toolz.dev הוא הכלי לאנטומיה: תן לו קישור והוא מראה לך את ההבחנה מארח מול מקור, יציאת ברירת המחדל, ואת החלקים של הנתיב מנתח מחרוזת השאילתות הוא הכלי לעבודה עם פרמטרים: תן לו את אותו קישור והוא נותן לך את הפרמטרים כמו JSON אתה יכול לערוך, ולאחר מכן בונה מחדש מחרוזת שאילתה מהעריכות שלך בפועל אני משתמש בהם יחד, מנתח כתובת האתר כדי להבין קישור ומנתח מחרוזת השאילתות כדי לשנות את הפרמטרים שלו, ואם אני מרכיב קישור מסע פרסום אני מושיט יד ל בונה UTM במקום זאת, שהוא בונה מחרוזות שאילתות המתמחה בתגי ניתוח.
מתי אני בעצם מושיט יד לזה?
התשובה הכנה היא בכל פעם שכתובת URL עושה יותר מאשר הצבעה על דף. אני משתמש בו כדי לנפות באגים ב-webhooks והפניות מחדש של OAuth, כאשר הפרמטרים נושאים את כל המטען וערך אחד מקודד שגוי שובר את הזרימה. אני משתמש בו כדי לקרוא את פרמטרי המעקב בקישור שיווקי כדי שאוכל לראות בדיוק מה עובר מסע פרסום. אני משתמש בו כדי להמיר מחרוזת שאילתה שעמית שהודבק בצ'אט ל-JSON אני יכול להיכנס למתקן בדיקה, וכדי לעשות את ההיפך, להפוך אובייקט קטן למחרוזת שאילתה לבקשה ידנית מהירה.
דוגמה עובדת הופכת את התמורה לקונקרטית. ספק OAuth מפנה חזרה לאפליקציה שלך עם משהו כמו ?code=abc123&state=xyz789&scope=read%20write&error=. מודבק במנתח, שמתפזר לאובייקט נקי: code ו state כערכים המילוליים שלהם, scope מפוענח ל read write בגלל %20 הוא מרחב, ו error כמחרוזת ריקה ולא כמפתח חסר, מה שאומר לך שהספק שלח את הפרמטר אבל השאיר אותו ריק. כשקוראים את זה מכתובת האתר הגולמית בעין, סביר להניח שתפספס את הרווח המקודד scope וקרא לא נכון את הריק error, ושני אלה הם בדיוק הפרטים שמחליטים אם המטפל שלך בהתקשרות חוזרת מסתעף בצורה נכונה. לראות את הטבלה המפוענחת מסיר את העמימות, ואם אז תצטרך לשחזר את הבקשה, מצב הבנייה הופך את האובייקט הערוך שלך בחזרה לכתובת URL חוקית להתקשרות חוזרת בשלב אחד.
מכיוון שכל כך הרבה מהעבודה הזו כוללת כתובות אתרים הנושאות אסימונים, ערכים חתומים ומזהי מעקב, ביצוע זה בכלי שפועל כולו בענייני הדפדפן שלך. שום דבר שאתה מדביק לא מועבר, נרשם או מאוחסן, והכלי ממשיך לעבוד עם הרשת כבוי, כך שתוכל לבדוק בבטחה כתובת URL חתומה להתקשרות חוזרת מהייצור ולא עותק מחוטא. אני עושה את המקרה הרחב יותר לשמירה על סוג זה של צד לקוח בעבודה פרטיות נתונים בכלים מקוונים מדריך, והמנתח הזה יושב לצד כלי השירות האחרים לקישור ולטקסט שתיארתי ב- ערכת כלים למפתחי אינטרנט. אם חלק מהעבודה שלך הופך קלט מבולגן ל-slugs נקי ולמזהים, ה- Slug מחולל הוא בן לוויה טבעי לצד הפלט של עבודת כתובת האתר.
שאלות נפוצות
מהי מחרוזת שאילתה?
מחרוזת שאילתה היא החלק של כתובת URL אחרי סימן השאלה הנושא פרמטרים כצמדי מפתח-ערך שמצטרפים אליהם אמפרסנדים, כגון ?q=json&page=2. שרתים וקוד לקוח קוראים אותו כדי לסנן תוצאות, לעקוב אחר מסעות פרסום או לעבור מצב כל מפתח וערך מקודדים ב-URL כך שרווחים ותווים שמורים שורדים, והפרגמנט לאחר hash אינו חלק ממנו.
כיצד מטפלים במפתחות חוזרים בניתוח?
כברירת מחדל מפתח שמופיע יותר מפעם אחת משולב למערך, אז תגיות=react&tags=laravel מנתח ל-{"tags":["react","laravel"]}. אתה יכול לעבור כדי לשמור רק את הערך הראשון או רק את הערך האחרון במקום זאת, מכיוון שקצוות אחוריים שונים פותרים כפילויות בצורה שונה ואתה רוצה שה-JSON יתאים למערכת שאליה אתה מכוון.
מה המשמעות של סוגריים כמו תגיות[] או פילטר[צבע]?
סימון סוגר מקודד מערכים ואובייקטים מקוננים בתוך מחרוזת שאילתה שטוחה. tags[]=react&tags[]=laravel בונה מערך, ומסנן[color]=red&filter[size]=l בונה את האובייקט המקונן {"filter":{"color":"red","size":"l"}}. זה נפוץ בספריות PHP, Rails וטפסים, כך שהנתח מרחיב אותו למבנה התואם, ותוכל לכבות את זה כדי לשמור על המפתחות המילוליים.
מדוע סימן פלוס הופך למרחב?
במחרוזת השאילתה של כתובת URL, רווח מילולי מקודד לעתים קרובות כסימן פלוס, כלל שעבר בירושה מהגשת טופס HTML, כך שהמנתח ממיר + בחזרה לרווח כברירת מחדל אם הנתונים שלך מכילים סימני פלוס אמיתיים שיש לשמור, כגון C++ או מספר טלפון, כבה את האפשרות פלוס כמרחב והפלוס נשמר.
האם אני יכול לבנות מחרוזת שאילתה מ-JSON?
כן. עבור למצב בנייה והדבק אובייקט JSON של צמדי מפתח-ערך. אחוז הכלי מקודד כל מפתח וערך ומצטרף אליהם עם אמפרסנדים, ותוכל לבחור כיצד מקודדים מערכים: מפתחות חוזרים, סוגריים ריקים, סוגריים באינדקס או רשימה מופרדת בפסיקים, כך שהפלט תואם לכל מה שהמערכת המקבלת מצפה.
מה ההבדל בין זה לבין מנתח URL מלא?
מנתח URL מלא מפרק כתובת URL שלמה לסכימה, מארח, יציאה, נתיב, שאילתה ופרגמנט מנתח מחרוזת שאילתות מתמקד בשאילתה בלבד, הופך אותה ל-JSON מובנה הניתן לעריכה כולל מערכים ומפתחות מקוננים, ויכול לבנות את השאילתה בחזרה השתמש במנתח ה-URL כדי לבדוק קישור, ובכלי זה כדי לקרוא או לשנות את הפרמטרים שלו.
האם הוא מטפל בכתובת URL מלאה או רק בחלק השאילתה?
שניהם אם אתה מדביק כתובת URL מלאה, המנתח מוריד הכל עד וכולל סימן השאלה ומתעלם מהקטע לאחר ה-hash, כך שאתה מקבל רק את הפרמטרים. אם אתה מדביק מחרוזת שאילתה חשופה ללא סימן שאלה, היא מנותחת כפי שהיא, וזה שימושי כאשר העתקת רק את הפרמטרים.
האם כתובת האתר שלי נשלחת לכל מקום?
מס 'ניתוח, פענוח, וקידוד כל לרוץ כמו JavaScript בדפדפן שלך, כך שום דבר לא מועבר, נרשם, או מאוחסן אתה יכול לאשר את זה על ידי צפייה בכרטיסייה הרשת בזמן שאתה מנתח כתובת URL, או על ידי ניתוק מהאינטרנט, כי הכלי ממשיך לעבוד במצב לא מקוון לאחר הדף נטען.
בדוק או הרכיב פרמטרים עם החינם מנתח מחרוזת שאילתה. הוא מנתח כתובת URL לתוך JSON ובונה מחרוזת שאילתה בחזרה, מטפל במפתחות חוזרים, מערכי סוגריים וקידוד, לחלוטין בדפדפן שלך.
