STDF 是個很有趣的檔案格式，它常用在儲存 ATE 的測試資料。
對於寫 C code 的人來說，可以很簡單的用 fread + structure 的方式無腦 parsing。
它的 Hex 資料如上圖，這裡只框出前 5 筆 record。
每一筆 record 都帶有 4 個 byte 的 header，前兩個 byte 是 REC_LEN，後面兩個 byte，一個是 REC_TYP，另一個是 REC_SUB，header 後面就是帶有 REC_LEN 長度的資料。
一個橘色框框的是一筆 record，淺藍色的就是 REC_LEN，深藍色的是 REC_TYP + REC_SUB，沒有底線的就是該筆 record 的資料組成。
我們可以由 REC_TYP + REC_SUB 得知 record 的種類。
Spec 中也很貼心的用 C code 表達不同資料的解碼方式。
我們以第一筆 FAR record 為例，CPU_TYPE 欄位 = 0x02，屬於 IBM PC 的處理器，故其大於 1 byte 資料的順序為 Little Endian，比如說 REC_LEN 在解碼時，就必須反過來看。
隨便使用 STDF parser 當關鍵字在 github 搜尋就有 3 頁的程式碼可以參考，各類程式語言應有盡有，挑自己喜歡的來使用即可。
就像前面說的，C code 跟這種檔案格式很搭，故要快速得到一個結果，找 C code 的專案就對了。
2025/12/06 更新
剪頭髮時，因為等待的人數太多，看了一下 spec，終於知道如何分辨最新版本。
原本 FAR 的 STDF_VER 只有一個 byte，如果是 V4 其值等於 4。
而最新的版本為 V4-2007，因為版本號並沒有進位，故無法用一個 byte 來表示。
取而代之的是多了一筆 00 30 的 VUR record，他的 UPD_NAME 欄位是一個 char []，其值為 "V4-2007" 字串。
換句話說，即使沒有 STDF parser，直接打開檔案搜尋此字串即可。
另外，我有一個很奇怪的疑問，我發現我為了快速驗證用的 C library 在處理 D*n 時，有考慮到未滿 8 bit 的情況，故長度會 + 1，但網友用這個 C library 寫的 dumper，在 print_Dn 時犯了錯誤，並未印到後面 2 個 byte，但我印象在我修正 Code 後，辦公室的 Code 反而會當機，難道是我記錯了？
偏偏網路上都沒有 D*n 的 STDF 檔案可以驗證，真是好奇心殺死螞蟻呀XD
2025/12/13 更新
知道 Record 有所謂的 optional field，但從每個 Record 卻看不出來？
回過頭看前面的說明才知道，原來每個 Record Table 後面 Missing / Invalid Data Flag 有描述的就表示是可選欄位，跟這個欄位一樣的值就表示該值沒有意義，可以忽略，但該欄位還是要存在，除了 Record 最後面的可選欄位。
另外，Initial Sequence 是必須要有的 Records，除了位在 STDF 檔案最前面外且順序如下圖。
總之，github 既然都有現成的專案可用，個人覺得了解到這樣就夠了。
