YamlBox के बारे में प्रश्न

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

--- द्वारा अलग किए गए दस्तावेज़ों को अलग-अलग पार्स किया जाता है और एक JSON सरणी में संयोजित किया जाता है, प्रति दस्तावेज़ एक ऑब्जेक्ट। यदि आप केवल पहला दस्तावेज़ चाहते हैं, तो बहु-दस्तावेज़ विकल्प को "केवल पहला दस्तावेज़" पर स्विच करें।

हाँ। कोई भी मान्य YAML 1.2 कार्य: Kubernetes मैनिफ़ेस्ट, docker-compose.yml, GitHub Actions और GitLab CI पाइपलाइन, अन्सिबल प्लेबुक, ओपनएपीआई स्पेक्स और Helm मान फ़ाइलें। Helm टेम्प्लेट द्वारा उपयोग किए गए एंकर और उपनामों को उनके अंतिम मानों तक हल किया जाता है।

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

टिप्पणियाँ JSON में मौजूद नहीं हैं, इसलिए उन्हें हटा दिया गया है। यदि आपको उन्हें संरक्षित करने की आवश्यकता है, तो YAML को सत्य के स्रोत के रूप में रखें और JSON को एक निर्मित कलाकृति के रूप में मानें।

कुछ मेगाबाइट तक की फ़ाइलें मिलीसेकंड में परिवर्तित हो जाती हैं। अत्यधिक बड़ी फ़ाइलें (दसियों मेगाबाइट) आपकी डिवाइस मेमोरी पर निर्भर करती हैं; एक डेस्कटॉप ब्राउज़र उन्हें आराम से संभालता है जहां एक फोन नहीं संभाल सकता।

क्योंकि यह JSON स्रोत में एक संख्या थी, और YAML संख्याओं को विहित रूप से प्रस्तुत करता है। यदि मान शब्दार्थ रूप से एक संस्करण या पहचानकर्ता है, तो "बल उद्धरण" चालू करें ताकि यह YAML में एक स्ट्रिंग बना रहे।

हाँ। जनरेटर किसी भी कुंजी को उद्धृत करता है जो YAML पार्सर को भ्रमित कर सकता है और सादे कुंजियों को बिना उद्धृत किए छोड़ देता है, इसलिए आउटपुट पठनीय लेकिन स्पष्ट रहता है।

हां - इसे पेस्ट करें, फ़ाइल को इनपुट फलक पर छोड़ें, या फ़ाइल बटन का उपयोग करें। डेस्कटॉप ब्राउज़र में मल्टी-मेगाबाइट दस्तावेज़ ठीक हैं; रूपांतरण में ही मिलीसेकंड लगते हैं।

डिफ़ॉल्ट रूप से, हाँ - कुंजियाँ अपना JSON क्रम बनाए रखती हैं। जब आप एक नियतात्मक, वर्णानुक्रमित फ़ाइल चाहते हैं जो संस्करण नियंत्रण में स्पष्ट अंतर उत्पन्न करती है तो "सॉर्ट कुंजियाँ" सक्षम करें।

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

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

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

हाँ - "सॉर्ट कुंजियाँ" सक्षम करें और कुंजियाँ हर स्तर पर पुनरावर्ती रूप से क्रमबद्ध की जाती हैं। यह फ़ाइलों को नियतिवादी बनाता है, इसलिए संस्करण नियंत्रण अंतर केवल वास्तविक परिवर्तन दिखाता है।

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

एक टेक्स्ट अंतर रेखाओं की तुलना करता है, इसलिए कुंजियों को पुन: स्वरूपित करने या पुन: व्यवस्थित करने से शोर पैदा होता है। यह उपकरण दोनों दस्तावेज़ों को पार्स करता है और पथ के आधार पर मानों की तुलना करता है, इसलिए यह केवल वास्तविक अर्थ संबंधी परिवर्तनों की रिपोर्ट करता है।

हाँ - सरणियों की तुलना तत्व दर तत्व की जाती है। एक तत्व जो एक दस्तावेज़ में मौजूद है, लेकिन दूसरे में नहीं, $.users[2] जैसे अनुक्रमित पथ पर जोड़े या हटाए जाने की सूचना दी जाती है।

हाँ। मुख्य आदेश अप्रासंगिक है क्योंकि दोनों दस्तावेज़ों को पहले पार्स किया गया है। {"a":1,"b":2} और {"b":2,"a":1} की तुलना समान है।

पहले उन्हें दूसरे टैब में YAML से JSON कनवर्टर के साथ कनवर्ट करें, फिर दोनों JSON आउटपुट को यहां पेस्ट करें। क्योंकि अंतर संरचनात्मक है, पहले YAML को JSON में परिवर्तित करने से परिणाम प्रभावित नहीं होता है।

आपके द्वारा प्रदान किए गए नमूने के लिए प्रकार और संरचना सटीक हैं। जो निष्कर्ष नहीं पता चल सकता वह व्यावसायिक नियम है - कि एक आयु सकारात्मक होनी चाहिए, या यह कि एक क्षेत्र एक गणना है। आउटपुट को एक मजबूत शुरुआती बिंदु मानें और हाथ से बाधाएं जोड़ें।

आइटम स्कीमा को मर्ज कर दिया जाता है: प्रत्येक आइटम में मौजूद गुण आवश्यक हो जाते हैं, और केवल कुछ आइटम में मौजूद गुण वैकल्पिक रहते हैं। प्रकार के अंतर एक संघ का निर्माण करते हैं जैसे कि प्रकार: ["स्ट्रिंग", "संख्या"]।

यदि आपका सत्यापनकर्ता AJV 6/7 है, पुराने संपादक हैं, या हाल ही में अपडेट नहीं किया गया कुछ भी है तो ड्राफ्ट-07 चुनें - इसका व्यापक समर्थन है और अधिकांश ओपनएपीआई 3.0 टूलिंग यही अपेक्षा करते हैं। नई परियोजनाओं और एजेवी 8 के लिए 2020-12 चुनें।

रनटाइम जांच के लिए एजेवी और अन्य सत्यापनकर्ता, आपकी JSON फ़ाइलों के स्वत: पूर्ण और सत्यापन के लिए वीएस कोड, दस्तावेज़ API प्रतिक्रियाओं के लिए ओपनएपीआई विनिर्देश, और जब कोई प्रतिक्रिया अनुबंध से हटती है तो विफल होने के लिए सीआई पाइपलाइन।

जब इनपुट वस्तुओं की एक सरणी होती है, तो प्रत्येक आइटम में प्रत्येक संपत्ति की जाँच की जाती है। कुछ वस्तुओं में गायब कुंजी को ? के साथ वैकल्पिक रूप से चिह्नित किया जाता है, और हर जगह मौजूद कुंजी आवश्यक रहती है।

एक शून्य को अपने स्वयं के एक प्रकार के रूप में माना जाता है, इसलिए एक फ़ील्ड जो कभी-कभी एक स्ट्रिंग होती है और कभी-कभी शून्य टाइप की गई स्ट्रिंग होती है अशक्त - आपके कंपाइलर द्वारा भरोसा किए गए झूठ के बजाय एक ईमानदार प्रकार।

इंटरफ़ेस अधिक सामान्य परिपाटी है और घोषणाओं में अच्छी तरह से विलीन हो जाता है; यूनियनों और चौराहों के लिए प्रकार के उपनाम बेहतर ढंग से पढ़े जाते हैं। कार्यात्मक रूप से, उत्पन्न डेटा आकृतियों के लिए, या तो काम करता है - आपके मौजूदा कोडबेस से मेल खाता है।

प्रत्यक्ष नहीं। उसी पेलोड से JSON स्कीमा उत्पन्न करें और एक सत्यापनकर्ता प्राप्त करें, या ज़ोड स्कीमा को हाथ से लिखें और स्थिर पक्ष के लिए इन इंटरफेस का उपयोग करें। प्रकार संकलन समय पर आकार का वर्णन करते हैं; सत्यापनकर्ता रनटाइम पर आपकी सुरक्षा करते हैं।

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

