【ISO14229_UDS刷写】-2-$35诊断服务RequestUpload理论部分

原创 已于 2023-05-27 12:21:05 修改 · 1.6k 阅读 · 8 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#UDS诊断刷写 #bootloader

于 2023-05-27 00:10:53 首次发布
本文详细介绍了UDS/OBD协议中的0x35RequestUpload服务，包括服务描述、请求消息定义、肯定响应消息、否定响应代码及服务数据参数。该服务用于从服务器到客户端的数据上传，涉及数据格式标识符、地址和长度格式标识符等关键参数。

总目录：（单击下方链接皆可跳转至专栏总目录）

《UDS/OBD诊断需求编辑工具》总目录https://blog.youkuaiyun.com/qfmzhu/article/details/123697014

目录

1 $0x35 RequestUpload诊断服务描述

2 0x35服务请求消息

2.1 0x35服务请求消息定义

2.2 0x35服务请求消息子功能参数$ Level（LEV_）定义

2.3 0x35服务请求消息数据参数定义

3 0x35服务肯定响应消息

3.1 0x35服务肯定响应消息定义

3.2 0x35服务肯定响应消息数据参数定义

4 0x35服务支持的否定响应代码（NRC_）

5 示例：0x35 RequestUpload服务消息流

附录：H.1 addressAndLengthFormatIdentifier示例值

结尾

优质博文推荐阅读（单击下方链接，即可跳转）：

点击返回「《Autosar从入门到精通-实战篇》总目录」

点击返回「《Autosar_BSW高阶配置》总目录」

点击返回《嵌入式硬件/软件开发刷写/烧录文件》专栏

RequestUpload（0x35） service请求上传服务

服务

SID

描述

RequestUpload

请求上传

0x35

client请求协商从server到client的数据传输。

1 $0x35 RequestUpload诊断服务描述

RequestUpload服务由client使用，以启动从server到client的数据传输（上传）。

在server收到requestUpload请求消息后，server应采取所有必要的行动来发送数据，然后再发送一个positive response message肯定响应消息。

重要的是 - server和client应满足ISO 14229-1的7.5章节中规定的请求和响应消息行为。

2 0x35服务请求消息

2.1 0x35服务请求消息定义

表398 - 请求消息定义

A_Data byte

参数名称

Cvt

字节值

助记符

#1

RequestUpload Request SID

请求上传请求SID

M

0x35

RU

#2

dataFormatIdentifier

数据格式标识符

M

0x00 – 0xFF

DFI_

#3

addressAndLengthFormatIdentifier

地址和长度格式标识符

M

0x00 – 0xFF

ALFID

#4

:

#(m-1)+4

