A: To get the attribute set, you should follow obsigna's advice, it is easier that way. Although your way should in theory work, you are relying on the shell not screwing up the content of a binary file that is being used on the command line; any mistake with quoting, and the attribute value is toast
B: To get the attribute, you should use the "-q" option on getextattr. Like that, it reports just the attribute value on stdout. However, getextattr will add a newline at the end of the attribute value when it prints it, so what you retrieve will be 1 byte longer. In theory, you could get around that. You could for example assume that there will always be a newline at the end of getextattr, and strip it off. But that is unreliable, since you are relying on an undocumented and not standardized behavior (remember, EAs are not Posix). If you really care to store binary data in an EA, you should properly encode it in a format that survives i18n and extra newlines, such as uuencode.
The real answer is this: why the heck are you doing this? Extended attributes are not intended to be used for (a) large data, and (b) binary data. Many operating systems and file systems have relatively small size limits for EAs, 4K is typical (often minus some rounding error to make it fit into a file system block or inode). Also, it has never been clear whether the name and content of EAs are unicode or or binary, so don't be surprised if a process running in a different locale gets different data back (which would play havoc with binary data). The safe and sane use of EAs is to use short names for them (length comparable to file names), and make the data be short and 7-bit ASCII strings, or at best UTF-8 encoded.
Extended attributes are really a disaster area of incompatibility, and their implementation in file systems can be very spotty. I was actually on the fringe of the first effort of standardizing extended attributes (as part of NFSv4 in the IETF, in the late 90s. When the first standards draft was written, it was so ambiguous that people could interpret it any way they wanted. For example, early on EAs could be text strings or file names (meaning you could have a file inside a file). Unfortunately, the standard allowed to add directory names to EAs, creating a whole parallel directory structure: An object that was a file on the outside could contain multiple directories on the inside. Which immediately led to intellectual puzzles: What if you add a real file (not an EA) to a directory that is an EA on another file? What if the file that contains the EA directory is deleted, do all the files in its EA subdirectory vanish, or how are they accessed? Since that experience, I have tried to stay away from EAs as much as possible.
