Snowflake ID Decoder: ถอดรหัส timestamp ที่ซ่อนอยู่ใน ID ของ Discord, Twitter/X และ Instagram

ID อย่าง 175928847299117063 ดูเหมือนตัวเลขสุ่ม ๆ ธรรมดา แต่จริง ๆ แล้วไม่ใช่เลย Discord, Twitter/X และ Instagram สร้าง object ID ด้วยรูปแบบ Snowflake ซึ่งเป็นตัวเลขขนาด 64-bit ที่บรรจุ creation timestamp ไว้ตรง ๆ ในตัวเลข ทุก message ID, tweet ID และ media ID ต่างพา "เวลาที่ถือกำเนิด" มาด้วย — ซ่อนอยู่ในบรรทัดเดียวอย่างเปิดเผย

Snowflake ID Decoder ช่วยอ่านบิตเหล่านี้ให้คุณ เพียง paste ID แล้วเลือกแพลตฟอร์ม เครื่องมือจะแยกค่าออกเป็น creation timestamp, worker และ datacenter ID และ sequence number ได้ทันที — ทำงานในเบราว์เซอร์ของคุณทั้งหมด ไม่มีข้อมูลใดถูกส่งไปเซิร์ฟเวอร์

ทักษะนี้มีประโยชน์มากกว่าที่คิด ทีม moderation ใช้เช็คว่าบัญชีหรือข้อความถูกสร้างจริงเมื่อไร นักวิเคราะห์ใช้สร้าง timeline จาก ID ที่เจอใน log นักพัฒนาใช้ debug ปัญหา pagination และ rate limit ที่ซ่อนอยู่ใน response ของ API บทความนี้จะพาคุณทำทุกอย่างนี้ได้ภายในไม่กี่วินาที

ทำไมต้องใช้ Snowflake ID Decoder?

• ได้วันที่สร้างจากตัวเลขชุดเดียว user, message หรือ tweet ID บอกได้ว่าถูกสร้างเมื่อไร แม้แพลตฟอร์มจะไม่แสดงฟิลด์นี้ให้เห็นก็ตาม paste ครั้งเดียว ได้คำตอบทันที
• รองรับ epoch ของแต่ละแพลตฟอร์ม Twitter/X เริ่มนับจากพฤศจิกายน 2010, Discord จากมกราคม 2015 และ Instagram จากกันยายน 2011 เครื่องมือเลือก epoch ให้ถูกต้องโดยอัตโนมัติ จึงไม่พลาดไปเป็นปี
• ได้ครบทั้ง layout ไม่ใช่แค่ timestamp คุณยังเห็น worker ID, datacenter ID และ sequence counter — ข้อมูลที่จำเป็นเวลา debug พฤติกรรมของ API
• เป็นส่วนตัว 100% การถอดรหัสรันด้วย JavaScript บนเครื่องคุณ ไม่มีการอัปโหลด ไม่มีบัญชี ไม่มี logging
• ฟรีและทันที ไม่ต้องสมัคร ไม่จำกัดจำนวน ไม่ต้องติดตั้ง เปิดในแท็บเบราว์เซอร์ใดก็ได้ ตอบเร็วเท่าที่คุณ paste
• เป็นสื่อการสอนที่ดี การเห็น sign bit, timestamp, worker และ sequence เรียงกันแบบภาพ ทำให้เข้าใจรูปแบบ Snowflake เร็วกว่าอ่าน spec หลายรอบ

ฟีเจอร์หลัก

การแปลง timestamp แม่นยำถึงระดับมิลลิวินาที และเนื่องจากหนึ่งมิลลิวินาทีบรรจุ ID ได้ถึง 4,096 ค่า segment ของ sequence คือตัวบอกว่าคุณกำลังดูค่าไหน การเลือก epoch ก็สำคัญไม่แพ้กัน: การถอดรหัสค่าเดิมด้วย epoch ผิดให้วันที่ที่ผิดอย่างมั่นใจ เครื่องมือจึงทำให้ทางเลือกนี้มองเห็นชัดเจน

วิธีใช้งาน

1. เปิด Snowflake ID Decoder โหลดทันทีในเบราว์เซอร์ทุกยี่ห้อ ไม่ต้องติดตั้ง ไม่ต้องมีบัญชี
2. Paste 64-bit ID คัดลอก ID ตัวเลขของ message, user หรือ guild ใน Discord, tweet หรือ media object ของ Instagram ลงช่อง input
3. เลือกแพลตฟอร์ม เลือก Discord, Twitter/X หรือ Instagram เพื่อใช้ epoch ที่ถูกต้อง เครื่องมือถอดรหัสสด ๆ ระหว่างที่คุณพิมพ์
4. อ่านผลลัพธ์ที่แยกแล้ว creation timestamp ขึ้นก่อน ตามด้วย worker และ datacenter ID และ sequence number พร้อม bit layout ให้เทียบ
5. คัดลอกหรือแปลงค่าต่อ เก็บ timestamp ที่ได้ไว้ในโน้ต หรือแปลงค่ามิลลิวินาทีดิบด้วย epoch converter หากต้องการหน่วยหรือ timezone อื่น

