FILETIME และ LDAP Timestamp Converter: แปลง timestamp 100 นาโนวินาทีของ Windows ได้ในคลิกเดียว

เคยไหมที่เปิดไฟล์ export จาก Active Directory audit, Windows event log หรือผลค้นหา attribute ของ LDAP แล้วเจอตัวเลขแบบ 134337744000000000 ตัวเลขสิบแปดหลักที่ดูเหมือนสัญญาณรบกวน แต่จริง ๆ แล้วชี้ไปยังช่วงเวลาหนึ่งอย่างแม่นยำถึงหน่วย 100 นาโนวินาที ระบบ Windows, Active Directory, NTFS และผลิตภัณฑ์ของ Microsoft อีกมากมายไม่ได้นับวินาทีจากปี 1970 แบบระบบ Unix แต่นับช่วงเวลา 100 นาโนวินาทีตั้งแต่วันที่ 1 มกราคม ปี 1601 ก่อนที่คุณจะแปลงตัวเลขนี้ ทุกค่าใน pwdLastSet, lastLogonTimestamp หรือ accountExpires ในรายงานของคุณก็อ่านไม่ออกเท่านั้น FILETIME and LDAP Timestamp Converter ฟรีของเราเปลี่ยนเลข 18 หลักพวกนี้เป็นวันที่แบบ ISO 8601, Unix timestamp และข้อความวันที่อ่านง่าย และแปลงย้อนกลับได้สะดวกพอกัน

เครื่องมือนี้ออกแบบมาเผื่อความจริงสุดวิสัยของฟอร์แมตนี้ ตัวเลขมีขนาดใหญ่เกินกว่าการคำนวณด้วยทศนิยมลอยทั่วไปจะแม่นได้ เครื่องมือจึงใช้ BigInt แบบจำนวนเต็มเป๊ะ ๆ ไม่มีทางเสียหลักไหนไปกับการปัดค่า ทุกอย่างทำงานในเบราว์เซอร์ของคุณทั้งหมด ไม่ต้องอัปโหลด ไม่ต้องสมัครสมาชิก ไม่ต้องรอ วางค่า อ่านผล ก๊อปใส่รายงาน แล้วไปต่อ

บทความนี้จะพาไล่ดูวิธีใช้เครื่องมือทีละขั้น ทำไม Windows ถึงเริ่มนับเวลาจากปี 1601 การแปลงไปเป็น Unix time ทำงานอย่างไร และฟอร์แมตนี้ซ่อน edge case ไว้ตรงไหน รวมถึงค่า sentinel อันโด่งดังที่แปลว่า "ไม่มีวันหมดอายุ" ซึ่งหลอกผู้ตรวจสอบมาแล้วหลายคน

ทำไมต้องใช้ FILETIME Converter?

• แปลงได้สองทิศทางในที่เดียว: ถอด FILETIME เป็น ISO 8601, Unix time และวันที่อ่านง่าย หรือป้อนวันที่เข้าไปเพื่อหาค่า 18 หลักสำหรับใช้ในสคริปต์และ query ก็ได้
• คำนวณด้วย BigInt แม่นยำ: ค่า FILETIME ของยุคปัจจุบันใหญ่เกินกว่าเลขทศนิยมลอยจะเก็บได้ครบ เครื่องมือใช้จำนวนเต็ม BigInt หลักสุดท้ายจึงไม่มีวันถูกปัดหายเงียบ ๆ
• ออกแบบมาเพื่องาน Active Directory: รองรับ attribute ที่เจอจริงอย่าง pwdLastSet, lastLogonTimestamp และ accountExpires ทำให้รายงาน audit และสคริปต์เก็บกวาดบัญชีได้ข้อมูลที่เชื่อถือได้
• อ่านทั้ง ISO 8601 และ Unix time: เครื่องมือยุคใหม่คุยกันด้วย ISO 8601 ขณะที่แพลตฟอร์ม log และ API ใช้ Unix time แปลงครั้งเดียวได้ทั้งสองแบบ
• ทำงานในเบราว์เซอร์ 100 เปอร์เซ็นต์: คณิตศาสตร์ทั้งหมดเกิดขึ้นในเครื่องคุณ ข้อมูลโดเมนจากงาน audit ไม่มีทางหลุดออกนอกเครื่อง ซึ่งสำคัญมากเวลาทำงานกับข้อมูล identity ของระบบ production
• ไม่ต้องติดตั้ง ไม่มีขั้นตอนยุ่งยาก: เปิดหน้าเว็บ วางค่า อ่านผล ไม่มีอะไรต้องดาวน์โหลด ไม่มีบัญชีต้องสร้าง ไม่ว่าจะนั่งอยู่ที่โต๊ะทำงานหรือกำลังยุ่งกับเหตุการณ์ด้านความปลอดภัย

