Character encoding problem after SmartGWT update

[Niels_EMP]

Hi, I just updated from 5.0-p20151016 to 5.1-p20151218 and afterwards special local characters began showing as "�".
I have made no changes to my database encoding and I have the following meta tags on all my pages:

      <meta charset="utf-8">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">

Do you have any idea what could cause this?

[Blama]

Just FYI: I had a problem with Character encoding as well when changing 5.0->5.1. See this thread.
Unfortunately I could not test any further so far.

Best regards
Blama

[Niels_EMP]

Thanks, all though my issue is not only Chrome specific.
I see the same thing in IE Edge. Haven't tested with FireFox yet.

[Blama]

Yes, my problem (only BatchUploader-related) is also happening in all Browsers, see post#2.

Best regards
Blama

[Isomorphic]

Take fresh look at the Internationalization overview and make sure you've followed all the steps, verifying not each one. Most likely, you changed something inadvertently during the upgrade process.

Not that Blama's problem, which is related to BatchUploader only, is almost certainly unrelated.

[OPY]

I have the same problem as Niels. I just updated from 5.0-p20150515 to 5.1-p20150214 and afterwards all chinese characters from database (through ds files) began showing as "�". (ps: Can show chinese words correctly when it's using RPCManager through server request without ds files.)
environment:
- Tomcat 7
- All type of browsers
- Same problem with Oracle and MSSQL.

No news also after done belows:
- field type set to "next": <field name="CONTENTNAME" title="Layout No" type="ntext" />
- ds file added header: <?xml version="1.0" encoding="UTF-8"?>
- web.xml:
<servlet>
<servlet-name>DataSourceLoader</servlet-name>
<servlet-class>com.isomorphic.servlet.DataSourceLoader</servlet-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</servlet>

[Isomorphic]

As with Neils_EMP above - recheck that you are following all the steps in the Internationalization overview and check the character encoding at each step of processing to isolate the problem.

It's a common occurrence that an issue like this is blamed on a framework change when in fact something else was changed inadvertently during the upgrade process.

[OPY]

I'm quite sure there is nothing changed during the upgrade process. Even I only replaced the library of 5.0 which started "isomorphic_xxxx" with the 5.1 library, the chinese words get from database (using ds file setting) will all change to "�".

[Isomorphic]

People are often quite sure.. as previously indicated, if you think this inside to a framework change, you should check the character encoding at each phase of processing and let us know where you think the flaw might be.

[OPY]

I am using the same code that has been working fine with 5.0, and then compile with 5.1 with no change, and 5.0 version working fine and 5.1 version data did not display correctly.

If I change the "isormophic_xxxxx.jar" in 5.0 app with 5.1 version of "isormophic_xxxxx.jar", the data also did not display correctly.

Just for your information.

Anyway, we will skip 5.1 version for now.

Thank you.

[Blama]

Hi Isomorphic,

even if it seems unrelated - I have a encoding problem as well in the tread linked in post#2 (didn't investigate further, yet).
This also occurred by just replacing 5.0 with 5.1. I really think something is going on here or all the users have (most likely unknowingly) some configuration in common you don't have.

Best regards
Blama

[Isomorphic]

Blama, again your post is specific to BatchUploader and this user is claiming issues with just ordinary DB fetches.

The theory that best fits the data is that these users did not follow all the steps from the Internationalization overview and were simply lucky that some kind of default behavior of their deployment environment was the right one with the particular way that 5.0 did things. Now 5.1 requires these same users to actually follow the docs.

We don't know which change from 5.0 to 5.1 caused this, but we have only a couple of users reporting a problem, and no credible reports of a problem when all documented steps are followed.

So it's not a good idea to assume this is a "bug" that will be reverted in a future version - any user running into this needs to troubleshoot the issue or they may be permanently stuck on 5.0, since there may well be nothing to "fix" on our end.