我编写了一个预约安排系统,它(除其他外)在预约到期前一天发送提醒短信。它要求用户通过对文本回复“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;
}
}
}
我的问题:
为什么会发生这种情况?
使用代码 - 我在这里有什么遗漏吗?例如,框架中是否有一些东西已经可以为我处理这个问题,或者是否有一些对 Unicode 了如指掌的人可以看到的明显缺点?有什么我可以做得更好的吗?
一些代码点仍然呈现为颠倒的问题(我怀疑这些是表情符号) - 有什么办法可以处理它们吗?
编辑 2018-04-26 给后代的说明
(我打算把它放在评论中,但不管我用它做什么,它看起来都很糟糕)
我查看了已接受答案中的链接,虽然代码比我的更简洁,但最后的输出是相同的——包括倒置的问号(以及我怀疑的字形是表情符号)。更多关于 Unicode 和 UCS2 之间差异的阅读可以在这里找到,维基百科的文章也值得一读:
TL;博士
- UCS-2 已过时并已被 UTF-16 取代 UCS-2 是固定宽度编码方案,而 UTF-16 是可变宽度编码方案
- 支持 UTF-16 的应用程序可以读取 UCS-2 文件,但反之则不行
- UTF-16 支持从右到左的脚本,而 UCS-2 不支持
- UTF-16 支持规范化,而 UCS-2 不支持