&quot;精通Vue：手把手教你將JSON數(shù)據(jù)優(yōu)雅寫入文本，并深度

通Vue：手把手教你將JSON數(shù)據(jù)優(yōu)雅寫入文本，并深度解讀Vue引入CDN的實戰(zhàn)技巧

一、前言：Vue與JSON數(shù)據(jù)交互的重要性



在現(xiàn)代Web開發(fā)領域中，Vue.js以其輕量級、易上手且功能強大的特性贏得了眾多開發(fā)者青睞。作為一款漸進式JavaScript框架，Vue在處理數(shù)據(jù)綁定、組件化開發(fā)等方面表現(xiàn)卓越，而JSON（JavaScript Object Notation）作為一種輕量級的數(shù)據(jù)交換格式，其簡潔明了的特性使其成為前后端通信的首選。因此，掌握如何優(yōu)雅地在Vue項目中處理JSON數(shù)據(jù)至關重要。本文將詳細介紹如何使用Vue將JSON數(shù)據(jù)優(yōu)雅寫入文本，并深入探討Vue引入CDN（Content Delivery Network）的實戰(zhàn)技巧，以提升應用性能與用戶體驗。

二、Vue中JSON數(shù)據(jù)的解析與顯示

2.1 JSON數(shù)據(jù)的獲取

javascript
import axios from 'axios';

export default {
  data() {
    return {
      jsonData: null,
    };
  },
  async created() {
    try {
      const response = await axios.get('https://api.example.com/data');
      this.jsonData = response.data;
    } catch (error) {
      console.error('Error fetching JSON data:', error);
    }
  },
};

首先，我們需要通過API接口或其他方式獲取JSON數(shù)據(jù)。以下是一個簡單的HTTP GET請求示例，使用axios庫獲取JSON數(shù)據(jù)：

2.2 JSON數(shù)據(jù)的模板渲染

html
<template>
  <div>
    <ul>
      <li v-for="user in jsonData.users" :key="user.id">
        ID: {{ user.id }} | Name: {{ user.name }} | Age: {{ user.age }}
      </li>
    </ul>
  </div>
</template>

對應的Vue模板代碼如下：

三、Vue中將JSON數(shù)據(jù)優(yōu)雅寫入文本文件

3.1 使用FileSaver.js實現(xiàn)下載



現(xiàn)在，只需在界面中添加一個按鈕觸發(fā)`exportJson`方法，用戶即可將JSON數(shù)據(jù)優(yōu)雅地保存為名為"data.json"的文本文件。

然后在Vue組件中使用：

四、Vue引入CDN的實戰(zhàn)技巧

4.1 為什么選擇CDN

CDN能有效減少網(wǎng)絡延遲、提高資源加載速度、減輕服務器壓力，從而提升應用性能和用戶體驗。對于Vue項目，引入CDN可以加速Vue核心庫、第三方依賴庫（如axios、lodash等）以及靜態(tài)資源（如圖片、字體等）的加載。

4.2 Vue核心庫CDN引入

html
<!DOCTYPE html>
<html lang="en">
<head>
  <!-- 替換為Vue CDN鏈接 -->
  <script src="https://cdn.jsdelivr.net/npm/vue@2"></script>
  <!-- 其他meta、link標簽... -->
</head>
<body>
  <!-- ... -->
</body>
</html>

在HTML文件中，直接替換本地Vue庫引用為CDN鏈接：

4.3 第三方庫CDN引入

html
<script src="https://cdn.jsdelivr.net/npm/axios@0.21"></script>
<script src="https://cdn.jsdelivr.net/npm/lodash@4.17"></script>

同樣地，第三方庫如axios、lodash等也可以通過CDN引入：

4.4 靜態(tài)資源CDN托管

html
<img src="https://example.cdn.com/path/to/image.jpg" alt="Image from CDN">
<link rel="stylesheet" href="https://example.cdn.com/path/to/font.css">

對于圖片、字體等靜態(tài)資源，建議將其上傳至云存儲服務（如阿里云OSS、騰訊云COS等），并獲取對應的CDN加速鏈接。在Vue項目中，直接使用CDN鏈接替代本地路徑：

4.5 備份方案與版本控制

