记上报信息格式异常问题的解决

本文记述解决上报信息格式异常问题的全过程。

问题描述

生产环境监控上报无法解析终端信息，通过日志发现是PCN字段前面缺失#号，导致解析程序解析失败。正常情况下，应该展示如下内容：

HD_1234#PCN1234

发生错误情况时，记录如下

HD_123?PCN1234

问题分析以及解决

通过进一步的后台日志数据分析，发现上述异常情况发生在特定终端，这说明是因为某些终端存在特殊情况，程序中没有考虑到这类特殊情况，从而导致的问题。HD字段后面跟着的是硬盘序列号，PCN字段后面是主机名称，他们中间用 # 字符连接。

下一步是复现问题，复现思路为在本地尝试构造特殊数据，并在复现这类情况，具体做法是在HD~123的后面手动追加异常数据，再和后面正常的 #PCN~1234进行拼接，用程序来检测拼接后是否出现?字符。

由于不知道什么数据会触发，怀疑是混入了无效中文导致的，于是，复习了下中文编码的知识后，

中文编码

ASCII --》 GB2312 			--》GBK          --》GB18030体系(字符集+编码格式统一)
           1980年发布          1995年发布          2000年发布 GB18030-2000  2005年发布 GB18030-2005
		   6763个汉字和符号     2万多个字符          7万多字符
		   定长2字节		    汉字2字节           变长多字节字符集(1\2\4字节组成)
							   英文1字节		   大部分中文字符只需要2个字节
											      单字节ASCII

ASCII -->										Unicode编码体系(规定字符集)
												编码的存储和解析有 UTF8、UTF16等标准。
												通过UTF8编码的中文，需要3个字节
		   
如果一个字节最高位是0，说明该字节为ASCII码，查表解析即可，否则认为是多字节编码，需要联合下一个字节一起解析。
utf8编码与ASCII完全兼容，最高位1的数量表示当前字符占用的字节数。

对于汉字来说，没有半角全角的区分；对于符号来说，ASCII和GB2312的符号编码不同，表现不同，GB2312编码的为全角，ASCII编码的为半角。

对于ASCII来说，它是7位编码，共128个字符，分为95个可打印字符和33个不可打印字符，可打印字符用于显示在输出设备，如屏幕或打印纸；不可打印字符又称为控制字符，编码范围在 0x00~0x1F 之间，用于向计算机发出控制指令。

找了几个特例汉字,
GB2312没有，GBK没有，GB18030中独有的字：㙍 0x8230AB33
GB2312没有，GBK有的字： 掆 0x92E2  昞 0x955C 鐯 0xE840 淂 0x9BFA

输入GB2312没有，GBK有的字，能够正常展示；
输入GB2312没有，GBK没有，GB18030中独有的字，显示为 HD~??#PCN，无法显示，但后面的#号没丢。

输入中文的尝试不行，干脆从0~255都试一遍，从1个字节，到2个字节，再到3个字节，都循环一把。这个流程的关键在于如何检测到异常。

判断异常有两个方向，一个是判断是否出现？，另一个是判断是否缺少#。

判断是否出现?, 尝试用 Find 函数查找，几轮全部循环完了都找不到，奇了怪了。

判断是否缺少#，用这个方法可以找到，问题是有太多字符组合发生这种情况了，太多的报错信息反倒是让我怀疑是这个思路不对。在随后的分析中，找一两个错误字符组合一试，果然会出现异常情况，随后多次测试，直到确定发生异常的最佳情况，下面以简化程序为例子来说明：

// 尝试处理无效字符串连接时的问题
void test_invalid_character_string_strcat()
{
	char sz2[32] = "123";

	const int nBufSize = 256;
	char szBuf[nBufSize] = { 0 };

	char sz1[32] = { 0x31, 0x13 };	// 测试各种不可打印字符包含在最后时，对后面格式化内容的影响
	//char sz1[32] = { 0x31, 0x01, 0x31 };	// 测试各种不可打印字符包含在中间时，对后面格式化内容的影响
#if 1
	for (char i = 0;i < 0x1F; i++)
	{
		sz1[1] = i;
		sz1[2] = 0;
		memset(szBuf, 0, nBufSize);
		_snprintf_s(szBuf, nBufSize, nBufSize - 1, "sz1:%s#sz2:%s", sz1, sz2);

		printf("0x%x:%c szBuf:(%s) \t", i, i, szBuf);
		if (i % 2 == 1)
		{
			printf("\n");
			fflush(nullptr);
		}
	}
	printf("\n");
#endif
	//char sz1[32] = { 0x30, 0x92 };	    // 无效字符包含在最后，会吞掉后面的1个符号
	//char sz1[32] = { 0x30, 0x91, 0x30 };	// 无效字符包含在中间，不会吞掉后面的1个符号
	
	//char sz1[32] = { 0x30, 0x01 };	    // 不可打印字符包含在最后，有些字符会会吞掉后面1个字符内容
	//char sz1[32] = { 0x30, 0x06 ,0x30};	// 不可打印字符包含在中间，
	
	_snprintf_s(szBuf, nBufSize, nBufSize - 1, "sz1:%s#sz2:%s", sz1, sz2);
	cout << "szBuf:" << szBuf << endl;

	string strTest(szBuf);
	int nIdx = strTest.find('?');
	//assert(nIdx == -1);		// 当格式化异常时，界面上展示的是?，但内存中是对应的0x91解决了当异常出现时，无法用 find 来定位

	int nFind = '?';
	char* pRet = strchr(szBuf, nFind);
	//assert(pRet == nullptr);
	
	getchar();
	exit(0);
}

经过上述代码实测，得出以下结论：

当待连接字符串中包含无效字符或不可打印字符时，在格式化时会影响后面的内容，具体表现为:

当出现不可打印字符时，详细影响情况见下图：

当不可见字符为0x0，0x7,0x8,0x9,0xa等字符时，后面的内容不会被影响，为其他不可打印字符时，在显示时，会吃掉后面的1个字符。
比如 0x11 0x35， 会显示为左三角; 当为 0x11 0x35 0x35， 会显示为左三角5;这说明不可见字符在显示时会隐藏掉后一个字符。

当出现无效字符（字符数值大于127的）时，无效字符在字符串中间，不会影响后续格式化；在字符串最后时，会吞掉后面的一个字符,自身显示为？。

小结

定位到问题原因，解决方案也就出来了。检测待格式化字符串，如果发现最后1位为无效字符，则在它后面追加一个有效字符，可确保不会影响后续格式化内容。