MySQL - Java - Can't handle special characters - java

I have a JTextArea from which I get the text, and send it through a POST request to a PHP page, which uses PDO and a prepare statement to insert the text into a MySQL database. This works for everything that I can type directly into the JTextArea. However, it doesn't work when I copy and paste something from Word, for example, into the JTextArea and then upload it.
For example, if I type into Word: "This is a super—long dash." Then copy and paste that in the JTextArea and have it send to the PHP page, which will upload it to the MySQL server, when I get the information back from the MySQL server (using another PHP page) it comes back as "This is a super—long dash."
This also happens for other various special characters, not just long dashes.
Is there anything I can do about this?
EDIT:
I tried to correct the issue by making sure all my php files are using utf8 to connect to mysql like so:
"mysql:host=$servername;dbname=$dbname;charset=utf8"
I also use
echo $_POST[xxx];
To make sure the text is coming in from java correctly, which it is. When I check what is the mysql database, it shows as "This is a superùlong dash". I tried to correct this by using the fixUTF8 function in the solution here: Detect encoding and make everything UTF-8 by Sebastián Grignoli. However, as a result I get "This is a super?long dash".

Related

Java-MySQL-Android: bad base-64

I guess this is a stupid question with an obvious solution, but I don't see it yet. So the problem is: I get an IllegalArgumentException on Android, which says my base64 input is not valid. This input took the following way before:
Upload: PDF file -(Java Base64 encoder) > Java Base64 encoded string -(POST)-> PHP -(INSERT as mediumtext via mysqli query)-> MySQL DB
Download: MySQL record -(SELECT via mysqli query and fetch assoc afterwards)-> PHP vars -(JSON)-> Java as JSON -(Jackson library, maps JSON to object containing String)-> Java Base64 String - (Android Base64 decoder)-> Exception
Is there any failure in my workflow? Communication is done with UTF-8 via HttpUrlConnection.
I was able to solve the problem: During transfer to the server + and / got omitted. After manually replacing them, everything is working now.

JSP doesn't display texts from DB in a language other than English

I have the following code in my JSP
... <%
out.println(request.getAttribute("textFromDB")); %> ...
When the JSP is called it just prints question marks (????..) instead of the actual text stored in a MySQL database which is not in English. What can I do to make it display the text correctly. I tried to change the charset and pageEncoding to UTF-8 but it didn't help.
Isn't encoding nice? Unfortunately it's hard to tell where it gets wrong: Your database might store in another character set than UTF-8. Or your database driver might be configured to work in another encoding. Or your server defaults to another one. Or your HTTP connection assumes different encoding and your charset change comes too late.
You'll have to go through all those layers - and keep in mind that everything might look fine and it's been the long-past write-operations to your database that already messed up the data beyond repair.
System.out.println(this.request.getHeader("Content-Encoding")); //check the content type
String data = new String(this.request.getParameter("data").getBytes("ISO-8859-1"), "UTF-8"); //this way it is encoded to byte and then to a string
if the above method didnt work you might wanna check with the database
if it encode characters to "UTF-8"
or
you can configure URIEncoding="UTF-8" in your tomcat setup and just (request.getAttribute("textFromDB")); do the rest.

UTF-8 encoding problems between Android, JSon and PHP

