ตัวแปลงไฟล์ HWP แบบอาศัย Pandoc - ขอแนะนำเครื่องมือโอเพนซอร์สสำหรับแปลง md, html, docx เป็น hwpx
(github.com/msjang)พัฒนาขึ้นเพื่อแก้ความไม่สะดวกของการทำงานเอกสาร HWP หลังจากทำงานในสถาบันวิจัยของรัฐมา 9 ปี
ที่มาของการพัฒนา
- ปี 2018: ช่วงที่ยังเป็นมือใหม่ Python ได้ลองทำตัวแปลง HML/HWPML แบบอิง regular expression - https://github.com/msjang/md2hml
- มกราคม 2025: พัฒนา
hwpfy- รวบรวมรายงานงานประจำสัปดาห์ของคนราว 20 คนจากวิกิที่แก้ไขร่วมกันแบบเรียลไทม์
- วิกิ → ส่งออกเป็น DOCX → แปลงเป็น DOCX ที่ใส่แบบฟอร์มราชการ (
hwpfy) → เปิดในแอป Hangul แล้วบันทึกเป็น HWPX → แชร์เป็น HWPX ให้หน่วยงานระดับบนภายในสถาบัน
- ธันวาคม 2025:
pypandoc-hwpx- ตอนนี้คิดว่าสั่งสมประสบการณ์มามากพอแล้ว จึงตั้งใจลงทุนเวลาและพัฒนาอย่างจริงจัง
วิธีพัฒนา
- สร้าง DOCX ตามรูปแบบที่ต้องการ แล้วบันทึกเป็น HWPX
- แตกไฟล์ DOCX และ HWPX ที่สร้างขึ้นด้วย unzip เพื่อดู XML จากนั้นลบแอตทริบิวต์ที่ไม่จำเป็นและปรับแต่ง แล้วตรวจสอบด้วยว่าสามารถเปิดได้ดีทั้งใน Word และแอป Hangul
- สร้างเอกสารเปรียบเทียบฟอร์แมต md, html, docx, hwpx - https://github.com/msjang/pypandoc-hwpx/…
- เดิมทีตั้งใจจะให้ LLM ช่วยเขียนโค้ดจาก
format_comparison.mdข้างต้น แต่ก็ตระหนักได้ว่าในสถานการณ์นี้มี HWPX ฉบับคำตอบอยู่แล้ว - สร้างขึ้นโดยรับฟีดแบ็กหลายรอบกับ Antigravity(Gemini Pro 3) เพราะผลลัพธ์ไม่ออกมาในรูปแบบที่ต้องการ จึงไล่ดู XML อย่างละเอียดแล้วให้ฟีดแบ็กเพิ่มเติม แม้จะไม่ได้อ้างถึงเอกสารเปรียบเทียบฟอร์แมตโดยตรง แต่การทำความเข้าใจเนื้อหาในนั้นช่วยให้รีวิวได้มาก
สิ่งที่จะทำต่อไป
อยากถอด Python ออกจาก Pypandoc แล้วเขียนด้วย Haskell เพื่อมีส่วนร่วมเพิ่ม HWPX writer ให้กับ Pandoc
7 ความคิดเห็น
https://velog.io/@wjsdj2009/…
มีบทความแบบนี้อยู่ ลองติดต่อบรรดานักการเมืองดูไหม...?
ดูเหมือนจะเป็นไอเท็มที่ Hancom ควรพัฒนาขึ้นมาก่อนเองด้วยซ้ำ... ถ้า Hancom มีความตั้งใจจะขยายไปต่างประเทศนะครับ
ขอเป็นกำลังใจให้การมีส่วนร่วมกับ Haskell!
เดิมทีตั้งใจจะค่อย ๆ ทำอย่างช้า ๆ ในช่วงหนึ่งถึงสองเดือน แต่เมื่อวานนี้มีข่าว https://youtu.be/8cSqPRsM_Yg ออกมา ก็เลยรีบทำขึ้นมาอย่างเร่งด่วน
เจ๋งมากครับ
แต่อาจจะเสียมารยาทนิดหน่อย แต่ทิศทางการแปลงที่ประธานาธิบดีต้องการ
คงเป็น
hwp* -> .md, docs, pdf plain text ...ไม่ใช่หรือครับ? โปรเจกต์นี้รองรับการแปลงย้อนกลับด้วยหรือเปล่าครับ?มีไลบรารีสำหรับแยกวิเคราะห์
hwpหรือhwpxอยู่มากมายนับแต่อดีต ตัวอย่างที่มีชื่อเสียงในฝั่ง Java คือสิ่งนี้https://github.com/neolord0/hwplib
https://github.com/neolord0/hwpxlib
ฝั่ง Python ก็มีตัวที่ห่อหุ้ม Hancom win32 api ไว้ นี่คือตัวที่มักปรากฏในคอร์สสอน HWP automation ยุคแรก ๆ
https://pypi.org/project/pyhwpx/
มีอีกตัวที่ใช้ Python จัดการ HWPX แบบ standalone ได้โดยไม่ต้องมีโปรแกรมแยก สามารถอ่านหรือแทนที่ข้อมูลได้ และยังเพิ่มย่อหน้าหรือตารางได้ด้วย https://github.com/airmang/python-hwpx
แต่พอลองคิดดูแล้ว พวกเราส่วนใหญ่สื่อสารกับแอป LLM กันอยู่แล้ว เราเข้าใช้งาน ChatGPT, Claude, Gemini ผ่านเว็บเบราว์เซอร์และสนทนากัน แม้จะรันโมเดลโลคัลด้วย OpenWebUI ก็ยังเข้าใช้งานผ่านเว็บเบราว์เซอร์ ผลลัพธ์จากโหมดเสียงของแอป ChatGPT บนสมาร์ตโฟนก็สามารถย้อนมาดูบันทึกการแชตบนเว็บเบราว์เซอร์ได้ และถ้ากดปุ่มคัดลอก output ของ LLM แล้วเอาไปวางใน Notepad ก็จะเห็นว่าเป็น markdown
เมื่อมีทั้ง markdown หรือ html จาก LLM แล้ว มีไลบรารีที่แปลงสิ่งนี้เป็น hwpx เพื่อบันทึกได้ทันทีไหม? ไม่มี
เวลาคิดไอเดียสิทธิบัตรกับ GEMINI Pro มันจะถามว่าให้ทำเป็นเอกสารไหม แล้วพอกดปุ่มก็จะมีร่างคำอธิบายสิทธิบัตรถูกสร้างเป็นเอกสาร Google Docs ไว้ให้ จริง ๆ แล้วก็แค่แปลงมาร์กดาวน์เป็นเอกสาร แต่ผลลัพธ์ก็ดูดีใช้ได้ทีเดียว
ไม่ว่าจะชอบหรือไม่ เกาหลีใต้ได้กำหนดให้ HWP เป็นมาตรฐานของการดำเนินงานและการสื่อสาร และใน workflow การทำงานของเรา การสร้าง HWP ก็ถือเป็นเรื่องธรรมดาในอีกความหมายหนึ่ง
หลังจากให้ ChatGPT โหมดเสียงฟังเนื้อหาการประชุมทั้งหมดแล้ว เราอาจสั่งว่า ‘ช่วยสรุปเป็นบันทึกการประชุมและส่งอีเมลให้ผู้เข้าร่วมด้วย’ หรือ ‘ช่วยทำสิ่งที่ brainstorm กันไว้ให้เป็นร่างคำอธิบายสิทธิบัตร’ เป็นต้น ซึ่งในมุมนี้ผลลัพธ์ควรจะต้องเป็น HWP
ที่ผ่านมา มนุษย์ยังต้องคัดลอกผลลัพธ์จาก LLM จากเว็บเบราว์เซอร์ไปยังแอป Hangeul แล้วค่อยจัดรูปแบบ ปรับความกว้างอักษร ระยะห่างตัวอักษร และจัดหน้าอย่างขยันขันแข็ง
ในยุคที่ GEMINI สร้าง Google Docs ให้ได้แล้ว บริการและโมเดล LLM ที่ใช้เงินภาษีของเกาหลีใต้ก็ควรจะสร้าง HWPX ได้โดยไม่ต้องมีมนุษย์เข้ามาแทรกแซงไม่ใช่หรือ?
ผมมีความต้องการแบบนี้เพื่อทำงานอัตโนมัติ และนั่นคือเหตุผลที่ผมสร้างมันขึ้นมา
เพิ่มเติมเล็กน้อย
ตัว HWP เองนั้น ถ้าจะแยกวิเคราะห์แล้วแปลงเป็นข้อความก็ทำได้ไม่ยาก Google ได้สร้างสิ่งนี้ขึ้นมาตั้งแต่ช่วงทศวรรษ 2000 เพื่อทำดัชนีเอกสารภาษาเกาหลี และได้นำไปใช้ภายในอยู่แล้ว อีกทั้งโอเพนซอร์สที่กล่าวถึงข้างต้นก็เพียงพอสำหรับเรื่องนี้
หากใส่สไตล์ระดับโครงร่าง 1~6 ที่สอดคล้องกับ
h1~h6ของ HTML ก็สามารถสร้างเอกสารโดยคงลำดับชั้น (hierarchy) ของเอกสารไว้ได้แต่ HWP มีฟีเจอร์ในตัวแก้ไขเยอะเกินไป และผู้ใช้ก็มุ่งเน้นการจัดรูปแบบให้เอกสารที่พิมพ์ลงกระดาษดูดี จึงไม่ได้พยายามใช้ระดับโครงร่าง (outline level) ตอนจัดรูปแบบมากนัก
ตัวอย่างที่เห็นชัดคือ เมื่อบันทึกเอกสาร HWP ความยาว 300 หน้าในสถาบันวิจัยเป็น PDF กลับไม่มีข้อมูลบุ๊กมาร์กถูกสร้างขึ้นมาเลย ดังนั้นแม้จะเป็นเอกสารอิเล็กทรอนิกส์ก็ยังต้องเลื่อนหาเอง ซึ่งไม่สะดวกมาก และถ้าเป็น PDF ไฟล์ใหญ่ ไม่ว่าคอมพิวเตอร์จะดีแค่ไหน หากเลื่อนเร็ว ๆ เพื่อกวาดดูเนื้อหา ก็มักจะกระตุกมาก
เพราะไม่สามารถทำแบบนี้ตอนประเมินสถาบันได้ จึงต้องพิมพ์รายงานหลายร้อยหน้าออกมาเป็นตั้ง ๆ ตามจำนวนกรรมการผู้ประเมิน แล้วใช้ประเมินสถาบัน และเมื่อประเมินเสร็จก็ทิ้งทันที
ส่วนรายงานจากต่างประเทศนั้น หากได้รับรายงาน PDF ยาว 400 หน้า แค่สารบัญก็ยาว 16 หน้าแล้ว และในสารบัญยังมีลิงก์ให้คลิกไปยังหน้าที่เกี่ยวข้องได้ด้วย ถ้าเปิดดูแบบโครงร่างก็จะเห็นว่าบุ๊กมาร์กถูกแบ่งอย่างละเอียดและจัดไว้อย่างดี สิ่งนี้หมายความว่า ในเครื่องมือมีการป้อนข้อมูลที่จำเป็นได้อย่างง่ายดายโดยที่ผู้ใช้ไม่ต้องใส่ใจมากนัก จึงสร้างสิ่งเหล่านี้ขึ้นมาอัตโนมัติได้
อย่างไรก็ตาม กลับมาที่ประเด็นเดิม จาก HWP ที่ถูกสร้างขึ้นภายใต้วิธีปฏิบัติที่คนส่วนใหญ่ยังใช้ Hancom Hangul กันอยู่ในปัจจุบันนั้น เราสามารถดึงข้อความออกมาได้ แต่ยากที่จะได้ข้อมูลลำดับชั้นของเอกสาร
แต่ถ้าสร้าง HWP ด้วย LLM โดยไม่มีการแทรกแซงจากมนุษย์ ก็สามารถคำนึงถึงจุดนี้และสร้างออกมาโดยอัตโนมัติได้