*停權中*
加入日期: Feb 2018
文章: 33
|
關於UNICODE14.0的一些觀察雜記
UNICODE14.0 正式版的相關PDF、txt、網頁文件檔等等理論上預計明天在 unicode.org 官網正式公告,
當然部分的beta版資料已經先行上線了,我查到了網頁 http://www.unicode.org/charts/nameslist/ 把區段名稱依序瀏覽一輪,有些感慨, 仔細看區段名稱,可以發現一個細節,就是 拉丁字母系列的區段,越新加入的,碼位也會依序「往後擺」。 然而像是漢字系列、阿拉伯字母系列、日文假名系列等等其他非拉丁字母的文字系統系列, 卻發生,新加入的區段,碼位卻擺在該系列「舊的區段」「之前」的狀況, 這樣會導致在文書處理例如使用試算表的時候,如果操作試算表提供的的排序功能來給(非拉丁字母)的字元做排序, 少用或罕用字元,反而會被排序在常用字元「之前」的狀況。 在我的眼裡會解讀為,這完全就是美國在「細節之處」獨厚「拉丁字母」的「排序方便性」, 其他的文字系統,基本上就是有空的碼位就給它塞進去,而「不去顧慮」其他文字系統的排序方便性。 不過UNICODE這種東西,基本上還真的是美國說得算,反正你也可以選擇不用!? 它也沒有強迫你用! (但我還真的不得不用,我也沒有其它選擇了,個人能力範圍內只能用unicode)你能拿它怎麼樣? UNICODE14.0正式版的官方資料正式上線之後, 我會開始嘗試一點一滴的編輯更新UNICODE14.0全字元列表, 預計使用LibreOffice Calc 試算表格式, 原則上會包含到 字元名稱 和 區段名稱的 正體中文翻譯欄位, 至於什麼時候完成編輯並分享? 可遇不可求。 此文章於 2021-09-14 09:21 PM 被 FLYFLY4 編輯. |
|||||||
2021-09-14, 09:15 PM
#1
|
Junior Member
加入日期: Feb 2013
文章: 718
|
似乎是照部首及筆畫數排的。
我隨便看看的,也許有理解錯誤。 http://www.unicode.org/reports/tr38/#N101E4 https://stackoverflow.com/questions...-programming-la |
||
2021-09-14, 09:24 PM
#2
|
*停權中*
加入日期: Feb 2018
文章: 33
|
引用:
「區段」的部分,按照常用和罕用才合理。 此文章於 2021-09-14 09:34 PM 被 FLYFLY4 編輯. |
|
2021-09-14, 09:31 PM
#3
|
*停權中*
加入日期: Feb 2018
文章: 33
|
自編UNICODE14.0全字元列表分享,一份試算表檔案收錄了UNICODE14.0所整理的十四萬四千多個字元和符號。
這份檔案包含了Block Name、Subgroup Block Name、Character Name這三個欄位的正體中文翻譯。 正體中文翻譯沒有到達百分之百,但百分之九十五以上應該是有的。 檔案編輯環境是在 Mac Pro 2013 + 128GB RAM + macOS 10.15.7 + LO Calc v7.2。 有部分細節我依舊搞不定,原本預計要把"Supplementary Private Use Area-A/B"這兩個區段也全都放進表格內, 一個區段對應一個工作表,但編輯過程嚴重遲鈍,滑鼠游標彩球狂轉不同,最後我只好放棄了, 不收錄了"Supplementary Private Use Area-A/B"這兩個區段。 Tags、Variation Selectors Supplement 這兩個區段內的字元無法正常顯示出來, 我確定對應的字形檔都有安裝,至少 unicodechecker.app顯示得出來, 我處理不了這個問題。 一些資料彙整之後的雜感,我真的會覺得「美國」其實透過把全世界的文字和符號拿來數位化/電腦化/規範化, 其實間接的就是在某種程度的掌控著「文化」(尤其是「文字和符號」這部分)呈現在電腦這一個領域層面的「話語權」。 非英語系國家的人們,即便美國表面上也沒有強迫你使用,但你不得不用,除非你願意過著原始人的生活, 只要你要在現代社會使用個人電腦和網路通訊,你基本上就得會用到「美國」規範出來的東西。 UNICODE這套規範,不會是百分之百完美的,裡頭「誤解」他國的文字和符號意義的數量也真的可以數出一些。 別跟我扯「將錯就錯」沒差啦,知道有這麼一回事就好。 我會認為美國這樣一個相對大型的組織單位還在那邊「將錯就錯」是很不應該的。 也別跟我扯,你編輯出來的這份試算表,內容小問題也不會少。 個人編輯出來的佛系文件,跟相對龐大有資源、有預算的單位編輯出來的文件,層級是有差的。 UNICODE14.0-LOv7204-v1100926.ods https://sites.google.com/site/ianho...eCharactersList 有興趣、有需要的網友或許參考。 |
2021-09-26, 10:32 PM
#4
|
Senior Member
加入日期: Sep 2001 您的住址: K
文章: 1,444
|
感謝分享,Windows、macOS跟Linux都是美國或美國人弄出來的,
編碼格式也是,要他們修正哪有那麼容易,總之辛苦了。 引用:
|
|
2021-09-26, 11:20 PM
#5
|
*停權中*
加入日期: Feb 2018
文章: 33
|
引用:
雞蛋裡挑個骨頭,linux(的核心)基本算上是歐洲人弄出來的,不過linux的「觀念源頭」是unix-like, 然後美國人看得長遠,又把Linus請去美國工作,所以Linux又算是半個美國貨了∼唉∼∼∼∼ |
|
2021-09-26, 11:27 PM
#6
|
Senior Member
加入日期: Sep 2001 您的住址: K
文章: 1,444
|
是啊,我知道他是歐洲人,但也因為他有美國籍,所以Linux也算美國貨囉。
另外我也補充一下,Linux也算是源自早年由美國開發的UNIX, 所以說它是美國貨不算錯! 引用:
此文章於 2021-09-27 12:06 AM 被 substar999 編輯. |
|
2021-09-26, 11:57 PM
#7
|
Major Member
加入日期: Dec 2012
文章: 182
|
這不是寫程式給機器讀的嗎?當然是用有規律可循的的排序方式,怎麼會是靠常不常用?
|
2021-09-27, 04:53 AM
#8
|
Senior Member
加入日期: Sep 2001 您的住址: K
文章: 1,444
|
各人觀點不同,不過若改版本身也要確保軟體最大相容性的話,
要調整原有字元的位置難矣。 引用:
|
|
2021-09-27, 09:22 AM
#9
|
*停權中*
加入日期: Feb 2018
文章: 33
|
引用:
情境舉例,這裡以 unicode "block" 的排序為例, unicode這個美國組織 把 "CJK Unified Ideographs Extension A"(相對「不常用」的漢字,碼位相對在前)這個"block" 擺在 "CJK Unified Ideographs"(相對常用的漢字,碼位相對在後)「之前」。 這樣會造成一個狀況,當文書套裝軟體例如試算表使用排序功能時 (試算表預設依據unicode碼位區段來排序) 就會出現罕用漢字被排在在前,常用漢字被排在後的狀況。 我使用試算表軟體來協助編輯注音輸入法表格檔(支援到將近有九萬五千漢字,橫跨至少三個 unicode cjk漢字 block), 需要的就是常用漢字在前,罕用漢字在後,於是這樣我就麻煩了, 還好後來還有發現一個中華民國cns116643<>美國unicode的對照表, cns116643就是依照常用漢字在前罕用漢字在後的排序。 然而我發現,拉丁字母系列的 "block" 的排序,就完全是常用字母或連結字在前, 相對罕用的拉丁字母連結字等等在後。 所以不只是給機器讀,也是給人讀的。文書軟體排序的判讀方便性是有差別的。 |
|
2021-09-27, 11:33 AM
#10
|