memoryAddress[] = [

byte#1 (MSB)

:

byte#m ]

M

:

C1

0x00 – 0xFF

:

0x00 – 0xFF

MA_

B1

:

Bm

#n-(k-1)

:

#n

memorySize[] = [

byte#1 (MSB)

:

byte#k ]

M

:

C2

0x00 – 0xFF

:

0x00 – 0xFF

MS_

B1

:

Bk

C1：该参数的存在取决于addressAndLengthFormatIdentifier的地址长度信息参数。

C2：该参数的存在取决于addressAndLengthFormatIdentifier的memory size长度信息。

2.2 0x35服务请求消息子功能参数$ Level（LEV_）定义

此服务不使用子功能参数。

2.3 0x35服务请求消息数据参数定义

表399 - 请求消息数据参数定义

定义

dataFormatIdentifier数据格式标识符

这个数据参数是一个字节的值，每个nibble单独编码。高位的nibble指定 " compressionMethod压缩方法"，low nibble指定 " encryptingMethod加密方法"。值0x00指定既不使用compressionMethod也不使用encryptingMethod。除了0x00以外的值是由vehicle manufacturer汽车制造商决定的。

addressAndLengthFormatIdentifier地址和长度格式标识符

这个参数是一个字节的值，每个nibble单独编码（见H.1的示例值）：

位7 - 4: memorySize参数的长度(字节数)

位3 - 0: memoryAddress参数的长度（字节数）。

memoryAddress内存地址

参数memoryAddress是server memory的起始地址，数据将从这里被检索出来。用于该地址的字节数由addressAndLengthFormatIdentifier的low nibble（bit 3 - 0）定义。memoryAddress参数中的Byte#m总是在server中被引用的地址中LSB（least significant byte）。地址中MSB（most significant byte）可以作为memory identifier使用。

一个使用memory identifier的例子是一个具有16位寻址和memory address重叠的双processor server。(当一个给定的地址对任何一个处理器都有效，但产生了不同的physical memory device或使用了内部和外部flash）。在这种情况下，memoryAddress参数中一个未使用的字节可以被指定为memory identifier，用于选择所需的memory device。该功能的使用应按照车辆制造商/系统供应商的规定。

memorySize内存大小

这个参数应被server用来比较memory size和TransferData服务期间传输的数据总量。这增加了programming编程的安全性。用于该大小的字节数由addressAndLengthFormatIdentifier的high nibble（bit 4）定义。如果使用了数据压缩，memory size是否代表压缩或未压缩的大小是由车辆制造商决定的。

3 0x35服务肯定响应消息

3.1 0x35服务肯定响应消息定义

表400 - 肯定响应消息定义

A_Data byte

参数名称

Cvt

字节值

助记符

#1

RequestUpload Response SID

请求上传响应SID

M

0x75

RUPR

#2

lengthFormatIdentifier

M

0x00 – 0xF0

LFID

#3

:

#n

maxNumberOfBlockLength = [

byte#1 (MSB)

:

byte#m ]

M

:

M

0x00 – 0xFF

:

0x00 – 0xFF

MNROB_

B1

:

Bm

3.2 0x35服务肯定响应消息数据参数定义

表396 - 响应消息数据参数定义

定义

lengthFormatIdentifier长度格式标识符

这个参数是一个字节的值，每个nibble单独编码：

位7-4：maxNumberOfBlockLength参数的长度（字节数）。

位3-0：由文件保留，要设置为'0'。

该参数的格式与请求信息中包含的addressAndLengthFormatIdentifier参数的格式兼容，只是lower nibble必须被设置为'0'。

maxNumberOfBlockLength最大块长度

这个参数被RequestUpload肯定响应消息用来通知client在server的每个TransferData肯定响应消息中包含多少数据字节。这个长度反映了完整的消息长度，包括TransferData肯定响应消息中的service identifier和data-parameter。这个参数允许client在server开始向client传输数据之前适应server的发送缓冲区大小。client需要接受长度与报告的maxNumberOfBlockLength相同的transferData响应。发送哪些长度小于maxNumberOfBlockLength的transferData响应（如果有的话）是由server决定的。

注意：一个给定block块中的最后一个transferData响应可能被要求小于maxNumberOfBlockLength。

4 0x35服务支持的否定响应代码（NRC_）

对于这项服务，应执行以下negative response code否定响应代码。表402中记录了每个响应代码会发生的情况。如果错误情况适用于服务器，应使用列出的negative response否定响应。

表402 - 支持的否定响应代码

NRC

描述

助记符

0x13

incorrectMessageLengthOrInvalidFormat消息长度不正确或格式无效

如果信息的长度有误，则应发送该NRC。

IMLOIF

0x22

conditionsNotCorrect条件不正确

如果不符合requestUpload的标准，将返回这个NRC。如果server在requestUpload已经激活但尚未完成的情况下收到该服务的请求，就会发生这种情况。

CNC

0x31

requestOutOfRange请求超出范围

如果出现以下情况，将返回这个NRC：

指定的dataFormatIdentifier是无效的。

指定的addressAndLengthFormatIdentifier是无效的。

指定的memoryAddress/memorySize是无效的。

ROOR

0x33

securityAccessDenied安全访问被拒绝

如果在收到对该服务的请求时，server是安全的（对于支持SecurityAccess服务的server），应返回这个NRC。

SAD

0x70

uploadDownloadNotAccepted上传下载不被接受

该NRC表明，由于某些故障条件，无法完成向server的memory下载的尝试。

UDNA

评价顺序记录在图27中。

Key

1)至少5个（SI+DFI_+ALFID+最小MA_+最小MS_）。

2)长度可以从addressAndLengthFormatIdentifier中计算出来。

图27 - NRC处理请求下载服务

5 示例：0x35 RequestUpload服务消息流

详见以下博文：

【ISO14229_UDS刷写】-6-$34,$35,$36,$37诊断服务用于downloading下载/uploading上载数据的消息流示例icon-default.png?t=N4P3https://blog.youkuaiyun.com/qfmzhu/article/details/130895979

附录：H.1 addressAndLengthFormatIdentifier示例值

表 H.1 包含 addressAndLengthFormatIdentifier 的high和low nibble的值组合示例。需要考虑以下几点：

⎯对于“manageable memorySize”或“memoryAddress range”标记为“not applicable”的值，不允许使用，并且必须通过否定响应消息被server拒绝。

⎯此参数允许具有适用的“manageable memorySize”和“memoryAddress range”的值。

表H.1 - addressAndLengthFormatIdentifier示例

Byte Value

Description

bit 7-4 (high nibble) number of memorySize bytes

bit 3-0 (low nibble) number of memoryAddress bytes

bytes used for memorySize parameter

manageable size

bytes used for memoryAddress parameter

addressable memory

0x00

not applicable

not applicable

not applicable

not applicable

0x01

not applicable

not applicable

1

256 Byte - 1

0x02

not applicable

not applicable

2

64 KB - 1

0x03

not applicable

not applicable

3

16 MB - 1

0x04

not applicable

not applicable

4

4 GB - 1

0x05

not applicable

not applicable

5

1,024 GB - 1

0x06 – 0x0F

:

:

:

:

0x10

1

256 Byte

not applicable

not applicable

0x11

1

256 Byte

1

256 Byte – 1

0x12

1

256 Byte

2

64 KB – 1

0x13

1

256 Byte

3

16 MB – 1

0x14

1

256 Byte

4

4 GB – 1

0x15

1

256 Byte

5

1,024 GB – 1

0x16 – 0x1F

:

:

:

:

0x20

2

64 KB

not applicable

not applicable

0x21

2

64 KB

1

256 Byte – 1

0x22

2

64 KB

2

64 KB – 1

0x23

2

64 KB

3

16 MB – 1

0x24

2

64 KB

4

4 GB – 1

0x25

2

64 KB

5

1,024 GB – 1

0x26 – 0x2F

:

:

:

:

0x30

3

16 MB

not applicable

not applicable

0x31

3

16 MB

1

256 Byte – 1

0x32

3

16 MB

2

64 KB – 1

0x33

3

16 MB

3

16 MB – 1

0x34

3

16 MB

4

4 GB – 1

0x35

3

16 MB

5

1,024 GB – 1

0x36 – 0x3F

:

:

:

:

0x40

4

4 GB

not applicable

not applicable

0x41

4

4 GB

1

256 Byte – 1

0x42

4

4 GB

2

64 KB – 1

0x43

4

4 GB

3

16 MB – 1

0x44

4

4 GB

4

4 GB – 1

0x45

4

4 GB

5

1,024 GB - 1

0x46 -0xFF

:

:

:

:

以上摘自《ISO 14229-1:2013》。

结尾

获取更多“汽车电子资讯”和“工具链使用”，

请关注优快云博客“汽车电子助手”，做您的好助手。

《我的AUTOSAR之路》UDS 0x34 service
libuping2023的博客
10-13 300
其中 RequestDownload Request SID，dataFormatIdentifier，addressAndLengthFormatIdentifier 是固定长度一个字节，而memoryAddress和memorySize是非固定长度，OEM可以自定义。其中request的第三位44 分别表示[80 00 00 00]的字节的长度和[09 68 F4 00]数据长度的字节长度，而响应的第二位40中的4表示后面[00 40 00 00]的字节长度。0x34服务支持的NRC 如表格所示。
【Python搞定车载自动化测试】——Python基于Pytest框架实现UDS诊断自动化测试（含Python源码）
测试领域技术分享
05-25 1997
在之前的专栏【如何学习CAN总线测试】中介绍了如何通过CAPL语言实现UDS诊断测试，但CAPL语言依赖于Vector CANoe设备，随着智能电动汽车行业的发展，目前使用Python语言实现自动化测试的需求越来越广，本章节主要介绍如何使用Python语言基于Pytest自动化框架来实现UDS诊断自动化测试。首先回顾一下UDS诊断基础知识介绍：统一诊断服务（Unified Diagnostic Services），简称UDS。
UDS 诊断 - RequestDownload（请求下载）（0x34）服务
耳朵东金子千的博客
09-12 2025
字节参数名称Cvt字节值#1RequestDownload （请求下载） 请求 SIDM0x34#2dataFormatIdentifier（数据格式标识符）M#3addressAndLengthFormatIdentifier（地址和长度格式标识符）M#4#(m-1)+4byte#m ]MC1#n-(k-1)#nbyte#m ]MC2C1：此参数的存在性取决于 addressAndLengthFormatIdentifier 的地址长度信息参数。
UDS 34/36/37 服务
qwe0405080615的博客
02-09 9624
UDS 34/36/37 服务
【ISO14229_UDS_0x35服务详解】
weixin_43722921的博客
08-21 2903
本文章介绍了0x35服务(RequestUpload，请求上传服务)的使用说明。
UDS-RequestUpload(请求上传)（0x35）服务
lj__1111的博客
05-11 1631
1、作用：客户端利用RequestUpload服务启动服务器到客户端之间的数据传输。 note：服务器接收到RequestUpload请求消息后，应在其发送肯定响应消息之前采取必要行动接收数据。 2、请求消息定义 A_Data byte Parameter name Cvt Hex value Mnemonic #1 RequestUpload Request Service Id M 34 RD #2 dataFormatIdentifi
UDS诊断ISO14229新手入门篇
weixin_45387165的博客
09-21 1552
这个命令的格式稍微复杂一点。sub-function = 0x06 用于读取某个 DTC 及其相关的环境数据，此时 parameter 为 4 个 byte，前三个 byte 用于标识我们要读取的 DTC，第四个 byte 用于标识要读取的环境数据的范围，UDS 规定使用 FF 来表示读取所有的环境数据，各厂家可以要根据自己的需求定义其他的值来代表要读取的环境数据的范围。环境数据包括 DTC 状态，优先级，发生次数，老化计数器，时间戳，里程等，厂家还可以根据自己的需求定义一些此 DTC 产生时的测量数据。
UDS诊断服务列表.pdf
11-14
UDS（统一诊断服务）是汽车领域中广泛使用的一套标准通信协议，主要用于汽车ECU...了解和运用这些UDS诊断服务是汽车电子技术领域的一个重要部分，它对于诊断车辆故障、程序更新、系统监控以及满足法规要求至关重要。
UDS 诊断 - SecurityAccess（安全访问）（0x27）服务
耳朵东金子千的博客
08-08 2398
下表规定了请求消息定义 - sub-function =。字节参数名称字节值#1SecurityAccess（安全访问）请求SID0x27#2#3#n下表规定了请求消息定义 - sub-function = ==sendKey==。字节参数名称字节值#1SecurityAccess（安全访问）请求SID0x27#2#3#n。
《UDS协议从入门到精通》系列——图解0x38：请求文件传输
车载系统攻城狮
06-28 2676
详细解释UDS协议中0x38-请求上传服务的各个参数！！
汽车行业标准ISO14229-UDS统一诊断服务
01-29
汽车行业标准ISO14229-UDS统一诊断服务（1-6）全套 ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
跟我学UDS(ISO14229) ———— 0x35(RequestUpload)
永远的菜鸡小詹的博客
06-29 3236
  客户端请求从服务器到客户端的数据传输。服务器收到requestUpload请求消息后，服务器应采取所有必要的措施在发送肯定响应消息之前发送数据。在这里，ISO 14229 中并没有明确定义需要采用什么措施来确保接受数据的可行性。因此，需要额外关注主车厂给到的相关措施。 诊断请求格式  具体的格式如下： 参数 memoryAddress 与 memorySize 的长度均取决于参数 addressAndLengthFormatIdentifier。 message data parameter de
UDS升级入门，手把手教你———诊断服务UDS CANTP
不断debug，优化中……
03-26 1239
参考资料《ISO14229-1》
《UDS协议从入门到精通》系列——图解0x35：请求上传
车载系统攻城狮
06-27 2171
如何从目标ECU获取大块数据？图解请求上传服务，示例详解无所不用其极！！快速上手！！
汽车UDS诊断详解及Vector相关工具链使用说明——2.6.4 请求上传（0x35）
weixin_42967006的博客
11-17 2119
1. 概述 请求上传服务是与0x34请求下载服务(点击这里回顾)的服务，二者的诊断报文格式类似，只是数据发送方向不同，请求下载是向ECU中写入一段数据，请求上传是从ECU中读取一段数据。 上传数据的过程也会用到0x36传输数据和0x37退出传输，只不过0x36服务的诊断仪请求报文中不再带有数据，而是ECU发送的响应中带有数据。 ECU在收到请求上传的诊断指令后，要进入准备上传数据的状态，一切准备做好后，再发送肯定响应。 2. 请求报文格式 请求上传的请求报文格式和请求下载的报文格式是一样的，参数含义也相同，
UDS诊断服务详解
热门推荐
qq_43216283的博客
02-04 1万+
数据记录值的格式和定义应该由车辆制造厂商或者系统供应商所指定，这些数据记录值可能会包含模拟量输入和输出信号，数字输入和输出信号，内部数据和系统状态信息。服务端可能会先同时请求的数据标识符数量，首先需要由车辆制造厂商和系统供应商商讨决定。一旦收到了0x22服务的请求消息，服务端应该访问由数据标识符参数指定数据元素几率之，并且在单个22服务肯定应答报文中去传输他们的值。请求报文中可能会多次包含同一个DID值，服务端应该将这些重复的DID看作独立的DID并答复。
【ISO14229_UDS刷写】UDS 35 36 37服务 RequestUpload
quentin_neng的博客
12-07 964
UDS 35 36 37服务。
uds服务-上传下载功能单元【34、36、37】
yunhuhude的博客
02-14 3066
0x34 00-FF 44 数据格式标志符，【00-FF】，左半元组表示压缩方法，右半元组表示加密算法，如果没有应用压缩或者加密，相应位为0 44的bit7~4表示memorysize参数的长度 bit3~0表示memoryadress参数的长度TransferData （0x36）—— 数据传输这个服务通常是用来下载/上传数据时用的，数据的传输方向由不同的服务控制：0x34服务表示下载，0x35服务表示上传。0x36服务包含了一个blockSequenceCounter，在多个服务请求序列失败的时候以提高
统一诊断服务 (Unified diagnostic services ， UDS)
Mr_kanger的博客
09-26 519
统一诊断服务 (Unified diagnostic services ， UDS) 对知乎专栏汽车控制器(ECU)网络诊断技术交流中UDS的内容进行一个快速访问链接整理。文章很好并且比较系统。 UDS（一）请求与响应格式 Diagnostic request的格式 Diagnostic response的格式 Negative Response Code UDS（二）诊断和通信管理1 DiagnosticSessionControl (0x10) ECUReset (0x11) SecurityAc
uds35服务
最新发布
04-04
<think>好的，我现在要处理用户关于UDS 0x35服务的问题。首先，我需要确认用户的需求是什么。用户提到“uds35服务”，根据之前的引用内容，UDS中的0x35服务是RequestUpload，即请求上传服务。用户可能想了解这个服务的功能、应用场景、工作流程，或者相关的否定应答码（NRC）以及案例说明。 首先，我需要回忆UDS协议的基本结构。UDS是统一诊断服务，用于汽车电子控制单元（ECU）的诊断通信。每个服务都有一个唯一的服务ID，比如0x34是RequestDownload，0x35是RequestUpload。这两个服务分别用于下载和上传数据，即从客户端到服务器传输数据，或者从服务器到客户端传输数据。 根据引用[1]，0x35服务的否定应答码处理过程有详细说明，这可能包括常见的NRC如NRC-31（requestOutOfRange）或NRC-33（securityAccessDenied）等。而案例说明部分可能解释了在实际应用中如何正确使用该服务，例如如何配置内存地址和大小，或者如何处理安全访问的问题。 用户可能还需要知道0x35服务与0x34服务的区别，比如0x34用于下载，0x35用于上传，两者在数据传输方向上的不同。此外，服务的工作流程可能包括请求阶段、数据传输阶段和响应阶段。例如，客户端发送RequestUpload请求，指定内存地址和数据长度，服务器回应是否允许上传，然后客户端使用TransferData服务进行数据传输。 接下来需要检查用户提供的引用内容是否正确应用。引用[1]详细说明了0x35服务的NRC处理，引用[2]提到了0x34服务，但用户的问题是关于0x35的，所以主要参考引用[1]。需要确保回答中正确引用这些内容，并在适当的位置添加引用标识。 用户可能还想了解该服务的实际应用场景，比如在汽车诊断中，维修人员可能需要上传ECU内的故障日志或特定数据，这时就会用到RequestUpload服务。此外，安全机制也是重要部分，例如服务器可能需要客户端先通过安全验证（如0x27服务）才能允许上传数据，否则返回NRC-33。 在回答结构方面，应该先定义0x35服务，然后描述其功能、工作流程、相关参数、否定应答码，最后给出应用案例。需要确保使用正确的中文术语，避免技术术语错误。同时，按照用户的要求，行内数学表达式使用$...$格式，但在这个问题中可能涉及较少数学内容，更多的是协议流程，所以可能需要用列表或步骤来描述。 最后，生成相关问题时要考虑用户可能进一步询问的内容，比如如何实现安全访问与0x35的结合使用，或者具体的NRC处理流程，以及如何诊断上传失败的问题。需要确保相关问题与主题相关，并且有助于用户深入理解。</think>### UDS 0x35服务（RequestUpload，请求上传）详解 UDS（Unified Diagnostic Services，统一诊断服务）中的**0x35服务**（RequestUpload）用于客户端向服务器（如汽车ECU）发起数据上传请求，将服务器端的数据传输到客户端[^1]。 --- #### 1. 功能与作用 - **数据传输方向**：服务器→客户端（与0x34服务方向相反）。 - **典型应用**：读取ECU内部存储的故障日志、配置参数或传感器数据[^1]。 - **安全要求**：可能需要先通过安全访问服务（如0x27服务）解锁权限。 --- #### 2. 服务请求格式 客户端发送的请求报文格式为： ``` 0x35 [数据格式标识] [内存地址] [内存大小] ``` - **数据格式标识**：定义地址和长度的编码方式（如0x00表示32位地址+32位长度）。 - **内存地址**：需上传数据的起始地址。 - **内存大小**：需上传的数据长度。 --- #### 3. 服务响应 - **肯定响应**： ``` 0x75 [数据格式标识] [最大块长度] ``` - `最大块长度`：服务器允许单次传输的数据块大小[^1]。 - **否定响应**： 常见NRC（否定应答码）： - **0x31**（requestOutOfRange）：请求的内存地址或大小无效。 - **0x33**（securityAccessDenied）：未通过安全验证。 --- #### 4. 工作流程示例 1. **客户端请求上传**： ```python # 示例请求报文：上传地址0x0800FF00，长度0x200字节 request = [0x35, 0x00, 0x08, 0x00, 0xFF, 0x00, 0x00, 0x00, 0x02, 0x00] ``` 2. **服务器响应**： - 若允许上传，返回`0x75 0x00 0x100`（最大块长度256字节）。 - 若地址无效，返回`0x7F 0x35 0x31`（NRC-31）。 3. **数据传输**：客户端通过`TransferData`（0x36服务）分块接收数据。 --- #### 5. 应用案例 - **场景**：读取ECU存储的DTC（故障码）详情。 - **步骤**： 1. 通过0x27服务解锁安全权限。 2. 发送0x35服务请求，指定存储DTC的地址和长度。 3. 按块接收数据并解析。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

汽车电子助手

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值