I tried as below:
sqlplus username/passwd#dbname
Here it is connected
But in the sqlplus prompt whenever I try to execute/write a query which is longer than 256 chars, the prompt isn't allowing. it is omitting the chars after 256 chars.
Related
I have a thermal printer "MPT-II" from an unknown Chinese brand, that has both USB and Bluetooth. I can successfully print text using:
Loyverse app on Android
JavaScript
Raw HEX or decimal
However, only using the Loyverse app am I able to input special characters, and by special characters I mean the Danish characters æøå/ÆØÅ.
If I open up any BLE tool on Windows (Bluetooth LE Lab for example), I can select the correct characteristic and send something like 104 101 108 108 111 13 10 which would print "hello" on the printer. I've read a bit about the ESC R and ESC t commands, but how exactly do I set those modes? I've tried prepending it to each command, such as 27 82 1 104 101 108 108 111 13 10 where the 27 82 1 corresponds to ESC R 4 and the 4 corresponds to Denmark I.
According to the printer's manual, it states the following:
GB18030 character set, ASCII characters, user defined characters, bar codes CODE39, EAN13, EAN8, CODABAR, CODE93, ITF, bitmaps.
According to that list, the Danish character set is not supported. I'm not sure how the Loyverse app is doing it correctly, but the text is the same using raw commands and Loyverse, so I don't think Loyverse is converting to a bitmap and sending that data.
So my real question is: How do I send the correct character set for my printer? Maybe the character set is already correct, but the ASCII character for æøå/ÆØÅ are wrong?
EDIT: I have confirmed that something works with the ESC XXXX commands. If I do 27 97 2 followed by my "hello" sequence, the text is printed to the right (right aligned). So that definitely works.. I have tried probably all character sets thus far using ESC R and ESC t but none of them work :(
EDIT 2: I have now tested every single combination of ESC R and ESC t. I went through the entire list printing some Chinese characters, and every single line of 150+ I tried all returned the same Chinese character. So ESC R or ESC t is definitely not the command I should be using to change the charset.
From this, MySQL load data infile command works well with hexadecimal delimiter like X'01' or X'1e' in my case. But the same command can't be run with same command load data infile on MemSQL.
I tried specifying various forms of of the same delimiter \x1e like:
'0x1e' or 0x1e
X'1e'
'\x1e' or 'x1e'
All the above don't work and throw either syntax error or other error like this:
This is like the delimiter can't be resolved correctly:
mysql> load data local infile '/container/data/sf10/region.tbl.hex' into table REGION CHARACTER SET utf8 fields terminated by '\x1e' lines terminated by '\n';
ERROR 1261 (01000): Row 1 doesn't contain data for all columns
This is syntax error:
mysql> load data local infile '/container/data/sf10/region.tbl.hex' into table REGION CHARACTER SET utf8 fields terminated by 0x1e lines terminated by '\n';
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '0x1e lines terminated by '\n'' at line 1
mysql>
The data is actually delimited by non-printable hexadecimal character of \x1e and line terminated by regular \n. Use cat -A can see the delimited characters as ^^. So the delimiter should be correct.
$ cat -A region.tbl.hex
0^^AFRICA^^lar deposits. blithely final packages cajole. regular waters are final requests. regular accounts are according to $
1^^AMERICA^^hs use ironic, even requests. s$
Are there a correct way to use hex values as delimiter? I can't find such information in documentation.
For the purpose of comparison, hex delimiter (0x1e) can work well on MySQL:
mysql> load data local infile '/tmp/region.tbl.hex' into table region CHARACTER SET utf8 fields terminated by 0x1e lines terminated by '\n';
Query OK, 5 rows affected (0.01 sec)
Records: 5 Deleted: 0 Skipped: 0 Warnings: 0
MemSQL supported hex delimiters as of 6.7, of the form in the last code block in your question. Prior to that, you would need the literal quoted 0x1e character in your sql string, which is annoying to do from a CLI. If youre on an older version you may need to upgrade.
I have an IP of the server and a port on which I'm able to connect via nc on Ubuntu 14.04.
> nc x.x.x.x PORT
In order to communicate with the server, the first step is to send a WAKEUP call and get acknowledgment. The server expects a 3 byte ID in the wakeup call. An example is provided in the documentation that shows the success scenario of sending the ID and receiving the ack using a software. i.e
The client sends:
<sy><sy><eq>111<et>
And the server responds with:
<sy><ak>A<et><cr>
Here is some detail of <sy>
Within <> brackets is a non-printable ASCII character (<sy> = ASCII 22 or Hex 0x16)
I tried to replicate the exact same scenario but failed to do so. The server doesn't respond to the data I send, although the data is received there. I'm not sure about these tags <sy><sy><eq> etc. How to send the ID(111) along with these tags <sy> correctly?
Also tried to send this data using Rails framework and Bindata ruby gem but don't know how to represent the above format.
netcat is probably the wrong tool for this. Or at least you will want to use some other program to feed it input.
If I were doing this, I would code up something in python or C that would both connect to the server and feed it whatever data I needed to send it (and receive/interpret the responses) leaving out nc altogether. There are many examples on the web.
You can encode the control characters in a byte string in python with the syntax b'\x16' for your <sy> character. Most other languages have an equivalent capability.
I can't be sure exactly what those characters are. It seems likely they are standard ASCII control characters, but they aren't using the standard abbreviations (see http://www.theasciicode.com.ar/ for example). So presumably the documentation you are looking at has a list of the corresponding values. Assuming for the sake of example that <eq> corresponds to the ASCII ENQ character and <et> to the ASCII EOT (and given you already know that <sy> is equivalent to ASCII SYN), your desired string <sy><sy><eq>111<et> can be encoded in a python byte string: b'\x16\x16\x05111\x04'
(or equivalently b'\x16\x16\x05\x31\x31\x31\x04' if you like regularity: the 1 characters are simply ASCII digits, so you can replace each 1 with its binary equivalent b'\x31')
To return to nc, trying to type in the control characters to the nc input from a terminal window is, while possible in most cases, very difficult and error-prone. You will need to know the equivalent control character mapping (for example, 0x16 is "Ctrl-V") and will need to know how to get the terminal to accept that literal character (coincidentally, in linux, you have to precede most control characters with a Ctrl-V in order to enter them as input and avoid having them interpreted in the usual way: Ctrl-D == EOF, Ctrl-C == Interrupt, Ctrl-W == Delete-Previous-Word, etc).
So if you wanted to enter the data above into nc's input from the command line, you would need to type these characters:
Ctrl-V Ctrl-V <sy> / SYN
Ctrl-V Ctrl-V <sy> / SYN
Ctrl-V Ctrl-E <eq> / ENQ
1
1
1
Ctrl-V Ctrl-D <et> / EOT
But also important to note is that ordinarily nc will not actually send anything until you enter a newline (i.e. press the Return key). Then that newline character will also get sent to the server which might not be what you want.
When I grep on a log file , the matched patterns are truncated to 2048 characters.
Eg: grep 'txn-id-111111' transactions.log gives
2015-12-18 (txn-id-111111) EmployeeInformation[AssociateDetails[empId=161223,empname=JohnSmith],AssociateAddress[street1 =1074 NY boulevard]..........................empBranch=N
The object is printed only until 2048 characters.
Is there a way to retrieve the complete line without getting truncated?
FYI..I'm using using super putty.
I have been trying to figure out how exactly \x00, \n, \r, \, or \x1a can cause an SQL Injection (as it is mentioned at http://nl3.php.net/manual/en/function.mysql-real-escape-string.php)
I understand the idea of single quote and double quotes, but how and why I need to take care of the other items to make my query safe?
I was wondering about the same question and I found the answer in the C API documentation of MySQL, it states:
Characters encoded are “\”, “'”, “"”, NUL (ASCII 0), “\n”, “\r”, and
Control+Z (\x1a). Strictly speaking, MySQL requires only that backslash and
the quote character used to quote the string in the query be escaped.
mysql_real_escape_string() quotes the other characters to make them
easier to read in log files.
It is also explained in String Literals that:
The mysql client truncates quoted strings containing NUL characters if
they are not escaped, and Control+Z may be taken for END-OF-FILE on
Windows if not escaped.
The NUL character represents the end of a string in C language, so this can falsely terminate the input argument of the mysql client program. Same thing for \x1a, it marks the end-of-file under Windows (try type test.txt in a command prompt with a \x1a character in the middle of the file).
The main point is that an admin can miss important information in a log file if his log file reader doesn't show the data beyond one of these characters. But who still uses precarious type command or equivalent under Windows to read a log file anyway?
In other terms, there is no danger with \n, \r, \0 or \x1a in PHP, other than potentially making a log file difficult to read.
As for the backslash, \' OR 1==1 would be converted to \\' OR 1==1 if it was not escaped too, cancelling the effect of the escaping of the quote.
let's assume you have
$SQL="select * from mytable where myfield='$uservalue'"
\ -> \:
try \' or 1=1; --', after escaping the quote, you would get \\' or 1=1; --' and the SQL would be select * from mytable where myfield='\\' or 1=1; --'
\x00
Not important for PHP, but for C
Sorry, too lazy for the rest.