UDS诊断服务SID详解UDS
本文最后更新于16 天前,其中的信息可能已经过时,如有错误请留言评论。

UDS诊断服务SID详解

0x10诊断会话控制

诊断会话控制服务在ECU中用于切换至不同的诊断会话,对应的SID为0x10。通常包含3个子功能:01 Default(默认会话),02 Programming(编程会话),03 Extended(扩展会话),ECU上电时,进入的是01默认会话。这三个子功能可以相互跳转,当然也可根据实际需求设定这些功能的跳转关系。通常,默认会话模式可以直接切换到扩展会话模式,但是不能直接切换到编程会话模式,如果想进入编程会话模式, 则必须先进入扩展会话模式。同样,编程会话模式不能直接进入扩展会话模式,只能进入默认会话模式。

当进入到一个非默认会话时,一个定时器会开始运转,一段时间内没有收到任何请求,一旦时间达到,诊断会退回到默认会话01。当然,可以用3E服务,使诊断一直保持在非默认会话。

诊断会话控制服务CAN报文示例(使用0x55填充无用字节):

0x02 10 01 55 55 55 55 55 #诊断仪请求ECU跳转到默认会话
0x02 10 02 55 55 55 55 55 #诊断仪请求ECU跳转到编程会话
0x02 10 03 55 55 55 55 55 #诊断仪请求ECU跳转到扩展会话
0x06 50 01 00 32 01 F4 55 #ECU肯定响应,ECU跳转到默认会话
0x03 7F 10 12 55 55 55 55 #ECU否定响应,不支持当前子功能

ECU肯定响应时,需要两个参数P2(ECU响应最大时间,两个字节,比如上述肯定响应报文中的00 32,单位ms)与P2*(ECU发送0x78否定响应码之后再次发响应的最大时间,两个字节,比如上述肯定响应报文中的01 F4,单位10ms)。因为0x10是最基础的服务,所有支持UDS的ECU均需要支持,因此通常不会有否定响应。

0x11复位ECU

诊断仪通过该诊断服务命令ECU复位。ECU应先发送肯定响应报文,再执行复位,ECU复位成功后,进入默认会话。

ECU复位服务也有几个常用子功能:

  • 01 HardReset(硬复位,等同ECU断电,ECU的易失性存储器和非易失性存储器数据可能被重新初始化为默认值)。
  • 02 KeyOffOnReset(下电复位,等同车辆熄火,通常会保留非易失性存储器位置的数据,易失性存储器数据被初始化为默认值)。
  • 03 SoftReset(软件复位,软件功能回到默认状态,不影响数据)。
  • 04 EnableRapidPowerShutDown (快速下电使能,让ECU进入休眠)。

ECU复位服务CAN报文示例:

0x02 11 01 55 55 55 55 55 #诊断仪请求ECU硬件复位
0x02 11 03 55 55 55 55 55 #诊断仪请求ECU软件复位
0x02 51 01 55 55 55 55 55 #ECU肯定响应,ECU硬件复位
0x02 51 03 55 55 55 55 55 #ECU肯定响应,ECU软件复位
0x03 7F 11 12 55 55 55 55 #ECU否定响应,不支持当前子功能

ECU肯定响应时,不需要额外的参数。因为0x11是最基础的服务,所有支持UDS的ECU均需要支持,但是并不是每个ECU都支持所有的复位子功能。当ECU不支持某种复位子功能时,ECU有否定响应不支持当前请求的复位子功能。

0x27安全访问

车上有很多独有的数据存放在ECU内部,不希望随便被读写;或者一些诊断服务,需要进行安全校验,在Unlocked后才能访问,ECU默认情况下是Locked状态。一般情况下,重启或者重新返回到Default Session都会重新恢复到Locked状态,需要再次Unlocked之后才能进行相应的访问。

完成SecurityAccess安全访问步骤如下:

  1. 诊断仪向ECU请求种子(通常使用1、3、5、7子功能)。
  2. ECU向诊断仪发送种子。
  3. 诊断仪根据种子及与ECU内部相同的算法算出“Key1”,并发送给ECU(通常使用2、4、6、8子功能)。
  4. ECU校验诊断仪发来的“Key1”是否有效(ECU也通过相同的Seed和算法计算出Key2,然后比较Key1和Key2的一致性,如果一致则Unlocked)。

