摘要：避免使用最低公分母方法你可能想讓你的程序像最低公分母文件系統(tǒng)一樣，通過將所有文件名規(guī)范化為大寫，將所有文件名規(guī)范化為格式，并將所有文件時(shí)間戳標(biāo)準(zhǔn)化為秒分辨率，這是最小公分母的方法。

Node公開了文件系統(tǒng)的許多功能，但并非所有文件系統(tǒng)都相似，以下是建議的最佳實(shí)踐，以便在使用不同的文件系統(tǒng)時(shí)保持代碼簡單和安全。

在使用文件系統(tǒng)之前，你需要知道它的行為方式，不同的文件系統(tǒng)表現(xiàn)不同，并且具有比其他或多或少的功能：區(qū)分大小寫、不區(qū)分大小寫、大小寫保留、Unicode形式保留、時(shí)間戳解析、擴(kuò)展屬性、inode、Unix權(quán)限、備用數(shù)據(jù)流等。

警惕從process.platform推斷文件系統(tǒng)行為，例如，不要假設(shè)因?yàn)槟愕某绦蛟贒arwin上運(yùn)行，因此你正在處理不區(qū)分大小寫的文件系統(tǒng)（HFS+），因?yàn)橛脩艨赡苷谑褂脜^(qū)分大小寫的文件系統(tǒng)（HFSX）。類似地，不要假設(shè)因?yàn)槟愕某绦蛟贚inux上運(yùn)行，因此你正在處理支持Unix權(quán)限和inode的文件系統(tǒng)，因?yàn)槟憧赡芪挥谔囟ǖ耐獠框?qū)動器、USB或網(wǎng)絡(luò)驅(qū)動器上。

操作系統(tǒng)可能不容易推斷文件系統(tǒng)行為，但并不會丟失所有內(nèi)容，你可以探測文件系統(tǒng)以查看它的實(shí)際行為，而不是保留每個已知文件系統(tǒng)和行為的列表（總是不完整），某些易于探測的特征的存在或缺失，往往足以推斷其他更難探測的特征的行為。

請記住，某些用戶可能在工作樹中的各種路徑上安裝了不同的文件系統(tǒng)。

你可能想讓你的程序像最低公分母文件系統(tǒng)一樣，通過將所有文件名規(guī)范化為大寫，將所有文件名規(guī)范化為NFC Unicode格式，并將所有文件時(shí)間戳標(biāo)準(zhǔn)化為1秒分辨率，這是最小公分母的方法。

不要這樣做，你只能安全地與文件系統(tǒng)進(jìn)行交互，該文件系統(tǒng)在各個方面具有完全相同的最小公分母特征，你將無法以用戶期望的方式使用更高級的文件系統(tǒng)，并且你將遇到文件名或時(shí)間戳沖突，你肯定會通過一系列復(fù)雜的相關(guān)事件來丟失和損壞用戶數(shù)據(jù)，并且你將創(chuàng)建即使不是不可能解決也很困難的bug。

當(dāng)你以后需要支持僅具有2秒或24小時(shí)時(shí)間戳分辨率的文件系統(tǒng)時(shí)會發(fā)生什么？當(dāng)Unicode標(biāo)準(zhǔn)進(jìn)展到包括稍微不同的規(guī)范化算法時(shí)（如過去發(fā)生的那樣）會發(fā)生什么？

最小公分母方法傾向于嘗試僅使用“可移植”系統(tǒng)調(diào)用來創(chuàng)建可移植程序，這會導(dǎo)致程序出現(xiàn)漏洞，而且實(shí)際上是不可移植的。

通過采用超集方法充分利用你支持的每個平臺，例如，一個可移植備份程序應(yīng)該在Windows系統(tǒng)之間正確地同步btimes(文件或文件夾的創(chuàng)建時(shí)間)，并且不應(yīng)該銷毀或更改btimes，即使Linux系統(tǒng)不支持btimes。相同的可移植備份程序應(yīng)該在Linux系統(tǒng)之間正確同步Unix權(quán)限，并且不應(yīng)該銷毀或更改Unix權(quán)限，即使在Windows系統(tǒng)上不支持Unix權(quán)限。

通過使程序像更高級的文件系統(tǒng)一樣處理不同的文件系統(tǒng)，支持所有可能功能的超集：大小寫敏感、大小寫保留、Unicode形式敏感、Unicode形式保留、Unix權(quán)限、高分辨率納秒時(shí)間戳、擴(kuò)展屬性等。

