我一直在研究一些允许通过telnet登录的设备，我从设备中提取了一些数据并做了一些报告，没有任何问题。最近，我不得不切换到SSH，而其余的脚本都是一样的，只有登录程序已经从telnet更改为SSH。在切换到SSH之后，我面临一些问题，提取的数据在某些行中有一些无效字符，下面是一个例子：可以看出，在行中的PON7后面有一个无效字符：
OLT:LT6.PON7.ONT1,ALARM,Date time,
问题是这个无效字符在bash / csv文件中甚至不可见，但是当我在notepad ++中复制该行或在此处发布它时发现了它。
现在我有两个问题： 1st：如果有人知道在telnet / ssh之间切换时导致这些无效字符的原因。 第二：如何在BASH中处理这个无效字符，因为它在BASH中甚至不可见，但是这个报告正在某处使用，这些无效字符会导致问题。
编辑：
将文本粘贴到text-to-hex converter会产生这个：
4f 4c 54 3a 4c 54 36 2e 50 4f 4e 37 11 2e 4f 4e 54 31 2c 41 4c 41 52 4d 2c 44 61 74 65 20 74 69 6d 65 2c
看起来“7”和“。”之间有一个DC1字符（十六进制11）。
不幸的是，此编辑还具有从示例文本中删除字符的副作用。
答案 0 :(得分：1)
通过text to hexadecimal converter传递文本表明隐形字符为ASCII DC1 character（十六进制11，八进制021）。此字符也称为Ctrl-Q或XON。它有时用于流量控制。
在bash脚本中，您可以使用tr程序对其进行过滤：
echo $badtext | tr -d '\021'
SSH本身并不会将DC1字符插入文本流中。如果您在设备的输出中获得DC1字符，则可能是设备发送了该字符。