安全访问服务CAN报文示例:

0x02 27 01 55 55 55 55 55 #诊断仪请求ECU发送种子
0x06 67 01 BB BB BB BB 55 #ECU肯定响应,ECU发送种子
0x06 27 02 CC CC CC CC 55 #诊断仪发送密钥Key1
0x06 67 02 55 55 55 55 55 #ECU肯定响应,ECU解锁
0x03 7F 27 35 55 55 55 55 #ECU否定响应,密钥不匹配

否定响应码0x35、0x36与0x37是安全访问服务特有的,其中0x35为基础功能,通常ECU均需要实现,而0x36与0x37则取决于具体ECU的实现情况。

0x28通信控制

通信控制服务是控制某类通信关闭/开启接收或者发送。当UDS需要下载升级或者传输大量数据时需要将CAN总线资源让出来,提高传输效率,这时通过0x28服务关闭某类的通信发送报文到CAN总线上,待下载升级或传输数据完成后再通过0x28服务将通信开启即可。

通信控制服务中两个最常用的子功能:00开启通信,03禁止收发。

通信控制服务中的参数为报文类型,通常使用01常规应用报文。

通信控制服务CAN报文示例:

0x03 28 00 01 55 55 55 55 #诊断仪请求ECU开启通信
0x03 28 03 01 55 55 55 55 #诊断仪请求ECU禁止通信
0x02 68 00 55 55 55 55 55 #ECU肯定响应,ECU开启通信
0x02 68 03 55 55 55 55 55 #ECU肯定响应,ECU停止通信
0x03 7F 28 12 55 55 55 55 #ECU否定响应,不支持当前子功能

ECU否定响应时,有可能是会话模式导致的,因为只有扩展会话模式才支持0x28服务,当ECU处于其它会话模式时,控制器可能发否定响应0x03 7F 28 7E,表示当前会话不支持当前请求的子功能。

0x3E待机握手

待机握手服务是告知ECU与诊断仪正连接着,用于保持ECU当前诊断会话(诊断仪一般在ECU处于非Default Session模式下发送0x3E至ECU)。正常情况下,ECU超过一定的时间收不到诊断命令,ECU会退出非Default Session模式,而使用0x3E服务可避免这个问题。

待机握手的两个子功能:00需要响应,80不需要响应。因为子功能80不需要响应通常使用抑制肯定响应来实现,所有ECU往往不需要实现子功能80。

待机握手服务CAN报文示例:

0x02 3E 00 55 55 55 55 55 #诊断仪请求ECU保持当前会话,并要求ECU响应
0x02 3E 80 55 55 55 55 55 #诊断仪请求ECU保持当前会话,但不需要ECU响应
0x02 7E 00 55 55 55 55 55 #ECU肯定响应,ECU保持当前会话
0x03 7F 3E 12 55 55 55 55 #ECU否定响应,不支持当前子功能

0x85控制DTC设置

控制DTC设置服务用于控制ECU的DTC存储,这个服务常常和前面提到的0x28服务一起使用,比如,在开始写参数之前,为了获得更快的传输速度,我们用0x28服务把所有ECU的通信关闭了,但此时因为收到不到相关的报文,ECU会没有必要地存储很多DTC,这时如果使用0x85服务把ECU存储DTC的功能暂时性地禁止掉,则不会造成这种麻烦。

控制DTC设置服务的两个子功能:01开启DTC记录,02关闭DTC记录。

控制DTC设置服务CAN报文示例:

0x02 85 01 55 55 55 55 55 #诊断仪请求ECU开启DTC记录
0x02 85 02 55 55 55 55 55 #诊断仪请求ECU关闭DTC记录
0x02 C5 01 55 55 55 55 55 #ECU肯定响应,ECU开启DTC记录
0x02 C5 02 55 55 55 55 55 #ECU肯定响应,ECU关闭DTC记录
0x03 7F 85 12 55 55 55 55 #ECU否定响应,不支持当前子功能

