Character encoding bug

Have you tried the new charset settings at admin/build/services/settings/amfphp.

I wonder then, should we just remove this line altogether as well as the configuration page? You tell me, I've never dealt with other encodings.

I had to change line 50 in the amfphp.module to

$gateway->setCharsetHandler("iconv", "UTF-8", "UTF-8");

To get Japanese to work before.

thanks

I had the same problem and just deleted that line 50 to solve it. It seems that the module can receive data in utf8 and stores it correctly in drupal, but if it serves data, it converts the utf8 data from drupal into ISO-8859-1 (in line 50), which should not be done, because flex handles it as utf8.

Just wanted to add that we had to do the same thing because line 50 was overriding anything being set in gateway.php

-Loc

Hi,
Just chiming in.

I had the same problem with Japanese too and you have to take out line 50.
Once it's out everything runs peachy.

The explanation I read is that Drupal turns everything internally to UTF-8 already there is no need to decode it again as it is already UTF-8 out of Drupal and by AMF messing with it, it screws it up when it enters Flash.

So when I update the AMFPHP module I have to take out line 50.
I had to do this recently and the problem was I had forgotten that this was necessary as I had done it a long time ago.
After a lot of panicking I re-found the article on Drupal where some kind gent explains the problem.

Hi,

I had the same problem with the german special-characters (Ö,Ä,Ü,ö,ä,ü)
I deleted that line 50 to solve it.

i make a patch that add admin screen to the amfphp module, where you can control the charset handler, and change the problematic line 50 to :
$gateway->setCharsetHandler(variable_get('amfphp_charset_mode', 'iconv'), variable_get('amfphp_charset_phpCharset', 'UTF-8'), variable_get('amfphp_charset_sqlCharset', 'UTF-8'));

and make the default charset handler utf-8.

@perelman yuval: The patch contains your .project file (eclipse?). You should remove it.
Apart from that - it does the work, and allows flexibility where it's needed.

@z.stolar thanks for the comment , i removed the project file and upload the file again.

I had to make the same (remove the line from the amfphp.module file).
I suggest do not force the charset, but let the user choose it in the file amfphp/gateway.php

I suggest use a copy of /modules/amfphp/amfphp/gateway.php (named for example, modules/amfphp/amfphp/drupal-gateway.php) and require it in the file amfphp.module (maybe the file could be placed in drupal/sites/default/ for example)

@JuniorZ: The patch in #11 saves the need of editing files, and makes it easy for people to test different encodings, until the desired result is achieved.

GREAT, that worked for me with Danish Character to. Thanks

Subscribing.

On the DRUPAL-6--1 (dev) branch, an admin settings form was added. See #237193: Add settings form to change Charset with variable_get. This patch will need to be re-rolled against DRUPAL-6--1, if there even any changes now that the settings form is already in.

Gentlemen,

I updated this lovely module recently and it blew up my site (on test so no worries), and I found that our good friend line 50 is no longer at line 50.

So this is for anyone reading the thread who has had the same problem~

X No longer on amfphp.module Line 50

Open up, amfphp.inc and kill this on line 17:

$gateway->setCharsetHandler(variable_get('charset_method','utf8_decode'), variable_get('charset_php','ISO-8859-1'), variable_get('charset_sql','ISO-8859-1'));

That got it working again for me.

I'm sure there is a good reason why it's still in the module.
However the above line has for the history of this thread, utterly buggered foreign languages so I would have thought it might have happened in the update. I see there is a cunning solution being formed in the thread, but until it has been formed, is it not better just to have the line gone?

Cheers guys.
Love this module all the same.

Thanks for the update. Worked 100% for me in the first shoot