okay so i have a program i am writing , and basically i am going to be taking input for keyboard keys such as left arrow, right arrow, up and down etc and my question is , in what is the best option to scan in these keys so that i can make my program run both in linux and windows
and what am i scanning exactly? am i supposed to scan the ascii values and store them in int? chars? or is it another way to do this ? i have searched the internet and i am finding that the kex values for keyboard scan codes are e0 4b e0 4d e0 48 e0 50
but when i actually scan the values using getchar() and store them into ints i get 4 values for each key pressed namely for example 27 91 67 10 , 27 91 68 10
i understand that each key has press release and other values attached to it , so should i be scanning for the 67 68 etc range?
or is there another way to do this
i am writing the program using c language
In Linux, it seems like you're seeing ANSI escape sequences. They are used by text terminals, and start with the Escape character, which is '\x1b' (decimal 27).
This is probably not what you want, if you want to make something keyboard-controllable in direct, game-like manner you need to use "raw" input. There's plenty of references for that, look at ncurses for instance.
Open a terminal and use the command xev. You can then press any key you want and see its corresponding codes. You can also move and click the mouse to see what happens there.
Related
The character I'm first looking for is usually 201 in normal ascii code, but its different for mac. How do i work around this?
It's possible to input the Unicode characters on a Mac by switching to the Unicode Hex Input keyboard layout.
Open system preferences
Choose keyboard
Add Unicode Hex Input to the list
Select "Show Input menu in menu bar"
Close the preferences
Click on the flag that's appeared in the menu bar
Select Unicode Hex Input
Then you need the codes and you can find a nice summary of the box codes here at Wikipedia.
To enter a code:
Hold down Option (alt)
Type the code, without the preceding U, i.e for U+2560, type 2560
Release Option
I drew this example using that method: ╠╩╬╩╣
After you're finished, you can change your keyboard input back to your normal one using the flag in the menu bar.
This character in not available in any single byte character set on OS X.
Unlike the Windows environment (which require special coding to use Unicode), Unicode is readily available in OS X.
Use Unicode U+2554 or UTF-8 E2 95 94
You can just use the following in a character or string ╔
There is no such thing as ASCII character 201. ASCII is a 7-bit single byte character encoding, where code points go from 0 to 127, inclusive. Maybe you are referring to “╔” in the original IBM PC character set?
Then you can do this:
Use a Windows PC with a keyboard that has a numeric keypad.
In a console window with input (e.g. the command interpreter), hold down Alt and type 201 on the numeric keypad, in number mode (NumLock on).
Start Word or Windows’ WordPad.
Copy and paste the character into Word or WordPad.
Type Alt+X.
On my laptop WordPad reports 2554, which means it's Unicode character U+2554 (hexadecimal).
In C++ you can express that character as L'\u2554', which is of type wchar_t.
On the other hand, if you prefer names to numbers, ncurses has supported double- and thick-line drawing characters in Unicode terminals since late 2009. That is after the (rather old) ncurses 5.7 bundled with OSX, but newer releases are available with MacPorts, etc.
Here are a couple of screenshots to illustrate:
I am reading a hexadecimal file and I am looking for a specific set of hexadecimals and once I find that specific set, start storing the information.
The set I am trying to find is "AA 44 12 1C 1F 01". This set is a desired message identifier and in the file there are other messages that I dont want. I would like to find this set, and I know the information I want is 74 more characters long, then repeat the search and read process.
I know there is a built in std::fstream.peek(), but can I use it similar to std::string.find_first_of(" ")?
For one value I am getting two different values when I am casting nvarchar to binary.
For the value A12875 I am getting a result like 0x4131323837350000000000000000000000000000
I get this when I am using a select statement.
If the same statement is executed in a stored procedure I am getting a result like this
0x2000410031003200380000000000000000000000
I am using the same query
select cast('A12875' as binary(20))
What is the difference?`
The difference is character encoding. A character encoding is a way to represent characters as bytes.
The characters you have, and their unicode code points are
A code point 41
1 code point 31
2 code point 32
8 code point 38
7 code point 37
5 code point 35
If you use UTF-8 (or Latin-1 or even ASCII) to encode this string you will get, left padded in a field of 20 bytes:
41 31 32 38 37 35 00 00 ... 00
But there are other character encodings. It looks like when you run a stored procedure, it is choosing UTF-16LE as the encoding, and that somehow a space character ends up in front. In UTF-16LE the code point 41 is represented as
41 00
because it would normally be 0041 but the bytes are reversed. So you would expect:
41 00 31 00 32 00 38 00 37 00 35 00 ... 00 00
The space character is code point 20 so it is represented as 20 00. I don't know why they put the space up front; it could be a funny way of making a byte order mark, i.e. 2000 for little endian and 0020 for big endian.
At any rate you should look at the SQL Server documentation to see how to use character encodings when characters are converted to bytes. You know, whenever you try to covert characters to bytes, you must specify an encoding. Maybe a default is there, but in general characters->bytes make no sense without an encoding. In your scenario, the two different environments used two different defaults.
I'd appreciate suggestions on how I can convert ASCII control characters, which are supplied via an HTML text box, to their hexadecimal or binary representations.
Currently, my web app, takes the ASCII control character string and converts the values, for example, if ^C is entered the value 5e43 is returned which represents "^" and "6", not control-c which is represented as 02 in hex.
The idea I had was to run a regex against the input to check for control characters with something like: ^[\w]{1} and then return values from a predefined table that matches the regex.
You can directly read from in with (. *in* read) though how the characters get to you is going to be dependent on a lot of things, most specifically the case that the browser is likely to encode them for http transport before you even get started.
I maintain a secure terminal proxy that has to handle all combinations of control characters so I thought I would pass on a few notes:
they are not one character long. you need up to six characters to represent them. try hitting Esc-Ctrl-alt-left-arrow.
esc implies Alt but alt does not imply esc. if the first character is an esc then the next character is the meta/alt of its character value. so if you see esc-b this is Alt-b
some keys (page up for example) send the esc automatically.
esc-esc is it's own thing (which I can't say I fully understand).
The best way is to write a small program that reads from the keyboard one character at a time and then start mashing the keyboard and see what you can come up with.
Here I will read a character from in twice and hit home the first time and end the second
clojure.core=> (. *in* read)
10
clojure.core=> (. *in* read)
10
So clearly one character is not enough to distinguish these two keys, how about two characters?
This next example won't run in the repl because the repl tries to "handle" control character for you, so you will have to make a new project lein new esc add this code then lein uberjar and java -jar esc-1.0.0-SNAPSHOT-standalone.jar
(ns esc.core
(:gen-class))
(defn -main []
(dorun (repeatedly #(println (. *in* read)))))
Running it and hitting these two keys produces this:
^[OF
27
79
70
10 <-- this is the newline
^[OH
27 <-- esc start marker look for this
79
72
10 <-- this is the newline
Here is esc-end
^[^[OF
27
27
79
70
10
And the ctrl character grand prize winner thus far esc-right-arrow
^[[1;5C
27
91
49
59
53
67
10
taking the prize at six bytes.
Working with exclusive-OR on bits is something which is clear to me. But here, XOR is working on individual characters. So does this mean the byte which makes up the character is being XORed? What does this look like?
#include <iostream.h>
int main()
{
char string[11]="A nice cat";
char key[11]="ABCDEFGHIJ";
for(int x=0; x<10; x++)
{
string[x]=string[x]^key[x];
cout<<string[x];
}
return 0;
}
I know bits XORed look like this:
1010
1100
0110
XOR has the nice property that if you XOR something twice using the same data, you obtain the original. The code you posted is some rudimentary encryption function, which "encrypts" a string using a key. The resulting ciphertext can be fed through the same program to decrypt it.
In C and C++ strings are usually stored in memory as 8-bit char values where the value stored is the ASCII value of the character.
Your code is therefore XORing the ASCII values. For example, the second character in your output is calculated as follows:
'B' ^ ' '
= 66 ^ 32
= 01000010 ^ 00100000
= 01100010
= 98
= 'b'
You could get a different result if you ran this code on a system which uses EBCDIC instead of ASCII.
The xor on characters performs the xor operation on each corresponding bit of the two characters (one byte each).
So does this mean the byte which makes up the character is being XORed?
Exactly.
What does this look like?
As any other XOR :) . In ASCII "A nice cat" is (in hexadecimal)
41 20 6E 69 63 65 20 63 61 74
and ABCDEFGHIJ
41 42 43 44 45 46 47 48 49 4A
so, if you XOR each byte with each other, you get
00 62 2D 2D 26 23 67 2B 28 3E
, which is the hexadecimal representation of "\0b--&#g+(>", i.e. the string that is displayed when you run that code.
Notice that if you XOR again the resulting text you get back the text with which you started; this the reason why XOR is used often in encoding and cyphering.
This is a simple demonstration of one time pad encryption, which as you can see is quite simple and also happens to be the only provably unbreakable form of encryption. Due to it being symmetric and having a key as large as the message, it's often not practical, but it still has a number of interesting applications.. :-)
One fun thing to notice if you're not already familiar with it is the symmetry between the key and the ciphertext. After generating them, there's no distinction of which one is which, i.e. which one was created first and which was based on the plaintext xor'd with the other. Aside from basic encryption this also leads to applications in plausible deniability.