Frase un requisito per la codifica dei nomi di file

12

Sono in procinto di scrivere una specifica dei requisiti e ho un dilemma nel formulare un pezzo dei requisiti.

Scenario: scarichiamo i file da un sito Web e i file scaricati devono essere allegati a un elemento nello strumento CM che abbiamo. I file scaricati contengono nomi che possono essere ASCII, ISO-8859-1, giapponese, ecc.

Nel frase seguente, "non ASCII" copre tutte le situazioni?

Il nome del file scaricato può contenere caratteri non ASCII e l'elaborazione di questo non deve causare l'arresto anomalo dell'applicazione

requirements requirements-management

— KK99
fonte

Da un sito Web o da molti siti Web? Quel sito Web contiene davvero un filesystem gobbledegook?

— 200_successo

7

quindi se il nome del file contiene ASCII l'applicazione può andare in crash;)

— jk.

11

Sarebbe pedante sottolineare che "giapponese" non è una codifica?

— Ixrec

@lxrec -> hai ragione. Il giapponese non è una codifica. Quello che volevo dire erano i personaggi giapponesi ma non ho scritto a fondo. grazie

— KK99

@jk In alcune implementazioni se il nome del file non è ASCII l'applicazione si arresta in modo anomalo. storia vera :-)

— KK99

30

Il requisito, come affermato, è confuso per me.

La prima domanda che vorrei porre è: quante codifiche di caratteri devono essere supportate? Le possibili interpretazioni includono:

Ogni codifica mai ideata, inclusi single-byte (es. ISO-8859-15 ), multibyte (es. Big5 , Shift-JIS , HZ ) e rari / strani (es. UTF-7 , Punycode , EBCDIC ).
Questo è ovviamente estremo. Che ne dici del supporto minimo, ovvero ISO-8859-1?
Solo ISO-8859-1 sembra debole. Che ne dici di supportare solo le migliori pratiche moderne, ovvero Unicode come UTF-8 ?

Se non specifichi quali codifiche intendi, quando si verifica un bug specifico per la codifica, tu e il responsabile dell'implementazione potreste litigare ed entrambi avreste ragione. Questa è, per definizione, la conseguenza di una specifica sfocata.

Andando oltre, cosa deve fare il software con il nome file, oltre a non arrestarsi in modo anomalo? Dovrebbe…

Conserva il nome file nella sua codifica originale, byte per byte?
Normalizzare tutto su Unicode? In tal caso, deve rilevare automaticamente la codifica di origine? Con quale meccanismo?
Memorizzare sia il modulo Unicode che l'originale, nel caso in cui la normalizzazione fallisca?

Una versione migliore del tuo requisito sarebbe

Il downloader deve supportare nomi di file in varie codifiche, tra cui almeno ASCII, ISO-8859-1, ISO-8859-15, KOI8-R, UTF-8, Shift-JIS, EUC-JP, GB2312 e Big5. Se la risposta del server Web specifica una codifica, deve essere rispettata. (Se la codifica non è specificata, si può presumere che ISO-8859-1 o una ipotesi migliore.) I nomi dei file devono essere normalizzati in una rappresentazione Unicode nel sistema di gestione dei contenuti.

Gli esempi specifici di codifiche richieste sono essenziali per l'elaborazione di criteri di accettazione. Le frasi aggiunte indicano ciò che il software deve fare, oltre a non arrestarsi in modo anomalo.

— 200_success
fonte

Mentre NTFS memorizza i nomi dei file in Unicode, la maggior parte degli altri filesystem memorizza i nomi dei file come flussi di byte senza alcuna codifica specificata. Dato quel caso, come faresti a sapere quale codifica indovinare?

— Gabe,

@Gabe Il web server, quando serve il file, può indicare la codifica. Altrimenti, ci sono anche euristiche di analisi del testo che possono indovinare una codifica.

— 200_successo

2

Ricorda, stiamo parlando del nome del file stesso, non del contenuto del file. Le probabilità sono che il web server non abbia modo di conoscere la codifica del nome file, quindi se afferma che il nome file è in una determinata codifica, probabilmente sta mentendo. Se provi a convertire da UTF-8 a UTF-16 ma il tuo nome file è in realtà ISO-8859-1, è probabile che si verifichi un arresto anomalo. Inoltre, consultare blogs.msdn.com/b/oldnewthing/archive/2007/04/17/2158334.aspx per un esempio di come l'euristica negativa sia per indovinare le codifiche da campioni di testo di dimensioni di nome file.

— Gabe,

@Gabe Nota che ho suggerito ISO-8859-1 come impostazione predefinita. C'è una ragione per questo - evita molti dei pericoli che menzioni.

— 200_successo

