文本編碼 ASCII (Windows 1251, CP866, KOI8-R) 和 Unicode (UTF 8, 16, 32) - 如何用破解者解決問題

今天我們將討論 krakozyabrs 在網站和程式中的來源、存在哪些文字編碼以及應該使用哪些文字編碼。讓我們仔細看看它們的發展歷史，從基本的 ASCII 開始，及其擴展版本 CP866、KOI8-R、Windows 1251，最後到現代 Unicode 聯盟編碼 UTF 16 和 8。目錄 ：

• ASCII - 拉丁字母的基本文本編碼
• Asuka 的擴展版本 - CP866 和 KOI8-R 編碼
• Windows 1251 - ASCII 變體以及為什麼 krakozyabry 出現
• Unicode - 通用編碼 UTF 8、16 和 32
• 瘋狂的單字而不是俄語字母 - 如何修復它

對於某些人來說，這些資訊可能看起來沒有必要，但是您知道我收到了多少專門關於爬行 krakozyabrs（不可讀的字元集）的問題。現在有機會請大家參考這篇文章的文字，找出自己的錯誤。好吧，準備好吸收資訊並嘗試遵循故事的流程。

ASCII - 拉丁字母的基本文本編碼

文本編碼的發展與IT產業的形成同時發生，在此期間它們經歷了相當多的變化。從歷史上看，這一切都始於 EBCDIC，它的俄語發音相當不和諧，它使得用控製字元對拉丁字母、阿拉伯數字和標點符號進行編碼成為可能。但是，現代文本編碼發展的起點應該被認為是著名的ASCII（美國資訊交換標準代碼，在俄語中通常發音為“ask”）。它描述了英語用戶最常用的前 128 個字元 - 拉丁字母、阿拉伯數字和標點符號。這 128 個用 ASCII 描述的字符還包括一些服務字符，如括號、井號、星號等。事實上，你可以自己看到它們： 正是這 128 個來自 ASCII 原始版本的字元成為了標準，在任何其他編碼中你肯定會找到它們，並且它們會按這個順序出現。但事實是，借助一個位元組的信息，你可以編碼的不是128個，而是多達256個不同的值（二的八次方等於256），因此，在Asuka的基本版本之後，一整套系列擴展的ASCII 編碼出現了，其中除了 128 個基本字元之外還可以使用國家編碼字元（例如俄語）進行編碼。在這裡，可能值得多說一下描述中使用的數字系統。首先，眾所周知，計算機只能處理二進制系統中的數字，即零和一（“布爾代數”，如果有人在研究所或學校學過的話）。一個位元組由八個位元組成，每個位元代表一個二的二次方，從零開始，一直到二的第七位元： 不難理解，在這樣的結構中，所有可能的零和一的組合都可以只有 256。將數字從二進制轉換為十進制非常簡單。您只需將兩個以上的所有冪相加即可。在我們的例子中，結果是 1（2 的 0 次方）加 8（2 的 3 次方），加上 32（2 的 5 次方），加上 64（6 次方），加上 128 （到七次方）。總計為十進制 233。正如您所看到的，一切都非常簡單。但如果您仔細查看包含 ASCII 字元的表，您會發現它們是用十六進位編碼表示的。例如，「星號」對應於 Aski 中的十六進位數 2A。您可能知道，在十六進制數字系統中，除了阿拉伯數字之外，還使用從A（表示十）到F（表示十五）的拉丁字母。好吧，將二進制數轉換為十六進制採取以下簡單的方法。每個位元組的資訊分為兩部分，每部分四位元。那些。每個半位元組中，只能用二進位編碼十六個值（二的四次方），可以很容易地表示為十六進位數。此外，在位元組的左半部分，需要從零開始重新計算度數，而不是如螢幕截圖所示。結果，我們發現截圖中編碼的是數字E9。我希望您能清楚我的推理過程和這個難題的解決方案。好吧，現在讓我們繼續討論文字編碼。

Asuka 的擴展版本 - 帶有偽圖形的 CP866 和 KOI8-R 編碼