एक JSON null को सादे स्ट्रिंग या int में संग्रहित नहीं किया जा सकता है, इसलिए एक nullable फ़ील्ड को एक पॉइंटर (*string, *int) मिलता है। यह एन्कोडिंग/जेसन को बिना असफल हुए "अनुपस्थित" और "वर्तमान लेकिन शून्य" के बीच अंतर करने देता है, जो वास्तव में सूचक प्रकारों के लिए है।

यदि कोई मान एक आइटम में एक स्ट्रिंग है और दूसरे में एक संख्या है, तो जनरेटर गलत ठोस प्रकार का आविष्कार करने के बजाय किसी का भी उपयोग करता है। यदि API वास्तव में इतना ढीला है तो आप एक कस्टम UnmarshalJSON पर निर्णय ले सकते हैं।

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

हाँ - टैब, संरेखण और फ़ील्ड ऑर्डरिंग gofmt सम्मेलनों का पालन करते हैं। चिपकाने के बाद gofmt -l चलाएँ और इसमें कोई परिवर्तन नहीं होना चाहिए।

हाँ। नेस्टेड ऑब्जेक्ट अलग-अलग नामित संरचनाएं बन जाते हैं जबकि पार्स किए गए JSON में साइकिल चलाना असंभव है, इसलिए गहराई से नेस्टेड पेलोड भी एक फ्लैट, पठनीय प्रकार का सेट उत्पन्न करते हैं।

प्रत्येक कॉलम को सभी पंक्तियों में स्कैन किया जाता है। सभी पूर्णांक पूर्णांक/INT बन जाते हैं, कोई भी दशमलव संख्यात्मक/दोहरा हो जाता है, बूलियन बूलियन बन जाता है, JSON-दिखने वाली स्ट्रिंग TIMESTAMPTZ बन जाती है, और नेस्टेड ऑब्जेक्ट या सरणियाँ बोली के आधार पर JSONB/JSON/TEXT बन जाती हैं।

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

वे नेस्टेड मान धारण करने वाला एकल JSON/JSONB/TEXT कॉलम बन जाते हैं। नेस्टेड संरचनाओं का रिलेशनल मॉडलिंग एक डिज़ाइन निर्णय है, इसलिए जनरेटर आपके लिए जुड़ने का अनुमान नहीं लगाता है।

यदि आप JSONB और TIMESTAMPTZ चाहते हैं तो PostgreSQL, डबल न्यूमेरिक्स वाले JSON कॉलम के लिए MySQL, फ़ाइल-आधारित डेटाबेस और परीक्षणों के लिए SQLite। स्क्रिप्ट की संरचना समान है; केवल प्रकार के नाम और बूलियन अक्षर बदलते हैं।

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

सही - पार्सर RFC 4180 का अनुसरण करता है, इसलिए "हॉपर, पीएचडी" एक फ़ील्ड है, दो नहीं। एंबेडेड दोहरे उद्धरण चिह्न हटा दिए गए हैं, और बहु-पंक्ति उद्धृत मान संरक्षित हैं।

हाँ। डिलीमीटर का पहली पंक्ति से स्वतः पता लगाया जाता है, और आप विकल्प बार में स्पष्ट रूप से विकल्प को ओवरराइड कर सकते हैं।

JSON लाइनें (प्रति पंक्ति एक JSON ऑब्जेक्ट) वह प्रारूप है जिसकी अपेक्षा अधिकांश डेटा टूल, लॉग प्रोसेसर और एलएलएम पाइपलाइन करते हैं। यह बेहतर स्ट्रीम भी करता है: प्रत्येक पंक्ति को स्वतंत्र रूप से संसाधित किया जा सकता है।

कोई कृत्रिम सीमा नहीं - बहुत बड़ी फ़ाइलें केवल आपके ब्राउज़र की मेमोरी तक सीमित होती हैं। एक 50 एमबी CSV एक सामान्य लैपटॉप पर आराम से परिवर्तित हो जाता है।

