Określanie wymagań dotyczących kodowania nazw plików

12

Jestem w trakcie pisania specyfikacji wymagań i mam dylemat w sformułowaniu fragmentu wymagań.

Scenariusz: pobieramy pliki ze strony internetowej, a pobrane pliki należy dołączyć do elementu w posiadanym przez nas narzędziu CM. Pobrane pliki zawierają nazwy, które mogą być ASCII, ISO-8859-1, japoński itp.

Czy w sformułowaniu poniżej „nie-ASCII” obejmuje wszystkie sytuacje?

Pobrana nazwa pliku może zawierać znaki spoza ASCII, a przetwarzanie tego nie spowoduje awarii aplikacji

KK99
źródło
Z pomocą strony internetowej, lub z wielu stron internetowych? Czy ta strona naprawdę zawiera system plików gobbledegook?
200_success
7
więc jeśli nazwa pliku zawiera ascii, aplikacja może ulec awarii;)
jk.
11
Czy pedantycznie byłoby zauważyć, że „japoński” nie jest kodowaniem?
Ixrec,
@lxrec -> masz rację. Japoński nie jest kodowaniem. Chciałem powiedzieć japońskie znaki, ale nie napisałem w pełni. dzięki
KK99,
@jk W niektórych implementacjach, jeśli nazwa pliku nie jest ASCII, aplikacja ulega awarii. prawdziwa historia :-)
KK99

Odpowiedzi:

30

Wymóg, jak stwierdzono, jest dla mnie niewyraźny.

Moje pierwsze pytanie brzmiałoby: ile kodowań znaków wymaga obsługi? Możliwe interpretacje obejmują:

  1. Każde kodowanie, jakie kiedykolwiek opracowano, w tym jednobajtowe (np. ISO-8859-15 ), wielobajtowe (np. Big5 , Shift-JIS , HZ ) i rzadkie / dziwne (np. UTF-7 , Punycode , EBCDIC ).
  2. To oczywiście ekstremalne. Co powiesz na minimalne wsparcie, a mianowicie ISO-8859-1?
  3. Tylko ISO-8859-1 wydaje się łasica. A może po prostu wesprzeć nowoczesne najlepsze praktyki, a mianowicie Unicode jako UTF-8 ?

Jeśli nie określisz, jakie kodowanie masz na myśli, wtedy, gdy wystąpi błąd specyficzny dla kodowania, ty i implementator moglibyście walczyć i oboje mielibyście rację. Jest to z definicji konsekwencja rozmytej specyfikacji.

Idąc dalej, co oprogramowanie musi zrobić z nazwą pliku, oprócz awarii? Czy to…

  1. Czy zachować nazwę pliku w oryginalnym kodowaniu, bajt po bajcie?
  2. Znormalizować wszystko do Unicode? Jeśli tak, to czy musi automatycznie wykrywać kodowanie źródłowe? Według jakiego mechanizmu?
  3. Przechowywać zarówno formularz Unicode, jak i oryginał, na wypadek niepowodzenia normalizacji?

Lepsza wersja twojego wymagania byłaby

Program pobierający musi obsługiwać nazwy plików w różnych kodowaniach, w tym co najmniej ASCII, ISO-8859-1, ISO-8859-15, KOI8-R, UTF-8, Shift-JIS, EUC-JP, GB2312 i Big5. Jeśli odpowiedź serwera WWW określa kodowanie, należy go przestrzegać. (Jeśli kodowanie jest nieokreślone, można założyć ISO-8859-1 lub można lepiej zgadywać.) Nazwy plików należy znormalizować do reprezentacji Unicode w systemie zarządzania treścią.

Konkretne przykłady wymaganych kodowań są niezbędne do opracowania kryteriów akceptacji. Dodane zdania określają, co oprogramowanie musi zrobić, nie powodując awarii.

200_sukces
źródło
Podczas gdy NTFS przechowuje nazwy plików w Unicode, większość innych systemów plików przechowuje nazwy plików jako strumienie bajtów bez żadnego określonego kodowania. W takim przypadku, skąd miałbyś wiedzieć, jakie kodowanie zgadnąć?
Gabe,
@ Gabe Serwer WWW, gdy obsługuje plik, może wskazywać kodowanie. Jeśli nie, istnieją również heurystyki analizy tekstu, które mogą odgadnąć kodowanie.
200_success
2
Pamiętaj, że mówimy o samej nazwie pliku, a nie o zawartości pliku. Szanse są takie, że serwer sieciowy nie ma możliwości poznania kodowania nazwy pliku, więc jeśli twierdzi, że nazwa pliku jest w określonym kodowaniu, prawdopodobnie kłamie. Jeśli spróbujesz przekonwertować z UTF-8 na UTF-16, ale twoja nazwa pliku to tak naprawdę ISO-8859-1, prawdopodobnie wystąpi awaria. Zobacz także blogs.msdn.com/b/oldnewthing/archive/2007/04/17/2158334.aspx, aby zobaczyć przykład złej heurystyki polegającej na odgadywaniu kodowań na podstawie próbek tekstu wielkości pliku.
Gabe
@ Gabe Zauważ, że jako domyślną zasugerowałem ISO-8859-1. Jest ku temu powód - pozwala uniknąć wielu niebezpieczeństw, o których wspominasz.
200_success
Obawiam się, że UTF-8 nie wystarczy - przynajmniej z niektórych wersji systemu Windows (systemy plików FAT?) Nazwy plików będą dostępne w lokalnych kodowaniach innych niż Unicode - np. Win-1252 lub win-1257; przeglądarka może konwertować nazwy plików na utf-8 podczas przesyłania, ale wątpię w to.
Peteris,
14