盡管CDN可以顯著提升應用性能，但應考慮網(wǎng)絡波動、CDN服務不穩(wěn)定等情況，提供本地備份或備用CDN鏈接。同時，對CDN資源進行版本控制，確保在更新依賴時不影響線上應用。

五、結語

通過本文，您已掌握了如何在Vue項目中優(yōu)雅地處理JSON數(shù)據(jù)，包括獲取、渲染與導出，以及如何巧妙地引入CDN以提升應用性能。這些技巧將助力您打造更高效、更穩(wěn)定的Vue應用程序，為用戶提供卓越的Web體驗。持續(xù)關注本頭條號，了解更多前沿的Web前端開發(fā)知識與實戰(zhàn)技巧。

一篇文章我們介紹了一個html/xml解析器——htmlparser，這篇文章我們介紹另外一個解析模塊htmlparser2，后者是對前者的重構，同時對前者的API做了部分兼容。

用法簡介

安裝

const { Parser } = require('htmlparser2');
const parser = new Parser(handler, options);
parser.parseComplete('html/xml內(nèi)容');

寫法

const { Parser } = require('htmlparser2');
const parser = new Parser(handler, options);
parser.parseComplete('html/xml內(nèi)容');

htmlparser2提供了一個解析器——Parser，初始化它至少需要一個handler，options是可選的。

handler是一個對象，在這個對象上可以設置很多的鉤子函數(shù)，Parser解析時會在每個階段運行對應的鉤子函數(shù)。

以下是可以設置的所有的鉤子函數(shù)，

onopentag(<str> name, <obj> attributes)

onopentagname(<str> name)

onattribute(<str> name, <str> value)

ontext(<str> text)

onclosetag(<str> name)

onprocessinginstruction(<str> name, <str> data)

oncomment(<str> data)

oncommentend()

oncdatastart()

oncdataend()

onerror(<err> error)

onreset()

onend()

htmlparser模塊是通過正則表達式來解析html內(nèi)容的，而htmlparser2則不同，它會按順序讀取html的每個字符，并且推測后面字符是標簽名、屬性還是其他的類型，所以htmlparser2在解析完每一個標簽后都會運行相應的鉤子函數(shù)。

先來看一下例子，

圖1

圖1中設置了所有的鉤子函數(shù)以便來說明每個鉤子函數(shù)的作用，運行一下，

圖2

對照圖1和圖2就能看出來每個鉤子函數(shù)的運行時機，這其中有以下幾個鉤子函數(shù)需要注意一下。

oncdatastart和oncdataend會在解析<![CDATA[文本]]>標簽時觸發(fā)，但是觸發(fā)的前提是選項設置了recognizeCDATA=true或者xmlMode=true；
onprocessinginstruction會在解析<!xxyy>或者<?xxyy>這樣的標簽時觸發(fā)，xx和yy中間可以有分隔符（斜杠或者空格），分隔符前面的字符串就是鉤子函數(shù)中的name的值；
運行parseComplete方法會執(zhí)行reset鉤子函數(shù)，如果僅僅執(zhí)行parser的write或者end方法并不會執(zhí)行reset方法。

除了自定義handler以外，htmlparser2還提供了幾個handler，比如DomHandler，用法如下：

圖3

運行一下，我們看看結果，

圖4

如果4所示，DomHandler處理的結果是以數(shù)組的形式輸出的，在每個單元數(shù)據(jù)中還可以拿到上一個、下一個以及父節(jié)點的數(shù)據(jù)。

htmlparser2還可以通過操作流Stream解析內(nèi)容，寫法如下：

圖5

總結

這篇文章和上一篇是姊妹篇，都是介紹解析html/xml內(nèi)容的模塊，通過對比，我們發(fā)現(xiàn)htmlparser2模塊功能更強大一些，也更靈活一些，同時也兼容htmlparser模塊的一些接口。雖然兩者功能類似，但是這給了我們更多的選擇性。

喜歡我的文章就關注我吧，有問題可以發(fā)表評論，我們一起學習，共同成長！

自： https://twobithistory.org/2017/09/21/the-rise-and-rise-of-json.html
作者： Two-bit History
譯者： runningwater

