我已经编写了一个预约调度系统,其中包括在约会到期日前一天发送一条提醒短信。它要求用户通过回复文本"OK“来确认他们出席约会的情况。
在人们确实回复的地方,它通常工作得很好,并且减少了大量的人工工作量。我现在正在整理一些缺陷(谢天谢地,它们很少,而且影响很小),但偶尔我会看到@u{some string}的响应。我没有规则来解析这一点,所以它们进入无效的响应桶进行手动跟踪。
今天,我看到了如下的回应:
@u004f006b
在这个阶段,我非常肯定@u表示下面的是Unicode (类似于C#中的\u标识符),因此,根据这个假设,我得到如下结论:
U+004F =>十进制79 => O(大写) U+006B =>十进制107 => k(小写)
负责的公司告诉我,信息是那样击中他们的服务器的,所以这一定是客户端的问题,对吗?我查看了我的短信发送应用程序(Android7.x上的ChompSMS),没有看到任何将其设置为在Unicode中显式发送的东西,所以我想知道这是如何发生的?
我从数据库中提取了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;
}
}
}我的问题:
编辑2018-04-26后人备注
(我本来打算发表评论的,但不管我做了什么,它看起来都很糟糕)
我看了一下被接受的答案中的链接,虽然代码比我的更简洁,但结尾的输出是相同的--包括倒问号(我怀疑这些符号是emojis)。更多地阅读Unicode与UCS2、可以在这里找到和维基百科文章之间的差异也值得一读:
TL;博士
发布于 2018-04-24 17:11:02
SMS消息可以用几个编码来编码。其中包括7位(GM-7)、8位和16位(UCS2).当大多数SMS程序以最少浪费的编码方式编码消息时,即使所有字符都属于其他编码范围,使用16位编码也没有任何无效。我猜你的情况就是这样。当然,sms消息是以字节的形式传输的,而不是以u004f006b字符串的形式传输的,所以,为什么会这样表示它是由您使用的\第三方工具决定的。
至于你的解析代码。它假定字符串在UTF-16 ( C#字符串的内部表示形式)中,但如果上面的表示是正确的,则编码是UCS2。它非常类似于UTF-16,但并不完全相同。我不太适合讨论差异,但您可以查看这个答案,以获得一些关于如何使用它的线索。这也可能是某些字符被错误解码的原因。
发布于 2018-04-24 17:19:41
下面是更简单的方法:
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();
}
}
}https://stackoverflow.com/questions/50006931
复制相似问题