Retain Japanese language directory / file names?

[murphyslaw]

I am trying to figure out how to retain file names that are in Japanese.

All my directory and file names are in Japanese and I would like to be able to retain them in that language.
Once I upload a directory or file the name is changed to question marks ??

For example, directory names are changed from 自動車 to ??
jpeg names are changed from something like キャディラック-Eldorado_1953_01 to _____-Eldorado_1953_01 (All the Japanese text is replaced by _____) and so I lose all the file names

I am using the latest version of Coppermine.
PHP 5.2.2
ImageMagick

I have made my database run as utf8_general_ci

Thanks for any help

[murphyslaw]

I am using filezilla as my ftp client

[Joachim Müller]

I am trying to figure out how to retain file names that are in Japanese.

Non-Latin chars can lead to issues on various server platforms (Unix. Linux etc.). It's generally not recommended to use non-latin chars as folder/filenames on webservers. That's why Coppermine contains some routines that replace non-latin chars with web-safe equivalents (underscores). After all, the file name doesn't matter - you should not rely on it, but use the caption/description fields (which reside in the database and therefor can contain non-latin chars without issues). If you insist on keeping your non-latin chars, you're on your own with this: I'm reluctant to code a workaround that would just have the lame effect of file-name preservation with the great disadvantage of security issues. Bottom line: if you need to keep your asian file-names, dig into coppermine's core code and remove the security checks that rewrite the file names. But in the end, I recommend reviewing your idea to keep those asian chars - there are several good reason why they get replaced by Coppermine.

I am using the latest version of Coppermine.

That's not a very bright remark. Your perception of what is the latest version may differ from our view. In any case, the information in your posting will become invalid as soon as a new version comes out . That's why we don't name our releases "the most recent", but assign version numbers to them. Subsequently, if you want replies that make sense, post your actual version number in the future. It's always a good idea to post a link to your gallery as well.

Joachim

[murphyslaw]

It's generally not recommended to use non-latin chars as folder/filenames on webservers.

Ah .. so all those who live in Asia / elsewhere and don't use ASCII characters can just like it or lump it? Fair enough, it's your software but in my opinion it is a short term view of things as China and other Asian / non- ASCII character using countries come online. While I don't know what the security risks or server issues you allude to are that are connected to non ASCII characters your response leaves me none the wiser.
Having the front end translated into various languages is admirable but if you can't use files that have names in that language it is only half the job.

[

That's not a very bright remark. Your perception of what is the latest version may differ from our view.

Well Joachim, I realise you may have a lot to do and I'm sure you're a busy man but there's hardly any need to be obnoxious.
A reasonably intelligent person would infer from the date of my post what version I was using.

Thanks for the help

[Joachim Müller]

Ah .. so all those who live in Asia / elsewhere and don't use ASCII characters can just like it or lump it?

Well, the standards that make the www work have been invented with the limited scope of ASCII in mind many years ago. Don't blame me for those standards - I haven't come up with them in the first place.. There have been workarounds to allow other charsets, but there are always issues with them. From your perspective, the loss of the ability to use filenames with asian chars might be bad, but after all, file names don't matter: think of the filenames just as pointers that are simply meant to make them unique to enable them getting written into the database as well as enabling them to be processed by the webserver as well as the browser. This is tech stuff that the average visitor of your site doesn't care for at all. What matters to your site's visitors should be the content generated by Coppermine, which basically is the picture itself and the textual description (using title/caption and longer description text). The textual description can be in any charset you want (utf-8 prefered), which supports asian charsets pretty well. So I simply can't see the point in preserving the file names.

Having the front end translated into various languages is admirable but if you can't use files that have names in that language it is only half the job.

In my mother's tongue (German), there are only a few special chars (the so-called "Umlauts": äöüÄÖÜß), but they are used very often. They get replaced as well when they are being used in file names, and there have been German users who complained about this in the past as well. Basically, there's little we can do to circumvent this. If you're unhappy with this situation, you're welcome to participate in internationalization projects that discuss possible future steps to make all components involved in displaying www sites work with "exotic" charsets (keep in mind that there's a myriad of platforms both client- as well server-sided). If you do, you'll realize how hard it would be to make applications like coppermine work with non-latin chars with only a small benefit for the end users - as suggested above, the end user doesn't care for the file name very much. That's why the Coppermine dev team has chosen to avoid compatibility and security issues by coming up with a routine that replaces potential "trouble-maker" chars with safe ones. If you know a better way to handle those issues, I'm all ears. If you don't know a better method, then please accept my explanation, which is purely technical and in no way directed against people who use non-latin charsets. In my opinion you accussed me of racism in your last posting...

There are loads of good and valid feature requests that I would like to see go into future Coppermine versions. One of the features that doesn't get requested very often but is very important to me personally is an even better approach to i18n and l10n within Coppermine; however, the preservation of special chars in file names is not very high in my priority list.

While I don't know what the security risks or server issues you allude to are

Well, then just take my word on it that things are not as easy as they seem to be for you.

A reasonably intelligent person would infer from the date of my post what version I was using.

I'd be a rich man if I just had a penny for each user who said that he had the most recent version, but in fact didn't have it. Let's see how well you would do on a Microsoft support board: do you think that you could get away with posting that you have "the most recent Windows version" ? Certainly not.
A "reasonably intelligent person" would have posted "you're right, I should have posted what actual version I use, it's cpgX.Y.Z".

I find it sad that even though I took the time trying to explain the situation in detail you replied with a confrontational message, forcing me to come up with an even more detailed (though pointless) reply. Quite frankly: if you don't understand the technical difficulties involved and if you're not ready to read them up, then don't ask for technical details. As suggested: you're welcome to remove the file name replacement routines that are built into Coppermine as a safety precaution. After all it's you who'll have to live with the consequences. That's one of the nice things about open source: you're allowed to change the code as you see fit.

Joachim