Cron Parser 是一個在瀏覽器端運作的 cron 解析器 API 替代方案，可在無需帳號、API 金鑰或遠端請求的情況下，驗證經典的五欄位 crontab 語法，並回傳接下來五個符合的執行時間（同時以本地時間與 UTC 時間表示）。此工具接受傳統的數字格式——分鐘、小時、日期、月份與星期——並支援星號、逗號清單、包含性範圍，以及正向步進（例如 */15 或 10-50/20）。驗證完成後，解析器會標準化多餘的空白、將週日的 7 標準化為 0、以淺白語言說明每個欄位選取的內容，並列舉未來最多五年安全範圍內的分鐘級匹配結果。執行結果會以檢視者的本地時間顯示，同時也提供 ISO UTC 時間戳記，方便與其他時區的排程器記錄與儀表板進行比對。此工具不會執行指令、聯繫伺服器，也不會儲存運算式，這使得它非常適合作為在將運算式貼入 Cronie、Vixie cron、systemd timers、Kubernetes CronJobs 或雲端排程器之前的快速驗證步驟。
為什麼開發者會選擇 Cron 解析器 API 替代方案
託管式的 cron 解析器服務理論上很方便，但實際的生產團隊常常會遇到相同的摩擦點。每一次請求都會消耗配額，而許多服務商會將免費方案設在使用者註冊之後，而這對 CI 管線與文件來說反而成為一項長期的依賴。一旦上游解析器發生服務中斷，可能會讓依賴已驗證的下次執行時間的部署或發行說明停擺。網路延遲雖然只是個小困擾，但在開發者只想確認「每個工作日 02:30」是否如預期回傳時，仍會為其工作迴圈多增加數秒時間。
隱私是另一個潛在的驅動因素。Cron 運算式可能會編碼部署的節奏——帳務週期、備份時段、每晚的維護作業——這些都是組織可能不希望送到第三方端點的資訊。在瀏覽器端運作的解析器徹底免除了來回傳輸：運算式在使用者自己的瀏覽器分頁中完成解析，下次執行時間也在其中計算。即使在筆電關閉 Wi-Fi 的情況下，網頁仍可運作，這使得它在出差或受限環境中依然實用。
最後，一個靜態、具確定性的替代方案更容易理解。Cron Parser 的契約是事先公開的：它以經典的五欄位數字格式為目標，並以精準的錯誤訊息拒絕其他格式，在內部使用 UTC 進行下次執行時間的掃描。這種定位比起一個會隨版本更新而微妙漂移的回應，更容易向團隊成員說明，也更容易在不同的作業系統間重現。
解析器實際檢查了什麼
解析器會依據空白字元將輸入分割為恰好五個有序的欄位。任何超過五個欄位的情況——包括六欄位的 Quartz 運算式或七欄位的雲端排程——會在第一時間被拒絕，這與 Cronie 所記錄且 Oracle Linux cron 指南所摘要的可攜式 crontab 契約一致。接著，每個欄位會根據 Cronie 風格 crontab 檔案所使用的傳統範圍進行驗證。
| 位置 | 欄位 | 允許範圍 | 特殊標準化 |
|---|---|---|---|
| 1 | Minute | 0–59 | — |
| 2 | Hour | 0–23 | — |
| 3 | Day of month | 1–31 | 略過沒有該日期的月份（由 JavaScript Date 處理） |
| 4 | Month | 1–12 | — |
| 5 | Day of week | 0–7 | 0 與 7 皆標準化為週日 |
在任何欄位中皆可使用萬用字元、逗號清單、包含性範圍與正向步進。寫成 * 的欄位會選取該範圍內的所有值。像 0,15,30,45 這樣的清單會合併個別值與可選的範圍子運算式（如 8-12）。在萬用字元上的步進——*/15——會從該欄位的最小值開始，每隔十五個值選取一次，因此在分鐘欄位中的 */15 會得到 0, 15, 30, 45。在範圍上的步進寫成 10-50/20，則會選取 10、30 與 50。
如何使用 Cron Parser 驗證運算式
- 開啟 Cron Parser 頁面，並將您的運算式輸入到輸入框中——例如 */15 9-17 * * 1-5。
- 確認您已依序提供恰好五個欄位，依「分鐘、小時、日期、月份、星期」的順序排列，並以空白字元分隔。
- 使用您的排程器所預期的語法：數字、* 萬用字元、逗號清單、包含性範圍，以及如 */15 或 10-50/20 的正向步進。其他任何形式——名稱、別稱、第六個欄位、遞減範圍——將會以精準的錯誤訊息被拒絕。
- 閱讀標準化後的運算式、各欄位的摘要說明，以及接下來五個符合的執行時間。每次執行都會以瀏覽器的本地時間顯示，同時提供 ISO UTC 時間戳記，方便您與其他時區的記錄進行比對。
- 將結果與實際執行該作業的排程器文件進行交叉比對——例如 Cronie crontab(5) 參考文件 或 Oracle Linux cron 指南——並確認您打算使用的時區已在正式主機上正確設定。
接受的語法與被拒絕的擴充
此解析器刻意以可攜式的數字核心為目標。下表摘要了哪些會被接受、哪些會被拒絕，讓您能快速判斷您的運算式是否能夠在經典的五欄位排程器上成功解析。
| 元素 | 範例 | 結果 | 原因 |
|---|---|---|---|
| 數字字面值 | 15 | 接受 | 該欄位範圍內的值 |
| 萬用字元 | * | 接受 | 選取欄位中的所有值 |
| 逗號清單 | 0,15,30,45 | 接受 | 混合數值與子範圍 |
| 包含性範圍 | 8-12 | 接受 | 必須在欄位內由小到大 |
| 在萬用字元上的步進 | */15 | 接受 | 從欄位的最小值開始 |
| 在範圍上的步進 | 10-50/20 | 接受 | 選取 10、30、50 |
| 遞減範圍 | 5-1 | 拒絕 | 必須由小到大 |
| 零或空白步進 | */0 | 拒絕 | 步進必須為正整數 |
| 空白清單項目 | 1,,3 | 拒絕 | 不允許空值 |
| 超出範圍的值 | 分鐘欄位中的 62 | 拒絕 | 超出欄位範圍 |
| 第六或第七個欄位 | * * * * * * | 拒絕 | 必須恰好五個欄位 |
| 結尾的命令文字 | 0 5 * * * /bin/true | 拒絕 | 僅解析排程部分 |
| 月份或星期名稱 | JAN 或 MON | 拒絕 | 僅接受數字語法 |
| 別稱捷徑 | @daily 或 @reboot | 拒絕 | 不屬於經典 crontab |
| Quartz 問號 | 0 0 15 ? * | 拒絕 | 僅限 Quartz 的擴充 |
| 秒數或年份欄位 | 0 0 12 * * ? 2026 | 拒絕 | 六或七欄位的方言 |
當您在不同的排程器之間遷移時，這個界線非常重要。一個能在這裡解析的五欄位運算式，在六或七欄位的服務上仍可能代表不同的意義——甚至會直接被拒絕——因此在上線排程之前，務必再次檢查目的端排程器的文件。
日期欄位、閏年與其他日曆邊界情況
日期與星期欄位值得特別留意。傳統的 cron 在兩者皆受限制時，會以「或」的方式處理：一個像 0 12 21 * 1 的運算式，除了每週一之外，也會匹配每個月的 21 號，而非僅匹配同時滿足兩者的日子。當其中一個日期欄位是萬用字元時，則由受限制的那個欄位決定匹配。Cron Parser 套用了這個「或」的行為，因此各欄位的摘要會清楚標示實際生效的規則，審閱者不必死記該慣例。
日曆的有效性會委派給 JavaScript Date 物件。這意味著像 0 0 31 2 *（二月的 31 日午夜）這樣的運算式根本不會匹配——因為沒有這一天——解析器只會在該日期實際存在的二月列出匹配。相同的機制也會處理閏年：0 0 29 2 * 會在閏年匹配，而在平年則會默默略過，因此一個在文字上看起來令人擔心的二月 29 排程，能夠在沒有意外的情況下被解析。
內部的時間運算使用 UTC 瞬間（instant）執行，因此演算法在日光節約時間的轉換期間仍能保持確定性。檢視者仍然會看到本地時間與 UTC 時間戳記，但底層的掃描永遠不需要去處理 23 小時或 25 小時的日子。這個選擇讓下次執行時間的清單在不同的機器與時區間皆可重現，這也是靜態解析器存在的核心價值。
將結果與實際排程器進行比對確認
任何 cron 解析器——無論是基於瀏覽器還是託管式——的輸出都應被視為驗證輔助，而非最終的權威依據。解析器會以 UTC 列舉接下來五個瞬間，並以本地時間回報，但實際執行該作業的排程器會使用其自身設定的時區。在 Linux 主機上，這通常意味著 /etc/localtime 或 TZ 環境變數；在容器內，則預設可能是 UTC 時鐘。一個在解析器檢視者本地時間顯示為 02:00 觸發的排程，在不同時差的地區可能會在 04:00 觸發，因此本地時間欄位是給操作者參考使用的，而 UTC 欄位才是與伺服器記錄進行比對的依據。
日期欄位的語意與支援的擴充也會因產品而異。Cronie、Vixie cron 與 systemd timers 以與 Cron Parser 相同的方式解讀經典格式，但 Kubernetes CronJobs 在並行原則與錯過執行的處理上加入了自己的機制，而 Quartz、AWS EventBridge 與 GitHub Actions 也各自帶來了不同的擴充。若您要在不同的系統之間移動運算式，請在目的端重新解析並重新閱讀其文件。針對更複雜的部署工作流程，如何透過範例在 Kubernetes 中建立 Cron Job 指南會逐步介紹經典 crontab 所未涵蓋的排程器專屬欄位。
最後，請以人工方式檢查其節奏。若您預期一個作業每小時執行一次，但解析器回報在接下來一天內有 24 次執行，則很可能是欄位順序顛倒了。若接下來五次執行集中在同一個星期，而非分散開來，那就是受限制的星期欄位比您預設的影響更大。在部署前抓出這些錯誤，正是解析器存在的實際理由，而在本機瀏覽器中執行它，則能在不將排程送到第三方服務的情況下，讓回饋迴圈保持緊湊。
若您正在權衡各種方案，本機 CSS 的 Border Radius Generator API 替代方案 有詳細的介紹。