CUT : Caractère paragraphe (§) n'est pas accepté comme délimiteur Le sujet est résolu

Tout ce qui concerne la programmation.
Répondre
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3546
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

Bonjour,

J'aimerais bien comprendre pourquoi le caractère Paragraphe_(symbole) tapé sur mon clavier [Maj+!] n'est pas reconnu comme 1 unique caractère délimiteur par cut ?

Je n'ai trouvé nulle-part mention que ce soit un caractère spécial pour bash.


Je soupçonne / crains que d'autres caractères que j'ignorent, produisent cette mauvaise farce.


Car rien n'y fait avec : §

Ici un échantillon... j'ai tenté d'avantage de syntaxes sans plus de succès :012:

Code : Tout sélectionner

cut --delimiter="§" -f 1 test.txt
cut: le délimiteur doit être un seul caractère
Saisissez « cut --help » pour plus d'informations.


cut --delimiter=§ -f 1 test.txt
cut: le délimiteur doit être un seul caractère
Saisissez « cut --help » pour plus d'informations.


cut -d \§ -f 1 test.txt
cut: le délimiteur doit être un seul caractère
Saisissez « cut --help » pour plus d'informations.


cut -d§ -f 1 test.txt
cut: le délimiteur doit être un seul caractère
Saisissez « cut --help » pour plus d'informations.


cut -d "§" -f 1 test.txt
cut: le délimiteur doit être un seul caractère
Saisissez « cut --help » pour plus d'informations.


cut -d '§' -f 1 test.txt
cut: le délimiteur doit être un seul caractère
Saisissez « cut --help » pour plus d'informations.



Si vous avez une idée ....
Merci
**Simple Utilisateur** -- Debian stable - XFCE
Avatar de l’utilisateur
vv222
Membre actif
Membre actif
Messages : 852
Inscription : 18 avr. 2016, 20:14
Contact :
Status : Hors-ligne

C’est un piège de unicode et de la manière dont il encode certains caractères. Tu ne peux tout simplement pas utiliser "§" comme séparateur avec cut.

Mais tu peux contourner ça en t’aidant de sed par exemple :

Code : Tout sélectionner

$ echo 'lorem§ipsum§dolor§sit§amet' | \
    sed 's/§/@/g' | cut --delimiter='@' --fields=2,3 | sed 's/@/§/g'
ipsum§dolor
Il faut bien sûr utiliser un caractère de remplacement qui ne soit pas présent dans le texte d’origine, "@" ne sera pas forcément adapté dans ton cas.
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3546
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

Merci, sais-tu si une liste de ces caractères "piégeurs" est publiée quelque-part ?
**Simple Utilisateur** -- Debian stable - XFCE
Avatar de l’utilisateur
vv222
Membre actif
Membre actif
Messages : 852
Inscription : 18 avr. 2016, 20:14
Contact :
Status : Hors-ligne

Aucune idée. Il faudrait que tu trouves la liste des caractères unicode qui ne sont pas codés sur un octet unique.
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3546
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

vv222 a écrit : 16 oct. 2023, 23:27 caractères unicode qui ne sont pas codés sur un octet unique.

Merci, c'est déjà une bonne piste.
**Simple Utilisateur** -- Debian stable - XFCE
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3546
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

Tous les caractères au delà de U+007F sont codés sur plus de 1 octet (byte)

ça correspond bien avec :

@ : U+0040
§ : U+00A7



Source :
Why does UTF-8 use more than one byte to represent some characters? | Stackoverflow
UTF-8 uses the 2 high bits (bit 6 and bit 7) to indicate if there are any more bytes: Only the low 6 bits are used for the actual character data.
That means that any character over ''7F'' requires (at least) 2 bytes.
Ç signifie que tot caractère au dessus de 7F nécessite (aumoins) 2 octets.

Pour une liste, je verrai ça plus tard.... si j'y repense
**Simple Utilisateur** -- Debian stable - XFCE
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3546
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

Pour la liste, en 1ère approximation (non-vérifié > incomplète)
on peut déjà tabler sur : Unicode > Basic Latin

Pour en finir : 1 octet = 8 bit (0/1) ce qui donne 2^8 = 256 possibilités de valeur
pour une raison que je n'ai pas recherchée le jeu de caractère ASCII est codé sur 7 bits
(1 bit libre pour autre chose ...) => 2^7= 128 = 0080 (base 16)

Donc 128 est le maxi sur 7bits (0-127) ce qui correspond aux caractères de ce tableau :
ascii-table.png
source > Wikipedia

Voilà, ça laisse le centre du tableau comme choix possibles (94) pour le délimiteur de cut
Vous ne pouvez pas consulter les pièces jointes insérées à ce message.
**Simple Utilisateur** -- Debian stable - XFCE
Avatar de l’utilisateur
piratebab
Site Admin
Site Admin
Messages : 4960
Inscription : 24 avr. 2016, 18:41
Localisation : sud ouest
Status : En ligne

Il y a le dollar, mais pas l'euro.
Comme par hasard ....
Encore un sale coup du complot mondialiste qui veux monétiser internet
:banana_ninja:
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3546
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

Et pas de rouble ... c'est trouble !
Image
€ ?.... je te laisse deviner où il incubait quand ce tableau fût... :194:
:crazy:
**Simple Utilisateur** -- Debian stable - XFCE
Répondre