چگونه مشاهده PDF، Office، CAD و تصویر را در یک برنامه وب .NET جاسازی کنیم
7/10/2026

چگونه مشاهده PDF، Office، CAD و تصویر را در یک برنامه وب .NET جاسازی کنیم

راهنمای گام به گام برای برنامه‌ریزی مشاهده امن و جاسازی شده اسناد PDF، Office، CAD، ایمیل و فایل‌های تصویری با SDK .NET Doconut.

افزودن قابلیت مشاهده اسناد به یک برنامه تجاری بیش از قرار دادن یک PDF در iframe است. فایل‌های Office، نقشه‌های CAD، ایمیل‌ها و تصاویر نیاز به قابلیت‌های رندرینگ متفاوتی دارند، در حالی که برنامه همچنان باید احراز هویت، ذخیره‌سازی، مجوزدهی و نگهداری را کنترل کند.

Doconut یک SDK نمایشگر سند .NET است که برای جاسازی رندرینگ و تعامل اسناد در برنامه‌های وب طراحی شده است. به جای ارائه یک دستورالعمل کد منبع غیرمورد تأیید، این راهنما تصمیمات یکپارچه‌سازی‌ای که تیم شما باید بگیرد را توضیح می‌دهد و اجزای استاندارد .NET را که معمولاً دور SDK قرار می‌گیرند شناسایی می‌کند.

ذخیره‌سازی امن سند متصل به یک نمایشگر جاسازی‌شده در یک برنامه وب .NET
ذخیره‌سازی امن سند متصل به یک نمایشگر جاسازی‌شده در یک برنامه وب .NET

چرا یک نمایشگر جاسازی‌شده متفاوت از دانلود فایل است

یک نقطه انتهایی دانلود، فایل اصلی را منتقل می‌کند و تجربه مشاهده را به نرم‌افزاری خارج از برنامه شما می‌سپارد. یک نمایشگر جاسازی‌شده کاربر را در داخل محصول شما نگه می‌دارد و می‌تواند مکان ثابتی برای ناوبری، جستجو، مرور و سایر ویژگی‌های فعال‌شده فراهم کند.

ساخت لایه رندرینگ توسط خودتان دشوار است زیرا هر فرمت قوانین خاص خود را دارد:

  • فایل‌های PDF می‌توانند شامل فونت‌های جاسازی‌شده، حاشیه‌نویسی‌ها، فرم‌ها و مجموعه‌های صفحه‌ای بسیار بزرگ باشند.
  • فایل‌های Word، Excel و PowerPoint نیاز به چیدمان دقیق و مدیریت فونت دارند.
  • نقشه‌های CAD به مقیاس‌گذاری دقیق، لایه‌ها و زوم جزئیات نیاز دارند.
  • فرمت‌های ایمیل و تصویر پیوست‌ها، متادیتا، رنگ و نگرانی‌های وضوح را معرفی می‌کنند.

یک SDK اختصاصی به تیم برنامه اجازه می‌دهد تا بر کنترل دسترسی، گردش کار و تجربه کاربری تمرکز کنند به جای نگهداری یک رندرر جداگانه برای هر فرمت پشتیبانی‌شده.


گام ۱: تأیید فرمت‌ها و ویژگی‌های مورد نیاز

با یک فهرست واقعی از فایل‌هایی که کاربران شما باز می‌کنند شروع کنید. فرمت‌های ضروری را از فرمت‌های گاه‌به‌گاه جدا کنید و نمونه‌های نماینده‌ای برای تست ثبت کنید.

چک‌لیست شما ممکن است شامل موارد زیر باشد:

  • اسناد PDF و XPS
  • اسناد پردازش کلمه
  • صفحات گسترده
  • ارائه‌ها
  • نقشه‌های CAD
  • فایل‌های ایمیل
  • فرمت‌های رایج تصویر

سپس ویژگی‌هایی که برای هر گردش کار مهم هستند شناسایی کنید. مشاهده، جستجوی متن، حاشیه‌نویسی، چاپ و تبدیل قابلیت‌های متفاوتی هستند و ممکن است به مؤلفه‌ها یا مجوزهای مختلف Doconut نیاز داشته باشند.

