HTML常用标签

TML常用标签有：a标签、table标签、img标签、form标签和input标签。

a标签

作用

跳转到外部网页
跳转到内部锚点
跳转到邮箱或电话等

属性

（一）href

href是hyper reference的缩写，超链接的意思。

用于指定链接目标的ur地址，(必须属性)当为标签应用href属性时，它就具有了超链接的功能；
href=“#”表示这是一个空链接；
如果href里面地址是—个文件或者压缩包,会下载这个文件。

<a href="https://google.com">超链接到google网站的主页</a>
 <a href="https://google.com">超链接到google的主页</a>
 <a href="//google.com">超链接到google的主页</a>

展现形式：

点击此链接，即可到达google的主页

a标签href的取值：

1、上述代码中的网址的取值(推荐使用第三行的代码)

<a href="//google.com">超链接到google的主页</a>

由于此方式能够自动补齐相关的网络地址，前面两种写错就会报错，所以推荐使用。

2、路径

/a/b/c 或者是a/b/c

当前路径下的a里面的b，b里面的c

index.html 以及./index.html

在当前目录下寻找index.html文件

3、伪协议

javascript：代码；（冒号与分号一定要写）

<a href="javascript：;">点击后无任何点击或刷新等动作的反应</a>

锚点链接

<a href="#要跳转的元素的id"></a>

点击链接的时候，会跳转到指定元素所在的位置。

mailto：邮箱

<a href="mailto:abcdefg@163.com ">发邮件给我</a>

tel：手机号

<a href="tel:12345678901">打电话给我</a>

（二）targe

用于指定链接页面的打开方式

a的target取值

1、内置名字

_blank 在空白页打开

_self 在当前页面打开

_parent 在父级窗口打开

_top 在最顶级的窗口打开

<a href="//google.com" target="_blank">超链接到google网站的主页在空白页打开</a>

2、程序员的命名

window：name（在xxx页面打开）

iframe的name（iframe现在已经很少使用了，是指内嵌窗口）

（三）download

下载页面，但目前很少用，有的浏览器不支持，尤其是手机浏览器可能不支持。

table标签

1、table标签的语法：

thead:表头

tbody:表的内容，用于定义

tfoot:表的脚部

tr:table row,表格里的行

th:表格的表头部分，其中的文本内容字体加粗居中显示

td:table data,表格数据，用于定义表格中的单元格

<!DOCTYPE html>
<html lang="zh-CN">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>Document</title>
  </head>
  <body>
    <table>
      <thead>
        <tr>
          <th></th>
          <th>小红</th>
          <th>小黄</th>
          <th>小蓝</th>
        </tr>
      </thead>
      <tbody>
        <tr>
          <th>数学</th>
          <td>90</td>
          <td>60</td>
          <td>80</td>
        </tr>
        <tr>
          <th>语文</th>
          <td>88</td>
          <td>95</td>
          <td>97</td>
        </tr>
        <tr>
          <th>英语</th>
          <td>88</td>
          <td>95</td>
          <td>97</td>
        </tr>
      </tbody>
      <tfoot>
        <tr>
          <th>总分</th>
          <td>266</td>
          <td>250</td>
          <td>274</td>
        </tr>
      </tfoot>
    </table>
  </body>
</html>

第一行的th标签为空

2、table的样式

table-layout：auto；自动计算每一行的宽高

table-layout：fixed；通过列表的宽度来决定平均宽度

border-collapse：collapse；合并边框(默认边框与边框之间不合并)

border-spacing：0；边框为0.(边框与边框之间的距离)。

img标签（图片）

作用：发出get请求，展示一张图片。

<img src="1.JPG" alt="头像" width="400" />

当前路径下的1.jpg，确定宽度为400，只写宽度高度会自适应

属性

alt：alternate的缩写，替换的意思。替换文本，图像不能显示的文字。

路径错误显示alt内容

title：提示文本。鼠标放到图像上，显示的文字。

响应

