आरई त्रुटि: मैक ओएस एक्स पर अवैध बाइट अनुक्रम

Question

मैं iOS के लिए क्रॉस-संकलन के लिए मैक ओएस एक्स पर एक मेकफाइल में एक स्ट्रिंग को बदलने की कोशिश कर रहा हूं। स्ट्रिंग में डबल कोट्स हैं। आदेश है:

sed -i "" 's|"iphoneos-cross","llvm-gcc:-O3|"iphoneos-cross","clang:-Os|g' Configure

और त्रुटि यह है:

sed: RE error: illegal byte sequence

मैंने डबल कोट्स, कॉमा, डैश और कॉलोन से बचने की कोशिश की है, जिनमें कोई खुशी नहीं है। उदाहरण के लिए:

sed -i "" 's|\"iphoneos-cross\"\,\"llvm-gcc\:\-O3|\"iphoneos-cross\"\,\"clang\:\-Os|g' Configure

मैं इस मुद्दे पर डिबगिंग के समय की एक बिल्ली हूँ। क्या किसी को पता है कि sedअवैध बाइट अनुक्रम की स्थिति को कैसे प्रिंट किया जाए? या किसी को पता है कि अवैध बाइट अनुक्रम क्या है?

Comments

अवैध बाइट अनुक्रम कुछ ऐसा लगता है जो आपको 8-बिट एसेसी खिलाते समय मिलता है, जो यूटीएफ -8 की अपेक्षा करता है।

— क्लेस लिंडबैक

क्या आप कोशिश कर सकते हैं:LC_CTYPE=C && LANG=C && sed command

— शुभ

धन्यवाद दोस्तों। यह LANGबात थी। आह ....

— jww

@ user2719058: बीएसडी sed(जैसा कि ओएस एक्स पर भी उपयोग किया जाता है) को -i ''बैकअप फ़ाइल के बिना इन-प्लेस अपडेट के लिए (अलग, खाली-स्ट्रिंग विकल्प-तर्क) की आवश्यकता होती है ; GNU के साथ sed, केवल -iअपने आप काम करता है - देखें stackoverflow.com/a/40777793/45375

— mklement0

LANG बात के लिए प्लस एक। अच्छा दु: ख, यह अस्पष्ट है, गैर-स्पष्ट और आश्चर्यजनक रूप से अनुसंधान के लिए मुश्किल है।

— स्पडली

Answer 1

^{एक नमूना आदेश जो लक्षण प्रदर्शित करता है: sed 's/./@/' <<<$'\xfc'विफल रहता है, क्योंकि बाइट 0xfcएक मान्य UTF-8 वर्ण नहीं है।
ध्यान दें कि, इसके विपरीत, जीएनयू sed (लिनक्स, लेकिन मैकओएस पर इंस्टॉल करने योग्य) बस एक त्रुटि रिपोर्ट किए बिना, अमान्य बाइट से गुजरता है।}

पूर्व में स्वीकार किए गए उत्तर का उपयोग करना एक विकल्प है, यदि आपको अपने वास्तविक स्थान के लिए समर्थन खोने का मन नहीं है (यदि आप यूएस सिस्टम पर हैं और आपको विदेशी वर्णों से निपटने की आवश्यकता नहीं है, तो यह ठीक हो सकता है।)

हालाँकि, एक ही प्रभाव केवल एक आदेश के लिए तदर्थ हो सकता है :

LC_ALL=C sed -i "" 's|"iphoneos-cross","llvm-gcc:-O3|"iphoneos-cross","clang:-Os|g' Configure

नोट: क्या मायने रखती है एक है प्रभावी LC_CTYPE की स्थापना C, इसलिए LC_CTYPE=C sed ...होता है सामान्य रूप से भी काम करते हैं, लेकिन अगर LC_ALL(अलावा कुछ करने के लिए सेट होता है C), यह अलग-अलग स्थान पर आ जाएगी LC_*जैसे -category चर LC_CTYPE। इस प्रकार, सबसे मजबूत दृष्टिकोण सेट करना है LC_ALL।