उन्हें डॉट नोटेशन के साथ चपटा किया जाता है, इसलिए {"ग्राहक":{"नाम":"एडीए"}} कॉलम ग्राहक नाम बन जाता है। नेस्टेड सरणियों को सार्थक रूप से चपटा नहीं किया जा सकता है और सेल के अंदर JSON के रूप में क्रमबद्ध किया जाता है।

कॉलम सूची सभी रिकॉर्ड्स में सभी कुंजियों का संघ है। एक गुम कुंजी बस एक खाली सेल उत्पन्न करती है, जो प्रत्येक पंक्ति को एक ही हेडर से संरेखित रखती है।

हाँ। आउटपुट UTF-8 एन्कोडिंग के साथ मानक RFC 4180 CSV है। एक्सेल में, डेटा → टेक्स्ट से/CSV का उपयोग करें यदि डबल-क्लिक करने से पुराने संस्करणों पर एन्कोडिंग बाधित हो जाती है।

हां - प्रत्येक पंक्ति को एक रिकॉर्ड के रूप में पार्स किया जाता है, इसलिए JSONL इनपुट एक समान तालिका को समकक्ष JSON सरणी के रूप में उत्पन्न करता है।

XML एक ही नाम के साथ एक विशेषता और एक चाइल्ड तत्व की अनुमति देता है, जिसे JSON एक कुंजी के साथ व्यक्त नहीं किया जा सकता है। @ उपसर्ग विशेषताओं को तत्वों से अलग रखता है, इसलिए रूपांतरण में कुछ भी खो नहीं जाता है।

जब एक ही टैग भाई-बहनों के बीच एक से अधिक बार दिखाई देता है, तो मान एक JSON सरणी बन जाते हैं। एक एकल घटना एक अदिश या वस्तु बनी रहती है - यही कारण है कि उपभोक्ताओं को दोनों को सहन करना चाहिए, या आपको अपने कोड में सामान्यीकरण क्यों करना चाहिए।

हाँ। नामांकित तत्व अपने स्थानीय नाम रखते हैं, और उपसर्ग टकराव को स्रोत में लिखे अनुसार संरक्षित किया जाता है। यदि आपको पूर्ण नामस्थान निष्ठा की आवश्यकता है, तो मूल XML को JSON के साथ रखें।

हां - लिफाफा और बॉडी किसी भी अन्य XML की तरह परिवर्तित हो जाती है। SOAP के लिए, कास्टिंग सक्षम रखें ताकि संख्यात्मक फ़ील्ड स्ट्रिंग के बजाय संख्याओं के रूप में आएं।

नहीं, .xlsx फ़ाइल को बंडल रीडर का उपयोग करके आपके ब्राउज़र टैब में जावास्क्रिप्ट द्वारा पार्स किया जाता है। यह आपके डिवाइस को कभी नहीं छोड़ता है, जो टूल को HR, वित्त और ग्राहक डेटा के लिए सुरक्षित बनाता है।

.xlsx (एक्सेल 2007 और बाद में) और .csv। लीगेसी बाइनरी .xls प्रारूप समर्थित नहीं है - इसे Excel में खोलें और पहले .xlsx या .csv के रूप में सहेजें।

एक्सेल द्वारा संग्रहित कैश्ड मानों का उपयोग किया जाता है। यदि कोई फ़ाइल सूत्रों के साथ सहेजी गई थी लेकिन कैश्ड परिणामों के बिना - दुर्लभ, लेकिन संभव है - वे कोशिकाएं खाली हो सकती हैं। एक्सेल में दोबारा सेव करने से कैश रिफ्रेश हो जाता है।

एक्सेल दिनांकों को क्रमांक के रूप में संग्रहीत करता है; पाठक उन्हें जावास्क्रिप्ट तिथियों में परिवर्तित करता है और आईएसओ स्ट्रिंग उत्सर्जित करता है, इसलिए "2025-03-14" 45730 के बजाय पाठ के रूप में आता है।

