8

के तहत अलग-अलग परिणाम प्राप्त करते हैं, मैं अपने आवेदन की i18n संगतता का परीक्षण कर रहा हूं। मेरे पास विंडोज 7 का एक अंग्रेजी संस्करण है जिसका अर्थ है कि सिस्टम की डिस्प्ले भाषा अंग्रेजी है। और मैंने गैर-यूनिकोड अनुप्रयोग के लिए सिस्टम लोकेल को चीनी के रूप में सेट किया है।Charset.defaultCharset() जेडीके 1.7 और जेडीके 1.6

जेडीके 1.6 के तहत चीनी चरित्र के साथ एचटीएमएल फाइलों को निर्यात करते समय मेरे एप्लिकेशन में समस्याएं आईं, लेकिन jdk1.7 के तहत चलते समय ठीक काम करता है।

मैंने इसे डीबग किया और पाया कि प्रत्यक्ष कारण यह था कि Charset.defaultCharset() अलग-अलग मान लौटा।

जेडीके 1.7 Charset.defaultCharset() के तहत GBK लौटा जो चीनी के लिए वर्णमाला है।

जेडीके 1.6 Charset.defaultCharset() के तहत window_1252 लौटा जो लैटिन भाषा के लिए वर्णमाला है।

मुझे पता है कि कोड को नामित वर्णमाला द्वारा हल किया जा सकता है, utf-8, कोड में।

लेकिन मैं जानना चाहता हूं कि क्यों Charset.defaultCharset() जेडीके 1.7 और जेडीके 1.6 के तहत अलग-अलग मान लौटाते हैं।

+1

अनुमान में, "गैर-यूनिकोड अनुप्रयोग के लिए लोकेल" सेटिंग को पढ़ने के लिए विंडोज़ जेआरई 7 में एक नई सुविधा है (मुझे लगता है कि रिलीज नोट्स में उल्लेख करने के लिए पर्याप्त महत्वपूर्ण नहीं हो सकता है, और बग डेटाबेस के लिए खोज सुविधा वास्तव में बग डेटाबेस नहीं खोजती है।) – millimoose

+3

कुछ [यूनिकोड और अंतर्राष्ट्रीयकरण संवर्धन] रहे हैं (http://download.oracle.com/javase/7/docs/technotes/guides/intl /enhancements.7.html) जावा 7 में - शायद यह इसके साथ बंडल किया गया था। – Bringer128

+1

क्या आप पोस्ट कर सकते हैं 'System.getProperty ("file.encoding") को jdk 6 और 7 दोनों में कॉल करके आप क्या प्राप्त करते हैं? – mindas

उत्तर

3

Charset.defaultCharset() जेवीएम चलने का वर्णमाला देता है, इसलिए यह हमेशा एक ही मूल्य नहीं होता है। उदाहरण के लिए यदि आप नेटबींस के साथ अपने प्रोग्राम चला रहे हैं, तो यह हमेशा यूटीएफ -8 लौटाएगा, क्योंकि नेटबीन्स में जावा प्रोजेक्ट्स के लिए यह डिफ़ॉल्ट एन्कोडिंग है।

मेरे पास आपके जैसा सेटअप है। मेरा विंडोज अंग्रेजी है (मेनू, संवाद अंग्रेजी हैं) और मैं गैर-यूनिकोड अनुप्रयोगों के लिए तुर्की का उपयोग कर रहा हूं। जब मैं किसी भी झंडे या सिस्टम पैरामीटर के बिना JVM प्रारंभ करता हूं, तो जावा 7 और जावा 6 रनटाइम दोनों "CP1254" देते हैं जब Charset.defaultCharset() कहा जाता है। System.getProperty("file.encoding") और डिफ़ॉल्ट आईओ एन्कोडिंग भी वही हैं। (सिस्टम की लोकल इन दो जावा संस्करणों में अलग है, हालांकि यह एक और कहानी है।)

तो मुझे लगता है कि आपकी समस्या यह है कि आप कैसे अपना जेवीएम शुरू करते हैं, या कैसे JVM डिफ़ॉल्ट एन्कोडिंग का निर्णय लेता है, इसका उपयोग करना चाहिए। यदि आप सुनिश्चित हैं कि समस्या पूर्व नहीं है (आप किसी भी एन्कोडिंग पैरामीटर के बिना JVM चलाते हैं और आप अपने प्रोग्राम में कहीं भी डिफ़ॉल्ट वर्णसेट को बदलने का प्रयास नहीं करते हैं), तो JVM गलत एन्कोडिंग गलत तरीके से प्राप्त करता है और संभवतः यह असामान्य व्यवहार है।

3

Java 7 technote का कहना है:

समर्थित एनकोडिंग जावा प्लेटफार्म, मानक संस्करण 7 (जावा SE 7) के विभिन्न कार्यान्वयन के बीच बदलती हैं।

Charset doc का कहना है:

जावा आभासी मशीन के हर उदाहरण के एक डिफ़ॉल्ट चारसेट, जो या मानक वर्णसेट में से एक हो नहीं हो सकता है। डिफ़ॉल्ट वर्णसेट वर्चुअल-मशीन स्टार्टअप के दौरान निर्धारित किया जाता है और आमतौर पर अंतर्निहित ऑपरेटिंग सिस्टम द्वारा उपयोग किए जाने वाले लोकेल और वर्णसेट पर निर्भर करता है।

इसके अलावा, मैं इस अंतिम मूल्यांकन के साथ -Dfile.encoding का उपयोग कर के बारे में "bug" पाया है:

यह एक बग नहीं है। जे 2 एसई प्लेटफार्म विनिर्देशन द्वारा "file.encoding" प्रॉपर्टी की आवश्यकता नहीं है; यह सूर्य के कार्यान्वयन का आंतरिक विवरण है और उपयोगकर्ता कोड द्वारा जांच या संशोधित नहीं किया जाना चाहिए। यह केवल पढ़ने के लिए ही है; यह के लिए तकनीकी रूप से असंभव है कमांड लाइन पर या किसी अन्य समय प्रोग्राम निष्पादन के दौरान मनमाने ढंग से मूल्यों के लिए इस संपत्ति की सेटिंग का समर्थन करता है।

वीएम और रनटाइम सिस्टम द्वारा उपयोग किए गए डिफ़ॉल्ट एन्कोडिंग को बदलने का पसंदीदा तरीका अपने जावा प्रोग्राम को शुरू करने से पहले अंतर्निहित प्लेटफार्म के लोकेल को बदलना है।

संबंधित मुद्दे