android - 使用 Erlang 解析 ASCII 字符

Question

对需要进行哪些解析以及在客户端/服务器端进行哪些解析感到困惑。

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

在此之后，我将其作为推送通知发送给我的客户(静默地通过 GCM/APNS)。从那里开始，客户端通过 UTF-8 解码一个一个地对每个数字进行构建(这是错误的)。

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

如果要接受两个字节或三个或更多字节，则此重建需要标识。这因字母的语言而异(例如德语)。

客户端如何确定要重构的语言(一次性解码的字节数)？

要添加更多，

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}]})).

将 json 生成为:

"{\"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}"

在我给出“hi”作为消息的地方，mochijson 给了我 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

但是当我使用 http://www.unit-conversion.info/texttools/ascii/

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

那么，谁应该做解析？应该如何处理。

当重构 ASCII 时，我重构的消息全是乱码。

谢谢

Answer 1

这里要担心的事情有很多，并且与所需的编码或数据结构有关。在 Erlang 中，文本以下列方式之一处理:

1. 字节列表 ( [0..255, ...] )
   • 如果您监听一个套接字并且数据以列表形式返回，您就会得到这种结果。
   • VM 假定没有编码。它们是字节，意义不大。
   • 但是 VM 可以将这些解释为字符串(例如 io:format("~s~n", [List]) )。当发生这种情况时(具体使用 ~s 标志)，VM 假定编码为 latin-1。 (ISO-8859-1)。
2. Unicode 代码点列表 ( [0..1114111, ...] )。
   • 您可以从以 unicode 和作为列表读取的文件中获取这些信息。
   • 当你有像io:format("~ts~n", [List])这样的格式化程序时，你可以在输出中使用它们其中 ~ts就像~s但作为 unicode。
   • 这些列表代表您在 unicode 标准中看到的代码点，没有任何编码(它们不是 UTF-x)
   • 这可以与 latin-1 字符列表结合使用，因为 Unicode 代码点和 latin1 字符在 255 以下具有相同的序列号。
3. 二进制文件 ( <<0..255, ...>> )
   • 如果您在 binary 下收听或阅读任何内容，这就是您得到的结果格式。
   • 可以告诉 VM 假设很多事情:
     1. 它们是字节序列(0..255)，没有特定含义(<<Bin/binary>>)
     2. 它们是 utf-8 编码序列 ( <<Bin/utf-8>> )
     3. 它们是 utf-16 编码序列 ( <<Bin/utf-16>> )
     4. 它们是 utf-32 编码序列 ( <<Bin/utf-32>> )
   • io:format("~s~n", [Bin])仍然会假设任何序列都是 latin-1 序列； io:format("~ts~n", [Bin])将假设 UTF-8仅。
4. unicode 列表和 utf 编码二进制文件的混合列表(称为 iodata() )，专门用于输出。

总而言之:

• 字节列表
• latin-1 字符列表
• Unicode 代码点列表
• 二进制字节
• utf-8 二进制
• utf-16二进制
• utf-32 二进制
• 其中的许多列表用于快速连接的输出

另请注意:在 17.0 版之前，所有 Erlang 源文件都仅为 latin-1。 17.0 添加了一个选项，通过添加此 header 让编译器将源文件读取为 unicode:

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

下一个因素是 JSON，根据规范，假设 UTF-8作为它所拥有的一切的编码。此外，Erlang 中的 JSON 库倾向于假定二进制文件是字符串，而列表是 JSON 数组。

这意味着如果您希望输出足够，则必须使用 UTF-8 编码的二进制文件来表示任何 JSON。

如果你拥有的是:

• 一个表示 utf 编码字符串的字节列表，然后是 list_to_binary(List)获得正确的二进制表示
• 代码点列表，然后使用 unicode:characters_to_binary(List, unicode, utf8)得到一个utf-8编码的二进制文件
• 表示 latin-1 字符串的二进制文件:unicode:characters_to_binary(Bin, latin1, utf8)
• 任何其他 UTF 编码的二进制文件:unicode:characters_to_binary(Bin, utf16 | utf32, utf8)

获取该 UTF-8 二进制文件，并将其发送到 JSON 库。如果 JSON 库是正确的并且客户端正确解析它，那么它应该是正确的。