इंटरनेट पैरामीटर (5, 6, 7 और 8) को यूनिकोड के रूप में अपने मापदंडों को एनकोड करने के लिए मजबूर करने के लिए इस पैरामीटर को प्रपत्रों में जोड़ा गया था ।
विशेष रूप से, इस बग को ट्रिगर किया जा सकता है यदि उपयोगकर्ता ब्राउज़र -1 को लैटिन -1 में स्विच करता है। यह समझने के लिए कि कोई उपयोगकर्ता ऐसा क्यों प्रतीत होता है कि वह पागल है, इस Google खोज को देखें । एक बार जब उपयोगकर्ता ने वेब-साइट को लैटिन -1 मोड में डाल दिया है, अगर वे ऐसे पात्रों का उपयोग करते हैं जिन्हें लैटिन -1 और यूनिकोड (उदाहरण के लिए, é या ç, नामों में सामान्य) के रूप में समझा जा सकता है, तो इंटरनेट एक्सप्लोरर उन्हें लैटिन में एनकोड करेगा -1।
इसका मतलब है कि यदि कोई उपयोगकर्ता "च्यू ग्वेरा" खोजता है, तो यह सर्वर-साइड पर गलत तरीके से आएगा। रूबी 1.9 में, यह एक एन्कोडिंग त्रुटि का परिणाम देगा जब पाठ अनिवार्य रूप से नियमित अभिव्यक्ति इंजन में अपना रास्ता बनाता है। रूबी 1.8 में, यह उपयोगकर्ता के लिए टूटे हुए परिणाम देगा।
एक ऐसा पैरामीटर बनाकर जिसे केवल IE द्वारा एक यूनिकोड वर्ण के रूप में समझा जा सकता है, हम IE को स्वीकार-चारसेट विशेषता को देखने के लिए मजबूर कर रहे हैं, जो तब इसे सभी वर्णों को UTF-8 के रूप में एनकोड करने के लिए कहता है, यहां तक कि जिन्हें एनकोड किया जा सकता है लैटिन में -1।
ध्यान रखें कि रूबी 1.8 में, अपने यूटीएफ -8 डेटाबेस में लैटिन -1 डेटा प्राप्त करना बेहद तुच्छ है (चूंकि पूरे स्टैक में कुछ भी नहीं दिखता है कि उपयोगकर्ता किसी भी बिंदु पर भेजे गए बाइट्स वैध यूटीएफ -8 वर्ण हैं)। परिणामस्वरूप, यह उपयोगकर्ता-सामना करने वाले बग को प्रदर्शित करने के लिए रूबी अनुप्रयोगों (और PHP अनुप्रयोगों, आदि) के लिए बेहद आम है और इसलिए उपयोगकर्ताओं के लिए एक उपशामक उपाय के रूप में एन्कोडिंग को बदलने की कोशिश करने के लिए बेहद आम है।
उस सभी ने कहा, जब मैंने इस पैच को लिखा था, मुझे एहसास नहीं था कि पैरामीटर का नाम कभी भी उपयोगकर्ता-सामना करने वाली जगह में दिखाई देगा (यह उन रूपों के साथ होता है जो जीईटी कार्रवाई का उपयोग करते हैं, जैसे कि खोज फ़ॉर्म)। चूंकि यह करता है, हम इस पैरामीटर का नाम बदल देंगे _e, और अधिक सहज दिखने वाले यूनिकोड चरित्र का उपयोग करेंगे।