本文小編為大家詳細(xì)介紹“Salesforce的id長度實(shí)例分析”，內(nèi)容詳細(xì)，步驟清晰，細(xì)節(jié)處理妥當(dāng)，希望這篇“Salesforce的id長度實(shí)例分析”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學(xué)習(xí)新知識吧。
為榆陽等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及榆陽網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、榆陽網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！
我們都知道 18位id 與 15位id 他們雖然不同,但是18位id的前15位是與15位id相同的.
比如,一個(gè)客戶,其URL上的id參數(shù)為 0011000000VA5ok.
其中頭三位001為Account的prefix
四到六位的6F0為Org Id的第4到6位。由于OrgId的唯一性，所以每個(gè)ID在整個(gè)SFDC世界都是唯一的。
同樣是這條Account，使用公式取得的Id為18位的 0011000000VA5okAAD.
可以看出18位的Id 前15位與15位版本的Id 相同，后3位則是根據(jù)前15位計(jì)算得來。
在salesforce中所有的記錄ID有兩種長度,15位和18位,如果你知道記錄ID的15位代碼,通過下列代碼你可以將它轉(zhuǎn)換成對應(yīng)的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）。
同時(shí), 15位ID與18位ID是一對一的關(guān)系，并不會出現(xiàn)一對多的情況。
在 Api Developer Guide中有這樣說法,18位ID為大小寫安全I(xiàn)D（an 18-digit, case-safe version of the ID）。
那么問題來了 什么叫大小寫安全呢？
做DevOps的同學(xué)應(yīng)該對Excel的檢索不區(qū)分大小寫深惡痛絕。
由于report等標(biāo)準(zhǔn)UI功能導(dǎo)出的數(shù)據(jù)ID都是15位，當(dāng)使用15位ID進(jìn)行檢索的時(shí)候，經(jīng)常遇見同一個(gè)ID匹配到了1個(gè)以上的結(jié)果的情況。
如果是數(shù)據(jù)文件是18位ID，并且使用18位ID進(jìn)行檢索，則可以保證只有1個(gè)結(jié)果被匹配。
因?yàn)?8位ID與15位ID是一對一的關(guān)系，同一個(gè)15位ID生成的18位ID是固定的。
比如，兩個(gè)15位ID，0016D000000000A與0016D000000000a，除了大小寫以外是一樣的，18位ID的后三位會根據(jù)15位的信息進(jìn)行拓展，這兩個(gè)ID對應(yīng)的18位ID在無視大小寫的情況下絕對不會相同。比如，0016D000000000AQWE與0016D000000000aASD。
在Excel這種無視大小寫的環(huán)境中，18位ID可以確保只能匹配到唯一一條數(shù)據(jù)，但并不代表18位ID的大小寫可以隨意改動(dòng)------動(dòng)了任何一個(gè)字母的大小寫，在sfdc中便是另一條數(shù)據(jù)，甚至壓根不存在。
我們知道，由于SFDC的歷史遺留問題，走UI和畫面的都是15位ID，而數(shù)據(jù)庫與走后臺的都是18位ID。
URL是大小寫敏感的，所以15位ID在URL HACKING中不會有問題。
而15位ID進(jìn)入數(shù)據(jù)庫的ID字段時(shí)也會被自動(dòng)轉(zhuǎn)換成18位版本。
然而，一些跨越UI與后臺的行為就會存在風(fēng)險(xiǎn)。
比如，在Controller里取得url中的15位ID，
1. 用來與其他的項(xiàng)目拼成聯(lián)合key之后放進(jìn)unique的text字段。通過trigger，batch等后臺渠道取得的ID是18位，可能會導(dǎo)致聯(lián)合key的唯一檢查失效。
2. 直接傳給有數(shù)據(jù)交互的外部系統(tǒng)的WebService。由于ETL等工具通過接口取得的一定是18位ID，將15位ID傳遞過去可能導(dǎo)致查不到數(shù)據(jù)。
3. 將parent的Id或者其他字段的ID放到text型的公式字段中。這種情況下，從這個(gè)公式字段拿到的text值為15位的ID，會有潛在的風(fēng)險(xiǎn)。
如果保持良好的開發(fā)習(xí)慣，則可以避免此類問題的發(fā)生。
1. 在Apex中使用ID類型存放Id。
2. 在Formula中使用CASESAFEID()確保統(tǒng)一使用18位ID。
3. 在使用Excel查找數(shù)據(jù)時(shí)確保使用18位ID，如果只有15位ID，則一定要使用聯(lián)合key。
讀到這里，這篇“Salesforce的id長度實(shí)例分析”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識點(diǎn)還需要大家自己動(dòng)手實(shí)踐使用過才能領(lǐng)會，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