因此，我們開始談論 ASCII，它可以說是所有現代編碼（Windows 1251、Unicode、UTF 8）開發的起點。最初，它只包含 128 個拉丁字母、阿拉伯數字和其他字符，但在擴展版本中，可以使用可以在一個位元組資訊中編碼的所有 256 個值。那些。可以在 Aski 中加入您語言的字母符號。在這裡，我們需要再次離題，解釋為什麼需要文字編碼以及為什麼它如此重要。電腦螢幕上的字元是基於兩件事形成的：各種字元的向量形狀（表示）集（它們位於電腦上安裝的字體檔案中）和允許您準確提取該字元的程式碼從這組向量形狀（字體文件）中提取需要插入到正確位置的符號。很明顯，字體本身負責向量形狀，但作業系統和其中使用的程式負責編碼。那些。電腦上的任何文字都是一組字節，每個位元組都會編碼該文字的一個字元。在螢幕上顯示這段文字的程式（文字編輯器、瀏覽器等），在解析程式碼時，讀取下一個字元的編碼，並在需要的字體檔案中尋找對應的向量形式，連接起來顯示這段文字文字文檔。一切都是簡單而平庸的。這意味著，為了對我們需要的任何字元（例如，國家字母表）進行編碼，必須滿足兩個條件：該字元的向量形式必須在所使用的字體中，並且該字元可以用擴展 ASCII 編碼進行編碼在一個位元組中。因此，有很多這樣的選擇。僅用於編碼俄語字符，就有多種擴展 Aska。例如，最初出現的CP866能夠使用俄語字母表中的字符，並且它是ASCII的擴展版本。也就是說，它的上半部分與Aska 的基本版本（128 個拉丁字符、數字和其他廢話）完全一致，如上面的屏幕截圖所示，但CP866 編碼的表格的下半部分具有如圖所示的外觀。下面的螢幕截圖允許編碼另外 128 個字元（俄語字母和各種偽圖形）： 你看，在右列中，數字以 8 開頭，因為 從 0 到 7 的數字指的是 ASCII 的基本部分（請參閱第一個螢幕截圖）。這樣，CP866 中的西里爾字母「M」就會有代碼 9C（位於 9 對應的行和十六進制數字 C 的列的交點處），可以用一個字節的信息寫入，如果有適合俄語字符的字體，該字母將毫無問題地出現在文本中。這筆錢從哪裡來？CP866 中的偽圖形？關鍵在於，這種俄語文本編碼是在那些混亂的年代開發的，當時圖形作業系統還沒有像現在這樣普遍。在 Dosa 和類似的文字作業系統中，偽圖形至少在某種程度上使文字設計多樣化成為可能，因此 CP866 和 Asuka 擴展版本類別中的所有其他同類都大量使用了偽圖形。CP866 由 IBM 分發，但除此之外，還為俄語字元開發了多種編碼，例如KOI8-R可以歸為同一類型（擴展 ASCII） ： 其操作原理與前面描述的CP866 的情況- 文本的每個字元都被編碼為一個位元組。截圖顯示的是KOI8-R表的後半部分，因為 前半部與基本的明日香完全一致，如本文第一個螢幕截圖所示。在 KOI8-R 編碼的特性中，可以注意到其表中的西里爾字母並非按字母順序排列，如 CP866 中所做的那樣。如果您查看第一個螢幕截圖（基本部分的螢幕截圖，包含在所有擴展編碼中），您會注意到在 KOI8-R 中，俄語字母與拉丁字母表的相應字母位於表格的相同單元格中從表的第一部分開始。這樣做是為了方便從俄語字符切換到拉丁字符，只需丟棄一位（2 的七次方或 128）。

Windows 1251 - 現代版本的 ASCII 以及出現裂縫的原因

文字編碼的進一步發展是由於圖形作業系統越來越流行，並且隨著時間的推移，在其中使用偽圖形的需要消失了。結果，出現了一整組，本質上仍然是明日香的擴展版本（文本的一個字符僅用一個字節的信息進行編碼），但沒有使用偽符號。它們屬於所謂的 ANSI 編碼，由美國標準協會開發。一般來說，西里爾字母這個名稱也用來支持俄語的版本。Windows 1251就是一個例子。它與先前使用的 CP866 和 KOI8-R 的不同之處在於，其中偽圖形符號的位置被俄語印刷術中缺少的符號（重音符號除外）以及接近斯拉夫語言的符號所取代。俄語（烏克蘭語、白俄羅斯語言等）。）： 由於俄語的編碼如此豐富，字體製造商和軟體製造商不斷地頭痛，而你和我，親愛的讀者，經常遇到同樣臭名昭著的錯誤的麻煩當與文本中使用的版本發生混淆時。很多時候在透過電子郵件發送和接收訊息時就會出現這種情況，這需要創建非常複雜的轉換表，這實際上並不能從根本上解決這個問題，並且用戶經常使用拉丁字母的音譯進行通信，以便避免在使用CP866、KOI8-R 或Windows 1251 等俄語編碼時出現臭名昭著的亂碼。事實上，出現的裂紋而不是俄語文本是由於錯誤使用給定語言的編碼而導致的，該語言與中的編碼不對應文字訊息最初是編碼的。假設，如果您嘗試使用 Windows 1251 代碼表顯示使用 CP866 編碼的字符，那麼這些相同的亂碼（一組無意義的字符）將會出現，完全替換訊息的文字。 在創建和設定網站、論壇或部落格時，經常會出現類似的情況，即帶有俄語字元的文字被錯誤地保存為網站預設使用的錯誤編碼，或保存在錯誤的文字編輯器中，這會增加一個無形的噱頭。用肉眼觀察程式碼。最後，許多人厭倦了這種大量編碼和不斷爬出垃圾的情況，並且出現了創建新的通用變體的先決條件，該變體將取代所有現有變體並解決出現不可讀文本的問題。此外，還有像中文這樣的語言的問題，其語言字符遠多於256個。

