Nume de fișier - Filename

Image
Captură de ecran a unui shell de comandă Windows care arată numele fișierelor într-un director
Image
Lista de nume de fișiere, cu nume de fișiere lungi care conțin virgule și caractere spațiale așa cum apar într-un ecran software.

Un nume de fișier sau un nume de fișier este un nume utilizat pentru a identifica în mod unic un fișier de computer într-o structură de director . Diferite sisteme de fișiere impun restricții diferite asupra lungimii numelor de fișiere și a caracterelor permise în numele fișierelor.

Un nume de fișier poate include una sau mai multe dintre aceste componente:

  • gazdă (sau server ) - dispozitiv de rețea care conține fișierul
  • dispozitiv (sau unitate ) - dispozitiv sau unitate hardware
  • director (sau calea ) - director arbore ( de exemplu, /usr/bin, \TEMP, [USR.LIB.SRC]etc.)
  • fișier - numele de bază al fișierului
  • tip ( format sau extensie ) - indică tipul de conținut al fișierului ( de exemplu .txt, .exe, .COMetc.)
  • versiune - numărul de revizuire sau generație al fișierului

Componentele necesare pentru identificarea unui fișier variază în funcție de sistemele de operare, la fel ca și sintaxa și formatul pentru un nume de fișier valid.

Discuțiile privind numele fișierelor sunt complicate de lipsa standardizării termenului. Uneori, „nume de fișier” este folosit pentru a însemna întregul nume, cum ar fi numele Windows c: \ director \ fișierul meu.txt . Uneori, va fi folosit pentru a se referi la componente, deci numele fișierului în acest caz ar fi myfile.txt . Uneori, este o referință care exclude o extensie, astfel încât numele fișierului ar fi doar fișierul meu .

Istorie

Punct (perioada sau full-stop) ca separator de extensie nume de fișier, precum limita la extensiile de trei litere, a apărut în anii 1970. Este posibil să fi venit din limite de codare a caracterelor RAD50 pe 16 biți .

În mod tradițional, majoritatea sistemului de operare suporta nume de fișiere cu caractere alfanumerice majuscule , dar pe măsură ce timpul a trecut, numărul de caractere permise a crescut. Acest lucru a dus la probleme de compatibilitate la mutarea fișierelor între diferite sisteme de fișiere.

În 1985, RFC 959 a definit oficial un nume de cale pentru a fi șirul de caractere care trebuie introdus într-un sistem de fișiere de către un utilizator pentru a identifica un fișier.

În jurul anului 1995, VFAT , o extensie a sistemului de fișiere MS-DOS FAT, a fost introdusă în Windows 95 și Windows NT . A permis numele de fișiere lungi Unicode cu majuscule (LFN), pe lângă numele clasice „8.3”.

Referințe: absolut vs relativ

Articol principal: Cale (calcul)

O referință absolută include toate nivelurile de director. În unele sisteme, o referință de nume de fișier care nu include calea completă a directorului este implicită în directorul curent de lucru . Aceasta este o referință relativă. Un avantaj al utilizării unei referințe relative în fișierele sau scripturile de configurare a programului este că instanțele diferite ale scriptului sau programului pot utiliza fișiere diferite.

Aceasta face o cale absolută sau relativă compusă dintr-o succesiune de nume de fișiere.

Numărul de nume pe fișier

Sistemele de fișiere de tip Unix permit unui fișier să aibă mai multe nume; în sistemele de fișiere tradiționale în stil Unix, numele sunt legături dure către inodul fișierului sau echivalent. Windows acceptă legături dure pe sistemele de fișiere NTFS și oferă comanda fsutilîn Windows XP și mklinkîn versiunile ulterioare, pentru crearea acestora. Link-urile hard sunt diferite de comenzile rapide Windows , aliasurile clasice Mac OS / macOS sau linkurile simbolice . Introducerea LFN-urilor cu VFAT a permis alias-uri de nume de fișier. De exemplu, cu maximum opt caractere plus trei caractere, era un alias al fișierului „ ” ca o modalitate de a se conforma cu limitările 8.3 pentru programele mai vechi. longfi~1.???long file name.???

Această proprietate a fost utilizată de algoritmul de comandă de mutare care creează mai întâi un al doilea nume de fișier și apoi elimină doar primul nume de fișier.

Alte sisteme de fișiere, prin proiectare, furnizează un singur nume de fișier pentru fiecare fișier, ceea ce garantează că modificarea fișierului unui nume de fișier nu modifică fișierul celuilalt nume de fișier.

