ข้อกำหนดของวลีเกี่ยวกับการเข้ารหัสชื่อไฟล์

12

ฉันอยู่ในขั้นตอนการเขียนข้อกำหนดเฉพาะและฉันมีปัญหาในการใช้ถ้อยคำเป็นส่วนหนึ่งของข้อกำหนด

สถานการณ์จำลอง: เราดาวน์โหลดไฟล์จากเว็บไซต์และไฟล์ที่ดาวน์โหลดต้องแนบกับรายการในเครื่องมือ CM ที่เรามี ไฟล์ที่ดาวน์โหลดมีชื่อซึ่งสามารถเป็น ASCII, ISO-8859-1, ญี่ปุ่นและอื่น ๆ

ในถ้อยคำด้านล่าง "non-ASCII" ครอบคลุมทุกสถานการณ์หรือไม่?

ชื่อไฟล์ที่ดาวน์โหลดอาจมีอักขระที่ไม่ใช่ ASCII และการประมวลผลจะไม่ทำให้แอปพลิเคชันเสียหาย

requirements requirements-management

— KK99
แหล่งที่มา

จากเว็บไซต์หรือจากหลายเว็บไซต์? เว็บไซต์นั้นมีระบบไฟล์ gobbledegook หรือไม่?

— 200_success

7

ดังนั้นหากชื่อไฟล์มี ascii แอปพลิเคชันได้รับอนุญาตให้ผิดพลาด;)

— jk

11

มันจะเป็นการหยิ่งยะโสที่จะชี้ให้เห็นว่า "ญี่ปุ่น" ไม่ใช่การเข้ารหัสหรือไม่?

— Ixrec

@lxrec -> คุณถูกต้อง ภาษาญี่ปุ่นไม่ใช่การเข้ารหัส สิ่งที่ฉันอยากจะบอกก็คือตัวละครญี่ปุ่น แต่ไม่ได้พิมพ์ผ่านอย่างสมบูรณ์ ขอบคุณ

— KK99

@jk ในการใช้งานบางอย่างหากชื่อไฟล์ไม่ใช่ ASCII แอปพลิเคชันขัดข้อง เรื่องจริง :-)

— KK99

30

ข้อกำหนดตามที่ระบุไว้นั้นคลุมเครือสำหรับฉัน

คำถามแรกที่ฉันจะมีคือต้องรองรับการเข้ารหัสอักขระจำนวนเท่าใด การตีความที่เป็นไปได้รวมถึง:

การเข้ารหัสทุกครั้งที่คิดค้นรวมถึงไบต์เดียว (เช่นISO-8859-15 ), หลายไบต์ (เช่นBig5 , Shift-JIS , HZ ) และหายาก / แปลก (เช่นUTF-7 , Punycode , EBCDIC )
เห็นได้ชัดว่าสุดขั้ว การสนับสนุนขั้นต่ำเพียงอย่างเดียวคือ ISO-8859-1
แค่ ISO-8859-1 ดูเหมือนว่าจะดี วิธีการเกี่ยวกับเพียงการสนับสนุนการปฏิบัติที่ดีที่สุดทันสมัยคือ Unicode เป็นUTF-8 ?

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

หากดำเนินการต่อไปซอฟต์แวร์ต้องทำอะไรกับชื่อไฟล์นอกเหนือจากการไม่ทำงานล้มเหลว? ควรเป็น…

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

ความต้องการของคุณจะดีกว่า

ตัวดาวน์โหลดต้องรองรับชื่อไฟล์ในการเข้ารหัสต่าง ๆ รวมถึงอย่างน้อย ASCII, ISO-8859-1, ISO-8859-15, KOI8-R, UTF-8, Shift-JIS, EUC-JP, GB2312 และ Big5 หากการตอบสนองของเว็บเซิร์ฟเวอร์ระบุการเข้ารหัสจะต้องได้รับการเคารพ (หากการเข้ารหัสนั้นไม่ได้ระบุไว้อาจสันนิษฐาน ISO-8859-1 หรืออาจจะทำการเดาได้ดีกว่า) ชื่อไฟล์จะถูกทำให้เป็นมาตรฐานในการแสดง Unicode ในระบบการจัดการเนื้อหา

