我有一個程序，簡而言之，需要將一個文件的目錄和寫入文件中，每個文件的元數據和內容。第二步是從文件中恢復目錄。從C [linux]中的字符數組中提取一組變量變量
我無法想出一種方法來分離文件中的元數據，以便在任何情況下都可以輕鬆提取它。這主要是因爲Linux允許幾乎每個字符都用於命名目錄或文件（/或\0除外）。因此，任何其他字符可能只是文件名稱或其內容的一部分。
實施例縮短文件條目的：
DIR_NAME/sub_directory/FILE_NAME [隔板] 9999 [隔板] 1234 [隔板]內容
任何想法將不勝感激。
您可以使用例如Base64編碼
我會建議你的文件分爲兩部分，標題和正文。其中標題將包含文件名稱元數據（包括文件內容開始在正文部分的結束位置）。正文只包含文件的內容。
至少有四種基本方法：
編碼文件名
有，你可以用它來對文件進行編碼名稱，以便編碼版本只包含便攜式可接受的字符不同的編碼。
Linux中的目錄條目基本上只是非空的8位字節序列，以零結尾（\0），可能不包含正斜槓（/）。序號.爲當前目錄保留，..爲父目錄。
您可以使用多種可能的編碼。維基百科Binary-to-text category和Binary-to-text encoding page包含一些您可能希望查看的更常見示例。
逃離
類似於C如何使用反斜槓控制字符（如\n指ASCII LF，或在Unix/Linux環境換行），可以使用特殊字符，以逃避您使用的字符作爲分離器或者特別處理。 （請注意，爲便於攜帶，您應該將這些文件視爲二進制文件 - 不是例如UTF-8編碼），但特定字節具有特定含義。）
儘管您基本上無限制地瞭解如何執行最容易實現的一種方法是使用一個轉義字符，如%，後跟兩個十六進制字符來指定轉義字符。
結構化文本
您可以使用最少的標記語言，甚至像XML，描述每個目錄條目。
雖然標記會增加每個目錄條目的長度，但是擴展是微不足道的。例如，您可能希望在某個時候添加對擴展屬性的支持;以向後兼容的方式添加這些將是微不足道的。
當然，您可以改爲使用邏輯上的associative array來代替每個目錄條目，並讓您的文件成爲這些關聯數組的數組。關聯數組鍵之一將指定目錄條目名稱，指定數據部分，等等。
關聯數組邏輯數組的最小實現是在每個字段的開始處使用固定寬度的鍵。實際上，這很常見：文件格式，如JFIF（最常見的JPEG文件格式），TIFF和PNG。事實上，EXIF數據相機添加到JPEG圖像使用這種確切的可擴展性。
二進制數據結構
而不是依靠特定字節是分離的，可以使用二進制數據結構。類似於上述的JFIF等人。文件格式，檔案文件由一個或多個段組成。每個段包含一個長度（指定段的長度（以字節爲單位））和一個類型標識符。該分部的內容根據類型進一步構建。
文件名將類似地使用段描述（在「文件段」內）。因此，文件名可能包含任何字節值，包括\0和/，儘管您的應用程序當然應該驗證文件名是否適用於當前操作系統，並且可能會在必要時應用適當的轉換。 （類似的工具，如tar做。）
有兩個額外的皺紋你應該知道。一個是字節順序;你不能只說四個字節對一個單詞進行編碼，你還必須說明哪個字節是最重要/最不重要的。另一個是文件長度。許多舊的實用程序假設文件長度不會超過2個字節，因此所有長度都可以用4個字節編碼。這不再是事實。幸運的是，您可以假設在可預見的未來，文件長度不會超過2個字節;即使用八個字節來編碼長度就足夠了。 （沒有因爲它是不可想象的 - 它不是 - ，而僅僅是因爲其他人一樣，太。）
有基於哪種方法您使用的實際效果。主要是，二進制數據結構被認爲對數據損壞的穩健性較差，但它們確實允許更快的掃描（因爲像文件數據段這樣的東西可以被跳過，根本不能從存儲中檢索）。此外，人類可以解析轉義和結構化文本，但很少（完全）編碼或二進制數據;編碼和二進制數據通常需要特殊工具。個人而言，我更喜歡二進制方法，但我已經使用結構化文本，尤其是對於存儲數據的人體檢查已經有用的情況。
有問題？
[this]（http://stackoverflow.com/a/614000/1971013）有幫助嗎？ –