提出有关文件名编码的要求

我正在编写需求规范，而在措辞部分需求方面存在两难选择。

场景：我们从网站下载文件，并且下载的文件需要附加到我们拥有的CM工具中的项目中。下载的文件包含的名称可以是ASCII，ISO-8859-1，日语等。

在下面的措词中，“非ASCII”是否涵盖所有情况？

下载的文件名可能包含非ASCII字符，对此文件的处理不会使应用程序崩溃

如上所述，这个要求对我来说是模糊的。

我要问的第一个问题是：需要支持多少个字符编码？可能的解释包括：

1. 曾经设计过的每种编码，包括单字节（例如ISO-8859-15），多字节（例如Big5，Shift-JIS，HZ）和稀有/奇怪的编码（例如UTF-7，Punycode，EBCDIC）。
2. 那显然是极端的。怎么样只是最低支持，即ISO-8859-1？
3. 只是ISO-8859-1显得有些狡猾。如何只支持现代的最佳做法，即统一为UTF-8 ？

如果您没有指定要使用的编码，那么当发生特定于编码的错误时，您和实现者可能会吵架，而且都对。也就是说，根据定义，模糊规范的结果。

更进一步，除了不崩溃，软件还需要处理文件名吗？应该是…

4. 保留文件名的原始编码，逐字节？
5. 将所有内容标准化为Unicode？如果是这样，是否需要自动检测源编码？通过什么机制？
6. 同时存储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）您应该以积极的态度来表达需求，而不是以不应该做的事情来表达。如何测试“不崩溃”。

2）短语“下载的文件名可能包含...”含糊不清。

建议的替代措词（当然，完全是主观的）可能是：

该应用程序应支持包含非ASCII字符的下载文件名。

（“支持”一词仍含糊不清，在与您的应用程序的其他要求结合使用时可以更改为更具体。）

规范编写的问题在于，它没有说明应用程序应使用“有趣的”文件名做什么。我遇到过一个程序，它将用不明白的文件名字符替换掉_，结果是当要求复制包含两个名称相同的字符的目录时，该实用程序不理解的字符除外，第二个文件写入目录将覆盖第一个。这样的行为将被视为“不崩溃”，但是这并不意味着如果没有明确的说明就是可以接受的。

我建议，一个好的规范应该肯定地说明应该发生什么，或者指出可以采取的措施，例如：“如果文件名包含无法识别的字符，则系统应为整个操作生成一个新的GUID，并生成一个文件名。它结合了GUID，索引号和可以容易容纳的原始文件名的任何部分；它应该产生一个映射新旧文件名的表”或“如果文件名包含无法识别的字符，则系统可能会形成一个新的通过连接识别的字符来命名；如果两个文件名最终通过这种转换而变得相同，则可以任意地将其中一个声明为“优胜者””。