파일 이름 인코딩에 대한 요구 사항 표현

요구 사항 사양을 작성하는 중이며 요구 사항을 표현하는 데 딜레마가 있습니다.

시나리오 : 웹 사이트에서 파일을 다운로드하며 다운로드 한 파일은 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. 모든 것을 유니 코드로 정규화합니까? 그렇다면 소스 인코딩을 자동 감지해야합니까? 어떤 메커니즘으로?
6. 정규화가 실패하는 경우를 대비하여 유니 코드 형식과 원본을 모두 저장 하시겠습니까?

요구 사항의 더 나은 버전은

다운로더는 최소한 ASCII, ISO-8859-1, ISO-8859-15, KOI8-R, UTF-8, Shift-JIS, EUC-JP, GB2312 및 Big5를 포함한 다양한 인코딩의 파일 이름을 지원해야합니다. 웹 서버 응답이 인코딩을 지정하는 경우이를 존중해야합니다. (인코딩이 지정되지 않은 경우 ISO-8859-1이 가정되거나 더 나은 추측이 이루어질 수 있습니다.) 파일 이름은 컨텐츠 관리 시스템에서 유니 코드 표현으로 정규화되어야합니다.

필요한 인코딩의 구체적인 예는 수락 기준을 고안하는 데 필수적입니다. 추가 된 문장은 충돌하지 않고 소프트웨어가 수행해야 할 작업을 나타냅니다.

귀하가 작성한 요구 사항에는 좋은 요구 사항의 특성 이 없습니다 . 구체적으로, 응집력이없고, 원자 적이 아니며, 모호하지 않습니다. 이러한 특성이 없기 때문에 쉽게 확인할 수 없습니다.

초기 상태 요구 사항은 다음과 같습니다.

다운로드 한 파일 이름에 ASCII가 아닌 문자가 포함되어있을 수 있으며이 파일을 처리하면 응용 프로그램이 중단되지 않습니다

"...을 처리하면 응용 프로그램이 중단되지 않습니다"를 제거하는 것이 좋습니다. 소프트웨어가 무언가를해야한다는 요구 사항이 있다면, 소프트웨어를 충돌시키지 않고해야한다는 가정을하는 것이 좋다고 생각합니다.

이는 요구 사항을 다음과 같이 변환합니다.

다운로드 한 파일 이름에 ASCII가 아닌 문자가 포함될 수 있습니다

이제 응집력 있고 원자적인 요구 사항이 있습니다. 그러나 나는 그것이 확실하지 않다. 귀하의 질문에는 여러 가지 다른 형식이 언급되어 있습니다. 몇 가지 옵션이 있습니다.

일부는 지원해야하는 각 파일 이름 인코딩에 대해 별도의 고유 한 요구 사항을 권장합니다. 이는 응집성, 원 자성, 추적 가능, 명확하고 검증 가능한 요구 사항을 가장 잘 지원합니다. 또한 각 요구 사항의 중요성을보다 쉽게 ​​지정할 수 있습니다. 아마도 일부 인코딩에 대한 지원이 더 중요하거나 더 필요할 수 있습니다.

다른 사람들은 지원되는 형식의 테이블을 권장 할 수 있으며이 요구 사항은 테이블에 연결됩니다. 덜 완전하지만 (텍스트 문장과 테이블을 유지 보수해야 함) 동일한 문서 나 데이터베이스에있을 것입니다. 그러나 요구 사항 관리 도구에서 링크를 수행하려는 경우이를 변경하면 링크 된 요구 사항이 강조 표시 될 수 있습니다. 또한 텍스트를 그대로 다른 소프트웨어 패키지로 전달할 수 있지만 다른 인코딩에 대해 다른 테이블을 사용합니다.

요구 사항을 문서화하는 방법은 특정 요구에 따라 다릅니다.

요구 사항을 약화시키는 문구에는 몇 가지 문제가 있습니다.

1) 요구 사항을 하지 말아야 할 것이 아니라 긍정적 인 용어로 표현 해야합니다 . "충돌하지 않는"테스트는 어떻게합니까?

2) "다운로드 한 파일 이름에 다음 이 포함되어 있을 수 있습니다 ..." 라는 문구 가 모호합니다.

제안 된 대체 문구 (순전히 주관적)는 다음과 같습니다.

응용 프로그램은 ASCII가 아닌 문자가 포함 된 다운로드 파일 이름을 지원해야합니다.

( "지원"이라는 단어는 여전히 약간 모호하며 응용 프로그램의 다른 요구 사항과 함께 사용할 때보다 구체적으로 변경 될 수 있습니다.)

작성된 스펙의 문제점은 응용 프로그램이 "관심있는"파일 이름으로 무엇을해야하는지 말하지 않는다는 것입니다. 나는 이해하지 못하는 파일 이름 문자를 대체하는 하나의 프로그램을 발견했습니다 _. 유틸리티가 이해하지 못하는 문자를 제외하고 이름이 동일한 두 문자가 포함 된 디렉토리를 복사하라는 메시지가 표시되면 두 번째 파일 디렉토리에 쓰면 첫 번째 디렉토리를 덮어 씁니다. 이러한 동작은 "충돌하지 않는"것으로 간주되지만 명시적인 사양이없는 것으로 허용되는 것은 아닙니다.

좋은 스펙은 어떤 일이 발생해야하는지 적극적으로 명시해야하며, 그렇지 않은 경우 어떤 행동 강령을 수용해야하는지 제안해야합니다 (예 : "파일 이름에 인식 할 수없는 문자가 포함 된 경우 시스템은 전체 작업을위한 새로운 GUID를 생성하고 파일 이름을 생성해야 함) GUID, 색인 번호 및 쉽게 수용 할 수있는 원본 파일 이름의 일부를 결합하여 이전 파일 이름과 새 파일 이름을 매핑하는 테이블을 생성해야합니다. "또는"파일 이름에 인식 할 수없는 문자가 포함 된 경우 시스템은 새로운 파일 이름이 인식하는 문자를 연결하여 이름을 지정합니다. 두 파일 이름이 이러한 변환을 통해 동일 해지면 둘 중 하나가 임의로 '승자'로 선언 될 수 있습니다. "