[entangled]ASCII 和 Tryte 的轉換
大家都知道在 iota 中是使用 Trinary (三進位)系統，因此在送資料的時候必須從電腦原本的二進位編碼轉換為三進位編碼。這本身沒有什麼問題，說不定反而要說是 IOTA 的特色之一。當初幾個 IOTA 理想主義色彩濃厚的元素，三進位就是其中之一。但是呢本人最近在開發 IOTA 軟體的時候發現被大大的 gank 了，所以特別寫了這篇文章來解釋一下。
其實可以快速的總結說我為什麼覺得我被 entangled 陰了一波。在 IOTA 的官方函式庫「們」(對的不只有 entangled 這個 C 語言的函式庫)，可以找到像下面這邊列出的 tryte 轉 ascii、ascii 轉 tryte 的函式。
當初的我很天真地以為這只是做型態轉換，所以我預計會有下面的轉換結果
轉換前的 ascii 字串 ABCDEFG
轉換後的 tryte 編碼 ABCDEFG
但實際上轉換的結果會是
轉換前的 ascii 字串 ABCDEFG
轉換後的 tryte 編碼 KBLBMBNBOBPBQB
好的我知道有些人會覺得我很蠢，轉換當然會變成不一樣的東西啊，還覺得轉換後會是一模一樣的我是不是智障。但是但是!! 我必須解釋這是有原因的。因為我考慮到我的轉換前的 ascii 就已經是以 IOTA 的 三進位方式進行編碼，理應不需要再進行轉換。但天知道 IOTA 官方函式庫給的轉換函式其實做的是把輸入的字串不管怎樣都把它當作一個 256 範圍內的數字，轉換成兩個三進位的 tryte。換言之，我把編碼轉換函式 (ascii_to_trytes()和 trytes_to_ascii()) 當作是變數型態轉換函式才會造成這個笨問題。
那麼究竟是如何轉換的呢？其實公式十分的簡單就只是把這個最大值為 256 的數字轉成以兩位數的 27 進位數表達。以字元 A 當作例子，A 根據 ascii table 若以數字表達是 65，首先 27 進位的個位數(最右邊的數)是 65 / 27 的商 = 2，十位數(右邊數來第2位數)是 65 / 27 的餘數 = 11。
所以到這邊我們知道，65 可以表達成: [11, 2]
根據 tryte table 的順序
TRYTE_ALPHABET = 9ABCDEFGHIJKLMNOPQRSTUVWXYZ11 是 K，2 是 B。因此 A (ascii) = KB (trytes)
因為太快打完了，所以補一些前陣子處理這玩意而遇到的心得。
如果大家有注意到的話 ascii 的定義其實範圍只有到 127，換句話說，char 的最高位 (sign bit) 完全不會用到，那這部份在 C 語言的函式 entangled 中其實會產生些問題 (對的我就是被這問題雷過不然怎麼知道有問題)。在 entangled 中若是 core API 收到 unicode 的輸入，會造成整個軟體 SEGV，爭個爆炸，其根本原因就是因為 unicode 編碼有時候會用到 sign bit，那這樣我就不能把這個 char 變數所儲存的數字當作 ascii 來解碼，因為 ascii 根本沒有定義到這個數字。
目前我自己想到的解決方法是把前 4 bit 轉成一個 tryte，後 4 bit 轉成一個 tryte，這樣就可以輕鬆迴避掉 sign bit 的問題， core api 對於各種編碼也會直接相容。但是有個缺點就是跟現在的編碼轉換方式不同軌。但就看之後要如何解決摟。