JSON 已經(jīng)占領了全世界。當今，任何兩個應用程序彼此通過互聯(lián)網(wǎng)通信時，可以打賭它們在使用 JSON。它已被所有大型企業(yè)所采用：十大最受歡迎的 web API 接口列表中（主要由 Google、Facebook 和 Twitter 提供），僅僅只有一個 API 接口是以 XML 的格式開放數(shù)據(jù)的。¹這個列表中的 Twitter API 為此做了一個鮮活的注腳：其對 XML 格式的支持到 2013 年結束，其時發(fā)布的新版本的 API 取消 XML 格式，轉(zhuǎn)而僅使用 JSON。JSON 也在程序編碼級別和文件存儲上被廣泛采用：在 Stack Overflow（LCTT 譯注：一個面向程序員的問答網(wǎng)站）上，現(xiàn)在更多的是關于 JSON 的問題，而不是其他的數(shù)據(jù)交換格式。²

XML 仍然在很多地方存在。網(wǎng)絡上它被用于 SVG 和 RSS / Atom 信息流。Android 開發(fā)者想要獲得用戶權限許可時，需要在其 APP 的 manifest 文件中聲明 —— 此文件是 XML 格式的。XML 的替代品也不僅僅只有 JSON，現(xiàn)在有很多人在使用 YAML 或 Google 的 Protocol Buffers 等技術，但這些技術的受歡迎程度遠不如 JSON。目前來看，JSON 是應用程序在網(wǎng)絡之間通信的首選協(xié)議格式。

考慮到自 2005 年來 Web 編程世界就垂涎于 “異步 JavaScript 和 XML” 而非 “異步 JavaScript 和 JSON” 的技術潛力，你可以發(fā)現(xiàn) JSON 的主導地位是如此的讓人驚訝。當然了，這可能與這兩種通信格式的受歡迎程度無關，而僅反映出縮寫 “AJAX” 似乎比 “AJAJ” 更具吸引力。但是，即使在 2005 年有些人（實際上沒有太多人）已經(jīng)用 JSON 來取代 XML 了，我們不禁要問 XML 的噩運來的如此之快，以至于短短十來年，“異步 JavaScript 和 XML” 這個名稱就成為一個很諷刺的誤稱。那這十來年發(fā)生了什么？JSON 怎么會在那么多應用程序中取代了 XML？現(xiàn)在被全世界工程師和系統(tǒng)所使用、依賴的這種數(shù)據(jù)格式是誰提出的？

JSON 之誕生

2001 年 4 月，首個 JSON 格式的消息被發(fā)送出來。此消息是從舊金山灣區(qū)某車庫的一臺計算機發(fā)出的，這是計算機歷史上重要的的時刻。Douglas Crockford 和 Chip Morningstar 是一家名為 State Software 的技術咨詢公司的聯(lián)合創(chuàng)始人，他們當時聚集在 Morningstar 的車庫里測試某個想法，發(fā)出了此消息。

在 “AJAX” 這個術語被創(chuàng)造之前，Crockford 和 Morningstar 就已經(jīng)在嘗試構建好用的 AJAX 應用程序了，可是瀏覽器對其兼容性不好。他們想要在初始頁面加載后就將數(shù)據(jù)傳遞給應用程序，但其目標要針對所有的瀏覽器，這就實現(xiàn)不了。

這在今天看來不太可信，但是要記得 2001 年的時候 Internet Explorer（IE）代表了網(wǎng)頁瀏覽器的最前沿技術產(chǎn)品。早在 1999 年的時候，Internet Explorer 5 就支持了原始形式的 XMLHttpRequest，開發(fā)者可以使用名為 ActiveX 的框架來訪問此對象。Crockford 和 Morningstar 能夠使用此技術（在 IE 中）來獲取數(shù)據(jù)，但是在 Netscape 4 中（這是他們想要支持的另一種瀏覽器）就無法使用這種解決方案。為此 Crockford 和 Morningstar 只得使用一套不同的系統(tǒng)以兼容不同的瀏覽器。

第一條 JSON 消息如下所示：

<html><head><script>
document.domain = 'fudco';
parent.session.receive(
{ to: "session", do: "test",
text: "Hello world" }
)
</script></head></html>

消息中只有一小部分類似于今天我們所知的 JSON，本身其實是一個包含有一些 JavaScript 的 HTML 文檔。類似于 JSON 的部分只是傳遞給名為 receive() 的函數(shù)的 JavaScript 對象字面量。