Wymóg, który napisałeś, nie ma cech dobrego wymagania . W szczególności nie jest spójny, nie jest atomowy i nie jest jednoznaczny. Z powodu braku tych cech nie jest to również łatwe do zweryfikowania.

Wymagany stan początkowy to:

Pobrana nazwa pliku może zawierać znaki spoza ASCII, a przetwarzanie tego nie spowoduje awarii aplikacji

Polecam usunięcie „... a przetwarzanie tego nie spowoduje awarii aplikacji”. Jeśli masz wymaganie, że oprogramowanie musi coś zrobić, myślę, że można założyć, że powinno to robić bez awarii oprogramowania.

Przekształca to wymaganie w:

Pobrana nazwa pliku może zawierać znaki inne niż ASCII

Teraz masz spójny i atomowy wymóg. Nie jestem jednak pewien, czy jest to jednoznaczne. W swoim pytaniu wymieniasz wiele różnych formatów. Istnieje kilka opcji.

Niektórzy zalecają osobne i unikalne wymagania dla każdego kodowania nazw plików, które muszą być obsługiwane. To najlepiej wspiera spójne, atomowe, identyfikowalne, jednoznaczne i weryfikowalne wymagania. Ułatwiłoby to również określenie znaczenia każdego wymagania - być może obsługa niektórych kodowań jest ważniejsza lub potrzebna wcześniej.

Inni mogą zalecić tabelę obsługiwanych formatów, a wymaganie to prowadzi do tabeli. Byłoby to mniej kompletne (masz zdanie tekstowe i tabelę do utrzymania), ale byłyby w tym samym dokumencie lub bazie danych. Jeśli jednak zamierzasz wykonać łączenie w narzędziu do zarządzania wymaganiami, można je połączyć ze sobą, aby zmiany w jednym z nich uwypukliły powiązane wymaganie. Pozwoliłoby to również na przepływ tekstu do innych pakietów oprogramowania, ale jest z inną tabelą dla różnych kodowań.

Sposób dokumentowania wymagań zależy jednak od konkretnych potrzeb.

Thomas Owens
źródło
4

Istnieje kilka problemów z twoim sformułowaniem, które osłabiają wymóg:

1) Powinieneś wyrazić wymóg w kategoriach pozytywnych , a nie w kategoriach tego, czego nie powinien robić . Jak sprawdza się test „nie upaść”.

2) Wyrażenie „Nazwa pobranego pliku może zawierać ...” jest niejasne.

Sugerowane alternatywne sformułowanie (oczywiście subiektywne) może być:

Aplikacja obsługuje pobrane nazwy plików zawierające znaki spoza ASCII.

(Słowo „wsparcie” jest wciąż nieco niejasne i można je zmienić, aby było bardziej konkretne, jeśli zostanie ono uwzględnione w połączeniu z innymi wymaganiami dotyczącymi aplikacji.)

Kent A.
źródło
1
Komentarz własny: non-ASCII również nie jest najlepszym sformułowaniem, ponieważ non-ASCII może oznaczać każde inne kodowanie. Lepszy wymóg zawierałby listę dozwolonych kodowań, co sprawiłoby, że powstałe przypadki testowe byłyby w stanie lepiej określić, czy oprogramowanie działa zgodnie z przeznaczeniem. W przeciwnym razie testowanie jednego kodowania innego niż ASCII może spełnić wymaganie, ale może nie w pełni przetestować oprogramowanie.
Kent A.
2
Lepiej byłoby powiedzieć „aplikacja będzie obsługiwać pobrane nazwy plików zawierające znaki Unicode” i być może podać konkretne kodowanie, które musi być obsługiwane, np. UTF-8.
1

Problem z zapisaną specyfikacją polega na tym, że nie mówi ona, co aplikacja powinna zrobić z „interesującymi” nazwami plików. Zetknąłem się z jednym programem, który zastąpiłby dowolne znaki nazwy pliku, których nie rozumiał _, z takim skutkiem, że gdy poproszono o skopiowanie katalogu zawierającego dwa znaki o identycznych nazwach, z wyjątkiem znaków, których narzędzie nie rozumiało, drugi plik zapisany w katalogu zastąpiłby pierwszy. Takie zachowanie kwalifikowałoby się jako „nie upaść”, ale nie powinno to oznaczać, że jest to dopuszczalne bez wyraźnej specyfikacji.

Sugerowałbym, że dobra specyfikacja powinna twierdząco określać, co powinno się stać, lub też zauważyć, jakie działania są dopuszczalne, np. „Jeśli nazwa pliku zawiera nierozpoznane znaki, system powinien wygenerować nowy identyfikator GUID dla całej operacji i wygenerować nazwę pliku który łączy ten identyfikator GUID, numer indeksu i dowolną część oryginalnej nazwy pliku, którą można łatwo pomieścić; powinien utworzyć tabelę odwzorowującą stare i nowe nazwy plików ”lub„ Jeśli nazwa pliku zawiera nierozpoznane znaki, system może utworzyć nowy nazwa poprzez połączenie rozpoznawanych znaków; jeśli dwie nazwy plików w wyniku takiej transformacji staną się identyczne, każdą z nich można dowolnie uznać za „zwycięzcę”.

supercat
źródło