<track> तत्व, और प्रत्येक प्रमुख ब्राउज़र प्लेयर, WebVTT विनिर्देश लागू करता है। SRT प्रसारण टूलींग से एक विरासत प्रारूप है - जो खिलाड़ी इसे स्वीकार करते हैं वे आमतौर पर आंतरिक रूप से, अपूर्ण रूप से परिवर्तित होते हैं।

नहीं, रूपांतरण एक क्लाइंट-साइड टेक्स्ट परिवर्तन है। गोपनीय या अप्रकाशित सामग्री ब्राउज़र को कभी नहीं छोड़ती है, जो अक्सर स्टूडियो के लिए एक संविदात्मक आवश्यकता होती है।

WebVTT को उनकी आवश्यकता नहीं है, और वे वैकल्पिक हैं। डिफ़ॉल्ट रूप से संकेतों को क्रमिक रूप से पुनः क्रमांकित किया जाता है; आप नंबरिंग को पूरी तरह से बंद कर सकते हैं.

हां - SRT <b>/<i>/<u> टैग मान्य WebVTT हैं और संरक्षित हैं। SRT-विशिष्ट {an8}-शैली पोज़िशनिंग ओवरराइड हटा दिए जाते हैं, क्योंकि WebVTT पोज़िशनिंग को अलग ढंग से व्यक्त करता है।

यह सामान्य वास्तविक दुनिया की विचित्रताओं को सहन करता है: , या . मिलीसेकंड में, एक-अंकीय घंटे, मान्य टाइमकोड के साथ संकेतों के बीच रिक्त रेखाएँ गायब। वास्तव में टूटी हुई फाइलों को मौन भ्रष्टाचार के बजाय स्पष्ट त्रुटि मिलती है।

इस टूल के साथ, टोकन के लिए ही - डिकोडिंग आपके ब्राउज़र में शुद्ध जावास्क्रिप्ट है और कहीं भी कुछ भी नहीं भेजा जाता है। लेकिन टोकन को बिना किसी परवाह के रहस्य मानें: एक JWT एक धारक क्रेडेंशियल है, जो इसे समाप्त होने तक अपने पास रखता है उसके लिए मान्य है। उत्पादन टोकन के लिए, अपने स्वयं के डिबगर में स्थानीय रूप से डिकोडिंग को प्राथमिकता दें।

नहीं, और न ही कोई डिकोडर आपकी गुप्त या सार्वजनिक कुंजी के बिना काम करता है। केवल बेस64यूआरएल को डिकोड करने से खंडों को डिकोड किया जाता है। सत्यापन के लिए हस्ताक्षर कुंजी की आवश्यकता होती है और यह आपके बैकएंड या जोस या जेसनवेबटोकन जैसी लाइब्रेरी में होती है।

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

iat जारी किया जाता है - पर, exp समाप्ति समय है और nbf पहले नहीं है। तीनों सेकंड में यूनिक्स टाइमस्टैम्प हैं। एक टोकन तब मान्य होता है जब nbf ≤ now < exp (जब वे दावे मौजूद होते हैं)।

आप पेलोड को संपादित कर सकते हैं, लेकिन हस्ताक्षर अब मेल नहीं खाएंगे, इसलिए कोई भी सर्वर जो हस्ताक्षरों को सत्यापित करता है - सही ढंग से - इसे अस्वीकार कर देगा। परीक्षण के लिए, अपने वातावरण में कुंजी के साथ पुनः हस्ताक्षर करें; प्रामाणिक पथों का ईमानदारी से परीक्षण करने का यही एकमात्र तरीका है।

परिमाण के अनुसार: युग सेकंड आज 10 अंक (1735689600), मिलीसेकंड 13 (1735689600000) हैं। कनवर्टर उस नियम को लागू करता है, और स्पष्ट दशमलव का भी सम्मान करता है - 1735689600.5 को भिन्नात्मक भाग के साथ सेकंड के रूप में माना जाता है।

