एकाधिक भाषाओं से डेटा पढ़ते समय जंक/कचरा पात्रों से कैसे बचें?

गुजराती शुरू होता है રેલવે , सही? और मलयालम शुरू होता है നേപ , सही? और अंग्रेजी में Bureau’s शामिल होना चाहिए था ।

यह

• क्लाइंट में आपके पास मौजूद बाइट utf8 में सही ढंग से एन्कोडेड हैं। (Bureau utf8 के Ascii/latin1 सबसेट में एन्कोड किया गया है; लेकिन ’ एएससीआई एपॉस्ट्रॉफी नहीं है।)
• आप SET NAMES latin1 . से जुड़े हैं (या set_charset('latin1') या ...), शायद डिफ़ॉल्ट रूप से। (यह utf8 होना चाहिए था ।)
• तालिका में कॉलम घोषित किया गया था CHARACTER SET latin1 . (या संभवतः इसे तालिका/डेटाबेस से विरासत में मिला था।) (यह utf8 होना चाहिए था। ।)

डेटा के लिए समाधान एक "2-चरणीय परिवर्तन" है।

ALTER TABLE Tbl MODIFY COLUMN col VARBINARY(...) ...;
ALTER TABLE Tbl MODIFY COLUMN col VARCHAR(...) ... CHARACTER SET utf8 ...;

जहां लंबाई काफी बड़ी है और अन्य "..." के पास और कुछ भी है (NOT NULL , आदि) पहले से ही कॉलम पर था।

दुर्भाग्य से, यदि आपके पास काम करने के लिए बहुत सारे कॉलम हैं, तो इसमें बहुत सारे ALTER होंगे। आप MODIFY . कर सकते हैं (चाहिए) VARBINARY . के लिए सभी आवश्यक कॉलम ALTERs . की जोड़ी में एकल तालिका के लिए ।

कोड के लिए समाधान utf8 को कनेक्शन के रूप में स्थापित करना है; यह PHP में प्रयुक्त एपीआई पर निर्भर करता है। ALTERs कॉलम की परिभाषा बदल देगा।

संपादित करें

आपके पास VARCHAR . है गलत CHARACTER SET . के साथ . इसलिए, आप Mojibake को રેલ . की तरह देखते हैं . अधिकांश रूपांतरण तकनीकें રેલ . को संरक्षित करने का प्रयास करती हैं , लेकिन वह नहीं है जो आपको चाहिए। इसके बजाय, VARBINARY . पर एक कदम उठाएं लैटिन 1-एन्कोडेड वर्णों का प्रतिनिधित्व करने वाले बिट्स की पुरानी परिभाषा को अनदेखा करते हुए बिट्स को संरक्षित करता है। दूसरा चरण फिर से बिट्स को सुरक्षित रखता है, लेकिन अब दावा कर रहा है कि वे utf8 वर्णों का प्रतिनिधित्व करते हैं।