Salesforce的id長度實例分析

本文小編為大家詳細介紹“Salesforce的id長度實例分析”，內容詳細，步驟清晰，細節處理妥當，希望這篇“Salesforce的id長度實例分析”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

    我們都知道 18位id 與 15位id 他們雖然不同,但是18位id的前15位是與15位id相同的.

    比如,一個客戶,其URL上的id參數為 0011000000VA5ok.

其中頭三位001為Account的prefix
四到六位的6F0為Org Id的第4到6位。由于OrgId的唯一性，所以每個ID在整個SFDC世界都是唯一的。

同樣是這條Account，使用公式取得的Id為18位的 0011000000VA5okAAD.
可以看出18位的Id 前15位與15位版本的Id 相同，后3位則是根據前15位計算得來。

在salesforce中所有的記錄ID有兩種長度,15位和18位,如果你知道記錄ID的15位代碼,通過下列代碼你可以將它轉換成對應的18位ID.

public class ID15to18Converter {

  
    public String char15 {get;set;}
    public String char18 {get;set;}
    public String bin15 {get;set;}
    String testString= 'ABCDEFGHIJKLMNOPQRSTUVWXYZ';
   
    public ID15to18Converter(){}

   
    public void StartConvert(){
     
                 char15 = '輸入你的15位ID';
                 char18 = '';
                 bin15 = '';
 
                  
                      if(testString.contains(char15.substring(j,j+1))){
                          bin15='1'+bin15;
                      }
                      else{
                          bin15='0'+bin15;
                      }

             
                char18 = char15;
                 char18 += convertBin(bin15.substring(10,15));
                 char18 += convertBin(bin15.substring(5,10));
                 char18 += convertBin(bin15.substring(0,5));

                  //char18 就是你的18位ID 

 

    }
   
    public String convertBin(String s){
   
       String codeResult = '';
       
       Map<String,String> codeKey = new Map<String,String>{
           '00000' => 'A',
           '00001' => 'B',
           '00010' => 'C',
           '00011' => 'D',
           '00100' => 'E',
           '00101' => 'F',
           '00110' => 'G',
           '00111' => 'H',
           '01000' => 'I',
           '01001' => 'J',
           '01010' => 'K',
           '01011' => 'L',
           '01100' => 'M',
           '01101' => 'N',
           '01110' => 'O',
           '01111' => 'P',
           '10000' => 'Q',
           '10001' => 'R',
           '10010' => 'S',
           '10011' => 'T',
           '10100' => 'U',
           '10101' => 'V',
           '10110' => 'W',
           '10111' => 'X',
           '11000' => 'Y',
           '11001' => 'Z',
           '11010' => '0',
           '11011' => '1',
           '11100' => '2',
           '11101' => '3',
           '11110' => '4',
           '11111' => '5'
       };
       
       codeResult =  codeKey.get(s);
       return codeResult;
       
    }

    }

通常我們將 15位ID稱為15位大小寫敏感ID（the 15-character case-sensitive ID），18位ID稱為18位大小寫不敏感ID（the 18-character case-insensitive ID）。

同時, 15位ID與18位ID是一對一的關系，并不會出現一對多的情況。

在 Api Developer Guide中有這樣說法,18位ID為大小寫安全ID（an 18-digit, case-safe version of the ID）。

那么問題來了  什么叫大小寫安全呢？

做DevOps的同學應該對Excel的檢索不區分大小寫深惡痛絕。
由于report等標準UI功能導出的數據ID都是15位，當使用15位ID進行檢索的時候，經常遇見同一個ID匹配到了1個以上的結果的情況。
如果是數據文件是18位ID，并且使用18位ID進行檢索，則可以保證只有1個結果被匹配。
因為18位ID與15位ID是一對一的關系，同一個15位ID生成的18位ID是固定的。
比如，兩個15位ID，0016D000000000A與0016D000000000a，除了大小寫以外是一樣的，18位ID的后三位會根據15位的信息進行拓展，這兩個ID對應的18位ID在無視大小寫的情況下絕對不會相同。比如，0016D000000000AQWE與0016D000000000aASD。
在Excel這種無視大小寫的環境中，18位ID可以確保只能匹配到唯一一條數據，但并不代表18位ID的大小寫可以隨意改動------動了任何一個字母的大小寫，在sfdc中便是另一條數據，甚至壓根不存在。

我們知道，由于SFDC的歷史遺留問題，走UI和畫面的都是15位ID，而數據庫與走后臺的都是18位ID。
URL是大小寫敏感的，所以15位ID在URL HACKING中不會有問題。
而15位ID進入數據庫的ID字段時也會被自動轉換成18位版本。

然而，一些跨越UI與后臺的行為就會存在風險。
比如，在Controller里取得url中的15位ID，
1. 用來與其他的項目拼成聯合key之后放進unique的text字段。通過trigger，batch等后臺渠道取得的ID是18位，可能會導致聯合key的唯一檢查失效。
2. 直接傳給有數據交互的外部系統的WebService。由于ETL等工具通過接口取得的一定是18位ID，將15位ID傳遞過去可能導致查不到數據。
3. 將parent的Id或者其他字段的ID放到text型的公式字段中。這種情況下，從這個公式字段拿到的text值為15位的ID，會有潛在的風險。

如果保持良好的開發習慣，則可以避免此類問題的發生。
1. 在Apex中使用ID類型存放Id。
2. 在Formula中使用CASESAFEID()確保統一使用18位ID。
3. 在使用Excel查找數據時確保使用18位ID，如果只有15位ID，則一定要使用聯合key。

讀到這里，這篇“Salesforce的id長度實例分析”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。