Question

我写了一个预约安排系统，其中（除其他外）在预约到期前一天发出提醒短信。它要求用户通过向文本回复“确定”来确认他们出席约会。

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

今天我看到的回复如下：

@ u004f006b

我很确定在这个阶段，@ u表示接下来是Unicode（类似于C＃中的\ u指示符）所以做出这个假设我得到以下内容：

U + 004F =＆gt;十进制79 =＆gt; O（大写）

U + 006B =＆gt;十进制107 =＆gt; k（小写）

负责的公司告诉我，这条消息正在打击他们的服务器，所以它必须是客户端问题吗？我查看了我的短信发送应用程序（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;
        }
    }
}

我的问题：

为什么会发生这种情况？
使用代码 - 这里有什么我想念的吗？例如。框架中有什么东西可以为我处理这个问题，还是有一些明显的缺点，知道所有关于Unicode的人都可以看到？有什么我可以做得更好吗？
有些代码点仍然呈现为颠倒的问题（我怀疑这些是表情符号） - 有什么方法可以处理它们吗？

编辑2018-04-26后人的说明

（我打算将其放在评论中，但无论我用它做什么，它看起来都很糟糕）

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

TL; DR

UCS-2已经过时，已经被UTF-16取代，UCS-2是一个固定宽度编码方案，而UTF-16是可变宽度编码方案
支持UTF-16的应用程序可以读取UCS-2文件但不能读取
UTF-16在UCS-2时支持从右到左的脚本
UTF-16支持规范化，而UCS-2不支持

Answer 1

SMS消息可以使用多种编码进行编码。这些包括7位（GSM-7），8位和16位（UCS2）。虽然大多数SMS程序以最少浪费的编码对消息进行编码 - 但即使所有字符都属于其他编码范围，使用16位数也没有任何效果。那是我假设你的情况会发生什么。当然sms消息是作为字节传输的，而不是Select * FROM ( SELECT u.YearDt, u.MonthDt, u.DayDt, u.HourDt, u.MinDt, COUNT(Distinct u.session_id) as unique_sessions, COUNT(Distinct u.user_name) as unique_users, LISTAGG(u.user_name, ', ') WITHIN GROUP (ORDER BY u.user_name ASC) as users FROM (SELECT EXTRACT(year FROM l.start_date) as YearDt, EXTRACT(month FROM l.start_date) as MonthDt, EXTRACT(day FROM l.start_date) as DayDt, EXTRACT(HOUR FROM CAST(l.start_date AS TIMESTAMP)) as HourDt, EXTRACT(MINUTE FROM CAST(l.start_date AS TIMESTAMP)) as MinDt, l.session_id, l.user_name, l.start_date as act_date, 1 as is_start FROM web_session l UNION ALL SELECT EXTRACT(year FROM l.stop_date) as YearDt, EXTRACT(month FROM l.stop_date) as MonthDt, EXTRACT(day FROM l.stop_date) as DayDt, EXTRACT(HOUR FROM CAST(l.stop_date AS TIMESTAMP)) as HourDt, EXTRACT(MINUTE FROM CAST(l.stop_date AS TIMESTAMP)) as MinDt, l.session_id, l.user_name, l.stop_date as act_date, 0 as is_start FROM web_session l ) u GROUP BY CUBE ( u.YearDt, u.MonthDt, u.DayDt, u.HourDt, u.MinDt) ) c字符串，所以为什么它被表示为你使用的工具\你使用的第三方。

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

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();
        }


    }
}

处理针对短信的异常回复

2 个答案: