Формулировка требования о кодировке имени файла

12

Я нахожусь в процессе написания спецификации требований, и у меня возникла дилемма в формулировке части требований.

Сценарий: мы загружаем файлы с веб-сайта, и загруженные файлы необходимо прикрепить к элементу в имеющемся у нас инструменте CM. Загруженные файлы содержат имена, которые могут быть ASCII, ISO-8859-1, японский и т. Д.

В приведенной ниже фразе «не ASCII» охватывает все ситуации?

Загруженное имя файла может содержать не-ASCII-символы, и его обработка не должна приводить к сбою приложения.

KK99
источник
С на веб - сайте, или из многих веб - сайтов? Этот веб-сайт действительно содержит файловую систему gobbledegook?
200_success
7
поэтому, если имя файла содержит ascii, приложение может аварийно завершить работу;)
jk.
11
Было бы педантично указать, что «японский» не кодировка?
Ixrec
@lxrec -> вы правы. Японский не кодировка. То, что я хотел сказать, было японскими иероглифами, но не печатал полностью. спасибо
KK99
@jk В некоторых реализациях, если имя файла не ASCII, происходит сбой приложения. правдивая история :-)
KK99

Ответы:

30

Требование, как указано, для меня нечетко.

Первый вопрос, который у меня возникнет: сколько кодировок необходимо поддерживать? Возможные интерпретации включают в себя:

  1. Все когда-либо разработанные кодировки, включая однобайтовые (например, ISO-8859-15 ), многобайтовые (например, Big5 , Shift-JIS , HZ ) и редкие / странные (например, UTF-7 , Punycode , EBCDIC ).
  2. Это явно экстрим. Как насчет минимальной поддержки, а именно ISO-8859-1?
  3. Просто ISO-8859-1 кажется ласковым. Как насчет поддержки современных лучших практик, а именно Unicode как UTF-8 ?

Если вы не укажете, какую кодировку вы имеете в виду, то при возникновении ошибки, связанной с кодировкой, вы и разработчик можете сразиться, и вы оба будете правы. Это, по определению, следствие нечеткой спецификации.

В дальнейшем, что программное обеспечение должно делать с именем файла, кроме того, чтобы не зависать? Если это ...

  1. Сохранить имя файла в исходной кодировке, byte-by-byte?
  2. Нормализовать все для Unicode? Если да, нужно ли автоматически определять кодировку источника? По какому механизму?
  3. Сохранить как форму 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 Веб-сервер, когда он обслуживает файл, может указывать кодировку. Если нет, то есть также эвристика анализа текста, которая может угадать кодировку.
200 удач
2
Помните, мы говорим о самом имени файла, а не о содержимом файла. Скорее всего, веб-сервер не может узнать кодировку имени файла, поэтому, если он утверждает, что имя файла находится в определенной кодировке, он, вероятно, лжет. Если вы попытаетесь конвертировать из UTF-8 в UTF-16, но ваше имя файла действительно ISO-8859-1, вы, скорее всего, получите сбой. Кроме того, см. Blogs.msdn.com/b/oldnewthing/archive/2007/04/17/2158334.aspx для примера того, насколько плоха эвристика для угадывания кодировок из образцов текста размером с имя файла.
Гейб
@Gabe Обратите внимание, что я предложил ISO-8859-1 по умолчанию. Есть причина для этого - она ​​избегает многих опасностей, которые вы упоминаете.
200_успех
Я боюсь, что UTF-8 будет недостаточно - по крайней мере, в некоторых версиях Windows (файловые системы FAT?) Вы получите имена файлов в локальных кодировках, отличных от Юникода, например, win-1252 или win-1257; браузер может конвертировать имена файлов в utf-8 при загрузке, но я сомневаюсь в этом.
Петерис
14

Написанное вами требование не имеет характеристик хорошего требования . В частности, это не связно, не атомарно и не однозначно. Из-за отсутствия этих характеристик это также нелегко проверить.

Ваше начальное требование к состоянию:

Загруженное имя файла может содержать не-ASCII-символы, и его обработка не должна приводить к сбою приложения.

