我正在增强一个实现简单的基于ASCII协议的软件。
协议很简单......这里有一个消息看起来有点像的例子（虽然不一样，我不能告诉你真正的协议）：
AUTH 1 1 200<CR><LF>
我们收到类似于
的回复230 DEVICE 1 STATE AUTH 200 OUTPUT 1 NAME "Photo Black"<CR><LF>
名称“Photo Black”来自数据库sqlite数据库。我需要加强它以支持外语。所以我一直认为“Photo Black”字段需要“可选”地编码为引号之间的UTF-8字符串。我想知道是否有一个标准，以便客户端应用程序可以解释引号中的字符串，并立即将其识别为UTF-8或纯ASCII。我不愿意重写协议，这将是太多的工作。只需滑动某种编码，客户就可以识别一些西班牙语或瑞典语。
我不希望该字段总是被解释为UTF-8，长话故事。您知道在C ++中我可以输入0xFF并且编译器知道这是一个十六进制字符串...是否有等效的UTF-8？对不起，我可能会开枪，但我不熟悉UTF-8编码和国际化。
答案 0 :(得分：2)
阅读Ascii Compatible Encoding或ACE的概念。 iDNS就是一个例子。那是/是UTF-7。
这是master发言。
你真的不能代码切换进出UTF-8。对于一场噩梦，请查看ISO-2022，它试图支持这种事情。另请注意，UTF-8 包括 ASCII，但不包括Latin-1。
答案 1 :(得分：2)
您是否可以控制服务器和客户端？如果没有，则无法更改协议，因此不会能够执行此操作。当你说你“不想重写协议”时 - 你将不得不这样做至少要某些范围。无论你做什么， 都会改变协议。
我不确定为什么你不想总是将数据解释为UTF-8 - 如果它当前只是ASCII，那么它将完全向后兼容以始终将其解释为UTF-8，因为所有ASCII在UTF-8中以相同的方式编码。也许如果您能提供更多信息，我们可以提供更多帮助。
您可以为UTF-8编码的字符串引入前缀，例如U：
230 DEVICE 1 STATE AUTH 200 OUTPUT 1 NAME U"Photo UTF-8 stuff here Black"<CR><LF>
会有帮助吗？
您实际拥有8位数据路径吗？如果某些内容会破坏每个字节的最高位，那么您需要考虑Punycode之类的选项而不是UTF-8。
答案 2 :(得分：1)
为什么不希望该字段“始终被解释为UTF-8”？你不说。
如果您确实让客户端将协议解释为UTF-8编码文本，则所有现有输出仍然可以正常工作，因为UTF-8是ASCII的正确超集。