Menyusun persyaratan tentang pengodean nama file

Saya sedang dalam proses menulis spesifikasi persyaratan, dan saya memiliki dilema dalam menyusun sepotong persyaratan.

Skenario: Kami mengunduh file dari situs web dan file yang diunduh harus dilampirkan ke item di alat CM yang kami miliki. File yang diunduh berisi nama yang bisa ASCII, ISO-8859-1, Jepang, dll.

Dalam ungkapan di bawah, apakah "non-ASCII" mencakup semua situasi?

Nama file yang diunduh mungkin mengandung karakter non-ASCII dan pemrosesan ini tidak akan membuat aplikasi mogok

Persyaratan, seperti yang disebutkan, tidak jelas bagi saya.

Pertanyaan pertama yang saya miliki adalah: berapa banyak penyandian karakter yang perlu didukung? Kemungkinan interpretasi meliputi:

1. Setiap encoding yang pernah dibuat, termasuk byte tunggal (misalnya ISO-8859-15 ), multibyte (misalnya Big5 , Shift-JIS , HZ ), dan yang langka / aneh (misalnya UTF-7 , Punycode , EBCDIC ).
2. Itu jelas ekstrem. Bagaimana dengan dukungan minimum saja, yaitu ISO-8859-1?
3. Hanya ISO-8859-1 sepertinya tidak sopan. Bagaimana kalau hanya mendukung praktik terbaik modern, yaitu Unicode sebagai UTF-8 ?

Jika Anda tidak menentukan penyandian yang Anda maksud, maka ketika bug khusus penyandian terjadi, Anda dan implementor bisa bertengkar dan Anda berdua akan benar. Artinya, menurut definisi, konsekuensi dari spec fuzzy.

Lebih jauh, apa yang perlu dilakukan perangkat lunak dengan nama file, selain tidak crash? Haruskah itu ...

4. Pertahankan nama file dalam penyandian aslinya, byte-for-byte?
5. Normalisasikan semuanya ke Unicode? Jika demikian, apakah perlu mendeteksi sumber pengkodean secara otomatis? Dengan mekanisme apa?
6. Simpan bentuk Unicode dan yang asli, kalau-kalau normalisasi gagal?

Versi yang lebih baik dari kebutuhan Anda adalah

Pengunduh harus mendukung nama file dalam berbagai penyandian, termasuk setidaknya ASCII, ISO-8859-1, ISO-8859-15, KOI8-R, UTF-8, Shift-JIS, EUC-JP, GB2312, dan Big5. Jika respons server web menentukan suatu pengkodean, itu harus dihormati. (Jika pengkodean tidak ditentukan, ISO-8859-1 dapat diasumsikan, atau tebakan yang lebih baik dapat dibuat.) Nama file harus dinormalisasi menjadi representasi Unicode dalam sistem manajemen konten.

Contoh spesifik pengkodean yang diperlukan sangat penting untuk merancang kriteria penerimaan. Kalimat yang ditambahkan menyatakan apa yang perlu dilakukan perangkat lunak, di luar tidak macet.

Persyaratan yang Anda tulis tidak memiliki karakteristik persyaratan yang baik . Secara khusus, itu tidak kohesif, itu bukan atom, dan itu tidak ambigu. Karena kurangnya karakteristik ini, itu juga tidak mudah diverifikasi.

Persyaratan awal Anda adalah:

Nama file yang diunduh mungkin mengandung karakter non-ASCII dan pemrosesan ini tidak akan membuat aplikasi mogok

Saya akan merekomendasikan menghapus "... dan pemrosesan ini tidak akan merusak aplikasi". Jika Anda memiliki persyaratan bahwa perangkat lunak perlu melakukan sesuatu, saya pikir tidak apa-apa untuk membuat asumsi bahwa itu harus dilakukan tanpa menabrak perangkat lunak.

Ini mengubah persyaratan menjadi:

Nama file yang diunduh mungkin berisi karakter non-ASCII

Sekarang, Anda memiliki persyaratan kohesif dan atom. Namun, saya tidak yakin itu tidak ambigu. Dalam pertanyaan Anda, Anda menyebutkan sejumlah format berbeda. Ada beberapa opsi.

Beberapa akan merekomendasikan persyaratan terpisah dan unik untuk setiap pengkodean nama file yang harus didukung. Ini akan lebih baik mendukung persyaratan kohesif, atomik, dapat dilacak, tidak ambigu, dan dapat diverifikasi. Ini juga akan membuatnya lebih mudah untuk menentukan pentingnya setiap persyaratan - mungkin dukungan untuk beberapa pengkodean lebih penting atau dibutuhkan lebih cepat.

Orang lain mungkin merekomendasikan tabel format yang didukung dan persyaratan ini akan ditautkan ke tabel. Itu akan kurang lengkap (Anda memiliki kalimat tekstual dan tabel untuk dipelihara), tetapi mereka akan berada di dokumen atau database yang sama. Namun, jika Anda akan melakukan penautan di alat manajemen persyaratan, mereka dapat dihubungkan bersama sehingga perubahan satu akan menyoroti persyaratan tertaut. Ini juga akan memungkinkan teks mengalir ke paket perangkat lunak lain apa adanya, tetapi dengan tabel berbeda untuk pengkodean yang berbeda.

Namun, bagaimana Anda mendokumentasikan persyaratan tergantung pada kebutuhan spesifik Anda.

Ada beberapa masalah dengan kata-kata Anda yang melemahkan persyaratan:

1) Anda harus mengungkapkan persyaratan dalam hal positif , bukan dalam hal apa yang seharusnya tidak dilakukan . Bagaimana satu tes untuk "tidak menabrak".

2) Ungkapan "Nama file yang diunduh mungkin berisi ..." tidak jelas.

Alternatif susunan kata yang disarankan (murni subjektif, tentu saja) mungkin:

Aplikasi harus mendukung nama file yang diunduh yang mengandung karakter non-ASCII.

(Kata "dukungan" masih sedikit kabur dan dapat diubah menjadi lebih konkret saat digunakan bersamaan dengan persyaratan lain untuk aplikasi Anda.)

Masalah dengan spesifikasi seperti yang tertulis adalah bahwa ia tidak mengatakan apa yang harus dilakukan aplikasi dengan nama file "menarik". Saya telah menjumpai satu program yang akan menggantikan karakter nama file yang tidak dimengerti _, dengan efek ketika diminta untuk menyalin direktori yang berisi dua karakter yang namanya identik kecuali dalam karakter utilitas tidak mengerti, file kedua ditulis ke direktori akan menimpa yang pertama. Perilaku seperti itu akan memenuhi syarat sebagai "tidak menabrak", tetapi itu tidak berarti bahwa itu tidak dapat diterima karena ada spesifikasi eksplisit yang mengatakannya.

Saya akan menyarankan bahwa spec yang baik harus secara tegas menentukan apa yang harus terjadi, atau perhatikan tindakan apa yang dapat diterima, misalnya "Jika nama file berisi karakter yang tidak dikenal, sistem harus menghasilkan GUID baru untuk keseluruhan operasi, dan menghasilkan nama file yang menggabungkan GUID itu, nomor indeks, dan setiap bagian dari nama file asli yang dapat dengan mudah ditampung; itu harus menghasilkan tabel pemetaan nama file lama dan baru "atau" Jika nama file berisi karakter yang tidak dikenal, sistem dapat membentuk yang baru nama dengan menggabungkan karakter yang dikenali; jika dua nama file akhirnya menjadi identik melalui transformasi tersebut, salah satu dari mereka dapat secara sewenang-wenang dinyatakan sebagai 'pemenang' ".