Unicode - 通用編碼 UTF 8、16 和 32

東南亞語言組的這數千個字元不可能用分配給 ASCII 擴展版本中的字元編碼的一個位元組的資訊來描述。結果，一個名為Unicode（統一碼聯盟）的聯盟在許多對通用文字編碼的出現感興趣的IT 行業領導者（那些生產軟體的人、編碼硬體的人、創建字體的人）的合作下成立了。在 Unicode 聯盟的支持下發布的第一個變體是UTF 32。編碼名稱中的數字表示用於對一個字元進行編碼的位數。32 位元等於 4 個位元組的訊息，需要用新的通用 UTF 編碼來編碼單一字元。因此，使用擴充版 ASCII 和 UTF-32 編碼的相同檔案（在後一種情況下）的大小（重量）將增加四倍。這很糟糕，但現在我們有機會使用 UTF 編碼等於 2 的 30 秒次方的字元數（數十億個字元將覆蓋任何真正必要的值，並具有巨大的餘裕）。但許多使用歐洲集團語言的國家根本不需要在編碼中使用如此龐大的字符數，然而，當使用UTF-32時，他們無緣無故地獲得了四倍的文本文檔權重增加，結果，互聯網流量和存儲數據量增加。這是很多，沒有人能夠承受這樣的浪費。由於 Unicode 的發展，出現了UTF-16，它非常成功，以至於默認採用它作為我們使用的所有字元的基本空間。它使用兩個位元組來編碼一個字元。讓我們看看這個東西是什麼樣子的。在Windows作業系統中，可以依照「開始」-「程式」-「附件」-「系統工具」-「字元表」的路徑進行操作。結果，將開啟一個表格，其中包含系統上安裝的所有字體的向量形狀。如果您在「進階選項」中選擇 Unicode 字元集，您將能夠分別查看每個字型中包含的整個字元範圍。順便說一句，點擊其中任何一個，你都可以看到它的UTF-16 格式的兩位元組代碼，由四個十六進制數字組成： 使用 16 位元可以在 UTF-16 中編碼多少個字元？65,536（二的十六次方），這是 Unicode 中所採用的基本空間數字。此外，還有一些方法可以使用它來編碼大約 200 萬個字符，但它們僅限於 100 萬個字符的文本擴展空間。但即使是這個成功的Unicode 編碼版本也沒有給那些只用英語編寫程式的人帶來太大的滿足，因為從ASCII 的擴展版本過渡到UTF-16 後，文檔的重量增加了一倍（每個位元組一個位元組）。Aski 中的字元和 YUTF-16 中相同字元的兩個位元組）。正是為了滿足 Unicode 聯盟中的所有人和所有事物，才決定提出可變長度編碼。它被稱為 UTF-8。儘管名稱中有八個，但它實際上具有可變長度，即 文字的每個字元可以被編碼成長度為一到六個位元組的序列。實際上，UTF-8 僅使用 1 到 4 個位元組的範圍，因為超過 4 個位元組的程式碼，理論上甚至不再可能想像任何內容。其中的所有拉丁字元都被編碼為一個位元組，就像老式的 ASCII 一樣。值得注意的是，在僅編碼拉丁字母的情況下，即使那些不理解 Unicode 的程式仍然會讀取 YTF-8 編碼的內容。也就是說，Asuka 的基本部分只是簡單地轉移到了 Unicode 財團的這個創意。UTF-8 中的西里爾字元以兩個位元組編碼，例如，格魯吉亞字元以三個位元組編碼。Unicode 聯盟在創建 UTF 16 和 8 後解決了主要問題 - 現在我們的字體中只有一個程式碼空間。現在他們的製造商只能根據自己的優勢和能力用向量形式的文字字元填充它。在上面的「字元表」中您可以看到不同的字體支援不同數量的字元。一些富含 Unicode 的字體可能相當重。但現在它們的不同之處不在於它們是為不同的編碼創建的，而在於字體製造商已經用某些向量形式填充或未完全填充單個代碼空間。