Restricții de lungime

Unele sisteme de fișiere restricționează lungimea numelor de fișiere. În unele cazuri, aceste lungimi se aplică întregului nume de fișier, ca în 44 de caractere pe IBM S / 370. În alte cazuri, limitele de lungime se pot aplica anumitor porțiuni ale numelui fișierului, cum ar fi numele unui fișier dintr-un director sau un nume de director. De exemplu, 9 (de exemplu, FAT pe 8 biți în Standalone Disk BASIC ), 11 (de exemplu , FAT12 , FAT16 , FAT32 în DOS), 14 (de exemplu, Unix timpuriu), 21 ( Human68K ), 31, 30 (de exemplu, Apple DOS 3.2 și 3.3), 15 (de exemplu, Apple ProDOS ), 44 (de exemplu, IBM S / 370) sau 255 (de exemplu, Berkeley Unix timpuriu) caractere sau octeți. Limitele de lungime rezultă adesea din alocarea spațiului fix într-un sistem de fișiere pentru stocarea componentelor numelor, astfel încât creșterea limitelor necesită adesea o schimbare incompatibilă, precum și rezervarea mai mult spațiu.

O problemă specială cu sistemele de fișiere care stochează informații în directoare imbricate este că ar putea fi posibil să creați un fișier cu un nume complet de cale care depășește limitele de implementare, deoarece verificarea lungimii se poate aplica numai părților individuale ale numelui, mai degrabă decât întregului nume. Multe aplicații Windows sunt limitate la o MAX_PATHvaloare de 260, dar numele fișierelor Windows pot depăși cu ușurință această limită [2] . Din Windows 10, versiunea 1607 , limitările MAX_PATH au fost eliminate.

Extensii de nume de fișier

Multe sisteme de fișiere, inclusiv sistemele FAT , NTFS și VMS , consideră extensia numelui fișierului partea numelui fișierului care constă din unul sau mai multe caractere după ultima perioadă a numelui fișierului, împărțind numele fișierului în două părți: un nume de bază sau o stemă și o extensie sau sufix utilizat de unele aplicații pentru a indica tipul de fișier . Mai multe fișiere de ieșire create de o aplicație utilizează același nume de bază și diferite extensii. De exemplu, un compilator ar putea utiliza extensia FORpentru fișierul de intrare sursă (pentru codul Fortran), OBJpentru ieșirea obiectului și LSTpentru listare. Deși există unele extensii comune, acestea sunt arbitrare și o altă aplicație ar putea utiliza RELși RPT. Extensiile au fost restricționate, cel puțin istoric pe unele sisteme, la o lungime de 3 caractere, dar, în general, pot avea orice lungime, de ex html.

Codarea interoperabilității

Nu există un standard general de codificare pentru numele de fișiere.

Numele fișierelor trebuie schimbate între mediile software pentru transferul de fișiere în rețea, stocarea sistemului de fișiere, software de backup și sincronizare a fișierelor, gestionarea configurației, comprimarea și arhivarea datelor etc. Este, așadar, foarte important să nu pierdem informațiile despre numele fișierelor între aplicații. Acest lucru a dus la adoptarea pe scară largă a Unicode ca standard pentru codarea numelor de fișiere, deși software-ul vechi ar putea să nu fie conștient de Unicode.

Interoperabilitatea indicațiilor de codificare

În mod tradițional, numele de fișiere permiteau orice caracter din numele lor de fișiere, atâta timp cât erau sigure pentru sistemul de fișiere. Deși acest lucru a permis utilizarea oricărei codificări și, astfel, a permis reprezentarea oricărui text local pe orice sistem local, a provocat multe probleme de interoperabilitate.

Un nume de fișier ar putea fi stocat folosind șiruri de octeți diferiți în sisteme distincte dintr-o singură țară, cum ar fi dacă unul ar folosi codarea japoneză Shift JIS și o altă codificare japoneză EUC . Conversia nu a fost posibilă deoarece majoritatea sistemelor nu au expus o descriere a codificării utilizate pentru un nume de fișier ca parte a informațiilor extinse ale fișierului. Acest lucru a forțat ghicirea costisitoare a codificării numelui de fișier cu fiecare acces la fișier.

O soluție a fost adoptarea Unicode ca codificare pentru numele fișierelor.

Cu toate acestea, în sistemul de operare Mac clasic, codificarea numelui fișierului a fost stocată cu atributele numelui fișierului.

