共计 2790 个字符，预计需要花费 7 分钟才能阅读完成。
本文丸趣 TV 小编为大家详细介绍“Salesforce 的 id 长度实例分析”，内容详细，步骤清晰，细节处理妥当，希望这篇“Salesforce 的 id 长度实例分析”文章能帮助大家解决疑惑，下面跟着丸趣 TV 小编的思路慢慢深入，一起来学习新知识吧。
我们都知道 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 长度实例分析”文章已经介绍完毕，想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会，如果想了解更多相关内容的文章，欢迎关注丸趣 TV 行业资讯频道。