ฟีเจอร์หลัก

• คำนวณใหม่ทันที ทุกครั้งที่พิมพ์ ผลลัพธ์อัปเดตระหว่างนิ้วยังเลื่อนไม่พ้น ไล่ตรวจค่ายาว ๆ ได้รวดเดียวจบ
• แสดงผลแบบ UTC เป็นหลัก ปิดช่องโหว่คลาสสิกของการแปลงหลักฐาน audit ไปตกอยู่เขตเวลาท้องถิ่นผิดโดยไม่ตั้งใจ
• ตรวจสอบย้อนกลับได้ encode วันที่ที่รู้จัก แปลงกลับ แล้วเทียบกับค่าในไฟล์ export เพื่อยืนยันว่าตรงกัน

วิธีใช้งาน

1. เปิดเครื่องมือ เข้าหน้า FILETIME and LDAP Timestamp Converter ในเบราว์เซอร์ของคุณ
2. วางค่าที่ต้องการแปลง คัดลอกเลข 18 หลักจาก export ของ AD, event log หรือผล LDAP search มาวางในช่อง FILETIME เช่น 134337744000000000
3. อ่านผลลัพธ์ เครื่องมือแสดง timestamp แบบ ISO 8601 (2026-09-13T12:00:00Z), ค่า Unix time (1789300800) และวันที่ภาษาคนทันที
4. สลับทิศทางเมื่อต้องการ ถ้าจะสร้างค่า FILETIME สำหรับสคริปต์ ให้กรอกวันที่และเวลาแทน ค่า tick 100 นาโนวินาทีที่เป๊ะจะโผล่มาทันที
5. ก๊อปผลลัพธ์ กดปุ่มคัดลอกเพื่อยกค่าไปวางในรายงาน audit, LDAP filter หรือ query ของ log ได้เลย

Epoch ปี 1601 และ Tick 100 นาโนวินาที

Windows วัดเวลาด้วยจำนวนช่วงเวลา 100 นาโนวินาที — มักเรียกว่า tick — ที่ผ่านไปตั้งแต่ 00:00:00 UTC ของวันที่ 1 มกราคม ปี 1601 ทางเลือกนี้ดูแปลกจนกว่าคุณจะนึกถึงประวัติศาสตร์ปฏิทินเบื้องหลัง ปฏิทินเกรกอเรียนวนรอบรูปแบบปีอธิกสุรทินทุก 400 ปี และวันที่ 1 มกราคม ปี 1601 เปิดรอบ 400 ปีแบบนี้พอดี การวาง epoch ไว้ต้นรอบสมบูรณ์ทำให้นักพัฒนา NT คำนวณเรื่องปีอธิกสุรทินได้ง่ายขึ้นมาก เพราะทุกช่วงสี่ศตวรรษมีจำนวนวันเท่ากันเป๊ะและคำนวณได้ตรง ๆ

สะพานเชื่อมสอง epoch ใหญ่คือค่าคงที่ตัวหนึ่ง จากปี 1601 ถึงปี 1970 มีเวลาผ่านไป 11644473600 วินาที (369 ปี รวมปีอธิกสุรทินด้วย) ทั้งการแปลงจึงเหลือแค่สองขั้น ถอดจาก FILETIME ไปเป็น Unix time ให้ลบ 11644473600 วินาทีออกจากจำนวน tick แล้วหารด้วย 10,000,000 เพราะหนึ่งวินาทีมีสิบล้าน tick ทิศกลับกันคือคูณ Unix timestamp ด้วย 10,000,000 แล้วบวกค่าคงที่เดิมเข้าไป ตัวอย่างจริงจะเห็นภาพชัด: 134337744000000000 tick หารด้วยสิบล้านได้ 13433774400 วินาทีนับจากปี 1601 ลบ 11644473600 ออกเหลือ 1789300800 วินาทีนับจากปี 1970 ซึ่งก็คือ 2026-09-13T12:00:00Z วันอาทิตย์เที่ยง UTC พอดี