हालांकि, (प्रभावी रूप से) स्ट्रिंग्स LC_CTYPEको Cव्यवहार करने के लिए सेट करता है जैसे कि प्रत्येक बाइट का अपना चरित्र था ( एन्कोडिंग नियमों पर आधारित कोई व्याख्या नहीं की गई है), मल्टीबाइट-ऑन-डिमांड के लिए कोई संबंध नहीं है - यूटीएफ -8 एन्कोडिंग जो ओएस एक्स डिफ़ॉल्ट रूप से काम करता है। , जहां विदेशी पात्रों में बहुसंख्यक एनकोडिंग हैं ।

संक्षेप में: स्थापित करने LC_CTYPEके लिएC कारण बनता है खोल और उपयोगिताओं केवल अक्षर के रूप में बुनियादी अंग्रेजी अक्षरों (7-बिट ASCII रेंज में हैं) को मान्यता देने, ताकि विदेशी वर्ण। उदाहरण के लिए, अपर-लोअरकेस रूपांतरणों को विफल करने के लिए अक्षरों के रूप में व्यवहार नहीं किया जाएगा ।

फिर, यह ठीक हो सकता है यदि आपको मल्टीबाइट-एन्कोडेड वर्णों जैसे कि मेल नहीं खाते हैंé , और बस ऐसे पात्रों को पास करना चाहते हैं ।

यदि यह अपर्याप्त है और / या आप मूल त्रुटि के कारण को समझना चाहते हैं (यह निर्धारित करना कि इनपुट बाइट्स की समस्या क्या है) और मांग पर एन्कोडिंग रूपांतरण करें, नीचे पढ़ें ।

---

समस्या यह है कि इनपुट फ़ाइल की एन्कोडिंग शेल के मेल से मेल नहीं खाती है।
अधिक विशेष रूप से, इनपुट फ़ाइल में वर्ण शामिल हैं जो UTF-8 में मान्य नहीं है (जैसा कि @Klas Lindbäck ने एक टिप्पणी में कहा है) - यही sedत्रुटि संदेश द्वारा कहने की कोशिश कर रहा है invalid byte sequence।

सबसे अधिक संभावना है, आपकी इनपुट फ़ाइल एकल-बाइट 8-बिट एन्कोडिंग का उपयोग करती है जैसे कि ISO-8859-1, अक्सर "पश्चिमी यूरोपीय" भाषाओं को एन्कोड करने के लिए उपयोग किया जाता है।

उदाहरण:

उच्चारण पत्र àमें यूनिकोड कोडपॉइंट 0xE0(224) है - उसी में ISO-8859-1। हालांकि, की प्रकृति के कारण UTF-8 एन्कोडिंग, इस एकल कोडपॉइंट के रूप में प्रस्तुत किया जाता है 2 बाइट्स - 0xC3 0xA0, जबकि पारित करने के लिए कोशिश कर रहा एक बाइट 0xE0 है अवैध UTF-8 के तहत।

यहाँ एक बाइट (ANSI-C- उद्धृत बैश स्ट्रिंग ( ) जो बाइट बनाने के लिए उपयोग होती है ) के रूप में प्रतिनिधित्व के साथ, एन्कोडेड स्ट्रिंग का उपयोग करके समस्या का प्रदर्शन है।voilàISO-8859-1à$'...'\x{e0}

ध्यान दें कि sedकमांड प्रभावी रूप से एक नो-ऑप है जो केवल इनपुट से गुजरता है, लेकिन हमें त्रुटि को भड़काने के लिए इसकी आवश्यकता है:

  # -> 'illegal byte sequence': byte 0xE0 is not a valid char.
sed 's/.*/&/' <<<$'voil\x{e0}'

बस समस्या को अनदेखा करने के लिए , उपरोक्त LCTYPE=Cदृष्टिकोण का उपयोग किया जा सकता है:

  # No error, bytes are passed through ('á' will render as '?', though).
LC_CTYPE=C sed 's/.*/&/' <<<$'voil\x{e0}'

यदि आप यह निर्धारित करना चाहते हैं कि इनपुट के कौन से हिस्से समस्या का कारण बनते हैं , तो निम्न प्रयास करें:

  # Convert bytes in the 8-bit range (high bit set) to hex. representation.
  # -> 'voil\x{e0}'
