เครื่องพิมพ์ดีดเก่าบนโต๊ะไม้ในห้องโทนเขียวเข้ม ใต้แผ่นป้ายทองเหลืองว่างสองแผ่นที่ดูเกือบเหมือนกัน แผ่นหนึ่งมีแสงอำพันกระทบ

Python แก้ช่องโหว่แปลงชื่อเว็บ: ตัวพิมพ์เล็กทำให้ระบบมองคนละโดเมน

น้องกายEngineering

ช่องโหว่แปลงชื่อเว็บใน Python ได้คะแนนความรุนแรง 6 แปลว่าอยู่ระดับปานกลาง ตามทะเบียน CVE ที่ปรับปรุงวันที่ 2 ตุลาคม 2026 ซึ่งเป็นรายการอ้างอิงช่องโหว่สาธารณะ ทีม Python ออกแพตช์แล้ว โดยPython Insider ยืนยันว่ารุ่นที่ประกาศรอบนี้แก้ปัญหานี้ด้วยครับ

เรื่องนี้เกี่ยวกับชื่อเว็บที่ใช้ตัวอักษรนอกภาษาอังกฤษ เพราะชื่อเดียวกันอาจถูกแปลงเป็นคนละผลลัพธ์ Seth Larson ผู้ทำงานด้านความปลอดภัยให้ Python Software Foundation อธิบายว่า ต้นเหตุอยู่ที่การเรียกฟังก์ชันเปลี่ยนตัวพิมพ์เล็ก ด้วยกฎตัวอักษรที่ไม่ตรงกับมาตรฐาน แต่ยังไม่มีหลักฐานในแหล่งข้อมูลชุดนี้ว่าอักษรไทยได้รับผลกระทบ

สรุป 30 วินาที: เกิดอะไรขึ้น

ชื่ออ้างอิงของปัญหาคือ CVE-2026-17084 แปลว่าเป็นรหัสสำหรับติดตามช่องโหว่เดียวกันในเอกสารต่างแหล่ง ทะเบียน CVE ระบุว่า ส่วนประกอบชื่อ stringprep ซึ่งเตรียมข้อความก่อนนำไปใช้ ประมวลผลคุณสมบัติของตัวอักษรผิดจากกฎที่กำหนด ผลจึงกระทบการแปลงชื่อโดเมน หรือชื่อเว็บที่ระบบใช้ระบุปลายทาง

ทะเบียนนี้เผยแพร่วันที่ 18 สิงหาคม 2026 แปลว่าปัญหาถูกประกาศต่อสาธารณะก่อนข่าวอัปเดตรอบเดือนตุลาคม ตามเวลาที่บันทึกใน CVE ส่วนประกาศ Python Insiderระบุว่าแพตช์จำกัดการใช้คุณสมบัติตัวอักษรให้ตรงกับมาตรฐานแล้ว จึงมีรุ่นแก้ไขให้เลือกตามสายที่ระบบใช้อยู่

แต่ขอบเขตแคบกว่าคำว่า “Python แปลงตัวพิมพ์เล็กไม่ปลอดภัย” ครับ Real Python ย้ำว่า ช่องโหว่อยู่ในส่วนเตรียมข้อความและตัวแปลงชื่อโดเมนมาตรฐานเก่า การเรียก str.lower() เพื่อเปลี่ยนข้อความทั่วไปไม่ได้เป็นช่องโหว่นี้ไปทั้งหมด แล้วฟังก์ชันเล็กขนาดนี้ไปเกี่ยวกับความปลอดภัยของชื่อเว็บได้อย่างไร?

ทำไมเรื่องนี้เกี่ยวกับคุณ

สำหรับคนทำงานหรือเจ้าของร้าน จุดที่ควรสนใจคือโปรแกรมของคุณตัดสินใจเรื่องชื่อเว็บอย่างไร Real Python อธิบายว่า เมื่อส่วนต่าง ๆ ของระบบเข้าใจไม่ตรงกันว่ากำลังพูดถึงโดเมนใด ผู้โจมตีย่อมมีช่องให้ใช้ประโยชน์ นี่เป็นความเสี่ยงด้านการตรวจปลายทาง มากกว่าปัญหาตัวอักษรบนหน้าจอดูไม่สวย