ทำไมต้องย้ำเรื่อง BigInt เลขทศนิยมความละเอียดคู่แทนจำนวนเต็มได้ครบเฉพาะไม่เกิน 2 ยกกำลัง 53 หรือราว 9007199254740992 ขณะที่ค่า FILETIME ปัจจุบันอยู่แถว 1.34 คูณสิบยกกำลัง 17 ใหญ่กว่ากันราวหมื่นห้าพันเท่า พอส่งเลขเข้าเลขคณิตทศนิยมทั่วไป หลักท้ายจะเปลี่ยนไปเงียบ ๆ ผลลัพธ์เลื่อนไปเสี้ยววินาทีหรือถ้าค่าใหญ่ขึ้นก็เป็นวินาทีเต็ม เครื่องมือนี้คำนวณทุกอย่างด้วยจำนวนเต็ม BigInt ข้อมูลที่ป้อนเข้าไปจึงถูกนับครบทุกหลักจริง ๆ

หลาย attribute ของ Active Directory เก็บเวลาในฟอร์แมตนี้พอดี และนั่นคือเหตุผลที่คนส่วนใหญ่ต้องมีตัวแปลงติดมือ pwdLastSet บันทึกว่ารหัสผ่านเปลี่ยนล่าสุดเมื่อไหร่ ซึ่งเป็นฐานของรายงานหมดอายุรหัสผ่าน lastLogonTimestamp เป็นค่าประมาณเวลาล็อกอินแบบโต้ตอบล่าสุดที่คนมักไป query (ข้อควรรู้คือ AD อัปเดตค่านี้เฉพาะตอน replication เท่านั้น จึงหลังจากเวลาจริงได้ถึง 14 วันโดยการออกแบบ) ส่วน accountExpires และ lockoutTime ปิดท้ายชุด attribute ที่คุณจะเจอในงาน audit

สุดท้ายอย่าลืมค่า sentinel ค่า FILETIME เท่ากับ 0 มักแปลว่า "ไม่เคยถูกตั้ง" เช่นบัญชีที่ไม่เคยล็อกอินเลย หรือรหัสผ่านที่ไม่เคยถูกเปลี่ยนในแบบที่ AD บันทึกไว้ ส่วนค่า 9223372036854775807 คือจำนวนเต็ม 64 บิตแบบมีเครื่องหมายที่มากที่สุดเท่าที่จะเก็บได้ ใน accountExpires ค่านี้แปลว่าบัญชีไม่มีวันหมดอายุ ทั้งสองค่าเป็นสถานะตั้งใจที่ถูกต้อง ไม่ใช่ข้อมูลเสีย เครื่องมือจะแจ้งให้ทราบเพื่อที่คุณจะรายงานว่า "ไม่มี" แทนที่จะได้วันที่ไร้สาระย้อนอนาคตไกลออกไป

กรณีใช้งานจริง

ตรวจสอบบัญชีใน Active Directory

งานทบทวนสิทธิ์เข้าถึงรอบไตรมาสและการล่าบัญชีเก่าค้าง ชี้เป็นชี้ตายที่ lastLogonTimestamp ทั้งหมด export วัตถุ user ออกมา แปลงทุกค่า 18 หลัก แล้วจัดเรียงตามวันที่จริงเพื่อหาบัญชีที่ไม่ถูกใช้ 90 หรือ 180 วัน การทำมือล้วน ๆ ทรมานมาก แต่กับเครื่องมือนี้คุณสุ่มตรวจแถวที่น่าสงสัยจบในไม่กี่วินาที และวางวันที่อ่านง่ายลงในหลักฐาน audit ได้เลย

รายงานหมดอายุรหัสผ่าน

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

