UTF-8/ ISO-8859-1 issue with upgrade from 5.2(IIS+MSSQL) to 6.2 (Linux+Apache+MSSQL)

[jgrimaldos]

Hi, I'm migrating an old sugar install from 5.2 to 6.2, however we're also changing platforms and the sugarcrm app has been used A LOT (this would be relevant on a while).

So far, the upgrade process hasn't been very user-friendly, with some vardef sync queries having been done by hand as the sugarcrm scripts seem unable to cope with them... however, with the help of the forum I was able to fix them.

But now, I have a bigger issue in hand: We have done some customization and the system has a langpack installed... Anyway, here's the beef of the post: SugarCRM seems to be using UTF-8 and the data SQL Server is displayed wrong, if I manually change encoding to ISO-8859-1, the SQL-stored strings look fine but the Langpack-stored strings look mangled... changing the data on the DB is not an option as the DB is used by the Crystal Reports with some custom reports and changing default_charset in config.php didn´t help... I could manually pass for each of the langpack files but Chrome, Firefox and IE seem to ALWAY assume that SugarCRM is in UTF-8... even with a iso-8859-1 on the header!

Thanks for the hellp.

[jgrimaldos]

Bump because I´m still struggling with it, even after setting Apache's default encoding as ISO-8859-1, php's default encoding as !SO-8859-1 and Sugar's default encoding as ISO-8859-1, the encoding that the browser uses is UTF-8, the HTTP headers have been overwritten and read UTF_8, but I can't figure out when and who is overwriting it.

[christianknoll]

MSSQL cannot handle UTF-8 but only if we speak unicode UCS-2 as an antiquated double byte encoding. When Sugar stores data in the MSSQL Database it stores the UTF-8 encoded String with the Database encoding ending up that you see garbage in the database. However if the bean handles data it is encoded properly and presented as it should. This is the life with MSSQL and Sugar ... if you purely use it with Sugar everything is fine but if you want to access the data direct with third party tools like Crystal this will lead into problems.

christian.

Hi, I'm migrating an old sugar install from 5.2 to 6.2, however we're also changing platforms and the sugarcrm app has been used A LOT (this would be relevant on a while).

So far, the upgrade process hasn't been very user-friendly, with some vardef sync queries having been done by hand as the sugarcrm scripts seem unable to cope with them... however, with the help of the forum I was able to fix them.

But now, I have a bigger issue in hand: We have done some customization and the system has a langpack installed... Anyway, here's the beef of the post: SugarCRM seems to be using UTF-8 and the data SQL Server is displayed wrong, if I manually change encoding to ISO-8859-1, the SQL-stored strings look fine but the Langpack-stored strings look mangled... changing the data on the DB is not an option as the DB is used by the Crystal Reports with some custom reports and changing default_charset in config.php didn´t help... I could manually pass for each of the langpack files but Chrome, Firefox and IE seem to ALWAY assume that SugarCRM is in UTF-8... even with a iso-8859-1 on the header!

Thanks for the hellp.

[jgrimaldos]

I found that in include/utils the encoding header was hardcoded... if this is by design, why there's a default_encoding option on config.php?

Anyway, I tried to handle this issue on my langpacks by doing a system-wide search-and-replace of special chars and replacing them with htmlentities... so far, so good until I hit Javascript... Javascript doesn't handle this issue very well.