xml
代表擴充套件標記語言（
extensible markup language
），是由
world wide web consortium（w
3c
）的
xml工作組定義的。這個工作組是這樣描述該語言的：「擴充套件標記語言（
xml）是
sgml
的子集，其目標是允許普通的
sgml
在web
上以目前
html
的方式被服務、接收和處理。
xml被設計成易於實現，且可在
sgml
和html
之間互相操作。」
「關於此規範的正確題目，亦即xml的正確全名，應該是extensible markup language，extensible markup language只不過是乙個拼寫錯誤罷了。但是，現在簡寫xml不僅正確，而且正如它在本規範的標題中一樣，是extensible markup language的官方名稱。
——extensible markup language (xml) 1.0 specs, the annotated version.
正如所看到的，
xml是一種專門在
world wide web
上傳遞資訊的語言，就像
html
（超文字標記語言）一樣（自從
web出現以來，
html
已經成為了建立
web頁的標準語言）。因為我們已經有了
html
，而且它已發展成一種似乎可以滿足任何需要的語言，所以，你可能會疑惑：為什麼我們還需要在
web上採用一種全新的語言呢？
xml有什麼新特性和不同之處？它有什麼特有的優點和長處呢？它與
html
有什麼關係？它是要替換還是增強
html
？最後，這個以
xml作為其子集的
sgml
是什麼，為什麼我們不就用
sgml
來建立web
頁呢？html
提供了固定的預定義元素集，可以使用它來標記乙個典型、通用的web頁的各個組成部分。預定義元素的例子有：標題（
heading
）、（paragraph
）、列表（
list
）、**
（table）
、影象（image）和鏈結（link）。顯示
html
頁的瀏覽器可以識別這些標準元素中的每乙個元素，並且知道怎樣格式化和顯示它們。例如，瀏覽器通常用最大的字型顯示h1標題，h2標題用乙個較小的字型，元素p表示更小的字型。它在未排序的列表中把乙個li元素顯示成乙個帶有專案符號的、縮排的段落。
儘管自從第乙個html版本後，預定義的html元素已經得到了極大的擴充套件，但是html仍然無法適用於已定義的眾多文件型別。下面就是無法使用html充分描述的文件示例：
l不是由典型的組成部分（標題、段落、列表、**等等）組成的文件。例如，html缺乏標記**樂譜或算術等式集的元素。
l想要組成樹型分層結構的文件。例如，你正在寫一本書，而且想要把它分為部分、章、a小節、b小節、c小節等等。接著，乙個程式可以使用這個結構化的文件生成目錄，各種不同級別細節資訊的架構，抽取特定的小節，以及通過其他方法使用這些資訊。
另外，還更有一批對html無可奈何的人，那就是搜尋引擎的開發者。因為從html的標籤本身，他們幾乎得不到任何有用的資訊。如果你要到網上去找出世界上所有關於xml的書籍的價錢，天啊，搜尋引擎要被你忙壞了。它要分辨網路上哪些「xml」字段對應的是書名，又要知道這些書名所對應的價錢。可能你會說，在我們圖書館的網頁中，這不是已經辦到了嗎？問題就在這裡，圖書館是根據內部的資料庫來進行搜尋的，資料庫中的各個欄位都有著明確的含義。但搜尋引擎在網上是根據html檔案來進行搜尋的，那些原本條理清晰、層次分明的資料庫的內容在html檔案中早就被各種各樣的標籤搞得混亂不堪，而搜尋引擎則不得不在這些混亂的內容中大海撈針！
為什麼要使用blog
有哥們問我，你為什麼使用blog?我總結了一下，覺得有如下幾個原因。1對自己的督促 有了blog，就會經常記得寫點東西 就會經常翻翻網上的新文章，了解一下新技術，不至於迷失在忙碌的生活中 如果把自己的所感所想所學寫出了，自己對自己也會有個概念，不至於迷迷糊糊 還有，畢竟是掛在網上的文字，心中難免擔心...
為什麼要使用Nginx？
有人說這些基準測試是不準確的，因為在這樣那樣的環境下，做的比較不一致。我傾向同意基準測試只是告訴了我們其中一部分情況，你能做的是消除偏見 有人見過所有人都同意乙個基準測試是公平的嗎？我是沒見過。我們投資的一些公司把web平台切換到nginx後，可以顯著的解決擴充套件問題。nginx明顯有效的實現了今...
為什麼要使用RTP
1.維基百科的相關解釋 像tcp這樣的可靠傳輸協議，通過超時和重傳機制來保證傳輸資料流中的每乙個bit的正確性，但這樣會使得無論從協議的實現還是傳輸的過程都變得非常的複雜。而且，當傳輸過程中有資料丟失的時候，由於對資料丟失的檢測 超時檢測 和重傳，會資料流的傳輸被迫暫停和延時。2.為什麼rtp可以解...