Oct 222014
 

Webchat logoXIN.at has been running an IRC chat server for some time now, but the problem always lies with people needing some client software to use it, like X-Chat or Nettalk or whatever.

People usually just don’t want to install yet another chat client software, no matter how old and well-established IRC itself may be. Alternatively, they can use some other untrusted web interface to connect to either the plain text [irc://www.xin.at:6666] or the encrypted [irc+ssl://www.xin.at:6697] server via a browser, but this isn’t optimal either. Since JavaScript cannot open TCP sockets on its own, and hence cannot connect to an IRC server directly, there are only two kinds of solutions:

  • Purely client-based as a Java Applet or Adobe Flash Applet, neither of wich are very good options.
  • JavaScript client + server backend for handling the actual communication with the IRC server.
    • Server backends exist in JavaScript/Node.js, Perl, Python, PHP etc.

Since I cannot run [Node.js] and [cgi:irc] is unportable due to its reliance on UNIX sockets, only Python and PHP remained. Since PHP was easier for me, I tried the old [WebChat2] software developed by Chris Chabot for this. To achieve connection-oriented encryption security, I wrapped SSL/TLS around the otherwise unencrypting PHP socket server of WebChat2. You can achieve this with cross-platform software like [stunnel], which can essentially wrap SSL around almost every servers connection (minus the complex FTP protocol maybe). While WebChat2’s back end is based on PHP, the front end uses JavaScript/Comet. This is what it looks like:

So that should do away with the “I don’t wanna install some chat client software” problem, especially when considering that most people these days don’t even know what Internet Relay Chat is anymore. ;) It also allows anonymous visitors on this web log to contact me directly, while allowing for a more tap-proof conversation when compared with what typical commercial solutions would give you (think WhatsApp, Skype and the likes). Well, it’s actually not more tap-proof considering the server operator can still read all communication at will, but I would like to believe that I am a more trustworthy server operator than certain big corporations. ;)

Oh, and if you finally do find it in yourself to use some good client software, check out [XChat] on Linux/UNIX and its fork [HexChat] on Windows, or [LimeChat] on MacOS X. There are mobile clients too, like for Android ([AndroIRC], [AndChat]), iOS ([SIRCL], [TurboIRC]), Windows Phone 8 ([IRC Free], [IRC Chat]), Symbian 9.x S60 ([mIRGGI]) and others.

So, all made easy now, whether client software or just web browser! Ah and before I forget it, here’s the link of course:

Edit: Currently, only the following browsers are known to work with the chat (older version may sometimes work, but are untested):

  • Mozilla FireFox 31+
  • Chromium (incl. Chrome/SRWare Iron) 30+
  • Opera 25+
  • Apple Safari 5.1.7+
  • KDE Konqueror 4.3.4+

The following browsers are known to either completely break or to make the interface practically unusable:

  • Internet Explorer <=11
  • Opera <=12.17
Sep 202012
 

x264 LogoI have played around with PHP a little again, and actually managed to generate PNG images with some elements rendered to them using a few basic GD functions of the scripting language. This is all still very new to me, so don’t be harsh! ;)

I thought I might use this to create some dynamic and more fancy than plain text statistics about the [x264 benchmark]. I decided to do some simple stats about operating systems and CPUs first, didn’t want to overdo it.

So I went for basic OS families and a more broken down visualization of all Windows and all UNIX derivatives. For microprocessors I went for basic architecture families (x86, RISC, VLIW) and a manufacturer breakdown. I know “x86” should probably have been “CISC” instead, but since x86 in itself is so wide-spread, I thought I should just make it its own family. See the following links:

Just so you can see how the generated images look like, I’ll link them in here. As you can see I decided to keep it very plain and simple, no fancy graphics, operating systems first:

Operating systems

Windows operating systems

Windows operating systems

And the microprocessors:

Microprocessor architectures

Microprocessor manufacturers

Not too bad for my first PHP-generated dynamic images? I would sure like to think so. ;)

Jul 092012
 

PHP & MySQL LogoServing UTF-8 can be useful. Why? For instance to display text in several languages on your website. If you want to mix different European and for instance Asian languages, more limited character sets won’t suffice anymore. Thus, UTF-8. In my case, I wanted to display a mix of European and Chinese Mandarin. However, my PHP scripts, MySQL database and even the script textfiles themselves were not prepared. So what do you need to do? First, make sure your database is encoded in UTF-8, using a proper collation too:

ALTER DATABASE `dbname` CHARACTER SET `utf8` COLLATE `utf8_general_ci`;
ALTER TABLE `tablename` CONVERT TO CHARACTER SET `utf8` COLLATE `utf8_general_ci`;

Now your raw data will be stored in UTF-8. The next step is rather easy; Ensure that your script files themselves (also any raw HTML present) are encoded in UTF-8. For that – on MS Windows – you can just use [Notepad++], it can autodetect your source character set and convert to UTF-8.

Additionally, any raw HTML that you might have or that is written by PHP needs a proper encoding definition in the <head></head> section to tell the browser “My text is UTF-8”. Like this:

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Your Title</title>
</head>

Good. Now the hard part. Since PHP sucks a bit, it will default to ISO-8859-1 in pretty much everything it’s doing, that’s basically some modern Latin1 character set including the ‘€’ symbol. But that ain’t good enough for displaying some Japanese or Chinese, so we need to take special care here. The first important thing is to make sure that PHP will read data from MySQL in the properly encoded fashion. Otherwise it will read UTF-8 assuming it’s ISO-8859-1, hence garbling most of the text. So when defining your MySQL connection in PHP, you need to add the mysql_set_charset() function. Could look like this:

$connection = mysql_connect($sql_host,$sql_user,$sql_pass)
mysql_select_db($sql_dbname, $connection)
mysql_set_charset('utf8',$connection);

Now PHP will read and output UTF-8 by default. But be aware that there are additional caveats in PHP! Most string processing functions like e.g. substr() won’t process strings with large multibyte characters correctly. They are hardcoded for ISO-8859-1! Luckily you can load the PHP extension mb_string, which provides multibyte-capable string processing functions. They just use a mb_ prefix, so substr() simply becomes mb_substr()! Still, that means you might need to update your PHP code for UTF-8 capability, sometimes significantly. A documentation of all multibyte-related functions in PHP can be found [here]. With that, handling UTF-8 in both input, processing and output shouldn’t be a problem anymore.