iconv -f ASCII --byte-subst='\x{%02x}' <<<$'voil\x{e0}'

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

---

मांग पर एन्कोडिंग रूपांतरण करना :

मानक उपयोगिता iconvका उपयोग ( -t) और / या ( -f) एन्कोडिंग में बदलने के लिए किया जा सकता है ; iconv -lसभी समर्थित लोगों को सूचीबद्ध करता है।

उदाहरण:

उपरोक्त उदाहरण पर निर्माण, ISO-8859-1शेल में प्रभाव से एन्कोडिंग में कनवर्ट करें ( LC_CTYPEजो UTF-8डिफ़ॉल्ट रूप से आधारित है),

  # Converts to UTF-8; output renders correctly as 'voilà'
sed 's/.*/&/' <<<"$(iconv -f ISO-8859-1 <<<$'voil\x{e0}')"

ध्यान दें कि यह रूपांतरण आपको विदेशी पात्रों से ठीक से मेल खाने देता है :

  # Correctly matches 'à' and replaces it with 'ü': -> 'voilü'
sed 's/à/ü/' <<<"$(iconv -f ISO-8859-1 <<<$'voil\x{e0}')"

ISO-8859-1प्रोसेसिंग के बाद इनपुट BACK को कन्वर्ट करने के लिए , परिणाम को दूसरे iconvकमांड पर पाइप करें :

sed 's/à/ü/' <<<"$(iconv -f ISO-8859-1 <<<$'voil\x{e0}')" | iconv -t ISO-8859-1

Comments

मैं कहूंगा कि यह एक बेहतर विकल्प है। सबसे पहले, मैं सभी टर्मिनल में बहु-भाषा समर्थन खोना नहीं चाहूंगा। दूसरा, स्वीकृत उत्तर एक स्थानीय समस्या के वैश्विक समाधान की तरह लगता है - इससे बचने के लिए कुछ।

— एलेक्स

मैं इस के लिए छोटे tweaks के एक जोड़े था। मैं प्रतिक्रिया की सराहना करता हूं। stackoverflow.com/a/35046218/9636

— हीथ बॉर्डर

LC_CTYPE=C sed 's/.*/&/' <<<$'voil\x{e0}'sed: RE error: illegal byte sequenceसिएरा पर मेरे लिए प्रिंट । एफडब्ल्यूआईडब्ल्यू को echo $LC_ALLआउटपुट करता है en_US.UTF-8।

— ahox

@ahcox: हाँ, क्योंकि सेटिंग उत्तर में बताए गए सहित अन्य सभी चर को LC_ALL ओवरराइड करती है । LC_*LC_CTYPE

— mklement0

@ mklement0 कूल, यह काम करता है: "LC_ALL = C sed 's /.*/&/' <<< $ 'voil \ x {e0}'"। वरीयता मेरे साथी के लिए यहाँ समझाया अज्ञानतावश

— ahcox

Answer 2

निम्न पंक्तियों को अपनी फ़ाइल ~/.bash_profileया ~/.zshrcफ़ाइल में जोड़ें ।

export LC_CTYPE=C 
export LANG=C

Comments

यह वास्तव में काम करता है, लेकिन क्या आप कृपया बता सकते हैं कि क्यों?

— होंग फाम

@HoangPham: किसी भी एन्कोडिंग नियमों को लागू किए बिना स्ट्रिंग्स में प्रत्येक बाइट को अपने चरित्र LC_CTYPEका Cकारण बनता है। चूंकि (UTF-8) एन्कोडिंग नियमों के उल्लंघन के कारण मूल समस्या उत्पन्न हुई, इससे समस्या दूर हो जाती है। हालाँकि, आपके द्वारा भुगतान किया जाने वाला मूल्य यह है कि शेल और उपयोगिताओं के बाद केवल मूल अंग्रेजी अक्षरों (7-बिट ASCII रेंज में) को अक्षरों के रूप में पहचानते हैं। अधिक के लिए मेरा जवाब देखें।

— mklement0

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

— ट्रिपल

बहुत खतरनाक अप्रत्याशित परिणाम पैदा कर सकता है। एक का उपयोग कर सकता है LC_CTYPE=C sed …, यानी केवल sed कमांड पर।