max-width：100% 所有的图片在手机上都自适应宽度，宽度最大为100%。

事件

onload/onerror 监听图片是否加载成功，加载成功时用onload，不成功是用onerror事件。确保在onerror事件能够补救。

<body>
 <img id="xxx" src="dog.jpg" alt="一只小狗">
<script>
xxx.onload = function () {
console.log("图片加载成功");
 };
xxx.onerror = function () {
console.log("图片加载失败");
xxx.src = "/404.jpg";
 };
</script>
</body>

监听成功时，打印出成功

监听失败时，先打印出监听失败并且开始执行加载失败是的挽救图片。404.jpg文件执行

感想：

a标签的默认样式可以设置清除，href属性可以有好多种取值，a标签的意义也不仅仅是跳转到一个网址，还可以发邮件打电话。
给img标签设置宽度和高度时，不能让图片变形
table标签必须按照thead,tbody,tfoot的结构去写，先划分好结构，再往里填充内容，即使tfoot写在前面，也会显示在页面的尾部

本文为作者本人的原创文章，著作权归作者本人和饥人谷所有，转载务必注明来源。

TTP 协议是互联网的基础协议，也是网页开发的必备知识，最新版本 HTTP/2 更是让它成为技术热点。

本文介绍 HTTP 协议的历史演变和设计思路。

一、HTTP/0.9

HTTP 是基于 TCP/IP 协议的应用层协议。它不涉及数据包（packet）传输，主要规定了客户端和服务器之间的通信格式，默认使用80端口。

最早版本是1991年发布的0.9版。该版本极其简单，只有一个命令GET。

GET /index.html

上面命令表示，TCP 连接（connection）建立后，客户端向服务器请求（request）网页index.html。

协议规定，服务器只能回应HTML格式的字符串，不能回应别的格式。

<html>
<body>Hello World</body></html>

服务器发送完毕，就关闭TCP连接。

二、HTTP/1.0

2.1 简介

1996年5月，HTTP/1.0 版本发布，内容大大增加。

首先，任何格式的内容都可以发送。这使得互联网不仅可以传输文字，还能传输图像、视频、二进制文件。这为互联网的大发展奠定了基础。

其次，除了GET命令，还引入了POST命令和HEAD命令，丰富了浏览器与服务器的互动手段。

再次，HTTP请求和回应的格式也变了。除了数据部分，每次通信都必须包括头信息（HTTP Header），用来描述一些元数据。

其他的新增功能还包括状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等。

2.2 请求格式

下面是一个1.0版的HTTP请求的例子。

GET / HTTP/1.0User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)Accept: */*

可以看到，这个格式与0.9版有很大变化。

第一行是请求命令，必须在尾部添加协议版本（HTTP/1.0）。后面就是多行头信息，描述客户端的情况。

2.3 回应格式

服务器的回应如下。

HTTP/1.0 200 OK
Content-Type: text/plainContent-Length: 137582Expires: Thu, 05 Dec 1997 16:00:00 GMTLast-Modified: Wed, 5 August 1996 15:55:28 GMTServer: Apache 0.84<html>
 <body>Hello World</body></html>

回应的格式是”头信息 + 一个空行（\r\n） + 数据”。其中，第一行是”协议版本 + 状态码（status code） + 状态描述”。

2.4 Content-Type 字段

关于字符的编码，1.0版规定，头信息必须是 ASCII 码，后面的数据可以是任何格式。因此，服务器回应的时候，必须告诉客户端，数据是什么格式，这就是Content-Type字段的作用。

下面是一些常见的Content-Type字段的值。

text/plain
text/html
text/css
image/jpeg
image/png
image/svg+xml
audio/mp4
video/mp4
application/javascript
application/pdf
application/zip
application/atom+xml

这些数据类型总称为MIME type，每个值包括一级类型和二级类型，之间用斜杠分隔。

除了预定义的类型，厂商也可以自定义类型。

application/vnd.debian.binary-package

上面的类型表明，发送的是Debian系统的二进制数据包。

MIME type还可以在尾部使用分号，添加参数。

Content-Type: text/html; charset=utf-8

上面的类型表明，发送的是网页，而且编码是UTF-8。

客户端请求的时候，可以使用Accept字段声明自己可以接受哪些数据格式。

Accept: */*

