Oracle VARCHAR2(8000) 網頁修改報「值過大」異常分析

問題現象

新聞發布系統中 newsCon VARCHAR2(8000) 欄位，資料庫直接插入正常，但網頁修改標題（未改內容）卻拋出「值過大」異常。

根本原因

字元編碼與位元組長度不匹配：

• Oracle VARCHAR2(8000) 預設單位為位元組（除非指定 CHAR 語意）。
• 資料庫字元集若為 AL32UTF8，一個中文字佔 3 位元組，8000 位元組僅能存約 2666 個中文字。
• 網頁端（如 Java/ODP.NET）讀取時可能將內容轉為 UTF-16 或經過 HTML 實體編碼（如 <→<），導致位元組長度暴增超過 8000 限制。
• 資料庫直接插入時使用的用戶端編碼可能不同，未觸發長度檢查。

驗證方法

-- 檢查實際位元組長度
SELECT LENGTHB(newsCon) FROM news_table WHERE id = :id;

-- 檢查字元集
SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER LIKE '%CHARACTERSET%';

解決方案

方案一：改用 CLOB（推薦長文本）

ALTER TABLE news_table MODIFY newsCon CLOB;

CLOB 無 4000 位元組限制，適合新聞內文，效能現代 Oracle 版本已優化。

方案二：指定 CHAR 語意

ALTER TABLE news_table MODIFY newsCon VARCHAR2(8000 CHAR);

改以字元數計算長度，8000 個中文字無壓力。需確認應用端同樣以字元邏輯驗證。

方案三：應用端截斷/驗證

在網頁儲存前，以資料庫字元集計算位元組長度並截斷：

// Java 範例
byte[] bytes = content.getBytes("UTF-8"); // 或資料庫實際字元集
if (bytes.length > 8000) content = new String(Arrays.copyOf(bytes, 8000), "UTF-8");

最佳實踐建議

1. 新專案長文本欄位一律用 CLOB 或 VARCHAR2(n CHAR)。
2. 應用層與資料庫層編碼保持一致（建議全鏈路 UTF-8）。
3. 啟用資料庫長度檢查約束，並在應用層提前攔截友善提示。

理解「字元 vs 位元組」與「資料庫 vs 應用編碼」的差異，是解決此類長度異常的關鍵。