ตัวอย่างเฉพาะของการเข้ารหัสที่จำเป็นมีความจำเป็นสำหรับการกำหนดเกณฑ์การยอมรับ ประโยคเพิ่มเติมระบุถึงสิ่งที่ซอฟต์แวร์ต้องทำ

— 200_success
แหล่งที่มา

ในขณะที่ระบบไฟล์ NTFS เก็บชื่อไฟล์ใน Unicode แต่ระบบไฟล์อื่น ๆ ส่วนใหญ่เก็บชื่อไฟล์เป็นสตรีมไบต์โดยไม่มีการเข้ารหัสที่ระบุ ในกรณีนั้นคุณจะรู้ได้อย่างไรว่าการเข้ารหัสจะเดาได้อย่างไร

— Gabe

@Gabe เว็บเซิร์ฟเวอร์เมื่อให้บริการไฟล์อาจบ่งบอกถึงการเข้ารหัส ถ้าไม่มีก็ยังมีฮิวริสติกวิเคราะห์ข้อความที่สามารถเดารหัสได้

— 200_success

2

จำไว้ว่าเรากำลังพูดถึงชื่อไฟล์เองไม่ใช่เนื้อหาของไฟล์ Odds คือเว็บเซิร์ฟเวอร์ไม่มีทางรู้การเข้ารหัสของชื่อไฟล์ดังนั้นถ้ามันอ้างว่าชื่อไฟล์นั้นอยู่ในการเข้ารหัสแน่นอนมันอาจจะโกหก หากคุณพยายามแปลงจาก UTF-8 เป็น UTF-16 แต่ชื่อไฟล์ของคุณคือ ISO-8859-1 จริง ๆ คุณมีโอกาสที่จะเกิดข้อผิดพลาด นอกจากนี้โปรดดูblogs.msdn.com/b/oldnewthing/archive/2007/04/17/2158334.aspxสำหรับตัวอย่างของวิธีการวิเคราะห์พฤติกรรมที่ไม่ดีสำหรับการเดาการเข้ารหัสจากตัวอย่างขนาดของชื่อไฟล์ของข้อความ

— Gabe

@Gabe โปรดทราบว่าฉันแนะนำ ISO-8859-1 เป็นค่าเริ่มต้น มีเหตุผลสำหรับสิ่งนั้น - มันหลีกเลี่ยงอันตรายมากมายที่คุณพูดถึง

— 200_success

ฉันกลัวว่า UTF-8 จะไม่เพียงพอ - อย่างน้อยจาก windows บางรุ่น (ระบบไฟล์ FAT?) คุณจะได้รับชื่อไฟล์ในการเข้ารหัสโลคอล non-unicode เช่น win-1252 หรือ win-1257; เบราว์เซอร์อาจแปลงชื่อไฟล์เป็น utf-8 เมื่ออัปโหลด แต่ฉันสงสัย

— Peteris

14

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

ข้อกำหนดสถานะเริ่มต้นของคุณคือ:

ชื่อไฟล์ที่ดาวน์โหลดอาจมีอักขระที่ไม่ใช่ ASCII และการประมวลผลจะไม่ทำให้แอปพลิเคชันเสียหาย

ฉันขอแนะนำให้ลบ "... และการประมวลผลนี้จะไม่ทำให้แอปพลิเคชันเสียหาย" หากคุณมีความต้องการที่ชิ้นส่วนของซอฟต์แวร์ต้องทำบางสิ่งบางอย่างฉันคิดว่ามันโอเคที่จะทำให้สมมติฐานที่ว่ามันควรจะทำโดยไม่ต้องชนซอฟต์แวร์

