विंडोज आदेशों में विस्तारित वर्णों को संभालना?

Question

मैं एक विंडोज बैच कमांड फ़ाइल डीबग कर रहा हूँ। यह विफल हो रहा है जब विस्तारित (> 0x7f) वर्ण पथ या फ़ाइल नामों में उपयोग किए जाते हैं। समस्या एक कमांड फ़ाइल में गुजरने वाले पैरामीटर से संबंधित प्रतीत होती है जिसे दूसरे से कॉल किया जाता है।

एक उदाहरण के लिए, इस आदेश का काम करता है के रूप में उम्मीद:

xcopy "Pezuñero\1 - 001.wav" \temp 

यह नहीं करता है:

call another.cmd "Pezuñero" 

"another.cmd" की सामग्री:

xcopy "%~1\1 - 001.wav" \temp 

% ~ 1 वाक्यविन्यास एक पैरामीटर फैलाता है और उद्धरण हटा देता है। यह आवश्यक है क्योंकि असली कमांड फ़ाइल में, कॉलिंग या कॉल कमांड फ़ाइल में पथ रिक्त स्थान हो सकते हैं।

C:\>call another.cmd "Pezu±ero"  

C:\>xcopy "Pezu±ero\1 - 001.wav" \temp 
File not found - 1 - 001.wav 
0 File(s) copied 

ध्यान दें कि "एन" (0xF1) चरित्र एक "±" (0xB1) को बदल दिया गया है:

दूसरे उदाहरण (सीएमडी खिड़की से नकल) का परिणाम यह है।

क्या कोई यह बता सकता है कि क्या हो रहा है, और इसके आसपास कैसे काम करना है?

Answer 1

मैकडॉवेल और रोमुलो को सही दिशा में इंगित करने के लिए धन्यवाद। मुझे एहसास हुआ कि मुझे बैच उत्पन्न करने वाले मेरे एप्लिकेशन (डेल्फी में) को बदलने की ज़रूरत है, इसलिए यह उचित (OEM) कोड पृष्ठ का उपयोग करता है जो विंडोज में कमांड प्रोसेसर के साथ संगत है। मुझे कोडपेज स्ट्रिंग्स को कन्वर्ट करने के लिए कुछ भी नहीं मिला, लेकिन मैंने विंडोज एपीआई फ़ंक्शन SetFileApisToOEM और SetFileApisToANSI को खोजा;

कि मैंने शुरू और मेरे कार्यक्रम के अंत में इन शब्दों में कहें, इस तरह:

{main procedure} 
begin 
    SetFileApisToOEM; 
    {all the rest of the program} 
    SetFileApisToANSI; 
end. 

अब बैच फ़ाइलों OEM कोड पृष्ठ के साथ उत्पन्न कर रहे हैं, और जब एक अध्यक्ष एवं प्रबंध निदेशक शीघ्र से चला वे ठीक से काम करते हैं।

Answer 2

आपको कोडपेज को उस पर सेट करने की आवश्यकता हो सकती है जिसमें शीर्ष पर ~ n है।

Answer 3

कोडपेज बैच फ़ाइलों में एक समस्या है क्योंकि उन्हें यूनिकोड रखने की अनुमति नहीं है। इस मुद्दे से पूरी तरह से बचने का सबसे आसान तरीका शायद डब्लूएसएच या पावरहेल का उपयोग करना होगा। मैं बैच फ़ाइलों के लिए एक वैकल्पिक हल अब तक जो वास्तव में मुझे परेशान के रूप में मैं अपने आप को एक यूनिकोड कट्टरपंथी :)

Answer 4

स्क्रिप्ट समान कूट cmd.exe का उपयोग करता है में लिखा होना चाहिए पर विचार नहीं मिली है।

प्रपत्र पर chcp टाइप करें और देखें कि आपको क्या मिलता है। फिर उस एन्कोडिंग का समर्थन करने वाले संपादक के साथ फ़ाइल खोलें। मेरे लिए chcp कोड कोड आउटपुट करता है, इसलिए मैं JEdit में आईबीएम 850 फ़ाइल एन्कोडिंग के रूप में अपनी स्क्रिप्ट संपादित करता हूं। प्रारूपOEM पर PSPad में फ़ाइल को संपादित करने के समान परिणाम मिलते हैं।

पुनश्च: एक ± जब कमांड प्रॉम्प्ट से पढ़ने मैं अपने मशीन में अपने चरणों का परीक्षण किया और ñ चरित्र है कि मैं notepad.exe में लिखने (डिफ़ॉल्ट एएनएसआई एन्कोडिंग का उपयोग) भी बदल जाती है, तो ऐसा लगता है कि आपकी मशीन समान एएनएसआई और OEM एन्कोडिंग का उपयोग करती है। यह सुनिश्चित करने के लिए ñ¤ (नोटपैड.एक्सई के साथ) को बदलने का प्रयास करें। कमांड प्रॉम्प्ट से चलाते समय स्क्रिप्ट मेरे लिए सही तरीके से काम करता है (क्योंकि एएनएसआई के by का बाइट मान OEM के ñ जैसा ही है)।

Answer 5

मैं looking at character handling in cmd.exe रहा हूं और मुझे लगता है कि Romulo ने सिर पर नाखून मारा है। डिफ़ॉल्ट रूप से, प्रॉम्प्ट पुराने डॉस (OEM) कोड पृष्ठों का उपयोग करता है (शायद डॉस प्रोग्राम के साथ संगतता के लिए)। आप (संभवतः) डिफ़ॉल्ट विंडोज कोड पेज (संभवतः 1252) का उपयोग करके अपनी फ़ाइल लिख रहे हैं, जो अलग है। बैच फ़ाइल को संपादित करने के लिए संपादित करें का उपयोग करें।

अगर मैं प्रॉम्प्ट पर chcp लिखते हैं, तो कोड पेज 850

तो, उदाहरण के लिए, अगर मैं नोटपैड का उपयोग इस टाइप करने के लिए रिपोर्ट:

DIR Pezuñero 

... अगर मैंका उपयोग

     ñ 
44 49 52 20 50 65 7A 75 F1 65 72 6F 

: इस द्विआधारी मूल्यों के साथ 1252 के रूप में एन्कोड किया गया हैफ़ाइल में लिखने का, यह द्विआधारी मूल्यों के साथ 850 के रूप में एन्कोड किया गया है:

     ñ 
44 49 52 20 50 65 7A 75 A4 65 72 6F 

एक बात मैं पर cmd/यू स्विच का उपयोग कर रहा है देखा नहीं है, लेकिन मैं बहुत यकीन है कि केवल है कर रहा हूँ खोल कमांड में निर्मित के लिए और XCOPY के साथ आपकी मदद नहीं करेगा।