在程序中保留大小寫后，如果需要與不區(qū)分大小寫的文件系統(tǒng)進(jìn)行交互，則可以始終實(shí)現(xiàn)大小寫不敏感。但是，如果你放棄了程序中的大小寫保留，你就無法安全地與保留大小寫的文件系統(tǒng)進(jìn)行交互，對于Unicode形式保留和時(shí)間戳分辨率保留也是如此。

如果文件系統(tǒng)為你提供小寫和大寫混合的文件名，則將文件名保留在給定的確切大小寫中，如果文件系統(tǒng)為你提供混合Unicode格式或NFC或NFD（或NFKC或NFKD）的文件名，則將文件名保留在給定的確切字節(jié)序列中，如果文件系統(tǒng)為你提供毫秒時(shí)間戳，則保持時(shí)間戳以毫秒為單位。

當(dāng)你使用較小的文件系統(tǒng)時(shí)，你可以始終適當(dāng)?shù)剡M(jìn)行下采樣，使用運(yùn)行程序的文件系統(tǒng)的行為所需的比較函數(shù)。如果你知道文件系統(tǒng)不支持Unix權(quán)限，那么你不應(yīng)該期望讀取你編寫的相同Unix權(quán)限。如果你知道文件系統(tǒng)不保留大小寫，那么你應(yīng)該準(zhǔn)備在程序創(chuàng)建abc時(shí)在目錄列表中看到ABC。但是，如果你知道文件系統(tǒng)確實(shí)保留了大小寫，那么在檢測文件重命名或文件系統(tǒng)區(qū)分大小寫時(shí)，你應(yīng)該將ABC視為與abc不同的文件名。

你可以創(chuàng)建一個名為test/abc的目錄，有時(shí)會驚奇地發(fā)現(xiàn)fs.readdir("test")返回["ABC"]，這不是Node中的bug，Node返回文件系統(tǒng)存儲它的文件名，并非所有文件系統(tǒng)都支持大小寫保留，某些文件系統(tǒng)將所有文件名轉(zhuǎn)換為大寫（或小寫）。

大小寫保留和Unicode形式保留是類似的概念，要理解為什么應(yīng)該保留Unicode形式，請確保首先理解為什么要保留大小寫，如果正確理解，Unicode形式保留就一樣簡單。

Unicode可以使用幾個不同的字節(jié)序列對相同的字符進(jìn)行編碼，幾個字符串可能看起來相同，但具有不同的字節(jié)序列。使用UTF-8字符串時(shí)，請注意你的期望與Unicode的工作方式一致。正如你不希望所有UTF-8字符編碼為單個字節(jié)一樣，你不應(yīng)期望幾個在人眼看起來相同的UTF-8字符串具有相同的字節(jié)表示，這可能是你可以擁有ASCII而不是UTF-8的期望。

你可以創(chuàng)建一個名為test/café的目錄（NFC Unicode形式，字節(jié)序列<63 61 66 c3 a9>并且string.length === 5）并且有時(shí)你會驚訝地發(fā)現(xiàn)fs.readdir("test")返回["café"]（NFD Unicode形式，字節(jié)序列<63 61 66 65 cc 81>并且string.length === 6），這不是Node中的bug。Node返回文件系統(tǒng)存儲時(shí)的文件名，并非所有文件系統(tǒng)都支持Unicode形式保留。

例如，HFS+會將所有文件名規(guī)范化為幾乎總是與NFD形式相同的形式，不要指望HFS+的行為與NTFS或EXT4相同，反之亦然。不要試圖通過規(guī)范化永久地更改數(shù)據(jù)作為掩蓋文件系統(tǒng)之間Unicode差異的漏洞抽象，這會產(chǎn)生問題而不解決任何問題，相反，保留Unicode形似并僅使用規(guī)范化作為比較函數(shù)。

