众所周知，Salesforce的Id有15位和18位两种。
18位ID的前15位与15位版本相同。
比如，有一条Account，其URL上的Id为0016F00002Dbbt5。
其中头三位001为Account的prefix（关于prefix，参照《salesforce的prefix和suffix》）
四到六位的6F0为Org Id的第4到6位。由于OrgId的唯一性，所以每个ID在整个SFDC世界都是唯一的。
同样是这条Account，使用工具取得的Id为18位的0016F00002Dbbt5QAB。
前15位与15位版本的ID相同，后3位则是根据前15位计算得来。
插个题外话，Org Id为00D开头的15或18位ID，第四位代表org所属的Instance。
比如说，我的OrgId为00D6F0XXXXXXXXX，那么此org所属的Instance是6对应的AP1。
第四位代码与Instance的对应关系表，请参照《Instance代码对照表》
通过这个对照表，可以轻松的通过Org Id知道其所属的Instance。
包括某些官方文档在内，都将15位ID称为15位大小写敏感ID（the 15-character case-sensitive ID），18位ID称为18位大小写不敏感ID（the 18-character case-insensitive ID）。
那么问题来了，假如18位ID大小写不敏感，那是否就意味着
1. 0016F00002Dbbt5QAB
2. 0016F00002DBBT5QAB （全大写）
3. 0016f00002dbbt5qab （全小写）
代表同一条数据吗？
显然，答案是否定的，2和3作为soql的检索条件进行检索的话，会显示查无此数据。
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规则会使你事半功倍。
海外同步地址：https://wp.me/p3i9xe-ik