我需要在我的程序中包含基本的文件發送和文件接收例程，它需要通過ZMODEM協議。問題是我無法理解規範。瞭解ZMODEM協議
僅供參考，here is the specification。
該規範沒有定義各種常量，所以這裏是a header file from Google。
在我看來，像有很多重要的事情在該文件中未定義：
- ，它始終是指ZDLE編碼，但是什麼呢？什麼時候使用它，何時不使用它？
- 在ZFILE數據框之後，文件的元數據（文件名，修改日期，大小等）被傳輸。接下來是ZCRCW塊，然後是根據規範未定義類型的塊。據稱ZCRCW模塊包含一個16位CRC，但該規範沒有定義CRC計算的數據。
它沒有定義它使用的CRC多項式。我偶然發現CRC32 poly是標準的CRC32，但我沒有CRC16 poly的這種運氣。沒關係，我通過反覆試驗找到了它。 CRC16 poly是0x1021。
我查找過參考代碼，但是我能找到的所有文件都是從90年代初期以來無法讀取的，未公開的C文件。我還發現這一套從MSDN文檔，但它是痛苦的模糊和矛盾的，我已經運行的測試：http://msdn.microsoft.com/en-us/library/ms817878.aspx（您可能需要查看通過Google's cache）
爲了說明我的困難，這裏是一個簡單的例子。我在包含「Hello world！」的服務器上創建了一個純文本文件，它名爲helloworld.txt。
我開始從服務器上使用以下命令傳遞：
sx --zmodem helloworld.txt
這提示服務器發送以下ZRQINIT框架：
本2A 2A 18 42 30 30 30 30 30 30 30 30 30 30 30 30 **.B000000000000
30 30 0D 8A 11 00.Š.
三個問題：
- 是否填充字節（0x2A）是任意的？爲什麼這裏有兩個，但在其他情況下只有一個，有時沒有？
- 該規範最後沒有提及[CR] [LF] [XON]，但是MSDN文章沒有提到。爲什麼在那裏？
- 爲什麼[LF]會設置位0x80？
之後，客戶端需要發送一個ZRINIT幀。我得到這個從MSDN文章：
2A 2A 18 42 30 31 30 30 30 30 30 30 32 33 62 65 **.B0100000023be
35 30 0D 8A 50.Š
除了[LF] 0x80的標誌問題，我有兩個更多的問題：
- 爲什麼不[XON]包括這個時間呢？
CRC是根據二進制數據還是ASCII十六進制數據計算的？如果它在二進制數據上我得到0x197C，並且如果它在ASCII十六進制數據上我得到0xF775;這些都不是幀中的實際內容（0xBE50）。（已解決;它遵循您使用的任何模式，如果您處於BIN或BIN32模式，則它是二進制數據的CRC;如果您處於ASCII十六進制模式，則表示ASCII十六進制字符）
服務器用ZFILE幀響應：
2A 18 43 04 00 00 00 00 DD 51 A2 33 *.C.....ÝQ¢3
確定。這個是有道理的。如果我計算[04 00 00 00 00]的CRC32，我確實得到0x33A251DD。但是現在我們在最後沒有任何[CR] [LF] [XON]。爲什麼是這樣？
立即這個框架之後，服務器還發送文件的元數據：
68 65 6C 6C 6F 77 6F 72 6C 64 2E 74 78 74 00 31 helloworld.txt.1
33 20 32 34 30 20 31 30 30 36 34 34 20 30 20 31 3 240 100644 0 1
20 31 33 00 18 6B 18 50 D3 0F F1 11 13..k.PÓ.ñ.
這甚至沒有一個頭，它只是直接跳轉到的數據。好的，我可以忍受這一點。然而：
- 我們有我們的第一個神祕的ZCRCW框架：[18 6B]。這個框架有多長？ CRC數據在哪裏，是CRC16還是CRC32？它沒有在規範中的任何地方定義。
- MSDN文章指定[18 6B]後面應該跟[00]，但不是。
- 然後我們有一個未定義類型的幀：[18 50 D3 0F F1 11]。這是一個單獨的框架，還是它是ZCRCW的一部分？
客戶需要用ZRPOS幀響應，再次從MSDN文章採取：
2A 2A 18 42 30 39 30 30 30 30 30 30 30 30 61 38 **.B0900000000a8
37 63 0D 8A 7c.Š
同樣的問題與ZRINIT框架： CRC錯誤，在[LF]有位0x80設置，並且沒有[XON]。
服務器用ZDATA幀響應：
2A 18 43 0A 00 00 00 00 BC EF 92 8C *.C.....¼ï’Œ
同樣的問題ZFILE：CRC的所有罰款，哪來的[CR] [LF] [XON]？
之後，服務器發送文件的有效負載。由於這是一個簡單的例子，它適合在一個塊（最大尺寸爲1024）：
48 65 6C 6C 6F 20 77 6F 72 6C 64 21 0A Hello world!.
從文章似乎談不上什麼，有效載荷與[ZDLE]逃脫。那麼如何傳輸恰好匹配[ZDLE]值的有效載荷字節？還有其他的值嗎？
服務器用這些幀結束：
18 68 05 DE 02 18 D0 .h.Þ..Ð
2A 18 43 0B 0D 00 00 00 D1 1E 98 43 *.C.....Ñ.˜C
我完全失去了在第一個。第二個與ZRINIT和ZDATA幀一樣有意義。
由於完全相同的原因，我正在處理完全相同的事情;如果你曾經做過這個工作，並且有源代碼，那將會很棒...... – 2013-05-27 10:45:50
這是怎麼回事？花了幾天編碼來獲得可靠的zmodem接收工作後，我放棄了，直接去lrz。一天工作。它遠沒有那麼幹淨，但我真的不想花費更多的時間在一個古老而過時的協議上...... – bronson 2016-11-01 22:50:44
另外，要小心！我發現了一些其他的zmodem代碼庫，但它們都是完全不可靠的！我試過的文件中大概有5％以失敗告終，我甚至沒有試圖利用角落案例。確保你使用經過測試的代碼，而不是某人的週末項目。 – bronson 2016-11-01 22:53:34