ข้อดีด้านความปลอดภัยของการรวม·แบ่ง PDF ในเบราว์เซอร์

เผยแพร่ 2026-04-13 อ่าน 8 นาที

สรุป (TL;DR)

เดือนที่แล้วผมต้องรวมสัญญาที่สแกนไว้ 47 แผ่น (รวม 230MB) เป็นไฟล์เดียว ผมเกือบจะอัปโหลดไปที่เครื่องมือ PDF ออนไลน์ที่คุ้นเคย แต่เห็นว่าชื่อไฟล์มีชื่อจริงของคู่สัญญาติดอยู่จึงหยุด สุดท้ายผมจัดการในเบราว์เซอร์ด้วย pdf-lib (v1.17.1) ใช้เวลาประมาณ 18 วินาทีบน M2 MacBook Air โดยพัดลมไม่หมุน นับแต่นั้นมา สำหรับ PDF ที่อ่อนไหว ผมลองเส้นทางเบราว์เซอร์ก่อนเสมอ

การรวม·แบ่ง PDF ไม่ใช่งานที่ “ต้องอัปโหลดเอกสารไปยังเซิร์ฟเวอร์ของใครสักคน” ด้วย web standards และไลบรารีบน WebAssembly (pdf-lib, PDFium ports, MuPDF.js ฯลฯ) เอกสารขนาดเล็กถึงกลาง สามารถประมวลผลในเบราว์เซอร์ได้เร็วพอ ข้อได้เปรียบใหญ่สุดคือ ไฟล์ไม่ออกจากเครือข่าย ไม่มีการอัปโหลด ดังนั้น server log ที่เก็บชั่วคราว backup และเส้นทางรั่วไหลจึงลดลงโดยพื้นฐาน อย่างไรก็ตาม สำหรับไฟล์หลายร้อย MB การบีบอัดสแกนแบบ image-based และ OCR ที่ใช้ CPU เข้มข้น หรือการจัดการ signature ที่ซับซ้อนในเอกสารบางประเภท เครื่องมือฝั่งเซิร์ฟเวอร์อาจยังเหนือกว่า สรุปคือยิ่ง ความอ่อนไหวสูงและขนาดสมเหตุสมผล การประมวลผลในเบราว์เซอร์เหมาะกว่า ส่วน ไฟล์ใหญ่ OCR ซับซ้อน และ digital signature ที่ซับซ้อน ควรเลือกเครื่องมือเซิร์ฟเวอร์ที่ได้รับการตรวจสอบหรือแอปเดสก์ท็อปในเครื่อง

ภูมิหลังและแนวคิด

PDF ไม่ใช่แค่ภาพ แต่เป็น ฟอร์แมตเอกสารแบบ object-based ไฟล์ประกอบด้วย indirect object หลายตัว และแต่ละ object ถูกจัดดัชนีด้วย byte offset ผ่าน cross-reference table (XRef) ที่ท้ายไฟล์ PDF สมัยใหม่อาจใช้ object stream อย่าง ObjStm เพื่อบีบหลาย object ไว้ด้วยกัน และอาจเผยแพร่พร้อมส่วน incremental update ที่ต่อท้าย การรวมไฟล์จึงไม่ใช่ “ต่อสองไฟล์เข้าด้วยกัน” แต่คล้ายกับ การคัดลอก object graph ของ PDF หนึ่งไปยัง namespace ของอีก PDF แล้วเขียน XRef ใหม่

การแบ่งก็เช่นกัน หากคงไว้เฉพาะบางหน้า ต้องคัดเฉพาะ font และ image resource ที่หน้านั้นอ้างอิง แล้วเชื่อม reference ที่ขาดใหม่จึงจะได้ PDF ที่ถูกต้อง ไลบรารีเบราว์เซอร์อย่าง pdf-lib จัดการทั้งหมดด้วย JavaScript + WebAssembly ล้วน หมายความว่าในเส้นทางการประมวลผลในเบราว์เซอร์ แม้ bytes ของเอกสารจะไม่ออกไปยังเซิร์ฟเวอร์ ก็สามารถให้ผลลัพธ์ที่เทียบเท่าระดับ spec ได้