ข้อผิดพลาดที่พบบ่อยที่สุดคือข้ามขั้นตอนที่ 3 — ถ้าเอา Discord ID ไปถอดด้วย epoch ของ Twitter วันที่จะเพี้ยนไปหลายปีโดยแทบมองไม่ออก

โครงสร้าง Snowflake แบบ 64-Bit

Snowflake ID คือเลขจำนวนเต็มไม่มีเครื่องหมายขนาด 64-bit ที่ประกอบจากสี่ฟิลด์:

• Sign bit (1 บิต) เป็นศูนย์เสมอ เพื่อให้ค่าเป็นบวกในทุกภาษาที่ถือว่าบิตบนสุดคือเครื่องหมาย
• Timestamp (41 บิต) จำนวนมิลลิวินาทีนับจาก epoch ของแพลตฟอร์ม สี่สิบเอ็ดบิตครอบคลุมราว 69 ปี นั่นคือเหตุผลที่ Twitter/X เลือก 4 พฤศจิกายน 2010, Discord เลือก 1 มกราคม 2015 และ Instagram เลือก 28 กันยายน 2011 — แต่ละแพลตฟอร์มเลือก "จุดศูนย์" ที่ใกล้ตัวเพื่อให้บิตเหลือใช้ไกลเข้าอนาคต โดย Instagram ใช้ timestamp 41 บิตเช่นกันแต่แบ่งบิตที่เหลือต่างออกไป (13 บิต shard, 10 บิต sequence)
• Worker และ datacenter ID (10 บิต) ระบุเครื่อง (และในกรณีของ Discord คือ process ภายในเครื่อง) ที่สร้าง ID ทำให้เซิร์ฟเวอร์นับพันสร้าง ID พร้อมกันได้โดยไม่ชนกัน
• Sequence number (12 บิต) ตัวนับรายมิลลิวินาที เมื่อ worker สร้างหลาย ID ในมิลลิวินาทีเดียว sequence จะเพิ่มขึ้น สูงสุด 4,096 ค่าต่อมิลลิวินาทีต่อ worker

ตัวอย่างที่ถอดรหัสครบทุกฟิลด์

ลองใช้ Discord ID 175928847299117063 ซึ่งเป็นตัวอย่างในเอกสารของ Discord เอง sign bit เท่ากับ 0 บิต timestamp ให้ค่า 1,462,015,105,796 ซึ่งบวกกับ epoch ของ Discord ที่ 1,420,070,400,000 ได้ผลลัพธ์ 2016-04-30 11:18:25.796 UTC ส่วน worker ID เท่ากับ 1, process ID เท่ากับ 0 และ sequence เท่ากับ 7

เรียงลำดับได้โดยดีไซน์

โครงสร้างนี้คือเหตุผลที่ Snowflake ชนะ random UUID สำหรับระบบที่มีปริมาณสูง UUID v4 แบบสุ่มไม่มีลำดับ การเรียงตามจึงไม่บอกอะไรเรื่องเวลา และฐานข้อมูลไม่ได้ index locality แต่ Snowflake ID มีลักษณะเกือบ monotonic: ID สองค่าจากแพลตฟอร์มเดียวกันเรียงตามลำดับการสร้างเสมอ ทำให้ pagination แบบ cursor เป็นธรรมชาติและช่วยให้ฐานข้อมูลจัดกลุ่มแถวใหม่ได้

เรื่องความเป็นส่วนตัว

อีกด้านของการเรียงลำดับในตัวคือการเปิดเผยในตัว: ทุก Snowflake ID เปิดเผยเวลาที่สร้างให้ใครก็ตามที่เห็นมัน ID ใน screenshot, log หรือ response ของ API บอกเวลาที่บัญชีหรือไฟล์ปรากฏตัวได้เงียบ ๆ นี่คือ metadata สาธารณะ — แต่ควรรู้ไว้ก่อนเผยแพร่ ID ของคุณเอง

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

ตรวจสอบบัญชีในงาน moderation

บัญชีนี้สร้างเมื่อหลายปีก่อนจริงหรือเพิ่งมาเมื่อวาน? ถอดรหัส user ID ดูสิ — ID บอกเวลาสร้างแม้หน้าจอของแอปจะไม่เคยแสดง ช่วยให้ทีมแยกบัญชีมานานออกจากบัญชีขยะ

Debug API

เมื่อ pagination พังหรือ rate limit ทำตัวแปลก ๆ ID ใน response คือหลักฐานที่ดีที่สุด การถอดรหัส ID ต่อเนื่องกันแสดงให้เห็นว่า object แต่ละตัวถูกสร้างเมื่อไร worker ใดสร้าง และ record กลับมาเรียงผิดลำดับหรือไม่ — ถ้า ID ของ worker หนึ่งย้อนเวลาไปข้างหลัง นั่นคือสัญญาณของ clock skew

การตรวจพิสูจน์ข้อมูล (forensics) และ timeline