Crockford 和 Morningstar 決定濫用 HTML 的幀（<frame>）以發(fā)送數(shù)據(jù)。他們可以讓一個幀指向一個返回的上述 HTML 文檔的 URL。當接收到 HTML 時，JavaScript 代碼段就會運行，就可以把數(shù)據(jù)對象字面量如實地傳遞回應用程序。只要小心的回避瀏覽器保護策略（即子窗口不允許訪問父窗口），這種技術就可以正常運行無誤。可以看到 Crockford 和 Mornginstar 通過明確地設置文檔域這種方法來達到其目的。（這種基于幀的技術，有時稱為隱藏幀技術，通常在 90 年代后期，即在廣泛使用 XMLHttpRequest 技術之前使用。³）

第一個 JSON 消息的驚人之處在于，它顯然不是一種新的數(shù)據(jù)格式的首次使用。它就是 JavaScript！實際上，以此方式使用 JavaScript 的想法如此簡單，Crockford 自己也說過他不是第一個這樣做的人。他說 Netscape 公司的某人早在 1996 年就使用 JavaScript 數(shù)組字面量來交換信息。⁴因為消息就是 JavaScript，其不需要任何特殊解析工作，JavaScript 解釋器就可搞定一切。

最初的 JSON 信息實際上與 JavaScript 解釋器發(fā)生了沖突。JavaScript 保留了大量的關鍵字（ECMAScript 6 版本就有 64 個保留字），Crockford 和 Morningstar 無意中在其 JSON 中使用了一個保留字。他們使用了 do 作為了鍵名，但 do 是解釋器中的保留字。因為 JavaScript 使用的保留字太多了，Crockford 做了決定：既然不可避免的要使用到這些保留字，那就要求所有的 JSON 鍵名都加上引號。被引起來的鍵名會被 JavaScript 解釋器識別成字符串，其意味著那些保留字也可以放心安全的使用。這就為什么今天 JSON 鍵名都要用引號引起來的原因。

Crockford 和 Morningstar 意識到這技術可以應用于各類應用系統(tǒng)。想給其命名為 “JSML”，即JavaScript 標記語言(JavaScript Markup Language)的意思，但發(fā)現(xiàn)這個縮寫已經(jīng)被一個名為 Java Speech 標記語言的東西所使用了。因此他們決定采用 “JavaScript Object Notation”，縮寫為 JSON。他們開始向客戶推銷，但很快發(fā)現(xiàn)客戶不愿意冒險使用缺乏官方規(guī)范的未知技術。所以 Crockford 決定寫一個規(guī)范。

2002 年，Crockford 買下了 JSON.org 域名，放上了 JSON 語法及一個解釋器的實例例子。該網(wǎng)站仍然在運行，現(xiàn)在已經(jīng)包含有 2013 年正式批準的 JSON ECMA 標準的顯著鏈接。在該網(wǎng)站建立后，Crockford 并沒有過多的推廣，但很快發(fā)現(xiàn)很多人都在提交各種不同編程語言的 JSON 解析器實現(xiàn)。JSON 的血統(tǒng)顯然與 JavaScript 相關聯(lián)，但很明顯 JSON 非常適合于不同語言之間的數(shù)據(jù)交換。

AJAX 導致的誤會

2005 年，JSON 有了一次大爆發(fā)。那一年，一位名叫 Jesse James Garrett 的網(wǎng)頁設計師和開發(fā)者在博客文章中創(chuàng)造了 “AJAX” 一詞。他很謹慎地強調(diào)：AJAX 并不是新技術，而是 “好幾種蓬勃發(fā)展的技術以某種強大的新方式匯集在一起。⁵” AJAX 是 Garrett 給這種正受到青睞的 Web 應用程序的新開發(fā)方法的命名。他的博客文章接著描述了開發(fā)人員如何利用 JavaScript 和 XMLHttpRequest 構建新型應用程序，這些應用程序比傳統(tǒng)的網(wǎng)頁更具響應性和狀態(tài)性。他還以 Gmail 和 Flickr 網(wǎng)站已經(jīng)使用 AJAX 技術作為了例子。

