"Jigal van Hemert" <[EMAIL PROTECTED]> wrote:
> At the moment we're using MySQL 4.0.20 and PHP 4.3.8 to build a new website > frame work which should support various languages and various browser > encodings. Upgrading to MySQL 4.1.x and PHP 5.x is not possible in the near > future, because a number of webservers and a couple of MySQL servers would > be involved in the simultaneous upgrade. > > A the moment we have defined the internal encoding for the application as > ISO-8859-1, but we would like to use UTF-8 to make storing and outputting > data in non-Western European encodings a lot easier. > Although I realize that MySQL 4.0.x has no UTF-8 support, I was wondering > what the implications and problems could be if we tried to store UTF-8 data > in MySQL 4.0.20 InnoDB tables? Is it limited to LIKE and FULLTEXT problems > or can you expect other problems? Do we need to declare columns as BINARY or > should queries use BINARY? >From the MySQL's side, UTF8 is nothing but a binary data. We at Ensita.NET are using UTF8 in most of our projects and we just INSERT and SELECT it from the tables as a binary data. No problem. Yes, FULLTEXT and LIKE are likely to work in an unexpected manner. -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.net http://www.ensita.net/ __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Egor Egorov / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.net <___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
