เรนเดอร์ตาราง HTML ผ่าน NextPDF Connect

ภาพรวมโดยสังเขป

เรนเดอร์ข้อมูลแบบตารางที่มีโครงสร้างจากสตริงตาราง HTML โดย add_table จะ sanitize อินพุตด้วย allowlist ของ DOMDocument ที่เข้มงวดก่อนจัดวาง เอาต์พุตจึงยังสอดคล้องกันแม้มาร์กอัปต้นทางจะแตกต่างกัน ใช้เครื่องมือ Core create_pdf, add_table และ output_pdf ตารางจะถูกจัดวางเป็นกริดแบบ row/column (CSS Tables 3 §3.1)

การติดตั้ง

composer require nextpdf/server

หลังจากผูก transport แล้ว อินพุตต้องมี root <table> พร้อมแถว <tr> และเซลล์ <th>/<td> อยู่ภายใน

ภาพรวมเชิงแนวคิด

add_table บังคับใช้ allowlist ของอิลิเมนต์แบบตายตัว (table, thead, tbody, tfoot, tr, th, td, caption, b, i, u, strong, em, br, p, span) และ ตัดแอตทริบิวต์ทั้งหมดทิ้ง จากทุกอิลิเมนต์ ได้แก่ style, class, width, colspan, rowspan, id และส่วนที่เหลือทั้งหมด แท็กใดก็ตามที่อยู่นอก allowlist จะถูกแทนที่ด้วยเนื้อหาข้อความของแท็กนั้น ข้อความในเซลล์ใช้สถานะฟอนต์ที่ใช้งานอยู่ของเอกสาร ซึ่งกำหนดได้ด้วย set_font ก่อน add_table ข้อความจะถูกส่งออกโดยตัวดำเนินการแสดงข้อความตามลำดับใน content stream (ISO 32000-2 §9.4) เอนจินการจัดวางเป็นผู้กำหนดความกว้างของคอลัมน์ ไม่ใช่ inline CSS

พื้นผิว API

เครื่องมือ	บทบาท	ระดับความเสี่ยง
`create_pdf`	เปิดเซสชัน	ปลอดภัย
`set_font`	กำหนดฟอนต์สำหรับข้อความในเซลล์ (ไม่บังคับ ก่อน `add_table`)	ควรระมัดระวัง
`add_table`	sanitize และจัดวางตาราง	ควรระมัดระวัง
`output_pdf`	เรนเดอร์และส่งคืน PDF	ต้องได้รับอนุมัติ / ตรวจสอบ (base64)

หน้า แคตตาล็อกเครื่องมือ เป็นแคตตาล็อกอ้างอิงอย่างเป็นทางการ เครื่องมือที่พร้อมใช้งานขึ้นอยู่กับ tier ที่ติดตั้ง

ตัวอย่างโค้ด — เริ่มต้นอย่างรวดเร็ว

create_pdf (A4 แนวตั้ง, title) → document_id ที่ส่งกลับ
add_table พร้อมสตริง <table>...</table> ที่สมบูรณ์ (แถวส่วนหัวและแถวข้อมูล)
output_pdf → base64 หรือเขียนไฟล์แบบมีการควบคุมเมื่อมี file_path

เคอร์เซอร์จะเลื่อนลงไปใต้แถวสุดท้ายที่เรนเดอร์ และเหลือพื้นที่ไว้สำหรับเนื้อหาที่ตามมา

ตัวอย่างโค้ด — Production

ตรวจสอบความถูกต้องของ HyperText Markup Language (HTML) ก่อนส่ง กำหนดฟอนต์ของเซลล์ด้วย set_font เพื่อให้การจัดวางตัวอักษรมีผลลัพธ์ที่แน่นอน หากพึ่งพาค่าเริ่มต้น ฟอนต์ของเอาต์พุตจะขึ้นอยู่กับการนำไปใช้งาน หากต้องการควบคุมว่าโฮสต์เรียกใช้เครื่องมือใดได้บ้าง ให้จำกัด registry ผ่านนโยบายความปลอดภัย

กรณีขอบและข้อควรระวัง

HTML ที่ว่างเปล่าหรือไม่ใช่ตาราง อินพุตที่ไม่มี <table> จะส่งคืนข้อผิดพลาดว่าไม่มีตารางที่สามารถเรนเดอร์ได้
มาร์กอัปที่มีรูปแบบไม่ถูกต้อง แท็กที่ไม่สมดุลจะส่งคืนข้อผิดพลาดในการแยกวิเคราะห์ จึงควรตรวจสอบความถูกต้องของโครงสร้างก่อน
ตารางกว้างกว่าหน้ากระดาษ ลดจำนวนคอลัมน์ ย่อเนื้อหาให้สั้นลง หรือเปลี่ยนเป็นการวางแนวนอน
การล้น ตารางที่สูงเกินหน้ากระดาษจะไหลไปยังหน้าใหม่ ตรวจสอบ position.page ในการตอบกลับ หรือเรียก add_page ไว้ล่วงหน้า