Я бы порекомендовал удалить «... и обработка этого не приведет к сбою приложения». Если у вас есть требование, чтобы какое-то программное обеспечение должно было что-то делать, я думаю, можно предположить, что оно должно делать это без сбоя программного обеспечения.

Это преобразует требование в:

Имя загруженного файла может содержать символы не ASCII

Теперь у вас есть связное и атомарное требование. Однако я не уверен, что это однозначно. В своем вопросе вы упоминаете ряд различных форматов. Есть несколько вариантов.

Некоторые рекомендуют отдельное и уникальное требование для каждой кодировки имени файла, которая должна поддерживаться. Это наилучшим образом соответствует связным, атомарным, прослеживаемым, однозначным и проверяемым требованиям. Это также облегчило бы определение важности каждого требования - возможно, поддержка некоторых кодировок более важна или необходима раньше.

Другие могут рекомендовать таблицу поддерживаемых форматов, и это требование будет ссылаться на таблицу. Он будет менее полным (у вас есть текстовое предложение и таблица, которую нужно сохранить), но они будут в одном документе или базе данных. Однако, если вы собираетесь выполнить связывание в инструменте управления требованиями, их можно связать вместе, чтобы изменения в одном из них выдвинули на первый план связанное требование. Это также позволило бы передавать текст другим пакетам программного обеспечения, как есть, но с другой таблицей для разных кодировок.

Однако то, как вы документируете требования, зависит от ваших конкретных потребностей.

Томас Оуэнс
источник
4

Есть несколько проблем с вашей формулировкой, которые ослабляют требование:

1) Вы должны выразить требование в положительном выражении, а не в терминах того, что оно не должно делать . Как сделать один тест на «не сбой».

2) Фраза «Имя загруженного файла может содержать ...» расплывчата.

Предлагаемая альтернативная формулировка (сугубо субъективная, конечно) может быть:

Приложение должно поддерживать загруженные имена файлов, содержащие не-ASCII символы.

(Слово «поддержка» все еще немного расплывчато и может быть изменено, чтобы быть более конкретным, если принимать его вместе с другими требованиями для вашего приложения.)

Кент А.
источник
1
Самокомментация: не-ASCII также не лучшая формулировка, поскольку не-ASCII может означать любую другую кодировку. Лучшим требованием был бы список разрешенных кодировок, что сделало бы результирующие тестовые примеры более точными для определения того, что программное обеспечение работает как задумано. В противном случае тестирование одной не-ASCII-кодировки может удовлетворить требование, но может не полностью протестировать программное обеспечение.
Кент А.
2
Было бы лучше указать «приложение должно поддерживать загруженные имена файлов, содержащие символы Unicode» и, возможно, указать конкретную кодировку, которая должна поддерживаться, например, UTF-8.
1

Проблема со спецификацией в том виде, в котором она написана, в том, что она не говорит, что приложение должно делать с «интересными» именами файлов. Я столкнулся с одной программой, которая заменила бы любые символы имени файла, которые он не понимал _, с тем эффектом, что когда его попросили скопировать каталог, который содержал два символа, имена которых были идентичны, за исключением символов, которые утилита не понимала, второй файл записанный в каталог перезаписал бы первый. Такое поведение будет квалифицироваться как «не сбой», но это не должно означать, что это допустимо при отсутствии явной спецификации, в которой говорится об этом.

Я хотел бы предложить, чтобы в хорошей спецификации было указано, что должно произойти, или отметьте, какие действия допустимы, например: «Если имя файла содержит нераспознанные символы, система должна сгенерировать новый GUID для всей операции и сгенерировать имя файла который объединяет этот GUID, порядковый номер и любую часть исходного имени файла, которую можно легко разместить; он должен создать таблицу, отображающую старые и новые имена файлов »или« Если имя файла содержит нераспознанные символы, система может сформировать новый имя путем объединения символов, которые он распознает; если в результате такого преобразования два имени файла оказываются идентичными, любое из них может быть произвольно объявлено «победителем» ».

Supercat
источник