MBOX से PST

एक या अधिक MBOX मेलबॉक्स फ़ाइलों को एकल Unicode Outlook PST में बदलें। परिवर्तन हर संदेश के पूर्ण हेडर, HTML या प्लेन‑टेक्स्ट बॉडी, और सभी एटैचमेंट्स को संरक्षित करता है, और परिणामी PST पुराने 2 GB आकार सीमा से अधिक हो सकता है। आउटपुट PST में एक "Inbox" फ़ोल्डर होता है जहाँ सभी संदेश मिलते हैं; अलग‑अलग MBOX फ़ाइलें अलग फ़ोल्डर के रूप में नहीं रहतीं।

सभी संदेश एकल Inbox फ़ोल्डर में मिलाए गए

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

स्रोत MBOX आर्काइव के फ़ाइल नामों को सब‑फ़ोल्डर में नहीं बदला जाता। जब कई आर्काइव एक साथ सबमिट किए जाते हैं, तो उनके संदेश क्रमशः अपलोड क्रम में जोड़ दिए जाते हैं, प्रत्येक आर्काइव के भीतर मूल कालक्रम को बनाए रखते हुए एक निरंतर Inbox दृश्य उत्पन्न होता है।

Unicode PST आउटपुट जो पुरानी 2 GB सीमा से अधिक है

जनरेटेड PST Outlook 2003 SP3 से प्रस्तुत Unicode फ़ॉर्मेट का उपयोग करता है, जो पुराने ANSI PST की 2 GB आकार सीमा को हटाता है। यह आउटपुट फ़ाइल को दो गीगाबाइट से कहीं अधिक बढ़ने की अनुमति देता है, जिससे बड़े मेल आर्काइव्स को संभालना संभव होता है जो अन्यथा पुरानी सीमाओं को पार कर जाएंगे।

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

पूर्ण हेडर ट्रांसफ़र, Bcc सहित

सभी मानक लिफ़ाफ़ा हेडर—From, To, Cc, Subject, और मूल Date—सीधे Outlook के मूल फ़ील्ड्स में मैप किए जाते हैं ताकि प्रत्येक संदेश अपने मेटाडेटा को ठीक उसी तरह रखे जैसा कि स्रोत MBOX में था। यह सुनिश्चित करता है कि Outlook में सॉर्टिंग, सर्च और थ्रेडिंग मूल क्लाइंट के समान व्यवहार करें।

कनवर्टर मौलिक संदेश में Bcc प्राप्तकर्ताओं को भी संरक्षित करता है। कई परिवर्तन पाइपलाइन के विपरीत जो Bcc जानकारी हटा देती हैं, यह टूल PST आइटम के भीतर उन छिपे पतों को रखता है, जिससे मूल रूप से भेजे गए संदेश की सटीक पुनः निर्मिति संभव होती है।

HTML और प्लेन‑टेक्स्ट बॉडीज को जैसा है वैसा ही रखा गया

जब कोई संदेश दोनों HTML भाग और प्लेन‑टेक्स्ट विकल्प रखता है, तो कनवर्टर दोनों भागों को Outlook आइटम के भीतर स्टोर करता है। Outlook उपयोगकर्ता की प्राथमिकताओं के आधार पर यह तय करता है कि कौन सा प्रतिनिधित्व दिखाया जाए, जिससे प्राप्तकर्ता को या तो समृद्ध फ़ॉर्मेटेड संस्करण या साधारण टेक्स्ट संस्करण जैसा कि मूल में इच्छित था, दिखता है।

HTML बॉडी को पुनः‑कोडिंग या परिवर्तन के बिना ट्रांसफ़र किया जाता है, पैराग्राफ, सूची, तालिका, बोल्ड, इटैलिक और इनलाइन शैलियों को संरक्षित करता है। इसी प्रकार, प्लेन‑टेक्स्ट विकल्प भी अपरिवर्तित रहता है। यह एक‑से‑एक ट्रांसफ़र यह सुनिश्चित करता है कि मूल क्लाइंट में देखी गई दृश्य उपस्थिति और फ़ॉर्मेटिंग Outlook में सही रूप से पुन: उत्पन्न हो।

एटैचमेंट और इनलाइन इमेजेज़ संरक्षित

सभी बाइनरी एटैचमेंट्स—PDFs, ZIP आर्काइव्स, DOCX फ़ाइलें, इमेजेज़, और मूल ईमेल में संलग्न किसी भी फ़ाइल प्रकार—PST में मूल Outlook एटैचमेंट्स के रूप में ट्रांसफ़र होते हैं। वे संदेश में बिल्कुल उसी तरह दिखाई देते हैं जैसे ईमेल सीधे Outlook में प्राप्त हुआ हो, बिना डेटा नुकसान के।

cid: पहचानकर्ता के साथ संदर्भित इनलाइन इमेजेज़ मल्टीपार्ट एटैचमेंट्स के रूप में बनी रहती हैं और Outlook समान CID लुकअप मैकेनिज़्म का उपयोग करके इन्हें इनलाइन रेंडर करता है। बाह्य इमेज URLs (http/https) HTML बॉडी में लिंक के रूप में रहते हैं; Outlook अपने स्वयं के बाह्य‑सामग्री नीतियों के अनुसार व्यू टाइम पर इन्हें फ़ेच करता है, जिससे संदेश की दृश्य सामग्री संरक्षित रहती है।

सीमाएँ और दायरा

डाउनलोड लिंक की आयु

जनरेटेड .pst फ़ाइल परिवर्तन समाप्त होने के 24 घंटे के बाद डाउनलोड के लिए उपलब्ध रह सकती है।