Markdown TOC Generator: สร้างสารบัญคลิกได้จาก Markdown ในไม่กี่วินาที
เรียนรู้วิธีใช้ Markdown TOC Generator สร้างสารบัญแบบคลิกได้ รองรพ anchor สไตล์ GitHub, GitLab และ Pandoc พร้อมปรับความลึกของ heading ได้ตามต้องการ
Table of Contents
เอกสาร Markdown ที่ยาวขึ้นเรื่อ่ย ๆ — ไม่วาจะเป็น README ของโปรเจกต์, technical spec, หรือบล็อกโพสต์ — จะอ่านยากขึ้นทันที่ถ้าไม่มีสารบัญ (Table of Contents) คอยนำทาง ผู้อ่านต้อง scroll หาหัวข้อเอง เสี่ยงพลาดเนื้อหาสำคัญ และดูไม่มืออาชีพ การนั่งพิมพ์ส์ารบัญด้วยมือก็เสียเวลา แถมยังผิดพลาดง่าย โดยเฉพาะเมื่อต้องแปลงหัวข้อเป็น anchor link ให้ถูกต้องตามแพลตฟอร์ม
Markdown TOC Generator จาก Online Tools Forge คือเครื่องมือที่ช่วยแก้ปัญหานี้ — เพียงวางเนื้อหา Markdown ลงไป เครื่องมือจะ parse หัวข้อทั้งหมดและสร้างสารบัญแบบ nested bullet list พร้อมลิงก์ anchor ที่คลิกได้ทันที รองรพ anchor style ทั้ง GitHub, GitLab และ Pandoc ปรับความลึกของ heading ไดตั้งแต่ H1 ถึง H1–H6 ทำงานทั้งหมดบน browser ของคุณ ฟรี และไม้ต้องสมัครสมาชิก
ในโพสต์นี้ เราจะพาไปดูวาทำไม่สารบัญถิงสำคัญสำหรับเอกสาร Markdown, ฟีเจอร์เด่นของเครื่องมือ, วิธีใช้งานแบบขันตอนตอขันตอน, และเจาะลึกเรื่อง anchor style ทั้งสามแบบเพื่อให้คุณเลือกใช้ได้ออกอย่างถูกต้อง
ทำไม่ต้องใช้ Markdown TOC Generator?
- ประหยัดเวลา: สารบัญสำหรับเอกสาร 30 หัวข้อใช้เวลาไม่ถึง 5 วินาที แทันที่จะต้องพิมพ์ทุก ลิงก์ด้วยมือ
- ไม่มีทางผิด anchor: เครื่องมือสร้าง slug ตามกฎของแตล่ะแพลตฟอร์มให้อัตโนมัติ ไม่ต้องเดาวา GitHub จะตัดเครื่องหมายอะไรออกบาง
- อัปเดตง่าย: เมื่อโครงสร้างเอกสารเปลี่ยน แควาง Markdown ใหม่แล้ว generate ใหม่ ได้สารบัญทั้งหมดในครังเดียว
- นำทางได้จริง: ลิงก์ [text](#anchor) คลิกแล้วกระโดดไปหัวข้อนั้นทันที เหมาะกับ README และเอกสารยาว ๆ บนเว็บ
- ควบคุมความลึกได้: เลือกแสดงเฉพาะ H1–H2 หรือลงลึกถึง H6 ตามความเหมาะสมของเอกสาร ไม่ให้สารบัญยาวเกินจำเป็น
- รองรับหลายแพลตฟอร์ม: GitHub, GitLab และ Pandoc ใช้กฏการสร้าง anchor ต่างกัน เครื่องมือนี้เลือกใหตรงปลายทางได้
ฟีเจอร์เด่น
| ฟีเจอร | รายละเอียด |
|---|---|
| รองรับหัวข้อ | ATX-style (# Heading) และ Setext-style (ขีดเสนใต้) |
| Anchor styles | GitHub, GitLab, Pandoc |
| ความลึกสูงสุด | ตั้งแต่ H1 ถึง H1–H6 |
| รูปแบบผลลัพธ์ | Nested Markdown bullet list ของ [text](#anchor) |
| ปูมกระทำ | Copy, Download, Clear |
| การทำงาน | Client-side 100% — ข้อมูลไม่ออกจาก browser |
- Parse หัวข้อไดทั้งสองรูปแบบ: ไม่วาคุณจะเขียนหัวข้อแบบ ## Heading หรือแบบ Setext ที่ใช้ === และ --- ขีดเสนใต้ เครื่องมือก็จับไดทั้งคู้
- Copy / Download / Clear: สำเนาผลไปวางในเอกสารด้วยคลิกเดียว, download เป็นไฟล์, หรือลางพื้นที่เพื่อเริ่มตนใหม่
- ความเป็นส่วนตัว: เนื่องจากทำงาน client-side ทั้งหมด โค้ดและเอกสารของคุณไม่ถูกสงไป server ใด ๆ ใช้งานได้อย่างสบายใจ
วิธีใช้งาน
- เปิดหน้า Markdown TOC Generator
- วางเนื้อหา Markdown ของคุณลงในช่อง input (จะ paste ทั้งไฟล์ หรือพิมพ์ก็ได)
- เลือก anchor style ที่ต้องการ — GitHub, GitLab หรือ Pandoc — และกำหนดความลึกสูงสุดของ heading
- ผลลัพธ์สารบัญจะปรากฏขึ้นทันที ตรวจสอบวาหัวข้อและลำดับถูกต้อง
- กด Copy เพื่อนำไปวางในเอกสาร หรือกด Download เพื่อบันทึกเป็นไฟล์
เข้าใจ Anchor Styles: GitHub vs GitLab vs Pandoc
หัวใจของสารบัญ Markdown คือ anchor — คือ slug ที่ถูกสร้างจากข้อความหัวข้อ แล้วใช้เป็น target ของลิงก์ #anchor แต่ละแพลตฟอร์มมีวิธี "slugify" หัวข้อที่ตางกัน ถ้าเลือก style ไม่ตรงกับปลายทาง ลิงก์จะคลิกไม่ไป
GitHub เป็นแบบที่คนใช้งานมากที่สุด กฎคือ: แปลงตัวพิมพ์ทุก ตัวเป็นตัวพิมพ์เล็ก, แทันที่ช่องวางด้วย -, ตัดเครื่องหมายวรรคตอนออก (เช่น :, ,, !, ?) และเก็บเฉพาะตัวอักษร ตัวเลข และ - เช่น หัวข้อ ## Getting Started! จะกลายเป็น #getting-started สำหรับหัวข้อที่ซ้ำกัน GitHub จะเติม -N ตอทาย โดยตัวแรกไมีม suffix ตัวที่สองเป็น -1 ตัวที่สามเป็น -2 ไปเรื่อย ๆ เช่น ## FAQ สองครัง จะได้ #faq และ #faq-1 ตามลำดับ
GitLab ใช้แนวคิดคลายกันแตมีรายละเอียดตางออกไป เช่น การจัดการอักขระบางตัวและการนับหัวข้อซ้ำ ทาให้ slug ที่ได้อาจไม่เหมือน GitHub ทุกตัวอักษร ถ้าเอกสารของคุณ host อยบน GitLab (เช่น wiki ของ repo หรือ GitLab Pages) ควรเลือก style นี้เพื่อให้อ้างอิงได้ถูก
Pandoc เป็นตัวแปลงเอกสารสารพดัประโยชน์ที่ใช้งานในวง academic และ static site generators หลายตัว Pandoc มีกฎการสร้าง identifier ของตัวเอง เช่น การตัดคำนำหน่าบางประเภทและการจัดการ Unicode ที่แตกต่าง่างางไป ถ้าคุณ build เอกสารด้วย Pandoc หรือ framework ที่ใช้มัน เลือก Pandoc style จะปลอดภัยที่สุด
แล้วทำไม่ anchor ถิงสําคัญขนาดนั้น? เพราะ README และเว็บเอกสารสมัยใหม่ถูก render เป็น HTML ที่มี navigation ภายใน — ถ้า anchor ในสารบัญไม่ตรงกับที่ renderer สร้างไว ลิงก์จะ "ตาย" คลิกแล้วไม่เกิดอะไรขึ้น ผ้อ่านเสียความเชื่อถือ และดไมูมืออาชีพ การใช้เครื่องมือที่คํานวณ slug ตามกฎจริงของแพลตฟอร์มจึงเป็นทางลัดที่ตัดความเสี่ยงนี้ทิ้งไปเลย
ตัวอย่างง่าย ๆ: ถ้า Markdown ของคุณคือ
# Project Overview ## Installation ## Usage ### Basic Usage ### Advanced Usage
สารบัญที่ generate ได (GitHub style, depth H1–H3) จะเป็น:
- [Project Overview](#project-overview)
- [Installation](#installation)
- [Usage](#usage)
- [Basic Usage](#basic-usage)
- [Advanced Usage](#advanced-usage)
กรณีใช้งานจริง
README navigation
README ที่ดีควรมีสารบัญอยูตอนบนเสมอ โดยเฉพาะ repo ที่มีหัวข้อมากกว่า 5–6 หัวข้อ เช่น Installation, Configuration, API Reference, Troubleshooting การ generate TOC ด้วย GitHub style แล้ววางไวหลังคำอธิบายสั้น ๆ ช่วยให developer คนอื่นกระโดดไปสวนที่ต้องการไดทันที โดยไม่ต้องอ่านทั้งหมด
เว็บเอกสาร
ถาคุณเขียน docs ด้วย static site generator เช่น MkDocs, Docusaurus หรือ Astro บางธีมไม่มี auto-TOC ในหน้า การแทรกสารบัญที่ generate แล้วไวตนหน่าช่วยให navigation ดขึ้นมาก และถา pipeline ของคุณใช้ Pandoc ก็เลือก Pandoc style ใหตรงกันได้เลย
Technical spec
เอกสาร spec ทียาวหลายสิบหน่ามักมีโครงสร้างลึกถึง H3–H4 การจำกัด depth ของ TOC ใหอยูที่ H1–H2 แล้วใช้ heading ยอยในเนื้อหาช่วยใหสารบัญกระชับ แตยังเห็นภาพรวมครบ ถ้าต้องการรายละเอียดเพิ่มก็คอยขยาย depth เป็น H1–H4
บล็อกโพสต์
บล็อกสาย technical ที่เขียนด้วย Markdown ก็ไดประโยชน์เช่นกัน สารบัญช่วยให SEO ดขึ้น (search engine เขาใจโครงสร้างหน้า) และลด bounce rate เพราะผ้อ่านหาเรื่องที่สนใจเจอเร็วขึ้น
Best Practices
- ตั้งชื่อหัวข้อให้สื่อความหมายและไม่ซ้ำ: หัวข้อที่ชัดเชนทำให anchor อ่านง่าย และหลีกเลี่ยงปัญหา -1, -2 ตอทายที่ดูรุงรัง
- จำกัดความลึกของ TOC: เอกสารสวนใหญอ่านสบายที่สุดเมื่อสารบัญแสดงแค H1–H2 หรือ H1–H3 ลงลึกกว่านั้นมักยาวเกินจำเป็น
- วาง TOC หลัง intro: ใหผ้อ่านเห็นภาพรวมของเอกสารกอน แล้วคอยตามด้วยสารบัญ จะดูเป็นธรรมชาติกว่าวางไวบรรทัดแรกสุด
- สร้างใหม่หลังปรับโครงสร้าง: ทุกครั้งทีเพิ่ม ลบ หรือเปลี่ยนลำดับหัวข้อ ให generate สารบัญใหม่เสมอ เพื่อไม่ให้อ้างอิงผิด
- ใช้ GitHub style สำหรับ repo: ถาเอกสารอยูบน GitHub (README, wiki, docs ใน repo) เลือก GitHub style คือตัวเลือกที่ปลอดภัยที่สุด
- ตรวจลิงก์หลัง render: หลังวางสารบัญในเอกสารจริง ลองคลิกสัก 2–3 ลิงก์เพื่อยืนยันวา anchor ตรงกับ platform ที่ใช้
เริ่มสร้างสารบัญของคุณวันนี้
ไม่ต้องเสียเวลากับการพิมพ์ส์ารบัญด้วยมือหรือนั่งเดากฎ anchor ของแต่ละแพลตฟอร์มอีกต่อไป — วาง Markdown ของคุณลงใน Markdown TOC Generator เลือก style ที่ตรงกับปลายทาง ปรับความลึก แล้ว copy ผลลัพธ์ไ์ปใช้งานไดในไม่กี่วินาที ฟรี ไม่ต้องสมัครสมาชิก และข้อมูลของคุณไม่ออกจาก browser
เครื่องมือที่เกี่ยวของ
- Markdown Table Generator — สร้างตาราง Markdown จากข้อมูลหรือ CSV พรอมจัด format ให้อ่านง่าย
- Markdown Preview — ดูตัวอย่างการ render เอกสาร Markdown แบบ real-time กอนนำไปใช้งานจริง
- Markdown to HTML Converter — แปลง Markdown เป็น HTML สำหรับใช้ในเว็บหรือ email
ขอใหสนุกกับการเขียนเอกสาร!