[自編資料分享]UNICODE 13.0 全字元列表
 

因為包含有unicode 13.0規範內的十四萬三千多個完全不同的碼位，所以雖然檔案不大、沒有超過5MB，但讀取進度條可能還是得等它一下。
這份文件還包含有 區段名稱、子群組區段名稱、字元名稱 的正體中文翻譯欄位。有興趣有、需要的網友或許參考。

UNICODE13.0.ods (LibreOffice Calc ODS格式)
https://sites.google.com/site/ianho...eCharactersList

13版新加入5930字,包含CJK-G 4939個字。
CJK-G新字太多第2字面所剩空間不夠,因此直接啟用第3字面(Plane3,U+30000-U+3134A)
目前EXT-G的字型只有 https://www.babelstone.co.uk/Fonts/Han.html 有提供不太全的檔,就等"明朝花園體"的出現啦。

一些檔案編輯過程的雜記：
遭遇到一些字元名稱字串，例如：
http://unicode.org/charts/PDF/U1FB00.pdf
---
1FBBC

🮼

RIGHT OPEN SQUARED DOT
---
以我有限的英文程度，第一時間真的困惑了。字形圖樣的方框開口在左邊，字元名稱字串卻是"RIGHT OPEN"。
看了其他討論區網友提供的觀點留言之後，我決定自行擴充解讀腦補成「朝右的有開口方框圍起的點」。
然而過於精簡的字元名稱英文原文並沒有「朝向」意味的英文字眼，所以我得自行腦補有朝向意味的可能，才能合乎原文的"RIGHT"。
我會有這樣的自以為是的推論：
英語母語者搞不好都無法在第一時間正確理解這個符號和字元名稱！何況非英語母語者。
unicode組織的那群人，自以為是的過度簡化字元名稱，結果就是造成不必要的會錯意/誤解（陰謀論：搞不好unicode組織那群人自己也無法完全搞清楚那些字元和符號所代表的完整原意，所以字元名稱故意寫得過度簡略，製造模糊解讀空間，但很多不必要的第一時間誤會就是從這種細節產生的（也的確有些字元名稱曾被眼尖網友發現寫錯了，詳情請自行去維基百科爬文））。

想成 RIGHT, OPEN SQUARED DOT就沒問題了
用於 xx方的xxx

個人延伸想法，如果真的得靠自行加逗點或再自行腦補才能理解其字串真正的原意，那我會認為這個unicode組織滿有問題的，現在已經不是文言文的世代了，不該自以為是的認為別人都能夠第一時間就成功腦補你unicode編寫的文件的真正原意。尤其是unicode的文件，第一眼閱讀就理解的「白話」更是理所當然應該要做好的。
當然字元名稱太長串也不妥當，所以unicode當然得想辦法在長串和會讓人第一時間誤解的過度精簡之間，想出一句取得平衡點、也能讓閱讀者第一時間不會會錯意的字串。
---
或許有某些潛水鄉民會嗆說，那你寫信去跟unicode組織反應啊！
很遺憾的是我的英語自然語言程度就是沒有到達可以寫英文書信的程度，也不要叫我去練英文云云。如果只是叫英文程度不好的人去練英文，那外國軟體進臺灣市場又何必中文化？
也或許有某些潛水鄉民會嗆說，那你就不要用unicode啊，又沒有強迫你用！？
問題是我手邊的文書編輯環境現階段還真的不得不用unicode，現實真的就是「沒有」比unicode同等級或更速效或更好的選擇。
---
我把unicode13.0的 十四萬三千多個字元名稱百分之九十五以上的整理出正體中文，就是因為我看英文看得好累！
當然我也承認我所整理出來的 正體中文 字元名稱，其「其國語思維的順暢度」，絕對還有再改善的空間。

一些檔案編輯過程的雜記2：
unicode.org 的字元屬性資料把「燙」這個漢字解釋為
kDefinition：scald, heat; wash; iron clothes
我去查了英漢字典，前兩組英文單字都還直觀上說得通。後兩個英文單字，我就覺得「過譯」，得自行去過度腦補才能連結意思。
「燙」如果參雜在「詞彙」之中，後兩組英文單字解釋當然也是可以説得通。
然而unicode的格式設計是僅針對漢字的單字本身，而不是詞彙，那就不該把詞彙的解釋拿來單字用，
整個unicode所有漢字的 kDefinition 若認真查閱起來，真的就是一堆的「過譯」。
許多不必要的第一時間誤會就是從這種細節產生的。