ไทย

ข้อมูลและสเปรดชีต · CSV สะอาดยิ่งขึ้น

การเข้ารหัสอักขระสำหรับผู้ใช้สเปรดชีต: ASCII, Windows-1252 และ UTF-8

· พื้นหลัง

csv การเข้ารหัส ข้อมูลรูปแบบ

ASCII ข้อความที่เข้ากันได้ที่ส่งผ่าน UTF-8 ในขณะที่ไบต์เดิมที่ไม่รองรับจะหยุดที่ขอบเขตที่ทำเครื่องหมายไว้
ภาพประกอบเวกเตอร์ต้นฉบับ ToolAcre

การเข้ารหัสคือการตกลงกันว่าไบต์ใดหมายถึงอักขระใด และไฟล์ CSV จะไม่ระบุว่าใช้อักขระใด โพสต์นี้จะอธิบาย ASCII, Windows-1252 และ UTF-8 อย่างชัดเจน เหตุใด UTF-8 จึงได้รับชัยชนะ และสิ่งที่มีความหมายต่อการส่งออก

"มันเป็นปัญหาการเข้ารหัส" เป็นคำอธิบายที่ไม่ได้อธิบายอะไรเลย จริงๆ แล้วการเข้ารหัสคืออะไร

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

ข้อตกลงของ ToolAcre มีความชัดเจน: ข้อความที่เลือกอ่านเป็น UTF-8 และเฉพาะเครื่องหมายลำดับไบต์ UTF-8 นำหน้าเท่านั้นที่จะได้รับการจัดการพิเศษ สัญญาแบบแคบนี้มีประโยชน์มากกว่าการแกล้งทำเป็น CSV มีป้ายกำกับการเข้ารหัส ผู้ส่งออกและผู้รับจะต้องตกลงกันก่อนจึงจะสามารถเชื่อถือได้ในการล้างโครงสร้าง

ASCII: แกนที่ใช้ร่วมกัน — เจ็ดบิต, ตัวอักษรภาษาอังกฤษและเครื่องหมายวรรคตอน และเหตุใดจึงเป็นเรื่องปกติในการเข้ารหัสเกือบทุกรูปแบบ

อักขระ ASCII ซ้อนทับกับ UTF-8 สำหรับตัวอักษรภาษาอังกฤษ ตัวเลข และเครื่องหมายวรรคตอนที่คุ้นเคยซึ่งใช้โดยไวยากรณ์ CSV ส่วนใหญ่ นั่นคือสาเหตุที่ไฟล์สามารถดูดีได้จนกว่าชื่อลูกค้าหรือสัญลักษณ์จะมีไบต์อยู่นอกช่วงที่ใช้ร่วมกัน พื้นที่เก็บข้อมูลสนับสนุนการสังเกตเชิงปฏิบัตินี้ แต่ไม่ใช่แหล่งที่มาหลักสำหรับประวัติ ASCII หรือลำดับเหตุการณ์การออกแบบที่แน่นอน

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

ASCII การทับซ้อนกันเป็นบริบทที่มีประโยชน์ ในขณะที่จำนวนบิตและประวัติจำเป็นต้องมีแหล่งข้อมูลภายนอก

โค้ดเพจแบบเดิมกำหนดค่าไบต์ภายใต้ตารางภูมิภาค และการใช้ตารางที่ไม่ถูกต้องจะเปลี่ยนอักขระ สมุดงานขอรายละเอียด Windows-1252 แต่ ToolAcre ไม่มีตัวถอดรหัสหรือตารางการแมปที่เลือกได้ การกำหนดค่าเตือนว่า Windows-1252 และ Shift-JIS อ่านเป็น UTF-8 และแสดงอักขระแทนที่

ระบุแหล่งที่มาดั้งเดิมผ่านการตั้งค่าของผู้ผลิตหรือตัวตรวจสอบการเข้ารหัสที่ทำงานจากไบต์ที่ไม่ถูกแตะต้อง อย่าขอให้น้ำยาทำความสะอาดนี้อนุมานตารางจากชื่อ เมื่อ `File.text()` ส่งคืนสตริงที่เสียหาย parser จะไม่สามารถกู้คืนความแตกต่างของไบต์ที่การถอดรหัสทิ้งไป

รายละเอียดโค้ดเพจแบบเดิมเป็นหลักฐานจากพื้นที่เก็บข้อมูลภายนอก ToolAcre ไม่ได้ถอดรหัส

UTF-8 สามารถแสดงข้อความที่เกินจาก ASCII ที่ทับซ้อนกัน โดยปล่อยให้อักขระไวยากรณ์ทั่วไปเหล่านั้นไม่เปลี่ยนแปลง เบราว์เซอร์จะแปลงไบต์ที่เลือกเป็นสตริง JavaScript ก่อนที่ผู้ปฏิบัติงานจะแยกวิเคราะห์ ภายในสตริงนั้น ชื่อ Unicode และอิโมจิไปกลับผ่านตัวแยกวิเคราะห์และซีเรียลไลเซอร์ของ ToolAcre ตามที่การทดสอบแสดงให้เห็น

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

