這個怎麼運作

Google Drive（獨立）Web 應用程式可自動從 Drive 下載（輪詢）檔案到使用者的本地 PC（下載資料夾）。

DriveApp 提供搜尋和下載檔案的機制。但是，由於 Google Apps 繼承了客戶端/伺服器架構，下載機制存在一些嚴重的限制。 （沒有谷歌的錯誤）

伺服器端 DriveApp 不提供下載到本地 PC 的直接功能，因為伺服器沒有客戶端的概念，將檔案下載到伺服器本身就沒有意義。

伺服器端程式碼需要一種機制來向客戶端程式碼提供檔案資料或檔案連結。提供了這兩種機制，但前者的資料僅限於客戶端程式碼直接使用。客戶端沒有將資料儲存到本地 PC 的機制。因此，它可用於在網頁本身上顯示資料。

第二種機制允許傳回指令碼（本身）的 url 或 Drive 檔案的 url。Drive 檔案 URL 不是很有用，因為無法在客戶端瀏覽器中直接使用它來下載檔案。將此 URL 置於錨點（並單擊它）只會導致開啟但實際上沒有執行任何操作的網頁（除非可能線上檢視該檔案）。

這留下了指令碼網址。但是指令碼 url 僅提供指令碼而不提供檔案。

要啟動下載，必須使用 ContentService createTextOutput 從伺服器端指令碼的 doGet / doPost 函式返回 Drive 服務中的檔案，完全如 Google 線上指南中所示。但是，這意味著 doGet / doPost 返回的結果在網頁上不能有其他 UI 元素。

這給我們留下了一個非常缺乏吸引力的解決方案。沒有使用者 UI 元素下載頁面的空白網頁，關閉，需要在需要另外下載時手動開啟。

顯然，另一個託管網頁可以提供 UI 和 Web App 下載指令碼的連結來解決此問題。

該指令碼使用 Dr. Jekyll 和 Mr Hyde 方法來解決此問題。

如果開啟的指令碼沒有 GET 引數（doGet），則預設顯示錶單。這將是使用者首次開啟發布的應用程式時的情況。此示例中提供的表單非常簡單。

如果使用引數 servefile = true 開啟指令碼，則指令碼將表現為 Drive 檔案下載。

客戶端 javascript 包含一個輪詢機制（事件計時器 setInterval），它定期呼叫伺服器端指令碼以檢查另一個要下載的檔案的可用性。

當伺服器端指令碼執行時，如果找到與搜尋條件匹配的任何 Drive 檔案*，則返回指令碼本身的 url，並附加引數：

？servefile = TRUE＆ID = the_id_of_the_google_drive_file

（*這個簡單示例中的搜尋條件被硬編碼到伺服器端指令碼中。如果需要，可以很容易地從客戶端傳遞到伺服器。）

此資訊通過已識別的 withSuccessHandler 機制以字串形式返回給客戶端。

然後，客戶端 java 指令碼使用此返回的資訊更新隱藏錨點的 HREF，然後自動單擊錨點。

這會導致啟動另一個 app / script 呼叫。當應用程式的新呼叫啟動時，doGet 將檢測 servefile 引數，而不是返回使用者介面，它將返回檔案到瀏覽器。返回的檔案將是由先前由上述搜尋返回的提供的 ID 引數標識的檔案。

鑑於具有提供的 ID 的檔案仍然存在，它將被下載並且應用程式的新呼叫將關閉，而第一次呼叫將重複此過程。

如果使用者/測試人員在等待計時器時不耐煩，則在簡單介面上提供一個按鈕，但不需要該按鈕，否則可以將其移除。

當然，可以擴充套件簡單形式以在需要時提供更豐富的使用者介面。例如提供檔案搜尋條件。