Shulou(Shulou.com)05/31 Report--

In this article, the editor introduces in detail the "case analysis of id length of Salesforce", with detailed contents, clear steps and proper handling of details. I hope that this article "case analysis of id length of Salesforce" can help you solve your doubts.

We all know that 18-bit id is different from 15-bit id, but the first 15 bits of 18-bit id are the same as 15-bit id.

For example, a customer whose id parameter on URL is 0011000000VA5ok.

The first three digits 001 are prefix of Account

The 6F0 of four to six is the fourth to sixth of Org Id. Because of the uniqueness of OrgId, each ID is unique in the entire SFDC world.

The same Account, using the formula to obtain the Id of 18-bit 0011000000VA5okAAD.

It can be seen that the first 15 bits of the 18-bit Id are the same as the 15-bit version of Id, and the last 3 bits are calculated based on the first 15 bits.

All record ID in salesforce has two lengths, 15-bit and 18-bit. If you know the 15-bit code for recording ID, you can convert it to the corresponding 18-bit ID through the following code.

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 =' enter your 15-bit ID'; char18 ='; bin15 ='' If (testString.contains (char15.substring (jjjinger 1)) {bin15='1'+bin15;} else {bin15='0'+bin15;} char18 = char15 Char18 + = convertBin (bin15.substring (10Magne 15)); char18 + = convertBin (bin15.substring (5je 10)); char18 + = convertBin (bin15.substring (0Power5)); / / char18 is your 18-bit ID} public String convertBin (String's) {String codeResult ='' Map codeKey = new Map {'00000' = >' A', '00001' = > 'Bamboo,' 00010'= >'C', '00011' = > 'Dust,' 00100'= > 'Egg,' 00101'= > 'Fitch,' 00110'= > 'Globe,' 00111'= >'H' '01000' = > 'Ifat', '01001' = > 'Juan,' 01010'= > 'Kraft,' 01011'= > 'Lemma,' 01100'= >'M', '01101' = > 'Nice,' 01110'= > 'Orange,' 01111'= > 'Please,' 10000' = >'Q' '10001' = > 'Renewal,' 10010' = > 'Sparks,' 10011' = > 'Tails,' 10100' = > 'Utility,' 10101'= > 'Vince,' 10110' = > 'Wells,' 10111' = >'X', '11000' = >' Y', '11001' = >' Z' '11010' = > '013', '11011' = >'1', '11100' = >'2', '11101' = >'3', '11110' = >'4', '11111' = >'5'} CodeResult = codeKey.get (s); return codeResult;}}

Generally, 15-bit ID is called 15-bit case-sensitive ID (the 15-character case-sensitive ID), and 18-bit ID is called 18-bit case-insensitive ID (the 18-character case-insensitive ID).

At the same time, there is an one-to-one relationship between 15-bit ID and 18-bit ID, and there is no one-to-many situation.

There is a saying in Api Developer Guide that 18-bit ID is a case-safe ID (an 18-digit, case-safe version of the ID).

So the question is, what is case security?

Students who do DevOps should hate the case-insensitive retrieval of Excel.

Because the data ID exported by standard UI functions such as report are all 15 bits, when using 15-bit ID for retrieval, we often encounter the situation that the same ID matches more than one result.

If the data file is 18-bit ID and 18-bit ID is used for retrieval, only 1 result can be guaranteed to be matched.

Because the 18-bit ID has an one-to-one relationship with the 15-bit ID, the 18-bit ID generated by the same 15-bit ID is fixed.

For example, two 15-bit ID,0016D000000000A and 0016D000000000a are the same except case. The last three digits of the 18-bit ID will be expanded based on the 15-bit information. The 18-bit ID corresponding to the two ID will never be the same regardless of case. For example, 0016D000000000AQWE and 0016D000000000aASD.

In a case-insensitive environment like Excel, 18-bit ID ensures that only one piece of data can be matched, but it doesn't mean that the case of 18-bit ID can be changed at will-if you change the case of any letter, it is another piece of data in sfdc, or even doesn't exist at all.

We know that due to the historical problems of SFDC, both the UI and the screen are 15-bit ID, while the database and backstage are 18-bit ID.

URL is case-sensitive, so 15-bit ID will not be a problem in URL HACKING.

The 15-bit ID is automatically converted to the 18-bit version when it enters the ID field of the database.

However, some behaviors that span UI and backend are risky.

For example, get the 15-bit ID in url in Controller

1. It is used to form a federated key with other projects and put it into the text field of unique. The ID obtained through background channels such as trigger,batch is 18 bits, which may invalidate the only check of the federated key.

two。 A WebService that is passed directly to an external system that has data interaction. Because tools such as ETL must get 18-bit ID through the interface, passing 15-bit ID may result in no data to be found.

3. Put the Id of parent or the ID of other fields into the formula field of text type. In this case, it is potentially risky to get an ID with a text value of 15 bits from this formula field.

If you maintain good development habits, you can avoid such problems.

1. Use the ID type to store the Id in Apex.

two。 Using CASESAFEID () in Formula ensures that 18-bit ID is used uniformly.

3. Be sure to use 18-bit ID when using Excel to find data, and if there is only 15-bit ID, be sure to use federated key.

After reading this, the article "id length example Analysis of Salesforce" has been introduced. If you want to master the knowledge points of this article, you still need to practice and use it yourself to understand it. If you want to know more about related articles, welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.