輸入具有不同的數據類型可能會導致此問題，因為當前沒有任何類型或范圍檢查的XXTEA實現。
或者它可能是由于所涉及的兩臺計算機的不同端序行為，因為二進制文件通常存儲為由字節構造的字數組。
或者可能是由于缺少正式加密特定字符串和密鑰的官方或標準參考示例。在沒有參考示例(使用二進制加密結果的十六進制或base64轉換)的情況下，無法判斷加密的實現是否正確，即使其結果使用相應的解密實現正確解密。
添加：
我想我在已發布的XXTEA代碼中發現了一個兼容性問題。在這里討論它可能值得花些時間。
具體地說，問題在于不同的實現為加密相同的明文和密鑰創建了不同的結果。
討論：
這個問題是由于將明文的長度作為long數組的最后一個元素而增加的。雖然這解決了長度不是4的倍數的明文問題，但它生成的加密值與JavaScript實現生成的加密值不同。
如果你插入“$ w = false;”在long2str和str2long函數的開頭，PHP實現的加密值與JavaScript實現相同，但解密后的值最后有垃圾。
以下是此更改的一些測試用例結果：
PHP：
text: >This is an example. !@#$%^&*(){}[]:;<
Base64: PlRoaXMgaXMgYW4gZXhhbXBsZS4gIUAjJCVeJiooKXt9W106Ozw=
key: 8GmZWww5T97jb39W
encrypt: sIubYrII6jVXvMikX1oQivyOXC07bV1CoC81ZswcCV4tkg5CnrTtqQ==
decrypt: >This is an example. !@#$%^&*(){}[]:;
注意：“解密”行末尾有兩個UTF-8問號字符。
JavaScript的：
text: >This is an example. !@#$%^&*(){}[]:;<
Base64: PlRoaXMgaXMgYW4gZXhhbXBsZS4gIUAjJCVeJiooKXt9W106Ozw=
key: 8GmZWww5T97jb39W
encrypt: sIubYrII6jVXvMikX1oQivyOXC07bV1CoC81ZswcCV4tkg5CnrTtqQ==
decrypt: >This is an example. !@#$%^&*(){}[]:;<
JavaScript實現中沒有垃圾的原因即使它沒有保存明文的長度，也會在注釋中給出：“注意運行字符串的結尾會生成空值，因為按位運算符將NaN視為0”。換句話說，生成的字符串用從未見過的NUL填充，即使JavaScript(如PHP)可以在字符串中包含NUL，因為它分別存儲長度。
我對哪種方法最好是沒有意見，但應該為所有實現選擇一種方法。
應該有加密結果標準的原因(無論二進制文件是轉換為十六進制還是轉換為base64以便安全傳輸)，人們可能希望使用PHP進行編碼，而使用JavaScript進行解碼，具體取決于在兩個地方使用哪種語言是很自然的。畢竟，加密最常用于在兩個位置之間進行通信，并且目標位置使用的語言甚至可能都不知道。
)
)
)
