Tên tệp và khoảng cách


1

Tôi đã làm việc để thực hiện một tiêu chuẩn công ty mới cho quy ước đặt tên tệp của chúng tôi (siêu thú vị) và tôi đã đề cập rằng có một "tiêu chuẩn" nói rằng bạn không nên sử dụng khoảng trắng trong tên tệp và thư mục lưu tài liệu.

Tôi đã thực hiện một số tìm kiếm và tôi đã không tìm thấy một tiêu chuẩn được công bố nói theo cách này hay cách khác cho dù điều này có thể chấp nhận được. Có ai biết một tiêu chuẩn liên quan đến điều này?

thí dụ

"Bản vẽ đã phát hành" trái ngược với "Phát hành bản vẽ" dưới dạng tên thư mục

hoặc là

"123 - Rev 0 - Phần quan trọng" trái ngược với "123-Rev0-Quan trọng"

Tôi hy vọng tìm thấy một tiêu chuẩn cụ thể, không chỉ là một quy tắc hay thực hành tốt nhất.


1
Bạn đang nhắm mục tiêu hệ điều hành nào?
Eric Shain

Hệ điều hành Windows 10, chủ yếu là các tệp CAD, pdf của các bản vẽ và các tệp word / excel là những gì tôi đang làm việc nếu có vấn đề gì.
Diesel

Bạn nên chỉnh sửa câu hỏi của bạn với thông tin cần thiết này.
Eric Shain

Tôi đã phải làm điều này cho nhiều tệp với một đồng nghiệp và vì lúc đó chỉ có 8 và 3 (cửa sổ không thể xử lý nhiều hơn thế), chúng tôi có 2 ký tự cho thị trường, 2 cho mô hình và 4 cho số thành phần ... làm việc tốt
Solar Mike

Có lẽ bạn nên xem xét các tiêu chuẩn được sử dụng cho mật khẩu: không có ký tự đặc biệt, v.v ...
Solar Mike

Câu trả lời:


4

Nếu bạn có khả năng chia sẻ các tệp của mình với các tổ chức khác sử dụng các hệ điều hành khác nhau, bạn cần nghiên cứu những gì hoạt động tốt nhất trên tất cả các tùy chọn chính - ví dụ: Windows, MacOS và các hương vị khác nhau của Unix. "Nếu nó hoạt động trên Windows 10, điều đó không sao vì đó là hệ thống duy nhất chúng tôi sử dụng" có lẽ đang đào một cái lỗ để rơi vào tương lai!

Không gian trong tên tệp thường gây ra tình trạng tăng nặng vô nghĩa, khi một hệ thống chỉ lấy "từ" đầu tiên của tên làm tên đầy đủ và đầu tiên phàn nàn rằng tệp không tồn tại, và sau đó phàn nàn rằng nó không thể hiểu điều gì xảy ra sau nó . Bạn có thể làm việc đó bằng cách đặt toàn bộ tên trong dấu ngoặc kép, nhưng tại sao lại khiến mọi người làm điều đó? Nếu bạn không thích RelazedDrawings, hãy sử dụng Relazed-Drawings hoặc Relazed_Drawings thay thế.

Có các ký tự không hợp lệ khác - bản thể rõ ràng nhất / là dấu phân cách giữa các bộ phận của tên tệp (ví dụ: thư mục và thư mục) và tương đương \ trên Windows. Các ký tự khác là dấu ngoặc kép, "& gt;", "& lt;", "?", "*", V.v. Những ký tự này có ý nghĩa đặc biệt về hướng dẫn dòng lệnh trong hầu hết các hệ điều hành.

Một số hệ điều hành có tên tệp phân biệt chữ hoa chữ thường (Phát hành và rút tiền là các tệp khác nhau!) Nhưng các tệp khác thì không. Windows là một sự thỏa hiệp.

Một số hệ thống có tên tệp "dành riêng" - ví dụ COM và NUL trên Windows.

Có thể có giới hạn về tổng chiều dài của tên tệp (bao gồm tất cả các tên thư mục đi trước nó).

Một tài liệu tham khảo của Microsoft (rõ ràng là dành riêng cho Windows) là https://support.in eb39e07630fa

Bạn có thể làm điều tồi tệ hơn là gắn bó với đặc tả POSIX cho "tên tệp di động hoàn toàn" chỉ cho phép các ký tự A-Z, a-z, 0-9, "_", "-" và "." ("-" không được là Đầu tiên ký tự của tên) và độ dài tối đa 14 ký tự hoặc ISO 9660 (được sử dụng trên CD và các thiết bị tương tự) không phân biệt chữ hoa chữ thường và chỉ cho phép A-Z, 0-9, "_" và "." với độ dài tối đa khoảng 180 ký tự.


Gotcha, do đó, mặc dù có thể không có một tiêu chuẩn cụ thể nào cho việc không bao gồm các khoảng trắng, nhưng nó thường được ưa thích hơn từ quan điểm lập trình. Tổ chức tệp dễ dàng hơn và khả năng tương thích chéo tốt hơn giữa các hệ điều hành. Định dạng mà tôi đang hướng tới gần với ISO 9660 hơn, tôi là một kẻ hút các tên tệp mô tả dài và nhiều đối với một số người mất tinh thần.
Diesel

1

AFAIK, lý do chính cho quy ước không gian là vì các hệ thống định hướng url và mạng, vì một số hệ thống gặp vấn đề khi mã hóa / giải mã không gian dưới dạng các phần của url (chúng cũng trông lộn xộn trong trình duyệt, v.v.).

Các tổ chức khác nhau có tiêu chuẩn riêng của họ như tiêu chuẩn của tổ chức này

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.