ECU否定响应时,有可能是会话模式导致的,因为只有扩展会话模式才支持0x85服务,当ECU处于其它会话模式时,控制器可能发否定响应0x03 7F 85 7E,表示当前会话不支持当前请求的子功能。

0x22通过ID读数据

通过ID读数据中的ID指的是Data Identifier数据标识符,简称DID,DID长度为2个字节。诊断仪一次可以请求读取多个DID,ECU将相同个数的DID数据发给诊断仪。但是常用的方式是一次请求读取一个DID数据。

DID有一部分已经被ISO 14229-1规定好了,已经规定好的常用DID见下表:

DID(0x)Description说明
F180bootSoftwareIdentificationDataIdentifierBOOT软件ID数据ID
F181applicationSoftwareIdentificationDataIdentifier应用软件ID数据ID
F182applicationDataIdentificationDataIdentifier应用数据ID数据ID
F183bootSoftwareFingerprintDataIdentifierBOOT软件指纹数据ID
F184applicationSoftwareFingerprintDataIdentifier应用软件指纹数据ID
F185applicationDataFingerprintDataIdentifier应用数据指纹数据ID
F186ActiveDiagnosticSessionDataIdentifier当前诊断会话数据ID
F187vehicleManufacturer SparePartNumberDataIdentifier主机厂车辆备件数据ID
F188vehicleManufacturer ECUSoftwareNumberDataIdentifier主机厂车辆ECU软件编号数据ID
F189vehicleManufacturer ECUSoftwareVersionNumberDataIdentifier主机厂车辆ECU软件版本编号数据ID
F18AsystemSupplierIdentificationDataIdentifier系统供应商ID数据ID
F18BECUManufacturingDateDataIdentifierECU制造日期数据ID
F18CECUSerialNumberDataIdentifierECU序列号数据ID
F190VINDataIdentifierVIN数据ID
F191vehicleManufacturer ECUHardwareNumberDataIdentifier主机厂ECU硬件编号数据ID
F192systemSupplier ECUHardwareNumberDataIdentifier系统供应商ECU硬件编号数据ID
F193systemSupplier ECUHardwareVersionNumberDataIdentifier系统供应商ECU硬件版本编号数据ID
F194systemSupplier ECUSoftwareNumberDataIdentifier系统供应商ECU软件编号数据ID
F195systemSupplier ECUSoftwareVersionNumberDataIdentifier系统供应商ECU软件版本编号数据ID

通过ID读数据通常不需要使用子功能,使用SID+DID即可发请求。

通过ID读数据服务CAN报文示例:

0x03 22 F1 86 55 55 55 55 #诊断仪请求ECU读取当前诊断会话ID
0x04 62 F1 86 01 55 55 55 #ECU肯定响应,ECU发当前诊断会话ID为01
0x03 7F 22 31 55 55 55 55 #ECU否定响应,请求参数超出范围/数据ID不支持

0x2E通过ID写数据

0x2E的ID与0x22类似,是用来写入数据到ECU。比如车辆下线时,ECU都需要写入VIN号来与车进行绑定。

对于写数据的请求,一般是需要Unlock情况下才能进行,所以在写入DID之前,需要用0x10来进行会话模式转换。

通过ID写数据没有子功能,使用SID+DID即可发请求。

通过ID写数据服务CAN报文示例:

0x10 14 2E F1 90 01 02 03 #诊断仪请求ECU写VIN
0x21 04 05 06 07 08 09 0A #连续帧
0x22 0B 0C 0D 0E 0F 10 11 #连续帧
0x03 6E F1 90 55 55 55 55 #ECU肯定响应,VIN已经写入
0x03 7F 2E 31 55 55 55 55 #ECU否定响应,请求参数超出范围/数据ID不支持

ECU否定响应时,有可能是访问权限导致的,因为ECU只有在安全状态为解锁状态下才支持0x2E服务,当ECU处于未解锁状态时,控制器可能发否定响应0x03 7F 2E 33,表示安全访问拒绝,需要先解锁ECU。

0x14清除诊断信息

客户端通过0x14清除诊断信息服务来请求清除ECU中存储的诊断信息。当ECU完全处理0x14服务后,ECU应发送肯定响应;即使ECU没有存储DTC内容,也应回复肯定响应。

除非另有说明,否则ECU应清除排放与非排放相关的所有DTC。

清除诊断信息没有子功能,使用SID+DTC组编号即可,DTC组编号的长度为3个字节,当DTC组编号为0xFFFFFF时为请求清除ECU中存储的所有诊断信息。

清除诊断信息服务CAN报文示例:

0x04 14 FF FF FF 55 55 55 #诊断仪请求ECU清除ECU中存储的所有诊断信息
0x01 54 55 55 55 55 55 55 #ECU肯定响应,ECU清除ECU中存储的所有诊断信息
0x03 7F 14 31 55 55 55 55 #ECU否定响应,请求参数超出范围/数据ID不支持

0x19读取DTC信息

如果系统检测到了一个错误,它将存储为DTC。DTC可表现为:电气线路的故障、通信信号的丢失、排放相关的故障或安全相关的故障等。DTC可以表征错误的位置和错误类型。

读取DTC信息服务常用的子服务有:

  • 01 (读取符合掩码条件的DTC数量),后面的参数是DTC状态掩码,若为01表示想读当前故障,若为08表示想读历史故障,若为09表示当前故障和历史故障都想读。
  • 02(读取符合掩码条件的DTC列表及其状态),后面的参数是DTC状态掩码,解读同上。
  • 04(根据DTC编号读取快照信息),也叫冻结帧。
  • 06(根据DTC编号读取扩展信息)。
  • 0A(读取ECU支持的所有DTC列表及其状态)。

读取DTC信息服务01子功能CAN报文示例:

0x03 19 01 09 55 55 55 55 #诊断仪请求ECU读取DTC数量,包括当前故障和历史故障
0x06 59 01 09 01 00 02 55 #ECU肯定响应,ECU符合要求的DTC有两个
0x03 7F 19 12 55 55 55 55 #ECU否定响应,不支持当前子功能

ECU肯定响应时,参数一共4个字节,第一个字节为DTC状态掩码,第二个字节参数为0时代表DTC为ISO15031-6格式,为1时代表DTC为ISO14229格式。DTC数量的长度为2个字节。

读取DTC信息服务02子功能CAN报文示例:

0x03 19 02 09 55 55 55 55 #诊断仪请求ECU读取DTC列表,包括当前故障和历史故障
0x07 59 02 09 C1 23 45 01 #ECU肯定响应,ECU报告DTC故障码与状态
0x03 7F 19 12 55 55 55 55 #ECU否定响应,不支持当前子功能

ECU肯定响应时,参数一共5个字节,第一个字节为DTC状态掩码,后续3个字节为DTC故障码,最后1个字节为故障状态,故障状态由8个位组合起来表示。其中最常用的0x01表征当前故障正在发生,08表征当前故障至少发生过一次,0F表征当前故障至少发生过两次并且故障正在发生,0E表征当前故障至少发生过两次但是当前没有发生。

如果DTC有多个的话,每个DTC占据4个字节(3字节DTC故障码+1字节故障状态),ECU需要使用多帧报文才能将多个DTC发给诊断仪,这时候需要使用首帧与连续帧。

读取DTC信息服务04子功能CAN报文示例:

0x06 19 04 C1 23 45 01 55 #诊断仪请求ECU读取故障码C12345的快照信息即冻结帧
0x10 0F 59 04 C1 23 45 08 #ECU肯定响应,ECU报告故障码C12345的快照信息即冻结帧
0x21 01 02 D1 D2 B1 B2 D3 #ECU肯定响应,快照编号01,快照编号的ID个数是2
0x22 D3 B3 55 55 55 55 55 #ECU肯定响应,DTC ID 是D1D2(数据为B1B2)、D3D4(数据为B3)
0x03 7F 19 12 55 55 55 55 #ECU否定响应,不支持当前子功能

诊断仪请求ECU读取故障码的快照信息即冻结帧时,参数一共4个字节,前3个字节为故障码,最后1个字节为01时代表读取该DTC快照编号为1的快照信息,为FF时代表读取该DTC的所有快照信息,通常都使用01读取DTC的快照信息(读取DTC的所有快照信息过于复杂易出错)。