上面代码中，客户端声明自己可以接受任何格式的数据。

MIME type不仅用在HTTP协议，还可以用在其他地方，比如HTML网页。

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><!-- 等同于 --><meta charset="utf-8" />

2.5 Content-Encoding 字段

由于发送的数据可以是任何格式，因此可以把数据压缩后再发送。Content-Encoding字段说明数据的压缩方法。

Content-Encoding: gzipContent-Encoding: compressContent-Encoding: deflate

客户端在请求时，用Accept-Encoding字段说明自己可以接受哪些压缩方法。

Accept-Encoding: gzip, deflate

2.6 缺点

HTTP/1.0 版的主要缺点是，每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。

TCP连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢（slow start）。所以，HTTP 1.0版本的性能比较差。随着网页加载的外部资源越来越多，这个问题就愈发突出了。

为了解决这个问题，有些浏览器在请求时，用了一个非标准的Connection字段。

Connection: keep-alive

这个字段要求服务器不要关闭TCP连接，以便其他请求复用。服务器同样回应这个字段。

Connection: keep-alive

一个可以复用的TCP连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。

三、HTTP/1.1

1997年1月，HTTP/1.1 版本发布，只比 1.0 版本晚了半年。它进一步完善了 HTTP 协议，一直用到了20年后的今天，直到现在还是最流行的版本。

3.1 持久连接

1.1 版的最大变化，就是引入了持久连接（persistent connection），即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive。

客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接。

Connection: close

目前，对于同一个域名，大多数浏览器允许同时建立6个持久连接。

3.2 管道机制

1.1 版还引入了管道机制（pipelining），即在同一个TCP连接里面，客户端可以同时发送多个请求。这样就进一步改进了HTTP协议的效率。

举例来说，客户端需要请求两个资源。以前的做法是，在同一个TCP连接里面，先发送A请求，然后等待服务器做出回应，收到后再发出B请求。管道机制则是允许浏览器同时发出A请求和B请求，但是服务器还是按照顺序，先回应A请求，完成后再回应B请求。

3.3 Content-Length 字段

一个TCP连接现在可以传送多个回应，势必就要有一种机制，区分数据包是属于哪一个回应的。这就是Content-length字段的作用，声明本次回应的数据长度。

Content-Length: 3495

上面代码告诉浏览器，本次回应的长度是3495个字节，后面的字节就属于下一个回应了。

在1.0版中，Content-Length字段不是必需的，因为浏览器发现服务器关闭了TCP连接，就表明收到的数据包已经全了。

3.4 分块传输编码

使用Content-Length字段的前提条件是，服务器发送回应之前，必须知道回应的数据长度。

对于一些很耗时的动态操作来说，这意味着，服务器要等到所有操作完成，才能发送数据，显然这样的效率不高。更好的处理方法是，产生一块数据，就发送一块，采用”流模式”（stream）取代”缓存模式”（buffer）。

因此，1.1版规定可以不使用Content-Length字段，而使用“分块传输编码”（chunked transfer encoding）。只要请求或回应的头信息有Transfer-Encoding字段，就表明回应将由数量未定的数据块组成。

Transfer-Encoding: chunked

每个非空的数据块之前，会有一个16进制的数值，表示这个块的长度。最后是一个大小为0的块，就表示本次回应的数据发送完了。下面是一个例子。

HTTP/1.1 200 OKContent-Type: text/plainTransfer-Encoding: chunked25This is the data in the first chunk1Cand this is the second one3con8sequence0

3.5 其他功能

1.1版还新增了许多动词方法：PUT、PATCH、HEAD、 OPTIONS、DELETE。

