Windows Server Charset bug

[GoogleCodeExporter]

If you remember, then you fixed the charset problem in Mollify, but it seems 
with some characters the problem is still there.

Using Plupload plugin to upload a file named:
Enya - La Soñadora.mp3 
works fine, but trying to upload with the character:
Enya - La Sońadora.mp3
does not, it gives "Unexpected Server Error".

In PHP Error log the line says:
MOLLIFY ERROR: PHP error #8, iconv(): Detected an illegal character in input 
string (SERVER_PATH_HERE\backend\include\Util.class.php:85)

The same goes for when i try using webdav in Mollify, everything else works, 
but the software "GoodSync" starts giving out errors on these files, that 
cannot remove/delete the file, internal server error 500 and not found 404 
codes etc, so the issue is probably somewhere in Mollify.

Configuration bit is:   "convert_filenames" => "CP1252",

Also the same files show and work normally under windows itself (explorer).

Let me know if you need more information.

Original issue reported on code.google.com by Logic...@gmail.com on 14 Feb 2013 at 2:37

[GoogleCodeExporter]

Does the upload error happen when using the default uploader? Or is it just the 
plugins Plupload and WebDAV?

Original comment by samuli.j...@gmail.com on 16 Feb 2013 at 9:24

[GoogleCodeExporter]

It is on all occasions you named above. 
I moved to using NetDrive, it basically mounts a webdav server as a disk in 
windows (easier for me to use) and in there i can't upload files with those 
"bad" characters as well, it gives an error about "couldn't save file" etc. So 
yes, it happens with webdav clients and also Mollify plupload plugin.

Original comment by Logic...@gmail.com on 16 Feb 2013 at 7:50

[GoogleCodeExporter]

Ok, I managed to solve this issue, hopefully.

Under windows, by default, the php.ini has the "default_charset" config line 
commented and should be something like this:

;default_charset = "iso-8859-1"

When reading PHP manual, it says when it is commented or "empty" PHP lets the 
script choose what charset to use. Well, in reality, PHP is not that polite and 
does not and enforces the script to use "iso-8859-1". (Some bug in PHP)
To resolve this issue uncomment the line and add the following:

default_charset = "utf-8"

This solved the issue for me and everything seems to be working now.

Original comment by Logic...@gmail.com on 25 Mar 2013 at 9:47

[GoogleCodeExporter]

Great! Yes it comes down to the fact that windows does not use utf-8 by 
default. Unfortunately most users cannot change the entire PHP charset (service 
providers usually don't allow this), so I should take a look at this some 
point...

Original comment by samuli.j...@gmail.com on 26 Mar 2013 at 10:08

[GoogleCodeExporter]

Alright, another issue appeared.
While the uploading of a file works fine and i can feed Mollify with pretty 
much anything when uploading (making the Mollify script to output the file on 
HDD when done with it), the problem is that when the file gets created under a 
directory which Mollify monitors (where the output files usually gets placed) 
with any other method, other Than uploading it through Mollify (like FTP) and 
includes the "bad characters", trying to view the file via Mollify, get's 
resulted in an "Unknown Error occurred". 

PHP Error Log without Mollify DEBUG enabled shows as follows:

MOLLIFY ERROR: PHP error #2, is_dir(): open_basedir restriction in effect. 
File(MOLLIFY_USER_ROOT_PATH\Enya - La So?adora.Mp3) is not within the allowed 
path(s): (OPEN_BASEDIR_PATH's) 
(MOLLIFY_ROOT_PATH\MOLLIFY\backend\include\filesystem\LocalFilesystem.class.php:
118)

MOLLIFY ERROR: PHP error #8, iconv(): Detected an illegal character in input 
string (MOLLIFY_ROOT_PATH\MOLLIFY\backend\include\Util.class.php:85)

I am very sure that my server in fact DOES support full UTF-8 on all of the 
server components, PHP, Apache, MySQL. Since PHP handles these character 
encodings through Mollify i can't find where the problem lies here.

To simplify a bit:

I can upload a file called "Enya - La Soñadora.mp3" through Mollify and it 
ends up on the Windows Server HDD as "Enya - La SoƱadora.mp3", but gets 
displayed correctly when viewing it through Mollify. That is a bit odd and 
annoying, but i could live with that.

When the file is ALREADY on the disk, the Mollify can't view the file itself 
and results in an error.

Maybe there is a way to be able to reverse the process of the situation 
described above. To be able to first process the file with Mollify BEFORE the 
user actually sees it, meaning it will get decoded to whatever Mollify or PHP 
can understand. 

Even better would be to upload the file and it would actually end up on the 
servers HDD with the correct character instead of that gibberish character.

I also found this: 
http://stackoverflow.com/questions/15593394/encoding-issues-windows-1255-to-utf-
8
It seems the issue perhaps might be there as the user is experiencing the same 
problem, but the lack of my coding skills make me unable to implement the 
solution (or at least a possible solution) to mollify itself.

Maybe this information somehow helps you give some ideas on the issue.

Also, excitingly waiting for Mollify 2.0! 
Good luck and thanks for all your help!

Original comment by Logic...@gmail.com on 2 Sep 2013 at 4:37

[GoogleCodeExporter]

Discussed in issue 492

Original comment by samuli.j...@gmail.com on 11 Nov 2013 at 9:47

• Changed state: WontFix