ASCII 模式下 TFTP 上傳期間二進製文件中的輸入和換行比特流
在 TFTP 的情況下，可以選擇“ASCII”或“八位字節”模式。據我了解，二進製文件中的 00001010（換行）或 00001101（輸入）位流在 ASCII 模式下會得到某種特殊處理嗎？但是，我創建了一個包含這些字元的文件：
root@A58:~# printf '\n' | xxd | xxd -r > bfile; printf '\r' | xxd | xxd -r >> bfile; printf 'A' | xxd | xxd -r >> bfile root@A58:~# xxd -b bfile 0000000: 00001010 00001101 01000001 ..A root@A58:~#..當我使用“八位字節”和“netascii”模式將此文件從 TFTP 客戶端上傳到 TFTP 伺服器時，該文件以相同的條件到達 TFTP 伺服器並具有完全相同的內容：
T42 ~ # cmp /srv/tftp/reverse_ascii /srv/tftp/reverse_binary T42 ~ #我做錯什麼了嗎？或者 ASCII 模式應該如何處理二進制數據？
TFTP 使用與 telnet 類似的機制來傳輸 ASCII。它遵循NVT 規範中規定的規則。因此，行尾標記有效地以 終止
<cr><lf>，如果您想發送實際的，<cr>則將其轉換為<cr><nul>.十六進制轉儲我創建的文件：
00000000 0d 54 65 73 74 69 6e 67 33 0d 0a |.Testing3..|但是在通過 tftp 傳輸時（從 a 獲得
tcpdump -X）：0x0020: 0d00 5465 7374 696e 6733 0d00 0d0a ..Testing3....請注意
<cr><lf>序列是如何轉換為<cr><nul><cr><lf>.當我比較本地和遠端文件的結果時，我最終得到了相同的文件。這將是因為
<cr><nul>序列將被返回，<cr>並且換行符的本地格式（在 unix 下）是<lf>，因此<cr><lf>被轉換為<lf>並接收到傳輸的原始文件。我不太確定 DOS tftp 伺服器將如何處理該<cr><nul><cr><lf>序列，我感覺它可能會破壞輸出以獲得額外的<cr>（<cr><nul>變得<cr>和<cr><lf>變得<cr><lf>），特別是考慮到 RFC 狀態：A host which receives netascii mode data must translate the data to its own format.參考