— योंगवेई वू

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

— 21

Answer 3

मेरे समाधान में पर्ल का उपयोग किया गया था:

find . -type f -print0 | xargs -0 perl -pi -e 's/was/now/g'

Comments

यह एक महान काम करता है। और मेरे पास दूसरों के विपरीत विशेष पात्रों से बचने में कोई त्रुटि नहीं है। पिछले लोगों ने मुझे "sed: RE error: अवैध बाइट अनुक्रम" या sed: 1: "path_to_file": अमान्य कमांड कोड जैसे मुद्दे दिए।

— JMags1632

Answer 4

mklement0 का उत्तर बहुत अच्छा है, लेकिन मेरे पास कुछ छोटे ट्वीक्स हैं ।

इसका bashउपयोग करते समय स्पष्ट रूप से एन्कोडिंग निर्दिष्ट करने के लिए एक अच्छा विचार है iconv। इसके अलावा, हमें एक बाइट-ऑर्डर मार्क ( भले ही यूनिकोड मानक इसकी अनुशंसा नहीं करता हो ) को रोकना चाहिए क्योंकि यूटीएफ -8 और एएससीआईआई के बीच बाइट-ऑर्डर मार्क के बिना वैध भ्रम हो सकते हैं । दुर्भाग्य से, iconvजब आप स्पष्ट रूप से एक एंडियननेस ( UTF-16BEया UTF-16LE) निर्दिष्ट करते हैं , तो एक बाइट-ऑर्डर मार्क को प्रीपेन्ड नहीं करता है , इसलिए हमें उपयोग करने की आवश्यकता है UTF-16, जो प्लेटफ़ॉर्म-विशिष्ट एंडियननेस का उपयोग करता है, और फिर उपयोग किए file --mime-encodingगए सही एंडियननेस का पता लगाने के लिए iconvउपयोग करता है।

(मैं अपने सभी एन्कोडिंग्स को अपरकेस करता हूं क्योंकि जब आप सभी iconvसमर्थित एनकोडिंग्स को सूचीबद्ध iconv -lकरते हैं, तो वे सभी अपरकेस हैं।)

# Find out MY_FILE's encoding
# We'll convert back to this at the end
FILE_ENCODING="$( file --brief --mime-encoding MY_FILE )"
# Find out bash's encoding, with which we should encode
# MY_FILE so sed doesn't fail with 
# sed: RE error: illegal byte sequence
BASH_ENCODING="$( locale charmap | tr [:lower:] [:upper:] )"
# Convert to UTF-16 (unknown endianness) so iconv ensures
# we have a byte-order mark
iconv -f "$FILE_ENCODING" -t UTF-16 MY_FILE > MY_FILE.utf16_encoding
# Whether we're using UTF-16BE or UTF-16LE
UTF16_ENCODING="$( file --brief --mime-encoding MY_FILE.utf16_encoding )"
# Now we can use MY_FILE.bash_encoding with sed
iconv -f "$UTF16_ENCODING" -t "$BASH_ENCODING" MY_FILE.utf16_encoding > MY_FILE.bash_encoding
# sed!
sed 's/.*/&/' MY_FILE.bash_encoding > MY_FILE_SEDDED.bash_encoding
# now convert MY_FILE_SEDDED.bash_encoding back to its original encoding
iconv -f "$BASH_ENCODING" -t "$FILE_ENCODING" MY_FILE_SEDDED.bash_encoding > MY_FILE_SEDDED
# Now MY_FILE_SEDDED has been processed by sed, and is in the same encoding as MY_FILE

Comments

++ सहायक तकनीकों के लिए, विशेष रूप से file -b --mime-encodingफ़ाइल की एन्कोडिंग की खोज और रिपोर्टिंग के लिए। हालांकि, संबोधित करने लायक कुछ पहलू हैं, जो मैं अलग-अलग टिप्पणियों में करूँगा।

— mklement0