另外，客户端请求的头信息新增了Host字段，用来指定服务器的域名。

Host: www.example.com

有了Host字段，就可以将请求发往同一台服务器上的不同网站，为虚拟主机的兴起打下了基础。

3.6 缺点

虽然1.1版允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为“队头堵塞”（Head-of-line blocking）。

为了避免这个问题，只有两种方法：一是减少请求数，二是同时多开持久连接。这导致了很多的网页优化技巧，比如合并脚本和样式表、将图片嵌入CSS代码、域名分片（domain sharding）等等。如果HTTP协议设计得更好一些，这些额外的工作是可以避免的。

四、SPDY 协议

2009年，谷歌公开了自行研发的 SPDY 协议，主要解决 HTTP/1.1 效率不高的问题。

这个协议在Chrome浏览器上证明可行以后，就被当作 HTTP/2 的基础，主要特性都在 HTTP/2 之中得到继承。

五、HTTP/2

2015年，HTTP/2 发布。它不叫 HTTP/2.0，是因为标准委员会不打算再发布子版本了，下一个新版本将是 HTTP/3。

5.1 二进制协议

HTTP/1.1 版的头信息肯定是文本（ASCII编码），数据体可以是文本，也可以是二进制。HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为”帧”（frame）：头信息帧和数据帧。

二进制协议的一个好处是，可以定义额外的帧。HTTP/2 定义了近十种帧，为将来的高级应用打好了基础。如果使用文本实现这种功能，解析数据将会变得非常麻烦，二进制解析则方便得多。

5.2 多工

HTTP/2 复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了”队头堵塞”。

举例来说，在一个TCP连接里面，服务器同时收到了A请求和B请求，于是先回应A请求，结果发现处理过程非常耗时，于是就发送A请求已经处理好的部分，接着回应B请求，完成后，再发送A请求剩下的部分。

这样双向的、实时的通信，就叫做多工（Multiplexing）。

5.3 数据流

因为 HTTP/2 的数据包是不按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。

HTTP/2 将每个请求或回应的所有数据包，称为一个数据流（stream）。每个数据流都有一个独一无二的编号。数据包发送的时候，都必须标记数据流ID，用来区分它属于哪个数据流。另外还规定，客户端发出的数据流，ID一律为奇数，服务器发出的，ID为偶数。

数据流发送到一半的时候，客户端和服务器都可以发送信号（RST_STREAM帧），取消这个数据流。1.1版取消数据流的唯一方法，就是关闭TCP连接。这就是说，HTTP/2 可以取消某一次请求，同时保证TCP连接还打开着，可以被其他请求使用。

客户端还可以指定数据流的优先级。优先级越高，服务器就会越早回应。

5.4 头信息压缩

HTTP 协议不带有状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如Cookie和User Agent，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。

HTTP/2 对这一点做了优化，引入了头信息压缩机制（header compression）。一方面，头信息使用gzip或compress压缩后再发送；另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

5.5 服务器推送

HTTP/2 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送（server push）。

常见场景是客户端请求一个网页，这个网页里面包含很多静态资源。正常情况下，客户端必须收到网页后，解析HTML源码，发现有静态资源，再发出静态资源请求。其实，服务器可以预期到客户端请求网页后，很可能会再请求静态资源，所以就主动把这些静态资源随着网页一起发给客户端了。

近被「诺亚财富34亿踩雷」的新闻刷屏了，报案、否认、甩锅，一波三折，如今演绎成了罗生门。承兴造假，京东否认，诺亚报案。如何通过技术方案的设计在风险发生时为业务提供强有力的举证支持是我最近一直在思考的事情，其中电子合同的有效性是我们一直在讨论的重点问题。

随着互联网金融/金融科技的发展，合同通过电子化签署逐渐被大家接受。但是受限制于国内《电子签名法》采用了技术折中的立法模式，法律法规仅从功能性和效果上的角度上提出了要求。

