"अवैध बाइट अनुक्रम" की शिकायत

Question

मैं UNIX के लिए बिल्कुल नया हूं और मैं खुद को कुछ कमांड सिखाने के लिए किर्क मैकलेरन की "द मैक ओएस एक्स कमांड लाइन" का उपयोग कर रहा हूं।

मैं उपयोग करने का प्रयास कर रहा हूं trऔर grepताकि मैं नियमित एमएस-ऑफिस वर्ड डॉक्यूमेंट में टेक्स्ट स्ट्रिंग्स की खोज कर सकूं।

$ tr '\r' '\n' < target-file | grep search-string

लेकिन यह सभी रिटर्न है:

Illegal byte sequence.

robomechanoid:Position-Paper-Final-Draft robertjralph$ tr '\r' '\n' < Position-Paper-Final-Version.docx | grep DeCSS
tr: Illegal byte sequence
robomechanoid:Position-Paper-Final-Draft robertjralph$ 

मैंने वास्तव में एक स्क्रिप्ट पर वही लाइन चलाई है जो मैंने बनाई थी viऔर यह खोज को सही ढंग से करती है।

Comments

मैं यह नहीं देख सकता कि tr शिकायत क्यों करेगा, क्या आपने प्रश्न में जैसा लिखा था वैसा ही टाइप किया था? grep नहीं मिलेगा कि आप क्या चाहते हैं, xdoc एक बीमार परिभाषित मानक है। कोई भी वास्तव में नहीं जानता कि उन फाइलों पर क्या है, लोगों ने इसे उल्टा इंजीनियर बनाया है, जाहिर है कि मानक बिना किसी मदद के था।

— ctrl-alt-delor

Answer 1

grepएक टेक्स्ट प्रोसेसिंग टूल है। यह उनके इनपुट को टेक्स्ट फाइल होने की उम्मीद करता है । ऐसा लगता है कि वही trmacOS पर जाता है (भले ही trबाइनरी फ़ाइलों का समर्थन करने वाला हो)।

कंप्यूटर डेटा को बाइट्स के अनुक्रम के रूप में संग्रहीत करते हैं । एक पाठ वर्णों का एक क्रम है। वर्णों को बाइट्स के रूप में एन्कोड करने के कई तरीके हैं, जिन्हें वर्ण एन्कोडिंग कहा जाता है । दुनिया के अधिकांश हिस्सों में, विशेष रूप से OSX पर डी वास्तविक मानक वर्ण एन्कोडिंग, यूटीएफ -8 है , जो यूनिकोड वर्ण सेट के लिए एन्कोडिंग है । केवल 256 संभव बाइट्स हैं, लेकिन एक लाख से अधिक संभव यूनिकोड वर्ण हैं, इसलिए अधिकांश वर्ण एकाधिक बाइट्स के रूप में एन्कोड किए गए हैं। UTF-8 एक चर-लंबाई एन्कोडिंग है: चरित्र के आधार पर, एक वर्ण को एन्कोड करने में एक से चार बाइट्स लग सकते हैं। बाइट्स के कुछ क्रम UTF-8 में किसी भी वर्ण का प्रतिनिधित्व नहीं करते हैं। इसलिए, बाइट्स के क्रम हैं जो मान्य UTF-8 पाठ फ़ाइलें नहीं हैं।

trशिकायत कर रहा है क्योंकि यह इस तरह के एक बाइट अनुक्रम का सामना करना पड़ा। यह एक टेक्स्ट फ़ाइल को UTF-8 में एन्कोडेड देखने की उम्मीद करता है, लेकिन यह बाइनरी डेटा देखता है जो मान्य UTF-8 नहीं है।

