今天,小喵在上班的时候需要做个公式链接,需要将对象的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;
}
}
通常我们将 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规则会使你事半功倍。
