My HTMLEncode function in Java

Every now and then I have to work in an environment where imports of frameworks is prohibited and it in times like that that I had to create my own HTMLEncode function. Here is the result:

public static String HTMLEncode(String inputString) {

		// Check if string contains ANY special characters (<>"&)
		if(inputString.indexOf("<") != -1 || 
                   inputString.indexOf(">") != -1 || 
                   inputString.indexOf("\"") != -1 ||
                   inputString.indexOf("&") != -1) {

			char c;
			StringBuffer out = new StringBuffer();
			for(int i=0; i < inputString.length(); i++) {
			    c = inputString.charAt(i);
			    if(c=='"' || c=='<' || c=='>') {
			    else if(c == '&'){
                    // Is &-sign preceding an HTML entity?
			    	if(inputString.indexOf("&", i) == i || 
			    		inputString.indexOf("& #38;", i) == i ||
		    			inputString.indexOf("& lt;", i)  == i || 
		    			inputString.indexOf("& #60;", i) == i ||
		    			inputString.indexOf("& gt;", i)  == i ||
		    			inputString.indexOf("& #62;", i) == i ||
		    			inputString.indexOf("& quot;", i)== i ||
		    			inputString.indexOf("& #34;", i) == i ){
			    	else {
			    else {
			return out.toString();
		else {
			return inputString;			

NOTE! The spaces inside the strings on row 21 thru 27 are only there for displaying purposes. In real code these spaces should be removed

Charset problem in Play framework after upgrading OSX

This is such a strange problem that I just have to write it down for future reference.
Involved systems:
* One Ubuntu 14.04.2 LTS on AWS (Amazon Web Services)
* One MacBook Pro 2010 with 10.7.5 with iTerm 2.1.1
* One MacBook Pro 2015 with 10.10.3 with iTerm 2.1.1
* One Play framework 2.3 application

Problem description:
After starting the Play application with the MacBook that has the 10.10.3 version all files that were written to disk had all non-ascii characters shown as ??. When starting the Play application with the old computer (10.7.5) these characters where displayed correctly.

After quite a lot of trial-and-error I found that the command ‘locale’ on the remote AWS server complained about:
“locale: Cannot set LC_CTYPE to default locale: No such file or directory”
“locale: Cannot set LC_ALL to default locale: No such file or directory”
when using the newer computer but not with the old

The ‘locale’ command error lead me to the following solution in iTerm:
Untick the Terminal option “Set locale variables automaticly” in Preference

This option is AFAIK default on in iTerm

After this was done the ‘locale’ error was gone and all files had the correct charset

Add SSL certificate to a JKS storage

I have started doing this quite a lot these days so I’d better put a post up here to get rid of all the Google searching 🙂 It’s not that complicated but I know I will forget if I don’t do it for a while.

Lets start with the .p12 file. This is the file that we are going to put into the jks container. For this we have a .crt and .key file from our CA.

First we need to remove any password from the key file

openssl rsa -in server.key -out server.key_nopasswd

You will be prompted for the password of your .key file

Once the key file is without a password we can create the .p12 file

openssl pkcs12 -export -name somename -in server.crt -inkey server.key_nopasswd -out keystore.p12

Now we have the .p12 file. Time to put it into the jks container

keytool -importkeystore -destkeystore mykeystore.jks -srckeystore keystore.p12 -srcstoretype pkcs12 -alias somealias

Lastly we need the CA certificate

keytool -import -keystore mykeystore.jks -file someca.crt -alias someotheralias

That is pretty much it!