最近在轉檔時，遇到某本書名使用程式無法解析，程式會判斷沒有書名資訊，但用文字編輯器卻看不出有什麼問題？
該檔案是一個 UTF-8 編碼的 XML 檔，但我自己是習慣使用 Re 來解決這類小問題，我的正規表示法如下：
let regex = /dc:title.*>(.*)<\/dc:/
不論是 Javascript 或是 Python，都可以在正規表示式中任意圈出自己想要的資料，之後拿來使用就很方便。
回到問題身上，一開始會以為是不是書名裡有特殊字元導致，尤其這本書的書名接近 60 個字，實在嚇人。但把檔案和程式簡化後繼續測試，卻發生了隨機事件，有時候可以成功，有時候仍然不行？
嘗試使用 grep 和 Python 程式，兩者都可以正常執行，難道是我用的 Node.js 版本太舊導致？寫程式的大概都聽過類似的笑話：我的程式看起來沒問題呀，一定是 Compiler 的 Bug！殊不知這個是最不可能的事，如我一般的普通人寫的程式，理論上撞到這種問題的機率是非常的低，所以這個念頭也只是一閃而過。
好吧，來看看 binary 值好了，只要不是 ASCII 編碼的檔案我都很懶得看，畢竟我也無法一眼看出該中文的編碼為何？為了驗證這個問題，勢必要找出相關編碼的值才行。
檔案的 binary 內容長這樣。
書名最後 4 個字的編碼長這樣。
相比之下，結尾多了一個 E2 80 A9 的字，拿掉它之後，我的程式就恢復正常了。後來回想，之前發生隨機事件時，其實 UltraEdit 已經有徵兆，有時候針對該段文字反白複製時，偶爾便會看到一個不存在的字元，只是當時沒有想太多。
雖然問題解決了，但回到問題的本身，這個字是不合法的 UTF-8 字元嗎？
我們先來看看它的 binary 值。
1110 0010 # 1000 0000 # 1010 1001
它屬於 3 個位元的字元，其個別位元的開頭也有符合規則。將剩下的黑字再轉回 Unicode 碼，其值為 \u2029，跟用 Python Code 的 Re 結果一致。
使用 Chrome 直接開啟 XML 檔，可以正常顯示出該字元，使用全字庫網頁查詢，該字是一個中日韓相容表意文字區編碼。
查到這裡我就真的沒輒了，要再細究下去，可能要往 Node.js 用的 Re Code 方向去追查了。
後記
快下班時，無聊使用 \u2029 關鍵字查詢，才發現原來 \u2029 或是 \u2028 等字元，在正規式中是當做 a single white space，故會造成正規引擎把這一字元視為換行，而 "." 正規字元不包含換行字元，雖然可以用 "s" flag 來 match 換行字元，但書名就會包含換行字元，解決方式也很簡單，稍微更改 Re 即可。
let regex = /<dc:title.*>(.*)(\s*)<\/dc:title/
2020/11/22 更新
\u2028 是行分隔符
\u2029 則是段分隔符
不過重點還是 "." 字元不包含換行字元以外的字元， 我一直以為是包含全部字元，也算是學到一課了。
另外，這本書還真的是問題多多，放進我的 PW3 沒辦法更改字型，我目前的 PW3 版本為 5.13.2，我一向都是用 kindlegen 轉檔，這樣直式的書才能維持直式。
針對這個問題，好幾個網站都說即使是使用新型的 MOBI 格式，目前也不支持更改字型了，一定要使用 AW3 格式。但我覺得應該不是？一來我只有偶爾幾本書不行，二來我也有用 calibre 轉成 AW3 格式，結果一樣是不能更改字型。還好後來有看到一篇文章，說是把 CSS 裡面指定的字型拿掉即可，也就是 font-family 這行敘述拿掉，說也奇怪，這本書就這樣恢復正常了，我也終於可以使用我最喜歡的圓體字型來閱讀。
我後來想想，這個只是建議字型，理論上應該不影響功能才對。我目前只能想到 2 個原因，1 個是因為指定的字型有問題導致 Kindle 有 Bug，另外 1 個就是這本書不知道哪裡違反了 EPUB Spec 的規範。
我現在只能確定，隨便找了一本可以換字型的書，其 CSS 檔案也是有指定字型，差別在這本書的字型名稱沒有使用雙引號包住，而有問題的書則是同一行中有使用單引號，也有使用雙引號。理論上單雙引號皆可，只有在字型名稱包含空白時，才會使用引號包住。
沒有留言:
張貼留言