第一次 ASCII 對我來說真正重要時,我正在調試 WordPress 外掛程式的 CSV 導入,該插件不斷分裂一個客戶'地址分成兩行。在我打開它的每個編輯器中,該文件看起來都很好。事實證明,一個匯出使用裸回車符(代碼 13)作為行結尾,而我的解析器期望行饋送(代碼 10),並且雜散記錄分隔符(代碼30)從大型主機向上游匯出。這些字元都不會列印任何東西。你看不到它們。只有當你有一個將不可見位元組變成數字和名稱的表時,你才能看到它們 - 這正是我建立的原因 ascii 桌子 關於 toolz。dev 以及為什麼我將其固定在瀏覽器標籤中。
TL;DR: ASCII 將每個基本英文字元和一組控制訊號對應到數字 0 do127; ISO 8859-1(拉丁文 1)等擴充集填寫 128 so255。資本
A是65,小寫a是 97,空格是 32,並且 "不可見&引用;代碼 0 vos31 是控製字符,例如製表符 (9)、換行符 (10) 和回車符 (13)。如果您可以讀取該表,您可以解碼幾乎所有文字編碼錯誤,安全地轉義 HTML 中的任何字符,並了解為什麼 UTF-8、JSON 和每種程式語言的行為方式與字串相同。
我'花了數年時間在文字處理上建立生死存亡的東西 - WordPress 管理插件、Laravel API、React 前端 - 我可以告訴你,ASCII 的工作心理模型比幾乎任何其他低階模型節省更多的調試時間知識。
什麼是 ASCII 以及為什麼它仍然重要?
ASCII 代表美國資訊交換標準代碼。它於 1963 年首次標準化,並採用我們仍在使用的形式 ANSI X3.4-1986(也在國際上以 ISO/IEC 646 發布),並且今天仍然引用的網路定義是 RFC 20 (1969)。它的核心是一個查找表:從數字 0 到 127 到一組特定字元和控制訊號的映射。 7 位元、128 個插槽,整個運算世界可以共享的協議。
該協議是 1990 年在 Linux 伺服器上編寫的文字檔案至今仍在 Mac 筆記型電腦上正確開啟的原因。在標準字元代碼出現之前,每個製造商都有自己的方案,在機器之間移動文字是一個翻譯問題。 ASCII 將較低的 128 個代碼固定到位,此後就再也沒有移動過。
令人驚訝的是,現代計算仍然直接依賴它。 Unicode--涵蓋表情符號、中文、阿拉伯語和所有其他文字的巨大標準--故意使其前 128 個代碼點與 ASCII 相同。 UTF-8 是為網路提供動力的編碼,將前 128 個代碼點編碼為具有精確 ASCII 值的單位元組。所以一個簡單的 ASCII 文字檔案是 也 有效的 UTF-8 文件,位元組換位元組。當您了解 ASCII 時,您已經了解了建立其餘文字編碼的基礎。
ASCII 表是如何組織的?
128 個標準代碼分為幾個自然組,了解該組通常比記住任何單一值更有用。
控制字元(0 個 AX31 和 127)。 這些是非列印代碼。它們攜帶指令而不是字形:null (0)、bell (7)、退格 (8)、水平選項卡 (9)、換行 (10)、回車 (13)、轉義 (27) 和刪除 (127))是你和#39;實際上會遇到。它們被設計用於驅動電傳打字機,它們的幽靈仍然運行從原始文件中的行結尾到為終端輸出著色的轉義序列的所有內容。
可列印的標點符號和符號(32 SO47、58 SO44、91 SO96、123 SO126)。 空間為 32 - 最低的可列印程式碼,從技術上講,它是一個列印字符,儘管它什麼也沒顯示。其餘的是散佈在鍵盤周圍的符號: ! 33歲了, @ 64歲了, ~ 是126。
數字(48.57)。 人物 0 通過 9 從 48 到 57 整齊地坐著。這種排序是經過深思熟慮的:從數字中減去 48's 代碼,您得到它的數值,這就是幾乎每個 " 的數值;從字串中解析一個數字"例程開始。
大寫字母 (65 STOR90) 和小寫字母 (97 STOR122)。 A 65歲了, Z 是90; a 97歲了, z 是 122。字母與#39 之間的差距;大寫和小寫形式總是正好是 32。
擴展範圍 (128 coms255) 是一種不同的動物,它'這是最混亂的地方 - 所以它在下面有自己的部分。
ASCII 和 Extended ASCII 有什麼不同？
標準 ASCII 僅定義了 128 個代碼,因為它只使用 7 位元。但電腦以八位元組儲存文本,這留下了整個額外的 128 個插槽 (128 cos255) 未被標準使用。 &引用;擴展 ASCII&引用;是填充這些插槽的各種方案的總稱。
捕獲 - 並且它'一個很大的 - 是沒有單一的擴展 ASCII。不同的代碼頁分配上面的 128 個代碼完全不同。 IBM'代碼頁 437 將方框繪圖字元放在那裡。 Windows-1252 在那裡放置了大引號和歐元符號。 ISO/IEC 8859-1,稱為 Latin-1,將重音西歐字母放在那裡。值為 233 的位元組是 é 在 Latin-1 中,但代碼頁 437 中完全有其他內容。
在 toolz。dev I 上,我顯示了代碼 160 cos255 的 ISO 8859-1 (Latin-1) 分配,因為它是一個真正發布的標準,並且是原始 HTML 字元集的基礎 - 這意味著命名的 HTML 實體排列。 Latin-1 中的代碼 128 bus159 是第二個控製字元區塊("C1"controls),因此工具將它們標記為控製字符,而不是假裝它們'可列印。
實作課程:當有人說"擴展 ASCII,"總是問 哪一個. 代碼頁不符是造成這種情況的典型原因 é 當 UTF-8 檔案被讀取為 Latin-1 時,您會看到 Mojibake,或者當相反時,您會看到缺失的字形框。理解 資料隱私以及工具如何處理您的文字 是一個問題;了解位元組如何對應到字元是再也不會對亂碼文字感到驚訝的另一半。
為什麼大寫和小寫恰好相差 32?
這是我最喜歡的 ASCII 設計作品,因為它'這不是意外 - it'工程。選擇佈局是為了讓字母'大寫和小寫形式僅在位元 5 上有所不同,其值為 32。 A 是 65(二進制) 01000001); a 是 97(二進制) 01100001).唯一的區別是那個位。
該決定意味著程式可以透過一位運算而不是查找表來更改大小寫。大寫小寫字母,清除位元 5 (code & ~32);若要小寫大寫,請將其設為 (()code | 32);要以任何方式交換案例,請翻轉它(()code ^ 32)。在 Unicode' 之前,已有數十年的字串庫建立在這個技巧之上;更複雜的情況規則使得除了普通 ASCII 之外的任何東西都不安全。當您瀏覽表格並注意到每個大寫字母正好位於其小寫孿生字母下方 32 處時,您'正在研究 20 世紀 60 年代做出的決定,該決定仍然影響著軟體的編寫方式。
如何在十進位、十六進位和二進位字元之間進行轉換?
每個 ASCII 代碼都有四種常見的表示形式,在它們之間移動是低階工作的常規部分。這裡'他們如何與這封信產生共鳴 H:
| 代表性 | 的價值 H |
你在哪裡'會看到的 |
|---|---|---|
| 人物 | H |
普通文字 |
| 小數 | 72 | String.fromCharCode(72), chr(72) |
| 十六進位 | 48 | 六角轉儲, \x48URL/編碼百分比 |
| 八進制 | 110 | 較舊的 Unix 工具, \110 逃脫 |
| 二進制 | 01001000 | 按位操作、協定設計 |
若要從十六進位拼字單詞,請將每對十六進位數字作為一個位元組: 48 69 是小數點後 72 105,即 Hi。 若要反其道而行,請尋找每個字元's 代碼。這 ascii 桌子 執行兩個方向 - 它顯示每個程式碼的所有五列,並且其搜尋框接受一個字元、一個十進制數、一個十六進制值(帶或不帶 a) 0x 前綴)、八進位或二進位字串,甚至是 HTML 實體名稱,因此鍵入 &, 38,或者 amp 所有人都跳到&號。
如果您'定期轉換整個字串或跨 ASCII 以外的數基進行工作, 二進制翻譯 和 數目 基數轉換器 是我接觸到的配套工具。 ASCII 表為參考;這兩個是工作台。
ASCII 控製字元的實際用途是什麼?
非印刷代碼 0 COMS31(加上 127)感覺就像博物館藏品,但其中一些每天都在運行您的生活。
換行 (10) 和回車 (13) 是大二。在電傳打字機上,回車將列印頭移回左邊距,換行將紙張推進一行 - 兩個獨立的物理動作。這項傳統就是 Windows 文字檔案以兩者結尾的原因 (()CRLF, 13 然後 10),而 Unix 和 macOS 僅使用換行符 (()LF,10).幾乎每一個&引用;為什麼我的文件充滿了 ^M 人物?&引用; bug 可以追溯到這次分裂。我的 CSV 災難從介紹中正是如此。
水平標籤 (9) 是製表符 - 編輯器渲染為多個空格的單字節。 空 (0) 終止 C 字串並標記 "無資料"以無數的格式。 逃脫 (27) 介紹移動遊標並為終端著色的控制序列。 貝爾 (7) 曾經敲響過真正的鐘聲;現在它會發出蜂鳴聲或閃爍終端視窗。
一個好的表格命名這些代碼的原因很重要:當您在資料中找到位元組 27 時,"ESC - 逃脫並引用;立即告訴您,您'正在查看終端控制序列,而不是損壞的文字。原始數字會讓你猜測。
ASCII 與 HTML 實體和安全轉義有何關係?
如果您為網路和建築物寫作 一個可靠的開發人員工具包 意味著您會 - 少數 ASCII 字元需要轉義,因此瀏覽器不會'將它們誤讀為標記。小於號 < (60),大於 > (62),&符號 & (38),雙引號 " (34) 是危險的四個。在 HTML 中保持原始狀態,它們可能會破壞您的頁面或打開注入孔;寫成實體(<, >, &, ") 它們呈現為文字字元。
每個程式碼的形式中還有一個數字 HTML 實體 &#code;1,因此即使沒有命名實體的字元也總是可以安全地寫入。 ASCII 表列出了存在的命名實體,否則列出了數字形式,點擊 HTML 列會將其直接複製到剪貼簿。當您需要編碼或解碼整個標記區塊而不是查找單一字元時, HTML 實體 工具處理批次作業。為了更深入地了解我每天使用的編碼實用程序, 編碼工具指南 走遍整套。
ASCII 表與 Unicode 相同嗎？
不,但是他們'故意相容,並且這種關係值得直接解決。 Unicode 是一個更大的標準 - 超過一百萬個可能的代碼點,涵蓋每個書寫系統以及符號和表情符號。 ASCII 擁有 128 個代碼,是一個很小的子集。使它們能夠很好地配合在一起的原因是 Unicode'前 128 個代碼點被定義為與 ASCII 相同的單字節,而 UTF-8 將這 128 個代碼點與其 ASCII 值精確地編碼為單字節。
結果很優雅:任何有效的 ASCII 檔案都會自動成為有效的 UTF-8 檔案。您永遠不必在兩者之間轉換純英文文字。當您超出代碼 127(重音字母、大引號、表情符號)時,您將 ASCII 拋在後面,然後您'牢牢地處於多位元組 Unicode 領域,其中一個字元可能佔據兩個、三個或四個位元組。 toolz。dev ASCII 表直接覆蓋 ASCII 和 Latin-1 範圍,其文字編碼器會報告您貼上到它們之外的任何字元的 Unicode 代碼點,因此您可以準確地看到 ASCII 結束和 Unicode 接管的位置。
常見問題
什麼是ascii？
ASCII（美國資訊交換標準代碼）是一個字元編碼標準，它將字母、數字、標點符號和控制訊號對應到數字 0-127。 它在 1963 年被標準化為 ANSI X3.4，並且仍然是現代文本編碼的基礎，包括 UTF-8，其前 128 個代碼點與 ASCII 相同。
"A" 的 ASCII 值是多少??
大寫字母"A" ASCII 值為 65(十六進位 41,八進位 101,二進位 01000001)。小寫&引用;a&引用;是 97 - 正好高 32 - 這就是為什麼翻轉位元 5 在大寫和小寫之間切換字母。
ASCII 和 Extended ASCII 有什麼不同？
標準 ASCII 使用 7 位元並定義 128 個代碼 (0 bod127)。 &引用;擴展 ASCII&引用;使用第八位為重音字母、符號和方框圖字元新增另外 128 個代碼 (128 coses255)。沒有單一擴展 ASCII - 不同的代碼頁以不同的方式分配上半部。此表顯示了 ISO 8859-1 (Latin-1) 分配,它是 Latin-1 HTML 字元集的基礎。
什麼是 ASCII 控制字元？
代碼 0-31 和 127 是帶有指令而不是可見字形的非列印控制字元。 常見的包括換行 (10)、回車 (13)、水平標籤 (9)、轉義 (27) 和 NULL (0)。 他們最初控制了電傳打字機，但今天仍然終止線路、分隔欄位和驅動終端逃生序列。
如何將十六進位轉換為 ASCII？
每對十六進位數字代表一個字節,對應一個 ASCII 代碼。十六進位 48 十進位為 72,即 "H";十六進位 69 是 105,即 "i" - 所以 48 69 個拼法"Hi"。透過十六進位值(有或沒有 0x 前綴)搜尋 ASCII 表,立即找到符合的字元。
為什麼大寫與 ASCII 中的小寫相差 32？
ASCII 的佈局使得字母和#39 之間的唯一區別; s 大寫和小寫形式是位元 5(值 32)。 &引用;A&引用;是65和&引用;a&引用;是97; &引用;Z&引用;是 90 和 "z"是 122。這種經過深思熟慮的設計允許程式透過單一位元操作而不是查找表來更改大小寫。
ASCII 表與 Unicode 相同嗎？
不一樣,但相容。 Unicode 是一個更大的標準,涵蓋每個書寫系統超過一百萬個代碼點。它的前 128 個代碼點與 ASCII 相同,UTF-8 將它們編碼為單個字節,因此有效的 ASCII 文字也是有效的 UTF-8。 ASCII 表涵蓋了 ASCII 和 Latin-1 範圍;其編碼器報告超出它們的字元的 Unicode 代碼點。
當我使用 ASCII 表時,我的文字是否私有?
是的。整個表格是在您的瀏覽器中以普通的JavaScript 生成的,您粘貼到編碼器中的任何文本都會在本地處理- 它永遠不會上傳、記錄或存儲,並且一旦頁面加載,該工具就會在沒有網路連接的情況下繼續工作。
由 [toolz。dev](/、WP Adminify 以及一長串 Laravel 和 React 專案的建構者 Liton 撰寫,所有這些專案遲早都會歸結為正確取得位元組。