قبل از تعهد به یک فرمت یا ویژگی، صفحهٔ نمایشگر Doconut را مرور کنید. قابلیت‌های محصول می‌توانند تغییر کنند، بنابراین تست‌های پذیرش شما باید مرجع نهایی برای اسنادی باشد که مشتریان شما در واقع استفاده می‌کنند.


گام ۲: انتخاب منبع ورود اسناد به برنامه

یک برنامه ASP.NET می‌تواند اسناد را از چندین منبع کنترل‌شده دریافت کند:

  • بارگذاری‌ای که به عنوان IFormFile در ASP.NET Core مدیریت می‌شود
  • مکان فایل محافظت‌شده
  • یک مخزن مدیریت اسناد یا پایگاه داده
  • ذخیره‌سازی شیء که توسط سرور دسترسی پیدا می‌کند
  • سرویس داخلی که یک Stream برمی‌گرداند

گردش کار مشاهده باید از یک مرجع سند دارای مجوز سرور استفاده کند. اعتبارهای ذخیره‌سازی، مسیرهای فایل بدون محدودیت یا URLهای عمومی دائمی را در مارکاپ سمت کلاینت قرار ندهید.

اگر کاربران فایل‌ها را بارگذاری می‌کنند، قبل از رندرینگ آن‌ها را اعتبارسنجی کنید. اندازه فایل، پسوند، امضای فایل و هر محدودیت تجاری خاصی را بررسی کنید. شناسهٔ تولیدشده توسط سرور را ذخیره کنید نه اینکه به نام فایل اصلی به عنوان مسیر اعتماد کنید.


گام ۳: تعریف احراز هویت و مجوزدهی

برنامه—not نمایشگر UI—باید تصمیم بگیرد چه کسی مجاز به باز کردن یک سند است.

در ASP.NET Core، مکانیزم‌های استاندارد مانند میدل‌ویر احراز هویت، ویژگی [Authorize]، سیاست‌ها، ادعاها و مجوزدهی مبتنی بر منبع می‌توانند نقطه انتهایی که یک جلسه مشاهده را آغاز می‌کند محافظت کنند. تصمیم مجوزدهی باید هم کاربر فعلی و هم سند درخواست‌شده را در بر گیرد.

یک جریان درخواست امن به این شکل است:

  1. کاربر با استفاده از یک شناسهٔ سطح برنامه درخواست سند می‌کند.
  2. سرور کاربر را احراز هویت می‌کند.
  3. سرور تأیید می‌کند که کاربر می‌تواند به آن سند خاص دسترسی داشته باشد.
  4. سرور مکان ذخیره‌سازی محافظت‌شده را حل می‌کند.
  5. نمایشگر فقط اطلاعات مورد نیاز برای آن جلسهٔ مجاز را دریافت می‌کند.

هرگز فرض نکنید مخفی کردن یک دکمهٔ نوار ابزار، کنترل مجوز است. بررسی‌های دسترسی سمت سرور حتی زمانی که کنترل‌های دانلود یا چاپ نشان داده نمی‌شوند، همچنان ضروری هستند.


گام ۴: افزودن Doconut از طریق منابع رسمی یکپارچه‌سازی

از بسته و دستورالعمل‌های نصب فعلی که توسط Doconut ارائه شده‌اند استفاده کنید. صفحهٔ دانلود Doconut نسخهٔ تأییدشده‌ای از منابع یکپارچه‌سازی NuGet، مستندات، مثال‌ها و دموی‌ها را در اختیار می‌گذارد.

تنظیم دقیق می‌تواند به موارد زیر بستگی داشته باشد:

  • نوع برنامه ASP.NET یا .NET شما
  • محصول و افزونه‌های انتخابی Doconut
  • نسخهٔ Doconut
  • مجوز شما
  • فرمت‌های سند و ویژگی‌هایی که فعال می‌کنید
  • پیکربندی سرور ویندوز شما

مستنداتی را دنبال کنید که با نسخهٔ نصب‌شده مطابقت دارد. از کپی کردن قطعات اولیه از پست‌های بلاگ نامرتبط خودداری کنید زیرا فضاهای نام، پیکربندی، مسیرهای دارایی و APIها بین نسخه‌ها ممکن است تغییر کنند.


گام ۵: ایجاد یک مرز اختصاصی برای مشاهده