Unicode形式不敏感和Unicode形式保留是兩種不同的文件系統(tǒng)行為，經(jīng)?；ハ嗾`解。正如在存儲和傳輸文件名時(shí)將文件名永久規(guī)范化為大寫一樣，有時(shí)不正確地實(shí)現(xiàn)了大小寫不敏感，因此，在存儲和傳輸文件名時(shí)，通過將文件名永久規(guī)范化為某種Unicode格式（在HFS+的情況下為NFD），有時(shí)會錯誤地實(shí)現(xiàn)Unicode格式不敏感性。通過使用Unicode規(guī)范化進(jìn)行比較，可以并且更好地實(shí)現(xiàn)Unicode形式不敏感而不犧牲Unicode形式保留。

Node提供string.normalize("NFC" / "NFD")，你可以使用它將UTF-8字符串規(guī)范化為NFC或NFD，你永遠(yuǎn)不應(yīng)該存儲此函數(shù)的輸出，而只是將其用作比較函數(shù)的一部分，以測試兩個UTF-8字符串對于用戶是否看起來相同。

你可以使用string1.normalize("NFC") === string2.normalize("NFC")或string1.normalize("NFD") === string2.normalize("NFD")作為比較函數(shù)，你使用哪種形式并不重要。

規(guī)范化很快但你可能希望使用緩存作為比較函數(shù)的輸入，以避免多次規(guī)范化相同的字符串，如果該字符串不在緩存中，則對其進(jìn)行規(guī)范化并對其進(jìn)行緩存，注意不要存儲或保留緩存，只能將其用作緩存。

請注意，使用normalize()要求你的Node版本包含ICU（否則normalize()將返回原始字符串），如果你從網(wǎng)站下載最新版本的Node，那么它將包括ICU。

你可以將文件的mtime（修改時(shí)間）設(shè)置為1444291759414（毫秒分辨率），并有時(shí)驚訝地發(fā)現(xiàn)fs.stat將新mtime返回為1444291759000（1秒分辨率）或1444291758000（2秒分辨率），這不是Node中的bug。Node返回文件系統(tǒng)存儲它的時(shí)間戳，并非所有文件系統(tǒng)都支持納秒、毫秒或1秒時(shí)間戳分辨率。有些文件系統(tǒng)甚至對atime時(shí)間戳的分辨率非常粗糙，例如，對于一些FAT文件系統(tǒng)，分辨率為24小時(shí)。

文件名和時(shí)間戳是用戶數(shù)據(jù)，正如你永遠(yuǎn)不會自動重寫用戶文件數(shù)據(jù)以使數(shù)據(jù)大寫或?qū)?b>CRLF規(guī)范化為LF行結(jié)束一樣，因此你不應(yīng)該通過大小寫/Unicode格式/時(shí)間戳規(guī)范化來更改、干擾或損壞文件名或時(shí)間戳，規(guī)范化只應(yīng)用于比較，絕不能用于改變數(shù)據(jù)。

規(guī)范化實(shí)際上是有損哈希碼，你可以使用它來測試某些類型的等價(jià)性（例如，即使它們具有不同的字節(jié)序列，幾個字符串看起來相同）但你永遠(yuǎn)不能將它用作實(shí)際數(shù)據(jù)的替代品，你的程序應(yīng)按原樣傳遞文件名和時(shí)間戳數(shù)據(jù)。

你的程序可以在NFC中創(chuàng)建新數(shù)據(jù)（或者以其喜歡的任何Unicode形式組合）或使用小寫或大寫文件名，或者使用2秒的分辨率時(shí)間戳，但是你的程序不應(yīng)該通過強(qiáng)加大小寫/Unicode形式/時(shí)間戳規(guī)范化來破壞現(xiàn)有的用戶數(shù)據(jù)。相反，采用超集方法并在程序中保留大小寫、Unicode格式和時(shí)間戳分辨率，這樣，你就可以安全地與執(zhí)行相同操作的文件系統(tǒng)進(jìn)行交互。

確保正確使用大小寫/Unicode形式/時(shí)間戳比較功能，如果你正在處理區(qū)分大小寫的文件系統(tǒng)，請不要使用不區(qū)分大小寫的文件名比較函數(shù)。如果你正在使用Unicode形式敏感文件系統(tǒng)（例如NTFS和大多數(shù)保留NFC和NFD或混合Unicode形式的Linux文件系統(tǒng)），請不要使用Unicode形式不敏感的比較函數(shù)。如果你正在使用納秒時(shí)間戳分辨率文件系統(tǒng)，請不要以2秒分辨率比較時(shí)間戳。

請注意你的比較函數(shù)與文件系統(tǒng)的比較函數(shù)匹配（或者如果可能的話探測文件系統(tǒng)以查看它實(shí)際比較的方式），例如，不區(qū)分大小寫比簡單的toLowerCase()比較復(fù)雜，事實(shí)上，toUpperCase()通常比toLowerCase()更好（因?yàn)樗圆煌姆绞教幚砟承┩庹Z字符）。但更好的方法是探測文件系統(tǒng)，因?yàn)槊總€文件系統(tǒng)都有自己的大小寫比較表。

例如，Apple的HFS+將文件名規(guī)范化為NFD格式，但這種NFD格式實(shí)際上是當(dāng)前NFD格式的舊版本，有時(shí)可能與最新的Unicode標(biāo)準(zhǔn)的NFD格式略有不同，不要指望HFS+ NFD始終與Unicode NFD完全相同。