SIM Phone book

最近在学习SIM Phonebook，有一些心得，也有一些思考，分享出来，希望对大家有些帮助。
了解SIM卡存储contact的一些限制，对于了解SIM phone book spec有很大的帮助。SIM卡的特点：小，慢，通用。存储内存小，读取速度慢，并且SIM卡存储和读取要有通用性，在不同设备上都能正常工作。
Phonebook的基本内容如下表，包含name，number，Email等（下面只是例子）。

从APP或者上层来看，存储phone book最简单的方法就是按照结构体存储，这样APP处理最快最方便，SIM也按照这种方式存储，这样的话APP和SIM driver进行交流就非常简单了。
typedef struct {
char *name;
char *number;
char *email;
char * additional_number;
char *additional_number_alpha_string;
} Phone_Book
但是受限于SIM的特性，存储比较小，在有限的存储空间下要存储更多的内容，要更快的读取和更新，另外要有通用性。SIM卡随着时代的发展，内容会发生变化，会增加一些项，并且每个项的长度不同卡可能不同，如果使用结构体不能满足这些要求，如果动态分配，可能会出现碎片化，如果静态分配的话，固定长度，那么通用性会比较差，长度定的太长，那么势必浪费存储空间。所以SIM使用结构体不是上选（上面纯属瞎想）。那就选择列存储，每一列存储一个phone book的项。当然选择列存储也是SIM的必然选择，因为SIM的其他内容也都是这种存储方式。

我们看一下header的内容，首先要给文件起一个名字，也就是Identifier(FID)。这个标识了存储的类型，存储的到底是什么。

我们先阐明一下SIM文件存储的类型，基本文件Elementary Files在SIM卡有三种方式：Transparent EF，Linear fixed EF，Cyclic EF。



由于phonebook都是Liner fixed EF，Linear fixed EF ：The max record number is 254，the record max length is 255 bytes。
Header 结构体中也需要记录文件的类型，每一个record的长度。SIM卡本身还有一些权限的问题，也就是PIN，PIN2，PUK等，某些文件需要特点的权限才能存储和读取，header也需要记录Access，还有一项SFI（short file identifier），这一项在后面还会介绍到。

那说完header，我们继续看一下record（body）的内容，每一项的存储内容都有SPEC详细说明，包括每一个字节存储什么内容。
我们先拿phonebook最主要的文件ADN作为例子进行说明，ADN存储了number和name，如下，其中有一项是EF_EXT1这项也是存储number，是当number太长的时候，ADN存储不下的时候，会使用EF_EXT1进行存储，ADN中存储的是EF_EXT1中的index值，也就是在EF_EXT1中是第几个。

具体可参看下面的spec（下面的SPEC是3GPP的，和3GPP2的区别在于Identifier，在这里是固定值6F3A）
EF_ADN (Abbreviated dialling numbers)

ADN是主文件，其他文件都直接或间接的于ADN发生关系，根据与AND的关系，其他files可以分成下面几类。
▪ Type 1：与EF_ADN个数相同，并一一对应。Example：EF_IAP。
▪ Type 2：比EF_ADN个数少或相等，EF_IAP是其引用。
▪ Type 3：比EF_ADN个数少或相等，Type 1 （除EF_IAP）是其引用。

如果不理解的话，可以参看下面的示意图，其中的file文件如果不清楚存储内容，可以查一下spec。
下面的图是不含有EF_IAP的结构示意图。

下面是含有EF_IAP的示意图。

在继续讲之前，我们先要弄清SIM file的组织结构。SIM file我们可以参考Windows，文件放在文件夹下面，文件夹下面可以有文件，也可以继续有文件夹，是一种层次结构。一个文件可以通过文件夹路径查询到。

对于SIM phonebook来说，文件类型比较多，需要一个特殊的文件来描述sim phonebook，到底有哪些文件。而EF_PBR就是来做这件事情的，有了这样的文件，上层APP就很容易了解到当前SIM卡phonebook的状态和内容了。PBR存储就是TLV（Tag，length，value）。下面是PBR的Spec.

其中Tag的值分成两部分，A8,A9,AA描述了EF file的type，可以往前查一下。

下面这部分描述了file的种类，也就是当前file是什么类型的。

我们给出一个PBR的例子，可以自行解析一下。

文件的类型结构和组织方式介绍完了，下面介绍一下APDU，就是如何和SIM进行交互，读取SIM中的内容。
基本格式如下：

