sirve que para numeral funciona ejemplos como codigos codigo binario android erlang xmpp apple-push-notifications ejabberd

android - numeral - para que sirve el codigo ascii



Análisis de caracteres ASCII con Erlang (1)

Las cosas de las que preocuparse aquí son muchas y tienen que ver tanto con la codificación deseada como con la estructura de datos. En Erlang, el texto se maneja de una de las siguientes maneras:

  1. listas de bytes ( [0..255, ...] )
    • Esto es lo que obtienes si escuchas un socket y los datos se devuelven como una lista.
    • La VM asume que no hay codificación . Son bytes y significan poco más.
    • Sin embargo, la VM puede interpretarlos como cadenas (por ejemplo, en io:format("~s~n", [List]) ). Cuando eso sucede (con el indicador de ~s específicamente), la máquina virtual asume que la codificación es latin-1 (ISO-8859-1).
  2. listas de puntos de código Unicode ( [0..1114111, ...] ).
    • Puede obtenerlos de archivos que se leen como unicode y como una lista.
    • Puede usarlos en salida cuando tenga un formateador como io:format("~ts~n", [List]) donde ~ts es como ~s pero como unicode.
    • Esas listas representan los puntos de código que se ven en el estándar Unicode, sin ninguna codificación (no son UTF-x )
    • Esto puede funcionar junto con listas de caracteres latin-1 porque los puntos de código Unicode y latin1 tienen los mismos números de secuencia por debajo de 255.
  3. Binarios ( <<0..255, ...>> )
    • Esto es lo que obtienes si escuchas o lees a / desde cualquier cosa bajo un formato binary .
    • Se puede decir a la VM que asuma muchas cosas:
      1. Son secuencias de bytes ( 0..255 ) sin significado específico ( <<Bin/binary>> )
      2. Son secuencias codificadas en utf-8 ( <<Bin/utf-8>> )
      3. Son secuencias codificadas en utf-16 ( <<Bin/utf-16>> )
      4. Son secuencias codificadas en utf-32 ( <<Bin/utf-32>> )
    • io:format("~s~n", [Bin]) seguirá suponiendo que cualquier secuencia es una secuencia latin-1; io:format("~ts~n", [Bin]) asumirá UTF-8 solamente.
  4. Una lista mixta de listas unicode y binarios utf-codificados (conocidos como iodata() ), utilizados exclusivamente para salida.

Entonces en una esencia:

  • listas de bytes
  • listas de caracteres latin-1
  • listas de puntos de código Unicode
  • binario de bytes
  • utf-8 binary
  • utf-16 binary
  • utf-32 binario
  • listas de muchos de estos para salida que se concatena rápidamente

También para tener en cuenta: hasta la versión 17.0, todos los archivos fuente de Erlang eran latin-1 solamente. 17.0 agregó una opción para que el compilador lea su archivo fuente como unicode al agregar este encabezado:

%% -*- coding: utf-8 -*-

El siguiente factor es que JSON, por especificación, asume UTF-8 como una codificación para todo lo que tiene. Además, las bibliotecas JSON en Erlang tenderán a suponer que un binario es una cadena, y que las listas son matrices JSON.

Esto significa que si desea que su salida sea adecuada, debe usar binarios codificados en UTF-8 para representar cualquier JSON.

Si lo que tienes es:

  • Una lista de bytes que representan una cadena utf-encoded, luego list_to_binary(List) para obtener la representación binaria correcta
  • Una lista de puntos de código, luego use unicode:characters_to_binary(List, unicode, utf8) para obtener un binario codificado en utf-8
  • Un binario que representa una cadena latin-1: unicode:characters_to_binary(Bin, latin1, utf8)
  • Un binario de cualquier otra codificación UTF: unicode:characters_to_binary(Bin, utf16 | utf32, utf8)

Tome ese binario UTF-8 y envíelo a la biblioteca JSON. Si la biblioteca JSON es correcta y el cliente la analiza correctamente, entonces debería ser correcta.

Confundido con lo que debe hacerse el análisis y en qué final cliente / servidor.

When i send an Umlaut ''Ö'' to my ejabberd, it is received by ejabberd as <<"195, 150">>

Después de esto, le envío esto a mi cliente como notificaciones Push (a través de GCM / APNS en silencio). A partir de ahí, el cliente construye mediante decodificación UTF-8 en cada número uno por uno (esto es incorrecto).

i.e. 195 is first decoded to gibberish character � and so on.

Esta reconstrucción necesita identificación si se van a entretener dos bytes o 3 o más. Esto varía con el lenguaje de las letras (en alemán aquí, por ejemplo).

¿Cómo identificaría el cliente el idioma que va a reconstruir (número de bytes para decodificar de una vez)?

Para agregar más,

lists:flatten(mochijson2:encode({struct,[{registration_ids,[Reg_id]},{data ,[{message,Message},{type,Type},{enum,ENUM},{groupid,Groupid},{groupname,Groupname},{sender,Sender_list},{receiver,Content_list}]},{time_to_live,2419200}]})).

Produjo el json como:

"{/"registration_ids/":[/"APA91bGLjnkhqZlqFEp7mTo9p1vu9s92_A0UIzlUHnhl4xdFTaZ_0HpD5SISB4jNRPi2D7_c8D_mbhUT_k-T2Bo_i_G3Jt1kIqbgQKrFwB3gp1jeGatrOMsfG4gAJSEkClZFFIJEEyow/"],/"data/":{/"message/":[104,105],/"type/":[71,82,79,85,80],/"enum/":2001,/"groupid/":[71,73,68],/"groupname/":[71,114,111,117,112,78,97,109,101],/"sender/":[49,64,100,101,118,108,97,98,47,115,100,115],/"receiver/":[97,115,97,115]},/"time_to_live/":2419200}"

donde había dado "hola" como mensaje y mochijson me dio valores ASCII [104,105].

The groupname field was given the value "Groupname", the ASCIIs are also correct after json creation i.e. 71,114,111,117,112,78,97,109,101

Sin embargo, cuando uso http://www.unit-conversion.info/texttools/ascii/

It is decodes as Ǎo��me and not "Groupname".

Entonces, ¿quién debería hacer el análisis sintáctico? Cómo debería ser tratado el mismo

Mi mensaje reconstruido es todo gibberuish cuando se reconstruye el ASCII.

Gracias