瘋狂的單字而不是俄語字母 - 如何修復它

現在讓我們看看如何顯示 krakozyabrs 而不是文本，或者換句話說，如何選擇俄語文本的正確編碼。實際上，它是在您建立或編輯該文字或使用文字片段的程式碼的程式中設定的。為了編輯和建立文字文件，我個人使用一個非常好的（我認為）Html 和 PHP 編輯器 Notepad++。然而，它可以突出顯示數百種其他程式設計和標記語言的語法，並且還具有使用插件進行擴展的能力。請透過提供的連結閱讀對這個精彩程序的詳細評論。在 Notepad++ 的頂部選單中，有一項“編碼”，您可以在其中將現有選項轉換為預設在您的網站上使用的選項： 對於 Joomla 1.5 及更高版本上的網站，如就WordPress 上的博客而言，您應該避免出現Krakozyabrov 選擇不含 BOM 的 UTF 8 選項。BOM 前綴是什麼？事實是，當他們開發 YUTF-16 編碼時，出於某種原因，他們決定附加一種功能，即能夠以正序（例如 0A15）和反向（150A）寫入字元代碼。 。為了讓程式能夠理解以什麼順序讀取程式碼，發明了BOM（位元組順序標記，或者換句話說，簽名），它透過在文件的最開頭添加三個附加位元組來表示。在UTF-8編碼中，Unicode聯盟中沒有提供BOM，因此新增簽章（文件開頭那些臭名昭著的額外三個位元組）只會阻止某些程式讀取程式碼。因此，在以UTF儲存檔案時，我們必須始終選擇無BOM（無簽名）選項。因此，您將提前保護自己免受 krakozyabrs 爬出的影響。值得注意的是，Windows 中的某些程式無法執行此操作（它們無法以沒有 BOM 的 UTF-8 格式儲存文字），例如同樣臭名昭著的 Windows 記事本。它將文件保存為 UTF-8，但仍將簽名（三個額外位元組）添加到其開頭。此外，這些位元組將始終相同 - 按直接順序讀取程式碼。但在伺服器上，因為這個小事，就會出現一個問題——騙子就會出來。因此，在任何情況下都不要使用普通的 Windows 記事本。如果您不希望出現任何裂縫，請編輯您網站上的文件。我認為已經提到的 Notepad++ 編輯器是最好、最簡單的選擇，它幾乎沒有缺點，只有優點。在 Notepad++ 中，當您選擇編碼時，您可以選擇將文字轉換為 UCS-2 編碼，這本質上非常接近 Unicode 標準。另外，在記事本中，可以用 ANSI 編碼文本，即 對於俄語，這將是 Windows 1251，我們已經在上面描述過。這些資訊從哪裡來？它在 Windows 作業系統的註冊表中註冊 - 如果是 ANSI，則選擇哪種編碼；如果是 OEM，則選擇哪種編碼（對於俄語，則為 CP866）。如果您在電腦上設定另一種預設語言，則這些編碼將被取代為該語言的 ANSI 或 OEM 類別中的類似編碼。在Notepad++中以您需要的編碼儲存文件或從網站開啟文件進行編輯後，您將能夠在編輯器的右下角看到其名稱：為了避免混淆，除了上述步驟之外，在其標頭 中寫入有關此編碼的網站所有頁面資訊的原始程式碼將很有用，這樣伺服器或本機上就不會出現混淆。一般來說，除了Html之外的所有超文本標記語言都使用特殊的xml聲明，它指定文字編碼。

<?xml version="1.0" encoding="windows-1251"?>

在解析程式碼之前，瀏覽器知道正在使用哪個版本以及它需要如何準確地解釋該語言的字元程式碼。但值得注意的是，如果你用預設的Unicode來保存文檔，這個xml聲明可以省略（如果沒有BOM，編碼將被認為是UTF-8，如果有BOM，編碼將被認為是UTF-16）。對於 HTML 文檔，Meta 元素用於指示編碼，它放置在開始和結束 Head 標記之間：

<head>
...
<meta charset="utf-8">
...
</head>

該條目與Html 4.01中的標準有很大不同，但完全符合Html 5標準，並且目前使用的任何瀏覽器都可以正確理解它。理論上，指示 Html 文件編碼的 Meta 元素最好放置在文檔標題中盡可能高的位置，這樣當文本遇到第一個字符時，該字符不是來自基本 ANSI（它總是被正確讀取並且在任何變體），瀏覽器應該已經有關於如何解釋這些字元的程式碼的資訊。 原始來源連結：ASCII 文字編碼 (Windows 1251、CP866、KOI8-R) 和 Unicode (UTF 8、16、32) - 如何用破解者解決問題