No comando grep, posso alterar [: digit:] para [0-9]?

7

O grep [0-9] funcionará da mesma forma que grep [:digit:] ?

    
por D.Mar 13.04.2016 / 19:19

4 respostas

14

Não, [0-9] é não igual a [:digit:] .

[0-9] corresponde aos numerais de 0 a 9.

[:digit:] corresponde de 0 a 9 e numerais em idiomas não ocidentais (por exemplo, árabe oriental).

    
por 13.04.2016 / 19:37
3

Para ser preciso, [0-9] só é garantido como equivalente a [:digit:] if:

  • o analisador regexp suporta [:digit:] (ou seja, se não, então o [:digit:] existente provavelmente não faz o que você acha que faz), e:

  • o conjunto de caracteres de entrada é um tal como ASCII, em que os únicos dígitos são os caracteres 0 - 9 e são adjacentes. Isso pode não ser verdade em (por exemplo) unicode (onde os dígitos podem incluir caracteres diferentes dos dígitos 0 - 9 ), ou mesmo em outros conjuntos de caracteres de 8 bits em que 0 - 9 pode não ser adjacente (como acontece em EBCDIC os dígitos 0 - 9 são adjacentes).

Exemplos de exceções unicode são mostrados aqui . Como você pode ver, o conjunto de caracteres unicode na categoria 'Número, Dígito, Decimal' inclui um pouco mais que os 10 dígitos ASCII correspondidos por [0-9] ; inclui árabe indic, extended arabic, ngo, etc.

Mais informações sobre numerais em unicode podem ser encontradas aqui .

    
por 13.04.2016 / 20:42
2

Você pode alterar [[:digit:]] para [0-9] - nota [:digit:] está dentro de […] . Isso depende da codificação da entrada. Se for ASCII, não acho que haverá um problema. Com outras codificações, os dígitos podem não ser contíguos ou o intervalo de bytes pode ser diferente. Você também pode perder números especiais em outros sistemas de escrita.

    
por 13.04.2016 / 19:40
1

'[: digit:]' é teoricamente mais portátil, com a vantagem de não depender do conjunto de caracteres locais agrupando dígitos juntos.

Exemplo relacionado: Com '[: upper:]' vs '[AZ]' não há diferença em ASCII, mas é uma diferença em uma IBM antiga EBCDIC , onde '[AZ]' teria 41 caracteres e não 26 (códigos EBCDIC 193-233) e, portanto, corresponderia a EBCDIC "} \" et al .

    
por 13.04.2016 / 19:40

Tags