Noul sistem de fișiere APFS nu suportă normalizarea caracterelor Unicode la nivelul sistemului de fișiere, astfel încât fișierele sunt cele mai sigure pentru a le numi în cadrul codificării ASCII, rapoarte Cnews.
Aceasta reduce, de fapt, alegerea numelui în limba engleză, care nu necesită normalizare. În caz contrar, un număr de instrumente și cochilii de comandă nu vor putea să funcționeze cu fișierul.
Normalizarea Unicode
Sistemul de codificare Unicode include alfabetele aproape toate limbile lumii, cu scrisul, precum și numere, semne matematice, și așa mai departe. D. Pentru fiecare astfel de simbol este atașat un cod unic, pe care o parte a sistemului global face. Unele caractere sunt identificate prin mai multe combinații de cod. De exemplu, litera «é» pot fi reprezentate în UTF-8 ca doi octeți hexazecimal c3 A9, si poate arata ca un hexazecimal de trei octeți de 65 cc 81. Cu toate acestea, vizual este una și aceeași literă, iar computerul trebuie să citească uniforma ei , de aceea este necesară normalizarea.
Fișierele numite de simbolurile alfabetelor non-engleză, APFS consideră că sunt goale
Standardul Unicode prevede patru sistem de normalizare. Anterior sistemul de fișiere Apple, numit HFS +, folosește o formă de normalizare D. Aceasta înseamnă că două diferite «é» este dat în mod automat la aceeași specie și apar sub formă de trei octeți 65 cc 81. HFS + se face la nivelul sistemului de fișiere. Astfel, tot ceea ce se face pe un Mac, indiferent dacă este o aplicație, comanda, sau MacOS în sine, de lucru cu nume de fișiere și foldere normalizate. HFS + nu poate crea nici un nume „anormale“.
Cum funcționează APFS
În APFS, normalizarea caracterelor nu este efectuată la nivelul sistemului de fișiere. APFS nu schimbă combinațiile de coduri Unicode primite, indiferent dacă au fost normalizate sau nu. Normalizarea este construită în comenzi de sistem de nivel superior care funcționează cu fișiere și foldere.
Pentru a evita problemele, Apple recomandă dezvoltatorilor să utilizeze pentru a lucra cu sistemul de fișiere de mare Fundația API, cum ar fi NSFileManager sau NSURL. Sau recurge pentru a funcționa obiecte fileSystemRepresentation NSURL crearea și deschiderea fișierelor folosind API-ul de nivel inferior, cum ar fi POSIX, și când salvați fișierele dincolo de FPP.
Problema și consecințele acesteia
Ca răspuns, dezvoltatorii explică faptul că nu toate software-ul poate rula pe un astfel de sistem, și că unele API de nivel înalt nu este acceptă încă interogări necesare pentru a efectua această procedură. Situația este favorabilă pentru apariția erorilor FPP, iar acest risc crește atunci când sunt utilizate pentru denumire a fișierelor orice altă limbă decât engleza, deoarece alfabetul englez puțin trebuie să Normalizare Unicode. Trecerea de la un sistem de fișiere la altul presupune o normalizare mixtă.
Deoarece în simbolurile HFS + sunt normalizate la nivelul sistemului de fișiere, shell-urile nu fac acest lucru. De exemplu, instrumentul Terminal însuși prescrie un "é" non-normalizat pe două biți în numele fișierului café.txt. Și instrumentul Finder, așa cum promite Apple, conduce scrisoarea la o vizualizare pe trei biți. Unele scoici pot accesa numai fișiere și foldere cu nume normalizate, adică, ei nu văd café.txt unnormalized, ca, de exemplu, Pictograma vizualizare. Terminalul vede, dar are probleme cu efectuarea operațiunilor cu acest fișier. Apfelstrudel consideră că cele două fișiere café.txt cu normalizat și non-normalizat «é» sunt numite același, și Finder - care, în mai multe moduri.
Problema poate duce la eșecul multor unelte, mai ales că introducerea comenzilor direct sau prin coajă este adesea folosită în MacOS. Acum, utilizatorul nu poate fi sigur 100% ce caracter a intrat acum. Pentru a corecta situația, va trebui să introducem un mecanism de normalizare în instrumentele în sine, dar acest lucru nu va fi ușor.
Alăturați-vă pe Twitter. VKontakte. Facebook. Google+ sau prin RSS. pentru a fi conștienți de cele mai recente știri din lumea Apple, Microsoft și Google.
Trimiteți-le prietenilor: