漢字字形的處理

Hacker News 上看到「Your Code Displays Japanese Wrong (heistak.github.io)」這篇,原文是「Your Code Displays Japanese Wrong」。

這個算是 CJK 族群的經典問題,主要的問題是有不同的團體都在使用漢字,但雖然都是 U+5203 的「刃」,在不同的地區的「標準寫法」是不一樣的,像是「國家教育研究院 - 教育部國語小字典-刃」這邊就有 SVG 版本的「圖」可以看:

我在 different-lang.html 這邊把他提到的「刃直海角骨入」給放了進去,指定不同的 lang,像是這樣:

<dt>lang="jp"</dt><dd lang="jp">刃直海角骨入</dd>

如果你的電腦裡面有 Noto Sans CJK 的話,應該可以看出不同的字形。

在 HTML 網頁上可以利用 html 內的 lang 資訊告訴瀏覽器去抓取對應的字形,當然,系統有沒有這個字形又是另外一回事了,不過市場上至少有 open source license 的 Noto CJK 系列,算是個低標的答案可以用。

至於要更多樣的話,應該是要分不同語言下去找...

修好 Trac 1.6 上的 SlackIntegration

續上篇「修好 Trac 1.6 上的 TracSubtickets」提到的,反正 Trac 這個 community 的東西如果爛掉的話,自己修會比較快...

SlackIntegration 從字面上的意思就知道,是把 Trac 這邊的更新同步到 Slack 上的工具。

這包主要的問題是 Python 2 語法,所以在修的過程中間就不斷的在想起「啊,這是當初 Python 3 的 break-BC 改動」。

從「Comparing 72bec82..master · gslin/trac-slack-plugin」這邊可以可以到修正的東西,主要修正的都是跟 unicode 有關的程式碼。

一塊是 2to3 修正的,把 u'...' 這種字串直接變成 '...',不需要額外指定,另外是 unicode(...) 變成 str(...)

另外一個也還是 unicode 相關的,但因為是邏輯上的部分,2to3 沒有抓出來的,是 encode('utf-8') 的部分看起來就用不到了,這在 Python 3 裡面 requests 會自動處理掉,只要丟標準的 string (unicode string) 進去就可以了。

這樣又弄好一個套件了...

提議 OpenJDK 的程式碼 UTF-8 化

Hacker News 上看到提議把 OpenJDK 的程式碼 UTF-8 化:「Make JDK source code UTF-8 (openjdk.org)」,原始的 jira ticket 在「Make JDK source code UTF-8」這邊。

主要是現在的 source code 沒有統一標準:

Currently, the source code in the JDK is in an ill-defined encoding. There is no official declaration of the encoding used. It is "mostly ASCII", but the relatively few non-ASCII characters used are not well-defined. In many cases, it is latin-1, but I am pretty certain other encodings are used for e.g. Asian translations.

而 mailing list 上看起來還是有想要維持 ASCII 的討論:「Making the source code utf-8」,不過他提出來的理由我覺得不太行,在 console 跑 vi 或是 emacs 我覺得不太是個好理由...

Brian Kernighan 幫 AWK 加上 Unicode 支援

看到這個 commit,裡面是 Brian KernighanAWK 加上 Unicode 支援的信件。

現在在各 OS 下都有包不一樣的 AWK 實做,像是 Linux 下常見的 GNU awk,所以這個 patch 原版的 AWK 其實還好,但更多的是一種景仰的感覺...

Brian Kernighan 就是 AWK 的作者之一 (AWK 裡的 K 就是他),另外一個更為人熟知的就是經典的 The C Programming Language 這本書,或是因此而知名的簡寫,K&R 裡面的 K。

老人家八十歲還會送 patch 給現在的 maintainer 加功能...

JSON Canonicalization

這篇是講 JSON object 上的簽名,但實際上就是在討論 JSON Canonicalization 的前因後果:「How (not) to sign a JSON object」。

在處理 JSON 資料時,「判斷兩個 JSON object 是否相同」是一個不怎麼簡單的問題,其中一個想法是找一個機制可以把意義相同的 JSON object 都轉成相同的 (byte)string representative,這也就是 JSON Canonicalization。當你可以確保意義相同的 JSON Canonicalization 後,你就可以對 string 本身簽名。

這件事情其實在 XML 就有過同樣的歷史故事 (yeah,總是有人愛在某種資料格式上面疊上簽名),也就是「XML Signature」這個方式。

在 XML 這邊不幸的是,還不少標準選用 XML Signature,像是當年為了實做 Google Apps (現在叫做 G Suite) 的 SSO,而需要接 SAML...

回到原來的 JSON Canonicalization,可以馬上想到的變化包括了空白與 object 裡 key 的順序,也就是這兩個:

{"a":1,"b":2}
{
  "b": 2,
  "a": 1
}

但不幸的是,還有 Unicode 來一起亂,也就是下面這個跟上面有相同的意思:

{
  "\u0062": 2,
  "\u0061": 1
}

另外還有其他的地雷是平常不會想到的,如果你因為複雜而決定用 library 來做,那也代表 library 必須面對這些複雜的情境,未必沒有 bug...

所以文章作者在最後面才會請大家不要再來亂了 XDDD

Maybe you don’t need request signing? A bearer token header is fine, or HMAC(k, timestamp) if you’re feeling fancy, or mTLS if you really care.

Canonicalization is fiendishly difficult.

Add a signature on the outside of the request body, make sure the request body is complete, and don’t worry about “signing what is said versus what is meant” – it’s OK to sign the exact byte sequence.

繼續吵 Unicode 裡啤酒的圖示...

在「大家在吵漢堡的 Unicode 呈現...」這邊在吵漢堡,然後有人就開始找事了 XDDD

然後有點煩 XDDD

最近應該會有一波熱潮 XDDD

大家在吵漢堡的 Unicode 呈現...

前幾天在 Twitter 看到這個 tweet,然後在高雄的時候 (MOPCON 2017),跟 zonble 聊天時他也提到這則 tweet 很有趣 XD:

然後有人回必要條件 XDDD:

結果微軟是對的 XDDD

然後這邊有實物照片:

不過比較有實際價值的是知道了「? Emojipedia — ? Home of Emoji Meanings ????」這個站台,可以查每個平台的呈現方式...

用 unicode-range 混合不同的字型

Combining fonts」這邊示範了如何使用 CSS 的 unicode-range 針對某些特殊字元混用不同的字型,作者利用這個技巧,把 hyphen 與 equals 換掉...:

看了一下,支援度還蠻高的?IE 支援度是 9+ 的功能...

利用 Unicode Domain 釣魚,以及 Chrome 與 Firefox 的解法

一個多禮拜前引起蠻多討論的一篇文章,利用 Unicode Domain 釣魚的方法:「Phishing with Unicode Domains」。

由於這是幾乎完美的攻擊,所以被提出來後 (Security: Whole-script confusable domain label spoofing) 有不少討論:

This bug was reported to Chrome and Firefox on January 20, 2017 and was fixed in the Chrome trunk on March 24. The fix is included in Chrome 58 which is currently rolling out to users.

comment 8 提到:

We do have a whitelist. Essentially you're suggesting that we remove Cyrillic and Greek characters from the list. I'm not sure we want to go down that path.

在新版的 Chrome 58 已經「修正」了這個問題:

Firefox 的討論在「IDN Phishing using whole-script confusables on Windows and Linux」這邊,一開始就直接把票給關了 XDDD:

Indeed. Our IDN threat model specifically excludes whole-script homographs, because they can't be detected programmatically and our "TLD whitelist" approach didn't scale in the face of a large number of new TLDs. If you are buying a domain in a registry which does not have proper anti-spoofing protections (like .com), it is sadly the responsibility of domain owners to check for whole-script homographs and register them.

We can't go blacklisting standard Cyrillic letters.

If you think there is a problem here, complain to the .com registry who let you register https://www.xn--80ak6aa92e.com/ .

Gerv

Status: NEW → RESOLVED
Last Resolved: 3 months ago
Flags: needinfo?(gerv)
Resolution: --- → WONTFIX

然後一個月前被提出來看看 Chrome 怎麼做:

Gerv/Valentin, is this something we can/should align with Chromium on?

目前唯一的解法是改 flag,把所有的 Unicode Domain 直接當作一般的 domain 來處理,列出像是 www.xn--80ak6aa92e.com 的網址。

用 Unicode 字元當作短網址編碼的服務...

Hacker News Daily 上看到的服務:「9m URL Shortener」。

居然用 Unicode 短網址當作編碼的部份... 是很有趣啦,不過因為難以輸入,只適合用在 internet 上的傳遞?而不是讓人輸入的...

有些字在我的電腦上還出不來 XDDD