我有一個加密的 (128-AES-CTR-NoPadding) 視頻駐留在服務器上，我需要在下載時對其進行解密，以便用戶可以流式傳輸它（在普通播放器/網絡中）。我了解此解決方案的組成部分以及應如何將它們組合在一起以使其發揮作用。它部分有效，但對于其余部分，我無法正確實現流式傳輸。在過去的一周里，我一直在閱讀和學習示例（其中大部分是在磁盤上播放文件，這里不是這種情況），并得出結論這超出了我的范圍，我需要一些幫助。細節我使用輕量級網絡服務器 ( nanoHttpd ) 作為代理從遠程服務器下載加密數據并提供解密數據。下面是我的 NanoHTTPD.serve 方法中的主要代碼。//create urlConnection to encrypted video file with proper headers (ie range headers) as request received by the proxy serverInputStream inputStream = new CipherInputStream(cipher, urlConnection.getInputStream());return newChunkedResponse(status, contentType,inputStream);所以現在如果我轉到我的 NanoHttpd 網絡服務器 ( http://localhost:9000 )，文件將開始下載，下載完成后，文件將按預期完全解密和播放。因此，這確保了從服務器獲取加密數據和提供解密數據的工作正常。但是當要求任何視頻播放器（html5、vlc）從該 url 流式傳輸視頻時，它根本不起作用。如果將 NanoHTTPD.serve 中的上述代碼更改為//create urlConnection to cleardata video file with proper headers (ie range headers) as request received by the proxy server    InputStream inputStream = urlConnection.getInputStream();    return newChunkedResponse(status, contentType,inputStream);然后嘗試從上述播放器流式傳輸，它會工作得很好。因此，這可確保 Web 代理正確檢索和提供數據。潛在問題 為了支持來自視頻播放器的范圍請求，我們需要正確地跳到塊邊界，該塊邊界是密碼塊大小的倍數。因此，當視頻播放器請求帶有標頭（范圍：字節 34-44）的數據時，CipherInputStream 可能無法解密數據，因為輸入流具有來自 34-44 的數據。但是我不知道如何使用 urlConnection.getInputStream() 和 CipherInputStream 來做到這一點。但即使沒有這個，它至少應該開始播放前幾秒，因為視頻播放器發送的第一個請求是（范圍：0-），這意味著 inputStream 從索引 0 開始，因此 CipherInputStream 應該能夠解密并提供這些初始字節和視頻應繼續播放。我完全不知所措，因為我不知道如何調試它。歡迎任何想法，示例代碼，我會嘗試并在此處發布結果。