مشاهدهٔ سند را پشت یک سرویس کوچک برنامه نگه دارید به جای اینکه عملکرد SDK را در سراسر کنترلرها و مؤلفه‌های UI فراخوانی کنید.

این سرویس می‌تواند مسئول موارد زیر باشد:

  • حل یک شناسهٔ سند دارای مجوز
  • باز کردن سند به‌عنوان یک Stream کنترل‌شده در زمان مناسب
  • فراهم کردن پیکربندی مورد نیاز برای مشاهده
  • آزادسازی منابع فایل و استریم
  • ترجمهٔ خطاهای فنی به خطاهای ایمن برنامه
  • ثبت معیارهای عملیاتی بدون لاگ‌کردن محتوای سند
  • ثبت متریک‌های عملیاتی بدون ثبت محتوای سند

این مرز ارتقاها را آسان‌تر می‌کند و خطر افشای جزئیات ذخیره‌سازی به لایهٔ ارائه را کاهش می‌دهد. همچنین به تست‌ها مکان واضحی برای جایگزینی یک پیاده‌سازی ایمن می‌دهد.


گام ۶: طراحی صفحهٔ نمایشگر

نمایشگر باید فضای کافی برای مفید بودن داشته باشد. یک کارت باریک که توسط کنترل‌های نامرتبط احاطه شده، بررسی صفحات گسترده بزرگ و نقشه‌های CAD را دشوار می‌کند.

صفحه را بر اساس موارد زیر برنامه‌ریزی کنید:

  • ارتفاع ثابت نمایشگر
  • وضعیت‌های واضح بارگذاری، خالی و خطا
  • عنوان سند مختصر
  • کنترل‌های اطراف قابل دسترسی با صفحه‌کلید
  • چیدمانی که کنترل‌های مهم نمایشگر را مخفی نکند
  • روشی صریح برای بازگشت به جریان کاری والد

با نام فایل‌های طولانی، تعداد صفحهٔ زیاد، صفحات گستردهٔ عریض، نقشه‌های دقیق و اسنادی که رندر نمی‌شوند تست کنید. وضعیت خطا نباید مسیرهای سرور، ردگیری استثنا یا URLهای ذخیره‌سازی را فاش کند.


گام ۷: مدیریت فایل‌ها و داده‌های موقت

قبل از استقرار، یک سیاست نگهداری تعریف کنید. فایل اصلی، داده‌های رندرینگ موقت، کش‌ها، خروجی‌ها، حاشیه‌نویسی‌ها و لاگ‌ها را جداگانه در نظر بگیرید.

اقدامات حفاظتی مفید شامل موارد زیر هستند:

  • یک پوشهٔ موقت اختصاصی با دسترسی‌های محدود
  • نام‌های منحصربه‌فرد تولیدشده توسط سرور
  • پاک‌سازی پس از جلسات موفق یا ناموفق
  • یک فرآیند زمان‌بندی‌شده برای فایل‌های موقت رها شده
  • سهمیه‌های ذخیره‌سازی و نظارت
  • رمزنگاری در حالت استراحت در صورتی که سیاست امنیتی شما این‌گونه باشد

پاک‌سازی را قابل مشاهده کنید. اگر حذف به‌صورت ساکت شکست بخورد، فایل‌های موقت می‌توانند انباشته شوند و هم مشکل عملیاتی و هم امنیتی ایجاد کنند.


گام ۸: پیکربندی اقدامات ایمنی در محیط تولید

رندرینگ اسناد می‌تواند CPU، حافظه و فضای دیسک موقت را مصرف کند. برنامه را با محدودیت‌های صریح محافظت کنید:

  • حداکثر اندازهٔ بارگذاری
  • حداکثر تعداد کارهای رندرینگ همزمان
  • زمان‌سنجی درخواست و پردازش
  • محدودیت‌های صف زمانی که رندرینگ به‌صورت ناهمزمان انجام می‌شود
  • سهمیه‌های ذخیره‌سازی موقت
  • چک‌های سلامت و نظارت ساختاری بر خطاها

برای بارهای کاری بزرگ یا غیرقابل پیش‌بینی، رندرینگ را از فرآیندهای حساس به تأخیر جدا کنید. با اسناد شبیه به مشتری اندازه‌گیری کنید نه فقط با فایل‌های تست کوچک.


