☰

Versuchen Sie zunächst das Gegenteil:

tag-icon • tag-icon xattr base64
Versuchen Sie zunächst das Gegenteil:

Ich habe ein kurzes Shell-Skript geschrieben, das setfattrdas Setzen des erweiterten Attributs, das einem Freitextkommentar entspricht, einfach in eine etwas praktischere Form umschließt:

#!/bin/sh
test "$2" && setfattr -n user.xdg.comment -v "$2" "$1"
getfattr -d -m '^user.xdg.comment$' "$1"

Zum Speichern von US-ASCII-Kommentaren als xattrs funktioniert das hervorragend. Wenn ich jedoch versuche, einen Kommentar zu setzen, der nicht US-ASCII-Zeichen enthält, erhalte ich scheinbar Base64-codierte Daten:

$ touch xyz
$ set-comment xyz åäöåä
# file: xyz
user.xdg.comment=0sw6XDpMO2w6XDpA==
$

Aber es ist nicht nur Base64:

$ printf "0sw6XDpMO2w6XDpA==" | \base64 --decode
��:\:L;l:\:@base64: invalid input
$

Meistens bekomme ichNurzufällig aussehender Müll zurück. Manchmal gibt mir der Base64-Decoder auf diese Weise „ungültige Eingabe“ zurück.

Was ist das für eine Zeichenfolge?In welcher Beziehung steht es zum ursprünglichen Eingabewert? Wie komme ich von dem, was getfattrmir gibt, zurück zum ursprünglichen Eingabewert (wie åäöåäin diesem Fall)?

setfattr --versionauf meinem System antwortet mit setfattr 2.4.46. Ich verwende die von Debian Wheezy gepackte Version. Für den unwahrscheinlichen Fall, dass es wichtig ist: Ich verwende ZFS On Linux 0.6.3 (habe das gleiche Verhalten auch bei 0.6.2 gesehen) auf dem Standard-Wheezy-Kernel.

Antwort1

Ich bin ein bisschen neugierig geworden, als ich diese Frage gelesen habe. Also lasst uns ein paar„Forensik“:

Versuchen Sie zunächst das Gegenteil:

Wie wird åäöåäin Base64 kodiert?

$ echo åäöåä | base64
w6XDpMO2w6XDpAo=

Das sieht ganz offensichtlich sehr nach dem aus, 0sw6XDpMO2w6XDpA==was Sie haben. 0sAm Anfang steht ein Extra, und das Ende stimmt nicht ganz überein. Wenn wir den Zeilenumbruch am Ende von unterdrücken åäöåä(automatisch eingefügt von echo), erhalten wir:

$ echo -n åäöåä | base64
w6XDpMO2w6XDpA==

Dies ist exakt der user.xdg.comment-Wert, außer dem 0sam Anfang.

Abschluss

Der KommentarIstBase64-codiert und mit dem Präfix versehen 0s. Das Testen einiger anderer Zeichenfolgen bestätigt dies.

Beispiel:

$ ./set-comment xyz 日本語
# file: xyz
user.xdg.comment=0s5pel5pys6Kqe

$ base64 -d <<<'5pel5pys6Kqe' ; echo
日本語

(wobei dies ; echodazu dient, die nächste Eingabeaufforderung nicht durcheinander zu bringen, da die Ausgabe base64nicht mit einer neuen Zeile endet.)

Jedoch...

Dies zeigt nur, dass in diesen Fällen (wenn der Kommentar nicht ASCII-förmig ist) er in Base64 codiert und mit dem Präfix versehen wird 0s.

Die „wahre“ Antwort

Danach kam ich auf die großartige Idee, die Manpage zu überprüfen. getfattrDort steht unter anderem:

Bezüglich der Option-e en, --encoding=en

Kodieren Sie Werte nach dem Abrufen. Gültige Werte von en sind „text“, „hex“ und „base64“. Als Textzeichenfolgen kodierte Werte werden in doppelte Anführungszeichen (") eingeschlossen, während als Hexadezimal- und Base64-Zeichenfolgen 0x bzw. 0s vorangestellt werden.

Ändern Sie also Ihr Skript wie folgt:

(DateiKommentar setzen:)

#!/bin/sh
test "$2" && setfattr -n user.xdg.comment -v "$2" "$1"
getfattr -e text -d -m '^user.xdg.comment$' "$1"

druckt das Attribut immer als Text, beispielsweise:

$ ./set-comment xyz åäöåä   # with fixed script
# file: xyz
user.xdg.comment="åäöåä"

Es gibt jedoch noch einige Einschränkungen, wie zum Beispiel:

$ ./set-comment xyz 0x414243
# file: xyz
user.xdg.comment="ABC"

Und

$ ./set-comment xyz 0s5pel5pys6Kqe
# file: xyz
user.xdg.comment="日本語"

bei denen die Ausgabe nicht mit der Eingabe übereinstimmt.

Diese Probleme können behoben werden, indem das Argument in eine Form gebracht wird, die setfattrgefällt. Siehe man setfattr.

verwandte Informationen