I used this webpage http://javascriptobfuscator.com/default.aspx to obfuscate a small script.
$(document).ready(function(){
$("#likee").fadeOut("fast");
});
And the obfuscated code is:
$(document)["\x72\x65\x61\x64\x79"](function (){$("\x23\x6C\x69\x6B\x65\x65")["\x66\x61\x64\x65\x4F\x75\x74"]("\x66\x61\x73\x74");} );
I am using a form to insert the obfuscated code into mysql. However, when I inserted the code I got this:
$(document)["x72x65x61x64x79"](function (){$("x23x6Cx69x6Bx65x65")["x66x61x64x65x4Fx75x74"]("x66x61x73x74");} );
Does anybody know why backslashes are removed?
Will my code work without backslashes?
I believe it has something to do with the encoding. I guess that you are using the utf8 encoding format for the text/varchar (or some sort) column where the data is inserted in.
The utf8 encoding format only accepts unicode characters that can be represented with 3 bytes, but the \x23 character needs 4 bytes, so mysql strips the character.
How to solve?
Do you have mysql 5.5 or later? You can change the column encoding from utf8 to utf8mb4. This encoding allows characters of 4 bytes.
Source: "Incorrect string value" when trying to insert UTF-8 into MySQL via JDBC?
Related
I built a PHP web page and some of the characters are like this
⇾ ....
â€....
etc
Please help me on how to eliminate this
If you're not using UTF-8 characterset, I would try to change the encoding of the database to avoid these characters:
How to convert an entire MySQL database characterset and collation to UTF-8?
I am trying to change the character set from latin1 to utf8
Problem: The passwords are not working for French characters. The password works for special characters(like quotes, brackets, dollar sign, etc.). If I convert the character set in the code part back to latin1, I can login using French characters, but not with utf8
What have I done so far:
Changed the character set of the database; I can see all column types
are showing as utf8. I ran the query both at the database and the
table level.
Changed the character set for the code part to utf8.
My testing shows all is cool, I can see accented French characters
fine, and nothing seems broken. It is only for Passwords that
are giving me issues.
Please suggest:
Do I need to change the data itself to utf8 as well?
I ran alter table command, and it changed the column character set to
utf8, am I missing something here?
I am suspecting this may be the cause because the passwords are working fine if I convert the code part to latin1. So I am thinking as the code and the database were latin1, so it can recognize the special characters, but when I change it to utf8 it cannot interpret the special French letters as those were initially stored as latin1.
Both PHP and MySQL version are latest.
Since my response was long, I decided to add it here:
The hashing functions are very complex, it is using a combination of md5,encode64,and crypt function. I have noticed the resultant pwd is different for latin and unicode. That is the reason, I was suspecting that previously generated pwd using latin1 can match the pwd, and not unicode after conversion. Again, it is only happening for French letters, and not the ascii range for 0 to 127. I am not sure how to handle this situation where the existing users can successfully login, with the char set changed to unicode-8. I can't use iconv(), as there is no way I can distinguish whether the passwords are created using latin1 or unicode8. Do I need to change the data too in addition to changing the database, and how ? If I am thinking right, then the data conversion to unicode8 may take care of French characters as well?
if you need to convert char from some Unicode to another
you can use this function
iconv()
We are trying to migrate database content (with a PHP script).
Content has been copied into a CMS and then written to the database. Content copied could be from any character encoding scheme (e.g. IS0-...-14) and any website.
The PHP CMS is UTF-8 so the character pasted into a textbox would be converted to UTF-8 when it was POSTed but then written to the database as Latin-1 (MSSQL db...db charset and query charset both latin-1).
We are desperately trying to think up how this could be reversed or if it is even possible (to get it so the character is fully UTF-8) in PHP.
If we can get the logic we can write an extension in C++ if PHP cant handle it (which it probably cant, mb_shite and iconv).
I keep getting lost in UTF-8 4 byte character streams (i.e. 0-127 is..ect).
Anybody got any ideas?
So far we have used PHP's ord() function to try and produce a Unicode/Acsii char ref for each char (I know ord returns ASCII but it prints character numbers over 128 which I thought was wierd if it is just meant to be ASCII, or maybe it repeats itself).
My thoughts are the latin1 will struggle to convert back to UTF-8 and will result in black diamond due to single byte char stream in Latin1 (ISO-...-1).
If latin1 is an 8-bit clean encoding for your database (it is in MySQL, donno about MSSQL), then you don't need to do anything to reconstruct the utf-8 string. When you pull it out of your database into PHP you will get back the same bytes you put in, i.e. UTF-8.
If latin1 is not an 8-bit-clean encoding for your database then your strings are irretrievably broken. This means any characters which the database considered invalid were either dropped or replaced the moment you wrote your utf-8 string to the database. There isn't any way to recover from this.
I have the following problem: on a very simple php-mysqli query:
if ( $result = $mysqli->query( $sqlquery ) )
{
$res = $result->fetch_all();
$result->close();
}
I get strings wrongly encoded as Western encoded string, although the database, the table and the column is in utf8_general_ci collation. The php script itself is utf-8 encoded and the mysql-less parts of the script get the correct encodings. So say echo "ő" works perfectly, but echo $res[0] from the previous example outputs the EF BF BD character when the file viewed in the correct UTF-8 encoding. If I manually switch the browser's encoding to Western, the mysqli sourced strings get good decoding, except for the non-western characters being replaced with "?'.
What makes it even stranger is that on my development environment this isn't happening, while on my webserver it is. The developer environment is a LAMP stack (The Uniform Server), while the webserver uses nginx.
In this case, I entered the data in the database using phpMyAdmin, and inside phpmyadmin it displays perfectly. phpMyAdmin's collation is utf-8 too. I believe that the problem must be somewhere around here, as on the same webserver, for an other site where I enter data through php (using POST) the same problem doesn't happen. On that case, the data is visible correctly both while entering and while viewing it (I mean in the php generated webpages), but the special characters are not correct in phpMyAdmin.
Can you help me start where to debug? Is it connected to php or mysql or nginx or phpMyAdmin?
Use mysqli_set_charset to change the client encoding to UTF-8 just after you connect:
$mysqli->set_charset("utf8");
The client encoding is what MySql expects your input to be in (e.g. when you insert user-supplied text to a search query) and what it gives you the results in (so it has to match your output encoding in order for echo to display things correctly).
You need to have it match the encoding of your web page to account for the two scenarios above and the encoding of the PHP source file (so that the hardcoded parts of your queries are interpreted correctly).
Update: How to convert data inserted using latin-1 to utf-8
Regarding data that have already been inserted using the wrong connection encoding there is a convenient solution to fix the problem. For each column that contains this kind of data you need to do:
ALTER TABLE table_name MODIFY column_name existing_column_type CHARACTER SET latin1;
ALTER TABLE table_name MODIFY column_name BLOB;
ALTER TABLE table_name MODIFY column_name existing_column_type CHARACTER SET utf8;
The placeholders table_name, column_name and existing_column_type should be replaced with the correct values from your database each time.
What this does is
Tell MySql that it needs to store data in that column in latin1. This character set contains only a small subset of utf8 so in general this conversion involves data loss, but in this specific scenario the data was already interpreted as latin1 on input so there will be no side effects. However, MySql will internally convert the byte representation of your data to match what was originally sent from PHP.
Convert the column to a binary type (BLOB) that has no associated encoding information. At this point the column will contain raw bytes that are a proper utf8 character string.
Convert the column to its previous character type, telling MySql that the raw bytes should be considered to be in utf8 encoding.
WARNING: You can only use this indiscriminate approach if the column in question contains only incorrectly inserted data. Any data that has been correctly inserted will be truncated at the first occurrence of any non-ASCII character!
Therefore it's a good idea to do it right now, before the PHP side fix goes into effect.
Use mysqli::set_charset function.
$mysqli->set_charset('utf8'); //returns false if the encoding was not valid... won't happen
http://php.net/manual/en/mysqli.set-charset.php
I haven't used mysqli for some time, but if things are the same, connections by default use the latin swedish encoding (ISO 8859 1).
I will consider your page is already using utf8 encoding by having:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
Inside the <head> tag.
If you have string already on latin swedish encoding, you can use mk_convert_encoding:
http://php.net/manual/en/function.mb-convert-encoding.php
$fixedStr = mb_convert_encoding($wrongStr, 'UTF-8', 'ISO-8859-1');
iconv does something very similar: Truth be told, I don't know the difference, but here's the link to the function reference:
http://php.net/manual/en/function.iconv.php
I just realized that you might have some strings in utf8 and others in latin swedish. You can use mb_detect_encoding for that: http://php.net/manual/en/function.mb-detect-encoding.php
You can also dump the database and use iconv (cmd line) if you have it installed:
iconv -f latain -t utf-8 < currentdb.sql > fixeddb.sql
I have a MySQL table & fields that are all set to UTF-8. The thing is, a previous PHP script, which was in charge of the database writing, was using some other encoding, not sure whether it is in the script itself, the MySQL connection or somewhere else. The result is that although the table & fields are set to UTF-8, we see the wrong chars instead of Chinese.
It looks like that:
Now, the previous scripts (which were in charge of the writing and corrupted the data) can read it well for some reason, but my new script which all encoded in UTF-8, shows chars like ½©. How can that be fixed?
By the sound of it, you have a utf8 column but you are writing to it and reading from it using a latin1 connection, so what is actually being stored in the table is mis-encoded. Your problem is that when you read from the table using a utf8 connection, you see the data that's actually stored there, which is why it looks wrong. You can fix the mis-encoded data in the table by converting to latin1, then back to utf8 via the binary character set (three steps in total).
The original database was in a Chinese encoding – GB-18030 or similar, not Latin-1 – and the bytes that make up these characters, when displayed in UTF-8, show up as a bunch of Latin diacritics. Read each string as GB-18030, convert it to UTF-8, and save.