การเพิ่มการดูเอกสารในแอปพลิเคชันธุรกิจต้องทำมากกว่าการใส่ PDF ลงใน iframe ไฟล์ Office, แผนภาพ CAD, ไฟล์อีเมลและรูปภาพต้องการความสามารถในการเรนเดอร์ที่แตกต่างกัน ในขณะเดียวกันแอปพลิเคชันยังต้องควบคุมการรับรองความถูกต้อง การจัดเก็บ การอนุญาตและการเก็บรักษา
Doconut เป็น SDK ตัวดูเอกสาร .NET ที่ออกแบบมาเพื่อฝังการเรนเดอร์และการโต้ตอบของเอกสารในเว็บแอปพลิเคชัน แทนที่จะนำเสนอสูตรโค้ดแหล่งที่มาที่ไม่ได้รับการตรวจสอบ คู่มือนี้อธิบายการตัดสินใจการรวมที่ทีมของคุณควรทำและระบุส่วนประกอบมาตรฐานของ .NET ที่มักอยู่รอบ SDK

ทำไมตัวดูฝังจึงแตกต่างจากการดาวน์โหลดไฟล์
จุดเชื่อมต่อการดาวน์โหลดจะส่งไฟล์ต้นฉบับและปล่อยให้ประสบการณ์การดูเป็นหน้าที่ของซอฟต์แวร์ภายนอกแอปพลิเคชันของคุณ ตัวดูฝังทำให้ผู้ใช้คงอยู่ภายในผลิตภัณฑ์ของคุณและสามารถให้ตำแหน่งที่สอดคล้องสำหรับการนำทาง การค้นหา การตรวจสอบและคุณลักษณะอื่น ๆ ที่เปิดใช้งาน
การสร้างชั้นการเรนเดอร์ด้วยตนเองทำได้ยากเพราะแต่ละรูปแบบมีกฎของตนเอง:
- ไฟล์ PDF สามารถมีฟอนต์ฝัง, คำอธิบาย, ฟอร์มและชุดหน้าจำนวนมาก
- ไฟล์ Word, Excel และ PowerPoint ต้องการการจัดวางและการจัดการฟอนต์อย่างระมัดระวัง
- แผนภาพ CAD ต้องการการสเกลที่แม่นยำ, ชั้นต่าง ๆ และการซูมละเอียด
- รูปแบบอีเมลและรูปภาพนำเข้าการแนบ, เมตาดาต้า, สีและความละเอียดที่ต้องพิจารณา
SDK เฉพาะทางทำให้ทีมแอปพลิเคชันมุ่งเน้นที่การควบคุมการเข้าถึง, กระบวนการทำงานและประสบการณ์ผู้ใช้ แทนการบำรุงรักษาเรนเดอร์แยกต่างหากสำหรับแต่ละรูปแบบที่รองรับ
ขั้นตอนที่ 1: ยืนยันรูปแบบและคุณลักษณะที่ต้องการ
เริ่มต้นด้วยการทำรายการสินค้าจริงของไฟล์ที่ผู้ใช้ของคุณเปิด แยกรูปแบบที่จำเป็นออกจากรูปแบบที่ใช้เป็นครั้งคราว และบันทึกตัวอย่างที่เป็นตัวแทนสำหรับการทดสอบ
รายการตรวจสอบของคุณอาจรวมถึง:
- เอกสาร PDF และ XPS
- เอกสารประมวลผลคำ
- ตารางข้อมูล
- งานนำเสนอ
- แผนภาพ CAD
- ไฟล์อีเมล
- รูปแบบรูปภาพทั่วไป
จากนั้นระบุคุณลักษณะที่สำคัญสำหรับแต่ละกระบวนการทำงาน การดู, การค้นหาข้อความ, คำอธิบาย, การพิมพ์และการแปลงเป็นความสามารถที่แตกต่างกันและอาจต้องการส่วนประกอบหรือใบอนุญาตของ Doconut ที่ต่างกัน
ตรวจสอบขอบเขตผลิตภัณฑ์ปัจจุบันบนหน้า Doconut Viewer page ที่ได้รับการยืนยันก่อนตัดสินใจเลือกรูปแบบหรือคุณลักษณะ ความสามารถของผลิตภัณฑ์อาจเปลี่ยนแปลงได้ ดังนั้นการทดสอบการยอมรับของคุณควรเป็นอำนาจสุดท้ายสำหรับเอกสารที่ลูกค้าจริง ๆ ใช้งาน
ขั้นตอนที่ 2: เลือกแหล่งที่เอกสารเข้าสู่แอปพลิเคชัน
แอปพลิเคชัน ASP.NET สามารถรับเอกสารจากหลายแหล่งที่ควบคุมได้:
- การอัปโหลดที่จัดการเป็น
IFormFileของ ASP.NET Core - ตำแหน่งไฟล์ที่ได้รับการปกป้อง
- ฐานข้อมูลหรือคลังจัดการเอกสาร
- ที่เก็บวัตถุที่เซิร์ฟเวอร์เข้าถึงได้
- บริการภายในที่คืนค่า
Stream
กระบวนการดูควรใช้การอ้างอิงเอกสารที่ได้รับการอนุญาตจากเซิร์ฟเวอร์ อย่าใส่ข้อมูลประจำตัวการจัดเก็บ, เส้นทางไฟล์ที่ไม่จำกัดหรือ URL สาธารณะถาวรในมาร์กอัปฝั่งไคลเอนต์
หากผู้ใช้อัปโหลดไฟล์ ต้องตรวจสอบความถูกต้องก่อนการเรนเดอร์ ตรวจสอบขนาดไฟล์, ส่วนขยาย, ลายเซ็นไฟล์และข้อจำกัดเฉพาะธุรกิจ เก็บตัวระบุที่สร้างโดยเซิร์ฟเวอร์แทนการเชื่อถือชื่อไฟล์ต้นฉบับเป็นเส้นทาง
ขั้นตอนที่ 3: กำหนดการรับรองความถูกต้องและการอนุญาต
แอปพลิเคชัน—not ตัวดู UI—ควรตัดสินใจว่าใครได้รับอนุญาตให้เปิดเอกสาร
ใน ASP.NET Core กลไกมาตรฐานเช่น middleware การรับรองความถูกต้อง, แอตทริบิวต์ [Authorize], นโยบาย, คลมส์และการอนุญาตแบบอิงทรัพยากรสามารถปกป้องจุดเชื่อมต่อที่เริ่มเซสชันการดู การตัดสินใจอนุญาตควรรวมทั้งผู้ใช้ปัจจุบันและเอกสารที่ร้องขอ
กระบวนการร้องขอที่ปลอดภัยมีลำดับดังนี้:
- ผู้ใช้ร้องขอเอกสารโดยใช้ตัวระบุระดับแอปพลิเคชัน
- เซิร์ฟเวอร์ทำการรับรองความถูกต้องของผู้ใช้
- เซิร์ฟเวอร์ตรวจสอบว่าผู้ใช้สามารถเข้าถึงเอกสารนั้นได้หรือไม่
- เซิร์ฟเวอร์ระบุตำแหน่งที่เก็บข้อมูลที่ได้รับการปกป้อง
- ตัวดูได้รับเฉพาะข้อมูลที่จำเป็นสำหรับเซสชันที่ได้รับการอนุญาตนั้น
อย่าคิดว่าการซ่อนปุ่มบนแถบเครื่องมือเป็นการควบคุมการอนุญาต การตรวจสอบการเข้าถึงฝั่งเซิร์ฟเวอร์ยังคงจำเป็นแม้ว่าเครื่องมือดาวน์โหลดหรือพิมพ์จะไม่แสดง
ขั้นตอนที่ 4: เพิ่ม Doconut ผ่านแหล่งทรัพยากรการรวมอย่างเป็นทางการ
ใช้แพ็กเกจและคำแนะนำการตั้งค่าปัจจุบันที่ Doconut จัดให้ หน้า Doconut download page ที่ได้รับการยืนยันให้เข้าถึงทรัพยากรการรวม NuGet, เอกสาร, ตัวอย่างและสาธิต
การตั้งค่าที่แม่นยำอาจขึ้นกับ:
- ประเภทแอปพลิเคชัน ASP.NET หรือ .NET ของคุณ
- ผลิตภัณฑ์และปลั๊กอิน Doconut ที่เลือก
- เวอร์ชันของ Doconut
- ใบอนุญาตของคุณ
- รูปแบบเอกสารและคุณลักษณะที่คุณเปิดใช้งาน
- การกำหนดค่าของเซิร์ฟเวอร์ Windows ของคุณ
ปฏิบัติตามเอกสารที่ตรงกับรุ่นที่ติดตั้ง หลีกเลี่ยงการคัดลอกโค้ดการเริ่มต้นจากบล็อกโพสต์ที่ไม่เกี่ยวข้อง เพราะเนมสเปซ, การกำหนดค่า, เส้นทางทรัพยากรและ API อาจเปลี่ยนแปลงระหว่างเวอร์ชัน
ขั้นตอนที่ 5: สร้างขอบเขตการดูเอกสารเฉพาะ
เก็บการดูเอกสารไว้หลังบริการแอปพลิเคชันขนาดเล็กแทนการเรียกฟังก์ชัน SDK ตลอดคอนโทรลเลอร์และคอมโพเนนต์ UI
บริการนั้นสามารถรับผิดชอบต่อ:
- การระบุเอกสารที่ได้รับการอนุญาต
- การเปิดเอกสารเป็น
Streamที่ควบคุมเมื่อเหมาะสม - การจัดหาการกำหนดค่าการดูที่จำเป็น
- การปล่อยทรัพยากรไฟล์และสตรีม
- การแปลความล้มเหลวทางเทคนิคเป็นข้อผิดพลาดแอปพลิเคชันที่ปลอดภัย
- การบันทึกเมตริกการทำงานโดยไม่บันทึกเนื้อหาเอกสาร
ขอบเขตนี้ทำให้การอัปเกรดง่ายขึ้นและลดความเสี่ยงของการเปิดเผยรายละเอียดการจัดเก็บต่อชั้นการนำเสนอ อีกทั้งยังให้การทดสอบมีจุดที่ชัดเจนสำหรับการแทนที่ด้วยการทำงานที่ปลอดภัย
ขั้นตอนที่ 6: ออกแบบหน้าตัวดู
ตัวดูควรมีพื้นที่เพียงพอเพื่อให้ใช้งานได้ดี การ์ดแคบที่ล้อมรอบด้วยคอนโทรลที่ไม่เกี่ยวข้องทำให้สเปรดชีตขนาดใหญ่และแผนภาพ CAD ยากต่อการตรวจสอบ
วางแผนหน้าตาม:
- ความสูงของตัวดูที่คงที่
- สถานะการโหลด, ว่างและข้อผิดพลาดที่ชัดเจน
- ชื่อเอกสารสั้น ๆ
- คอนโทรลรอบข้างที่เข้าถึงด้วยแป้นพิมพ์
- การจัดวางที่ไม่ซ่อนคอนโทรลสำคัญของตัวดู
- วิธีที่ชัดเจนในการกลับไปยังกระบวนการทำงานหลัก
ทดสอบด้วยชื่อไฟล์ยาว, จำนวนหน้ามาก, สเปรดชีตกว้าง, แผนภาพละเอียดและเอกสารที่ไม่สามารถเรนเดอร์ได้ สถานะข้อผิดพลาดไม่ควรเปิดเผยเส้นทางเซิร์ฟเวอร์, ร่องรอยข้อยกเว้นหรือ URL การจัดเก็บ
ขั้นตอนที่ 7: จัดการไฟล์และข้อมูลชั่วคราว
กำหนดนโยบายการเก็บรักษาก่อนการปรับใช้ พิจารณาไฟล์ต้นฉบับ, ข้อมูลเรนเดอร์ชั่วคราว, แคช, การส่งออก, คำอธิบายและบันทึกแยกกัน
มาตรการป้องกันที่เป็นประโยชน์รวมถึง:
- ไดเรกทอรีชั่วคราวเฉพาะที่มีสิทธิ์จำกัด
- ชื่อที่สร้างโดยเซิร์ฟเวอร์ที่ไม่ซ้ำกัน
- การทำความสะอาดหลังเซสชันสำเร็จและล้มเหลว
- กระบวนการกำหนดเวลาสำหรับไฟล์ชั่วคราวที่ถูกละทิ้ง
- โควต้าการจัดเก็บและการตรวจสอบ
- การเข้ารหัสที่พักตามนโยบายความปลอดภัยของคุณ
ทำให้การทำความสะอาดเป็นที่สังเกต หากการลบล้มเหลวโดยเงียบไฟล์ชั่วคราวอาจสะสมและกลายเป็นปัญหาทางการดำเนินงานและความปลอดภัย
ขั้นตอนที่ 8: กำหนดค่ามาตรการป้องกันการผลิต
การเรนเดอร์เอกสารอาจใช้ CPU, หน่วยความจำและพื้นที่ดิสก์ชั่วคราว ปกป้องแอปพลิเคชันด้วยขีดจำกัดที่ชัดเจน:
- ขนาดการอัปโหลดสูงสุด
- งานเรนเดอร์พร้อมกันสูงสุด
- เวลาหมดอายุของคำขอและการประมวลผล
- ขีดจำกัดคิวเมื่อการเรนเดอร์ทำแบบอะซิงโครนัส
- โควต้าการจัดเก็บชั่วคราว
- การตรวจสอบสุขภาพและการเฝ้าติดตามข้อผิดพลาดแบบโครงสร้าง
สำหรับภาระงานที่ใหญ่หรือไม่คาดคิด ให้แยกการเรนเดอร์ออกจากกระบวนการแอปพลิเคชันที่ต้องการความหน่วงต่ำ วัดผลด้วยเอกสารที่คล้ายลูกค้าแทนการพึ่งไฟล์ทดสอบขนาดเล็กเท่านั้น
ขั้นตอนที่ 9: ทดสอบกระบวนการทำงานทั้งหมด
การทดสอบการรวมที่สำเร็จควรครอบคลุมมากกว่าการ “หน้าหนึ่งปรากฏ”
ทดสอบ:
- ทุกรูปแบบไฟล์ที่ต้องการ
- ไฟล์ขนาดเล็ก, ขนาดใหญ่, หลายหน้าและไฟล์เสีย
- เอกสารที่มีฟอนต์แปลก
- ไฟล์ที่มีรหัสผ่านเมื่อกระบวนการของคุณรองรับ
- ผู้ใช้ที่ได้รับอนุญาตและไม่ได้รับอนุญาต
- เซสชันการดูพร้อมกันหลายรายการ
- การรีสตาร์ทแอปพลิเคชันและคำขอที่ถูกขัดจังหวะ
- การทำความสะอาดหลังสำเร็จและล้มเหลว
- คุณลักษณะของตัวดูที่รวมอยู่ในการกำหนดค่าผลิตภัณฑ์ที่คุณเลือก
เก็บชุดเอกสารทดสอบที่ทำให้เป็นมาตรฐานและผ่านการทำให้เป็นข้อมูลส่วนบุคคลใหม่ ๆ ให้รันใหม่เมื่ออัปเกรด Doconut, .NET, Windows Server, โครงสร้างการจัดเก็บหรือการพึ่งพาที่เกี่ยวข้อง
รายการตรวจสอบความปลอดภัย
ก่อนปล่อย ให้ตรวจสอบว่า:
- ทุกคำขอการดูต้องผ่านการรับรองความถูกต้องตามความเหมาะสม
- มีการตรวจสอบการอนุญาตสำหรับเอกสารเฉพาะ
- อินพุตที่ผู้ใช้ควบคุมไม่สามารถกลายเป็นเส้นทางไฟล์เซิร์ฟเวอร์ที่ไม่จำกัดได้
- ข้อมูลประจำตัวการจัดเก็บไม่เคยถึงไคลเอนต์
- มีการเปิดใช้งานขีดจำกัดและการตรวจสอบอัปโหลด
- ไฟล์ชั่วคราวมีการเข้าถึงจำกัดและนโยบายทำความสะอาดที่ทดสอบแล้ว
- บันทึกไม่รวมเนื้อหาเอกสาร, ความลับหรือ URL ที่สำคัญ
- ข้อความแสดงข้อผิดพลาดต่อผู้ใช้ถูกทำให้สะอาด
- คอนโทรลของ SDK สามารถสนับสนุนกระบวนการทำงานของธุรกิจของคุณได้ แต่ไม่สามารถป้องกันการจับภาพทุกรูปแบบได้เมื่อข้อมูลปรากฏต่อผู้ใช้ที่ได้รับอนุญาต ใช้ร่วมกับการควบคุมการเข้าถึงและนโยบายการปกป้องข้อมูลที่เหมาะสม
Doconut อยู่ในตำแหน่งไหน
Doconut ให้ความสามารถในการดูเอกสารภายในแอปพลิเคชัน .NET ของคุณ ในขณะที่แอปของคุณยังคงรับผิดชอบต่อการระบุตัวตน, การอนุญาต, การจัดเก็บไฟล์, การเก็บรักษา, การตรวจสอบและกระบวนการทำงานโดยรอบ
การแบ่งหน้าที่นี้ให้ทีม .NET มีเส้นทางที่เป็นประโยชน์ในการสนับสนุนเอกสารธุรกิจโดยไม่ต้องสร้างเครื่องยนต์เรนเดอร์หลายตัวจากศูนย์ อีกทั้งยังทำให้รายละเอียดการรวมเฉพาะผลิตภัณฑ์ผูกติดกับเอกสารอย่างเป็นทางการสำหรับเวอร์ชันที่คุณปรับใช้
สำรวจ Doconut .NET document viewer SDK แล้วใช้ แหล่งดาวน์โหลดและเอกสารอย่างเป็นทางการ เพื่อประเมินด้วยเอกสารของคุณเอง
สรุป
ตัวดูเอกสารฝังที่เชื่อถือได้เริ่มต้นด้วยความต้องการรูปแบบที่ชัดเจนและกระบวนการเอกสารฝั่งเซิร์ฟเวอร์ที่ปลอดภัย ตรวจสอบอินพุต, อนุญาตทุกคำขอเอกสาร, แยกการเข้าถึง SDK ไว้หลังบริการแอปพลิเคชัน, วางแผนการทำความสะอาดไฟล์ชั่วคราวและทดสอบด้วยไฟล์ที่เป็นจริง
ด้วยพื้นฐานเหล่านั้น Doconut สามารถให้ชั้นการดูสำหรับเว็บแอป .NET บน Windows ของคุณในขณะที่ทีมของคุณยังคงควบคุมสถาปัตยกรรมแอปพลิเคชันและวงจรชีวิตของเอกสารได้อย่างเต็มที่.