整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
VvvebJs是一個開源的網頁拖拽自動生成的JavaScript庫，你可以以簡單拖拽的方式生成自己需要的網頁樣式，內置jquery和Bootstrap，你可以拖拽相關的組件進行網頁的構建，非常的方便，而且可以實時修改代碼，功能豐富，使用簡單，界面友好，特別適合一些專注于展示的網頁設計，需要的朋友不可錯過！
https://github.com/givanz/VvvebJs
默認情況下，編輯器附帶Bootstrap 4和Widgets組件，可以使用任何類型的組件和輸入進行擴展。
如下代碼：
<!-- jquery-->
<script src="js/jquery.min.js"></script>
<script src="js/jquery.hotkeys.js"></script>
<!-- bootstrap-->
<script src="js/popper.min.js"></script>
<script src="js/bootstrap.min.js"></script>
<!-- builder code-->
<script src="libs/builder/builder.js"></script>
<!-- undo manager-->
<script src="libs/builder/undo.js"></script>
<!-- inputs-->
<script src="libs/builder/inputs.js"></script>
<!-- components-->
<script src="libs/builder/components-bootstrap4.js"></script>
<script src="libs/builder/components-widgets.js"></script>
<script>
$(document).ready(function()
{
Vvveb.Builder.init('demo/index.html', function() {
//load code after page is loaded here
Vvveb.Gui.init();
});
});
</script>
要初始化編輯器，調用Vvveb.Builder.init。第一個參數是要加載以進行編輯的URL，它必須位于相同的子域中才能進行編輯。第二個參數是頁面加載完成時調用的函數，默認情況下調用編輯器Gui.init();
Component Group是一個組件集合，例如Bootstrap 4組由Button和Grid等組件組成，該對象僅用于在編輯器左側面板中對組件進行分組。例如，Widgets組件組只有兩個組件視頻和地圖，并被定義為如下
Vvveb.ComponentsGroup['Widgets'] = ["widgets/googlemaps", "widgets/video"];
Component是一個對象，它提供可以在畫布上放置的html以及在選擇組件時可以編輯的屬性，例如Video Component，具有Url和Target屬性的html鏈接Component定義為：
Vvveb.Components.extend("_base", "html/link", {
nodes: ["a"],
name: "Link",
properties: [{
name: "Url",
key: "href",
htmlAttr: "href",
inputtype: LinkInput
}, {
name: "Target",
key: "target",
htmlAttr: "target",
inputtype: TextInput
}]
});
在Component屬性集合中使用Input對象來編輯屬性，例如文本輸入，選擇，顏色，網格行等。例如，TextInput擴展Input對象并定義為：
var TextInput = $.extend({}, Input, {
events: {
"keyup": ['onChange', 'input'],
},
setValue: function(value) {
$('input', this.element).val(value);
},
init: function(data) {
return this.render("textinput", data);
},
}
);
輸入還需要一個在編輯器html（在editor.html中）定義為<script>標簽的模板，其id為vvveb-input-inputname，例如對于文本輸入為vvveb-input-textinput，定義：
<script id="vvveb-input-textinput" type="text/html">
<div>
<input name="{%=key%}" type="text" class="form-control"/>
</div>
</script>
以上是借助瀏覽器翻譯工具，對官網的文檔進行簡單的翻譯，可能會有些不夠準確的地方，感興趣的小伙伴可以直接查看相關文檔！
VvvebJs是一個非常強大的網頁可視化生成構建工具，讓不懂網頁設計的小伙伴們也能夠通過拖拽來生成美觀大方的網頁出來，讓設計網頁就像設計圖片一樣，VvvebJs特別適合展示型網頁，甚至可以不需要代碼就能完成一項復雜的網頁設計，總體來說，VvvebJs是一個值得嘗試的工具！
文本標記語言（英語：HyperText Markup Language，簡稱：HTML）是一種用于創建網頁的標準標記語言。HTML是一種基礎技術，常與CSS、JavaScript一起被眾多網站用于設計令人賞心悅目的網頁、網頁應用程序以及移動應用程序的用戶界面。網頁瀏覽器可以讀取HTML文件，并將其渲染成可視化網頁。HTML描述了一個網站的結構語義隨著線索的呈現，使之成為一種標記語言而非編程語言。
HTML元素是構建網站的基石。HTML允許嵌入圖像與對象，并且可以用于創建交互式表單，它被用來結構化信息——例如標題、段落和列表等等，也可用來在一定程度上描述文檔的外觀和語義。HTML的語言形式為尖括號包圍的HTML元素（如<html>），瀏覽器使用HTML標簽和腳本來詮釋網頁內容，但不會將它們顯示在頁面上。
HTML可以嵌入如JavaScript的腳本語言，它們會影響HTML網頁的行為。網頁瀏覽器也可以引用層疊樣式表（CSS）來定義文本和其它元素的外觀與布局。維護HTML和CSS標準的組織萬維網聯盟（W3C）鼓勵人們使用CSS替代一些用于表現的HTML元素。
歷史
W3C制作的早期HTML標志
發展
蒂姆·伯納斯-李
1980年，物理學家蒂姆·伯納斯-李在歐洲核子研究中心（CERN）在承包工程期間，為使CERN的研究人員使用并共享文檔，他提出并創建原型系統ENQUIRE。1989年，伯納斯-李在一份備忘錄中提出一個基于互聯網的超文本系統。他規定HTML并在1990年底寫出瀏覽器和服務器軟件。同年，伯納斯-李與CERN的數據系統工程師羅伯特·卡里奧聯合為項目申請資助，但未被CERN正式批準。在他的個人筆記中伯納斯-李列舉“一些使用超文本的領域”，并把百科全書列為首位。
HTML的首個公開描述出現于一個名為“HTML標簽”的文件中，由蒂姆·伯納斯-李于1991年底提及。它描述18個元素，包括HTML初始的、相對簡單的設計。除了超鏈接標簽外，其他設計都深受CERN內部一個以標準通用標記語言（SGML）為基礎的文件格式SGMLguid的影響。這些元素在HTML 4中仍有11個存在。
伯納斯-李認為HTML是SGML的一個應用程序。1993年中期互聯網工程任務組（IETF）發布首個HTML規范的提案：“超文本標記語言（HTML）”互聯網草案，由伯納斯-李與丹·康納利（英語：Dan Connolly (computer scientist)）撰寫。其中包括一個SGML文檔類型定義來定義語法。草案于6個月后過期，不過值得注意的是其對NCSA Mosaic瀏覽器自定義標簽從而將在線圖像嵌入的行為的認可，這反映IETF把標準立足于成功原型的理念。同樣，戴夫·拉格特（英語：Dave Raggett）在1993年末提出的與之競爭的互聯網草案“HTML+（超文本標記格式）”建議規范已經實現的功能，如表格與填寫表單。
在HTML和HTML+的草案于1994年初到期后，IETF創建一個HTML工作組，并在1995年完成"HTML 2.0"，這是第一個旨在成為對其后續實現標準的依據的HTML規范。
在IETF的主持下，HTML標準的進一步發展因競爭利益而遭受停滯。自1996年起，HTML規范一直由萬維網聯盟（W3C）維護，并由商業軟件廠商出資。不過在2000年，HTML也成為國際標準（ISO/ IEC15445：2000）。HTML 4.01于1999年末發布，進一步的勘誤版本于2001年發布。2004年，網頁超文本應用技術工作小組（WHATWG）開始開發HTML5，并在2008年與W3C共同交付，2014年10月28日完成標準化。
版本時間線
1995年11月24日
HTML 2.0作為IETF RFC 1866發布。追加RFC的附加功能：
1995年11月25日：RFC 1867（基于表單的文件上傳）
1996年5月：RFC 1942（表格）
1996年8月：RFC 1980（客戶端圖像映射）
1997年1月：RFC 2070（國際化）
1997年1月14日
HTML 3.2作為W3C推薦標準發布。這是首個完全由W3C開發并標準化的版本，因IETF于1996年9月12日關閉它的HTML工作組。
最初代號為“威爾伯”（Wilbur），HTML 3.2完全去除數學公式，協調各種專有擴展，并采用網景設計的大多數視覺標記標簽。由于兩家公司達成了協議，網景的閃爍元素（英語：blink element）和微軟的滾動元素（英語：marquee element）被移除。HTML對數學公式的支持最后成為另外一種被稱為MathML的標準。
1997年12月18日
HTML 4.0作為W3C推薦標準發布。它提供三種變化：
嚴格，過時的元素被禁止。
過渡，過時的元素被允許。
框架集，大多只與框架相關的元素被允許。
最初代號“美洲獅”（Cougar）， HTML 4.0采用許多特定瀏覽器的元素類型和屬性，并試圖淘汰網景的視覺標記功能，將其標記為不贊成使用。HTML 4是遵循ISO 8879 - SGML的SGML應用程序。
1998年4月24日
HTML 4.0進行微調，不增加版本號。
1999年12月24日
HTML 4.01作為W3C推薦標準發布。它同樣提供三種變化，最終勘誤版于2001年5月12日發布。
2000年5月
ISO/IEC 15445:2000（"ISO HTML"，基于HTML 4.01嚴格版）作為ISO/IEC國際標準發布。在ISO中這一標準位于ISO/IEC JTC 1/SC 34（英語：ISO/IEC JTC 1/SC 34）域（ISO/IEC聯合技術委員會1、小組委員會34 – 文檔描述與處理語言）。
2014年10月28日
HTML 5作為W3C推薦標準發布。
草案時間線
HTML5的Logo
1991年10月
HTML標簽，一個非正式CERN文件首次公開18個HTML標簽。
1992年6月
HTML DTD的首個非正式草案， 后續有七個修訂版（7月15日，8月6日，8月18日，11月17日，11月19日，11月20日，11月22日）。
1992年11月
HTML DTD 1.1（首個版本號，基于RCS修訂版，版本號從1.1開始而非1.0），非正式草案。
1993年6月
超文本標記語言由IETF IIIR工作小組作為互聯網草案（一個粗略的建議標準）。在被第二版代一個月后，IETF又發布6個草案，最終在RFC1866中發布HTML 2.0。
1993年11月
HTML+由IETF作為互聯網草案發布，是超文本標記語言草案的一個競爭性提案。它于1994年5月到期。
1995年4月 （1995年3月編寫）
HTML 3.0[33]被提議作為IETF的標準，但直到提案在五個月過期后（1995年9月28日）仍沒有進一步的行動。它包含許多拉格特HTML+提案的功能，如對表格的支持、圍繞數據的文本流和復雜的數學公式的顯示。W3C開始開發自己的Arena瀏覽器作為HTML 3和層疊樣式表的試驗臺（英語：Test bed），但HTML 3.0并沒有獲得成功。瀏覽器廠商，包括微軟和網景，選擇實現HTML3草案功能的不同子集并引入它們自己的插件（見瀏覽器大戰）。
2008年1月
HTML5由W3C作為工作草案（鏈接）發布。雖然HTML5的語法非常類似于SGML，但它已經放棄任何成為SGML應用程序的嘗試，除了一種替代的基于XML的HTML5序列，它已明確定義自己的“HTML”序列。
2011年 HTML5 – 最終征求
2011年5月，工作小組將HTML5推進至“最終征求”（Last Call）階段，邀請W3C社區內外人士以確認本規范的技術可靠性。W3C開發一套綜合性測試套件來實現完整規范的廣泛交互操作性，完整規范的目標日期為2014年。2011年1月，WHATWG將其“HTML5”活動標準重命名為“HTML”。W3C仍然繼續其發布HTML5的項目。
2012年 HTML5 – 候選推薦
2012年7月，WHATWG和W3C的工作產生一定程度的分離。W3C繼續HTML5規范工作，重點放在單一明確的標準上，這被WHATWG稱為“快照”。WHATWG組織則將HTML5作為一個“活動標準”（Living Standard）。活動標準的概念是從未完成但永遠保持更新與改進，可以添加新特性，但功能點不會被刪除。
2012年12月，W3C指定HTML5作為候選推薦階段。 該階段的標準為“兩個100％完成，完全實現交互操作”。
2014年 HTML5 – 提案推薦與推薦
2014年9月，HTML5進入提案推薦階段。
2014年10月28日，HTML5作為穩定W3C推薦標準發布，這意味著HTML5的標準化已經完成。
XHTML版本
XHTML是使用XML 1.0改寫自HTML 4.01的獨立語言。它不再被作為單獨標準開發。
XHTML 1.0， 2000年1月26日作為W3C推薦標準發布。修訂版于2002年8月1日發布，它提供與HTML 4.0和4.01相同的三個變化，這些變化被重新在XML中制定。
XHTML 1.1，基于XHTML 1.0 嚴格版，2001年5月31日 作為W3C推薦標準發布。修訂版可使用模塊化XHTML的模塊，2001年4月10日作為W3C推薦標準發布。
XHTML 2.0為工作草案，但為支持HTML5與XHTML5的工作，此草案被放棄。 XHTML 2.0與XHTML 1.x不兼容，因此更確切的說這是一個XHTML風格的新語言而不是XHTML 1.x的更新。
在HTML5草案中規定一個XHTML語法，稱為“XHTML5.1”。
標記
HTML標記包含標簽（及其屬性）、基于字符的數據類型、字符引用和實體引用等幾個關鍵部分。HTML標簽是最常見的，通常成對出現，比如<h1>與</h1>。這些成對出現的標簽中，第一個標簽是開始標簽，第二個標簽是結束標簽。兩個標簽之間為元素的內容，有些標簽沒有內容，為空元素，如<img>。
HTML另一個重要組成部分為文檔類型聲明（英語：document type declaration），這會觸發標準模式渲染。
以下是一個經典的Hello World程序的例子：
<!DOCTYPE html>
<html>
<head>
<title>This is a title</title>
</head>
<body>
<p>Hello world!</p>
</body>
</html>
<html>和</html>之間的文本描述網頁，<body>和</body>之間的文本為可視頁面內容。標記文本<title>This is a title</title>定義了瀏覽器的頁面標題。
文檔標記類型<!DOCTYPE html>用于HTML5。 如果未進行聲明，瀏覽器會使用“怪異模式”進行渲染。
元素
HTML文檔由嵌套的HTML元素構成。它們用HTML標簽表示，包含于尖括號中，如<p>
在一般情況下，一個元素由一對標簽表示：“開始標簽”<p>與“結束標簽”</p>。元素如果含有文本內容，就被放置在這些標簽之間。
在開始與結束標簽之間也可以封裝另外的標簽，包括標簽與文本的混合。這些嵌套元素是父元素的子元素。
開始標簽也可包含標簽屬性。這些屬性有諸如標識文檔區段、將樣式信息綁定到文檔演示和為一些如<img>等的標簽嵌入圖像、引用圖像來源等作用。
一些元素如換行符<br>，不允許嵌入任何內容，無論是文字或其他標簽。這些元素只需一個單一的空標簽（類似于一個開始標簽），無需結束標簽。
許多標簽是可選的，尤其是那些很常用的段落元素<p>的閉合端標簽。HTML瀏覽器或其他媒介可以從上下文識別出元素的閉合端以及由HTML標準所定義的結構規則。這些規則非常復雜，不是大多數HTML編碼人員可以完全理解的。
因此，一個HTML元素的一般形式為：<tag attribute1="value1" attribute2="value2">''content''</tag>。一些HTML元素被定義為空元素，其形式為<tag attribute1="value1" attribute2="value2">。空元素不能封裝任何內容。例如<br>標簽或內聯標簽<img>。一個HTML元素的名稱即為標簽使用的名稱。注意，結束標簽的名稱前面有一個斜杠“/”，空元素不需要也不允許結束標簽。如果元素屬性未標明，則使用其默認值。
例子
HTML文檔的頁眉：<head>...</head>。標題被包含在頭部，例如：
<head>
<title>The Title</title>
</head>
標題：HTML標題由<h1>到<h6>六個標簽構成，字體由大到小遞減：
<h1>Heading level 1</h1>
<h2>Heading level 2</h2>
<h3>Heading level 3</h3>
<h4>Heading level 4</h4>
<h5>Heading level 5</h5>
<h6>Heading level 6</h6>
段落：
<p>第一段</p> <p>第二段</p>
換行：<br>。<br>與<p>之間的差異是br換行但不改變頁面的語義結構，而p部分的頁面成段。
<p>這是<br>一個<br>使用換行<br>段落</p>
鏈接：使用<a>標簽來創建鏈接。href屬性包含鏈接的URL地址。
<a >中文維基百科的連結！</a>
注釋：
<!-- This is a comment -->
注釋有助于理解標記，但它不會在網頁上顯示。
HTML中存在以下幾種類型的標記元素：
用于文本的結構式標記
例如，<h2>羽毛球</h2>將“羽毛球”定義為二級標題。結構式標記不指示任何特定的渲染，但大多數網頁瀏覽器都會采用元素格式的默認樣式。要在內容上實現進一步的風格可以使用層疊樣式表（CSS）。
用于文本外觀的表現式標記，不論其目的
例如，<b>粗體</b>表示視覺輸出設備應將文本“粗體”加粗，但如果設備無法做到這一點（如朗讀文本的聽覺設備），就不會發生什么現象。在這種情況下，<b>粗體</b>與''斜體''也可能有相同的視覺效果，但在本質上它們更加語義化。如同<strong>加強文字</strong>與<em>強調文字</em>的區別。為支持CSS的使用，大多數表現式標記在HTML 4.0規范中不再被推薦使用。
超文本標記使文檔的一部分鏈接到其他文檔
錨元素在文檔中創建超鏈接，其href屬性設置鏈接的目標URL。例如：HTML標記<a 渲染為超鏈接。要將圖片渲染為超鏈接，img元素要作為內容插入到a元素中：<a ><img src="image.gif" alt="說明文字" width="50" height="50" border="0"></a>。
屬性
大多數元素的屬性以“名稱-值”的形式成對出現，由“=”分離并寫在開始標簽元素名之后。值一般由單引號或雙引號包圍，有些值的內容包含特定字符，在HTML中可以去掉引號（XHTML不行）。不加引號的屬性值被認為是不安全的[58]。有些屬性無需成對出現，僅存在于開始標簽中即可影響元素[6]，如img 元素的ismap 屬性。
許多元素存在一些共通的屬性：
id屬性為元素提供了在全文檔內的唯一標識。它用于識別元素，以便樣式表可以改變其表現屬性，腳本可以改變、顯示或刪除其內容或格式化。對于添加到頁面的URL，它為元素提供了一個全局唯一標識，通常為頁面的子章節。例如，ID "屬性"對于https://zh.wikipedia.org/wiki/HTML#屬性
class屬性提供一種將類似元素分類的方式。常被用于語義化或格式化。例如，一個HTML文檔可指定類<class="標記">來表明所有具有這一類值的元素都從屬于文檔的主文本。格式化后，這樣的元素可能會聚集在一起，并作為頁面腳注而不會出現在HTML代碼中。類屬性也被用于微格式的語義化。類值也可進行多聲明。如<class="標記 重要">將元素同時放入標記與重要兩類中。
style屬性可以將表現性質賦予一個特定元素。比起使用id或class 屬性從樣式表中選擇元素，“style”被認為是一個更好的做法，盡管有時這對一個簡單、專用或特別的樣式顯得太繁瑣。
title屬性用于給元素一個附加的說明。 大多數瀏覽器中這一屬性顯示為工具提示（英語：Tooltip）。
lang屬性用于識別元素內容的語言，它可能與文檔的主要語言不同。例如，在中文文檔中：
<p>法語<span lang="fr">c'est la vie</span>在法國的應用很普遍，意為“這就是生活” 。<p>
縮寫元素abbr可用于說明一些屬性：
<abbr id="ID" class="術語" style="color:purple;" title="超文本標記語言">HTML</abbr>
這個例子顯示為HTML； 在大多數瀏覽器中，光標指向縮寫時會顯示標題文字“超文本標記語言”。
大多數元素采用與語言相關的屬性dir 來指定文字方向，如 "rtl"采用從右到左的文本，比如阿拉伯語、波斯語以及希伯來語。
字符與實體引用
參見：XML與HTML字符實體引用列表和Unicode與HTML
在4.0版本中，HTML定義了一系列共252個字符實體引用和1,114,050個字元值參考。二者都支持單個字符通過簡單的標記寫入。文字字符與其對應的標記渲染的效果相同。
用這種方式“轉義”字符的能力允許字符<與&（當分別被寫作<和&時）被理解為字符數據而不是標記。例如<通常為標簽的開頭，&通常為字符實體引用與數字字符引用的開頭；&或&或&將&作為元素的內容或屬性的值。雙引號字符"在不被用于屬性值的標示時必須轉義為"或"或"；相等地，當于單引號字符'不被用于屬性值的標示時，也必須轉義為'或'（或HTML5與XHTML文檔中的'）。
如果文檔作者忽略了轉義這樣的字符，一些瀏覽器會嘗試通過上下文猜測他們的意圖。如果結果仍為無效標記，這會使其他瀏覽器或用戶代理難以訪問到該文檔，并使它們嘗試使用搜索和索引來解析該文檔。
那些難以輸入或不在該文檔字符編碼中的字符也可通過轉義來實現。例如通常只在西歐或南美的鍵盤出現的重音符e（é），可以在HTML文檔中用作實體引用é 或數字引用é或é。 諸如UTF-8的Unicode字符編碼與所有的現代瀏覽器兼容并允許直接訪問全球書寫系統幾乎所有的字符 。
數據類型
HTML為元素內容定義了多種數據類型，如腳本數據、樣式表數據以及許多屬性值的類型，包括ID、名稱、URI、數字長度單位、語言、媒體描述符顏色、字符編碼、日期和時間等等。所有這些數據類型都是字符數據的特殊化。
文檔類型聲明
HTML文檔需要以文檔類型聲明（英語：document type declaration）（英語非正式說法“doctype”）開頭。在瀏覽器中，文檔類型聲明有助于確定渲染模式——特別是是否使用怪異模式。
文檔類型聲明的初衷是通過基于文檔類型定義（DTD）的SGML工具來解析并驗證HTML文檔。
HTML5未定義DTD，所以在HTML5中文檔類型聲明更為簡短：
<!DOCTYPE html>
HTML 4文檔類型聲明舉例：
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
該聲明引用HTML 4.01“嚴格”版的DTD。基于SGML的驗證器可讀取DTD，正確解析這些文檔并執行驗證。在現代瀏覽器中，一個有效的文檔類型激活標準模式有別于怪異模式。
另外，HTML 4.01提供過渡型與框架集型的DTD。過渡型涵蓋最廣，它可整合當前以及老舊或“過時”的標簽，而嚴格型DTD排除了過時的標簽。框架集擁有所有構建框架所需的標簽以及過渡型的標簽。
語義化HTML
語義化HTML是一種編寫HTML的方式，它強調編碼信息的含義在其格式（樣子）之上。HTML從創立之初就包括語義化標記，但也包括標識性標記如<font>、<i>和<center>標簽。也存在一些語義上中立的span與div標簽。自1990年代末層疊樣式表開始應用于大多數瀏覽器，網頁制作者就被鼓勵使用CSS以便呈現與內容分離。
在2001年一次對語義網的討論中，蒂姆·伯納斯-李等人給出了一種的方法，使智能軟件“代理人”可能有一天會自動抓取網頁進行查找、過濾并將之前不相關的聯系起來。這種代理甚至在現在也不普遍，但一些Web 2.0、混搭和價格比較網站的想法可能會結束。這些網頁應用程序的混合與伯納斯-李的語義代理人的之間主要區別基于以下事實：當前的聚合與信息混合通常由網頁開發者設計，他們早已知道網絡位置和他們希望混搭、比較與結合的特定數據的API語義。
網頁代理的一個重要類型是網絡爬蟲或搜索引擎蜘蛛。這些軟件代理依賴于它們發現的網頁的語義清晰度，因為它們一天要使用各種技術與算法來讀取和索引數百萬個網頁并給網頁用戶提供搜索工具，沒有這些萬維網的有效性就會大大降低。
為使搜索引擎蜘蛛評估它們在HTML文檔中發現的文本片段的重要性，也為那些創建標記等混合的人與更多的自動化代理工具，HTML中的語義結構需要廣泛一致地應用從而將文本的含義呈現給瀏覽者。
表示性標記在當前的HTML和XHTML推薦中不被鼓勵使用，HTML5中則被視為非法。
好的語義化HTML也改善了網頁文檔的可訪問性。例如，當屏幕閱讀器或音頻瀏覽器可以正確判定一個文檔的結構時，視覺障礙用戶不會再因閱讀重復或無關的信息而浪費時間。
分發
HTML文檔分發的方法和其他計算機文件相同。不過，它們最常通過網頁服務器的超文本傳輸協議或電子郵件傳輸。
HTTP
萬維網主要由從服務器通過HTTP協議向瀏覽器發送的HTML文檔組成。但是，HTTP也可以被用于傳輸HTML之外的數據，例如圖像、聲音和其他內容。為使瀏覽器了解如何處理接收到的文檔，在傳輸文檔時必須同時傳遞文件類型。這種元數據包含MIME類型（對于HTML 4.01或更早版本是text/html，而對于XHTML 1.0或之后的版本是application/xhtml+xml），以及字符編碼（參見HTML字符編碼方式）。
在現在的瀏覽器中，和HTML文檔一起發送的MIME類型影響文檔的解讀方式。和XHTML MIME類型一起發送的文檔被認為是良構的XML，而語法錯誤會導致瀏覽器無法呈現文檔。完全相同的文檔如果和HTML MIME類型一起發送，則可能被正常顯示，因為瀏覽器對HTML的語法檢查更加松懈些。
W3C的推薦指出，遵循規定的推薦指引的XHTML 1.0文檔可標記二者任一的MIME類型。XHTML 1.1還指出，XHTML 1.1文檔應標有兩種MIME類型。
HTML郵件
大多數圖形電子郵件客戶端允許使用HTML的子集（經常界限不清）提供格式化和無法使用純文本的語義標記。這可能包括印刷信息，如彩色標題、強調和引用文本、內嵌圖片和圖表等。許多這樣的客戶包含一個編寫HTML電子郵件消息的圖形用戶界面編輯器和一個用于顯示的渲染引擎。在郵件中使用HTML受到了一些兼容性的批評，由于一些盲人或具有視覺障礙的人的訪問問題，這種方式有利于偽裝的釣魚攻擊。因其消息大小超過明文，所以它可混淆垃圾郵件過濾器。
命名規則
最常用的計算機文件擴展名為.html，通用縮寫為.htm。它起源于某些早期操作系統與文件系統，如DOS以及FAT數據結構的局限性，它將文件擴展名限制為3個字母。
HTML應用程序
HTML應用程序（HTA；文件擴展名".hta"）是一個Microsoft Windows應用程序，它在瀏覽器中使用HTML和動態HTML提供應用程序圖形界面。正規HTML文件被限制在瀏覽器的安全模型中，只能分別通過網頁服務器和網頁對象與站點Cookie進行通信和操作。HTA作為完全受信任的應用程序運行，因此擁有更多的權限，如創建/編輯/刪除文件與注冊表項。因為它們在瀏覽器安全模式之外操作，所以HTA不能通過HTTP執行，必須下載（就像EXE文件）并在本地文件系統執行。
所見即所得編輯器
所見即所得編輯器使用圖形用戶界面（GUI）顯示HTML文檔，常常類似于文字處理器，所以用戶可以設計一切。編者面對的是文檔，而不是代碼，所以作者并不需要太多的HTML知識。這種所見即所得的編輯模式一直受到詬病，主要因為它生成的代碼質量不高；也有人主張將其改變至WYSIWYM模型（所見即所指）。
年來，前端技術日新月異，前端已經不僅僅是網頁，更多的開始由狹義向廣義發展。
先后涌現出了具備后端能力的node，具備移動開發能力的react native，具備游戲渲染能力的cocos2d-js，以及iOS上的熱修復技術JSPatch等等新技術。
咋一看，幾乎各個端都被JavaScript攻陷，大有一統江湖之勢。
究竟，JavaScript如何做到上天入地無所不能？JavaScript真的能一統江湖嗎？
亂世出英雄：JavaScript的誕生故事要從JavaScript的由來說起。
高能瞎扯淡版，正經臉的同學可以忽略
有人的地方就有江湖，有江湖的地方就有紛爭。
故事要從當年的瀏覽器之戰說起。
時間回到1994年，
（→ 那時候我還是個寶寶~ #天真臉#）
景兄弟橫空出世，并自帶神器網景導航，戰斗力爆表，勢如劈竹，瞬時間威震天下。
一出世就武裝到牙齒，武力值這么高還自帶兵器，這個科學嗎？
港真，我也覺得不科學，也許跟熊孩子哪吒、女漢子雅典娜是一個品種吧？
這一切北方的老前輩微軟大濕，都看在眼里，不甘天下盡歸景兄弟這個初出茅廬的毛孩子，大濕積淀多年，潛心修煉一年，終于帶著大殺器IE 1.0出關了，誓于景兄弟爭個高低。
自此景兄弟的網景導航 VS 微軟大濕的IE 的軍備戰爭開始。
景兄弟仔細掂量，微軟大濕財大氣粗，內功深厚，臣妾實在是辦不到啊啊啊啊啊啊。
景兄弟緊急召集門人商議對策，有一門人曰：”以我們微薄之力硬磕，是萬萬使不得的。如今我們，一是宜施行合縱之策，抱大腿，組成聯盟！二是避其鋒芒，出奇招致勝。“
于是景兄弟依照此策略，一方面找到了當時德高為重的另一位前輩SUN，組成了開發者聯盟。
（微軟大濕：握草，聯盟都粗來了，那我是不是得搞個部落？）
另一方面，景兄弟找到了鍛造大師布蘭登，請布大師幫忙升級兵器網景導航，大師就是大師，不費吹灰之力就完成了強化升級，然而布大師突發奇想，本來這是近距離攻擊兵器，要是有多一個遠距離攻擊的能力那豈不是更好？Just do it. 想罷大師就加了一個遠距離攻擊的feature。于是有了自帶遠距離攻擊能力的網景導航2.0。景兄弟一看這么流弊心里甚是歡喜，不過遠距離攻擊的技能叫做LiveScript，感覺不是特別Fashion。特然想到這不是跟SUN前輩聯盟嘛，SUN家的Java正是獨霸武林之時。不如把名字改成跟Java有關，蹭一把東風，蹭點光環。一拍腦袋，JavaScript！！！眾門人一聽：”好好好，JavaScript 流弊炫酷吊炸天！“
果然第一節下半場，景兄弟攜強化過的網景導航2.0 戰個痛快，那是杠杠的！人家一問，你咋還能遠程攻擊，你這個遠程攻擊用的是啥？答曰：JavaScript。“JavaScript，一定是跟SUN家Java是一個系列產品，一定很流弊！”#光環加成，各種膜拜臉#
微軟大濕虧了一場，痛定思痛，也要搞遠程攻擊功能，果然不久，就祭出了同樣帶有遠程攻擊能力的IE 3.0，鑒于景兄弟的遠程攻擊叫做JavaScript，J開頭的感覺應該比較流弊，所以微軟大濕的叫做JScript。
然后戰爭就從地面貼身肉搏戰，開始逐步升級到了遠距離核戰爭。
正所謂，城門失火，殃及池魚。這么打下去苦逼的是搬磚的頁面仔，就是我這種，到處都是雷區，無處下腳。
最后到了1997年，“聯合國安理會秘書長”艾瑪（ECMA）出來調停，多方簽署了“核不擴散條約”，約束各種遠程攻擊武器的使用，這才走上了正軌。
1995年SUN開發了Java技術，這是第一個通用軟件平臺。Java擁有跨平臺、面向對象、泛型編程的特性，廣泛應用于企業級Web應用開發和移動應用開發。Java也伴隨著互聯網的迅猛發展而發展，逐漸成為重要的網絡編程語言。名噪一時。
1994年Netscape公司成立，并推出了自己的瀏覽器的免費版本 Netscape Navigator，很快就占有了瀏覽器市場。到了 1995 年，微軟公司開始加入，并很快發布了自己的 Internet Explorer 1.0。
1995年，當時在Netscape就職的Brendan Eich（布蘭登·艾克），正為Netscape Navigator 2.0瀏覽器開發的一門名為LiveScript的腳本語言，后來Netscape與Sun Microsystems組成的開發聯盟，為了讓這門語言搭上Java這個編程語言“熱詞”，將其臨時改名為“JavaScript”，日后這成為大眾對這門語言有諸多誤解的原因之一。
JavaScript最初受Java啟發而開始設計的，目的之一就是“看上去像Java”，因此語法上有類似之處，一些名稱和命名規范也借自Java。但JavaScript的主要設計原則源自Self和Scheme。JavaScript與Java名稱上的近似，是當時Netscape為了營銷考慮與SUN達成協議的結果。
==> 所以，JavaScript和Java其實沒有半毛錢關系。
JavaScript推出后在瀏覽器上大獲成功，微軟在不久后就為Internet Explorer 3.0瀏覽器推出了JScript，以與處于市場領導地位的Netscape產品同臺競爭。JScript也是一種JavaScript實現，這兩個
JavaScript語言版本在瀏覽器端共存意味著語言標準化的缺失，對這門語言進行標準化被提上了日程，在1997年，由Netscape、SUN、微軟、寶藍等公司組織及個人組成的技術委員會在ECMA（歐洲計算機制造商協會）確定定義了一種名叫ECMAScript的新腳本語言標準，規范名為ECMA-262。JavaScript成為了ECMAScript的實現之一。ECMA-262 第五版，即是ES5。
==> ECMA-262，包括ES5, ES6等是一個標準，JavaScript是ECMAScript的一個實現。
完整的JavaScript實現應該包含三個部分：
在網景導航2.0和IE 3.0出現之后的幾年間，網景和微軟公司不停的發布新版本的瀏覽器，支持更多的新功能。自此拉開了瀏覽器之戰的序幕。這場瀏覽器之戰到現在還在繼續，以下一張圖看清楚過程。
從瀏覽器之戰可以看出，各家瀏覽器比拼的大致兩個方面視覺體驗（渲染排版）和速度（腳本運行）。
==> 所以一個完整的瀏覽器組成，至少包含兩個部分：
補充一個市面常見瀏覽器的內核和JavaScript引擎搭配：
其他JavaScript引擎，Rhino，由Mozilla基金會管理，開放源代碼，完全以Java編寫，可以看做SpiderMonkey的Java版。
注意：webkit不單單只是一個排版引擎，webkit = 排版引擎 + JavaScript引擎。
==> 所以，JavaScript是動態語言，它的運行都是基于JavaScript引擎，引擎大都是由靜態語言實現C++、Java、and so on。JavaScript的能力也是由引擎賦予。不管是瀏覽器環境中是window，亦或是node環境中的process，均是由引擎提供。
（番外：Mozilla的人不知道為啥特別喜歡猴子，經常以猴子命名技術，所以看到帶Monkey的，十有八九估計是他們搞的。）
在瀏覽器環境中，DOM、BOM、window對象、setTimeout/setInterval，alert，console等方法均不是JavaScript自身具備的能力，而是瀏覽器native實現，然后通過JavaScript引擎注入到JS運行的全局上下文中，供JS使用。
鑒別方式，在調試器console中打出來，帶有[native code]的即是：
講道理：
JavaScript運行 → 依賴于JavaScript引擎 ← 瀏覽器集成了JavaScript引擎，同時通過JavaScript引擎注入native代碼工JS腳本使用
發散一下思維，只要有JavaScript引擎，就能運行JS腳本，不管有沒有瀏覽器！只是缺少瀏覽器提供的alert，window等方法。
既然瀏覽器可以往JavaScript引擎中注入代碼，賦予JS腳本在網頁中特殊的能力，同理我們可以自己集成JavaScript引擎，自己定義自己的方法往JavaScript引擎中注入，賦予JS更多更強的自定義能力！
注入的關鍵是：值類型相互對應，Obj映射class的一個實例，function映射一個句柄或者引用
JavaScript內部，所有數字都是以64位浮點數形式儲存，即使整數也是如此
這就是說，在JavaScript語言的底層，根本沒有整數，所有數字都是小數（64位浮點數）。容易造成混淆的是，某些運算只有整數才能完成，此時JavaScript會自動把64位浮點數，轉成32位整數，然后再進行運算。由于浮點數不是精確的值，所以涉及小數的比較和運算要特別小心。盡量避免使用JavaScript做精準計算和密集計算。
根據國際標準IEEE 754，JavaScript浮點數的64個二進制位，從最左邊開始，是這樣組成的。
第1位：符號位，0表示正數，1表示負數
第2位到第12位：儲存指數部分
第13位到第64位：儲存小數部分（即有效數字）
符號位決定了一個數的正負，指數部分決定了數值的大小，小數部分決定了數值的精度。
IEEE 754規定，有效數字第一位默認總是1，不保存在64位浮點數之中。也就是說，有效數字總是1.xx…xx的形式，其中xx..xx的部分保存在64位浮點數之中，最長可能為52位。因此，JavaScript提供的有效數字最長為53個二進制位（64位浮點的后52位+有效數字第一位的1）。
內部表現公式：(-1)^符號位 1.xx…xx 2^指數位
精度最多只能到53個二進制位，這意味著，絕對值小于2的53次方的整數，即-(253-1)到253-1，都可以精確表示。
而大部分的后端語言，C++、Java、Python等的long型都是可以支持到64位，因此long型數據從后端語言傳給JavaScript會發生低位截斷。遇到這種情況一般使用String處理，如需要在JavaScript中做long型計算，需要自行實現計算器。
有了自行往JavaScript引擎中注入的想法，接下來就是分析可行性。
大部分是JavaScript引擎是使用C++編寫，如果自己的程序使用的是C++可以很方便的進行注入，如果是OC，可以使用OC和C++混編的形式。
其他語言怎么破？
要在一門靜態語言上與動態語言JavaScript相互調用，最便捷的方式是找到一個這門語言實現的JavaScript引擎（開源），直接進行集成，注入。如果沒有，則需要使用多一層橋接，把這門語言的接口暴露給C++，再由C++實現的JavaScript引擎將接口注入供JavaScript使用。
服務端集成思路&實踐：
我們都知道nodeJS，但是nodeJS的運行依賴于Google的V8 引擎，V8是C++實現，底層使用C++實現底層功能，比如網絡，數據庫IO，對外暴露一個構造器接口注入到上下文中，注意此處暴露的只是一個構造器接口而不是一個創建完的實例。然后實現了一個require的hook函數。當使用require加載一個JS模塊時，跟網頁中使用AMD 的require并無異樣，當使用require加載系統庫，既是C++的模塊時，會調用暴露出來的構造器接口，得到一個實例對象。不管是裝載JS模塊還是裝載C++模塊，得到的都可以看做是一個Module Object，node會將裝載完的模塊緩存到binding_cache中，下次在別處的代碼中使用require裝載模塊時，就會先去binding_cache中查找，如果找到了則返回該module object，如果沒找到再執行上面的裝載流程。
這就是node的基本原理：C++封裝底層操作，通過V8注入，使得JS腳本有網絡和IO能力
以上說到的幾個都是C++層面的應用，那么經典的Java怎么玩？是不是Java就必須是靜態語言的玩法，沒有辦法像C++之類的，可以使用JS的動態特性？
當然不是。這個時候，我們需要說起前面介紹過的一個JS引擎 Rhino，Rhino是完全由Java編寫，可想而知，Rhino幾乎就是為Java應用而生的。
用法是這樣：
首先在我們的Java應用中集成Rhino；
所有的IO操作，網絡操作等，都封裝成service，并提供增刪改查，setter && getter等多種方法
通過spring，把這些service bean注入到Rhino中；
把業務邏輯寫到JS代碼中，JS代碼調用多個已注入的Java service處理業務邏輯，拼裝數據返回！
好處：修改業務邏輯不需要修改Java代碼，也就是不需要重新編譯和部署，只需要刷新下跑在Rhino中的JS代碼即可。以往Java應用的一個痛點是部署，需要重新編譯，打包，部署重啟服務器，現在以這種形式開發，可以達到服務端的熱更新和熱部署。既可以享有Java服務的穩定性和可靠性，又可以享有JS的靈活性。
這種技術和用法在差不多十年前就有過，前EMC的工程師基于EMC著名的商業產品Documentum，設計了一套Java開源的中小企業CMS系統Alfresco，在該系統中實現了這種技術，這種技術基于spring，叫做spring-surf，做了一個膠水層。可以看做小十年前的node吧。
Demo，使用spring-surf框架的系統中一個webscript模塊
categorynode.get.xml定義URL攔截器和權限控制；
.get指明是處理GET請求，RESTful；
在categorynode.get.js中調用已注入的Java Bean處理業務邏輯；
若為網頁請求返回.html.ftl，若為Ajax，返回.json.ftl；
（此處配套使用的是FreeMarker模板引擎）
==> categorynode.get.desc.xml
==> categorynode.get.js
==> categorynode.get.html.ftl
==> categorynode.get.json.ftl
React Native目前也是異常火爆，RN程序的運行依賴于Facebook的RN框架。在iOS、Android的模擬器或是真機上，React Native使用的是JavaScriptCore引擎，也就是Safari所使用的JavaScript引擎。但是在iOS上JavaScriptCore并沒有使用即時編譯技術（JIT），因為在iOS中應用無權擁有可寫可執行的內存頁（因而無法動態生成代碼），在安卓上，理論上是可以使用的。JavaScriptCore引擎也是使用C++編寫，在iOS和安卓中，JavaScriptCore都做了一層封裝，可以無須關心引擎和系統橋接的那一層。iOS/Android系統通過JavaScriptCore引擎將定制好的各種原生組件注入，如：listview，text等。
cocos2dx是游戲開發中非常常用的游戲渲染引擎，有一系列的產品，如：cocos2dx(C++)，cocos2d-lua（lua）, cocos2d-js(JavaScript)等多個產品。其中最新退出的是cocos2dx的JS版本的cocos2d-js，編寫游戲渲染特效代碼相比于C++和lua非常方便。對于做需要經常更新的渲染場景，C++是靜態語言，每次修改都需要重新編譯才能運行，顯然是不合適的。自然也就想到了腳本語言，lua和js，兩者有些類似，都是動態語言，只需要集成一個運行引擎，提供一個運行的容器即可運行，同時通過引擎注入底層方法供腳本調用即可。lua好處是精簡，語法精簡，引擎頁很小很精簡，所以不可避免的代碼量會比js多，同時學習成本比較高。js的好處是有ECMAScrtpt的核心，語法比較豐富，同時有支持一些高級屬性。在cocos2d-js中，cocos2dx(C++)集成了SpiderMonkey（C++）作為JS運行引擎，中間做了一個膠水層既是JS Binding，通過引擎注入了一個cc的全局對象，映射的是底層C++的一個單例C++實例。表面上寫的是JS代碼，實際上操作的是底層的C++。cocos2d-js是代碼可以運行在多種環境中，當運行的網頁環境中時，使用的是cocos2d-html5引擎，底層操作的是canvas；當運行在客戶端上時，使用的是cocos2dx引擎，底層操作的是C++，再由C++去操控openGL做繪制和渲染。提供相同的API，對開發者幾乎是透明無差異的，開發者只需要關注實現效果即可。達到一套代碼，多端運行（網頁端，客戶端）。
JSPatch是目前比較流行的iOS上的熱修復技術，JSPatch 能做到通過 JS 調用和改寫 OC 方法最根本的原因是 Objective-C 是動態語言，OC 上所有方法的調用/類的生成都通過 Objective-C Runtime 在運行時進行，我們可以通過類名/方法名反射得到相應的類和方法。JSPatch 的基本原理就是：JS 傳遞字符串給 OC，OC 通過 Runtime 接口調用和替換 OC 方法。
關鍵技術之一是 JS 和 OC 之間的消息互傳。JSPatch里包含了，一個JS引擎JavaScriptCore（Safari，React Native用的同款）。用到了 JavaScriptCore 的接口，OC 端在啟動 JSPatch 引擎時會創建一個 JSContext 實例，JSContext 是 JS 代碼的執行環境，可以給 JSContext 添加方法，JS 就可以直接調用這個方法。本質上就是通過JavaScriptCore引擎注入，暴露OC的方法供JS調用來實現動態修改OC的反射。
Demo，iOS熱更新，熱修復：
集成JavaScriptCore引擎；
通過引擎，橋接JS和OC；
通過JS修改OC反射。
詳細的JSPatch技術介紹請移步：https://github.com/bang590/JSPatch/wiki
關于JavaScript引擎：
在iOS 或 android 上能夠運行的JavaScript 引擎有4個：JavaScriptCore，SpiderMonkey，V8，Rhino。下面這個表格展示各個引擎在iOS 和 Android 的兼容性。
因為iOS平臺不支持JIT即時編譯，而V8只有JIT模式，所以V8無法在iOS平臺使用（越獄設備除外，想體驗iOS JIT的同學可以自行越獄）。
所以，目前可以做到橫跨iOS和Android雙平臺的JS引擎，只有兩款，即是SpiderMonkey和JavaScriptCore。
JavaScript引擎會受很多東西影響，比如交叉編譯器的版本、引擎的版本和操作系統的種類等。
至于如何選擇，可以參考:《Part I: How to Choose a JavaScript Engine for iOS and Android Development》
至此，JavaScript從立足于前端，到征戰全端的逆襲之路，可以總結為“攜引擎以令天下”。
不足之處，還請各位看官輕拍~
bang590/JSPatch中問參考文檔
Cocos2d-JS | Cocos2d-x官方參考文檔
Alfresco官方參考文檔
《Browser Wars: The End or Just the Beginning?》
《Part I: How to Choose a JavaScript Engine for iOS and Android Development》
《React Native 從入門到源碼》
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