ECU肯定响应时,参数前4个字节为DTC故障码+0x08(故障状态,可能为其它数据,比如0x01或者0x0F),第5个字节固定为01,第6个字节为快照编号的ID个数,之后的参数为第1个ID+数据,第2个ID+数据等等。ECU需要使用多帧报文才能将DTC快照信息发给诊断仪,这时候需要使用首帧与连续帧。

0x2F通过ID控制IO

通过ID控制IO服务可以通过DID(数据标识符)来进行输入信号的替换和控制零部件负载输出。这是一个用在产线上较多的服务。该报文的请求至少由4个字节组成。第一个字节是2F,第二第三字节是DID。第四字节是Input Output Control Parameter(并不算一个子功能,0x2F服务没有子功能),可以看做IO控制类型。

IO控制类型分为4类:

  • 00是控制权还给ECU,Return Control To ECU(常用)。
  • 01是复位为默认值,Reset to Default(不常用)。
  • 02是冻结当前的状态,Freeze Current State(不常用)。
  • 03是短暂接管控制权,Short Term Adjustment(常用)。

若控制类型是00-02这三种,请求报文是4个字节,其中00较为常用,01与02不常用。

若控制类型是03,请求报文的第五字节是控制代码,可以是数字量,比如01是开,00是关;也可以是模拟量,比如空调风门的开度。

通过ID控制IO服务CAN报文示例:

0x04 2F D1 D2 00 55 55 55 #诊断仪请求ECU控制D1D2代表的IO
0x05 6F D1 D2 00 02 55 55 #ECU肯定响应,ECU控制D1D2代表的IO,当前为2
0x05 2F D1 D2 03 01 55 55 #诊断仪请求接管D1D2代表的IO并开启
0x05 2F D1 D2 03 00 55 55 #诊断仪请求接管D1D2代表的IO并关闭
0x05 6F D1 D2 03 00 55 55 #ECU肯定响应,诊断仪控制D1D2代表的IO,当前关闭
0x03 7F 2F 31 55 55 55 55 #ECU否定响应,请求参数超出范围/数据ID不支持

ECU肯定响应时,参数通常为4个字节,前两个字节为IOID,第3个字节为IO控制类型(常见为00或者03,取决于诊断仪请求的值),第4个字节为IO的状态,状态字节的值与状态之间的对应关系由用户自行定义。需要注意的是,当IO控制类型发生变化时,ECU肯定响应返回的IO状态可能会延迟一个任务周期更新,因此一般需要间隔一段时间(比如100ms)后再次发送相同请求才能获取最新的IO状态。

ECU否定响应时,有可能是会话模式导致的,因为只有扩展会话模式才支持0x2F服务,当控制器处于其它会话模式时,控制器可能发否定响应0x03 7F 2F 7F,表示当前会话不支持当前请求的服务,需要先将会话模式切换到扩展会话模式。

ECU否定响应时,有可能是访问权限导致的,因为ECU只有在安全状态为解锁状态下才支持0x2F服务,当ECU处于未解锁状态时,控制器可能发否定响应0x03 7F 2F 33,表示安全访问拒绝,需要先解锁ECU。

0x31例行程序控制

例行程序控制服务可以通过RID(程序标识符)来进行例行程序的控制,通常用于例行程序的开启与关闭,RID与DID类似,长度为2个字节。

例行程序控制服务常用2个子功能:01开启程序,02关闭程序,03请求例行程序控制结果。

例行程序控制服务CAN报文示例:

0x04 31 01 FF 01 55 55 55 #诊断仪请求ECU开启FF01代表的程序
0x05 71 01 FF 01 01 55 55 #ECU肯定响应,ECU开启FF01代表的程序
0x03 7F 31 12 55 55 55 55 #ECU否定响应,不支持当前子功能
0x04 31 03 FF 01 55 55 55 #诊断仪请求FF01代表的例行程序控制结果
0x05 71 03 FF 01 00 55 55 #ECU肯定响应,ECU返回FF01代表的例行程序控制结果

ECU肯定响应时,参数通常为3个字节,前两个字节为RID,第3个字节为例行程序的最新状态,状态字节的值与状态之间的对应关系由用户自行定义。UDS允许使用多个字节来描述例行程序的最新状态,此时肯定响应的参数大于3个字节,但是这种方式并不常用。

