Salesforce之18位id与15位id-摩杜云开发者社区

今天,小喵在上班的时候需要做个公式链接,需要将对象的id作为url参数进行传参,听着挺简单的!说干就干,做好后结果却差强人意....

了解Salesforce的都知道一个对象都是有一个15位id和18位id的,小喵根据15位id跳转页面后没获取到数据,而18位的却可以获取到数据,小喵是真的纳闷!同时,这也不是小喵第一次遇见这种情况了.一开始是在写SQL语句的时候,小喵写了一个15位id作为条件查出来却显示的是18位的id.工作中有好几次都是因为id才错的,今天小喵去网上寻找了一些资料,顿时,恍然大悟!

我们都知道 18位id 与 15位id 他们虽然不同,但是18位id的前15位是与15位id相同的.

比如,一个客户,其URL上的id参数为 0011000000VA5ok.

其中头三位001为Account的prefix（关于prefix，参照《salesforce的prefix和suffix》）
四到六位的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;
       
    }

    }

Salesforce之18位id与15位id

通常我们将 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。

Id作为Salesforce云计算架构中重要的一环， <<理解ID>>，正确的运用ID规则会使你事半功倍。