如何界定电子签名、数据电文及电子合同的有效性涉及较为复杂的技术知识，司法实践中对于技术路径审查的相关经验并不多，存在着对“电子签名制作数据”、“电子签名”、“数字签名”、“用户密码”等专业概念的认知偏差，对如何签出一份合法有效的电子合同则比较模糊。

针对于此，我也与很多的法务同学、电子合同服务商进行过交流，整理了下我在交流中的感受，分享出来抛砖引玉，欢迎砸我。

一、电子合同是被法律认可的合同形式

首先我们得确认电子合同是合法有效的，这是这篇文章的基础。

对于这一点，在《合同法》以及《电子签名法》中都有明确规定：

《中华人民共和国合同法》
第十条：当事人订立合同，有书面形式、口头形式和其他形式；
第十一条：书面形式是指合同书、信件和数据电文（包括电报、电传、传真、电子数据交换和电子邮件）等可以有形地表现所载内容的形式。

简而言之：电子合同属于合同的一种。

《中华人民共和国电子签名法》
第十三条电子签名同时符合下列条件的，视为可靠的电子签名：
电子签名制作数据用于电子签名时，属于电子签名人专有；
签署时电子签名制作数据仅由电子签名人控制；
签署后对电子签名的任何改动能够被发现；
签署后对数据电文内容和形式的任何改动能够被发现。当事人也可以选择使用符合其约定的可靠的条件的电子签名；
第十四条可靠的电子签名与手写签名或者盖章具有同等的法律效力

简而言之：《电子签名法》规定了可靠的电子签名的有效性以及可靠的电子签名的要素：专有、专控、不可篡改。

（当然，《电子签名法》中也规定了一些不适用电子签名的情况：涉及婚姻、收养、继承等人身关系的；涉及停止供水、供电、供气等公用事业服务的；法律、行政法规规定的不适用电子文书的其他情形。这些不在我们本次讨论范围之内。）

合同的成立在传统合同书中一般通过签字或者盖章的方式来体现，在电子合同中签字盖章的行为被可靠的电子签名所代替《电子签名法》第十四条^[1]。

二、先从技术层面来说

本质上电子合同的成立生效没有跳出传统合同的要件要求，这些要求我们不在此做讨论。

既然是「可靠的电子签名」与手写签名或者盖章具有同等的法律效力，那么我们只需要能在业务中能够证明符合相关要素即可。市面上的一些第三方电子合同服务商都有符合相关规定（至少是能经得起推敲）的产品方案（毕竟人家赚的就是这份钱）。

但第三方服务商的标准产品开发需要最大程度的降低其自身的风险，一般情况下会将签署合同的整个过程至于其可控范围内，其产品流程并不一定适合我们的业务系统交互需求甚至可能与业务系统相冲突。

因此部分过程需要业务系统自己完成，业务系统在风险发生时需要承担一定举证责任（不得不说，某些服务商的方案对于业务系统侵入性太大，很难接受啊）。

我们先对电子合同签署的生命流程进行拆解：

实名认证步骤，一般分为个人实名和企业实名。（不讨论线下核验的方式）

个人实名的方案很多：生物识别、银行卡验证、手机号实名认证……一般目前最保险的是扫脸认证活体检测，最好将活体的视频保存下来，以便举证。

企业实名，目前用的最多的营业执照、银行账户小额打款、法人身份证来验证。

这里顺便我说一句，我只看到一家供应商可以提供法人姓名+身份证号的认证信息，不知道市面上还有没有其他的服务商可以有此类服务提供（不是根据法人身份证对信息做二要素验证，而是根据工商注册信息对提供的法人姓名和身份证号做验证）。

意愿认证上，方式有很多。目前大部分第三方电子合同服务商都采用云托管数字证书模式，在意愿认证上针对个人一般采用短信验证码、人脸识别等来作为签署人意愿表达的行为；针对企业一般通过向企业授权人发送短信验证码、识别授权人人脸等方式或者采用 Ukey 来作为意愿表达。

这里多说一句：如果你采用 ukey 来做鉴权，需要考虑一点就是签署时使用的数字证书是否为 ukey 里存储的数字证书。如果不是（极大概率不是）一定要注意证据链完整的问题，因为本质上还是云托管数字证书来完成签署。

至于合同生成和司法举证，去找第三方服务商吧，如果这些事情都要自己做，那你就是自己在做一个电子合同平台了。

三、举证能力的一些思考

其实技术上没有难点，主要在举证问题上有一些思考：

1. 如何证明已经进行完善的实名信息

一般来说，我们做实名都是调用第三方数据接口，我们需要尽量保证调用记录的完整性及可查性。在出现电子合同有效性问题时可以提供我方已经进行应尽的实名义务，并在力所能及的范围内做到了对用户的实名认证。

针对企业实名，要至少核验包括包括企业名称、统一社会信用代码，最好对法人姓名及身份证号进行核验，同时应对经办人进行个人实名核验，以及企业核心隐私数据的核验，例如对公银行打款、开具指定金额发票等核验方式；

也可通过电子认证服务机构颁发的数字证书进行实名核验（这一点某 CA 的一个服务可以实现通过全国大部分（小）银行发放的 ukey进行实名认证，不过大行很少）。

这里需要注意的一点是我们在选择第三方数据服务商的时候一定要主要选择政府权威部门的数据库或者取得政府权威部门授权或认可的电子数据库（比如国政通……国政通麻烦广告费结下）

2. 在意愿认证上尽可能多的收集签署时的信息。

在合法合规的前提下，除通过短信验证码、人脸识别或 ukey 认证等方式完成用户意愿认证外，管理系统还应该尽可能的收集用户在签署时的IP 地址、操作设备 MAC 地址、操作系统信息等可以佐证是用户自身操作的信息。

3. 自动签署（或者说代签署）是否有效。

目前大部分系统对接第三方电子合同服务商的时候为了不让电子合同系统侵入业务系统都采用了各家服务商提供的「自动签署」方案（这一点我要吐槽下拉，各家差不多都有这样的接口，但是在使用上并没有很好的给用户说明。）

首先，我们要说的是《电子签名法》第十三条里提到的「签署时电子签名制作数据仅由电子签名人控制」这一项规定是对电子签名过程中电子签名制作数据归谁控制的要求。这里所规定的控制是指一种实质上的控制，即基于电子签名人的自由意志而对电子签名制作数据的控制。

在电子签名人实施电子签名行为的过程中，无论是电子签名人自己实施签名行为，还是委托他人代为实施签名行为，只要电子签名人拥有实质上的控制权，则其所实施的签名行为，满足本法此项规定的要求。（这段话不是我说的，是全国人大关于《电子签名法》的释法^[2]）

在中国互联网金融协会《互联网金融个体网络借贷电子合同安全规范（征求意见稿）》第 8 司法举证要求（d）中也提到「电子签名人委托他人代为实施签名行为时，从业机构或第三方电子合同订立系统服务商提供电子签名制作数据由电子签名人控制的证据，包括调用电子签名制作数据的时间和方式、电子签名人位置、IP地址、授权及认证方式、授权及认证记录等；」

所以，自动签署的方案大家还是可以放心用，只需要你能通过其他方式来证明电子签名人拥有实质上的控制权即可。

4. 关于举证责任

关于电子签名，有一个举证的坑。

《电子签名法》第二十八条：电子签名人或者电子签名依赖方因依据电子认证服务提供者提供的电子签名认证服务从事民事活动遭受损失，电子认证服务提供者不能证明自己无过错的，承担赔偿责任。

也就是说，关于电子签名，举证责任倒置。即对方提出的侵权事实，电子认证提供者如果予以否认，则应负举证责任，证明自己没有过错。