گام ۹: تست کامل گردش کار

یک تست یکپارچه‌سازی موفق باید بیش از «صفحهٔ اول ظاهر شد» را پوشش دهد.

تست کنید:

  • هر فرمت فایل مورد نیاز
  • فایل‌های کوچک، بزرگ، چندصفحه‌ای و خراب
  • اسنادی با فونت‌های غیرمتداول
  • فایل‌های محافظت‌شده با رمز عبور وقتی که گردش کار شما از آن‌ها پشتیبانی می‌کند
  • کاربران مجاز و غیرمجاز
  • جلسات مشاهدهٔ همزمان
  • راه‌اندازی مجدد برنامه و درخواست‌های قطع‌شده
  • پاک‌سازی پس از موفقیت و شکست
  • ویژگی‌های نمایشگر که در پیکربندی محصول انتخابی شما گنجانده شده‌اند

یک مجموعهٔ نسخه‌بندی‌شده از اسناد تستی پاک‌سازی‌شده نگه دارید. هنگام ارتقا Doconut، .NET، Windows Server، زیرساخت ذخیره‌سازی یا وابستگی‌های مرتبط آن را دوباره اجرا کنید.


چک‌لیست امنیتی

قبل از انتشار، تأیید کنید که:

  • هر درخواست مشاهده نیاز به احراز هویت مناسب دارد.
  • مجوز برای سند خاص بررسی می‌شود.
  • ورودی‌های کنترل‌شده توسط کاربر نمی‌توانند به مسیر فایل سرور بدون محدودیت تبدیل شوند.
  • اعتبارهای ذخیره‌سازی هرگز به کلاینت نمی‌رسند.
  • محدودیت‌ها و اعتبارسنجی بارگذاری فعال هستند.
  • فایل‌های موقت دسترسی محدود دارند و سیاست پاک‌سازی تست‌شده‌ای دارند.
  • لاگ‌ها محتوای سند، اسرار و URLهای حساس را شامل نمی‌شوند.
  • پیام‌های خطا نشان داده‌شده به کاربران پاک‌سازی شده‌اند.
  • کنترل‌های SDK و برنامه از یک فرآیند به‌روزرسانی پیروی می‌کنند.

کنترل‌های نمایشگر می‌توانند به جریان کاری کسب‌وکار شما کمک کنند، اما نمی‌توانند هر شکل از ضبط را پس از مشاهده اطلاعات توسط کاربر مجاز جلوگیری کنند. از آن‌ها همراه با کنترل‌های دسترسی و یک سیاست مناسب حفاظت از اطلاعات استفاده کنید.


جایگاه Doconut

Doconut قابلیت مشاهده اسناد را داخل برنامه .NET شما فراهم می‌کند، در حالی که برنامه شما مسئول هویت، مجوزدهی، ذخیره‌سازی فایل، نگهداری، حسابرسی و گردش کار پیرامون آن می‌ماند.

این تقسیم مسئولیت‌ها مسیر عملی برای تیم‌های .NET فراهم می‌کند تا اسناد تجاری را بدون ساخت چندین موتور رندرینگ از ابتدا پشتیبانی کنند. همچنین جزئیات یکپارچه‌سازی خاص محصول را به مستندات رسمی نسخه‌ای که استقرار می‌دهید مرتبط می‌سازد.

SDK نمایشگر سند .NET Doconut را بررسی کنید، سپس از منابع رسمی دانلود و مستندات برای ارزیابی آن با اسناد خود استفاده کنید.


نتیجه‌گیری

یک نمایشگر سند جاسازی‌شدهٔ قابل اعتماد با نیازهای واضح فرمت و جریان سند سمت سرور امن شروع می‌شود. ورودی‌ها را اعتبارسنجی کنید، هر درخواست سند را مجوزدهی کنید، دسترسی به SDK را پشت یک سرویس برنامه ایزوله کنید، پاک‌سازی فایل‌های موقت را برنامه‌ریزی کنید و با فایل‌های واقعی تست کنید.

با این پایه‌ها، Doconut می‌تواند لایهٔ مشاهده را برای برنامه وب .NET مبتنی بر ویندوز شما فراهم کند در حالی که تیم شما کنترل معماری برنامه و چرخه حیات سند را حفظ می‌کند.