萬物的存在是靜止、不變且永恆的，變化與運動都只是幻覺，只是眼睛業障重罷了。試想一下，一支飛行的箭，它在飛行過程中的任何瞬間都有一個暫時的位置對吧？如果這個瞬間不動，下個瞬間不動，那麼這支箭是不是根本不會動？

在開發程式的時候，我們很常需要產生出有獨立名稱，且為連續或是有規律的數值，用來當作介面的參數數值。舉例來說，有一個函數擁有10種工作模式，可以透過該函數的第一個參數來傳入數值0~9來決定要使用哪一種模式，為了方便輸入，且為了確保輸入的數值是在0~9，我們通常會使用一種特殊結構作為這個參數的型別，來代入數值0~9。如果程式語言支援列舉(enum)，這個功能通常會直接使用列舉來實現。但是Rust程式語...

在西元2015年之後，我們所熟悉的HTTP網站已經被大多數人認為是不安全的網站了，許多瀏覽器甚至會直接針對沒有使用HTTPS協定的網站打上「不安全」的標籤，就連搜尋引擎也會降低HTTP網站的排名。因此讓網站支援SSL，並使用HTTPS協定進行傳輸，已經是再基本不過的事了。然而，網站用了HTTPS協定後，就一定是安全的嗎？

一個物體要從一端移動到另一端，首先它必須要先到達路程的二分之一，而它為了要先到達路程的二分之一，它也必須先到達路程的四分之一。依此類推，物體要移動到某一個位置，它總是必須要先完成該路程的一半的路程，所以會有無限的路程要走。於是我們可以得到一個結論──物體要運動是不可能的事！

Base64是一種能將任意Binary資料用64種字元組合成字串的方法，而這個Binary資料和字串資料彼此之間是可以互相轉換的，十分方便。在實際應用上，Base64除了能將Binary資料可視化之外，也常用來表示資料加密過後的內容。然而，標準版本的Base64對於URL或是檔案路徑來說可能不是那麼的友善，因為編碼後的Base64資料可能有「+」或是「/」這兩種字元。為了解決這個問題，Base64...

在進行程式設計的時候，有時會需要進行檔案大小或是資料大小的輸入與輸出，甚至會需要對其做一些運算。做這件事有什麼困難的嗎？我們應該都知道，8個位元是1個位元組(Byte)，1000個位元組是1KB，而1000KB是1MB。在設計程式的時候，如果要將一個以位元組為單位的值，選擇適當的單位來輸出(例如1200位元組要輸出成1.20MB、5555555位元組要輸出成5.56MB)的話，就必須要多撰寫幾行程...

Achilles(中譯為阿基里斯、阿喀琉斯或阿基琉斯)是一個古希臘神話的英雄人物。不曉得各位有沒有聽過一個人體的組織──阿基里斯腱？這個「阿基里斯腱」就是「腳筋」，腳筋同時也是「阿基里斯」這位驍勇善戰、全身刀槍不入的英雄唯一的弱點，因此我們才稱腳筋為阿基里斯腱。既然我們認為阿基里斯是一個強壯的英雄，那麼究竟為什麼會有他無法追上烏龜的說法呢？

循環冗餘校驗(CRC, Cyclic Redundancy Check)是一種簡單快速的雜湊函數，可以藉由比對資料傳輸或是儲存前後的循環冗餘校驗碼，檢測其是否有錯誤發生。能夠橫跨各領域應用的Rust程式語言，會有很大的機會需要使用CRC進行一些計算。可惜的是，Rust程式語言的標準函式庫並沒有提供CRC的演算法。那麼如果要使用Rust程式語言來計算CRC，該怎麼做比較好呢？

無論是Unix-like作業系統(如Linux、macOS)或是Windows作業系統的檔案路徑，皆有支援點(.)與點點(..)的功能。點(.)被用來表示「目前路徑的節點」或是「目前的工作目錄」，例如「/path/./to」或是「./path/to」；點點(..)則被用來表示「目前路徑的節點的上一層節點」或是「目前的工作目錄的上一層目錄」，例如「/path/../to」或是「../path/to」...

在大部分的情況下，我們不會限制使用者輸入檔案路徑的時候一定要使用絕對路徑還是相對路徑。但是在程式處理的過程中，或是需要輸出一些Log資訊的時候，我們可能就必須要將路徑通通都使用絕對路徑來處理了。Rust程式語言標準函式庫中的「fs」模組，以及「Path」和「PathBuf」結構體，雖然有提供「canonicalize」函數或方法，是可以取得檔案的絕對路徑沒錯，但使用起來有一些嚴重的限制。