對於檔案編碼格式的淺顯理解

2021-07-31 08:22:18 字數 1229 閱讀 4763

字型亂碼這個問題相信很多人都遇到過,但是都是間歇性的,不是經常性的,大多時候都沒有太在意。

在遇到過這麼多次亂碼之後,特別是在linux下開啟windows的檔案亂碼,我覺得有必要了解一下編碼方式了。

首先,計算機內部只能儲存二進位制資料,即1和0的bit位。所以,我們要讓計算機顯示各種字元,就必須要對字元進行編碼,讓每乙個字元對應乙個數字編碼。而之所以會造成亂碼現象,是因為當初建立檔案的時候採用的編碼方式,和開啟時的編碼方式不一樣,這樣的對應關係就亂了,於是我們看到的就是亂七八糟的。

計算機是美國人發明的,所以最初的計算機理所應當支援的就是英文本母以及英文裡面的各種符號。由於這些字元不怎麼多,美國人就提出了ascii編碼,只用乙個位元組(byte)表示乙個字元。

隨著計算機的發展,計算機只能顯示英語是絕對不行的,要不然怎麼有我現在的這篇文章呢?而並不是所有語言都像英語一樣可以用乙個位元組表示乙個字元(像我大中華便有好幾萬字元),於是各個國家紛紛開始提出自己國家文字的編碼方式。但是世界上這麼多國家,這麼多語言,要是每個國家都有自己的標準,那一台計算機上不得有好多種編碼方式啊,這會造成一種混亂。

這時,多語言軟體製造商組成的統一碼(unicode)聯盟出手了,這個組織在2023年正式提出了unicode編碼。正如unicode這個名字,它足以表示世界上所有語言中的字元,現在在世界上被廣泛採用。

在「統一」這個方面怎麼能少的了iso這個組織,在unicode聯盟研發unicode時,iso也在研發用於各種國家之間的編碼方式,iso定義了ucs(通用字符集),定義了iso/iec 10646。iso和unicode聯盟很快認識到研發兩個不同的統一碼是不必要的,所以他們選擇了合作,於是現在它們從內容上來說是同步一致的。

utf-8,utf-16以及utf-32都是unicode的實現方式

實現方式的理解:unicode編碼使乙個字元對應於乙個數字編碼,但是在計算機內部不是簡單的存入這個編碼值,這是為了對計算機中的內容進行更好的組織。所以就有了幾種實現方式,將這些數字編碼再對映到計算機記憶體中的二進位製碼。其中utf-8就是在網際網路的發展,強烈需求下產生的。

在unicode提出之前,我國就已經提出了自己的漢字編碼

linux下預設是utf-8,而windows可能是gb18030,於是這亂碼就不奇怪了

大致就是這樣了,這裡我說的是編碼方式,有乙個概念叫字符集,規定了每個字元對應的編碼,其實就是編碼方式,把一件事搞清楚了就好了,不用糾結文字。

如果**寫的不對,請各位大神們指出啊

對於字元編碼的理解

1.對於ascii碼的理解 採用乙個位元組來表示英文 數字的符號,將其與二進位制一一對應,位元組第一位為0,共編制128個符號,其中32個不能列印出來 2.非ascii編碼 由於乙個位元組可以表示256個字元,前0 127還是當時美國所表示的符號,各個國家根據自己的符號,編制屬於自己的128 256...

對於RestFul編碼風格的理解

resultful風格 restful風格是一種資源定位以及資源操作的風格。它既不是某種必須遵循的標準,也不是大家都不能改動的協議,而是一種編碼風格。當我們在實際的業務開放當中使用到restful風格時,會使得我們的業務進展速度很大程度度的提高。主要功能 get 用於查詢資源 post 用於建立資源...

檔案編碼格式

知道問題所在,還是沒有解決,又苦苦搜尋,終於在 stackoverflow 上找到靈感,可以把 open 的方式變為 二進位制,也就是下面 裡的 open filename,rb 這下好了,至少後面的read 可以通過。再之後就產生了以下 發現問題的路真心不好走,在此mark 下。coding ut...