當然了，“AJAX” 中的 “X” 代表 XML。但在隨后的問答帖子中，Garrett 指出，JSON 可以完全替代 XML。他寫道：“雖然 XML 是 AJAX 客戶端進行數(shù)據(jù)輸入、輸出的最完善的技術，但要實現(xiàn)同樣的效果，也可以使用像 JavaScript Object Notation（JSON）或任何類似的結構數(shù)據(jù)方法等技術。 ”⁶

開發(fā)者確實發(fā)現(xiàn)在構建 AJAX 應用程序時可以很容易的使用 JSON，許多人更喜歡它而不是 XML。具有諷刺意味的是，對 AJAX 的興趣逐漸的導致了 JSON 的普及。大約在這個時候，JSON 引起了博客圈的注意。

2006 年，Dave Winer，一位高產(chǎn)的博主，他也是許多基于 XML 的技術（如 RSS 和 XML-RPC）背后的開發(fā)工程師，他抱怨到 JSON 毫無疑問的正在重新發(fā)明 XML。盡管人們認為數(shù)據(jù)交換格式之間的競爭不會導致某一技術的消亡。其寫到：

毫無疑問，我可以編寫一個例程來解析 JSON，但來看看他們要重新發(fā)明一個東西有多大的意義，出于某種原因 XML 本身對他們來說還不夠好（我很想聽聽原因）。誰想干這荒謬之事？查找一棵樹然后把節(jié)點串起來。可以立馬試試。⁷

我很理解 Winer 的挫敗感。事實上并沒有太多人喜歡 XML。甚至 Winer 也說過他不喜歡 XML。⁸但 XML 已被設計成一個可供任何人使用，并且可以用于幾乎能想象到的所有事情。歸根到底，XML 實際上是一門元語言，允許你為特定應用程序自定義該領域特定的語言。如 Web 信息流技術 RSS 和 SOAP（簡單對象訪問協(xié)議）就是例子。Winer 認為由于通用交換格式所帶來的好處，努力達成共識非常重要。XML 的靈活性應該能滿足任何人的需求，然而 JSON 格式呢，其并沒有比 XML 提供更多東西，除了它拋棄了使 XML 更靈活的那些繁瑣的東西。

Crockford 閱讀了 Winer 的這篇文章并留下了評論。為了回應 JSON 重新發(fā)明 XML 的指責，Crockford 寫到：“重造輪子的好處是可以得到一個更好的輪子。”⁹

JSON 與 XML 對比

到 2014 年，JSON 已經(jīng)由 ECMA 標準和 RFC 官方正式認可。它有了自己的 MIME 類型。JSON 已經(jīng)進入了大聯(lián)盟時代。

為什么 JSON 比 XML 更受歡迎？

在 JSON.org 網(wǎng)站上，Crockford 總結了一些 JSON 的優(yōu)勢。他寫到，JSON 的語法極少，其結構可預測，因此 JSON 更容易被人類和機器理解。¹⁰其他博主一直關注 XML 的冗長啰嗦及“尖括號負擔”。¹¹XML 中每個開始標記都必須與結束標記匹配，這意味著 XML 文檔包含大量的冗余信息。在未壓縮時，XML 文檔的體積比同等信息量 JSON 文檔的體積大很多，但是，更重要的，這也使 XML 文檔更難以閱讀。

Crockford 還聲稱 JSON 的另一個巨大優(yōu)勢是其被設計為數(shù)據(jù)交換格式。¹²從一開始，它的目的就是在應用程序間傳遞結構化信息的。而 XML 呢，雖然也可以使用來傳遞數(shù)據(jù)，但其最初被設計為文檔標記語言。它演變自 SGML（通用標準標記語言），而它又是從被稱為 Scribe 的標記語言演變而來，其旨在發(fā)展成類似于 LaTeX 一樣的文字處理系統(tǒng)。XML 中，一個標簽可以包含有所謂的“混合內(nèi)容”，即帶有圍繞單詞、短語的內(nèi)嵌標簽的文本。這會讓人浮現(xiàn)出一副用紅藍筆記錄的手稿畫面，這是標記語言核心思想的形象比喻。另一方面，JSON 不支持對混合內(nèi)容模型的清晰構建，但這也意味著它的結構足夠簡單。一份文檔最好的建模就是一棵樹，但 JSON 拋棄了這種文檔的思想，Crockford 將 JSON 抽象限制為字典和數(shù)組，這是所有程序員構建程序時都會使用的最基本的、也最熟悉的元素。

最后，我認為人們不喜歡 XML 是因為它讓人困惑。它讓人迷惑的地方就是有很多不同的風格。乍一看，XML 本身及其子語言（如 RSS、ATOM、SOAP 或 SVG）之間的界限并不明顯。典型的 XML 文檔的第一行標識了該 XML 的版本，然后該 XML 文檔應該符合特定的子語言。這就有變化需要考慮了，特別是跟 JSON 做比較，JSON 是如此簡單，以至于永遠不需要編寫新版本的 JSON 規(guī)范。XML 的設計者試圖將 XML 做為唯一的數(shù)據(jù)交換格式以支配所有格式，就會掉入那個經(jīng)典的程序員陷阱：過度工程化。XML 非常籠統(tǒng)及概念化，所以很難于簡單的使用。

在 2000 年的時候，發(fā)起了一場使 HTML 符合 XML 標準的活動，發(fā)布了一份符合 XML 標準的 HTML 開發(fā)規(guī)范，這就此后很出名的 XHTML。雖然一些瀏覽器廠商立即開始支持這個新標準，但也很明顯，大部分基于 HTML 技術的開發(fā)者不愿意改變他們的習慣。新標準要求對 XHTML 文檔進行嚴格的驗證，而不是基于 HTML 的基準。但大多的網(wǎng)站都是依賴于 HTML 的寬容規(guī)則的。到 2009 年的時候，試圖編寫第二版本的 XHTML 標準的努力已經(jīng)流產(chǎn)，因為未來已清晰可見，HTML 將會發(fā)展為 HTML5（一種不強制要求接受 XML 規(guī)則的標準）。

如果 XHTML 的努力取得了成功，那么 XML 可能會成為其設計者所希望的通用數(shù)據(jù)格式。想象一下，一個 HTML 文檔和 API 響應具有完全相同結構的世界。在這樣的世界中，JSON 可能不會像現(xiàn)在一樣普遍存在。但我把 HTML 的失敗看做是 XML 陣營的一種道義上的失敗。如果 XML 不是 HTML 的最佳工具，那么對于其他應用程序，也許會有更好的工具出現(xiàn)。在這個世界，我們的世界，很容易看到像 JSON 格式這樣的足夠簡單、量體裁衣的才能獲得更大的成功。

如果你喜歡這博文，每兩周會更新一次！請在 Twitter 上關注 @TwoBitHistory 或訂閱 RSS feed ，以確保得到更新的通知。

http://www.cs.tufts.edu/comp/150IDS/final_papers/tstras01.1/FinalReport/FinalReport.html#software ?
https://insights.stackoverflow.com/trends?tags=json%2Cxml%2Cprotocol-buffers%2Cyaml%2Ccsv ?
Zakas, Nicholas C., et al. “What Is Ajax?” Professional Ajax, 2nd ed., Wiley, 2007. ?
https://youtu.be/-C-JoyNuQJs?t=32s ?
http://adaptivepath.org/ideas/ajax-new-approach-web-applications/ ?
同上 ?
http://scripting.com/2006/12/20.html ?
http://blogoscoped.com/archive/2009-03-05-n15.html ?
https://scripting.wordpress.com/2006/12/20/scripting-news-for-12202006/#comment-26383 ?
http://www.json.org/xml.html ?
https://blog.codinghorror.com/xml-the-angle-bracket-tax ?
https://youtu.be/-C-JoyNuQJs?t=33m50sgg ?

via: https://twobithistory.org/2017/09/21/the-rise-and-rise-of-json.html

作者： Two-Bit History 選題： lujun9972 譯者： runningwater 校對： wxy

本文由 LCTT 原創(chuàng)編譯， Linux中國榮譽推出

點擊“了解更多”可訪問文內(nèi)鏈接

在線咨詢

上一篇：快速上手的移動端UI匯總，資源也是成長的一部分「薦」
下一篇：e起學丨WEB安全滲透測試基礎知識（六）

您的項目需求

*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。

整合營銷服務商

&amp;quot;精通Vue：手把手教你將JSON數(shù)據(jù)優(yōu)雅寫入文本，并深度