วิเคราะห์ไทม์ไลน์เหตุการณ์

Windows event log และ artifact ทางนิติวิทยาศาสตร์คอมพิวเตอร์โรยค่า FILETIME ไว้ทั่วทั้งเหตุการณ์ยืนยันตัวตน กิจกรรมไฟล์ และการเขียน registry การแปลงทุกค่ามาอยู่บนสเกล UTC เดียวกันทำให้คุณจับหลักฐานฝั่ง Windows มาเทียบกับ log ไฟร์วอลล์ ระเบียน VPN และข้อมูลใน SIEM ที่พูดภาษา Unix time ได้ ไทม์ไลน์การโจมตีจึงกลับมาเป็นเส้นเดียวกัน ไม่ใช่สามเส้นขนานกันไป

ย้ายข้อมูลและเชื่อมต่อระบบ

เวลา identity เคลื่อนจาก AD ไประบบ directory อื่นหรือระบบ HR ฟิลด์ timestamp ต้องถูกแปลงอย่างซื่อสัตย์ การ encode วันที่เป้าหมายเป็น FILETIME ช่วยให้สคริปต์ย้ายข้อมูลกรองได้เป๊ะ (เช่นเอาเฉพาะบัญชีที่ active หลังเส้นตายที่กำหนด) ขณะที่การ decode ใช้ตรวจความถูกต้องว่าข้อมูลที่ไปถึงปลายทางตรงกับต้นทางทุกหลัก

แนวปฏิบัติที่ดี

• จัดการค่า sentinel อย่างชัดเจน: ให้ถือว่า 0 และ 9223372036854775807 คือ "ไม่มี" หรือ "ไม่เคย" ใน logic และรายงาน การเอาไปแปลงเป็นวันที่ปกติจะได้ผลลัพธ์ที่หลอกตัวเอง
• ระบุเขตเวลาเสมอ: ทั้ง FILETIME และ Unix time แท้จริงคือ UTC เก็บหลักฐานเป็น UTC แล้วค่อยแปลงเป็นเวลาท้องถิ่นเฉพาะตอนนำเสนอ และใส่ชื่อเขตเวลากำกับทุกครั้งที่แชร์ออกไป
• ตรวจกับบัญชีที่รู้จักจริง: ก่อนเชื่อการแปลงเป็นชุด ให้ถอด timestamp หนึ่งตัวจากบัญชีที่คุณยืนยันกิจกรรมได้จากแหล่งอื่น แล้วเช็กว่าผลของเครื่องมือตรงกับความจริง
• อย่าเข้าใจว่า lastLogonTimestamp เป็นข้อมูลเรียลไทม์: ค่านี้หน่วงจาก replication 9 ถึง 14 วันโดยการออกแบบ ถ้าต้องการค่าเป๊ะต้องไปดู lastLogon ที่ domain controller แต่ละตัว ซึ่งไม่ replicate กัน
• รักษาความละเอียดเต็มรูปแบบตั้งแต่ต้นจนจบ: หลีกเลี่ยง pipeline ที่ส่ง timestamp ผ่านเลขทศนิยมหรือตัด string ใช้โค้ดที่รองรับ BigInt หรือเครื่องมือนี้ เพื่อให้ tick สุดท้ายรอดออกมาครบ
• ใส่หมายเหตุฟอร์แมตไว้ในไฟล์ export: เมื่อส่งสเปรดชีตให้ผู้ตรวจสอบหรือเพื่อนร่วมงาน เขียนกำกับว่าคอลัมน์เลข 18 หลักคือค่า FILETIME เพื่อไม่ให้ใครอ่านผิดเป็น Unix หน่วยมิลลิวินาที

เลิกถอดรหัส FILETIME ด้วยมือเถอะ

