Oracle ascii為0的陷阱

ascii0是個空字元，如果將這個字元插入到oracle資料庫中會是什麼現象，是null嗎？

建立一張測試表

create table test(id int, name varchar2(10), comm varchar2(30));

向這張測試表中插入以下資料

insert into test values(1, null, 'null'); --直接插入null

insert into test values(2, '', 'empty string'); --插入空字元

insert into test values(3, ' ', 'blank space'); --插入空格

insert into test values(4, chr(0), 'ascii0'); --插入ascii為0的字元

查測試表，可以看到第2列似乎都是空的

sql> select * from test; id name comm ------ ---------- --------------- 1 null 2 empty string 3 blank space

4 ascii0

檢視第2列不為空值的行

sql> select * from test where name is not null; id name comm ------ ---------- --------------- 3 blank space

4 ascii0

加trim函式再查

sql> select * from test where trim(name) is not null;
id name       comm
------ ---------- ---------------
4            ascii0

可以看到第4行的第2列跟第3行的第2列的空格一樣，都是佔了乙個位元組，而且他的ascii碼為0，那麼我們可以通過下面的方式將第4行查出來

sql> select * from test where name = chr(0);
id name       comm
------ ---------- ---------------
4            ascii0

ascii為0插入到oracle中，並不是null，它占用乙個位元組，要查詢出來只能用=chr(0)

盡量別插入ascii為0的字元到資料庫中，可以用插入空字串或者null代替，否則檢索起來不方便

碰到實在是不知道這個字段到底存的是什麼的時候，可以使用dump函式去檢視它具體的ascii碼

這裡分享下這個實驗的由來。

因為要對比兩個庫的同一張表的資料差異性，表資料量不大，而且僅相差三條資料，肉眼看肯定不靠譜，很自然的就想到在乙個庫上建一張臨時表，將另外乙個庫的這張表導過來，然後做個minus。但minus出來的結果竟然是第一張表的所有行，當時氣氛一度很尷尬。

後面經過仔細分析，才發現原來是chr(0)在搞鬼，通過工具匯出chr(0)的時候，它會自動轉換成null，然而資料庫中chr(0)並不是null，也就是說匯出來再導進去的資料已經跟原始表的資料不一樣了。