ลองคิดเป็นกรณีสมมติว่าโปรแกรมธุรกิจมี allow-list หรือรายชื่อเว็บที่อนุญาตให้ติดต่อ หากส่วนตรวจรายชื่อกับส่วนใช้งานชื่อเว็บแปลงข้อความต่างกัน ผลการอนุญาตอาจไม่สะท้อนปลายทางเดียวกัน นี่เป็นตัวอย่างเชิงแนวคิดจากความไม่ตรงกันที่Real Python กล่าวถึง ไม่ใช่รายงานว่าร้านค้าไทยถูกโจมตีด้วยวิธีนี้แล้ว

สำหรับผู้ปกครอง นักศึกษา หรือพนักงานทั่วไป การเห็นชื่อช่องโหว่นี้ยังไม่ใช่หลักฐานว่ามือถือหรือบัญชีถูกเจาะ ทะเบียน CVE จำกัดเงื่อนไขไว้ที่ชื่อโดเมนซึ่งมีตัวอักษรบางกลุ่ม ข้อเสนอสำหรับคุณคือส่งข่าวให้ผู้ดูแลโปรแกรมตรวจรุ่นและการใช้งาน ไม่ต้องเดาเองจากภาษาที่ปรากฏในชื่อเว็บ

ทำงานยังไง

Unicode คือชุดข้อมูลที่กำหนดตัวอักษรและคุณสมบัติของมัน เช่น การเปลี่ยนตัวพิมพ์ใหญ่เป็นตัวพิมพ์เล็ก Seth Larson อธิบายว่า มาตรฐานอินเทอร์เน็ตบางส่วนอ่านได้เฉพาะ ASCII ซึ่งเป็นชุดอักขระพื้นฐานที่มีตัวอักษรอังกฤษ จึงต้องมีวิธีแปลงชื่อเว็บภาษาอื่นให้ระบบเหล่านั้นอ่านได้

IDNA คือกติกาสำหรับนำชื่อโดเมนที่มีตัวอักษรหลากหลายภาษามาใช้กับระบบอินเทอร์เน็ต Punycode คือรูปแบบเข้ารหัสชื่อเหล่านั้นให้เป็นอักขระ ASCII ที่ระบบอ่านได้ Real Python อธิบายผลของบั๊กว่า ชื่อโดเมนเดียวกันอาจกลายเป็นข้อความ Punycode ต่างกัน ทั้งที่จุดเริ่มต้นเป็นตัวอักษรชุดเดียวกัน

ก่อนแปลงชื่อ ระบบต้องจัดข้อความให้อยู่ในรูปที่เปรียบเทียบกันได้ ขั้นตอน case folding คือปรับรูปตัวอักษรเพื่อให้เทียบข้อความโดยไม่ติดเรื่องตัวพิมพ์ใหญ่หรือเล็ก ตามคำอธิบายของ Seth Larson ขั้นตอนนี้อยู่ใน StringPrep และถูกนำไปใช้กับ NamePrep ซึ่งเป็นส่วนเตรียมชื่อโดเมนตามมาตรฐานเก่า

มาตรฐานดังกล่าวล็อกกฎไว้ที่ Unicode 3.2.0 แปลว่าต้องใช้คุณสมบัติตัวอักษรจากฐานข้อมูลรุ่นนั้น Seth Larson ระบุว่า Python มีฐานข้อมูลเก่านี้ให้ใช้อยู่แล้ว แต่คำสั่ง str.lower() กลับอิงข้อมูล Unicode ที่มากับตัว Python แต่ละรุ่น จึงมีโอกาสใช้กฎใหม่ในขั้นตอนที่ต้องใช้กฎเดิม

ตัวอย่างจาก Seth เป็นอักษร Cherokee รหัส U+13A0 แปลว่าเป็นตำแหน่งอ้างอิงตัวอักษรเฉพาะใน Unicode เขาแสดงว่าการใช้กฎคนละรุ่นทำให้ชื่อแปลงออกมาต่างกัน ตัวอย่างนี้ไม่ได้เป็นอักษรไทย และไม่ใช่หลักฐานว่าชื่อเว็บทุกภาษาจะมีปัญหาเหมือนกัน

