在連續論述了幾篇關于CMake如何使用的文章之后，筆者也是感覺被掏空了。接下來幾篇就還是回到構建依賴庫的問題上，容筆者花時間找到更好的主題來介紹更多關于CMake使用干貨。如何有的讀者自信已經很熟悉這方面的知識，可以進行跳過，在需要的時候再進行查閱。

uriparser是一個嚴格遵循RFC 3986的URI解析和處理庫，使用C89（“ANSI C”）編寫。筆者認為在構建上uriparser這個庫非常不錯，在主頁上就已經提供了CMake項目的引入示例和可用的CMake構建選項，大家可以參考一下。不得不說，要是所有的第三方庫的文檔都寫的這么清楚那就世界和平了。

好了不廢話了，直接給出構建的關鍵指令如下所示：

# 配置CMake  
cmake .. -G "$Generator" -A x64 `
    -DCMAKE_BUILD_TYPE=RelWithDebInfo `
    -DCMAKE_INSTALL_PREFIX="$InstallDir" `
    -DURIPARSER_BUILD_TESTS=OFF `
    -DURIPARSER_BUILD_DOCS=OFF

# 構建階段，指定構建類型
cmake --build . --config RelWithDebInfo

# 安裝階段，指定構建類型和安裝目標
cmake --build . --config RelWithDebInfo --target install

另外筆者主要使用這個庫對URI字符串進行解碼，使用的函數如下所示：

std::string UriDecode(const std::string& encoded) {
  // 創建一個可修改的字符緩沖區
  std::vector<char> buffer(encoded.begin(), encoded.end());
  buffer.push_back('\0');  // 確保以 '\0' 結尾

  // 進行解碼，uriUnescapeInPlaceA 解碼數據時修改輸入緩沖區
  uriUnescapeInPlaceA(buffer.data());

  return buffer.data();
}

有以下幾點需要注意：

1. uriUnescapeInPlaceA只解碼%開頭的字符，+字符或者換行編碼需要自己處理或者使用其他API。
2. uriUnescapeInPlaceA不用考慮資源釋放的問題，因為是在自身的資源空間處理的，解碼的字符串長度只會縮短，所以資源空間夠用，不用額外申請。
3. 嘗試過直接在std::string管理的字符串空間進行修改，也可以得到正常的結果且效率更高。不過chatgpt的回答表示這樣不太安全，就還是多申請了一段空間std::vector<char> buffer來進行處理。