【问题标题】:Dealing with unusual responses to text messages处理对短信的异常回复
【发布时间】:2018-10-05 00:35:56
【问题描述】:

我编写了一个预约安排系统,它(除其他外)在预约到期前一天发送提醒短信。它要求用户通过对文本回复“OK”来确认他们是否参加了约会。

在人们回复的地方,它通常运作良好,并且减少了巨大的人工工作量。我现在正在整理一些缺陷(谢天谢地,它们很少而且影响很小),但偶尔我会看到@u{some string} 的回复。我没有规则来解析这个,所以他们进入一个无效的响应桶进行手动跟进。

今天看到回复如下:

@u004f006b

在这个阶段我很确定@u 表示后面是 Unicode(类似于 C# 中的 \u 指示符),因此假设我得到以下信息:

U+004F => 十进制 79 => O(大写)

U+006B => 十进制 107 => k(小写)

负责的公司告诉我消息是这样发送到他们的服务器上的,所以这一定是客户端问题,对吧?我查看了我的 SMS 发送应用程序(Android 7.x 上的 ChompSMS),看不到任何将其设置为以 Unicode 和 ASCII 显式发送的内容,所以我想知道这是怎么发生的?

我从数据库中提取了 10 个以这个 Unicode 标识符开头的随机响应,并尝试编写一些东西来处理它们。以下是我对此的天真尝试:

using System;
using System.Text;

namespace CharConversion
{
    class Program
    {
        static void Main()
        {
            string[] unicodeResponses = new string[]
            {
                "@U00430061006e20190074002000620065002000610062006c006500200074006f002000620065002000740068006500720065",
                "@U004f006b002000bf00bf",
                "@U004f006b002000bf00bf",
                "@U004f004b002000bf00bf",
                "@U004f006b002000bf00bf",
                "@U00d2006b",
                "@U004f004b",
                "@U004f006b00610079002000bf00bf0020",
                "@U004f004b",
                "@U004f006b00bf00bf00bffffd"
            };

            foreach (string unicodeResponse in unicodeResponses)
            {
                string characters2 = UnicodeCodePointsToString(unicodeResponse);
                Console.WriteLine("'{0}' is '{1}' in plain text", unicodeResponse, characters2);
            }

            Console.Read();
        }

        private static string UnicodeCodePointsToString(string unicodeResponse)
        {
            string[] characterByteValues = SplitStringEveryN(unicodeResponse.Substring(2), 4);
            char[] characters = new char[characterByteValues.Length];

            for (int i = 0; i < characterByteValues.Length; i++)
            {
                int ordinal = Int32.Parse(characterByteValues[i], System.Globalization.NumberStyles.HexNumber);
                characters[i] = (char) ordinal;
            }

            return new string(characters);
        }

        private static string[] SplitStringEveryN(string input, int splitLength)
        {
            StringBuilder sb = new StringBuilder();
            for (int i = 0; i < input.Length; i++)
            {
                if (i % splitLength == 0)
                {
                    sb.Append(' ');
                }
                sb.Append(input[i]);
            }

            string[] returnValue = sb.ToString().TrimStart().Split(' ');
            return returnValue;
        }
    }
}

我的问题:

  1. 首先为什么会发生这种情况?

  2. 使用代码 - 我在这里有什么遗漏吗?例如。框架中是否有一些东西已经可以为我处理这个问题,或者是否有一些对 Unicode 了如指掌的人可以看到的明显缺点?有什么我可以做得更好的吗?

  3. 一些代码点仍然呈现为颠倒的问题(我怀疑这些是表情符号) - 有什么办法可以处理它们吗?

编辑 2018-04-26 留给后代的说明

(我打算把它放在评论中,但不管我用它做什么,它看起来都很糟糕)

我查看了已接受答案中的链接,虽然代码比我的更简洁,但最后的输出是相同的 - 包括倒置的问号(以及我怀疑是表情符号的字形)。更多关于 Unicode 和 UCS2 can be found herethe Wikipedia article 之间差异的阅读也值得一读:

TL;DR

  • UCS-2 已过时并已被 UTF-16 取代 UCS-2 是 固定宽度编码方案,而 UTF-16 是可变宽度编码 方案
  • 支持 UTF-16 的应用程序可以读取 UCS-2 文件,但不能读取 其他方式
  • UTF-16 支持从右到左的脚本,而 UCS-2 没有
  • UTF-16 支持规范化,而 UCS-2 不支持

【问题讨论】:

  • 我怀疑倒置问号确实是倒置问号。例如,第二个示例字符串末尾包含“0x00BF,0x00BF”,这确实是 unicode 倒置问号。例如,它们用于西班牙语,因此它们有可能是合法的(例如“OK ??”消息)。
  • 而在最后一个字符串中,最后一个字符是0xfffd,它是通用的unicode替换字符,用于替换无法识别的东西。所以我怀疑即使有一些表情符号 - 它们在这些数据到达你之前丢失了。
  • ^ 这个。上游正在这样做,因为供应商坚持认为这是消息到达他们的方式。无论如何,我认为现在已经“足够好”,以至于阅读报告的人现在可以从中推断出足够的含义。再次感谢!
  • 是的,据我了解,您只需要弄清楚回复是否“OK”,这就足够了。
  • 没错,它仍然属于无效响应类别,但最终用户可以从中推断出足够的含义,因此他们可以手动确认约会而无需致电客户。

标签: c# .net text unicode ucs2


【解决方案1】:

SMS 消息可以使用多种编码进行编码。其中包括 7 位 (GSM-7)、8 位和 16 位 (UCS2)。虽然大多数 SMS 程序以最不浪费的编码方式对消息进行编码 - 即使所有字符都属于其他编码范围,使用 16 位编码也没有什么无效的。这就是我假设你的情况会发生什么。当然,短信是作为字节传输的,而不是作为u004f006b 字符串传输的,所以为什么它会这样表示是您使用的工具\与您合作的第三方的问题。

至于你的解析代码。它假定字符串为 UTF-16(C# 字符串的内部表示),但如果上述正确,则编码为 UCS2。它与 UTF-16 非常相似,但并不完全相同。我不太有资格讨论差异,但您可以查看例如 this answer 以获取有关如何使用它的一些线索。这也可能是某些字符被错误解码的原因。

【讨论】:

    【解决方案2】:

    这是更简单的方法:

    using System;
    using System.Text;
    
    namespace CharConversion
    {
        class Program
        {
            static void Main()
            {
                string[] unicodeResponses = new string[]
                {
                    "@U00430061006e20190074002000620065002000610062006c006500200074006f002000620065002000740068006500720065",
                    "@U004f006b002000bf00bf",
                    "@U004f006b002000bf00bf",
                    "@U004f004b002000bf00bf",
                    "@U004f006b002000bf00bf",
                    "@U00d2006b",
                    "@U004f004b",
                    "@U004f006b00610079002000bf00bf0020",
                    "@U004f004b",
                    "@U004f006b00bf00bf00bffffd"
                };
    
                string message = "";
    
                foreach (string unicodeResponse in unicodeResponses)
                {
                    for (int i = 2; i < unicodeResponse.Length; i += 4)
                    {
                        message += (char)Int16.Parse(unicodeResponse.Substring(i, 4), System.Globalization.NumberStyles.HexNumber);
                    }
                }
                Console.WriteLine(message);
                Console.Read();
            }
    
    
        }
    }
    

    【讨论】:

    • 代码转储不被视为答案,特别是当 OP 提出代码未回答的问题时。不知道这个转储如何帮助任何人理解问题
    • 虽然这有点用处(它使代码更简洁),但其代价是 IMO 的可读性和可维护性。此外,它只尝试回答所问问题的三分之一
    • 我做得更好。当有人创建非常复杂的代码而不是非常简单的代码时,您不要尝试修复错误的代码。而是推荐一个更好的解决方案。
    猜你喜欢
    • 2021-06-29
    • 1970-01-01
    • 2015-08-19
    • 2020-12-06
    • 2012-08-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-12-16
    相关资源
    最近更新 更多