दोनों एक ही क्षण का वर्णन करते हैं। यूटीसी समय-क्षेत्र-स्वतंत्र है - भंडारण और लॉग के लिए हमेशा सुरक्षित। लोकल दिखाता है कि ब्राउज़र के टाइमज़ोन का उपयोग करके आपके डिवाइस की घड़ी क्या प्रदर्शित करती है, जो उपयोगकर्ता को पता चलता है।

लगभग हमेशा टाइमस्टैम्प बग के बजाय एक टाइमज़ोन बग: स्थानीय-समय पार्सर के साथ बनाया गया एक मान लेकिन यूटीसी (या इसके विपरीत) के रूप में पढ़ा जाता है। यहां यूटीसी और स्थानीय पंक्तियों की तुलना करें - यदि वे आपके यूटीसी ऑफसेट से भिन्न हैं, तो यही कारण है।

हाँ। नकारात्मक यूनिक्स टाइमस्टैम्प मान्य हैं और युग से पहले की तारीखों का प्रतिनिधित्व करते हैं; कनवर्टर उन्हें संभालता है और ऐतिहासिक दिनांक स्ट्रिंग को भी पार्स करता है।

19 जनवरी 2038 को 03:14:07 यूटीसी पर 32-बिट हस्ताक्षरित पूर्णांक ओवरफ़्लो टाइमस्टैम्प को int32 के रूप में संग्रहीत करने वाले पुराने सिस्टम को प्रभावित करता है। जावास्क्रिप्ट में, यह टूल अप्रभावित है - और 64-बिट या मिलीसेकंड स्टोरेज का वर्तमान अभ्यास इसके अधीन नहीं है।

आप क्वेरी पैरामीटर (?q=…) के अंदर जो मान रख रहे हैं, उसके लिए encodeURIComponent का उपयोग करें: यह &, =, ?, / और # से बच जाता है, इसलिए मान URL की संरचना को नहीं तोड़ सकता है। जिस पूर्ण URL को आप अक्षुण्ण रखना चाहते हैं, उसके लिए एनकोडयूआरआई का उपयोग करें, जो :, / और ? को छोड़ देता है। अकेला।

पथ या टुकड़े में, स्थान %20 होना चाहिए। एप्लिकेशन/x-www-form-urlencoded डेटा में - क्लासिक HTML फॉर्म का मुख्य भाग - स्पेस + है। यहां क्वेरी पार्सर + को एक स्पेस के रूप में मानता है, जो फॉर्म-एन्कोडेड स्ट्रिंग्स के लिए सही व्यवहार है।

क्योंकि इसे दो बार एन्कोड किया गया था - अक्सर एक फ्रेमवर्क पहले से एन्कोडेड मान को एन्कोड करता है। यहां एक बार डिकोड करें; यदि परिणाम में अभी भी %-अनुक्रम शामिल हैं, तो दोबारा डीकोड करें, फिर पाइपलाइन को ठीक करें ताकि यह ठीक एक बार एनकोड हो जाए।

हाँ। टेक्स्ट को UTF-8 बाइट्स के रूप में एन्कोड किया जाता है और फिर प्रतिशत-एस्केप किया जाता है, इसलिए जापानी, अरबी, सिरिलिक और इमोजी सभी सही, इंटरऑपरेबल यूआरएल उत्पन्न करते हैं।

नंबर Base64 एक एन्कोडिंग है, एन्क्रिप्शन नहीं - इसमें कोई कुंजी नहीं है और शून्य गोपनीयता प्रदान करता है। Base64-एन्कोडेड डेटा को सादे टेक्स्ट के रूप में मानें जो केवल उलझा हुआ दिखता है। गोपनीयता की आवश्यकता होने पर एन्क्रिप्शन (टीएलएस, एईएस, आयु) का उपयोग करें।

मानक Base64 + और / का उपयोग करता है, जो URL और पहचानकर्ताओं के अंदर समस्याग्रस्त हैं। URL-सुरक्षित संस्करण (आरएफसी 4648 §5) - और _ को प्रतिस्थापित करता है और अक्सर = पैडिंग को छोड़ देता है, इसलिए मान क्वेरी स्ट्रिंग या फ़ाइल नाम में रखे जाने से बच जाता है।