Microsoft Word दस्तावेज़ एक पाठ फ़ाइल नहीं है: यह एक शब्द संसाधन दस्तावेज़ है। वर्ड प्रोसेसिंग डॉक्यूमेंट फॉर्मेट न केवल टेक्स्ट, बल्कि फॉर्मेटिंग, एंबेडेड इमेज आदि को भी एनकोड करते हैं। वर्ड फॉर्मेट, ज्यादातर वर्ड प्रोसेसिंग फॉर्मेट की तरह, टेक्स्ट फाइल नहीं है।

आप स्थानीय को बदलकर बाइट्स पर काम करने के लिए टेक्स्ट प्रोसेसिंग टूल को निर्देश दे सकते हैं । विशेष रूप से, "C" लोकेल का चयन करें, जिसका मूल अर्थ है "कुछ भी नहीं फैंसी"। कमांड लाइन पर, आप पर्यावरण चर के साथ स्थानीय सेटिंग्स चुन सकते हैं ।

export LC_CTYPE=C
tr '\r' '\n' < target-file | grep search-string

यह किसी भी त्रुटि का उत्सर्जन नहीं करेगा, लेकिन यह कुछ भी उपयोगी नहीं होगा क्योंकि target-fileअभी भी एक बाइनरी फ़ाइल है जिसमें आपके द्वारा निर्दिष्ट अधिकांश खोज स्ट्रिंग शामिल होने की संभावना नहीं है।

संयोग से, tr '\r' '\n'एक बहुत ही उपयोगी कमांड नहीं है जब तक कि आपके पास मैक ओएस 9 या पुराने से पाठ की फाइलें नहीं बची हैं। \r(कैरिज रिटर्न) मैक ओएस एक्स से पहले मैक ओएस में न्यूलाइन सेपरेटर था। ओएसएक्स के बाद से, न्यूलाइन सेपरेटर \n(लाइन फीड, यूनिक्स मानक) है और टेक्स्ट फाइलों में कैरिज रिटर्न नहीं होता है। Windows दो-वर्ण अनुक्रम CR-LF का उपयोग करता है लाइन ब्रेक का प्रतिनिधित्व करने के लिए; tr -d '\r'एक Windows पाठ फ़ाइल को एक यूनिक्स / लिनक्स / OSX पाठ फ़ाइल में बदल देगा।

तो आप कमांड लाइन से वर्ड डॉक्यूमेंट में कैसे सर्च कर सकते हैं? एक .docxवर्ड डॉक्यूमेंट वास्तव में एक ज़िप आर्काइव है जिसमें कई फाइलें होती हैं, जिनमें से एक एक्सएमएल में होती है ।

unzip -l Position-Paper-Final-Version.docx

Mac OS X में ज़िप फ़ाइलों के अंदर खोजने के लिए zipgrep उपयोगिता शामिल है ।

zipgrep DeCSS Position-Paper-Final-Version.docx

परिणाम बहुत पठनीय नहीं होने वाला है क्योंकि docx प्रारूप में XML फाइलें ज्यादातर एक बड़ी लाइन से मिलकर बनी होती हैं। यदि आप दस्तावेज़ के मुख्य बॉडी टेक्स्ट के अंदर खोजना चाहते हैं, word/document.xmlतो आर्काइव से फ़ाइल निकालें । ध्यान दें कि दस्तावेज़ पाठ के अलावा, इस फ़ाइल में XML मार्कअप है जो दस्तावेज़ की संरचना का प्रतिनिधित्व करता है। एक्सएमएल मार्कअप की मालिश sedकरने योग्य लाइनों में विभाजित करने के लिए आप थोड़ा सा मालिश कर सकते हैं।

unzip -p Position-Paper-Final-Version.docx word/document.xml |
sed -e 's/></>\n</g' |
grep DeCSS

Comments

अच्छा सारांश और अतिरिक्त बिट्स के लिए +1। हालांकि मुझे एक बात कहनी है। XML स्वरूप के लिए, आप उपयोग कर सकते हैं xml_ppयह पैकेज में है xml-twig-toolsडेबियन GNU + लिनक्स पर (एक मैक पता नहीं है)।

