## html實體
我們日常看到的,說的字符,可以書寫的字符,組成了我們的交流信息的基礎。
但是在計算機的世界里面,用于編程的字符也是我們日常用的字符,為了區分程序代碼關鍵字和普通字符,內容的區分,所以系統定義了一些關鍵字,比如在各個編程語言中,關鍵字不能用作函數名一樣。
在html中也是如此,我們的標簽使用了大量的專用的字符,用于描述文檔結構,當然背后的代碼我們是看不到的,瀏覽器根據背后的代碼給我們渲染出表現層的視圖,我們無需關心背后運作的代碼。
但是有時候,我們的內容多種多樣,可能需要顯示出關鍵字那么此時怎么辦呢,變現層字符和代碼層字符是不相同的,如果直接寫字符給顯示層做內容,那么會破壞代碼結構,就和不能使用關鍵字做函數名一樣的道理。
那有什么辦法可以解決這個問題呢?
**有,html實體。**
~~~
HTML 實體
在 HTML 中,某些字符是預留的。
在 HTML 中不能使用小于號(<)和大于號(>),這是因為瀏覽器會誤認為它們是標簽。
如果希望正確地顯示預留字符,我們必須在 HTML 源代碼中使用字符實體(character entities)。
~~~
對于網頁來說,我們看到的只是表現層的東西,背后運作的代碼使我們看不到的。
如果我們看到html實體 &\___;的結構
&是實體字符的代碼字符,它可以表示別人,那么如果要顯示它自己時,誰來表示它了,如此循環,似乎這個問題進入死循環了。
其實沒那么復雜,這個世界上的任何字符都是可以顯示出來的,會有方式來表示這個字符的。
&的實體是 &
沒錯,實體里面還有&。&是表現層的顯示字符,你看得到的一個字符,而背后的實體就是&,當然你并不需要關系這個。
>[danger] 代碼字符的顯示還是用的代碼字符,所以不存在無限死循環不能滿足的情況,因為隱藏在背后的代碼都可以滿足。
同理,URL編碼的眼里也是一樣。
其實這和轉義字符是一樣的道理,當某些字符不能直接表示時,可以使用轉移字符,那么關鍵就在于轉義的轉義號,如果要輸出轉義號也是有辦法的,同上面一樣,轉義號的輸出也是有轉義號轉義的,沒錯就是自己轉義自己。
總之,要理解的一個概念就是,你書寫的代碼,和最終輸出顯示的東西,不是一回事,如果你能理解清楚這個,那么上面的都不是問題。
* * * * *
### 擴展
這個和thinkPHP中的替換有點類似,但也又不同:
~~~
A: __public__ 會被替換成 /public/
A: 那么如果我想顯示 __public__ 怎么辦?
Q: 用另一個字符代替吧,比如:
__p__ 替換成 __public__
A: 那如果我又想輸出 __p__怎么辦?
Q: 真是無語了,怎么所有鄂事你都能碰上啊?
A: 是啊,我就是碰上了。
Q: 無語。
~~~
這里存在邏輯死循環的根本原因在于,當想要輸出一個特殊字符時,我們只能用一個不用的字符替代另一個特殊字符,這樣就要保證我們那個字符是真的不用的,不然就會陷入死循環。
這里的本質是替換,和上面講的實體和轉義不同。
比如我要輸出&,其實背后還是&轉義**(可以把實體理解成轉義)**,但字符串的替換就不行了。
其實再往深了思考,轉義本身也是一種替換,只不過轉義的替換規則是系統語言自己提供的,而替換只是我們自己實現的,一般比較簡單的“轉義”規則,如:[BBCode](ttps://baike.baidu.com/item/BBCode/6814117?fr=aladdin)
* * * * *
### 參考:
[HTML 字符實體](http://www.w3school.com.cn/html/html_entities.asp)
[輸出替換 · ThinkPHP5.0完全開發手冊 · 看云](http://www.hmoore.net/manual/thinkphp5/118120)
last update:2017-8-19 13:13:27
- 開始
- 微信小程序
- 獲取用戶信息
- 記錄
- HTML
- HTML5
- 文檔根節點
- 你真的了解script標簽嗎?
- 文檔結構
- 已經落后的技術
- form表單
- html實體
- CSS
- css優先級 & 設計模式
- 如何編寫高效的 CSS 選擇符
- 筆記
- 小計
- flex布局
- 細節體驗
- Flex
- Grid
- tailwindcss
- JavaScript
- javascript物語
- js函數定義
- js中的數組對象
- js的json解析
- js中數組的操作
- js事件冒泡
- js中的判斷
- js語句聲明會提前
- cookie操作
- 關于javascript你要知道的
- 關于innerHTML的試驗
- js引擎與GUI引擎是互斥的
- 如何安全的修改對象
- 當渲染引擎遇上強迫癥
- 不要使用連相等
- 修改數組-對象
- 算法-函數
- 事件探析
- 事件循環
- js事件循環中的上下文和作用域的經典問題
- Promise
- 最佳實踐
- 頁面遮罩加載效果
- 網站靜態文件之思考
- 圖片加載問題
- 路由及轉場解決方案
- web app
- 寫一個頁面路由轉場的管理工具
- 談編程
- 技術/思想的斗爭
- 前端技術選型分析
- 我想放點html模板代碼
- 開發自適應網頁
- 后臺前端項目的開發
- 網站PC版和移動版的模板方案
- 前后端分離
- 淘寶前后端分離
- 前后端分離的思考與實踐(一)
- 前后端分離的思考與實踐(二)
- 前后端分離的思考與實踐(三)
- 前后端分離的思考與實踐(四)
- 前后端分離的思考與實踐(五)
- 前后端分離的思考與實踐(六)
- 動畫
- 開發小技巧
- Axios
- 屏幕適配
- 理論基礎
- 思考
- flexible.js原理
- 實驗
- rem的坑,為什么要設置成百分比,為什么又是62.5%
- 為什么以一個標準適配的,其它寬度也能同等適配
- 自適應、響應式、彈性布局、屏幕適配
- 適配:都用百分比?
- 番外篇
- 給你看看0.5px長什么樣?
- 用事實證明viewport scale縮放不會改變rem元素的大小
- 為什么PC端頁面縮放不會影響rem元素
- 究竟以哪個為設備獨立像素
- PC到移動端初試
- 深入理解px
- 響應式之柵格系統
- 深入理解px(二)
- 一篇搞定移動端適配
- flex版柵格布局
- 其他
- 瀏覽器加載初探
- 警惕你的開發工具
- JS模塊化
- webpack
- 打包原理
- 異步加載
- gulp
- 命名規范
- 接口開發
- sea.js學習
- require.js學習
- react學習
- react筆記
- vue學習
- vue3
- 工具、技巧
- 臨時筆記
- 怎么維護好開源項目
- 待辦
- 對前端MVV*C框架的思考
- jquery問題
- 臨時
- 好文
- 節流防抖