最近寫乙個程式用於讀取stl檔案（一種三維檔案格式），並顯示出來。stl檔案儲存格式有乙個特殊點就是分兩種型別，一種是ascii檔案型別，一種是二進位制檔案型別。ascii檔案型別的，裡面就是一些字串，描述了三維三角麵片的座標和法向量。二進位制檔案和ascii基本一致，不過是按照二進位制的方式按位來讀取，並且有檔案頭的描述。
於是我遇到乙個難題，就是如何判斷stl檔案是字串格式的還是二進位制格式的。
在解決該問題的過程中，我跳出該問題，上公升到所有檔案儲存型別的判斷。
嚴格的說，所有檔案在磁碟上的儲存都是二進位制的，這裡說說的二進位制的判斷，我認為就是判斷該檔案是否為可理解的。一串字元是可理解的，但一串類似0101001的**是無法理解的（再簡單點說：用記事本開啟你能看懂的）。
我再在網上查閱了一下，發現了好幾種解決方法，現在羅列一下，各位可以根據不同情況選擇使用：
1、判斷字元範圍。
該方式主要是針對英文本元的，如果檔案中有中文字元就會判斷失敗。比如：
該方式針對256以下的字元問題都不大，一旦遇到雙位元組中文就會出現c為負數的情況，導致判斷失敗。該方法不適合我。
2、判斷有沒有char(0)字元。
二進位制檔案基本上都會有char(0)，注意，是「基本上」 。
我嘗試通過這個方式來判斷，發現判斷正確率很高，我手頭的二進位制stl檔案都能夠判斷正確，但是總覺得這種方式不夠保險，如果剛好某個二進位制檔案沒有char(0)怎麼辦？？？
3、檔案大小對比法。
以文字方式開啟檔案，取一段資料（比如1024位元組），存為string，再寫入tmp檔案，如果新檔案的大小還是1024位元組，應該就是文字檔案了。否則就是二進位制檔案。
該方法我沒有認證，但是純粹從描述上來說，還是比較有效的。以我的理解，該方法在本質上還是方法1和方法2的結合，相比方法1來說，方便了中文字元的判斷，相比方法2來說，更為保險一些。其本質就是通過將二進位制檔案轉換為字串，將一些無效字元過濾掉（比如char(0)，回車等等），導致大小發生變化。但同樣的該方法也有漏洞，如果二進位制檔案中剛好沒有回車，沒有char(0)怎麼辦？？？
4、無效字元比例法。
該方法是基於方法1的一種概率判斷，遍歷檔案中的所有字元，對方法1中認定的無效字元進行計數，如果無效字元數量達到一定比例（這個比例值是經驗值，根據自己的程式執行環境自由設定），則認為是二進位制檔案。
同方法1一樣，無法對中文字元進行有效的判斷，乙個全為中文的文字檔案，肯定會被認定為二進位制檔案。
5、嚴格對比法。
逐字節讀取，然後滿足以下任何乙個條件那麼就是二進位制檔案：
1）所讀取位元組大於127並且小於160；
2）所讀取位元組大於等於160並且不成對出現；(注：大於等於160並成對出現的是漢字，其他unicode字符集編碼格式不是很清楚)
3）所讀取位元組小於32並且不等於9(tab)、10(換行) (注： 10 是unix格式文字換行)
4）所讀取位元組小於32並且等於13(回車)但是之後的位元組並不是10(換行) (注：13 10 是dos格式文字換行)
該方法我沒有驗證，但是感覺是最嚴謹的，也是判斷最複雜的，效率最低的，乙個較大的檔案判斷起來肯定會很慢。
最終，根絕我的應用環境，我採用了方法2，對於stl檔案來說，是一種十分有效的判斷方式，正確率極高，效率也十分的快。
留下此文以作備份，方便以後查閱！！！
C 判斷檔案是否文字檔案
今天fix bugs時，碰到乙個關於上傳檔案格式的問題。系統要求上傳.txt,csv格式的，這個可以根據檔案字尾名來過濾。但是如果使用者修改了字尾名來欺騙系統的話又該怎麼解決?比如a.jpg格式的改成a.txt，我現在的程式就無法識別了，雖然在後台可以彈出錯誤，但這個錯誤已經不是fs上定義的錯誤了。...
如何判斷文字檔案的編碼格式？
這裡指的文字是用於windows系統中的擴充套件名為.txt的檔案。notepad 記事本 只支援四種格式 ansi unicode unicode big endian uft 8，在delphi中如何判斷與讀取這些不同格式的文字呢？首先，不同編碼的文字，是根據文字的前兩個位元組來定義其編碼格式的...
判斷乙個檔案為文字檔案還是二進位制檔案
依次讀出檔案中的位元組，如果存在 0 則是二進位制檔案，否則為ascii文字檔案！實現如下 bool isasciifile lpctstr lpfilepath widechartomultibyte cp acp,wc compositecheck,lpfilepath,1,cfile,size...