เปรียบเทียบและข้อมูล

เกณฑ์แบบเซิร์ฟเวอร์แบบเบราว์เซอร์
ความเป็นส่วนตัวไฟล์ถูกอัปโหลดไปเซิร์ฟเวอร์ อาจเก็บชั่วคราวไฟล์ถูกประมวลผลเฉพาะในเครื่องผู้ใช้
ความเร็วสำหรับไฟล์เล็ก (ไม่กี่ MB)Round-trip delay ส่งผลมากกว่ามักรู้สึกเร็วกว่า
ไฟล์ใหญ่ (100MB+)CPU·memory เฉพาะเจาะจงได้เปรียบอาจชนขีดจำกัดหน่วยความจำของเบราว์เซอร์
การใช้งานออฟไลน์ใช้ไม่ได้ใช้ได้
ความเสี่ยงข้อมูลตกค้างต้องเชื่อนโยบายและ logต่ำโดยพื้นฐาน
ฟีเจอร์ขั้นสูง (OCR, signature ซับซ้อน)เครื่องมือที่โตเต็มที่มีเยอะจำกัดตาม implementation

เหตุที่ตารางนี้เน้นแนวโน้มมากกว่าตัวเลข เพราะความเร็วที่ผู้ใช้รู้สึกถูกกำหนดด้วยชุด “ขนาดไฟล์ × ความเร็วเครือข่าย × เวลาประมวลผลเซิร์ฟเวอร์” สำหรับเอกสารทำงานขนาดไม่กี่ MB จำนวน 20–30 ไฟล์ เบราว์เซอร์มักได้เปรียบเพราะข้ามการอัปโหลด

สถานการณ์จริง

สถานการณ์ 1 — การรวมสัญญา เมื่อส่งสัญญา เอกสารแนบ และภาคผนวกรวมเป็นไฟล์เดียว การประมวลผลในเบราว์เซอร์แข็งแกร่งที่สุดในแง่ที่ว่า ไฟล์ไม่ออกสู่ภายนอก ผมเคยเห็นสองบริษัทที่ฝ่ายกฎหมายห้ามใช้ PDF merger ภายนอก หนึ่งหลังจากร่างเอกสารรั่วไหลไปยัง search engine และอีกหนึ่งหลังจากพบข้อกำหนดเก็บข้อมูล 30 วันของเครื่องมือฟรี workflow นี้เข้ากับเอกสารที่ถูกจัดว่า “ห้ามอัปโหลดภายนอก” ตามกฎภายในองค์กร

สถานการณ์ 2 — การแบ่งคู่มือ ผมเคยแบ่งสื่อการสอน 100 หน้าเป็น 14 บทเพื่อเผยแพร่ ถ้าระบุช่วงหน้าผิดก็เพียง refresh แท็บใหม่ก็เริ่มใหม่ได้ การแก้ซ้ำๆ ทำได้สะดวก ประโยชน์เสริมคือแม้แบ่งผิด ต้นฉบับก็ไม่ได้กระจัดกระจายบนเครือข่าย

สถานการณ์ 3 — ลดขนาดเอกสารที่สแกน สแกนเป็น image-based จึงไฟล์ใหญ่ ผมเคย resample สัญญา 48MB ที่สแกนที่ 650dpi ลงเหลือ 11MB ด้วยการลดเป็น 200dpi ถ้าจัดการรูปก่อนรวม ขนาดของ PDF สุดท้ายจะลดลงอย่างมาก

ความเข้าใจผิดที่พบบ่อย