ToolAcre สาธิตการจัดการข้อความ UTF-8 ไม่ใช่รูปแบบการเข้ารหัส Unicode ที่สมบูรณ์

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

สำหรับผู้ปฏิบัติงาน การทำให้เป็นมาตรฐานหมายถึงการส่งออกหรือแปลงเป็น UTF-8 ก่อนที่จะโหลด ตรวจสอบค่าตัวแทนหลายภาษา จากนั้นทำให้ตารางที่ตรวจสอบแล้วเป็นอนุกรม สคริปต์รับควรคาดหวัง UTF-8 และตัดสินใจว่าจะยอมรับ BOM หรือไม่ ข้อตกลงทั้งสองฝ่ายมีความสำคัญมากกว่าคำแถลงทั่วไปเกี่ยวกับการผิดนัดชำระหนี้

พื้นที่เก็บข้อมูลกำหนดให้ UTF-8 เป็นสัญญาของเครื่องมือนี้ ไม่ใช่เหตุผลที่เว็บที่กว้างขึ้นเลือก

U+FEFF นำหน้าจะถูกลบออกก่อนการตรวจจับตัวคั่น และผลลัพธ์จะบันทึก `hadBom` เพื่อให้อินเทอร์เฟซสามารถรายงานได้ การส่งออกสามารถเติมเครื่องหมายเดียวกันไว้หน้าเมื่อผู้เยี่ยมชมเลือกตัวเลือก หากไม่มีตัวเลือกนั้น เอาต์พุตจะเริ่มต้นโดยตรงกับอักขระส่วนหัวตัวแรก

เครื่องหมายนี้สามารถช่วยให้เวิร์กโฟลว์สเปรดชีตบางรายการรู้จัก UTF-8 แต่การกำหนดค่าเตือนว่าสคริปต์ที่เข้มงวดหรือการนำเข้าฐานข้อมูลอาจแนบไปกับส่วนหัวแรก ใช้ตัวเลือกสำหรับผู้บริโภคที่รู้จัก ไม่ใช่ความสะอาดแบบสากล นโยบาย BOM เป็นส่วนหนึ่งของสัญญาอินเทอร์เฟซ

สิ่งนี้ไม่ครอบคลุม — UTF-16 การส่งออก การเข้ารหัสเอเชียตะวันออก และการทำให้อักขระที่แต่งขึ้นเป็นมาตรฐาน

UTF-16 การเข้ารหัสแบบดั้งเดิมของเอเชียตะวันออกและการปรับมาตรฐาน Unicode จะไม่ถูกนำมาใช้ที่นี่ ไม่มีการตรวจหาลำดับไบต์หรือการซ่อมแซมอักขระทดแทน การตั้งชื่อการละเว้นเหล่านั้นจะป้องกันไม่ให้ผู้ใช้ปฏิบัติต่อการดาวน์โหลดที่ประสบความสำเร็จเพื่อเป็นข้อพิสูจน์ว่าตัวละครดั้งเดิมทุกตัวรอดชีวิตได้

หากเกี่ยวข้องกับไบต์ที่ไม่สนับสนุน ให้คงต้นฉบับไว้และใช้ตัวถอดรหัสที่ออกแบบมาสำหรับแหล่งนั้น หลังจากการแปลงเป็น UTF-8 ที่ผ่านการตรวจสอบแล้ว ToolAcre สามารถจัดการโครงสร้าง CSV ที่ได้รับการบันทึกไว้ได้ การแยกการถอดรหัสอักขระออกจากการแยกวิเคราะห์แถวทำให้การวินิจฉัยความล้มเหลวง่ายขึ้น และหลีกเลี่ยงการคาดเดาแบบทำลายล้าง

ทำการส่งออกทุกครั้ง UTF-8 และพูดเช่นนั้น — วิธีที่ ToolAcre CSV การซ่อมแซมการเข้ารหัสของ Cleaner แปลงการส่งออกแบบเดิมเป็น UTF-8 ในเบราว์เซอร์ของคุณ

ทำให้ UTF-8 เป็นข้อกำหนดการแลกเปลี่ยนที่ชัดเจน และทดสอบกับคลาสอักขระจริงที่ใช้โดยชุดข้อมูล ToolAcre สามารถลบหรือเพิ่ม UTF-8 BOM นำหน้า เก็บสตริงเซลล์ Unicode ที่ถูกต้อง และทำให้ CSV quoting เป็นมาตรฐาน ไม่สามารถดำเนินการแปลงแบบเดิมที่สัญญาไว้ตามโครงร่างดั้งเดิมได้

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