I programmed an Android App, which manages data to be stored and deleted in a MySQL database (on server). Whenever on the smartphone special characters ("ä", "ü", ...) are used the symbol is converted badly.
In the log I can see that the "Umlaut" (e.g. "ä") is transmitted properly. I also use in my php file "SET NAMES 'UTF-8'", see here:
function connect()
{
....
// Connecting to mysql database
$con = mysql_connect(DB_SERVER, DB_USER, DB_PASSWORD) or die(mysql_error());
mysql_query("SET NAMES 'utf8'");
// Selecting database
$db = mysql_select_db(DB_DATABASE) or die(mysql_error()) or die(mysql_error());
return $con;
}
If I start a request via Postman, I can add words with special characters, e.g. "TÄST", the json response looks as follows:
{"catId":"35","category":"T\u00c4ST"}
So the words are well converted to UTF-8. But if I add an Item via smartphone, the response from the server (to retrieve the added item) looks like this:
{"catId":"37","category":"T?ST"}
The position in my code, where I add the parameters for the JSON Object is that (note that "name" is the string content of the edit text field):
List<NameValuePair> params = new ArrayList<NameValuePair>();
...
params.add(new BasicNameValuePair("category", catName));
After that the HTTPRequest is send:
JSONObject json = jsonParser.makeHttpRequest(url_dest, "POST", params);
If I print out the params the word "Täst" is visible... But unfortunately I'm not able to check which json string is arriving on the server (due to my bad php knowledge). So where's the problem? In my android application or in the php files located on the server?
Do I have to encode the outgoing json object in any way?
Thanks a lot for your help.
To debug on Eclipse I suggest you:
http://projects.eclipse.org/projects/tools.pdt
It is quite easy to configure.
Control the encoding in the DB; maybe the VARCHAR default latin1_swedish_ci can't save that string.
Another way to solve it could be looking to the apache commons:
http://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/StringEscapeUtils.html
in particular the functions provided by: escapeHtml4 and unescapeHtml4
#dafocus, if you set your Android app project to UTF-8 encoding in your IDE, it should ensure that UTF-8 is handled properly in the app. It looks like an encoding change somewhere. You might not need to convert TÄST to T\u00c4ST at all if the encoding is UTF-8 throughout. PHP used to be difficult with charsets. I would suggest you to look at the PHP to figure out if the handler page causes this (possible) and/or the DB - as #madx just said.

Russian character not showing well in java but is ok in php? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
We have a web application where the can insert russian character and in the mysql db it looks like this ДоÑтавка груза. But when is viewed on the web is shows correctly in the russian character form. But when we do it in java application it showing up in this format ДоÑтавка груза? Any help?
Part of the java codes are below.
Statement stmt1 = null;
//System.out.println("\n\nSELECT selectOTACommand : "+selectOTACommand);
String select1 = "Select locName from tblLoc where locID=2280"
ResultSet rs1= stmt1.executeQuery(select1);
while(rs1.next())
{
System.out.println("Loc Name : "+rs1.getString("locName"));
}
try{
if ( rs1 != null ){
rs1.close();
}
else{
System.out.println("MyError:rs1 is null in finally close");
}
if ( stmt1 != null ){
stmt1.close();
}
else{
System.out.println("MyError:stmt1 is null in finally close");
}
}
catch(SQLException ex){
System.out.println("MyError:SQLException has been caught for stmt1 close");
ex.printStackTrace(System.out);
}
you have to set on three places the encoding that is used, so that it will be ok and the way it should be.
php
mysql database and table
the link that php uses to communicate with mysql (this is what most ppl miss) you have two options here. phps' mysql_set_charset() -> mysql_set_charset or doing itwith two queries SET NAMES 'charset_name' + SET CHARACTER SET charset_name
That application says that it is windows-1251 encoding.
You should probably convert it to UTF.
I suggest, as Nikola said above, SET NAMES 'utf8' would solve your problem. You have to say MySQL what character set encoding your client is gonna use to send SQL statements and in what character set encoding it wants to receive the result. SET NAMES affects all these settings.
Please first have a read of The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).
After that let's take a look at your php script and how it interacts with the other components involved.
Your PHP script receives input from the client/browser, which apparently is utf-8 encoded. I.e. if the clients sends the character Д it sends the two bytes 0xD0 and 0x94.
If you take those two bytes and interpret/display them as e.g. iso-8859-1 encoded you get two characters: Д (just like in your question text).
Your PHP script takes those two bytes and passes them to MySQL. MySQL now has to parse/interpret those bytes, too. There are quite some encoding/charset-related settings involved in this but let's reduce it to: there's a charset associated with the connection between php and mysql and there's a charset for storing the data "within" the MySQL server. (For more information have a read of https://dev.mysql.com/doc/refman/5.0/en/charset-connection.html).
It looks like the connection charset in your case is something like iso-8859-1. I.e. the MySQL server interprets 0xD0,0x94 not as Д but as Д - two characters.
When your php script gets the data back from the MySQL server the server sends two characters, Ð and ”. Since the connection charset php<->mysql still is iso-8859-1 the MySQL server encodes those two characters again as 0xD0 and 0x94.
PHP takes those two bytes (doesn't have a clue about utf-8 but that doesn't matter in this case) and sends it back to the client.
The client now has to interpret those two bytes. In your case ("when is viewed on the web") the client most likely fetches the information about the encoding from either a header in the http response or from an equivalent parameter within your html document. And this parameter seems to be "the stream is utf-8" encoded. Therefore the two bytes 0xD0,0x94 are displayed as Д again. So from the client/webbrowser's point of view everything is fine, php doesn't care about the mistake and neither does MySQL in this case. (There are problems that can arise "within" your php script and "within" the MySQL server...)
So, everything looks fine here - but ...that's mostly because php doesn't care. Java on the other hand usually does.
I.e. when the MySQL server sends the two "characters" Ð and ” they will be handled as two separate characters in the java application. And when those two characters are send to the client that will be encoded in a way that the client will interpret them as two seperate characters as well and so on and on. (At least usually there a lot more automagically handled by default.)
Same with the frontend you've used to peek into the MySQl database. It apparently handled the encoding correctly and therfore displayed До‚авка грузаinstead of Дотавка груза.
Make sure your database/table column encoding can handle the characters you have to store; utf-8 can do it. see https://dev.mysql.com/doc/refman/5.0/en/charset-syntax.html
Make sure your php script sets the connection encoding to utf-8 since that's what the script seems to receive from the client anyway, no need to convert it to another charset first. How to do that depends on the API youre using to connect to the MySQL server:
mysql (mysql_connect): this module is deprecated, think about using another module like mysqli or pdo. The correct way to set the connection charset would be
mysql_set_charset('utf-8', $mysql);
That function is php>=5.2.3 but any other method like SET NAMES leaves the client library in the dark about the connection charset so e.g. mysql_real_escape() may not work correctly. see http://docs.php.net/mysql_set_charset
mysqli ( new MySQLi(), mysqli_connect ) : see http://docs.php.net/mysqli.set-charset.php
pdo ( new PDO('mysql:...') ):
$pdo = new PDO('mysql:host=HOSTNAME;port=3306;dbname=DATABASENAME;charset=utf8');
PHP >= 5.3.6, see http://docs.php.net/ref.pdo-mysql.connection

