क्या डायरी प्रविष्टि पढ़ने पर उसकी रिमोट छवि फिर से लोड होती है?

Markdown में छवि लिंक का क्या अर्थ है?

मानक Markdown में, `` जैसा छवि सिंटैक्स किसी छवि को उसके URL द्वारा पहचानता है। [CommonMark छवि ट्यूटोरियल](https://commonmark.org/help/tutorial/08-images.html) स्पष्ट रूप से पूर्ण वेब URL को मान्य छवि गंतव्यों के रूप में दिखाता है। यह सिंटैक्स स्वयं यह नहीं बताता कि छवि को डायरी में कॉपी किया गया है या स्थानीय रूप से संग्रहीत किया गया है।

जब कोई पाठक उस प्रविष्टि को प्रदर्शित करता है, तो सॉफ्टवेयर URL को छवि स्रोत के रूप में रेंडर कर सकता है। एक वेब पेज में, ब्राउज़र का `<img>` तत्व दस्तावेज़ में एक छवि को एम्बेड करता है, और इसका `src` विशेषता प्रदर्शित करने के लिए संसाधन की पहचान करती है, जैसा कि [MDN के `<img>` संदर्भ](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img) में वर्णित है। अनुरोध रिमोट सर्वर तक पहुंचता है या नहीं, यह कैशिंग और संबंधित ऐप, ब्राउज़र तथा नेटवर्क पथ पर निर्भर करता है।

क्या ब्राउज़र हर बार पढ़ने पर सर्वर से संपर्क करता है?

ऐसा कोई निश्चित नियम नहीं है जो यह कहे कि इसे हर छवि को नए सिरे से प्राप्त करना ही होगा। अनुरोध करते समय ब्राउज़र अपने HTTP कैश की जांच करते हैं; यदि कोई मेल खाने वाली, मान्य कैश्ड प्रतिक्रिया होती है, तो ब्राउज़र उस छवि के लिए मूल सर्वर से संपर्क किए बिना उसका उपयोग कर सकता है। [web.dev की HTTP कैश गाइड](https://web.dev/articles/http-cache) बताती है कि ताजगी (freshness) प्रतिक्रिया कैशिंग जानकारी पर निर्भर करती है और एक कैश्ड प्रतिक्रिया का पुन: उपयोग तब तक किया जा सकता है जब तक वह ताज़ा रहती है।

यदि कोई कैश्ड प्रतिक्रिया पुरानी (stale) हो गई है या सत्यापन की आवश्यकता है, तो ब्राउज़र यह जांचने के लिए सर्वर से संपर्क कर सकता है कि संग्रहीत प्रति अभी भी वर्तमान है या नहीं। सर्वर यह पुष्टि कर सकता है कि प्रति मान्य बनी हुई है, इसलिए इस जांच का अर्थ यह नहीं है कि पूरी छवि फिर से डाउनलोड की गई थी। [MDN की HTTP कैशिंग गाइड](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching) ताजगी, सत्यापन और उन मामलों को कवर करती है जहां प्रतिक्रियाओं को कैश नहीं किया जाना चाहिए। कैश साफ़ करना, समाप्ति, बदले हुए URL, ऐप का व्यवहार, या कैश सेटिंग्स—ये सभी बाद में पढ़ने पर होने वाली प्रक्रिया को बदल सकते हैं।

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

आप किसी URL और सहेजे गए संलग्नक में अंतर कैसे कर सकते हैं?

छवि संदर्भ या ऐप की संलग्नक जानकारी का निरीक्षण करें, यदि वह उपलब्ध कराई गई हो। `https://` या `http://` से शुरू होने वाला गंतव्य किसी रिमोट वेब पते को इंगित करता है। एक सापेक्ष पथ (relative path) या ऐप-विशिष्ट संलग्नक नाम की अधिक जांच की आवश्यकता होती है। एक वेब पेज में, एक सापेक्ष पथ किसी अन्य वेब पते में परिवर्तित हो सकता है; यह साबित नहीं करता कि फ़ाइल आपके डिवाइस पर स्थानीय है। डायरी ऐप के भंडारण और रेंडरिंग नियम गंतव्य तय करते हैं। केवल Markdown यह गारंटी नहीं देता कि स्थानीय दिखने वाला संदर्भ पोर्टेबल है या फ़ाइल प्रविष्टि के अंदर संग्रहीत है।

एक उपयोगी अंतर यह है कि किसका उपलब्ध रहना आवश्यक है: एक रिमोट URL रिमोट संसाधन के बने रहने और सुलभ होने पर निर्भर करता है; एक स्थानीय संलग्नक प्रासंगिक फ़ाइल के उस स्थान पर मौजूद होने पर निर्भर करता है जहाँ ऐप अपेक्षा करता है। डायरी फ़ोटो फ़ाइलों को सुरक्षित रखने के लिए, ऐप के स्वयं के निर्यात या बैकअप निर्देशों का पालन करें। इस लेख का ध्यान रिमोट लोडिंग के अलग प्रश्न पर है, किसी विशेष ऐप के भंडारण प्रारूप की गारंटी पर नहीं।

एक ऑफ़लाइन तुलना क्या दिखा सकती है?

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

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

व्यावहारिक चेकलिस्ट

जिस प्रविष्टि को अनुमानित रूप से प्रदर्शित होना चाहिए, उसके लिए छवि संदर्भ का निरीक्षण करें, फिर जांचें कि क्या संगत स्थानीय संलग्नक मौजूद है यदि इसे स्थानीय होना चाहिए। यदि यह एक रिमोट URL है, तो उपलब्धता और अद्यतन व्यवहार के होस्ट और कैशिंग पर निर्भर होने की अपेक्षा करें। अनुरोधों का निरीक्षण करने के लिए एक ऑनलाइन नेटवर्क पैनल और सीमित तुलना के रूप में ऑफ़लाइन री-ओपन का उपयोग करें। प्रत्येक परिणाम को परीक्षण किए गए ऐप, ब्राउज़र और कैश स्थिति के साक्ष्य के रूप में मानें—सार्वभौमिक गारंटी के रूप में नहीं।

इस विषय को आगे पढ़ें