इवेंट कैलेंडर QR कोड जनरेटर

iCalendar पेलोड, ठीक-ठीक

कोड पूरा RFC 5545 ऑब्जेक्ट ले जाता है, उसका लिंक नहीं। वह BEGIN:VCALENDAR से खुलता है, VERSION:2.0 और इस जनरेटर की पहचान बताने वाला PRODID ले जाता है, एक अकेले VEVENT को लपेटता है, और END:VCALENDAR पर बंद होता है। इवेंट के भीतर UID और DTSTAMP बैठते हैं, जो विनिर्देश की माँग हैं, और उनके साथ DTSTART, DTEND, SUMMARY तथा LOCATION, DESCRIPTION और URL में से जो भी आपने भरे हों।

हर सामग्री पंक्ति कैरिज रिटर्न और लाइन फ़ीड पर, इसी क्रम में, समाप्त होती है। पार्सर इस बारे में सख़्त हैं: सिर्फ़ लाइन फ़ीड इस्तेमाल करने वाला ऑब्जेक्ट ही वह चीज़ है जिससे वरना सही इवेंट भी आयात होने से रह जाता है। 75 ऑक्टेट से लंबी पंक्तियाँ CRLF और उसके बाद एक स्पेस डालकर मोड़ी जाती हैं, और पार्स करने से पहले रीडर उन्हें दोबारा जोड़ लेते हैं — इसीलिए लंबा विवरण ऑब्जेक्ट को तोड़ता नहीं।

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

फ़्लोटिंग स्थानीय समय बनाम UTC

फ़्लोटिंग मोड में DTSTART को YYYYMMDDTHHMMSS के रूप में लिखा जाता है, न अंत में Z और न कोई TZID पैरामीटर। RFC 5545 इसे फ़्लोटिंग समय कहता है, और इसका मतलब ठीक वही है जो कहा गया है: 19:00 उस हर डिवाइस पर 19:00 है जो उसे खोले, चाहे वह डिवाइस कहीं भी हो। किसी संगीत कार्यक्रम, बाज़ार के स्टॉल या स्कूल की खुली शाम के लिए लगभग हमेशा यही चाहिए होता है, क्योंकि पोस्टर पढ़ने वाला हर व्यक्ति उसी समय क्षेत्र में खड़ा है जिसमें आयोजन स्थल है।

UTC मोड में वही गुण YYYYMMDDTHHMMSSZ के रूप में लिखा जाता है और अंत का Z उस क्षण को बाँध देता है। हर डिवाइस आयात करते समय उसे स्थानीय समय में बदल लेता है, इसलिए 14:00 UTC पर तय इवेंट Berlin में 15:00 और New York में 09:00 दिखता है। वेबिनार के लिए यही सही चुनाव है और गाँव के मेले के लिए ग़लत।

नाम वाला ज़ोन — DTSTART;TZID=Europe/London — विनिर्देश में तीसरी संभावना है, और यह टूल उसे नहीं देता। उसे ठीक से करने के लिए डेलाइट-सेविंग के बदलावों के पूरे नियमों समेत VTIMEZONE घटक जोड़ना पड़ता है, जो ऐसे पेलोड में कई सौ बाइट और डाल देता है जिसे एक ही सिंबल में समाना है, और जो ऑब्जेक्ट ऐसे TZID का हवाला दे जिसे उसने परिभाषित न किया हो वह अमान्य है। फ़्लोटिंग और UTC छपे हुए पोस्टर वाले मामलों को उस क़ीमत के बिना ढक लेते हैं।

एस्केपिंग, पूरे दिन के इवेंट और आकार

पेलोड में जाने से पहले टेक्स्ट मान विनिर्देश के अनुसार एस्केप किए जाते हैं। पहले बैकस्लैश, फिर सेमीकोलन और कॉमा, फिर पंक्ति विराम; किसी और क्रम में एस्केप करने पर वे बैकस्लैश ही दोबारा एस्केप हो जाते हैं जो आपने अभी डाले थे। टेक्स्ट मान के भीतर कोलन को छोड़ दिया जाता है — RFC 5545 उसे एस्केप करने से साफ़ मना करता है, हालाँकि पुराना RFC 2445 उसकी माँग करता था, और इसीलिए हाथ से लिखे कुछ जनरेटर आज भी यह ग़लत करते हैं।

पूरे दिन का इवेंट तारीख़ वाला रूप लेता है: DTSTART;VALUE=DATE:20260904। उसका DTEND अपवर्जी होता है, इसलिए 4 सितंबर के एक अकेले दिन को DTEND;VALUE=DATE:20260905 के साथ लिखा जाता है। इसे ग़लत करने से ही वह इवेंट बनता है जो एक दिन कम या एक दिन ज़्यादा तक फैला रहता है।

यहाँ व्यावहारिक सीमा आकार है। QR सिंबल सबसे नीचे वाले रिकवरी स्तर पर ज़्यादा से ज़्यादा 2,953 बाइट रखता है, और आपका टेक्स्ट शुरू होने से पहले ही कैलेंडर का ढाँचा अकेले लगभग दो सौ खर्च कर देता है। लंबा विवरण सिंबल को ऊँचे संस्करण पर धकेल देता है जहाँ मॉड्यूल छोटे होते हैं, और तब या तो बड़ी छपाई चाहिए या पास से स्कैन। टाइप करते समय पूर्वावलोकन संस्करण दिखाता रहता है, इसलिए उसे हिलते हुए देखते रहिए।

• बैकस्लैश \\ बन जाता है, सेमीकोलन \; और कॉमा \,
• पंक्ति विराम दो अक्षरों \n में बदल जाता है
• RFC 5545 के टेक्स्ट मानों में कोलन कभी एस्केप नहीं किया जाता