Set [Automatically wrap text] in Java mail

i have an account register function, after user inputted personal data, an confirm email will be sent to that customer with a generated link. The problem is that: because the link is too long, it is broken into two lines (The second line is from character 76) and the second line does not belong the the first line (User cannot click on the whole link). I think this problem may come from the word wrap or something like that
In Outlook Express, under menu->Tools->Options->Send->HTML setting, we can set number of characters that the email content should be wrapped in each line by changing the value. Is there any way to set this function using core Java Mail?
Thank you in advance.
Word wrapping is done by the viewer (i.e. Outlook Express) not when sending email. I would guess that you are sending plain text emails and relying on the viewers to try and identify that it contains links. Try sending HTML mail and using ''
No, JavaMail is a library allowing you to send/receive email through Java. It is not an application like Outlook/Outlook Express or Thunderbird for that matter.
That said, you can write code that does the formatting before it invokes JavaMail to send the email out.
First, you can't set a setting in java mail to change a client's formatting.
Second, while my solution might not be the best answer to the question. It should help with the problem you are having.
Before adding your link into the body of the mail make sure you;
Put the link on a new line. "\n" ;)
Make a little method using URL shortening API like bitlyj for bit.ly to shorten the URL. Add the shortened link and walla!
msg.setContent("This is an example of adding a shortened URL\n"
+ shortLink("http://www.longlink.com")
+ "\n", "text/plain");
public String shortLink(String link) {
Url url = as("Username", "APIKey").call(shorten(link));
return url.getShortUrl();
}
Using this approach you shouldn't have any issues with word wrap stuff.

Categories