Temo che UTF-8 non sia abbastanza - almeno da alcune versioni di Windows (filesystem FAT?) Otterrai nomi di file nelle codifiche locali non unicode - ad esempio win-1252 o win-1257; il browser potrebbe convertire i nomi dei file in utf-8 durante il caricamento, ma ne dubito.

— Peteris,

14

Il requisito che hai scritto non ha le caratteristiche di un buon requisito . In particolare, non è coeso, non è atomico e non è inequivocabile. A causa della mancanza di queste caratteristiche, non è anche facilmente verificabile.

Il requisito di stato iniziale è:

Il nome del file scaricato può contenere caratteri non ASCII e l'elaborazione di questo non deve causare l'arresto anomalo dell'applicazione

Vorrei raccomandare di rimuovere "... e l'elaborazione di questo non deve causare l'arresto anomalo dell'applicazione". Se hai un requisito che un software deve fare qualcosa, penso che sia giusto supporre che dovrebbe farlo senza crash del software.

Questo trasforma il requisito in:

Il nome del file scaricato può contenere caratteri non ASCII

Ora hai un requisito coesivo e atomico. Tuttavia, non sono sicuro che sia inequivocabile. Nella tua domanda, fai riferimento a diversi formati. Ci sono alcune opzioni

Alcuni raccomanderebbero un requisito separato e unico per ogni codifica del nome file che deve essere supportato. Ciò supporterebbe al meglio requisiti coerenti, atomici, tracciabili, non ambigui e verificabili. Sarebbe anche più facile specificare l'importanza di ogni requisito - forse il supporto per alcune codifiche è più importante o necessario prima.

Altri potrebbero raccomandare una tabella di formati supportati e questo requisito si collegherebbe a una tabella. Sarebbe meno completo (hai una frase testuale e una tabella da mantenere), ma sarebbero nello stesso documento o database. Tuttavia, se avessi intenzione di eseguire il collegamento in uno strumento di gestione dei requisiti, potrebbero essere collegati tra loro in modo che le modifiche a uno evidenzino il requisito collegato. Consentirebbe inoltre al testo di fluire verso altri pacchetti software così come sono, ma con una tabella diversa per codifiche diverse.

Tuttavia, il modo in cui documenti i requisiti dipende dalle tue esigenze specifiche.

— Thomas Owens
fonte

4

Ci sono un paio di problemi con la tua formulazione che indeboliscono il requisito:

1) Dovresti esprimere il requisito in termini positivi , piuttosto che in termini di ciò che non dovrebbe fare . Come si fa a testare "non andare in crash".

2) La frase "Il nome del file scaricato può contenere ..." è vaga.

Una frase alternativa suggerita (puramente soggettiva, ovviamente) potrebbe essere:

L'applicazione deve supportare nomi di file scaricati contenenti caratteri non ASCII.

(La parola "supporto" è ancora un po 'vaga e potrebbe essere modificata per essere più concreta se presa di concerto con altri requisiti per l'applicazione.)

— Kent A.
fonte

1

Auto-commento: non ASCII non è anche la migliore formulazione, poiché non ASCII potrebbe significare qualsiasi altra codifica. Un requisito migliore dovrebbe elencare le codifiche consentite, il che renderebbe i casi di test risultanti più in grado di determinare che il software funziona come previsto. Altrimenti, testare una codifica non ASCII potrebbe soddisfare il requisito, ma potrebbe non testare completamente il software.

— Kent A.

2

Sarebbe meglio indicare "l'applicazione deve supportare nomi di file scaricati contenenti caratteri Unicode" e forse indicare la codifica specifica che deve essere supportata, ad esempio UTF-8.

1

Il problema con le specifiche scritte è che non dice cosa dovrebbe fare l'applicazione con nomi di file "interessanti". Ho incontrato un programma che sostituiva i caratteri del nome file che non capiva _, con l'effetto che quando veniva chiesto di copiare una directory che conteneva due caratteri i cui nomi erano identici tranne che nei caratteri che l'utilità non capiva, il secondo file scritto nella directory sovrascriverà il primo. Tale comportamento si qualificherebbe come "non si blocca", ma ciò non dovrebbe implicare che sia accettabile in assenza di una specifica esplicita che lo dica.

Suggerirei che una buona specifica specifichi affermativamente cosa dovrebbe accadere, oppure nota quali azioni sono accettabili, ad es. "Se un nome file contiene caratteri non riconosciuti, il sistema dovrebbe generare un nuovo GUID per l'operazione complessiva e generare un nome file che combina quel GUID, un numero di indice e qualsiasi parte del nome file originale che può essere facilmente adattato; dovrebbe produrre una tabella che associa i nomi di file vecchi e nuovi "o" Se un nome di file contiene caratteri non riconosciuti, il sistema può formare un nuovo concatenando i caratteri che riconosce; se due nomi di file diventano identici attraverso tale trasformazione, uno dei due può essere arbitrariamente dichiarato "vincitore" ".

— Supercat
fonte