ICS फ़ाइल क्या होती है?

ICS एक सादा टेक्स्ट फ़ॉर्मेट है, जो किसी भी एडिटर में खुल जाता है। इसका इस्तेमाल प्रोग्रामों के बीच डेटा ले जाना के लिए होता है।

एक्सटेंशन .ics है और पूरा नाम iCalendar। दोनों उतना नहीं बताते जितना यह कि फ़ाइल अंदर क्या-क्या रख सकती है — और इस पन्ने का बाक़ी हिस्सा इसी के बारे में है।

यह 1998 तक पीछे जाता है। विनिर्देश RFC 5545 है।

जो फ़ॉर्मेट इतने लंबे समय तक पढ़ा जाता रहा हो, उसे वह चीज़ सौंपी जा सकती है जो आपको दस साल बाद वापस चाहिए।

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

ICS फ़ाइल अपना अंदरूनी हिस्सा हूबहू सहेजती है। दोबारा सहेजने से कुछ नहीं बदलता, इसलिए इसे जितनी बार चाहें खोलिए, बदलिए और फिर से सहेजिए — नुक़सान जमा नहीं होता। यही बात इसे सौंपने का नहीं, काम करने का फ़ॉर्मेट बनाती है।

Google Calendar, Apple Calendar और Microsoft Outlook इसे पढ़ते हैं, और इसी तरह के ज़्यादातर दूसरे प्रोग्राम भी।

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

इसे कोई भी ब्राउज़र नहीं पढ़ता।

इसे बदलने की सबसे आम वजह यही है: फ़ॉर्मेट ख़राब है, ऐसा नहीं — बात यह है कि जहाँ आप फ़ाइल दिखाना चाहते हैं वह जगह उसे पढ़ ही नहीं सकती।

ICS इसलिए बना है कि इसे खोला और बदला जाए। जब तक काम चल रहा है फ़ाइल इसी फ़ॉर्मेट में रखिए, और जब भी बनी हुई प्रति चाहिए हो, इसी से निर्यात कीजिए।

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

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

सादा पाठ, इतनी पुरानी संरचना में कि वैसी ही दिखती है: प्रति लाइन एक प्रॉपर्टी, सब बड़े अक्षरों में, 75 अक्षर पर लपेटी हुई। हर इवेंट BEGIN और END चिह्न के बीच बैठता है, शुरुआत, अंत, सारांश, आमतौर पर विवरण और जगह, और एक अनोखी पहचान के साथ।

वही पहचान है जो अनोखे ढंग से बरतती है। यही तय करता है कि कैलेंडर किसी अपडेट को मौजूद अपॉइंटमेंट का हिस्सा माने या नया — इसलिए वही पहचान लिए दोबारा भेजा निमंत्रण मूल को हिलाता है, नक़ल नहीं बनाता। नई पहचान से भेजने पर अब हर किसी के पास दो बैठकें हैं।

इवेंट अपना समय तीन तरीक़ों में दर्ज कर सकता है, और वे अलग-अलग बरतते हैं। बिना ज़ोन का स्थानीय समय मतलब है «जहाँ भी हों वहाँ दस बजे», जो जन्मदिन के लिए सही और बैठक के लिए ग़लत है। पीछे Z लगा UTC समय एक तय पल है जिसे हर कैलेंडर पाठक के अपने ज़ोन में बदलता है।

कुछ के लिए एक घंटा इधर-उधर पहुँचने वाला अपॉइंटमेंट लगभग हमेशा यही है: ऐसे सिस्टम से लिखा इवेंट जिसने मान लिया सब एक ही देश में हैं। घड़ी बदलने तक ठीक रहा अपॉइंटमेंट यही ग़लती एक स्तर गहरे है।

दोहराव एक नियम से बताया जाता है, हर घटना लिखकर नहीं: हर दूसरा मंगलवार, महीने का आख़िरी शुक्रवार, किसी तारीख़ तक हर कामकाजी दिन। यह सघन और सटीक है।

जो इसे उलझाता है वह है अपवाद। रद्द हुई घटना और अलग दिन खिसकाई एक बैठक दोनों शृंखला में संशोधन की तरह सहेजे जाते हैं, और ऐप्लिकेशन इसे कितनी पूरी तरह लागू करते हैं यह अलग-अलग है।

एक बार वाली फ़ाइल के लिए, तीनों वही करते हैं: आयात जो इवेंट एक बार कॉपी करता है। Google Calendar में यह Settings, Import and export के तहत है; Outlook में File, Open and Export।

फ़ीड के लिए, डाउनलोड फ़ाइल के बजाय सब्सक्राइब विकल्प इस्तेमाल कीजिए और पता दीजिए। Google इसे «From URL» कहता है, Apple कैलेंडर सब्सक्रिप्शन, Outlook «Subscribe from web»। कैलेंडर फिर अपने शेड्यूल पर दोबारा लाता है, जिसे Google और Outlook घंटों में मापते हैं।

कुछ भी बुक करने वाला सिस्टम — टिकटिंग प्लैटफ़ॉर्म, बुकिंग फ़ॉर्म — आख़िरकार ICS जोड़ने की ज़रूरत महसूस करता है ताकि ग्राहक इसे अपने कैलेंडर में डाल सके। तीन ब्योरे तय करते हैं कि यह काम करेगा या सपोर्ट टिकट बनाएगा।

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

यह पाठ है, इसलिए कोई भी एडिटर खोलता है। लाइन-लपेटने का रिवाज़ ही एक चीज़ है जिसका सम्मान करना है: जारी रहने वाली लाइन एक स्पेस से शुरू होती है, और वह स्पेस हटाना चुपचाप प्रॉपर्टी बदल देता है।

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