เปรียบเหมือนร้านข้าวตามสั่งที่หน้าร้านกับครัวใช้สมุดชื่อเมนูคนละฉบับครับ ลูกค้าบอกชื่อเดียวกัน แต่คนรับออเดอร์กับคนทำอาหารจับคู่เป็นคนละเมนู การแก้ไม่ใช่สั่งให้ทุกคนอ่านเร็วขึ้น แต่ต้องให้ขั้นตอนที่เกี่ยวข้องอ้างสมุดฉบับเดียวกัน อุปมานี้อธิบายความคลาดเคลื่อนของกฎ ไม่ได้หมายความว่ามีระบบร้านอาหารใดถูกโจมตี

ข้อเสนอแก้ไขใน CPython ซึ่งเป็นตัว Python ที่ทะเบียน CVE ระบุเป็นผลิตภัณฑ์ ยืนยันว่าต้องใช้ฐานข้อมูลตามมาตรฐานอย่างเคร่งครัด Seth Larson อธิบายวิธีแก้ว่า เพิ่มข้อยกเว้นสำหรับตัวอักษรที่กฎปัจจุบันต่างจากกฎเก่า เพื่อให้ผลในฟังก์ชันนี้กลับมาตรงตามข้อกำหนด

จุดหักมุม: ใหม่กว่าอาจผิดกติกาเดิม

แต่การรองรับตัวอักษรใหม่ขึ้นไม่ได้ทำให้ทุกขั้นตอนถูกต้องขึ้นเสมอครับ CPython PR ระบุว่า บั๊กเกิดจากการพิจารณาคุณสมบัติที่ยังไม่มีในฐานข้อมูลเก่า หรือเปลี่ยนไปในรุ่นภายหลัง กฎที่ถูกต้องจึงขึ้นกับมาตรฐานของงานนั้น

อีกด้านคือการติดตั้งแพตช์ไม่ได้เปลี่ยนมาตรฐานเก่าเป็นมาตรฐานใหม่ Seth Larson ระบุว่า การแก้ครั้งนี้ทำให้ตัวแปลงแบบเดิมกลับมาสอดคล้องกับข้อกำหนด การเปลี่ยนมาตรฐานเป็นอีกการตัดสินใจหนึ่งของผู้พัฒนา

เรื่องเงิน / ผลกระทบ

ทะเบียน CVEประเมินผลกระทบต่อความถูกต้องของระบบไว้ระดับสูงในองค์ประกอบคะแนน ขณะที่คะแนนรวมอยู่ระดับปานกลาง แต่เอกสารชุดนี้ไม่มีมูลค่าความเสียหาย จำนวนเหยื่อ หรือรายชื่อองค์กรไทยที่ได้รับผลกระทบ จึงไม่ควรแปลงคะแนนให้กลายเป็นยอดเงินที่เสียไป

สำหรับธุรกิจเล็ก ผมเสนอให้เริ่มจากขอรายการโปรแกรมที่เกี่ยวข้องกับชื่อเว็บก่อน แล้วกำหนดผู้รับผิดชอบการอัปเดตและทดสอบ งานนี้ช่วยให้ตัดสินใจจากการใช้งานจริง เพราะขอบเขตใน CVEไม่ได้ระบุว่าโปรแกรมทุกชนิดที่เขียนด้วย Python มีช่องทางโจมตีเหมือนกัน

เรื่องที่อาจเพิ่มภาระการดูแลคือรุ่นเก่าบางสายไม่ได้แจกตัวติดตั้งสำเร็จรูป Python Insider ระบุว่ารุ่นแก้ไขในสายเก่าบางรุ่นเป็น source-only แปลว่าแจกซอร์สโค้ดให้สร้างโปรแกรมแทนตัวติดตั้ง Windows หรือ macOS ทีม IT จึงควรตรวจช่องทางอัปเดตของระบบตนเองก่อนนัดเวลาเปลี่ยน

