处理对短信的异常回复
Dealing with unusual responses to text messages
我写了一个约会安排系统,它(除其他外)在约会到期前一天发送提醒短信。它要求用户通过回复 "OK" 文本来确认他们是否出席了约会。
人们回复的地方通常效果很好,并且减少了巨大的手动工作量。我现在正在整理几个缺陷(谢天谢地,它们很少而且影响很小),但偶尔我会看到 @u{some string}
的回复。我没有解析这个的规则,所以它们进入了一个无效的响应桶以供手动跟进。
今天看到回复如下:
@u004f006b
我很确定在这个阶段 @u 表示后面是 Unicode(类似于 C# 中的 \u 指示符)所以做出这个假设我得到以下内容:
U+004F => decimal 79 => O (uppercase)
U+006B => decimal 107 => k (lowercase)
负责的公司告诉我邮件是这样发送到他们的服务器的,所以这一定是客户端问题,对吧?我查看了我的 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;
}
}
}
我的问题:
为什么首先会发生这种情况?
有了代码 - 有什么我遗漏的吗?例如。 Framework 中有什么东西已经可以为我处理这个问题了吗?或者说,了解 Unicode 的人可以看到一些明显的缺点吗?有什么我可以做得更好的吗?
一些代码点仍然呈现为颠倒的问题(我自己怀疑这些是表情符号)-我有什么办法可以处理它们吗?
编辑 2018-04-26 给后代的注释
(我本来打算把它放在评论中的,但无论我用它做什么,它看起来都很糟糕)
我查看了已接受答案中的 link,虽然代码比我的更简洁,但最后的输出是相同的——包括倒置的问号(以及我怀疑的字形是表情符号)。关于 Unicode 和 UCS2 之间差异的更多阅读 can be found here and 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 不支持
SMS 消息可以使用多种编码方式进行编码。其中包括 7 位 (GSM-7)、8 位和 16 位 (UCS2)。虽然大多数 SMS 程序以最不浪费的编码对消息进行编码 - 即使所有字符都属于其他编码的范围,使用 16 位编码也没有任何无效。那就是我假设你的情况会发生什么。当然,短信是按字节传输的,而不是 u004f006b
字符串,所以为什么要这样表示取决于您使用的工具\与您合作的第三方。
至于你的解析代码。它假定字符串是 UTF-16(C# 字符串的内部表示),但如果以上内容正确,则编码为 UCS2。它与 UTF-16 非常相似,但又不完全相同。我不太适合讨论差异,但您可以查看 this answer 等示例,了解有关如何使用它的一些线索。这也可能是某些字符解码不正确的原因。
这是更简单的方法:
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();
}
}
}
我写了一个约会安排系统,它(除其他外)在约会到期前一天发送提醒短信。它要求用户通过回复 "OK" 文本来确认他们是否出席了约会。
人们回复的地方通常效果很好,并且减少了巨大的手动工作量。我现在正在整理几个缺陷(谢天谢地,它们很少而且影响很小),但偶尔我会看到 @u{some string}
的回复。我没有解析这个的规则,所以它们进入了一个无效的响应桶以供手动跟进。
今天看到回复如下:
@u004f006b
我很确定在这个阶段 @u 表示后面是 Unicode(类似于 C# 中的 \u 指示符)所以做出这个假设我得到以下内容:
U+004F => decimal 79 => O (uppercase)
U+006B => decimal 107 => k (lowercase)
负责的公司告诉我邮件是这样发送到他们的服务器的,所以这一定是客户端问题,对吧?我查看了我的 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;
}
}
}
我的问题:
为什么首先会发生这种情况?
有了代码 - 有什么我遗漏的吗?例如。 Framework 中有什么东西已经可以为我处理这个问题了吗?或者说,了解 Unicode 的人可以看到一些明显的缺点吗?有什么我可以做得更好的吗?
一些代码点仍然呈现为颠倒的问题(我自己怀疑这些是表情符号)-我有什么办法可以处理它们吗?
编辑 2018-04-26 给后代的注释
(我本来打算把它放在评论中的,但无论我用它做什么,它看起来都很糟糕)
我查看了已接受答案中的 link,虽然代码比我的更简洁,但最后的输出是相同的——包括倒置的问号(以及我怀疑的字形是表情符号)。关于 Unicode 和 UCS2 之间差异的更多阅读 can be found here and 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 不支持
SMS 消息可以使用多种编码方式进行编码。其中包括 7 位 (GSM-7)、8 位和 16 位 (UCS2)。虽然大多数 SMS 程序以最不浪费的编码对消息进行编码 - 即使所有字符都属于其他编码的范围,使用 16 位编码也没有任何无效。那就是我假设你的情况会发生什么。当然,短信是按字节传输的,而不是 u004f006b
字符串,所以为什么要这样表示取决于您使用的工具\与您合作的第三方。
至于你的解析代码。它假定字符串是 UTF-16(C# 字符串的内部表示),但如果以上内容正确,则编码为 UCS2。它与 UTF-16 非常相似,但又不完全相同。我不太适合讨论差异,但您可以查看 this answer 等示例,了解有关如何使用它的一些线索。这也可能是某些字符解码不正确的原因。
这是更简单的方法:
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();
}
}
}