解決 ASP + MySQL + UTF-8 網頁亂碼與 LIKE 中文查詢失效問題

許多開發者在使用 ASP 連接 MySQL 時，明明資料庫編碼設為 UTF-8，網頁也加了大量 UTF-8 定義，卻仍出現亂碼（小方格），且 SQL 中使用 LIKE '%中文%' 完全查不到資料。反而將頁面與連線改為 gb2312，中文顯示與查詢卻一切正常。這是典型的編碼不一致導致的問題。

核心原因

MySQL 的 CHARSET=utf8 僅代表資料儲存編碼，若連線層（ODBC 驅動、ASP 代碼頁、HTTP 回應標頭）未同步設定為 UTF-8，資料在傳輸過程中會被錯誤解碼。早期 MySQL ODBC 3.51 驅動對 UTF-8 支援不完善，常導致「存入正常、讀出亂碼」或「LIKE 查詢失效」。

經驗修正方案（以 gb2312 為例）

1. ASP 連線檔

<%@LANGUAGE="VBSCRIPT" CODEPAGE="936"%>
<% Session.CodePage = 936 %>
Set conn = CreateObject("ADODB.Connection")
conn.Open "DRIVER={MySQL ODBC 3.51 Driver};Database=你的資料庫;CharSet=gb2312;"
conn.Execute "SET NAMES gb2312;"

2. 網頁 Meta 標籤

<meta http-equiv="Content-Type" content="text/html;charset=gb2312">

關鍵點

• CODEPAGE=936 / Session.CodePage=936：指定 ASP 內部處理中文的代碼頁（簡體中文）。
• 連線字串加入 CharSet=gb2312：告訴 ODBC 驅動以 gb2312 傳輸資料。
• SET NAMES gb2312：讓 MySQL Server 知曉客戶端使用 gb2312，避免 Server 端再做轉碼。
• 前端 Meta 必須一致，否則瀏覽器會用錯編碼渲染。

若堅持使用 UTF-8 的建議

1. 升級 MySQL ODBC 驅動至 5.3+ 版本，完整支援 CharSet=utf8mb4。
2. ASP 頁面統一 CODEPAGE=65001、Session.CodePage=65001、Response.CodePage=65001、Response.CharSet="utf-8"。
3. 連線字串：CharSet=utf8mb4，並執行 SET NAMES utf8mb4。
4. 資料表/欄位 Collation 建議 utf8mb4_unicode_ci。
5. 所有 .asp 檔案另存為 UTF-8 無 BOM 編碼。

總結：舊環境（ASP + MySQL ODBC 3.51）若不想折騰驅動升級，統一改用 gb2312 是最省事、最穩定的做法；新專案請直接上 UTF-8 全鏈路。