รุ่นที่แก้แล้วตามทะเบียน CVE มีดังนี้ แต่ละรายการแปลว่าเป็นจุดเริ่มต้นของรุ่นแก้ไขในสายนั้น ไม่ได้แปลว่าเลขรุ่นจากต่างสายเปรียบเทียบกันตรง ๆ ได้ อ้างอิงทะเบียนฉบับปรับปรุง:

  • 3.10.22 — แปลว่าเป็นรุ่นแก้ไขในสายเก่านี้ และเป็นรุ่นสุดท้ายของสายตามPython Insider
  • 3.11.17 — แปลว่าเป็นรุ่นแก้ไขของสายนี้ โดยประกาศทางการระบุว่าแจกเฉพาะซอร์สโค้ด
  • 3.12.15 — แปลว่าเป็นรุ่นแก้ไขของสายนี้ และประกาศทางการระบุว่าแจกเฉพาะซอร์สโค้ดเช่นกัน
  • 3.13.16 — แปลว่าเป็นรุ่นแก้ไขของสายนี้ และประกาศทางการระบุว่ามีตัวติดตั้งสำเร็จรูป
  • 3.14.8 — แปลว่าเป็นรุ่นแก้ไขของสายนี้ และประกาศทางการระบุว่ามีตัวติดตั้งสำเร็จรูป
  • 3.15.0rc2 — แปลว่าแพตช์อยู่ในรุ่นทดสอบก่อนออกจริงแล้ว ตามทะเบียน CVE

รายละเอียดรูปแบบการแจกจ่ายในรายการข้างต้นมาจากประกาศ Python Insider แต่สถานะ “มีแพตช์” กับ “ยังมีคนดูแลต่อ” ต้องอ่านแยกกัน ประกาศเดียวกันระบุว่าสายเก่าที่จบอายุจะไม่ได้รับอัปเดตความปลอดภัยต่อ อ่านบริบทเพิ่มได้ในบทความ Python รุ่นสุดท้ายกับการกวาดแพตช์ความปลอดภัย

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

ฝั่งสนับสนุนการเปลี่ยนมาตรฐาน: Seth Larson แนะนำให้ใช้แพ็กเกจภายนอกชื่อ idna ซึ่งเป็นชุดโปรแกรมเสริม เมื่อต้องการกฎ IDNA 2008 แปลว่าใช้มาตรฐานชื่อโดเมนรุ่นใหม่กว่า คำแนะนำของเขาคือใช้แทน .encode("idna") เมื่อทำได้ เพราะคำสั่งที่ติดมากับ Python ใช้กฎรุ่นเดิม

ข้อจำกัดต่อการเปลี่ยนทันที: Seth Larson คนเดียวกันยอมรับว่าบางงานยังจำเป็นต้องใช้พฤติกรรมเก่า เขาระบุข้อยกเว้นนี้ไว้ในบทความ จึงไม่มีหลักฐานว่าเขาเรียกร้องให้ทุกระบบเปลี่ยนพร้อมกัน และไม่มีแหล่งใดในชุดนี้คัดค้านการติดตั้งแพตช์ อย่าสร้างคู่ขัดแย้งขึ้นมาแทนข้อจำกัดด้านความเข้ากันได้ครับ

ฝั่งเตือนเรื่องจังหวะย้ายรุ่น: Real Python แนะนำให้ระบบใช้งานจริงรอความพร้อมของส่วนเสริมก่อนย้ายไปสายใหม่ คำเตือนนี้พูดถึงการย้ายรุ่นใหญ่ ไม่ได้บอกให้คงรุ่นที่มีช่องโหว่ไว้ ดังนั้นการอัปเดตรุ่นแก้ไขในสายเดิมกับการย้ายสายจึงวางแผนแยกกันได้

ชื่อฟังก์ชันในเอกสารไม่ตรงกัน: คำบรรยาย CVE ใช้ชื่อ in_table_b2() แต่ท้ายไฟล์แหล่งข้อมูลเดียวกันใช้ map_table_b2() ส่วนบทความ Seth Larson อธิบายเส้นทางการแมปผ่าน map_table_b3() ข้อความที่มีไม่พอให้ผมตัดสินว่าชื่อแรกเป็นความคลาดเคลื่อนแบบใด ทีมตรวจโค้ดควรค้นทั้งโมดูล ไม่ยึดคำเดียวจากคำบรรยาย

วันของประกาศรุ่นก็ต้องระวัง: ไฟล์ Python Insiderมี URL ของเดือนตุลาคม แต่ช่องวันที่ในข้อมูลประกอบกลับระบุปีเก่าที่ไม่สอดคล้องกัน ผมจึงอ้างเนื้อหาการออกแพตช์โดยไม่ยืนยันวันเผยแพร่จากช่องนั้น ส่วนวันที่เผยแพร่และปรับปรุงทะเบียน CVE มาจากบันทึกของ CVE โดยตรง

