cat -e
processando-os como M-^G
sugere que eles são 0x87 bytes (0207 em octal). Como sua documentação 1 diz, vim
renderiza o byte 0x87 como ~G
quando em locales usando conjuntos de caracteres de byte único ou quando o encoding
é Unicode e o caractere ESA é codificado como um UTF válido 8 seqüência multibyte, e processa o byte como <87>
quando a opção encoding
é Unicode e o caractere não faz parte de uma sequência UTF-8 válida. (Renderiza ^G
para 0x7, o caractere ASCII BEL.)
Isso é G
(0x47 em ASCII) com o bit 7 (meta) definido como 1 e o bit 6 definido como 0 (controle). Esse byte não forma um caractere válido em UTF-8 e normalmente é o código de um caractere de controle ( ESA
) no conjunto C1 em conjuntos de caracteres ISO8859-x.
Para se livrar disso, você pode fazer:
tr -d '7' < file > file.new
Com o GNU sed
e um shell como o ksh93 / zsh / bash com suporte para $'...'
:
sed -i $'s/7//g' file
Seu
sed 's/[^ -~]//g'
teria feito isso, mas apenas na localidade C. O intervalo de caracteres em outras localidades é bastante aleatório. Então:
LC_ALL=C sed 's/[^ -~]//g' < file > file.new
(note que ele excluiria todos os outros caracteres de controle, incluindo tabulação e caracteres CR (mas não LF) e não-ASCII).
0x87 é ‡ no conjunto de caracteres do windows-1252 (às vezes indevidamente atribuído como latin1 ou iso8859-1).
Se você quisesse que o 0x87 fosse convertido para ‡ (porque, por exemplo, esses arquivos vêm do mundo do Windows e é isso que esses 0x87 pretendiam ser) no charset da sua localidade (supondo que ele tenha tal caractere), você poderia usar :
iconv -f windows-1252 < file > file.new
1 Bram Moolenaar (2011-03-22). 'isprint' . "opções". Manual de referência do VIM .