สิ่งนี้จะแปลงความต้องการเป็น:

ชื่อไฟล์ที่ดาวน์โหลดอาจมีอักขระที่ไม่ใช่ ASCII

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

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

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

แม้ว่าคุณจะจัดทำเอกสารข้อกำหนดอย่างไรนั้นขึ้นอยู่กับความต้องการเฉพาะของคุณ

— โทมัสโอเวนส์
แหล่งที่มา

4

มีปัญหาบางอย่างเกี่ยวกับข้อความของคุณที่ทำให้ความต้องการลดลง:

1) คุณควรแสดงความต้องการในเชิงบวกแง่มากกว่าในแง่ของสิ่งที่มันควรจะได้ทำ หนึ่งการทดสอบสำหรับ "ไม่ล้มเหลว" ได้อย่างไร

2) วลี "ชื่อไฟล์ที่ดาวน์โหลดอาจมี ... " คลุมเครือ

ถ้อยคำทางเลือกที่แนะนำ (แน่นอนว่าเป็นเรื่องส่วนตัว) อาจจะเป็น:

แอปพลิเคชันจะต้องสนับสนุนชื่อไฟล์ที่ดาวน์โหลดที่มีอักขระที่ไม่ใช่ ASCII

(คำว่า "การสนับสนุน" ยังคงคลุมเครือเล็กน้อยและสามารถเปลี่ยนให้เป็นรูปธรรมมากขึ้นเมื่อแสดงพร้อมกับข้อกำหนดอื่น ๆ สำหรับการสมัครของคุณ)

— เคนต์เอ
แหล่งที่มา

1

ความคิดเห็นด้วยตนเอง: ไม่ใช่ ASCIIไม่ใช่ข้อความที่ดีที่สุดเนื่องจากไม่ใช่ ASCII อาจหมายถึงการเข้ารหัสอื่น ๆ ข้อกำหนดที่ดีกว่านี้จะแสดงรายการการเข้ารหัสที่ได้รับอนุญาตซึ่งจะทำให้กรณีทดสอบที่เกิดขึ้นสามารถระบุได้ว่าซอฟต์แวร์ทำงานได้ตามที่ต้องการ มิฉะนั้นการทดสอบการเข้ารหัสที่ไม่ใช่แบบ ASCII สามารถตอบสนองความต้องการได้ แต่อาจไม่สามารถทดสอบซอฟต์แวร์ได้อย่างสมบูรณ์

— Kent A.

2

จะเป็นการดีกว่าหากระบุ "แอปพลิเคชันจะสนับสนุนชื่อไฟล์ที่ดาวน์โหลดที่มีอักขระ Unicode" และอาจระบุการเข้ารหัสเฉพาะที่ต้องรองรับเช่น UTF-8

1

ปัญหาของข้อมูลจำเพาะตามที่เขียนคือไม่ได้บอกว่าแอปพลิเคชันควรทำอย่างไรกับชื่อไฟล์ "น่าสนใจ" ฉันพบโปรแกรมหนึ่งซึ่งจะแทนที่อักขระชื่อไฟล์ที่ไม่เข้าใจด้วย_ผลกระทบที่เมื่อถูกขอให้คัดลอกไดเรกทอรีซึ่งมีอักขระสองตัวที่ชื่อเหมือนกันยกเว้นในตัวอักษรที่ยูทิลิตี้ไม่เข้าใจไฟล์ที่สอง เขียนไปยังไดเรกทอรีจะเขียนทับแรก พฤติกรรมดังกล่าวจะถือว่าเป็น "ไม่ล้มเหลว" แต่นั่นไม่ควรหมายความว่าเป็นที่ยอมรับได้หากไม่มีสเป็กที่ชัดเจนว่าเป็นเช่นนั้น

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

— SuperCat
แหล่งที่มา