यह टूल टेक्स्ट को डिकोड करता है, जो टेक्स्ट पेलोड के लिए सही है। यदि डिकोड किए गए बाइट्स एक छवि या संग्रह हैं, तो यह डिकोडर रिपोर्ट करता है कि कचरा प्रिंट करने के बजाय स्पष्ट रूप से उनके लिए बाइट्स-टू-फ़ाइल टूल का उपयोग करें।

पैडिंग. Base64 3 बाइट्स को 4 वर्णों में एन्कोड करता है; जब इनपुट लंबाई तीन से अधिक नहीं होती है, तो ब्लॉक को पूर्ण रखने के लिए = के साथ एन्कोडिंग पैड। पैडिंग अक्सर वैकल्पिक होती है और URL-सुरक्षित उपयोग में हटा दी जाती है।

अनुरोध अनुवाद सटीक है - विधि, URL, हेडर और बॉडी मेल खाते हैं कि कर्ल क्या भेजेगा। शिपिंग से पहले आपको क्या जोड़ना चाहिए: त्रुटि प्रबंधन (रिस्पांस.ओके जांचें), एबॉर्टकंट्रोलर के साथ टाइमआउट, और इडेम्पोटेंट कॉल के लिए तर्क पुनः प्रयास करें।

इसे अनुवादित करने के बजाय एक टिप्पणी में नोट किया गया है, क्योंकि नोड फ़ेच डिफ़ॉल्ट रूप से टीएलएस को सत्यापित करता है और कोड में इसे अक्षम करना एक सुरक्षा निर्णय है। इसके बजाय प्रमाणपत्र ठीक करें; यदि आपको वास्तव में इसकी आवश्यकता है, तो NODE_TLS_REJECT_UNAUTHORIZED=0 को केवल फेंके हुए वातावरण में सेट करें।

-यू उपयोगकर्ता: पास एक प्राधिकरण बन जाता है: क्रेडेंशियल्स Base64-एन्कोडेड के साथ मूल हेडर, जो वास्तव में कर्ल भेजता है। जहां API इसका समर्थन करता है वहां मूल प्रमाणीकरण के स्थान पर टोकन को प्राथमिकता दें।

फ़ेच में संपीड़न पारदर्शी है, इसलिए --संपीड़ित को किसी कोड की आवश्यकता नहीं है। फ़ेच में डिफ़ॉल्ट रूप से रीडायरेक्ट का पालन किया जाता है, -L के साथ कर्ल का मिलान; यदि आपको मैन्युअल रीडायरेक्ट हैंडलिंग की आवश्यकता है, तो रीडायरेक्ट सेट करें: "मैन्युअल"।

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

क्योंकि README फ़ाइलें कच्चे रूप में पढ़ी जाती हैं, कम से कम उतनी बार रेंडर किए गए रूप में - संपादकों, अंतरों और टर्मिनलों में। गद्देदार कॉलम स्रोत को पढ़ने योग्य बनाते हैं, और Markdown रेंडरर्स अतिरिक्त रिक्त स्थान को अनदेखा कर देते हैं।

हाँ - मेज चिपकाएँ; एक पाइप-सीमांकित इनपुट पहचाना जाता है और मौजूदा विभाजक पंक्ति को छोड़ दिया जाता है, इसलिए आपको बिना फ़ॉर्मेटिंग के डेटा वापस मिल जाता है।

हाँ, बैकस्लैश (\|) के साथ, जो मानक GitHub-स्वादयुक्त Markdown एस्केप है। इसके बिना, किसी मान में एक पाइप चुपचाप पंक्ति को अतिरिक्त स्तंभों में विभाजित कर देगा।

GitHub, GitLab, बिटबकेट, ओब्सीडियन, नोशन (पेस्ट के माध्यम से), जीरा, अधिकांश स्थिर-साइट जनरेटर, और टेबल समर्थन के साथ कोई भी कॉमनमार्क रेंडरर। GitHub फ्लेवर्ड Markdown यहां वास्तविक मानक है।