• Application protocol data unit (APDU)
• CLA is the class of instruction, ‘A0’ is used in the GSM application, ‘00’ is used in the telecom application.
• INS is the instruction code
• P1, P2, P3 are parameters for the instruction
▪ P3: the length of the data,
• ‘00’: no data transfer to SIM
• ‘00’: 256 bytes data transfer from the SIM
• SW1 and SW2 are the status words indicating the successful or unsuccessful outcome of the command.
大家如果不太理解APDU的每个元素没有关系，我们针对读取phone book会详细说明。
下面是GSM SIM的APDU内容，黄色部分是读取phone book需要用到的，每个部分的意思都有详细说明。

下面是telecom SIM卡的APDU，CLA和GSM有些不同而已。

下面的例子大部分都是Telecom的。
这是对select每一项的解释，select动作类似于通过文件路径查找到文件，只有找到文件，才能对文件进行操作。

Select文件后，一般都需要紧跟一个Get Response的指令。我们有必要讲一下Get response的返回结果的内容。下面是整个response data的宏观结构，就是一个描述FCP和FCP内容的宏观结构
（File Control Parameter），就是Tag, length，后面是FCP的内容。

下面介绍的是FCP的内容，有Tag进行标识

下面是一些重要的项的解释



我们看一个具体的例子。可以根据spec解析一下里面的内容。
// Select - EF_FDN (Fixed Dialing Numbers)
CMD 00 A4 08 04 04
7F FF 6F 3B // DF_ADF = ‘7F FF’ EF_FDN = ‘6F 3B’
// Get Response request, 32 bytes available
RSP 61 20（这是select的返回值，61代表select后要紧跟一个get response的command，20代表get response这个command需要读取的data的长度）
// Get Response - 32d bytes
CMD 00 C0 00 00 20
// Normal Ending Of The Command // file size = FF = 255
RSP 62 1E 82 05 42 21 00 FF FE 83 02 6F 3B A5 03 80 // total file size = FD00 + 02 = 64770
01 31 8A 01 05 8B 03 6F 06 07 80 02 FD 02 88 00 // number record = total file size/ file size = 254
90 00

下面介绍一下read record.

下面以EF_FDN（Fixed dialing number）为例进行讲解，结构和EF_ADN是一样的。

// Read Record - record = 252d
// FC = 252，代表读取第252的record，04是mode，FF是读取的长度
CMD 00 B2 FC 04 FF
// Normal Ending Of The Command
RSP 54 45 53 54 20 4E 4F 2E 31 FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF 03 91 21 F3 FF FF FF FF FF FF FF FF FF FF （03 91 21 F3，BCD编码）
90 00

基本内容就讲完了，下面简单说一下APP或者上层读取SIM phonebook的基本流程如下。
▪ Read PBR
• 1 Get Response
• 2 Read Record
• 3 Create PBR file
▪ Read ADN
• 1 through PBR files to get ADN file ID
• 2 Get Response
• 3 from response to compute the number of ADN
• 4 read ADN （一个一个的读取，直到读取结束）
• 5 parse ADN
▪ Read Email
• 0 Get Email type from PBR files
• 1 through Email type to judge if read IAP file
• 2 Get Response
• 3 from response to compute the number of EMAIL
• 4 read EMAIL（一个一个的读取，直到读取结束）
• 5 parse EMAIL
• 6 build type1 Email or build type2 Email according to IAP

为了最大存储内容，SIM有一些优化的部分，例如phone number就是通过BCD编码进行存储，一个字节就可以存储两个number，18510912180在SIM卡中的存储是8115902181f0，下面是基本的解析例子，一个基本就明白了，就是对number的ASCII码减去30，之后每四位存储一个数，解析的时候反操作就可以了。

                      18510912180
            Asci: 31 38 35 31 30 39 31 32 31 38 30
       Asci- 30:   1   8    5    1   0   9   1   2    1   8   0

BCD number: 8 1 1 5 9 0 2 1 8 1 f 0

如果name或email只包含ASCII码，那就可以用ASCII码编码。如果包含Unicode，那就需要判断是采用80,81还是82编码了，可以参考这篇文章，写得不错。https://blog.csdn.net/linuxweiyh/article/details/51434984
文章写的有些急，要想精通还是要看spec，进行实践，这篇文章只是简单介绍，希望对入门有些许帮助。