Question

我在我的數據庫測試該查詢的預期結果，並能正常工作：

select * from variables where value = 'commas-:-)';

我得到一個結果。現在，我將該值存儲在一個變量中並使用查詢類。

$value = 'commas-:-)' < < <這個作爲參數傳遞現在

$query = "select * from variables where value = '$value'"; 
$this->db->query($query); 

，這個查詢適用於除本每隔一個值 - 但有什麼奇怪的是，如果我打印出精確的查詢（print_r的$query）並在數據庫上執行它，它會返回正確的結果。所以我還是認爲查詢類與我的查詢無關，它不應該是因爲一切都妥善轉義，並且$value是一個字符串文字。

這是怎麼回事？

Answer 1

我發現了問題 - 這是這是造成這場災難的重新路由功能。更具體地說，系統內核中路由文件夾中的段過濾功能。

事情是這樣的：

我創建了編碼值（逗號:-)）的錨和我配置的路由到URI重新路由到一個功能，我在我的控制器。每次點擊鏈接時，該值都會被傳遞，並且（據推測）會被重新路由到該函數。它所做的幾乎是我所用的所有價值。除此之外。

1假設：DB查詢功能轉義值。但是我關閉了轉義，以及通過打印檢查查詢。該值是正確的。然後我嘗試了其他查詢格式，但仍然沒有結果。結論：數據庫查詢功能沒有任何問題。

第二個假設：數據必須被破壞 - 雖然值是正確的（我收到逗號:-)），它不返回除了當我在值手動輸入任何東西。所以我測試了這個： 我創建了一個獨立的值，並將其設置爲等於我輸入的那個（工作的那個）。然後我使用VAR_DUMP打印原始值（一個傳遞）和新創建的值。 原來，參數值（一個不起作用）是一個長度爲14的字符串，而我的新變量是一個長度爲10的字符串。WTF？結論：在改變變量的重新路由/傳遞過程中發生了某些事情。

我又回到了config文件夾，並替換變量$ i的重新路由到字符串值逗號:-)。你猜怎麼着？它工作完美。只是爲了確保它不是正則表達式，我寫了自己的自定義正則表達式，它很好匹配，但值仍然在改變。所以我決定深入研究。

我將路由類中的URI操作追溯到_explode_segment（）函數，該函數用於執行正則表達式並分析其他變量的uri。它也做了這個事情...

_filter_uri（$ STR）

因爲這是相匹配的URI段的每個部分。

它做了什麼？它用（和）HTML實體代替可編程字符。現在，如果你不知道，html實體的長度比url編碼長。大聲笑。所以發生了什麼事情是這樣的：

原始分段：逗號 - ％3A-％29 < - 非常好！ 已過濾的分段：逗號 - ％3A-）< - NOOOOOOOOO！ （編碼有&＃41右邊括號。）

urldecode（」 &＃41 「）=串（4） urldecode（」 ％29" ）=串（1）

失敗。

或WIN ?!

Answer 2

$sql = "SELECT * FROM variables WHERE value = ?"; 
$this->db->query($sql, array('commas-:-)')); 

更多info

Answer 3

$get_data = $this->db->from('variables') 
         ->where('value', $value) 
         ->get(); 

希望這將工作...！

嘗試使用這些東西來檢查查詢

echo $this->db->last_query(); 

print_r($this->db->result_array($get_data));