מי שמצליח להצדיק את התוצאה הזו מMySQL יזכה בחופשה בקאריבים:
[code lang="sql"]
create table t(a varchar(10));
insert into t(a) values('aaa'),('bbb'),('ccc'),('ddd');
select * from t where a in (666,'a');
+——+
| a |
+——+
| aaa |
| bbb |
| ccc |
| ddd |
+——+
[/code]
Facebook Comments
מהתיעוד של mysql:
You should never mix quoted and unquoted values in an IN list because the comparison rules for quoted values (such as strings) and unquoted values (such as numbers) differ. Mixing types may therefore lead to inconsistent results.
מתוך: http://dev.mysql.com/doc/refman/5.0/en/comparison-operators.html#function_in
אין הצדקה, אבל יודעים להגיד "אל תעשה את זה"…
באג? לא חסרים באגים ב-MySQL. אבל תראה משהו מעניין, אם תנסה:
SELECT * FROM t WHERE a IN (BINARY 666, 'a');
תקבל תשובה נכונה.
לדעתי, ה-IN אמור לעשות השוואה בינארית, אבל במקרה הזה, שה-expression הוא סטרינג וברשימת החיפוש יש סוגי מידע שונים, הוא מפקשש עם המספר, ולא לוקח אותו כבינארי. לא מצאתי מספיק מידע על איך הוא משווה בין סוגי מידע שונים ברשימת החיפוש, אם הוא עושה קאסט ואיך.
תודיע לי אם תמצא פיתרון לדבר הזה. 🙂
הכל בגלל ה-666 הזה.
מספר בעייתי 🙂
יהונתן, מי קורא את התיעוד? 😉
יוקס, 666 וbinary 666 הם ערכים שונים.
IN אמור לעשות השוואה שתלויה בסוג של המשתנים, אם המשתנים הם סטרינגים אז השוואה של סטרינגים, אם הם דאבלים אז דאבלים וכו'.
יש שם איזה באג מטופש, שאגב לא משתחזר ב5.1 (לפי הבאג ריפורט שפתחתי: http://bugs.mysql.com/bug.php?id=37730)
המעקף לבעיה במקרה שלי הוא פשוט:
SELECT * FROM t WHERE a IN ('666','a');
הסיבה ש666 לא קיבל גרשיים היא מטופשת במיוחד, הוא מספר ופונקציית הescape בPHP לא נוגעת במספרים.
המעקף שלי בעצם הוא בדיקה של ערכים מספריים, ועטיפה שלהם בגרשיים ישירות ולא עם escape.
גיא, זה מספר שימושי שכל האקר צריך להכיר.
הוא מוציא את הרוע מכל שרת.
יכול להיות שהתוצאה שונה ממה שהיית מצפה לקבל.
בטוח שאין שום הגיון בשאילתה שבודקת האם שדה של מחרוזת מתאים למספק או מחרוזת.
עמרי – הוא לא רק מוציא את הרוע אלא גם מוסיף רשומת Beast ל-DNS.
אכן, מספר חשוב 🙂