Quote from: fixedmachine at Jun 04, 2010, 10:57 AM
Not exactly as expected. There should be Gallery folder inside Easy2 folder. Your description says:
"Zip’s name will be used as the new folder name."
Ahh... yeah. that one. I should change that description, then.
I need to explain that I don’t use the pclzip.lib.php anymore, which creates the new folder from the zip’s name.
As I’ll speak more about i18n below, pclzip brought me a headache when I need more call back function for ’_e2g_decode’-ing.
So actually I’ve already created my own function.
Coincidentally, MODx already has one. So I deleted my own, and used MODx’s for a testing. Several tests (at my side) went succeeded. But I knew that different platforms and character based filename would bring more trouble.
I couldn’t identify the problem if I didn’t publish this first, NOT via MODx’s extra package.
Quote from: fixedmachine at Jun 04, 2010, 10:57 AM
God ;P I was talking about my workstation. My webserver is running on Linux:
Linux kernel - 2.6.33.1-grsec
File system - ext3
MODx - 1.0.3
MySQL - 5.1.47
PHP - 5.2.12
Apache - 2.2.14
I’ll check it out on my localhost webserver on windows7 too. But there is something wrong in the code for sure.
I believe that this part of code is the thing that bring you troubled:
e2g.module.class.php, line 1940:
<?php // highlighting
// _unzip function
// str_replace must be used under windows to convert "/" into "\"
$complete_path = $path.str_replace('/','\\',dirname(zip_entry_name($zip_entry)));
$complete_name = $path.str_replace('/','\\', zip_entry_name($zip_entry) );
If your server has
magic_quotes_gpc = On, this is killing you.
Better you get it off.
Uhmm... should I put the run-time work around?
Quote from: fixedmachine at Jun 04, 2010, 10:57 AM
What about encoding. I’m ready with transliteration. So when you upload file with accent characters in its name it transliterate them to the closest one. If you don’t explicitly specify Title it will take the original (not transliterated) name of that file (without extension) and use it as a title in database.
But... There is a question: should we do that as a default or just an optional behaviour? If we do not want to transliterate file names and save them on the filesystem with their original names, there is a bunch of additional problems. We must know filesystem encoding (not always utf-8) and original file name encoding. In most cases using locale is pointless. One of the solutions is to encode filenames with Unicode encoded names for URI. In that case we using just legal ASCI letters. That generally safe, but the file name in this case could be really long and even if the user send us file with a legal 255B filename length, after the URI encoding it will be much longer. Of course file names that long are rarely used, and if the filename exceed the 255B limit we could trim it.
It’s just my proposition. What do you think? Should there be an option to store files with their original names on the file system or should we transliterate all the names and use UTF-8 characters only in titles in db?
There is a need to change the _e2g_decode and _e2g_encode functions - now, when they rely on utf8_decode and utf8_encode they are definitely useless.
I know that _e2g_decode/_e2g_encode functions is far from perfection, but I need to bring the idea that the encoding should have some selections.
Right now you’re talking about the polish’s character, tomorrow Japanese will ask the same question. So that’s the idea of the flexible encoding selection under a config’s variable was born.
Need more work? I couldn’t agree more.
And that’s why I don’t even use PHP’s zip extractTo() functions.
AFAIK, it breaks non latin-1 character.
Tested and proven. No chance to insert a callback function in the process.
ZipArchive class uses
IBM850 encoding for filenames, or also other
zip softwares.
So I think the better way is to strip down the content one by one, fwrite them, and use their [real] filename by an encoding function.
Well, again, I’m incompetence on this, just read them some.
So, what you explained above is fit with my purpose.
Btw, when you try to create a new selection, please remember to add that new selection too on the
easy2/includes/tpl/pane.config.inc.php, line 43.
Or for development only, you can change the value directly in the
config file.
Quote from: fixedmachine at Jun 04, 2010, 10:57 AM
Read that documents:
http://www.phpwact.org/php/i18n/utf-8
http://www.phpwact.org/php/i18n/charsets
I’ve read them from top to bottom.
No, I still don’t understand, because I don’t have that ’real’ obstacle, yet.
PS:
Anyway, please test the UTF-8 functions that’re already included in the includes/ folder.
☆ A M B ☆
So maybe one of our English friends could help with that task?