Just curious: working on a Intel hex record file parser w/ an ASCII conversion. My compiler generates its Intel hex records with capitalized letters for hex fields. Do some compilers generate their records w/ lowercase hex values?
:10001000C4BC5F563E678745456679D421234556F8
vs.
:10001000c4bc5f563e678745456679d421234556f8
The standard only uses capitalized letters, but since it doesn't seem to specifically prohibit lowercasae, I'm guessing some compilers might.
If you're working on Linux or some Unix system, you can always make the transformation yourself using a tool like tr. For example, see sed one-liner to convert all uppercase to lowercase?
If you're on Windows, you can find a working tr in msys (you may even have it already if you're using TortoiseGit, for example).
Related
In 2001 German scene group Farbrausch released a demo called "fuenf" (in your face). pouet.net It contains a 5 Byte executable which could be rather considered a troll approach than a demo. If you run it your hear a weird sound and it could crash your computer. At least it produces a sound. Whatever.
The hexadecimal content is:
95cd 21eb fc
And the binary representation is:
10010101 11001101 00100001 11101011 11111100
Using xxd I also get the printable chars from the content, which are:
..!..
And that makes me a little confused. Looking up the values in the ASCII table (e.g. here), I get this as a result:
•Í!ëü
At least the exclamation mark is correct.
But how does 95cd21ebfc translate into ..!..?
Side note:
file -bi fuenf.com sais the encoding is not known:
charset=unknown-8bit
And iconv -f ISO-8859-1 -t UTF-8 fuenf.com returns
Í!ëü
Which leads to the assumption, that XXD simply cannot decode the content and therefore just uses default results, like the dot?
First of all, this is not a text file, so looking at it as one makes no sense. It's instructions.
Secondly, even if it could be interpreted as text, you would need to know the encoding. It's definitely not ASCII, because that only defines symbols in the range 0-127 (and the 3rd byte here is the only one in that range, which maps to '!'). The "extended ASCII" table you link to is only one of many possible code pages that give meaning to the value from 128-255, but there are many of those code pages. Calling it "extended ASCII" is misleading, because it suggests that ASCII created an updated standard for this, which they did not. For a while, computer vendors just did whatever they wanted with those additional characters, and some of them became quasi-standards by virtue of being included in DOS, Windows, etc. Or they got standardized by ISO (you tried iso-8859-1, which is one such standard).
I tried to use online tools, like google/qr_codes and
goQR.me, but neither have an "alphanumeric characters" option, only complete binary (UTF8 or ISO) character set. I need only a little alphanumeric (A-Z,0-9,-,/,etc.), so a string like "http://bit.ly/1234" (a string with length=18) can be expressed by a Version-1 (21 rows) QR-Code symbol.
I also try to install (Linux, PHP, Python, etc.) tools... And, to my surprise, no "alphanumeric" option! (only, indirectly, the "binary" option).
Examples:
Good: https://chart.googleapis.com/chart?chs=250x250&cht=qr&chl=http://bit.ly/12&chld=L|1 Generates a symbol of "http://bit.ly/12" (a string with length=16) with a version-1 QR-Code. OK! The guide say "... can encode up to 25 alphanumeric characters", so 16<25, then espected to version-1.
1.1 Bad: https://chart.googleapis.com/chart?chs=250x250&cht=qr&chl=http://bit.ly/12&chld=M|1 (change L to M), generates a version-2 (25 rows) symbol.
1.2 Bad: https://chart.googleapis.com/chart?chs=250x250&cht=qr&chl=http://bit.ly/1234&chld=L|1 (change length from 16 to 18), generates a version-2 (25 rows) symbol.
Trying to programm it... bad... See http://phpqrcode.sourceforge.net/ , even when I programming, I can't select a real "alphanumeric" option! No Version-1 symbol can be generated (!) with this kind of tools.
The QR alphanumeric set does not include lowercase letters. The standard's definitive but the the wikipedia page lists the characters in the alphanumeric set.
May the encryption string provided by PBEWithMD5AndDES and then Base64 encoded contain the CR and or LF characters?
Base64 is only printable characters. However when it's used as a MIME type for email it's split into lines which are separated by CR-LF.
PBEWithMD5AndDES returns binary data. PBE encryption is defined within the PKCS#5 standard, and this standard does not have a dedicated base 64 encoding scheme. So the question becomes for which system you need to Base 64 encode the binary data. Wikipedia has a nice section within the Base 64 article that explains the various forms.
You may encounter a PBE implementation that returns a Base 64, and the implementation does not mention which of the above schemes is used. In that case you need to somehow figure out which scheme is used. I would suggest searching for it, asking the community, looking at the source or if all fails, creating a set of tests on the output.
Fortunately you are pretty safe if you are decoding base 64 and you are ignoring all the white space. Note that some implementations are disregarding padding, so add it before decoding, if applicable.
If you perform the encoding base 64 yourself, I would strongly suggest to not output any whitespace, use only the default alphabet (with '+' and '/' signs) and always perform padding when required. After that you can always split the result and replace any non-standard character (especially the '+' and '/' signs of course), or remove the padding.
I was using java with Andorid SDK. I found that the command:
String s = Base64.encodeToString(enc, Base64.DEFAULT);
did line wrapping. It put LF chars into the output string.
I found that:
String s = Base64.encodeToString(enc, Base64.NO_WRAP);
did not put the LF characters into the output string.
When I am trying to paste the character » (right double angle quotes) in Unix from my Notepad, it's converting to /273. The corresponding Hex value is BB and the Decimal value is 187.
My actual requirement is to have this character as the file delimiter when I export a .dat file from a database table. So, this character was put in as the delimiter after each column name. But, while copy-pasting, it's getting converted to /273.
Any idea about how to fix this? I am on Solaris (SunOS 5.10).
Thanks,
Visakh
ASCII only defines the character codes up to 127 (0x7F) - everything after that is another encoding, such as ISO-8859-1 or UTF-8. Make sure your locale is set to the encoding you are trying to use - the locale command will report your current locale settings, the locale(5) and environ(5) man pages cover how to set them. A much more in-depth introduction to the whole character encoding concept can be found in Joel Spolsky's The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
The character code 0xBB is shown as » in the IS0-8859-1 character chart, so that's probably the character set you want, so the locale would be something like en_US.ISO8859-1 for that character set with US/English messages/date formats/currency settings/etc.
Is there any special character that cannot be a part of the path in Windows or Unix that I can use it as a separator?
what about the delimiter for PATH environment variable? ; for windows, and : for Linux.
Wikipedia helpfully lists the reserved characters for different filesystems. Neither NTFS nor POSIX will accept the null or slash (/) characters in filenames. The slash character is obviously not a good separator, since it's common in POSIX paths, so maybe you could use null.
Of course null isn't suited to all situations (e.g. it isn't usually visible when printed), in which case you might have to use some sort of escaping scheme.
Java, which aims to work across different platforms, doesn't even try to find a common path separator. Instead each platform has its own character, accessible through an API.
Path separator are platform dependent :
For windows, it’s \ and for unix it’s /.
Technically, Unix does allow any character in a folder/filename, except / of course, which would be interpreted as as part of the path.
Windows does only support printable characters and some special characters excluding \ / : * ? " < > |.
In java you can use:
WindowsNTFileSystem
s.split(File.pathSeparator) for windows it will give ; (semicolon)
s.split(File.separator) for windows it will give \ (backward)
Linux
s.split(File.pathSeparator) for windows it will give : (colon)
s.split(File.separator) for windows it will give / (forward)
I would be careful with custom separators because they might break in the future, e.g. if someone uses unicode and your custom separator is part of another character.