有些軟體(例如Microsoft Office )預設是以ANSI 開啟與儲存檔案,而有些軟體(例如Sublime Text)或作業系統(例如OSX)預設則是Unicode,不同軟體間不同的編碼方式, ... ... <看更多>
ansi編碼wiki 在 Emoji在ptt | PTT鄉民百科 - Fandom 的推薦與評價
Emoji 是收錄在Unicode 內的一大類表情符號文字。在ANSI 編碼的PTT 上是被拆為兩個半形字元來顯示。PTT 上常見的有☺、☹、☁、☆、✈等。 部分手機BBS 軟體可以透過 ... ... <看更多>
ansi編碼wiki 在 字符编码总结 的推薦與評價
注:我们现在通常说到ANSI编码,通常指的是平台的默认编码,例如英文操作系统中是ISO-8859-1, ... 图片来自:https://en.wikipedia.org/wiki/ASCII. ... <看更多>
ansi編碼wiki 在 Re: [問題] 似乎是big5編碼- 看板C_and_CPP - 批踢踢實業坊 的推薦與評價
之前在 programming 版也問過相關的話題,對這有興趣。
就我的認知提供一些看法...先承認因為版友貼的是英文,所以只有跳著喵幾眼而已,
有空的版友,還望您幫忙看有沒有講錯,感謝。
※ 引述《jtmh ()》之銘言:
: ※ 引述《elfkiller (沒有暱稱)》之銘言:
: : 在寫網頁路徑變換程式
: : 而在網頁原始檔中有一段 %u5929%u4F7F ... 這樣的文字
: 這個算是 Unicode 表示法,
: 都是以 %u 開頭,
: 然後後面接著 4 個 16 進位數字。
: 例如「天使」這兩個字的 Unicode 碼位分別為 22825 和 20351,
: 由 10 進位轉成 16 進位後就變成 5929 和 4F7F,
: 再套入上述的表示法即為 %u5929 和 %u4F7F,
對這方面不熟,但我猜這 5929 跟 4F7F 應該是指 Unicode 中所謂的「code point」
也就是說今天有兩個字,外表長得像這樣:『天使』,那他們在 Unicode 的規範中,
分別是位於哪個位置?
※實際上好像不是一個外表對應一個 code point??而是分成好幾組,在某組
裡面有個長得像「天」這樣子的,其 code point 被定為 0x5929,也許另外一
組裡也有一個長得像「天」?這裡推薦一個網站
https://www.fileformat.info/info/unicode/char/search.htm
把你想要查 code point 的東西,也就是字或符號,貼上去按搜尋即可列出來。
「天」位於 0x5929,「使」位於 0x4F7F。知道位置後,要表示給人看時,
就牽涉到「編碼」。目前 Windows XP,以記事本 (notepad.exe) 的觀點,
一個檔案會有三種編碼: 1. ANSI編碼 2. UTF-8編碼 3. Unicode編碼
--
關於「3. Unicode編碼」
若更正確來說,Unicode 比較常見的編碼至少有 UTF-8、UTF-16LE、UTF16-BE、
UTF-32LE、UTF-32BE...等,這裡的「3. Unicode編碼」不是準確的講法,
實際上應該是 Windows XP 預設採用的 UTF-16LE 編碼。
換言之,code point 為 0x5929 的「天」字,在記事本用微軟新注音打 `u
再打入對應 code point=5929,字出來後,存成「3. Unicode編碼」,
則其 raw data 會寫29 59 (LE = Little Endian)。
--
關於「1. ANSI編碼」
這跟 Windows 控制台「地區及語言選項」的設定有關係。
簡單舉例看,raw data 寫 0x41 0xBA 0xCS 在簡體 Windows 記事本打開
會變「A好」;在繁體 Windows 打開會變「A疑」。
ANSI編碼是一種MBCS編碼,MBCS代表他裡面的任一個字,"不固定"由 1個 Byte
或 2 個 Byte 組成。好處是,因為CPU對MBCS編碼處理的單位是「1次1Byte」,
所以不會有Endian問題。CPU只有在處理像float這種,一次一定要「4個Bytes」
的資料時才必須考慮Endian。
UTF-8簡單講,在Unicode的編碼裡,他是屬於「1次1Byte」被CPU處理的那種,
跟ANSI編碼有一樣的優點。但 Windows 核心用的那種 UTF-16LE 編碼不是。
--
重點來了,網路傳輸網址,用GET方法時,資料會放在URL內,譬如這兩個網站
https://www.yam.com/
https://wiki.livedoor.jp/sougouwiki/search?keywords=
其中 yam 首頁的是用強悍的 Big5 編碼,素人系総合 wiki 網頁是用 日文 EUC-JP 編碼
註:EUC-JP 編碼、Big5 編碼、簡體 GBK 編碼...等,都歸納為 ANSI 編碼。
我們在搜尋框輸入資料,如果是 ASCII 比如 abc 就直接轉成 ASCII 很快樂的送出
0x616263 這 3 個 Bytes。
那如果要打不在 ASCII 內的字呢?比如要搜尋「台」字,那就會有問題...
傳過去的封包,裡面 raw data 到底要不要考慮 endian?你傳了 2 Bytes 過去,還要
再額外講 endian 才能避免因為對方的 CPU 是敵營,而解讀錯資料。
所以最後變成,資料該怎麼解讀,不能由傳送方指導,而是接收方收到後,照自己使用的
編碼來解讀。而且只會用無 endian 問題的 ANSI 跟 UTF-8 編碼解讀。
那麼接收方就不用考慮 endian。傳送方用的瀏覽器要聰明到在 素人wiki
輸入「台」執行搜尋時,先判斷這張網頁的編碼是 EUC-JP,然後再把「好」轉成
EUC-JP 的編碼 0xC2E6 送過去。
同理「yam 首頁」搜尋「台」字會送 Big-5 編碼的 0xA578 過去。
--
% 存在的理由—
本來是不需要用到 % 這個東西,但搜尋完 yam 或素人wiki後,我們知道因為 get 可以
讓網址=後面的字對應搜尋框輸入的資料。
只要連上網址:https://wiki.livedoor.jp/sougouwiki/search?keywords=%C2%E6
就會重複在素人wiki搜尋「台」的動作。
keyword=後面接要搜尋的資料,那直接把網址變成
https://wiki.livedoor.jp/sougouwiki/search?keywords=台
會怎樣?如果你在一張空白網頁,說要連上這個網址,鬼才知道對方用什麼編碼
事實上不可能在keyword=後面打任何沒有在 ASCII 內的字去做get。
那怎麼轉換台字?所以這就是 % 符號存在的價值,為了能重現當初送 0xC2E6 那就
直接傳 raw data 就好,問題是直接打 keyword=C260,顯然又牴觸原本的 ASCII。
所以在每個編碼基本單位 Byte 加上一個 % 就解決。
當然如果像 Big5 的「台」編碼是 0xA578,因為 78 其實等於 ASCII 編碼下的「x」,
你跑 https://search.yam.com/wps?k=%A5x 依然等於在yam首頁輸入「台」字搜尋。
而現在的瀏覽器會在你網址有「?keyword=台」這種狀況時,預設轉成 UTF-8 編碼
這也就是為什麼我們直接在 google
https://www.google.com.tw/search?&q=
的 q= 後面打個台字,就真的可以正確搜尋台字。
而在素人wiki的網址自己 DIY 打這樣
https://wiki.livedoor.jp/sougouwiki/search?keywords=台
卻不能變成搜尋台字的原因。
--
終於打完了,好熱
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 124.8.143.13
打字錯誤修正
※ 編輯: zlw 來自: 124.8.143.13 (07/05 22:35)
... <看更多>