— ctrl-alt-delor

मैक 2011 के लिए एक्सेल CSV फ़ाइलों को \ r लाइन एंडिंग्स से बचाता है, इसलिए यह tr आह्वान वास्तव में काफी प्रासंगिक और उपयोगी है।

— नूह येटर

जब आप एक टैब सीमांकित संपर्क सूची निर्यात करते हैं तो मैक 2011 के लिए आउटलुक मैक के लिए होता है।

— इवान एक्स

वैसे, इसको कम करने के लिए मेरे पास पर्याप्त प्रतिष्ठा नहीं है, लेकिन यह उत्तर बिल्कुल गलत है। इसकी शुरुआत " tr[...] से होती है। जबकि POSIX विनिर्देश स्पष्ट रूप से बताता है "मानक इनपुट किसी भी प्रकार की फ़ाइल हो सकती है।" । कृपया अपना उत्तर सही करें।

— 7heo.tk

@ 7heo.tk "इस जवाब पूरी तरह से गलत है" एक सकल exageration है, लेकिन आप रहे हों तो सही, trहै चाहिए बाइनरी इनपुट पर कार्रवाई करने के (विशेष रूप से, यह प्रक्रिया अशक्त सही ढंग से बाइट्स चाहिए था)। POSIX स्पष्ट रूप से निर्दिष्ट नहीं करता है कि इनपुट के साथ कैसे व्यवहार करना चाहिए जो कि वर्णों का अनुक्रम नहीं है, हालांकि। (यदि मैं एक कार्यान्वयनकर्ता होता, तो मैं अनमॉडिफाइड (या उन्हें हटा देता हूं -s) के माध्यम से अमान्य बाइट अनुक्रमों को पारित करता हूं , और मानक समिति के साथ एक दोष बढ़ाता हूं ।) जाहिर है, macOS के tr उनके बारे में शिकायत करते हैं।

— गिलेस एसओ- बुराई को रोकना '

Answer 2

मुझे लगता है कि स्थानों से आपका आकर्षण केंद्र UTF-8 है, जिससे आपको बाइनरी फ़ाइलों पर समस्या होगी। बस सी लोकेल पर जाएँ:

LC_ALL=C tr '\r' '\n' < target-file | LC_ALL=C grep search-string

Comments

आप भाषा को दो बार निर्दिष्ट करने से बचने के लिए कोष्ठक का उपयोग कर सकते हैं। LC_ALL=C ( tr '\r' '\n' < target-file | grep search-string )। हालांकि डॉक्स सी लोकल नहीं है। है utf16 और ज़िपित और जटिल और किसी का अनुमान है। मैं एक ऐसे उपकरण का उपयोग करूंगा जो इसे एक अलग प्रारूप में परिवर्तित कर सकता है जिसे आप html या odt (ओडीटी भी ज़िप किया गया है, लेकिन अच्छी तरह से परिभाषित और व्याख्या करने में आसान) की प्रक्रिया कर सकते हैं।

— ctrl-alt-delor

कोष्ठक (कोष्ठक) के साथ वाक्यविन्यास सभी गोले के साथ काम नहीं करता है (न मार, न zsh, न डैश)। फिर, एमएस वर्ड फ़ाइल के विषय में, यह निर्भर करता है। मेरे पास कुछ ऐसी फाइलें हैं जहां stringsकमांड स्पष्ट टेक्स्ट देती है।

— vinc17

वैकल्पिक रूप से, ( export LC_ALL=C; tr '\r' '\n' < target-file | grep search-string; )काम करना चाहिए।

— vinc17

stringsसुपर पावर है: यह उन फ़ाइलों को पढ़ सकता है जो केवल utf-8 या ascii टेक्स्ट नहीं हैं।

— ctrl-alt-delor-

इस ()बात के लिए खेद है कि मुझे लगा कि ठीक करने के लिए @ vinc17 का धन्यवाद होगा।

— ctrl-alt-delor