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