haskell - logotipos - ¿Por qué los diseñadores de bibliotecas usan ByteString donde el texto parece ser apropiado?

logos para biblioteca

Question

Trabajando en mi aplicación, me he topado con un problema de Aeson que no decodifica la entrada UTF8 . Al profundizar, descubrí que se basa en Parser ByteString de Attoparsec, que para mí parece ser la fuente del problema. Pero en realidad no es lo que estoy preguntando aquí.

El problema es que no es el único lugar donde he visto a personas que usan ByteString donde, como me parece obvio, solo el Text es apropiado, porque JSON no es un archivo binario, es un texto legible y puede contener caracteres UTF8. .

Así que me pregunto si me estoy perdiendo algo y hay razones válidas para elegir ByteString sobre Text o simplemente es un fenómeno generalizado de un mal diseño de biblioteca causado por la mayoría de las personas que se preocupan menos por cualquier otro conjunto de caracteres que el latino.

Answer 1

Creo que tu problema es solo un malentendido.

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./"}"

Cuando print un valor que contiene una String , se usa la instancia Show para Char , y que escapa a todos los caracteres con puntos de código por encima de 127. Para obtener los glifos que desea, debe poner la putStr[Ln] .

Así que aeson decodificó correctamente la entrada codificada en utf8, como debería esperarse porque utf8 codifica los valores en sí mismos:

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

Por lo tanto, a la pregunta de por qué aeson usa ByteString y no Text para el objetivo final de la codificación y el punto de inicio de la decodificación.

Porque ese es el tipo apropiado. Los valores codificados están destinados a ser transferidos entre máquinas. Eso sucede como un flujo de bytes (octetos, si estamos en un estado de ánimo pedante). Eso es exactamente lo que proporciona un ByteString , una secuencia de bytes que luego deben tratarse de una manera específica de la aplicación. Para los fines de aeson , el flujo de bytes se codificará en utf-8, y aeson asume que la entrada de la función de decode es válida utf-8, y codifica su salida como utf-8 válida.

La transferencia, por ejemplo, de Text tendría problemas de portabilidad, ya que una codificación de 16 bits depende de la endianidad, por lo que el Text no es un formato apropiado para el intercambio de datos entre máquinas. Tenga en cuenta que aeson utiliza el Text como un tipo intermedio cuando codifica (y probablemente también cuando decodifica), porque es un tipo apropiado para usar en etapas intermedias.

Answer 2

El estándar JSON se ha establecido en UTF-16, no en UTF-8. Más detalles están disponibles en el sitio web oficial, http://json.org/ . (Y en defensa adicional de Aeson, los bits binarios de JSON no están expuestos a través de su interfaz: el constructor de String de un Value contiene un Text , no un ByteString ).