ファイル名のエンコーディングに関する要件の表現
私は要件の仕様を作成中であり、要件の一部を表現する際にジレンマがあります。
シナリオ：Webサイトからファイルをダウンロードし、ダウンロードしたファイルを、CMツールのアイテムに添付する必要があります。ダウンロードしたファイルには、ASCII、ISO-8859-1、日本語などの名前が含まれています。
以下の言い回しでは、「非ASCII」はすべての状況をカバーしますか？
ダウンロードしたファイル名には非ASCII文字が含まれている可能性があり、これを処理してもアプリケーションはクラッシュしません。
述べたように、要件は私にはあいまいです。
最初の質問は、サポートする必要のある文字エンコーディングはいくつですか？可能な解釈は次のとおりです。
- これまでに考案されたすべてのエンコーディング、シングルバイト（例 ISO-8859-15 ）、マルチバイト（例 Big5 、 Shift-JIS 、 [〜＃〜] hz [〜＃〜] ）、レア/奇妙なもの（例 TF-7 、 Punycode 、 [〜＃〜] ebcdic [〜＃〜] ）。
- それは明らかに極端です。 最小限のサポート、、つまりISO-8859-1はどうですか？
- ISO-8859-1だけではおかしなようです。 最新のベストプラクティス、つまりUnicode TF-8 をサポートするだけではどうですか？
どのエンコーディングを指定するのかを指定しない場合、エンコーディング固有のバグが発生すると、あなたと実装者が戦いを起こす可能性があり、どちらも正しいでしょう。これは、定義上、ファジー仕様の結果です。
さらに進んで、クラッシュしないこと以外に、ソフトウェアはファイル名をどのように処理する必要がありますか？それは…
- ファイル名を元のエンコードでバイト単位で保持しますか？
- すべてをUnicodeに正規化しますか？もしそうなら、それはソースエンコーディングを自動検出する必要がありますか？どのようなメカニズムで？
- 正規化が失敗した場合に備えて、Unicode形式と元の形式の両方を保存しますか？
あなたの要件のより良いバージョンは
ダウンローダーは、少なくともASCII、ISO-8859-1、ISO-8859-15、KOI8-R、UTF-8、Shift-JIS、EUC-JP、GB2312、Big5など、さまざまなエンコーディングのファイル名をサポートする必要があります。 Webサーバーの応答でエンコードが指定されている場合は、それを尊重する必要があります。 （エンコードが指定されていない場合は、ISO-8859-1と見なされるか、より適切な推測が行われる場合があります。）ファイル名は、コンテンツ管理システムでUnicode表現に正規化されます。
必要なエンコーディングの具体例は、受け入れ基準を考案するために不可欠です。追加された文は、クラッシュしないことを超えて、ソフトウェアが何をする必要があるかを述べています。
あなたが書いた要件には 良い要件の特徴 がありません。具体的には、それはまとまりがなく、アトミックではなく、あいまいさもありません。これらの特性がないため、簡単に検証することもできません。
初期状態の要件は次のとおりです。
ダウンロードしたファイル名には非ASCII文字が含まれている可能性があり、これを処理してもアプリケーションはクラッシュしません。
「これを処理してもアプリケーションがクラッシュすることはありません」を削除することをお勧めします。ソフトウェアの一部が何かを実行する必要があるという要件がある場合、ソフトウェアをクラッシュさせることなく実行する必要があると想定しても問題ないと思います。
これにより、要件が次のように変わります。
ダウンロードしたファイル名に非ASCII文字が含まれている可能性があります
さて、あなたはまとまりのあるアトミックな要件を持っています。ただし、それが明確であるかどうかはわかりません。あなたの質問では、さまざまな形式について言及しています。いくつかのオプションがあります。
サポートする必要のあるファイル名のエンコーディングごとに、個別の固有の要件を推奨する人もいます。これは、まとまりのある、アトミックで、追跡可能で、明確で、検証可能な要件をサポートするのに最適です。また、各要件の重要性を簡単に指定できるようになります。おそらく、一部のエンコーディングのサポートがより重要であるか、より早く必要になるでしょう。
サポートされている形式の表を推奨する人もいますが、この要件は表にリンクしています。完全性は劣りますが（テキスト文と維持する表がある）、それらは同じドキュメントまたはデータベースにあります。ただし、要件管理ツールでリンクを実行する場合は、それらを一緒にリンクして、1つを変更するとリンクされた要件が強調表示されるようにすることができます。また、テキストを他のソフトウェアパッケージにそのまま流すこともできますが、エンコーディングごとに異なるテーブルが使用されます。
ただし、要件を文書化する方法は、特定のニーズによって異なります。
あなたの文言には要件を弱めるいくつかの問題があります：
1）要件をしないではなく、ポジティブの条件で表現する必要があります。どのようにして「クラッシュしない」かをテストします。
2）「ダウンロードしたファイル名may含む...」という句は曖昧です。
推奨される代替の表現（もちろん、主観的なものです）は次のようになります。
アプリケーションは、非ASCII文字を含むダウンロードされたファイル名をサポートします。
（「サポート」という言葉はまだ少しあいまいであり、アプリケーションの他の要件と合わせて解釈すると、より具体的になるように変更できます。）
記述された仕様の問題は、アプリケーションが「興味深い」ファイル名をどう処理するべきかを述べていないことです。理解できないファイル名の文字を_に置き換えるプログラムが1つありました。その結果、ユーティリティに含まれていない文字以外は名前が同じである2つの文字を含むディレクトリをコピーするように求められた場合、理解すると、ディレクトリに書き込まれた2番目のファイルは最初のファイルを上書きします。このような動作は「クラッシュしない」と見なされますが、明示的な仕様がない限り、それが許容できることを意味するものではありません。
良い仕様では、何をすべきかを明確に指定するか、またはどのような行動方針が受け入れられるかを記録することをお勧めします。 「ファイル名に認識できない文字が含まれている場合、システムは操作全体に対して新しいGUIDを生成し、そのGUID、インデックス番号、および元のファイル名の任意の部分を組み合わせたファイル名を生成する必要があります。これは、容易に対応できます。これにより、古いファイル名と新しいファイル名をマッピングするテーブルが生成されます。そのような変革を通じて、どちらかが勝者と勝手に宣言されるかもしれません。