Interoperabilitate Unicode

Standardul Unicode rezolvă problema determinării codării.

Cu toate acestea, rămân unele probleme limitate de interoperabilitate, cum ar fi normalizarea (echivalența) sau versiunea Unicode în uz. De exemplu, UDF este limitat la Unicode 2.0; sistemul de fișiere macOS HFS + aplică normalizarea NFD Unicode și este opțional sensibil la majuscule (fără majuscule și minuscule în mod implicit). Lungimea maximă a numelui fișierului nu este standard și poate depinde de mărimea unității de cod. Deși este o problemă serioasă, în cele mai multe cazuri aceasta este una limitată.

Pe Linux, aceasta înseamnă că numele fișierului nu este suficient pentru a deschide un fișier: în plus, este necesară reprezentarea exactă a octetului numelui fișierului pe dispozitivul de stocare. Acest lucru poate fi rezolvat la nivelul aplicației, cu unele apeluri dificile de normalizare.

Problema echivalenței Unicode este cunoscută sub numele de „coliziune de nume normalizat”. O soluție este conștientizarea non-normalizării compoziției Unicode folosită în comunitățile tehnice Subversion și Apache. Această soluție nu normalizează căile din depozit. Căile sunt normalizate numai în scopul comparațiilor. Cu toate acestea, unele comunități au brevetat această strategie, interzicând utilizarea acesteia de către alte comunități.

Perspective

Pentru a limita problemele de interoperabilitate, unele idei descrise de Sun sunt:

  • utilizați o codificare Unicode (cum ar fi UTF-8)
  • faceți conversii de cod transparente pe numele fișierelor
  • nu stocați nume de fișiere normalizate
  • verificați dacă există echivalențe canonice între numele de fișiere, pentru a evita două nume de fișiere echivalente din punct de vedere canonic în același director.

Aceste considerații creează o limitare care nu permite trecerea la o viitoare codificare diferită de UTF-8.

Migrarea Unicode

O problemă a fost migrarea către Unicode. În acest scop, mai multe companii de software au furnizat software pentru migrarea numelor de fișiere către noua codificare Unicode.

  • Microsoft a oferit migrarea transparentă pentru utilizator în întreaga tehnologie VFAT
  • Apple a furnizat „File Name Encoding Repair Utility v1.0”.
  • Comunitatea Linux a furnizat „ convmv ”.

Mac OS X 10.3 a marcat adoptarea de către Apple a descompunerii caracterelor Unicode 3.2, înlocuind descompunerea Unicode 2.1 utilizată anterior. Această modificare a cauzat probleme dezvoltatorilor care scriu software pentru Mac OS X.

Unicitate

Într-un singur director, numele fișierelor trebuie să fie unice. Deoarece sintaxa numelui de fișier se aplică și pentru directoare, nu este posibil să creați un fișier și intrări de director cu același nume într-un singur director. Mai multe fișiere din diferite directoare pot avea același nume.

Abordarea unicității poate diferi atât în ​​ceea ce privește sensibilitatea la majuscule, cât și în forma de normalizare Unicode, cum ar fi NFC, NFD. Acest lucru înseamnă că pot fi create două fișiere separate cu același nume de fișier text și o implementare de octet diferită a numelui fișierului, cum ar fi L "\ x00C0.txt" (UTF-16, NFC) (majusculă latină A cu grav) și L "\ x0041 \ x0300.txt "(UTF-16, NFD) (capitală latină A, combinare gravă).

Conservarea cazului scrisorii

Unele sisteme de fișiere, cum ar fi FAT , stochează numele fișierelor ca majuscule, indiferent de literele folosite pentru a le crea. De exemplu, un fișier creat cu numele „MyName.Txt” sau „myname.txt” va fi stocat cu numele de fișier „MYNAME.TXT”. Orice variantă de majuscule și minuscule poate fi utilizată pentru a face referire la același fișier. Aceste tipuri de sisteme de fișiere sunt numite insensibile la majuscule și minuscule . Unele sisteme de fișiere interzic utilizarea completă a literelor minuscule în numele fișierelor.

