विकल्प character_set_client MySQL क्लाइंट द्वारा भेजे जाने वाले प्रश्नों और डेटा के वर्ण सेट के लिए उपयोग करता है।
MySQL 5.5, 5.6, और 5.7 में utf8 और 8.0 में utf8mb4 डिफ़ॉल्ट है।
इसे आपकी my.cnf विकल्प फ़ाइल में, या प्रति सत्र सेट नाम बयान।
जब आप कनेक्ट करते हैं तो विकल्प को स्पष्ट रूप से सेट करना अच्छा होता है, इसलिए आपको इसका डिफ़ॉल्ट मान मानने की आवश्यकता नहीं है।
अपनी टिप्पणी दें:
मुझे डर है कि आप SQL इंजेक्शन के दो अलग-अलग मामलों को भ्रमित कर रहे हैं। उन विशिष्ट पाँच वर्ण सेटों का उपयोग करते समय जोखिम होता है, लेकिन यह दूसरे क्रम के SQL इंजेक्शन से संबंधित नहीं है।
वर्ण सेट जोखिम कुछ बहु-बाइट वर्ण सेट के कारण होता है। शाब्दिक उद्धरण वर्ण से बचने के लिए बैकस्लैश सम्मिलित करना आम बात है। लेकिन कुछ कैरेक्टर सेट में, बैकस्लैश बाइट पिछले बाइट में मर्ज हो जाता है, जिससे मल्टी-बाइट कैरेक्टर बनता है। यह उद्धरण को छोड़ देता है।
दूसरे क्रम का SQL इंजेक्शन पूरी तरह से अलग है। यह किसी भी वर्ण सेट के साथ हो सकता है। यह तब होता है जब कोई हमलावर किसी फ़ॉर्म को भरने जैसे वैध माध्यमों से आपके डेटाबेस में डेटा जोड़ता है। डेटा सम्मिलित करना त्रुटि के बिना नियंत्रित किया जाता है। लेकिन उनके द्वारा डाले गए मानों में कुछ बाद की SQL क्वेरी का फायदा उठाने के लिए डिज़ाइन किया गया सिंटैक्स होता है।
यह डेवलपर्स पर निर्भर करता है कि डेटा जो पहले से ही उनके डेटाबेस में सुरक्षित रूप से सहेजा गया है, उचित पैरामीटर के बिना उपयोग के लिए किसी भी तरह "सुरक्षित" है।
दूसरे क्रम के SQL इंजेक्शन का एक उदाहरण जो दुर्भावनापूर्ण होने के बजाय केवल आकस्मिक है, यह हो सकता है कि किसी व्यक्ति का अंतिम नाम "O'Reilly" हो और नाम को कोड द्वारा पढ़ा जाता है और बाद की क्वेरी में उपयोग किया जाता है।
$name = $db->query("SELECT last_name FROM people WHERE id = 123")->fetchColumn();
$sql = "SELECT * FROM accounts WHERE account_owner_last_name = '$name'";
अगर नाम में एक अक्षरशः एपॉस्ट्रॉफी है, तो यह उस उदाहरण में दूसरी क्वेरी को गड़बड़ कर देगा।
