haskell – 為什麼圖書館設計師使用ByteString文字似乎是合適的？

,這似乎是我的問題的根源.但這其實不是我在這裡問的.

事情是,這不是我看到人們使用ByteString的唯一的地方,因為它對我來說似乎很明顯,只有Text是適當的,因為JSON不是一些二進位制檔案,它是一個可讀的文字,它可能很好地包含UTF8字元.

所以我想知道我是否缺少某些東西,而且有合理的理由選擇ByteString Over Text,或者這是一個很普遍的現象,這是由大多數人關心的任何其他字符集而不是拉丁語造成的壞圖書館設計.

只是一個誤會.

Prelude> print "Ёжик лижет мёд."
"\1025\1078\1080\1082 \1083\1080\1078\1077\1090 \1084\1105\1076."
Prelude> putStrLn "\1025\1078\1080\1082 \1083\1080\1078\1077\1090 \1084\1105\1076."
Ёжик лижет мёд.
Prelude> "{\"a\": \"Ёжик лижет мёд.\"}"
"{\"a\": \"\1025\1078\1080\1082 \1083\1080\1078\1077\1090 \1084\1105\1076.\"}"

當您列印包含字串的值時,將使用“Char”的“Show”例項,並轉義所有程式碼點高於127的所有字元.要獲取所需的字形,需要putStr [Ln] String.

所以aeson正確解碼utf8編碼的輸入,這是應該預期的,因為它utf8編碼的值本身：

encode = {-# SCC "encode" #-} encodeUtf8 . toLazyText . fromValue .
{-# SCC "toJSON" #-} toJSON

那麼為什麼aeson使用ByteString而不是Text來解碼的最終目標編碼和起始點.

因為這是適當的型別.編碼值旨在在機器之間可移植地傳輸.這發生在一個位元組流(八位位元組,如果我們在沮喪的心情).這正是ByteString提供的,然後必須以特定應用程式處理的位元組序列.為了aeson的目的,位元組流應該被編碼在utf-8中,並且aeson假定解碼函式的輸入是有效的utf-8,並將其輸出編碼為有效的utf-8.

轉移例如文字將遇到可移植性問題,因為16位編碼取決於位元組順序,因此文字不是在機器之間交換資料的適當格式.請注意,aeson在編碼時使用Text作為中間型別(也可能在解碼時),因為這是在中間階段使用的適當型別.