ECU否定响应时,有可能是会话模式导致的,因为只有扩展会话模式才支持0x31服务,当控制器处于其它会话模式时,控制器可能发否定响应0x03 7F 31 7E,表示当前会话不支持当前请求的子功能,需要先将会话模式切换到扩展会话模式。

ECU否定响应时,有可能是访问权限导致的,因为ECU只有在安全状态为解锁状态下才支持0x31服务,当ECU处于未解锁状态时,控制器可能发否定响应0x03 7F 31 33,表示安全访问拒绝,需要先解锁ECU。

0x34请求下载

请求下载服务主要在启动下载传输前启用,作用是提醒ECU准备接收数据,ECU则通过0x74 Response告诉诊断仪自己是否允许传输,以及自己的接受能力是多大。这个服务主要是用来给ECU下载数据的,最常见的应用就是在Bootloader中,程序下载工具会发起下载请求,以完成ECU程序的升级。

请求下载服务没有子功能。

请求下载服务CAN报文示例:

0x10 0B 34 00 44 A1 A2 A3 #诊断仪请求ECU下载
0x21 A4 00 00 00 2F 55 55 #下载的地址为A1A2A3A4,下载的大小为2F
0x04 74 20 FF FF 55 55 55 #ECU肯定响应,块最大为FFFF个字节
0x03 7F 34 31 55 55 55 55 #ECU否定响应,请求参数超出范围/数据ID不支持

请求下载服务SID后通常使用10个字节的参数,第1个字节通常使用0x00,第2个字节通常使用0x44,后续4个字节代表下载的地址,最后4个字节代表下载的数据块大小。

ECU肯定响应时,参数一共3个字节,第1个字节通常使用0x20,后续两个字节代表数据块大小的最大值。

ECU否定响应时,否定响应码除了0x31之外还可使用0x70(不允许上传/下载)。

ECU否定响应时,有可能是访问权限导致的,因为ECU只有在安全状态为解锁状态下才支持0x34服务,当ECU处于未解锁状态时,控制器可能发否定响应0x03 7F 34 33,表示安全访问拒绝,需要先解锁ECU。

0x36数据传输

数据传输服务在0x34服务得到了正确响应之后,诊断仪就要启动数据传输过程了。0x36服务传输的数据块大小上限由上一步ECU返回的74服务中的参数确定。

数据传输服务没有子功能,服务的参数数量由数据块大小决定,第1个字节是数据块的序列编号,编号从1开始,通常情况下,诊断仪需要使用多帧报文才能将数据库发给ECU,这时候需要使用首帧与连续帧。

数据传输服务CAN报文示例:

0x11 2B 36 01 D1 D2 D3 D4 #诊断仪请求ECU数据传输第1个数据块
0x21 D5 D6 D7 D8 D9 DA DB #诊断仪传输数据
0x02 76 01 55 55 55 55 55 #ECU肯定响应,第1个数据块传输完毕
0x03 7F 76 31 55 55 55 55 #ECU否定响应,请求参数超出范围/数据ID不支持

ECU肯定响应时,参数为1个字节代表数据块的序列编号。

ECU否定响应时,否定响应码除了0x31之外还可使用0x71(数据传输中止)、0x72(编程失败)、0x73(块序列计数错误)。

0x37请求退出传输

请求退出服务用于退出上传下载,即诊断仪通过该诊断服务停止与ECU之间的数据传输。如果之前的0x34和0x36服务都顺利执行完成,那么37服务就可以得到ECU的肯定响应。否则ECU会负响应NRC 0x24,表示诊断请求序列有错误。

请求退出服务没有子功能,也没有参数。

请求退出服务CAN报文示例:

0x01 37 55 55 55 55 55 55 #诊断仪请求退出传输
0x01 77 55 55 55 55 55 55 #ECU肯定响应,退出传输
0x02 7F 37 24 55 55 55 55 #ECU否定响应,请求序列错误,数据传输失败

诊断请求序列有错误通常是因为请求下载的数据大小与实际数据传输的数据大小不一致,对于已经调试完成测试通过的系统,发生错误的概率很小。

偷书虫
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