Formulando um requisito sobre codificações de nome de arquivo

12

Estou no processo de escrever uma especificação de requisitos e tenho um dilema em formular uma parte dos requisitos.

Cenário: baixamos arquivos de um site e os arquivos baixados precisam ser anexados a um item na ferramenta CM que temos. Os arquivos baixados contêm nomes que podem ser ASCII, ISO-8859-1, japonês, etc.

No fraseado abaixo, "non-ASCII" abrange todas as situações?

O nome do arquivo baixado pode conter caracteres não ASCII e o processamento disso não deve travar o aplicativo

requirements requirements-management

— KK99
fonte

De um site ou de muitos sites? Esse site realmente contém um sistema de arquivos gobbledegook?

— 200_success

7

portanto, se o nome do arquivo contiver ascii, o aplicativo poderá travar;)

— jk.

11

Seria pedante salientar que "japonês" não é uma codificação?

— Ixrec

@lxrec -> você está correto. Japonês não é uma codificação. O que eu queria dizer era caracteres japoneses, mas não digitava completamente. obrigada

— KK99

@jk Em algumas implementações, se o nome do arquivo não for ASCII, o aplicativo trava. história verdadeira :-)

— KK99 5/15

30

O requisito, como afirmado, é confuso para mim.

A primeira pergunta que eu teria é: quantas codificações de caracteres precisam ser suportadas? As possíveis interpretações incluem:

Toda codificação já criada, incluindo byte único (por exemplo, ISO-8859-15 ), multibyte (por exemplo , Big5 , Shift-JIS , HZ ) e raros / estranhos (por exemplo, UTF-7 , Punycode , EBCDIC ).
Isso é obviamente extremo. Que tal apenas o suporte mínimo, ou seja , a ISO-8859-1?
Apenas a ISO-8859-1 parece mal-humorada. Que tal apenas apoiar as melhores práticas modernas, como Unicode como UTF-8 ?

Se você não especificar quais codificações você quer dizer, quando ocorrer um erro específico da codificação, você e o implementador poderão brigar e os dois estarão certos. Essa é, por definição, a consequência de uma especificação nebulosa.

Indo além, o que o software precisa fazer com o nome do arquivo, além de não travar? Deveria…

Preservar o nome do arquivo em sua codificação original, byte por byte?
Normalizar tudo para Unicode? Nesse caso, ele precisa detectar automaticamente a codificação de origem? Por qual mecanismo?
Armazene o formulário Unicode e o original, caso a normalização falhe?

Uma versão melhor de sua exigência seria

O downloader deve suportar nomes de arquivos em várias codificações, incluindo pelo menos ASCII, ISO-8859-1, ISO-8859-15, KOI8-R, UTF-8, Shift-JIS, EUC-JP, GB2312 e Big5. Se a resposta do servidor da web especificar uma codificação, ela deverá ser respeitada. (Se a codificação não for especificada, a ISO-8859-1 poderá ser assumida ou uma hipótese melhor.) Os nomes de arquivos devem ser normalizados para uma representação Unicode no sistema de gerenciamento de conteúdo.

Os exemplos específicos de codificações necessárias são essenciais para a elaboração de critérios de aceitação. As frases adicionadas indicam o que o software precisa fazer, além de não travar.

— 200_success
fonte

Enquanto o NTFS armazena nomes de arquivos em Unicode, a maioria dos outros sistemas de arquivos armazena nomes de arquivos como fluxos de bytes sem nenhuma codificação especificada. Nesse caso, como você saberia qual codificação adivinhar?

— Gabe

@Gabe O servidor da web, quando veicular o arquivo, pode indicar a codificação. Caso contrário, também existem heurísticas de análise de texto que podem adivinhar uma codificação.

— 200

2

Lembre-se, estamos falando do nome do arquivo em si, não do conteúdo do arquivo. As probabilidades são de que o servidor da Web não tenha como saber a codificação do nome do arquivo; portanto, se ele afirma que o nome do arquivo está em uma determinada codificação, provavelmente está mentindo. Se você tentar converter de UTF-8 para UTF-16, mas o nome do seu arquivo for realmente ISO-8859-1, é provável que ocorra um acidente. Além disso, consulte blogs.msdn.com/b/oldnewthing/archive/2007/04/17/2158334.aspx para obter um exemplo de como as heurísticas são ruins para adivinhar codificações de amostras de texto com tamanho de arquivo.

— Gabe

@ Gabriel Observe que eu sugeri a ISO-8859-1 como padrão. Há uma razão para isso - evita muitos dos perigos que você menciona.

— 200