เรื่องที่ยังตอบไม่ได้: ไม่มีข้อมูลในชุดนี้ว่าพบการโจมตีจริงในไทย หรือระบบของคุณเรียกส่วนที่มีปัญหาหรือไม่ CVE ระบุเพียงตัวอักษรที่ยังไม่ถูกลงทะเบียนในฐานข้อมูลเก่า หรือมีคุณสมบัติเปลี่ยนภายหลัง จึงยังสรุปไม่ได้ว่าอักษรไทยได้รับผลกระทบ ถ้าโปรแกรมของร้านตรวจชื่อเว็บผิด จะมีใครตรวจพบก่อนลูกค้าหรือเปล่า?

แล้วเราควรทำอะไร

คนทั่วไป พนักงาน ผู้ปกครอง และนักศึกษา — ทำตามได้เลย

  1. ส่งรหัสช่องโหว่และประกาศรุ่นแก้ไขให้ผู้ดูแลโปรแกรมหรือฝ่าย IT ขอให้ยืนยันว่าเครื่องที่ทำงานจริงใช้รุ่นใด ไม่ต้องติดตั้ง Python เองเพียงเพราะเห็นข่าว
  2. ถ้าคุณใช้โปรแกรมที่มีผู้ขายดูแล ให้ถามว่าโปรแกรมเกี่ยวข้องกับตัวแปลงชื่อโดเมนนี้หรือไม่ และมีอัปเดตที่รวมแพตช์หรือยัง คำถามนี้อิงขอบเขตผลิตภัณฑ์และโมดูลใน CVE ไม่ใช่การกล่าวหาว่าผู้ขายถูกโจมตีแล้ว
  3. หากใช้ Python เรียนหรือทำงานเอง ให้ตรวจเลขรุ่นจากโปรแกรมที่ใช้งานอยู่ แล้วเทียบรายการแก้ไขข้างต้น ก่อนอัปเดตให้เก็บงานและทดสอบงานเดิม แนวทางนี้แยกการแก้ช่องโหว่ออกจากการเปลี่ยนรุ่นใหญ่ตามข้อควรระวังของReal Python

ทีม IT และเจ้าของธุรกิจ — ทำตามได้เลย

  1. ตรวจรุ่น Python ที่ระบบบริการใช้จริง พร้อมช่องทางที่ติดตั้งมา ขอหลักฐานสถานะแพตช์จากผู้ดูแลระบบ แล้วเทียบกับทะเบียน CVE การเห็นรุ่นบนคอมของผู้พัฒนาอย่างเดียวไม่ตอบเรื่องเครื่องบริการ
  2. อัปเกรดเป็นรุ่นแก้ไขที่เหมาะกับสายเดิม แล้วทดสอบงานเกี่ยวกับชื่อเว็บและการอนุญาตปลายทาง เหตุผลคือแพตช์ทำให้ผลแปลงกลับมาตรงตามมาตรฐาน จึงควรตรวจว่าโปรแกรมเดิมรับผลที่ถูกต้องได้
  3. ถ้ายังอยู่ในสายที่หมดอายุ ให้แยกแผนติดตั้งแพตช์รอบนี้ออกจากแผนย้ายสายที่ยังดูแล Python Insider ขอให้ผู้ใช้สายที่จบอายุวางแผนอัปเกรด การแก้บั๊กวันนี้ไม่ได้รับประกันว่าจะมีแพตช์ครั้งหน้า

นักพัฒนา — ทำตามได้เลย

  1. ค้นโค้ดที่ใช้ .encode("idna") และ stringprep แล้วระบุว่าข้อมูลนั้นไปใช้ตรวจชื่อเว็บส่วนใดต่อ ตามเส้นทางที่ Seth Larson อธิบาย อย่าเริ่มด้วยการแทนคำสั่งเปลี่ยนตัวพิมพ์เล็กทุกจุด
  2. ตรวจว่าจุดอนุญาตชื่อเว็บและจุดนำชื่อไปใช้จริงเลือกกติกาเดียวกันหรือไม่ ทดสอบความสอดคล้องของผลโดยไม่สร้างขั้นตอนโจมตี เหตุผลคือReal Python ชี้ว่าความไม่ตรงกันระหว่างส่วนของระบบคือความเสี่ยง
  3. ประเมินการใช้แพ็กเกจ idna ตามคำแนะนำของ Seth Larson พร้อมทดสอบข้อมูลเดิมและความเข้ากันได้ หากงานจำเป็นต้องใช้พฤติกรรมมาตรฐานเก่า ให้ใช้ตัว Python ที่แก้แล้วและบันทึกเหตุผลไว้