Unele sisteme de fișiere stochează numele fișierelor în forma în care au fost create inițial; acestea sunt denumite în continuare caz retentive sau caz de conservare . Un astfel de sistem de fișiere poate fi sensibil la majuscule sau minuscule . Dacă sunt sensibile la majuscule, atunci „MyName.Txt” și „myname.txt” se pot referi la două fișiere diferite din același director și fiecare fișier trebuie să fie menționat cu majuscula exactă prin care este denumit. Pe un sistem de fișiere care nu face sensibilitatea la majuscule și minuscule, pe de altă parte, doar unul dintre „MyName.Txt”, „myname.txt” și „Myname.TXT” poate fi numele unui fișier dintr-un director dat la un timp dat, iar un fișier cu unul dintre aceste nume poate fi menționat prin orice scriere cu majusculă a numelui.

Încă de la începuturile sale, Unix și sistemele sale derivate au păstrat majuscule. Cu toate acestea, nu toate sistemele de fișiere de tip Unix sunt sensibile la majuscule și minuscule; în mod implicit, HFS + în macOS nu distinge majuscule și minuscule, iar serverele SMB oferă de obicei un comportament care nu distinge majuscule (chiar și atunci când sistemul de fișiere subiacent este sensibil la majuscule și minuscule, de exemplu Samba pe majoritatea sistemelor Unix), iar sistemele de fișiere client SMB oferă majuscule comportament nesensibil. Sensibilitatea între majuscule și minuscule a sistemului este o provocare considerabilă pentru software cum ar fi Samba și Wine , care trebuie să interacționeze eficient cu ambele sisteme care tratează fișierele majuscule și minuscule ca fiind diferite și cu sistemele care le tratează la fel.

Caracterele și cuvintele rezervate

„Caracterele rezervate” redirecționează aici. Pentru caracterele care nu pot fi utilizate în titlurile paginilor de pe Wikipedia, consultați Wikipedia: Convenții de denumire (restricții tehnice) § Caractere interzise .

Sistemele de fișiere nu au furnizat întotdeauna același set de caractere pentru compunerea unui nume de fișier. Înainte ca Unicode să devină un standard de facto, sistemele de fișiere foloseau în cea mai mare parte un set de caractere dependent de localizare. În schimb, unele sisteme noi permit ca un nume de fișier să fie compus din aproape orice caracter al repertoriului Unicode și chiar din unele secvențe de octeți non-Unicode. Limitările pot fi impuse de sistemul de fișiere, sistemul de operare, aplicația sau cerințele de interoperabilitate cu alte sisteme.

Multe utilitare de sistem de fișiere interzic caracterele de control să apară în numele fișierelor. În sistemele de fișiere asemănătoare Unix,caracterul nul și separatorul de căi /sunt interzise.

În Windows

Utilitățile sistemului de fișiere și convențiile de denumire pe diferite sisteme interzic anumite caractere să apară în numele fișierelor sau le fac problematice:

Caracter Nume Motivul interzicerii
/ bară oblică Folosit ca separator de componente de nume de cale în sistemele Unix, Windows și Amiga. (Atâta timp cât setarea SwitChar este setată la „/”, shell-ul DOS COMMAND.COM îl va consuma ca caracter de comutare, dar DOS și Windows însuși îl acceptă întotdeauna ca separator la nivelul API.)
Marele solidus ⧸ ( Punctul de cod Unicode U + 29F8) este permis în numele fișierelor Windows.
\ backslash Folosit ca separator implicit de componente de nume de cale în DOS, OS / 2 și Windows (chiar dacă SwitChar este setat la „-”; permis în numele de fișiere Unix, consultați Nota 1 ). Solidusul
invers mare ⧹ (U + 29F9) este permis în numele fișierelor Windows.
? semnul întrebării Folosit ca un wildcard în Unix, Windows și AmigaOS ; marchează un singur caracter. Permis în numele de fișiere Unix, consultați Nota 1 . Stația glotal ʔ (U + 0294), The interrobang ‽ (U + 203D Tntr), semnul de întrebare inversat ¿ (U + 00BF) și dublu semnul întrebării ⁇ (U + 2047) sunt permise în toate numele de fișiere.
% la sută Folosit ca wildcard în RT-11 ; marchează un singur caracter. Nu este special pe Windows.
* asterisc
sau stea 		Folosit ca un wildcard în Unix, DOS, RT-11, VMS și Windows. Marchează orice secvență de caractere (Unix, Windows, DOS) sau orice secvență de caractere în oricare dintre numele de baza sau extensia (astfel , „*. *“ În DOS înseamnă „toate fișierele“. Permis în numele de fișiere Unix, a se vedea nota 1 . A se
vedea de stele ( glif) pentru multe caractere asterisc-permise în numele fișierelor.
: colon Folosit pentru a determina punctul de montare / unitate pe Windows; utilizat pentru a determina dispozitivul virtual sau dispozitivul fizic, cum ar fi o unitate pe AmigaOS, RT-11 și VMS; folosit ca separator de cale în sistemul de operare Mac clasic . Dublat după un nume pe VMS, indică numele nodului DECnet (echivalent cu un nume de gazdă NetBIOS (rețea Windows) precedat de „\\”.). Colon este, de asemenea, utilizat în Windows pentru a separa un flux de date alternativ de fișierul principal. Colonului scrisoare ꞉ (U + A789) și simbolul raportul : (U + 2236) sunt permise în numele de fișiere Windows. În fontul Segoe UI , utilizat în Windows Explorer , glifele pentru două puncte și două litere sunt identice.
| bara
sau țeavă verticală		 Desemnează canalizarea software în Unix, DOS și Windows; permis în numele de fișiere Unix, consultați Nota 1 . Dentare click | (U + 01C0) este permisă în numele de fișiere Windows.
" citat dublu drept Ghilimelele simple ' (U + 0027) și ' (U + 2019) și ghilimele duble curbate „ (U + 201C) și ” (U + 201D) sunt permise oriunde în numele fișierelor. A se vedea nota 1 .
< mai puțin decât Folosit pentru redirecționarea intrării , permis în numele de fișiere Unix, consultați Nota 1 .
> mai mare ca Folosit pentru redirecționarea ieșirii , permis în numele de fișiere Unix, consultați Nota 1 .
. Perioada
sau dot 		Numele dosarelor nu se pot termina cu o punctă în Windows, deși numele se poate termina cu o perioadă urmată de un caracter spațiu alb, cum ar fi un spațiu neîntrerupt . În altă parte, perioada este permisă, dar ultima apariție va fi interpretată ca separator de extensie în VMS, DOS și Windows. În alte sisteme de operare, de obicei considerate ca făcând parte din numele fișierului și pot fi permise mai multe perioade (punct). În Unix, o perioadă principală înseamnă că fișierul sau folderul sunt ascunse în mod normal.
, virgulă Permis, dar tratat ca separator de către interpreții de linie de comandă COMMAND.COM și CMD.EXE pe DOS și Windows.
; punct şi virgulă Permis, dar tratat ca separator de către interpreții de linie de comandă COMMAND.COM și CMD.EXE pe DOS și Windows.
= semn egal Permis, dar tratat ca separator de către interpreții de linie de comandă COMMAND.COM și CMD.EXE pe DOS și Windows.
spaţiu
 Permis, dar spațiul este folosit și ca separator de parametri în aplicațiile din linia de comandă . Acest lucru poate fi rezolvat prin citarea întregului nume de fișier.

Notă 1: Deși sunt permise în numele fișierelor și folderelor Unix , majoritatea shell-urilor Unix necesită caractere specifice, cum ar fi spații, <,>, |, \, și uneori:, (,), &,;, #, precum și metacaractere ca ? și *, pentru a fi citat sau scăpat :

five\ and\ six\<seven(exemplu de scăpare)
'five and six<seven'sau "five and six<seven"(exemple de citare)

Caracterul å ( 0xE5) nu a fost permis ca prima literă într-un nume de fișier sub 86-DOS și MS-DOS / PC DOS 1.x-2.x, dar poate fi utilizat în versiunile ulterioare.

În utilitarele Windows, spațiul și perioada nu sunt permise ca caracter final al unui nume de fișier. Perioada este permisă ca prim caracter, dar unele aplicații Windows, cum ar fi Windows Explorer , interzic crearea sau redenumirea unor astfel de fișiere (în ciuda acestei convenții fiind utilizată în sistemele de tip Unix pentru a descrie fișiere și directoare ascunse ). Soluțiile alternative includ adăugarea unui punct la redenumirea fișierului (care este apoi eliminat automat după aceea), folosirea administratorilor de fișiere alternative , crearea fișierului folosind linia de comandă sau salvarea unui fișier cu numele de fișier dorit din cadrul unei aplicații.

Unele sisteme de fișiere dintr-un anumit sistem de operare (în special sistemele de fișiere implementate inițial pe alte sisteme de operare) și anumite aplicații din sistemul de operare respectiv, pot aplica restricții și interpretări suplimentare. Consultați comparația sistemelor de fișiere pentru mai multe detalii despre restricții.

În sistemele de tip Unix, DOS și Windows, numele fișierelor „.” și „..” au semnificații speciale (directorul curent și respectiv directorul părinte). Windows 95/98 / ME folosește, de asemenea, nume precum „...”, „....” și așa mai departe pentru a desemna directorii bunicilor sau străbunicilor. Toate versiunile Windows interzic crearea de nume de fișiere care constau doar din puncte, deși numele sunt formate din trei puncte („...”) sau mai multe sunt legale în Unix.

În plus, în utilitarele Windows și DOS, unele cuvinte sunt, de asemenea, rezervate și nu pot fi folosite ca nume de fișiere. De exemplu, fișierele dispozitivului DOS : 

CON, PRN, AUX, CLOCK$, NUL
COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9
LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9
LST (only in 86-DOS and DOS 1.xx)
KEYBD$, SCREEN$ (only in multitasking MS-DOS 4.0)
$IDLE$ (only in Concurrent DOS 386, Multiuser DOS and DR DOS 5.0 and higher)
CONFIG$ (only in MS-DOS 7.0-8.0)

Sistemele care au aceste restricții provoacă incompatibilități cu alte sisteme de fișiere. De exemplu, Windows nu va gestiona sau va genera rapoarte de erori pentru aceste nume de fișiere UNIX legale: aux.c, q "uote" s.txt sau NUL.txt.

Numele de fișiere NTFS care sunt utilizate intern includ: 

$Mft, $MftMirr, $LogFile, $Volume, $AttrDef, $Bitmap, $Boot, $BadClus, $Secure,
$Upcase, $Extend, $Quota, $ObjId and $Reparse

Compararea limitărilor numelui de fișier

Articol principal: Compararea sistemelor de fișiere
Sistem cauza
sensibile
Conservarea cazurilor		 Set de caractere permis Caracterele rezervate Cuvinte rezervate Lungime maximă (caractere) Comentarii
FAT pe 8 biți ? ? ASCII pe 7 biți (dar stocat ca octeți) primul caracter nu poate fi 0x00 sau 0xFF 9 Limita maximă a numelui de bază de 9 caractere pentru fișierele secvențiale (fără extensie) sau extensia maximă de 6 și 3 caractere pentru fișierele binare; vezi 6.3 numele fișierului
FAT12 , FAT16 , FAT32 Nu Nu orice pagină de cod OEM SBCS / DBCS 0x00-0x1F 0x7F "* /: <>? \ | +,.; = [] (Și în unele medii:! @; DOS 1/2 nu a permis 0xE5 ca prim caracter) Numele dispozitivelor, inclusiv: $ IDLE $ AUX COM1 ... COM4 CON CONFIG $ CLOCK $ KEYBD $ LPT1 ... LPT4 LST NUL PRN SCREEN $ (în funcție de starea AVAILDEV peste tot sau numai în directorul virtual \ DEV \) 11 Limita maximă a numelui de bază de 8 caractere și extensia de 3 caractere; vezi 8.3 numele fișierului
VFAT Nu da Unicode , folosind codificarea UCS-2 0x00-0x1F 0x7F "* /: <>? \ | 255
exFAT Nu da Unicode , folosind UTF-16 care codifică 0x00-0x1F 0x7F "* /: <>? \ | 255
NTFS Opțional da Unicode , folosind UTF-16 care codifică 0x00-0x1F 0x7F "* /: <>? \ | Numai în directorul rădăcină: $ AttrDef $ BadClus $ Bitmap $ Boot $ LogFile $ MFT $ MFTMirr pagefile.sys $ Secure $ UpCase $ Volume $ Extend $ Extend \ $ ObjId $ Extend \ $ Quota $ Extend \ $ Reparse ($ Extend este un director) 255 Căile pot avea până la 32.000 de caractere.

Interzice utilizarea caracterelor din intervalul 1-31 (0x01-0x1F) și a caracterelor "* /: <>? \ | Cu excepția cazului în care numele este marcat ca fiind în spațiul de nume Posix. NTFS permite ca fiecare componentă a căii (director sau nume de fișier) să fie Lungime de 255 de caractere.

Windows interzice utilizarea numelor dispozitivelor MS-DOS AUX, CLOCK $, COM1,…, COM9, CON, LPT1,…, LPT9, NUL și PRN, precum și aceste nume cu orice extensie (de exemplu, AUX.txt) , cu excepția cazului în care se utilizează căi lungi UNC (ex. \\. \ C: \ nul.txt sau \\? \ D: \ aux \ con). (Ceasul $ poate fi utilizat, dacă este prevăzută o extensie.) API-ul Win32 elimină perioada finală (punct) și caracterele spațiale de conducere și de urmărire din numele fișierelor, cu excepția cazurilor în care sunt utilizate căile UNC. Aceste restricții se aplică numai Windows; în distribuțiile Linux care acceptă NTFS, numele fișierelor sunt scrise folosind spațiul de nume Posix al NTFS, care permite orice caracter Unicode cu excepția / și NUL.

OS / 2 HPFS Nu da orice set de 8 biți | \? * <":> / 254
Mac OS HFS Nu da orice set de 8 biți : 255 versiunile vechi ale Finder sunt limitate la 31 de caractere
Mac OS HFS + Opțional da Unicode , folosind UTF-16 care codifică : pe disc, în Mac OS clasic și la nivelul Carbon în macOS; / la stratul Unix din macOS 255 Mac OS 8.1 - macOS
majoritatea sistemelor de fișiere UNIX da da orice set de 8 biți / nul 255 o conducere . indică faptul că lsși managerii de fișiere nu vor afișa fișierul în mod implicit
Sistem de fișiere MVS clasic z / OS (seturi de date) Nu Nu Pagini de cod EBCDIC altele decât $ # @ - x'C0 ' 44 primul caracter trebuie să fie alfabetic sau național ($, #, @)

„Calificat” conține .după fiecare 8 caractere sau mai puțin. Seturile de date partiționate (PDS sau PDSE) sunt împărțite în membri cu nume de până la 8 caractere; numele de membru este plasat între paranteze după numele PDS, de exPAYROLL.DEV.CBL(PROG001)

Sistem de fișiere CMS Nu Nu Pagini de cod EBCDIC 8 + 8 Structură de director cu un singur nivel cu litere de disc (A – Z). Numele fișierului de maximum 8 caractere cu un tip de fișier de maxim 8 caractere, separate prin spații albe. De exemplu, un fișier TEXT numit MEMO pe discul A va fi accesat ca „MEMO TEXT A”. (Versiunile ulterioare ale VM au introdus structuri ierarhice ale sistemului de fișiere, SFS și BFS, dar structura originală „minidisc” de director plat este încă utilizată pe scară largă.)
UNIX timpuriu ( AT&T Corporation ) da da orice set de 8 biți / 14 o conducere . indică un fișier „ascuns”
POSIX „Numele de fișier complet portabile” da da A – Z a – z 0–9. _ - / nul 14 cratima nu trebuie să fie primul caracter. Un utilitar de linie de comandă care verifică conformitatea, „pathchk”, face parte din standardul IEEE 1003.1 și din Specificațiile de bază pentru grupul deschis
ISO 9660 Nu ? A – Z 0–9 _. „aproape de 180” (nivelul 2) sau 200 (nivelul 3) Folosit pe CD-uri; 8 niveluri de director max (pentru nivelul 1, nu nivelul 2,3)
Amiga OFS Nu da orice set de 8 biți : / nul 30 Sistem de fișiere original 1985
Amiga FFS Nu da orice set de 8 biți : / nul 30 Sistem de fișiere rapid 1988
Amiga PFS Nu da orice set de 8 biți : / nul 107 Sistem de fișiere profesional 1993
Amiga SFS Nu da orice set de 8 biți : / nul 107 Sistem de fișiere inteligent 1998
Amiga FFS2 Nu da orice set de 8 biți : / nul 107 Sistem de fișiere rapid 2 2002
BeOS BFS da da Unicode , folosind UTF-8 de codificare / 255
DEC PDP-11 RT-11 Nu Nu RADIX-50 6 + 3 Sistem de fișiere plat fără subdirecții. O „specificație de fișier” completă include dispozitiv, nume de fișier și extensie (tip de fișier) în format: dev: filnam.ext.
DEC VAX VMS Nu De la
v7.2 		A – Z 0–9 $ - _ 32 pe componentă; mai devreme 9 pe componentă; în cele din urmă, 255 pentru un nume de fișier și 32 pentru o extensie. o "specificație completă a fișierului" include numele nodului, denumirea numelui, directorul / adresele, numele fișierului, extensia și versiunea în formatul: OURNODE :: MYDISK: [THISDIR.THATDIR] FILENAME.EXTENSION;
Comodorul DOS da da orice set de 8 biți :, = $ 16 lungimea depinde de unitate, de obicei 16
HP 250 da da orice set de 8 biți SPACE ",: NULL CHR $ (255) 6 Discurile și unitățile de bandă sunt adresate fie utilizând o etichetă (până la 8 caractere), fie o specificație a unității. Sistemul de fișiere HP 250 nu folosește directoare și nici nu folosește extensii pentru a indica tipul de fișier. În schimb, tipul este un atribut (de exemplu, DATA, PROG, BKUP sau SYST pentru fișierele de date, fișierele de program, copiile de rezervă și sistemul de operare în sine).

Vezi si

Referințe

  1. ^ a b c d e f David Robinson; Ienup Sung; Nicolas Williams (martie 2006). „Prezentări Solaris: sisteme de fișiere, Unicode și normalizare” (PDF) . San Francisco: Sun.com. Arhivat din original (PDF) la 4 iulie 2012.
  2. ^ RFC  959 IETF.org RFC  959 , Protocol de transfer de fișiere (FTP)
  3. ^ "Pagina de descriere a comenzii Fsutil" . Microsoft.com . Adus la 15 septembrie 2013 .
  4. ^ "Link-uri NTFS, joncțiuni de directoare și comenzi rapide Windows" . Flex hex . Inv Softworks . Adus pe 12 martie 2011 .
  5. ^ a b "Asistență ddname cu FTP, z / OS V1R11.0 Server de comunicații Ghidul utilizatorului IP și comenzi z / OS V1R10.0-V1R11.0 SC31-8780-09" . IBM.com.
  6. ^ [1]
  7. ^ "Numele de fișiere cu accente" . Ned Batchelder . Adus la 17 septembrie 2013 .
  8. ^ "NonNormalizingUnicodeCompositionAwareness - Subversion Wiki" . Wiki.apache.org. 21 ianuarie 2013 . Adus la 17 septembrie 2013 .
  9. ^ "File Name Encoding Repair Utility v1.0" . Support.apple.com. 1 iunie 2006 . Adus pe 2 octombrie 2018 .
  10. ^ "convmv - convertește numele fișierelor dintr-o codificare în alta" . J3e.de . Adus la 17 septembrie 2013 .
  11. ^ "Re: git pe MacOSX și fișiere cu nume de fișiere descompuse utf-8" . KernelTrap. 7 mai 2010. Arhivat din original la 15 martie 2011 . Adus pe 5 iulie 2010 .
  12. ^ "Convenții de denumire cross-platform filepath - General Programming" . GameDev.net . Adus la 17 septembrie 2013 .
  13. ^ "CaseInsensitiveFilenames - The Official Wine Wiki" . Wiki.winehq.org. 8 noiembrie 2009. Arhivat din original la 18 august 2010 . Adus la 20 august 2010 .
  14. ^ "Specificațiile de bază ale grupului deschis numărul 6" . IEEE Std 1003.1-2001 . Grupul Deschis. 2001.
  15. ^ "Denumirea fișierelor, căilor și spațiilor de nume (Windows)" . Msdn.microsoft.com. 26 august 2013 . Adus la 17 septembrie 2013 .
  16. ^ „Convenții de denumire Windows” . MSDN , Microsoft.com. A se vedea ultimul element marcat.
  17. ^ a b Denumirea unui fișier msdn.microsoft.com (MSDN), restricții privind numele fișierului pe Windows
  18. ^ Microsoft Windows 95 README for Tips and Tricks , Microsoft , recuperat 27 august 2015
  19. ^ Numele driverelor de dispozitiv MS-DOS nu pot fi utilizate ca nume de fișiere. , Microsoft
  20. ^ a b Denumirea fișierelor, căilor și spațiilor de nume , Microsoft
  21. ^ Ritter, Gunnar (30 ianuarie 2007). „Povestea„ aux.c ” ” . Proiectul Heirloom .
  22. ^ "Definiție subparametru, z / OS V1R11.0 MVS JCL Reference" . IBM.com . Adus la 17 septembrie 2013 .
  23. ^ Lewine, Donald. Ghidul programatorului POSIX: scrierea programelor portabile UNIX 1991 O'Reilly & Associates, Inc. Sebastopol, CA pp63-64
  24. ^ pathchk - verificați numele de cale
  25. ^ Hewlett-Packard Company Roseville, CA Referință sintaxă HP 250 Rev 1/84 Manual Nr. Piesă 45260-90063

linkuri externe