在司法实践上，《袁斌与合肥梦川玖贸易有限公司等小额借款合同纠纷二审案件》【案号：北京市第三中级人民法院（2018）京03民终4903号】^[3]中，法院也是这样认定的。

当然，只要电子认证服务提供者能够证明自己对于电子签名人或者电子签名依赖方所遭受的损失没有过错，就不承担责任。而对于电子认证服务提供者来讲，只要能够证明其所提供的服务完全是严格按照本法和符合国家规定并向国务院信息产业主管部门备案的电子认证业务规则实施的，则应能够证明没有过错。（《电子签名法释义法律责任》^[4]）

5. 电子签名无效的法律后果

电子签名无效仅仅表示该电子签名并非当事人真实意愿的表达，并不必然影响当事人之间的部分关系（比如债权债务关系、劳动关系）的成立。

如果能够从其他方面来证明当事人之间存在相关关系，法院大概率上会要求侵权方承担民事责任。但一些合同上具体规定可能无法予以认定。

比如上边提到的《袁斌与合肥梦川玖贸易有限公司等小额借款合同纠纷二审案件》中，法院虽然认定电子签名无效，但是从实名认证信息、操作记录等方面认定借款合同有效。

6. 一定要用数字签名么？

其实这一点上，《最高人民法院关于互联网法院审理案件若干问题的规定》第十一条^[5]已经明确指出：「当事人提交的电子数据，通过电子签名、可信时间戳、哈希值校验、区块链等证据收集、固定和防篡改的技术手段或者通过电子取证存证平台认证，能够证明其真实性的，互联网法院应当确认。」

最后多说一句，如果有钱花一点钱找服务商做个证据保全系统或者直接和司法鉴定中心、公证处之类的合作，毕竟法官不是开发小哥，你跟他讲技术远不如公证处或者司法鉴定中心的一个章子管用。

四、我为了写这篇东西，翻了多少材料

《电子签名法》：这个就不用说了，自己百度就好了；
详细的研究了各家服务商的材料（至少 Top3 的PPT 和接口文档我都比对了好几遍，其他一些的 PPT 我也都又翻了一遍）
《GB∕T36298-2018 电子合同订立流程规范》：商务部18 年新搞的推荐标准，至少目前各家服务商的 PPT 中我还没看到把这个拿出来写。有想要 PDF 的可以找我，不过也是图片扫描版的。
《互联网金融个体网络借贷电子合同安全规范（征求意见稿）》：这个不说了，都是当年的存货。（我不说当年我收集了中互金以及各地区的P2P 的规定、措施等等材料，毕竟当年也算家大业大。）
《JR/T 0118-2015 金融电子认证规范》：这个简单学习了下。
法律实践，说白了就是判例。一个在做法务的小伙伴跟我说，你问我不如去看判例……这里安利下「无讼」这个平台比文书网好用多了。

#References#

[1]《电子签名法》第十四条:可靠的电子签名与手写签名或者盖章具有同等的法律效力。

[2]全国人大关于《电子签名法》的释法:http://t.cn/AiYEl4bm

[3]《袁斌与合肥梦川玖贸易有限公司等小额借款合同纠纷二审案件》【案号：北京市第三中级人民法院（2018）京03民终4903号】:http://t.cn/AiYEOrYd

[4]《电子签名法释义法律责任》:http://t.cn/AiYElv5w

[5]《最高人民法院关于互联网法院审理案件若干问题的规定》第十一条:http://www.court.gov.cn/zixun-xiangqing-116981.html

#相关阅读#

互金业务中经常提到的电子合同，到底是个啥？

#专栏作家#

张小璋，公众号：张小璋的碎碎念（ID：SylvainZhang），人人都是产品经理专栏作家。野蛮生长的产品经理，专注于互联网金融领域。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议

在线咨询

上一篇：如何让你的网站在浏览器中自动跳转到 HTTPS，提升网站安全性！
下一篇：HTML 颜色

您的项目需求

*请认真填写需求信息，我们会在24小时内与您取得联系。

整合营销服务商