ผมมองว่า…

ผมมองว่า เรื่องนี้ไม่ใช่การแข่งขันว่าใครใช้ Unicode ใหม่ที่สุด แต่คือการทำให้ระบบที่ตรวจและระบบที่ใช้งานจริงเข้าใจชื่อเดียวกัน การมีข้อมูลใหม่เป็นเรื่องหนึ่ง การใช้ข้อมูลตรงกับกติกาของงานเป็นอีกเรื่องหนึ่ง บทเรียนนี้ตามมาจากสาเหตุและวิธีแก้ที่ Seth Larson อธิบาย ไม่ใช่ผลทดลองใหม่ของผม

ผมมองว่า คนทำงานไม่จำเป็นต้องจำชื่อตารางตัวอักษร แต่ควรรู้ว่าจะขอคำยืนยันจากใคร ส่วนทีม IT ควรตอบให้ได้ทั้งรุ่นที่ใช้งานและสถานะของโค้ดแปลงชื่อเว็บ ผมให้น้ำหนักกับหลักฐานเหล่านี้มากกว่าคำว่า “อัปเดตแล้ว” ที่ไม่ระบุระบบ เพราะขอบเขต CVEผูกกับทั้งรุ่นและเงื่อนไขของข้อมูล

ปิดท้าย: สิ่งที่ต้องจับตา

ชื่อเว็บที่เชื่อถือได้ต้องเริ่มจากทุกส่วนของระบบตีความชื่อให้ตรงกัน สิ่งแรกที่ควรติดตามคือคำยืนยันว่าโปรแกรมที่คุณใช้รวมแพตช์ตามทะเบียน CVEแล้ว สิ่งถัดมาคือแผนย้ายออกจากสายที่Python Insider ประกาศจบการดูแล โดยไม่สับสนกับการแก้บั๊กรอบนี้

สำหรับคนเตรียมย้ายสายใหม่ Real Python รายงานกำหนดรุ่นจริงวันที่ 9 ตุลาคม 2026 แปลว่าเป็นวันตามแผนที่ควรติดตาม ไม่ใช่เหตุผลให้เลื่อนแพตช์ของสายเดิม คุณรู้หรือยังว่าใครเป็นคนรับผิดชอบอัปเดต Python ในโปรแกรมที่ใช้ทำงานประจำ?

Recap

  • เกิดอะไรขึ้น: ส่วนเตรียมชื่อเว็บใช้คุณสมบัติตัวอักษรผิดจากมาตรฐาน และมีแพตช์แก้แล้ว
  • ตัวเลขที่ต้องจำ: คะแนน 6 แปลว่าความรุนแรงรวมระดับปานกลาง ไม่ใช่มูลค่าความเสียหาย
  • ใครเห็นต่าง: ไม่มีแหล่งคัดค้านแพตช์ แต่ Seth Larson ระบุว่างานบางชนิดยังต้องใช้มาตรฐานเก่า ส่วน Real Python เตือนให้ทดสอบก่อนย้ายรุ่นใหญ่
  • ยังไม่รู้: ไม่มีข้อมูลยืนยันผลกระทบต่ออักษรไทย การโจมตีจริงในไทย หรือสถานะโปรแกรมของคุณ
  • กระทบคุณอย่างไร: ผู้ดูแลโปรแกรมที่แปลงและตรวจชื่อเว็บควรตรวจทั้งรุ่นและความสอดคล้องของกฎ
  • ควรทำอะไร: ตรวจรุ่น อัปเกรดตามสาย ค้นการใช้ตัวแปลงชื่อเว็บ และวางแผนย้ายออกจากสายที่หมดอายุ
  • สิ่งที่ต้องจับตา: คำยืนยันแพตช์จากผู้ดูแล และความพร้อมของระบบก่อนเปลี่ยนมาตรฐานหรือย้ายสาย
  • แหล่งอ้างอิง: 1 — Seth Larson, 2 — CVE, 3 — CPython PR, 4 — Python Insider, 5 — Real Python