“เครื่องมือเบราว์เซอร์ช้า” จริงในปี 2015 แต่เปลี่ยนไปหลังจาก WebAssembly SIMD และ worker thread เข้ามา ในเครื่องของผม การรวม PDF 10MB จำนวน 5 ไฟล์ใช้เวลาประมาณ 1.3 วินาที ขณะที่เครื่องมือเซิร์ฟเวอร์ใช้เวลา 10 วินาทีขึ้นไปรวมอัปโหลด·ดาวน์โหลด

“เซิร์ฟเวอร์เร็วกว่าเสมอ” เพราะ upload·queue·process·download เกิดเป็นลูกโซ่ ถ้าเครือข่ายช้าหรือเซิร์ฟเวอร์แออัด การประมวลผลทันทีในเบราว์เซอร์อาจเร็วกว่า

“เบราว์เซอร์ไม่เหมาะกับ workflow ตรวจสอบและหลักฐาน” หากต้องการ audit trail ระบบเซิร์ฟเวอร์เฉพาะทางเหมาะสม แต่สำหรับงานส่วนบุคคลแค่รวม·แบ่ง·จัดเรียงหน้า ไม่จำเป็นต้องถือว่าเป็นเอกสารตรวจสอบ

“PDF ที่เข้ารหัสต้องทำบนเซิร์ฟเวอร์ทั้งหมด” ฟีเจอร์มาตรฐานอย่างการถอดรหัส AES-128/256 ไลบรารีเบราว์เซอร์รองรับเพียงพอ เพียงแต่ signature หรือ policy file แบบไม่มาตรฐานของบางหน่วยงาน ต้องตรวจสอบขอบเขตการรองรับของเครื่องมือก่อน

เช็กลิสต์

  1. เอกสารมีข้อมูลส่วนบุคคลหรือความลับหรือไม่
    • ใช่ พิจารณา การประมวลผลในเบราว์เซอร์ เป็นอันดับแรก
  2. ขนาดไฟล์รวมเท่าไร
    • ต่ำกว่า 50–100MB ประมาณนี้ เบราว์เซอร์จัดการได้
    • หลายร้อย MB ขึ้นไป ใช้แอปเดสก์ท็อปในเครื่องหรือเครื่องมือเซิร์ฟเวอร์ที่ผ่านการตรวจสอบ
  3. ต้องการ OCR, signature ขั้นสูง, audit trail หรือไม่
    • ใช่ พิจารณาเครื่องมือเฉพาะ (local/enterprise server)
  4. เป็นงานที่ทำซ้ำบ่อยหรือไม่
    • ใช่ bookmark เบราว์เซอร์และ workflow ทางลัดได้เปรียบ
  5. ต้องทำในสภาพแวดล้อมออฟไลน์หรือไม่
    • ใช่ มีเพียงเบราว์เซอร์ + web app ที่ cache ไว้ หรือแอปเดสก์ท็อปเท่านั้นที่ทำได้
  6. วิธีแชร์ผลลัพธ์เป็นอย่างไร ถ้าต้องการ share link ให้ตรวจสอบอีกครั้งว่าไม่มี tracking ที่ไม่พึงประสงค์แนบมา

เครื่องมือที่เกี่ยวข้อง

สถานการณ์การรวมในบทความนี้ทดลองได้โดยตรงที่ เครื่องมือรวม PDF ของ Patrache Studio หากต้องการลดขนาดรูปในเอกสารที่สแกนก่อน ให้อ่าน คู่มือการบีบอัดรูปภาพฉบับสมบูรณ์ ก่อนแล้วจัดการฟอร์แมต ผลลัพธ์จะดีกว่า หากวางแผนเพิ่ม QR สำหรับระบุผลิตภัณฑ์·เอกสารใน PDF ที่รวมแล้ว อ่าน ความปลอดภัยของ QR Code ที่ครอบคลุมความเสี่ยงในการพิมพ์·แจกจ่าย จะช่วยให้ตัดสินใจได้ง่ายขึ้น

อ้างอิง

เครื่องมือที่เกี่ยวข้อง

tools.patrache.studio/pdf/merge/