log, export และ archive มักมี Snowflake ID โดยไม่มี timestamp กำกับ เพราะเวลาสร้างอยู่ในตัว ID นักสืบสามารถสร้าง timeline จาก ID ล้วน ๆ ได้ — เรียงลำดับเหตุการณ์ เจอช่วงห่าง และผูกกิจกรรมเข้ากับวันที่

เรียงข้อมูลเก่าโดยไม่มีคอลัมน์ timestamp

ตารางที่เก็บ Snowflake ID เป็นตัวเลขธรรมดาเรียงตามเวลาได้ด้วยการ sort แบบตัวเลข ถ้าตารางเก่าเสียคอลัมน์ created_at ไป — หรือไม่เคยมีเลย — ID ก็ยังเก็บลำดับการสร้างไว้ให้

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

• เลือก epoch ของแพลตฟอร์มให้ถูกเสมอ บิตชุดเดียวกันถอดเป็นวันที่ต่างกันตาม epoch ยืนยันแพลตฟอร์มต้นทางก่อนเชื่อวันที่
• จำไว้ว่า ID รั่วเวลาสร้างแบบสาธารณะ ถือว่า timestamp ในตัวเป็น metadata ที่ทุกคนเห็นได้ ถ้าเวลาสร้างเป็นข้อมูลอ่อนไหวในผลิตภัณฑ์ของคุณ อย่าเปิดเผย Snowflake ID ดิบ
• อย่าเอา worker ID ไปทำ analytics มันบอกถึงเครื่องที่ปั๊ม ID ไม่ใช่ผู้ใช้ และโครงสร้างพื้นฐานเปลี่ยนไปตามเวลา — ใช้เป็นเบาะแสตอน debug เท่านั้น
• ถือ ID เป็น string JavaScript และ spreadsheet เสียความแม่นยำเกิน 2^53 — paste ค่าทศนิยมเต็มเป็นข้อความ
• คาดหวังว่า object จะมีอยู่ตั้งแต่ timestamp เป็นต้นไป timestamp คือเวลาที่ ID ถูกสร้าง ไม่จำเป็นต้องเท่ากับเวลาที่ส่งถึงผู้รับจบ
• เจออะไรแปลกให้เทียบกับ ID อีกตัว ถ้าวันที่ดูผิด ถอดรหัส ID ที่เกี่ยวข้องมาเทียบ — epoch ผิดคือสาเหตุของความคลาดเคลื่อนส่วนใหญ่

เริ่มถอดรหัส Snowflake แรกของคุณวันนี้

Snowflake ID เปลี่ยนสายตัวเลขที่อ่านไม่ออกให้เป็นบันทึกที่แม่นยำว่า "เมื่อไร" และ "ที่ไหน" — และ Snowflake ID Decoder เปิดเผยข้อมูลนั้นในไม่กี่วินาที อย่างเป็นส่วนตัวและอยู่ในเบราว์เซอร์ของคุณทั้งหมด ลอง paste ID จาก Discord, Twitter/X หรือ Instagram แล้วดูบิตเรียงเข้าที่

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

• UUID Decoder — แยก UUID เป็น version, variant และฟิลด์ timestamp ที่ฝังอยู่
• Epoch Batch Converter — แปลง Unix timestamp จำนวนมากพร้อมกันสำหรับงาน timeline ก้อนใหญ่
• Unix Timestamp Converter — แปลง Unix timestamp รายตัวให้เป็นวันที่ที่อ่านง่าย

ขอให้สนุกกับการถอดรหัส!

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

ถ: ฉันจะรู้ได้ไหมว่าใครสร้างบัญชีจาก Snowflake ID? ตอบ: ไม่ได้ ID บอกเฉพาะว่าถูกสร้างเมื่อไรและโดย worker ใด — ไม่มีข้อมูลอะไรเกี่ยวกับตัวบุคคล

ถ: ทำไม Discord ID ของฉันถอดแล้วได้วันที่ดูผิด ๆ? ตอบ: ส่วนใหญ่เพราะใช้ epoch ผิด Discord เริ่มนับจาก 1 มกราคม 2015 — เลือกแพลตฟอร์มเป็น Discord แล้วตรวจว่าค่าทศนิยมครบถ้วน

ถ: สอง object แชร์ Snowflake ID เดียวกันได้ไหม? ตอบ: ไม่ได้ worker ID และ sequence 12 บิตการันตีว่าเครื่องเดียวสร้าง ID ไม่ซ้ำได้ถึง 4,096 ค่าต่อมิลลิวินาที และ worker ต่างกันไม่มีทางชนกัน

ถ: เครื่องมือรับ ID ที่ paste มาจาก log หรือ spreadsheet ได้ไหม? ตอบ: ได้ ขอให้ค่าทศนิยมเต็มมาถึงแบบครบถ้วน ระวัง spreadsheet ที่แปลงตัวเลขใหญ่เป็น floating point เพราะถ้าเลขเปลี่ยน วันที่ที่ถอดได้ก็เพี้ยนตาม