ประสิทธิภาพ

ตารางขนาดเล็กเรนเดอร์ได้ภายในงบประมาณ และเอาต์พุตมีขนาดเพียงไม่กี่ KB โปรไฟล์คือ structural การ sanitize ทำงานแบบรอบเดียวบน DOM ที่แยกวิเคราะห์แล้ว

หมายเหตุด้านความปลอดภัย

ระบบตัดแอตทริบิวต์โดยไม่มีเงื่อนไขและไม่สามารถข้ามได้ การตัดแอตทริบิวต์นี้ป้องกันการแทรก style และ script ผ่านมาร์กอัปของเซลล์ จึงไม่มี inline CSS, event handler หรือ URL แบบ javascript: หลงเหลืออยู่ allowlist คือขอบเขตความเชื่อถือ จึงไม่ควรถือว่าเอาต์พุตที่เรนเดอร์จะจำลองสไตล์ต้นทางที่กำหนดมาได้อย่างครบถ้วน

ความสอดคล้องตามมาตรฐาน

ข้อความระบุ	ข้อกำหนด	ข้อ	รหัสอ้างอิง (reference_id)
ตารางถูกจัดวางเป็นกริดเซลล์แบบ row/column	CSS Tables 3	§3.1
ข้อความแสดงผลผ่านตัวดำเนินการข้อความตามลำดับในสตรีม	ISO 32000-2	§9.4

บริบทเชิงพาณิชย์

ไม่เกี่ยวข้อง — เครื่องมือทั้งหมดในหน้านี้เป็น Core

ส่วนที่ตัดตอนจากเมทริกซ์การรองรับ CSS (เฉพาะที่ผ่านการตรวจสอบแล้ว)

add_table ไม่ได้เรียกใช้เอนจิน CSS ทั่วไป พฤติกรรม “CSS” เพียงอย่างเดียวคือโมเดลกริดตารางแบบตายตัว แถวและคอลัมน์มาจากโครงสร้างตาราง และเอนจินการจัดวางเป็นผู้เลือกความกว้าง การจัดสไตล์แบบ inline ไม่ได้รับการรองรับโดยตั้งใจ เพราะแอตทริบิวต์ถูกตัดทิ้ง สำหรับการรองรับ CSS ในระดับเอนจิน (ไม่ใช่ Connect) ให้ดูเมทริกซ์การรองรับ CSS ของโปรเจกต์

ข้อจำกัดการสตรีมแบบรอบเดียว

add_table แยกวิเคราะห์มาร์กอัปที่ให้มาเป็น DOM เพียงครั้งเดียวและจัดวางในรอบเดียว ไม่มีการจัดวางใหม่ตาม stylesheet ภายนอก ตารางที่ล้นหน้ากระดาษจะเลื่อนไปยังหน้าถัดไปแทนที่จะจัดวางใหม่ย้อนหลัง

งบประมาณหน่วยความจำสำหรับตารางขนาดใหญ่

ตารางขนาดใหญ่มากจะเก็บ DOM ที่แยกวิเคราะห์แล้วและเซลล์ที่จัดวางแล้วไว้ในหน่วยความจำตลอดทั้งการเรียก แบ่งชุดข้อมูลขนาดใหญ่ออกเป็นการเรียก add_table หลายครั้งเพื่อให้อยู่ภายในงบประมาณหน่วยความจำสูงสุด

ความพร้อมใช้งานของ transport

การส่งข้อมูล (Transport)	พร้อมใช้งาน	หมายเหตุ
MCP (stdio)	ใช่	HTML ขนาดใหญ่ทำให้เฟรม stdio มีขนาดใหญ่ขึ้น
REST	ใช่	ส่ง HTML ใน request body
gRPC	ใช่	การเรียกแบบ unary มีข้อจำกัดด้านขนาดข้อความ

ระดับความเสี่ยง HITL

create_pdf จัดเป็น Safe; set_font และ add_table จัดเป็น Caution; output_pdf จัดเป็น Approval Required และลดระดับเป็น Review ในโหมด base64 เอาต์พุตแบบไฟล์ยังคงเป็น Approval Required ดู output-approval เพิ่มเติม

JSON envelope ของ confirmation gate

เอาต์พุต Base64:

{ "allowed": true }

เอาต์พุตแบบไฟล์จะส่งคืน challenge envelope ตามที่ระบุใน output-approval