เลขสิบแปดหลักที่นับจากปี 1601 ไม่ควรมาเบียดเสียดายเวลาทำ audit งานสืบสวน หรือการย้ายระบบ FILETIME and LDAP Timestamp Converter แปลงสองทิศทางอย่างแม่นยำระหว่าง tick ของ Windows, ISO 8601 และ Unix time ด้วยความเป๊ะระดับ BigInt ทำงานในเบราว์เซอร์ทั้งหมด ฟรี ไม่ต้องสมัครสมาชิก เก็บไว้ในรายการโปรดไว้รอคราวที่ไฟล์ LDAP export ตกมาในกล่องจดหมายครั้งหน้า แล้วปล่อยให้ค่าคงที่ 11644473600 อยู่ในที่ที่มันควรอยู่ นั่นคือข้างในเครื่องมือ

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• Unix Timestamp Converter — ถอดและสร้างค่า epoch แบบวินาทีนับจากปี 1970 สำหรับ log และ API
• Date Range Splitter — แบ่งช่วงเวลา audit เป็นช่วงรายวันหรือรายสัปดาห์สำหรับ query เป็นชุด
• Text Case Converter — ปรับรูปแบบตัวอักษรของ distinguished name, ชื่อ attribute และหัวข้อรายงานให้เป็นระเบียบ

ขอให้สนุกกับการแปลง timestamp ครับ

คำถามที่พบบ่อย

ถ: FILETIME หรือ LDAP timestamp เป็นฟอร์แมตแบบไหนกันแน่?

ตอบ: เป็นจำนวนช่วงเวลา 100 นาโนวินาทีที่ผ่านไปตั้งแต่ 00:00:00 UTC ของวันที่ 1 มกราคม ปี 1601 เก็บเป็นจำนวนเต็ม 64 บิตแบบมีเครื่องหมาย Windows, NTFS, Active Directory และผลิตภัณฑ์ของ Microsoft จำนวนมากใช้ฟอร์แมตนี้ภายใน ค่าที่โผล่มาในไฟล์ export และ raw attribute จึงเป็นเลขยาว 18 หลัก

ถ: ถ้าจะแปลง FILETIME เป็น Unix time ด้วยมือต้องคิดยังไง?

ตอบ: ลบ 11644473600 ซึ่งคือจำนวนวินาทีระหว่าง epoch ปี 1601 กับปี 1970 ออกจากจำนวน tick แล้วหารด้วย 10,000,000 เพราะหนึ่งวินาทีมีสิบล้าน tick ผลลัพธ์คือ Unix time มาตรฐานในหน่วยวินาที ทิศกลับกันคือคูณด้วยสิบล้านแล้วบวกค่าคงที่คืนเข้าไป

ถ: ทำไมต้องใช้ BigInt กับการแปลงนี้ด้วย?

ตอบ: ค่า FILETIME ของยุคปัจจุบันใหญ่กว่าเพดานราว 9 ล้านล้าน (quadrillion) ที่เลขทศนิยม 64 บิตจะแทนจำนวนเต็มได้ครบถ้วน เลขคณิตแบบ number ทั่วไปจะปัดหลักท้ายหายไปเงียบ ๆ ทำให้ผลเพี้ยนไปเป็นเสี้ยววินาทีที่จับต้องได้ ส่วน BigInt เป๊ะทุกหลัก tick จึงไม่หายสักตัว

ถ: ค่า 9223372036854775807 แปลว่าอะไร?

ตอบ: นั่นคือจำนวนเต็ม 64 บิตแบบมีเครื่องหมายที่มากที่สุด และ Active Directory ใช้เป็นค่า sentinel ใน accountExpires ค่านี้แปลว่าบัญชีไม่มีวันหมดอายุ ส่วนค่า 0 ก็หมายถึง "ไม่เคยถูกตั้ง" สำหรับ attribute อย่าง lastLogonTimestamp ทั้งคู่ควรถูกรายงานเป็นสถานะพิเศษ ไม่ใช่แปลงเป็นวันที่

ถ: ข้อมูล Active Directory ของฉันถูกส่งขึ้นเซิร์ฟเวอร์ไหนเมื่อใช้เครื่องมือนี้?

ตอบ: ไม่ การแปลงทั้งหมดทำงานฝั่งไคลเอนต์ในเบราว์เซอร์ด้วย JavaScript ในเครื่อง เลข 18 หลักที่คุณวางไม่มีทางออกนอกอุปกรณ์ของคุณ เครื่องมือจึงใช้กับข้อมูล identity ของระบบ production จากงาน audit และ incident response ได้อย่างปลอดภัย