איבדתי את רוב אחר הצהריים פעם אחת לכמת חמדן יחיד. כתבתי מפת הפניה להעברת וורדפרס - כמה מאות כתובות URL ישנות שזקוקות לשכתוב לשבלולים חדשים - והיה לי regex שהיה אמור ללכוד את השבלול הנגרר מכל נתיב זה עבד על שלוש כתובות האתרים שבדקתי בראש זה לא עבד על הרביעי, שהיו לו שני מקטעי נתיב, כי .* בלע בעליזות את החתך הראשון והכל אחריו הכלל הפנה בשקט חצי מהאתר למקום הלא נכון, וגיליתי מקורא, לא מהבדיקה שלי, כי שלי "testing" בהה בדפוס ובטח בו.
זו בעיית הליבה עם ביטויים רגולריים: הם כתיבה בלבד עד שאתה מפעיל אותם נגד משהו. דפוס נקרא כסביר עד לרגע שבו קלט אמיתי מוכיח שהוא שגוי, ומצבי הכשל שקטים. regex שלא תואם לשום דבר לא זורק שגיאה. regex שמתאים יותר מדי זורק לא שגיאה. regex עם קבוצת לכידה שגויה בעדינות מוסר לך את המחרוזת הלא נכונה וממשיך הלאה. הדרך היחידה לדעת דפוס עושה את מה שאתה חושב היא להזין אותו בטקסט המבולגן, עמוס הקצה שהוא באמת יראה ו תראה במה שהוא תופס.
א בודק regex סוגר את הפער הזה אתה שם את התבנית שלך בתיבה אחת, את הטקסט לדוגמה שלך בתיבה אחרת, וכל התאמה נדלקת במקום - כאשר קבוצות הלכידה מפורקות כך שתוכל לראות בדיוק איזו פרוסה של המחרוזת נחתה בקבוצה 1 לעומת קבוצה 2. זה שבניתי עבור Toolz.dev פועל על הדפדפן 's native RegExp מנוע, אותו אחד שקוד ה-JavaScript וה-TypeScript שלך משתמש בו, אז מה שאתה רואה בבוחן הוא מה שאתה מקבל בייצור. אין קירוב, אין "קרוב מספיק."
מדריך זה מכסה כיצד להשתמש בבוחן כדי לנפות באגים בתבניות במהירות, מה כל דגל עושה בפועל, כיצד קבוצות לכידה וקבוצות עם שם מופיעות בפלט, ואת ה-gotchas הספציפיים ל-JavaScript שמכשילים אנשים המגיעים מ-Python או PCRE.
TL;DR: הדבק את הדפוס שלך לתוך Toolz.dev Regex Tester (אין צורך ב-slashes), החלף את דגלי g/i/m/s/u/y, ושחרר את טקסט הבדיקה שלך למטה. התאמות מדגישות בשידור חי עם צבעים מתחלפים, כל קבוצת לכידה ממוספרת ושמה רשומה לפי התאמה, ושגיאות תחביר מציגות את המנוע 's הודעה מדויקת. הוא משתמש במנוע JavaScript RegExp האמיתי, מריץ 100% בצד הלקוח כך שיומנים רגישים לעולם אינם מעלים, ומשתלב עם בונה רגקס להרכבת דפוסים מאפס.
איך אתה בודק Regex מבלי להפעיל את כל התוכנית שלך?
הדרך האיטית לנפות באגים ב-regex היא הלולאה שרובנו מתחילים בה: ערוך את התבנית בקוד שלך, הפעל את התוכנית, קרא את הפלט, נחש מה השתבש, חזור על כל איטרציה עולה הפעלת תוכנית מלאה, והמשוב הוא עקיף - אתה רואה את תוצאה של המשחק, לא המשחק עצמו.
בודק ממוטט את הלולאה הזו לכלום אתה מדביק את התבנית, מדביק טקסט מייצג ורואה את ההתאמות מיד כאשר אתה משנה תו אחד בתבנית, הדגשים מתעדכנים זה מהדק את המשוב לנקודה שבה אתה יכול לחקור- נסה א + איפה שהיה לך א *, הוסף גבול מילה, הפוך קבוצה ללא לכידה - וצפה באפקט נוחת בזמן אמת במקום לדמיין אותו.
משמעת המפתח היא שימוש אמיתי טקסט בדיקה, לא הדוגמה הנקייה בראש שלך לכתובת האתר ששברה את מפת ההפניה שלי היו שני מקטעי נתיב; למקרה המבחן הנפשי שלי היה אחד. אם הייתי מדביק את הרשימה האמיתית של כתובות URL ישנות לתוך בודק, ההתאמה החמדנית הייתה שגויה בעליל בשורה ארבע. תפוס את שורות היומן בפועל, את כניסות המשתמש בפועל, את נתיבי הקבצים בפועל - כולל המכוערים - ותן לבוחן להראות לך היכן הדפוס מתפרק לפני שהמשתמשים שלך עושים זאת.
מה בעצם משתנים דגלי Regex?
דגלים משנים את אופן יישום הדפוס כולו, ואי הבנתם עומדת מאחורי נתח גדול של "למה 't this work" moments. ה טסטר חושף את כל ששת דגלי JavaScript כמתגים כדי שתוכל להעיף אחד ולצפות בשינוי התוצאה.
g - גלובלי. בלעדיו, ההתאמה נעצרת במכה הראשונה. איתו, המנוע מוצא כל התאמה בטקסט. בבודק, גלובלי פועל כברירת מחדל כי כמעט תמיד אתה רוצה לראות את כל ההתאמות; כבה אותו כדי לאשר איך נראית שיחה במשחק בודד String.match ללא g היה חוזר.
אני - התעלם ממקרה. הופך את כל הדפוס ללא רגיש למקרה, אז error גפרורים Error ו ERROR. ישר, והדגל הנפוץ ביותר אחרי g.
m - multiline. זה לא מובן באופן נרחב. זה כן לא לעשות . מעברי קו צולבים זה משנה מה ^ ו $ עוגן ל: עם m, הם תואמים בהתחלה ובסוף של כל אחד מהם קו, לא רק ההתחלה והסוף של כל המחרוזת. אם אתה ' מתאימים שורה אחר שורה ביומן, אתה רוצה את זה.
s - dotAll. זה הדגל שעושה . התאם דמויות בשורה החדשה. בלי זה, . תואם לכל דמות מלבד הפסקת קו, וזו הסיבה שדפוס שנועד להשתרע על מספר קווים נעצר לעתים קרובות בשקט בראשון. אם ההתאמה שלך צריכה לחצות את גבולות הקו, s הוא מה שאתה צריך - לא m.
u - יוניקוד. מאפשר מצב Unicode מלא, מה שהופך \u{...} בורח מהעבודה, מתייחס לזוגות פונדקאים כנקודות קוד בודדות, ועושה שיעורי תווים כמו \p{Letter} זמין. חשוב כאשר הטקסט שלך כולל אימוג'י או סקריפטים שאינם לטיניים.
y - דביק. מעגן כל ניסיון התאמה למיקום המדויק של lastIndex, אז התאמה מצליחה רק אם היא מתחילה בדיוק שם. It's דגל נישה המשמש באסימונים ומנתחים; רוב העבודה היומיומית אף פעם לא נוגעת בזה.
הבלבול שעולה הכי הרבה זמן הוא m לעומת s. אנשים מגיעים ל-multiline כשהם מתכוונים ל-dotAll. אם הנקודה שלך היא 't חוצה קווים, אתה צריך s. אם העוגנים שלך הם 't להכות גבולות קו, אתה צריך m. הם פותרים בעיות שונות ולעתים קרובות משתמשים בהם יחד.
כיצד מוצגות קבוצות לכידה בפלט?
סוגריים בתבנית עושים שתי עבודות: הם מקבצים תת-דפוסים עבור מכמים או חילופין, והם ללכוד הפרוסה המותאמת לחילוץ. When you're using a regex to pull data out of text - a date's year and month, a log line's timestamp and level - the capture groups are the all point, and getting them wrong is the most common source of "the pattern commats but I got the wring." הלא נכון;
ה טסטר מפרט כל התאמה עם קבוצות הלכידה שלה שפרוצות מתחתיה. קבוצה 1 היא תת-התבנית בסוגריים הראשונה, קבוצה 2 השנייה, וכן הלאה, כל אחת מוצגת עם הטקסט המדויק שהיא לכדה עבור אותה התאמה. זה הופך באגים בגבול הקבוצה לברורים: אם קבוצה 1 תפסה יותר ממה שציפית, אתה יכול לראות אותה ולמשוך את הסוגריים פנימה.
קבוצות שמות מקבלות את אותו יחס. When you write (?<year>\d{4})-(?<month>\d{2}), הבוחן מראה את הלכידות לפי שם - <year> ו <month>- לצד המקבילות הממוספרות שלהם, כך שתוכל לאשר את מפת השמות לפרוסות שאתה מתכוון לפני שאתה מסתמך עליהן match.groups.year בקוד קבוצות שמות הופכות דפוסים לתיעוד עצמי ולקוד לקריאה יותר, ולראות אותם נפתרים בצורה נכונה בבוחן היא הדרך המהירה ביותר לסמוך עליהם.
מלכודת קשורה שהבוחן משטח: קבוצה שמשתתפת בתבנית אבל did't התאמה בניסיון נתון מראה כ-"no match" ולא מחרוזת ריקה ההבחנה הזו חשובה, כי ב-JavaScript קבוצה כזו היא undefined, וקוד שמניח את זה's תמיד תזרוק מחרוזת. לראות את זה מסומן בבוחן אומר לך לשמור על הגישה הזו.
איזה טעם של Regex זה, ולמה זה משנה?
ביטויים רגולריים אינם שפה אחת. the pattern that works in Python's re מודול יכול להתנהג אחרת - או לזרוק - ב-JavaScript, ולהיפך. זֶה טסטר משתמש ב-JavaScript (ECMAScript) מנוע מובנה בדפדפן שלך, שהוא בייט-עבור-בייט אותו מנוע Node.js פועל. אז אם אתה ' כותבים JavaScript, TypeScript או קוד Node, התוצאות כאן הן בדיוק מה שהקוד שלך יעשה.
הדיוק הזה חותך לשני הכיוונים. אם תעתיק דפוס מתשובה של Stack Overflow שנכתבה עבור PCRE (PHP, וה- preg_ פונקציות שאני משתמש בהן ללא הרף בעבודה של וורדפרס) או עבור Python, כמה תכונות זכו 't לתרגם. JavaScript באופן היסטורי חסרה קביעות מבט מאחורי, השיגה אותן לאחרונה יחסית, ועדיין מטפלת בכמה בריחות מאפיינים של Unicode בצורה שונה. Possessive quantimifiers and atomic groups from PCRE don' t exist in JavaScript at all.Recursion - תכונת PCRE להתאמת מבנים מקוננים - אין מקבילה ל-JavaScript.
התוצאה המעשית: מבחן בטעם you'll לפרוס פנימה בודק שמיישם נאמנה מנוע אחד שימושי יותר מאחד שמיישם ממוצע מטושטש של כולם, כי " זה עבד בבודק" צריך להתכוון " זה יעבוד בקוד שלי." עבור עבודת PHP ו-WordPress אני שומר את ההבדלים בחשבון ומאמת את צד השרת בנפרד; לכל דבר JavaScript, הבוחן הזה הוא מקור האמת ערכת הכלים הרחבה יותר עבור סוג זה של אימות מודע לשפה מכוסה ב מדריך כלי קידוד.
מהם השימושים היומיומיים עבור בודק Regex?
בניית וניפוי באגים דפוסי אימות
שדות דואר אלקטרוני, מספרי טלפון, מיקודים, שבלולים, מחרוזות גרסאות סמנטיות - כל טופס מאמת משהו, והאימות הוא בדרך כלל regex. הבוחן מאפשר לך לזרוק את המקרים המביכים על הדפוס שלך לפני שהוא נשלח: האימייל עם תג פלוס כתובת, מספר הטלפון עם סיומת, מחרוזת הגרסה כמו 1.10.0 שדפוס נאיבי חותך הדבק עמודה של ערכים אמיתיים וצפה אילו מהם לא מצליחים להתאים.
חילוץ נתונים מיומנים
יומני שרת, יומני יישומים ויצוא CSV הם טקסט מובנה למחצה, ו-regex הוא הדרך שבה אתה שולף מהם שדות. קבוצות לכידה תופסות את חותמת הזמן, הרמה, מזהה הבקשה. הבוחן #39; פירוט קבוצות לכל התאמה הוא בדיוק התצוגה שאתה צריך כאן - הדבק תריסר שורות יומן אמיתיות, ואשר כל שדה נוחת בקבוצה הנכונה על פני כולן, לא רק בשורה הראשונה המסודרת. זה משתלב עם זרימת עבודה של ניפוי באגים ב-API כאשר גופי תגובה וכותרות נגרדים עבור ערכים ספציפיים.
חפש והחלף על פני בסיס קוד
עורכים ו-IDE תומכים ב-regex ב-find-and-replace, ודפוס גרוע שם יכול לשכתב הרבה יותר מהמתוכנן. בדיקת ה התאמה צד בבודק ייעודי לפני שאתה מפעיל את החלף הוא ביטוח זול - לראות בדיוק מה הדפוס בוחר על פני מדגם מייצג, ואז להפעיל את החלף בביטחון אסון redirect-מפה שלי היה ביסודו למצוא-ו-להחליף שמעולם לא בדקתי נגד קלט אמיתי ראשון.
למידה והוראה Regex
ההדגשה החיה הופכת את הבוחן לכלי למידה אמיתי בנה תבנית אסימון אחד בכל פעם וראה את ערכת ההתאמה מתכווצת וגדלה ככל שאתה מוסיף עוגנים, מכמתים ושיעורים. לראות \d+ תפוס מספר שלם ואז \d תפוס ספרה בודדת עושה יותר להבנה מכל הסבר פרוזה. כאשר אתה ' מוכנים להרכיב תבנית ממרכיבים במקום לנפות באגים בקיים, ה בונה רגקס הוא הכלי הנלווה.
כיצד נמנעים ממלכודת ההתאמה באורך אפס?
תבנית שיכולה להתאים למחרוזת ריקה - a*, \d*, (foo)?- יכול "match" בכל מיקום בין תווים, מייצר מבול של התאמות ריקות. קוד התאמה נאיבי שעושה 't להתקדם מעבר ללולאות התאמה באורך אפס לנצח. ה טסטר שומר מפני זה מבפנים על ידי התקדמות תמיד, כך שהוא לעולם לא תלוי, אבל הוא יהיה תלוי הצג את הגפרורים הריקים.
התצוגה הזו היא תכונה, לא רעש. ערימה של התאמות ריקות היא הבוחן שאומר לך שהכמת שלך מתירני מדי. אם התכוונת ל-" ספרה אחת או יותר," כתבת \d* כשרצית \d+. אם יש צורך בקבוצה, סימנת אותה כאופציונלית ?. לראות את ההתאמות הריקות הוא האבחון שמכוון אותך לתיקון. כאשר הדפוס שלך נכון, ההתאמות הן מחרוזות המשנה שאכפת לך מהן ותו לא.
JavaScript Regex לעומת טעמים אחרים: השוואה מהירה
| תכונה | JavaScript (בודק זה) | PCRE (PHP) | פייתון re |
|---|---|---|---|
| קבוצות שמות | (?<name>...) |
(?<name>...) או (?P<name>...) |
(?P<name>...) |
| תסתכל מאחור | נתמך (מנועים מודרניים) | נתמך | נתמך |
| קבוצות אטומיות / רכושניות | לא נתמך | נתמך | מוגבל |
| רקורסיה | לא נתמך | נתמך | לא נתמך |
| נקודה תואמת לדגל הקו החדש | s (dotAll) |
s (נקודה) |
re.DOTALL |
מאפיין Unicode \p{...} |
דורש u דגל |
דורש u משנה |
regex מודול בלבד |
| התאמה דביקה | y דגל |
\G עוגן |
\G-כמו ויה match עמדה |
הלקח של table's הוא ש-"regex" היא משפחה, לא סטנדרט התחביר חופף מספיק כדי להרגיע אותך להעתקת דפוסים על פני שפות, וההבדלים הם בדיוק התכונות המתקדמות שאליהן אתה מגיע בבעיות קשות בדוק בטעם היעד שלך עבור JavaScript ו-Node, that's this tester; ה ערכת כלים למפתחי אינטרנט מכסה היכן מתאימים הכלים הספציפיים לשפה האחרים.
האם זה בטוח לבדוק את Regex נגד טקסט רגיש?
הטקסט שאתה בודק את regex נגדו הוא לעתים קרובות מהסוג הרגיש: שורות יומן ייצור עם כתובות IP ומזהי משתמש, ייצוא עם כתובות דואל, קבצי תצורה עם שמות מארח פנימיים. That's בדיוק הנתונים שאתה should't הדבק לתוך כלי ששולח אותו לשרת.
ה Toolz.dev Regex Tester פועל כולו בדפדפן שלך הידור הדפוס, ההתאמה, החילוץ הקבוצתי - כל זה הוא JavaScript בצד הלקוח, ללא בקשת רשת נושאת את הדפוס שלך או את הטקסט שלך בשום מקום. Cut your connection after the page loads and it keeps working.That's ערובה לארכיטקטורה, לא משפט מדיניות פרטיות, ו-it's אותו עיקרון ראשון בדפדפן מאחורי כל כלי בסט, המופיע ב- מדריך פרטיות נתונים.
מה שאומר שאתה יכול להדביק את שורות היומן האמיתיות - אלה עם ה-PII בפועל שגורם לתבנית ' מקרי קצה מופיעים - ולאפות באגים נגדם בבטחה. That's כל העניין: הבוחן שימושי רק אם אתה מזין אותו בקלט אמיתי, וקלט אמיתי הוא לעתים קרובות בדיוק מה שאתה יכול 't לשלוח לשרת אחר 's.
שָׁוא
איך אני בודק ביטוי רגולרי באינטרנט?
הזן את התבנית שלך בשדה התבנית ללא הלוכסנים שמסביב, בחר את הדגלים שלך והדבק טקסט לדוגמה באזור הבדיקה. התאמות מדגישות באופן מיידי וקבוצות לכידה רשומות עבור כל התאמה. הכל פועל בדפדפן שלך - שום דבר לא מועלה.
באיזה טעם regex משתמש הבוחן הזה?
הוא משתמש במנוע ה-RegExp של JavaScript (ECMAScript) המובנה בדפדפן שלך, וזהה לזה שב-Node.js. התוצאות תואמות לאופן שבו אותו דפוס מתנהג ב-JavaScript וב-TypeScript. JavaScript regex שונה מ-PCRE, Python' מודול מחדש של Java ודפוסי Java בכמה תכונות מתקדמות כמו קבוצות אטומיות ורקורסיה, אז בדוק את הטעם שבו תפרוס.
מה המשמעות של דגלי הביטוי g, i, m ו-s?
הדגל g (גלובלי) מוצא את כל ההתאמות במקום לעצור בראשון הדגל i הופך התאמה ללא רישיות הדגל m (רב-קו) גורם לעוגנים ^ ו-$ להתאים בהפסקות קו ולא רק למחרוזת להתחיל ולסיים הדגל s (dotAll) מאפשר לנקודה להתאים גם לתווים בשורה חדשה הדגלים m ו-s מתבלבלים לעתים קרובות - m משנה את העוגנים, s משנה את הנקודה.
כיצד פועלות קבוצות לכידה בבודק?
סוגריים בתבנית שלך יוצרים קבוצות לכידה הבוחן מפרט כל קבוצה ממוספרת עם הטקסט שהיא לכדה עבור כל התאמה, כך שתוכל לאמת איזו פרוסה של המחרוזת תפס כל חלק בתבנית קבוצות שמות שנכתבו כ (?...) מוצגים לפי שם לצד הקבוצות הממוספרות.
למה ה-regex שלי לא תואם כלום או זורק שגיאה?
לתבנית שאינה תואמת דבר יש בדרך כלל תו ספציפי מדי או תו מיוחד שלא נמלט כמו נקודה מילולית או סימן פלוס. לתבנית שזורקת שגיאה יש בעיית תחביר, כגון סוגר או סוגריים לא מאוזנים. הבוחן מציג את המנוע ' הודעת שגיאה מדויקת כדי שתוכל לאתר את הבעיה במהירות.
איך אני מתאים על פני מספר קווים?
אפשר את הדגל s (dotAll) אם אתה צריך את הנקודה כדי לעבור מעברי שורות, והפעל את הדגל m (רב-קו) אם אתה רוצה שהעוגנים ^ ו-$ יתאימו בהתחלה ובסוף של כל שורה. שילוב שניהם מאפשר לתבנית בודדת לעבוד באופן טבעי מול קלט מרובה שורות כמו יומנים או שורות CSV.
האם זה בטוח לבדוק את ה-regex מול נתונים רגישים?
כן כל ההתאמה מתרחשת ב - JavaScript בתוך הדפדפן שלך - שום דפוס או טקסט בדיקה לא נשלח לשרת כלשהו, שום דבר לא נרשם, והכלי עובד כשהחיבור שלך מושבת אתה יכול לבדוק בבטחה מול קבצי יומן, נתונים אישיים או פורמטים קנייניים.
מה ההבדל בין בודק regex לבונה regex?
בודק regex מריץ תבנית קיימת מול טקסט כך שתוכל לאמת ולאפות באגים בה, בעוד שבונה regex עוזר לך לבנות תבנית מקומפוננטות או תבניות נפוצות השתמש ב-Regex Builder באתר זה כדי להרכיב תבנית, ולאחר מכן הבא אותה לבוחן כדי לבדוק אותה מול נתונים מדגם אמיתיים.
ביטויים רגולריים נשארים כתיבה בלבד עד שאתה מפעיל אותם נגד קלט אמיתי, והכישלונות שקטים - שום דבר לא תואם, יותר מדי התאמות, הקבוצה הלא נכונה לוכדת, ושום שגיאה לא אומרת לך. בודק הופך את הדפוס לגלוי: הדבק את ה-regex שלך, להאכיל אותו בטקסט האמיתי המכוער, ולצפות בדיוק במה שהוא תופס לפני שהוא תופס את הדבר הלא נכון בייצור.
