1. 場景需求

     普通的加密模式下，整個片段內容會被整體加密，密文就不再具備被模糊查詢的功能。考慮到某些欄位存在模糊查詢的求，我們的SDK可以提供一個進階的加密模式，加密後的密文仍然可以支援模糊查詢功能。這裡我們對這種模式做簡要介紹，以便ISV在確定方案的時候做出選擇。

      在普通加密方式下，我們在資料庫檢索該加密資料的時候必須以全文進行配對。如姓名：“張大鐵”，用普通方式加密後成為“DQ21aTz/oe9qT2Xje1tTcddQ”，在數據庫查詢時，如果希望獲取關於”張大鐵”的記錄，則對應篩選條件就是篩選出加密姓名為”“DQ21aTz/ oe9qT2Xje1tTcddQ」的記錄。然而，如果我們想檢索姓名中含有「大鐵」的人的記錄，原本可以用資料庫模糊查詢(如SQL的like 語句)方式獲取，現在加密後就無法滿足這樣的要求了。

      現在，我們的加密產品中最大程度的嘗試滿足這種需求。我們有一個允許模糊查詢的加密模式，仍然允許ISV對記錄進行模糊查詢。

但使用這種方式也有一定代價：

• 支援模糊查詢加密方式，產出的密文比較長；

• 支援的模糊查詢子句長度必須大於等於##4#個英文/數字，或2#個漢字。不支援過短的查詢(出於安全考慮);

• 傳回的結果清單中有可能有多餘的結果，需要增加篩選的邏輯：對記錄先解密，再篩選；

 #

      本產品允許每個欄位獨立設定此欄位的加密模式。 請您根據自己的應用程式場景確認每個欄位的加密方案。 請您根據您的業務仔細審查、選擇。一旦加密開始之後，再更改成本就較高了。

 #2. 方案介紹

2.1普通方式：

#1)只適用於手機號碼之外的其他欄位：在SQL語句中以(key = “value”)的形式會出現在where子句中，或不存在於where子句中。

2)對手機號碼欄位：在SQL語句的where從句中出現(key like “%前3位”)的前三位模糊查詢。 (註：即模糊查詢手機號碼前3位)

2.2支援模糊查詢的方式:

#1)在SQL語句的where從句中出現(key like “%partial%”)的全文任意字符串模糊搜尋部分。 （只適用於手機號碼以外的其他欄位：）

2)只對手機號碼欄位：在SQL語句的where子句中出現(key like “%後4位”)的後四位元模糊查詢。 (註：即透過手機號碼後4位查詢記錄，不支援少於4位的模糊查詢)

# 

請您根據自己的應用程式場景確認每個欄位的加密方案。

 附註：請您根據您的業務仔細檢視、選擇。一旦加密開始之後，再更改成本就較高了。

 #根據您每個欄位的使用加密方案，加密長度可能不同。根據此修改RDS的長度：

密文實例：