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小時內與您取得聯系。

整合營銷服務商