Because I am setting up vnc server, I need to convert string to base64 to setup password. (How to setup vnc password
Say, if I want my password to be qwerty, I have to place the encoded string into the password into conf file.
I see there is a base64 utility in Ubuntu. man base64. echo qwerty | base64 gives cXdlcnR5Cg==. But this doesn't work.
But if I use the online base 64 tool. qwerty is encoded to cXdlcnR5. This string WILL WORK.
Question: why the two base64 encode gives different result?
echo adds a '\n' ; try echo -n
$ echo -n qwerty | base64
cXdlcnR5
Related
I am looking for a command in Linux/Ubuntu for generating random content of any size into an empty file.
After the latter, I should use the same command to add new random text to another empty file.
I am run out ideas, Do anyone knows what command would be??
base64 /dev/urandom | head -c 500 > file.txt
This command will write 500 random characters into file.txt.
Keep in mind that it will generate only letters, numbers, '+' and '/' characters.
In Linux I created a plain text file. using "file -i" I am seeing file encoding is "us-ascii" . After trying below commands it is still showing output file encoding as "us-ascii". Could you please tell me how to change encoding? or Is there any way to download some encoded file which I can't read.
iconv -f US-ASCII -t ISO88592//TRANSLIT -o o.txt ip.txt
iconv -f UTF-8 -t ISO-8859-1//TRANSLIT -o op.txt ip.txt
I am expecting either iconv change the encoding or I can download some encoded file.
If your file contains only ASCII character, then there's no difference between the ASCII, UTF-8 and different ISO8859-x encoding. So after conversion, you will end up with the exactly same file.
A text file does not store any information about what encoding was used. Therefore, the file applies a few rules but at the end of the day, it's just a guess. And as the files are identical, the result will alwazys be the same.
To see a difference, you will must use characters that are encoded differently with the different encoding or are not avaialbe at all in one of the encodings, e.g. ă, € or 😊.
I'm using Mac OS 10.13.3. I'm trying to base64 encode a binary file but am having some issues. Specifically, I thought all base64 encoded files have to have a length that is a multiple of 4. However, when I encode my file, notice taht the length is not divisible by 4 ...
localhost:lib davea$ openssl base64 -in myfile.binary -out ~/Downloads/myfile.base64
localhost:lib davea$ ls -al ~/Downloads/myfile.base64
-rw-r--r-- 1 davea staff 93162 May 31 14:22 /Users/davea/Downloads/myfile.base64
Also when I look at the contents of the base64 file, I don't see the traditional "=" or "==" at the end, which usually indicates padding
localhost:lib davea$ cat ~/Downloads/myfile.base64
...
C9vgMjoKSQYkXMLTrGKRleR558g3bY3VTqlsVvTqZXquCLp4JS4cprTG6N10H0u9
i4pwPrVmSAP2DmE1V7mGwR2e4fiYEWnZjpSbHofpzlUo34yhiQ2/5kJoQZktD7BU
uxYBAgQIECBAgBs2
Am I doing something wrong, or is there another way to base64 encode my file?
OK. I believe we were over thinking this quite a bit. Here is what you are looking for to get the desired behavior:
openssl base64 -A -in myfile.binary -out ~/Downloads/myfile.base64
This will convert to base64 without any line endings. The -A option is what does the trick.
Am I doing something wrong,
No
or is there another way to base64 encode my file?
Yes, you can use base64. It takes a parameter to specify line length but is otherwise similar, the equivalent to your command is:
base64 -b 64 -i myfile.binary -o ~/Downloads/myfile.base64
Also when I look at the contents of the base64 file, I don't see the traditional "=" or "==" at the end, which usually indicates padding
Base64 maps 3 input bytes to 4 output bytes. Your file is 93162 bytes which is divisible by 3, so no padding required.
HTH
I used following command on terminal
`echo admin:admin | base64`
It gives me following output
YWRtaW46YWRtaW4K
But when I used https://www.base64encode.org/ for the same string admin:admin it gives me following
YWRtaW46YWRtaW4=
Any reason for this?
The reason this behaviour is the new line added by the echo command. Normally the echo command add a new line at the end which leads to a different encoding. Therefore if you use it with echo -n admin:admin | base64 the difference won't occur.
About character set I always have question.
Local (Mac OS)
bash-3.2$ 你好
bash: 你好: command not found
bash-3.2$ locale
LANG="en_US.UTF-8"
Linux Server (ssh)
root#hg:~# 你好
-bash: $'\344\275\240\345\245\275': command not found
root#hg:~# locale
LANG=en_US.utf8
Question 1
Why both are utf8, in Server 你好 changed to \344\275\240\345\245\275 but literal 你好?
Question 2
Dose \344\275\240\345\245\275 represents utf-8 encode of 你好? Should it be \xE4\xBD\xA0\xE5\xA5\xBD? Are there different utf-8?
Why both are utf8, in Server 你好 changed to \344\275\240\345\245\275 but literal 你好?
The display comes from your shell. Locally you're using zsh which just copies your input in the error message.
Remotely, you're using bash which tries to make sure the message is displayed even if you're missing the right fonts, so it converts each byte to octal representation.
Does \344\275\240\345\245\275 represents utf-8 encode of 你好? Should it be \xE4\xBD\xA0\xE5\xA5\xBD? Are there different utf-8?
The first is octal representation. Octal 344 is hex e4. All bytes match, it's just a different display format.