मुझे लगता है कि यह कहना सुरक्षित है कि यूनिक्स दुनिया ने इस बिंदु पर यूटीएफ -8 को अपनाया है: डिफ़ॉल्ट LC_CTYPEमूल्य आमतौर पर है <lang_region>.UTF-8, इसलिए बिना बीओएम (बाइट-ऑर्डर मार्क) के किसी भी फ़ाइल को यूटीएफ -8 फ़ाइल के रूप में व्याख्या की जाती है। यह केवल विंडोज की दुनिया में है कि छद्म बीओएम 0xef 0xbb 0xff का उपयोग किया जाता है; परिभाषा के अनुसार, यूटीएफ -8 को बीओएम की आवश्यकता नहीं है और यह अनुशंसित नहीं है (जैसा कि आप राज्य); विंडोज की दुनिया के बाहर, इस छद्म BOM के कारण चीजें टूट जाती हैं ।

— mklement0

पुन Unfortunately, iconv doesn't prepend a byte-order mark when you explicitly specify an endianness (UTF-16BE or UTF-16LE): यह डिज़ाइन द्वारा है: यदि आप स्पष्टता को स्पष्ट रूप से निर्दिष्ट करते हैं , तो BOM के माध्यम से इसे प्रतिबिंबित करने की भी आवश्यकता नहीं है, इसलिए कोई भी जोड़ा नहीं गया है।

— mklement0

पुन LC_*/ LANGचर: bash, ksh, और zsh(संभवतः दूसरों, लेकिन नहीं dash ) वर्ण एन्कोडिंग का सम्मान करते हैं; एक UTF-8-आधारित लोकेल के साथ POSIX- जैसे गोले में सत्यापित करें v='ä'; echo "${#v}": UTF-8 जागरूक शेल को रिपोर्ट करना चाहिए 1; यानी, इसे एकल चरित्र के रूप में मल्टी-बाइट अनुक्रम ä( 0xc3 0xa4) को पहचानना चाहिए । शायद और भी अधिक महत्वपूर्ण बात, तथापि: मानक उपयोगिताओं ( , , , ...) भी स्थान होने के लिए / एन्कोडिंग अवगत की जरूरत है, और जब तक सबसे पर उनमें से आधुनिक यूनिक्स की तरह प्लेटफार्मों हैं, वहाँ इस तरह के रूप अपवाद भी हैं OSX पर, और लिनक्स पर। sedawkcutawkcut

— mklement0

यह सराहनीय है कि fileUTF-8 छद्म BOM को पहचानता है, लेकिन समस्या यह है कि अधिकांश यूनिक्स उपयोगिताओं जो प्रक्रिया फ़ाइल नहीं करती हैं , और आमतौर पर एक के साथ सामना करने पर कम से कम या कम से कम दुर्व्यवहार को तोड़ती हैं। BOM के बिना, fileASCII के रूप में एक ऑल-7-बिट बाइट फ़ाइल को सही ढंग से पहचानता है, और जिसमें UTF-8 के रूप में मान्य UTF-8 मल्टी-बाइट वर्ण होते हैं। UTF-8 की सुंदरता यह है कि यह ASCII का सुपरसेट है: कोई भी मान्य ASCII फाइल एक वैध UTF-8 फ़ाइल (लेकिन इसके विपरीत नहीं) है; यह पूरी तरह से सुरक्षित है ASCII फ़ाइल को UTF-8 के रूप में

— मानने के लिए

Answer 5

आपको बस sed कमांड से पहले एक iconv कमांड को पाइप करना होगा । File.txt इनपुट के साथ पूर्व:

iconv -f ISO-8859-1 -t UTF8-MAC file.txt | sed 's / something / àéèêç s / g' | .....

-f विकल्प 'से' कोडसेट और -t का विकल्प 'से' कोडसेट रूपांतरण है।

मामले का ध्यान रखें, वेब पेज आमतौर पर लोअरकेस दिखाते हैं जैसे कि <charset = iso-8859-1 "/> और iconv अपरकेस का उपयोग करता है। आपके पास कमांड आइकॉन -l के साथ सिस्टम में iconv समर्थित कोडसेट की सूची है।

UTF8-MAC रूपांतरण के लिए आधुनिक ओएस मैक कोडसेट है।

Comments

Iconv मेलिंग सूची पर iconv और charset नाम भी देखें ।

— jww

Answer 6