Receio que UTF-8 não seja suficiente - pelo menos em algumas versões do Windows (sistemas de arquivos FAT?), Você obterá nomes de arquivos nas codificações locais não unicode - por exemplo, win-1252 ou win-1257; o navegador pode converter os nomes de arquivos em utf-8 durante o upload, mas duvido.

— Peteris

14

O requisito que você escreveu não possui as características de um bom requisito . Especificamente, não é coeso, não é atômico e não é ambíguo. Devido à falta dessas características, também não é facilmente verificável.

Seu requisito inicial de estado é:

O nome do arquivo baixado pode conter caracteres não ASCII e o processamento disso não deve travar o aplicativo

Eu recomendaria remover o "... e o processamento disso não deve travar o aplicativo". Se você tem a exigência de que um software precise fazer alguma coisa, acho que não há problema em assumir que ele deve ser feito sem travar o software.

Isso transforma o requisito em:

O nome do arquivo baixado pode conter caracteres não ASCII

Agora, você tem um requisito coeso e atômico. No entanto, não tenho certeza de que seja inequívoco. Na sua pergunta, você menciona vários formatos diferentes. Existem algumas opções.

Alguns recomendariam um requisito separado e exclusivo para cada codificação de nome de arquivo que deve ser suportada. Isso melhor suportaria requisitos coesos, atômicos, rastreáveis, inequívocos e verificáveis. Também facilitaria a especificação da importância de cada requisito - talvez o suporte para algumas codificações seja mais importante ou necessário mais cedo.

Outros podem recomendar uma tabela de formatos suportados e esse requisito vincularia a uma tabela. Seria menos completo (você tem uma sentença textual e uma tabela a ser mantida), mas elas estariam no mesmo documento ou banco de dados. No entanto, se você executasse o vínculo em uma ferramenta de gerenciamento de requisitos, eles poderiam ser vinculados para que as alterações em um destacassem o requisito vinculado. Também permitiria que o texto fluísse para outros pacotes de software como está, mas com uma tabela diferente para codificações diferentes.

Porém, como você documenta os requisitos depende de suas necessidades específicas.

— Thomas Owens
fonte

4

Existem alguns problemas com sua redação que enfraquecem o requisito:

1) Você deve expressar o requisito em termos positivos , e não em termos do que ele não deve fazer . Como se faz um teste para "não travar".

2) A frase "O nome do arquivo baixado pode conter ..." é vaga.

Uma redação alternativa sugerida (puramente subjetiva, é claro) pode ser:

O aplicativo deve suportar nomes de arquivos baixados contendo caracteres não ASCII.

(A palavra "suporte" ainda é um pouco vaga e pode ser alterada para ser mais concreta quando combinada com outros requisitos para sua aplicação.)

— Kent A.
fonte

1

Comentário automático: não ASCII também não é a melhor expressão, pois não ASCII pode significar qualquer outra codificação. Um requisito melhor listaria as codificações permitidas, o que tornaria os casos de teste resultantes mais capazes de determinar se o software funciona conforme o esperado. Caso contrário, o teste de uma codificação não ASCII pode satisfazer o requisito, mas pode não testar completamente o software.

— A.

2

Seria melhor indicar "o aplicativo deve suportar nomes de arquivos baixados contendo caracteres Unicode" e talvez indicar a codificação específica que deve ser suportada, por exemplo, UTF-8.

1

O problema com a especificação escrita é que ela não diz o que o aplicativo deve fazer com os nomes de arquivos "interessantes". Encontrei um programa que substituía qualquer caractere de nome de arquivo que ele não entendesse _, com o efeito de que, quando solicitado a copiar um diretório que continha dois caracteres cujos nomes eram idênticos, exceto nos caracteres que o utilitário não entendia, o segundo arquivo gravado no diretório substituiria o primeiro. Esse comportamento seria qualificado como "não travar", mas isso não deve implicar que seja aceitável a ausência de uma especificação explícita dizendo isso.

Eu sugiro que uma boa especificação especifique afirmativamente o que deve acontecer, ou observe quais cursos de ação são aceitáveis, por exemplo, "Se um nome de arquivo contiver caracteres não reconhecidos, o sistema deverá gerar um novo GUID para a operação geral e gerar um nome de arquivo. que combina esse GUID, um número de índice e qualquer parte do nome do arquivo original que possa ser facilmente acomodada; deve produzir uma tabela mapeando os nomes de arquivos novos e antigos "ou" Se um nome de arquivo contiver caracteres não reconhecidos, o sistema poderá formar um novo nome concatenando os caracteres que ele reconhece; se dois nomes de arquivos acabarem se tornando idênticos por meio dessa transformação, qualquer um deles poderá ser arbitrariamente declarado o 'vencedor' ".

— supercat
fonte