隨手記錄

為什麼會想要研究這個題目？其實到目前為止還不知道這個題目設定的對不對？檔案有分是否為Binary和ASCII的格式呢？真的不清楚。

若不清楚為什麼還會有這一個問題呢？起因是在測試某個產品時，會因為需求不同而會有載入不同Code檔 (文字檔)的狀況。以前一直都沒有問題，但今日卻有一個Code寫入後，在客戶端在使用上發生了問題。所以我們為了確認是否有轉錯Code的狀況，故開啟Code的文字檔來做檢查。

但卻在用UltraEdit開啟有問題Code的這一個文字檔時，發現到UltraEdit卻用不同的模式開啟這個檔案。也就是正常的檔案是用TEXT開啟和而有問題的檔案卻用HEX模式開啟。

▼UltraEdit開啟檔案的狀況

為了澄清此問題，我們再用「記事本」開啟檔案時，顯示出來的檔案容卻又是相同

▼用「記事本」開啟檔案的狀況

而用「DOS」more 指令來顯示檔案的內容，則可以發現有問題的檔案多了換行。

▼用「DOS」顯示檔案的內容

根據以往的經驗，這種問題常常發生在使用ftp傳送檔案時。ftp傳送檔案有兩種格式：ASCII和Binary，若時格式選錯時，常常會有上面所提的類似問題。故為什麼會發生這次的問題及如何解決，將不在此處探討。而只針對ASCII和Binary故基本的了解。

• 英文：American Standard Code for Information Interchange
• 中文：美國資訊交換標準代碼

ASCII有7位元編碼、8位元編碼兩種形式

2的7次方，故共可表達128個字元。最左邊(MSB)該位元並沒有用到。

• 控制字元|通訊字元：第0~32，127號(共34個)
  • 控制符：LF（換行）、CR（回車）、FF（換頁）、DEL（刪除）、BEL（振鈴）…。
  • 通訊專用字元：SOH（文頭）、EOT（文尾）、ACK（確認）…。
• 阿拉伯數字：第48~57號
• 大寫英文：第65～90號
• 小寫英文：第97~122號
• 標點|運算符號：其它

現代的電腦，對於系統內部的資料表達或處理，絕大多數都已經是以八個位元為一個位元組。當ASCII做為內碼使用時，習慣上都會在最大位元的左邊加上一個設定為“0”的位元，因而由七位元交換碼變成八位元內碼。

而這種做法也就代表著八位元內碼的256個碼位當中，會有一半的編碼空間(128個碼位）閒置不用。因此廠商為了在PC或某些終端機上（例如：VT220）提供ASCII所無的一些字元（例如：非英文的字母、數學符號、畫表格用的邊、角、線段等），特別將b8=1的128個 碼位另外賦予字元，稱為延伸ASCII。

ASCII檔 (ASCII file) 一種使用ASCII格式，

亦即上面所提到的字元集裏的字元所組的的（包含字元、空白、標點符號、跳行，有時也包含標籤和檔案結束記號），而且沒有任何格式化資訊的文件。一般也稱為ASCII file、text file、text-only file、文字檔……。

中文：二進位檔案

英語：Binary file

• 廣義的二進位檔案即為檔案，由檔案在外部儲存裝置的存放方式為二進位而得名。
• 狹義的二進位檔案即指除文字檔案以外的檔案。

也就是說所有的檔案都是Binary。但如果我們用狹義的定位，是除了「ASCII」之外的所有檔案。

答案上面已經有提到了。也就是說所有的檔案都是Binary。但如果我們用狹義的定位，是除了「ASCII」之外的所有檔案。

所以這次Code開啟時，UltraEdit會自動判定是使用TEXT (ASCII)還是HEX (Binary)的方式開啟檔案。判斷「可能」、「應該」、「也許」、「大概」是Code檔中含有非ASCII字元集中的字元和符號吧！