intval() 基礎行為 int intval(mixed $var, int $base = 10) 將變數轉為整數。base 參數指定進制（2-36 或

前言 代碼安全體現了開發者的綜合素質。本文從服務器配置、代碼層面兩大維度，總結 PHP 開發中常見的安全隱患與修復方案，幫助構建更健壯的應用。 一、 服務器層

前言：安全是系統工程而非單點修補 模組化開發雖提升維護性，卻易引入隱性安全缺口。本文從九個維度梳理 PHP 專案常見安全盲區與防禦策略。 1. 基礎型風險：檔

核心防禦機制 php.ini 的 disable_functions 指令可直接在引擎層禁用指定函式，無需修改程式碼即可阻斷整類攻擊向量。被禁用函式被呼叫時會拋

前言 妥善設定 php.ini 是 PHP 應用防禦的第一道防線。本文彙整 11 項關鍵安全配置，涵蓋執行環境鎖定、功能限制、資訊洩露防範、錯誤處理等面向。

前置條件與適用場景 此方案要求頁面為 PHP 動態執行（非靜態 HTML 快取），適用於需快速封鎖特定 IP 區段的簡易存取控制場景。 完整實作代碼 <

便利背後的風險 許多開發者為了省去判斷 POST/GET 的程式碼，習慣直接使用 $_REQUEST。但深入分析會發現，$_REQUEST 不僅合併 $_GET

漏洞緣起與官方因應 上週 Dmitry 在 PHP 5.4 即將釋出前夕，引入新設定項 max_input_vars： Added max_input_vars

漏洞背景與修補演進 還記得先前討論的 PHP Hash Collisions DoS 漏洞嗎？最初開發團隊的修補方案是：當輸入變數超過 max_input_va

前言 為了保護商業邏輯或防止二次開發洩露核心代碼，開發者常對 PHP 文件進行加密混淆。本文介紹兩種不同思路的加密方案：基於 gzdeflate + base6

前言 SQL 注入是 Web 應用中最常見也最危險的漏洞之一。本文提供一套完整的 PHP 防注入方案，涵蓋輸入過濾、參數類型檢查、SQL 關鍵字攔截等多層防護機

SQL 注入核心原理 SQL 注入本質是資料與程式碼未嚴格分離，攻擊者透過精心構造的輸入，打破 SQL 語句原本結構，竄改查詢邏輯。根本原因在於直接拼接未經處理

為什麼要停用危險函數？ PHP 內建多個可執行系統指令、操作檔案系統、修改執行環境的函數，若被惡意利用將導致伺服器完全淪陷。根據最小權限原則，生產環境應停用所有

功能豐富的 Captcha 類別完整解析 這是一個支援中文、英文、數字混合、自訂字體、干擾線、干擾點、文字扭曲、邊框等進階功能的驗證碼類別，適合對安全性與使用者

前言：隨機密碼生成的核心挑戰 隨機密碼廣泛應用於用戶初始密碼、重設密碼、API Token、資料庫密鑰等場景。核心挑戰在於：**熵源品質** (隨機數是否可預測

前言 本文提供一個可直接複製部署的 PHP 防注入實例，採用「統一入口過濾 + 黑名單攔截 + 強制型別」三層架構，適合快速強化既有專案安全性。程式碼已處理 m

前言 在無法全面重構舊專案採用 PDO 時，部署一個「全站統一輸入過濾器」作為第二道防線，能有效攔截大多數自動化掃描與通用 Payload。本文提供一個可直接

前言 許多 PHP 開發者仍習慣用 addslashes() 防禦 SQL Injection，卻不知其在多位元組字符集（GBK、BIG5、UTF-8 某些情況

前言 PHP 內建 mcrypt 擴展已於 PHP 7.2 棄用、PHP 8.0 移除。若專案需「可逆加密」且不想引入 OpenSSL/Sodium 依賴，可參

前言 base64_encode、urlencode、sha1 是 PHP 開發中最高頻的三種字串處理函數，但常被混淆使用。本文釐清三者定位、編碼原理、適用場景