क्या किसी को पता है कि अवैध बाइट अनुक्रम की स्थिति को कैसे प्रिंट किया जाए? या किसी को पता है कि अवैध बाइट अनुक्रम क्या है?

$ uname -a
Darwin Adams-iMac 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64

मैं सिर्फ tr का उपयोग करके उपरोक्त उत्तर देने के तरीके का हिस्सा बन गया ।

मेरे पास एक .csv फ़ाइल है जो एक क्रेडिट कार्ड स्टेटमेंट है और मैं इसे Gnucash में आयात करने का प्रयास कर रहा हूं। मैं स्विट्जरलैंड में आधारित हूं इसलिए मुझे ज़्यूरिख़ जैसे शब्दों से निपटना होगा। ग्नुकैश पर संदेह संख्यात्मक क्षेत्रों में "" पसंद नहीं है, मैं बस सभी को बदलने का फैसला करता हूं

; ;

साथ में

;;

यहाँ जाता हैं:

$ head -3 Auswertungen.csv | tail -1 | sed -e 's/; ;/;;/g'
sed: RE error: illegal byte sequence

मैंने कुछ प्रकाश डालने के लिए od का उपयोग किया है : इस od -c आउटपुट को 374 आधा नीचे नोट करें

$ head -3 Auswertungen.csv | tail -1 | od -c
0000000    1   6   8   7       9   6   1   9       7   1   2   2   ;   5
0000020    4   6   8       8   7   X   X       X   X   X   X       2   6
0000040    6   0   ;   M   Y       N   A   M   E       I   S   X   ;   1
0000060    4   .   0   2   .   2   0   1   9   ;   9   5   5   2       -
0000100        M   i   t   a   r   b   e   i   t   e   r   r   e   s   t
0000120                Z 374   r   i   c   h                            
0000140    C   H   E   ;   R   e   s   t   a   u   r   a   n   t   s   ,
0000160        B   a   r   s   ;   6   .   2   0   ;   C   H   F   ;    
0000200    ;   C   H   F   ;   6   .   2   0   ;       ;   1   5   .   0
0000220    2   .   2   0   1   9  \n                                    
0000227

फिर मैंने सोचा कि मैं के लिए राजी करने की कोशिश कर सकते टीआर जो कुछ भी सही बाइट कोड है के लिए 374 से प्रतिस्थापित करने का। इसलिए पहले मैंने कुछ सरल करने की कोशिश की, जो काम नहीं आया, लेकिन मुझे यह दिखाने का दुष्प्रभाव था कि परेशान करने वाली बाइट कहां थी:

$ head -3 Auswertungen.csv | tail -1 | tr . .  ; echo
tr: Illegal byte sequence
1687 9619 7122;5468 87XX XXXX 2660;MY NAME ISX;14.02.2019;9552 - Mitarbeiterrest   Z

आप 374 कैरेक्टर में tr बेल देख सकते हैं ।

पर्ल का उपयोग इस समस्या से बचने के लिए लगता है

$ head -3 Auswertungen.csv | tail -1 | perl -pne 's/; ;/;;/g'
1687 9619 7122;5468 87XX XXXX 2660;ADAM NEALIS;14.02.2019;9552 - Mitarbeiterrest   Z?rich       CHE;Restaurants, Bars;6.20;CHF;;CHF;6.20;;15.02.2019

Answer 7

मेरे काम करने के लिए gnu का उपयोग किया गया था sed। मेरे उद्देश्यों के लिए ठीक काम किया।

Comments

वास्तव में, जीएनयू sed एक विकल्प है यदि आप इनपुट स्ट्रीम में अमान्य बाइट्स को अनदेखा करना चाहते हैं ( LC_ALL=C sed ...वर्कअराउंड की कोई आवश्यकता नहीं है ), क्योंकि जीएनयू sedकेवल एक त्रुटि की रिपोर्ट करने के बजाय अमान्य बाइट्स से गुजरता है , लेकिन ध्यान दें कि यदि आप सभी को ठीक से पहचानना और प्रक्रिया करना चाहते हैं इनपुट स्ट्रिंग में वर्ण, इनपुट के एन्कोडिंग को बदलने का कोई तरीका नहीं है iconv।

— mklement0