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 codeKey = new Map{ '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长度实例分析"文章已经介绍完毕，想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会，如果想了解更多相关内容的文章，欢迎关注行业资讯频道。
