Wed 12 Oct 2005 09:53:31 PM UTC, comment #39:
@ Kargor
LC_CTYPE and LANG (generally in etc/environment) are maybe well defined in your system but it is not enough.
make sure the locales (at least the one you use) are existing and have been built.
output of the command 'locale'?
I ever run mldonkey on windows and linux and I never encountered any problem.
|
Wed 12 Oct 2005 04:16:08 PM UTC, comment #38:
For me, I can't try 2.6.4. I obtained a prebuilt version, and it is linked to a specific version of a library. The library doesn't exist on the MacOS X Tiger.
So, I couldn't test it. I'm sorry.
|
Wed 12 Oct 2005 02:57:32 PM UTC, comment #37:
I never got mldonkey 2.6.4 to work (on a Linux box), no matter how I set the various environment variables suggested in this thread.
So I decided to take a shortcut by just applying the "Mac" patch suggested a few posts below --- so now I'm back at where I was before: getting correct filenames instead of _________.
So, if the env-variables don't work, a recompile can fix it.
Would be better to fix this for good, but well... it's working now, and it's not my software :-)
Btw... this has made it into my top-10: I've seen quite a few unix programs with various 8-bit char problems, but I've never seen one that couldn't even handle the ASCII chars (letters, digits, ...) without special patches/configuration.
|
Tue 04 Oct 2005 07:53:43 AM UTC, comment #36:
I have similar problem. But no matter what I changed the LC_CTYPE to, the language and locale showed is always "EN" and "ANSI_X3.4-1968". Why?
I've tried 2.5.30-16 and 2.6.4.
|
Fri 08 Jul 2005 04:20:03 AM UTC, comment #35:
This problem is solved!!!!
Thank you.
|
Thu 07 Jul 2005 02:26:25 AM UTC, comment #34:
OK. Now I tested with the 2.5.30.17 version.
It recognizes the language as KO and the locale as UTF-8.
Let's wait and see what the completed file names become.
Thank you for this wonderful work!
|
Thu 07 Jul 2005 02:13:49 AM UTC, comment #33:
Oh.. I tested with 2.5.30.16.
Let me try with the 17 version.
|
Wed 06 Jul 2005 11:27:52 AM UTC, comment #32:
@JongAm Park: Are you using a current 2.5.30.17 core for your tests?
The bugfix by su_blanc was committed in that version.
|
Wed 06 Jul 2005 01:41:27 AM UTC, comment #31:
Hello, Su Blanc.
Oh! I see. I missed the line.
Even though I change the LC_CTYPE, the current language detected by mlnet is "EN" still.
Here is the dump.
JongAm-Parks-Computer:/Applications/Network/Mldk2.5.30 jongampark$ export LC_CTYPE="ko_KR.UTF-8"
JongAm-Parks-Computer:/Applications/Network/Mldk2.5.30 jongampark$ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="ko_KR.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8/ko_KR.UTF-8/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8"
JongAm-Parks-Computer:/Applications/Network/Mldk2.5.30 jongampark$ ./mlnet
Blocking system signals until core is started...
Current locale of the target machine is US-ASCII
Current language of the target machine is EN
|
Wed 06 Jul 2005 12:48:14 AM UTC, comment #30:
@JongAm Park
you didn't get me.
LC_CTYPE should change *ONLY* the LANGUAGE ('EN', 'KO', ...) detected by mlnet *NOT* the CODESET ('US-ASCII', 'UTF-8', ...).
Thus if you change LC_CTYPE, does the current LANGUAGE detected by melnet changed from 'EN' to 'KO'?
For the CODESET we have to patch the source src/utils/lib/charsetstubs.c, thus mlnet will detect 'UTF-8' by default on MACOS.
value
ml_locale_charset(void)
{
const char *str;
#ifdef MACOS
str = "UTF-8";
#else
#ifdef HAVE_LOCALE_CHARSET
str = locale_charset ();
#else
setlocale(LC_CTYPE, "");
str = nl_langinfo(CODESET);
#endif /* HAVE_LOCALE_CHARSET */
#endif /* MACOS */
if (!str)
raise_error ();
return (copy_string ((char*) str));
}
|
Tue 05 Jul 2005 01:22:16 AM UTC, comment #29:
Hello, Su Blanc.
I tried changing the LC_CTYPE explicitely.
However, the mlnet still think it is US-ASCII.
|
Tue 05 Jul 2005 12:35:46 AM UTC, comment #28:
Hello, Su Blanc~
Actually I didn't change the LC_CTYPE only.
I changed the LC_ALL, so, if you type "locale", you can also check the LC_CTYPE is changed as such.
So, in my case, although they are set to ko_KR.UTF-8, the mlnet still thinks it is US-ASCII
|
Mon 04 Jul 2005 01:00:01 AM UTC, comment #27:
sorry i wasn't logged in.
no the question is : if you change LC_CTYPE to "ko_KR.UTF-8", does the LANGUAGE detected by mlnet change to "KR"?
the CODESET is anyway not detected properly
|
Sat 02 Jul 2005 07:47:17 AM UTC, comment #26:
Hi, None.. I'm sorry to call you NONE, because there is no name on "posted by" column.
Anyway, whatever locale I change to, it is still US-ASCII.
Actually, LC* types can be changed properly, but mlnet still thinks that it is US-ASCII.
I already tested the ko_KR.UTF-8 case.
Thank you.
|
Sat 02 Jul 2005 07:19:52 AM UTC, comment #25:
@JongAm Park
1) Can you change the LC_CTYPE environment variable to "ko_KR.UTF-8" and see if the output of mlnet gives "...Current language of the target machine is KR ..."
2) i think this core uses the nl_langinfo but not the locale_charset () from libcharset...
There is a report stating that nl_langinfo(CODESET) returns "US-ASCII" on mac in the case the environment variables LANG, LC_CTYPE, LC_ALL are not set by the system.
http://lists.gnu.org/archive/html/bug-gnulib/2005-02/msg00048.html
but mlnet works well.
otherwise we would fall back to the string "ASCII" but not to "US-ASCII".
@spiralvoice and amorphous
The language detected by mlnet is given by LC_CTYPE that is the category related to encodings as per definition of a LOCALE model.
Maybe we should change ml_get_default_language by testing LANG first, then LC_ALL and then only LC_TYPE for all platforms?
For MacOS X, we should modify ml_locale_charset.
There is this paper from Bruno Haible (Author of the GNU libiconv) http://www.caddr.com/macho/archives/sbcl-devel/2004-11/4221.html
As suggested, on MacOS X, the default encoding UTF-8 has to be supposed.
Or instead of nl_langinfo on MacOS X, we could try to catch LANG, LC_ALL with getenv before to fallback to "UTF-8".
|
Fri 01 Jul 2005 07:06:16 AM UTC, comment #24:
Hello.
I set the LANG environment variable again.
JongAm-Parks-Computer:/etc jongampark$ locale
LANG="ko_KR.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
JongAm-Parks-Computer:/etc jongampark$ export LANGUAGE=ko_KR.UTF-8
JongAm-Parks-Computer:/etc jongampark$ locale
LANG="ko_KR.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
JongAm-Parks-Computer:/etc jongampark$ cd /Applications/Network/Mldk2.5.30/
JongAm-Parks-Computer:/Applications/Network/Mldk2.5.30 jongampark$ ./mlnet
Blocking system signals until core is started...
Current locale of the target machine is US-ASCII
Current language of the target machine is EN
However it still treat the locale as US-ASCII.
Can someone advise me how to set the locale properly?
|
Fri 01 Jul 2005 06:26:24 AM UTC, comment #23:
To sprialvoice
Well.. The Mac OS X system uses UTF-8 for its file system level.
I also set LANG environment variable to UTF-8 in terminal.
However the launched mlnet still recognize its encoding as US-ASCII.
To Su_Blanc
Well, yes. With the Finder, I can write in languages other than English. In its Terminal program, I also can write file names that way.
|
Thu 30 Jun 2005 12:18:05 PM UTC, comment #22:
"Current locale of the target machine is US-ASCII"
You have to have UTF-8 or something similar here, otherwise
MLDonkey converts all non-US-ASCII characters to US-ASCII,
the system has to provide UTF support, otherwise MLDonkey will
circumvent using non-available characters by replacing them with "_".
Please see my comments 14-17 how I managed to use UTF characters
with MLDonkey on a system which normally lacks UTF support.
It is possible, however the FTP and SSH daemons from that system
(outside the chroot) can´t access those files;-) But thats another
story, I have to compile some daemons for use in that chroot so
it will work.
If the core does not start with this message:
"Current locale of the target machine is UTF-8 "
it will never work for you.
|
Thu 30 Jun 2005 09:08:09 AM UTC, comment #21:
Can you write manually files with names having those characters that are replaced by mlnet in '_' on your system ?
|
Thu 30 Jun 2005 04:16:48 AM UTC, comment #20:
Hi.
It is US-ASCII.
Here is the dump of the screen.
Hope it helps.
Blocking system signals until core is started...
Current locale of the target machine is US-ASCII
Current language of the target machine is EN
List of charmap used to convert the strings:
Use encoding CP1252
Use encoding ISO-8859-15
Use encoding 850
Use encoding CP819
Use encoding MAC
Use encoding 437
Use encoding 860
Use encoding 863
Use encoding ANSI_X3.4-1968
Use encoding C99
Use encoding ISO-10646-UCS-2
Use encoding UCS-2BE
Use encoding UCS-2LE
Use encoding ISO-10646-UCS-4
Use encoding UCS-4BE
Use encoding UCS-4LE
Use encoding UTF-16
Use encoding UTF-16BE
Use encoding UTF-16LE
Use encoding UTF-32
Use encoding UTF-32BE
Use encoding UTF-32LE
Use encoding UNICODE-1-1-UTF-7
Use encoding UCS-2-INTERNAL
Use encoding UCS-2-SWAPPED
Use encoding UCS-4-INTERNAL
Use encoding UCS-4-SWAPPED
|
Thu 30 Jun 2005 01:00:48 AM UTC, comment #19:
@JongAm Park
what is the output of mlnet at start up regarding the current locale and the encoding list?
Can your system support the characters replaced by '_'?
|
Wed 29 Jun 2005 03:41:18 AM UTC, comment #18:
OK. I tested it.
The file names are still ----- where the characters are not English.
|
Sat 25 Jun 2005 11:05:21 PM UTC, comment #17:
As users can circumvent this through correctly setting up their
systems and there is currently no better idea doing this can this
bug be closed?
|
Sun 22 May 2005 03:10:18 AM UTC, comment #16:
Ok, can answer my question myself for Debian:
/usr/lib/locale/locale-archive
copying it into my chroot solves my problem:
# export LANG=de_DE.utf8
# export LANGUAGE=de_DE.utf8
# chroot /disk/mlnet /mlnet -stdout
Current locale of the target machine is UTF-8
Current language of the target machine is DE
List of charmap used to convert the strings:
Use encoding CP1252
Use encoding ISO-8859-15
Use encoding 850
Use encoding CP819
Use encoding MAC
Use encoding 437
Use encoding 860
Use encoding 863
Use encoding ANSI_X3.4-1968
Use encoding C99
Use encoding ISO-10646-UCS-2
Use encoding UCS-2BE
Use encoding UCS-2LE
Use encoding ISO-10646-UCS-4
Use encoding UCS-4BE
Use encoding UCS-4LE
Use encoding UTF-16
Use encoding UTF-16BE
Use encoding UTF-16LE
Use encoding UTF-32
Use encoding UTF-32BE
Use encoding UTF-32LE
Use encoding UNICODE-1-1-UTF-7
Use encoding UCS-2-INTERNAL
Use encoding UCS-2-SWAPPED
Use encoding UCS-4-INTERNAL
Use encoding UCS-4-SWAPPED
|
Sat 21 May 2005 11:16:36 AM UTC, comment #15:
My core prints this:
# ./mlnet -stdout
Current locale of the target machine is ANSI_X3.4-1968
Current language of the target machine is EN
List of charmap used to convert the strings:
Use encoding CP1252
Use encoding ISO-8859-15
Use encoding 850
Use encoding CP819
Use encoding MAC
Use encoding 437
Use encoding 860
Use encoding 863
Use encoding ANSI_X3.4-1968
Use encoding C99
Use encoding ISO-10646-UCS-2
Use encoding UCS-2BE
Use encoding UCS-2LE
Use encoding ISO-10646-UCS-4
Use encoding UCS-4BE
Use encoding UCS-4LE
Use encoding UTF-16
Use encoding UTF-16BE
Use encoding UTF-16LE
Use encoding UTF-32
Use encoding UTF-32BE
Use encoding UTF-32LE
Use encoding UNICODE-1-1-UTF-7
Use encoding UCS-2-INTERNAL
Use encoding UCS-2-SWAPPED
Use encoding UCS-4-INTERNAL
Use encoding UCS-4-SWAPPED
|
Sat 21 May 2005 11:14:24 AM UTC, comment #14:
I am using MLDonkey chroot´ed with glibc 2.3 in the chroot on a
system which lacks glibc completely. Which files do I have to copy
into my chroot to have UTF-8 support there?
As written in bug #9101 I can use UTF-8 files without problems
but I have the same situation described in this bug. I know its
not really a bug, its a feature.
But maybe some LANG files can help me?
|
Sat 21 May 2005 03:31:13 AM UTC, comment #13:
mlnet cannot write a [CJK] string if your locale is ISO-8859-15 (considered as western european by mlnet).
so each character contained in the string, that are not compatible with your locale, will be replaced by '_'.
I did it like this for a safe implementation and make sure we can commit all the files.
I'm opened to any suggestion that could improve/enhance the way we commit the file with its name.
|
Fri 20 May 2005 04:53:18 PM UTC, comment #12:
What happens if the files' names are in language X, but your locale is for language Y?
|
Thu 19 May 2005 05:31:16 PM UTC, comment #11:
Your versions are working fine for me on eisfair! Look here: http://www.mldonkey.org/phpbb2/viewtopic.php?p=31432
So if you could compile a version with this patch, I will test it as fast as possible.
|
Thu 19 May 2005 05:23:57 PM UTC, comment #10:
Ask here (http://www.matze-b.dyndns.org/) if he can make 2.5.30.15 cores for EISFAIR.
|
Thu 19 May 2005 04:54:07 PM UTC, comment #9:
Believe me, I would test it if I'm able to compile the files! :( I don't know how to do and I think my Eisfair isn't able to do it either. Sorry!
If you make a binary for me, I will test it (and try to set my locale back to Posix instead auf C) of course!
|
Thu 19 May 2005 04:07:16 PM UTC, comment #8:
Please test current CVS + patch #3984.
Do you compile yourself?
|
Tue 03 May 2005 03:03:00 AM UTC, comment #7:
you may try to set your environment variable LANG to "de_DE".
POSIX is very restrictive (like C).
|
Mon 02 May 2005 11:39:35 PM UTC, comment #6:
I don't know why, but now it works fine!
I have restarted the core after it freezes and now it has created three files with the right name. But I will investigate this further!
|
Mon 02 May 2005 01:03:54 PM UTC, comment #5:
OK, so here is my output:
LANG=POSIX
LC_CTYPE=de_DE@euro
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
Does this help?
|
Mon 02 May 2005 08:55:59 AM UTC, comment #4:
you can try the command 'locale' in a console. see 'man locale' for further infos...
|
Mon 02 May 2005 05:55:55 AM UTC, comment #3:
How or where can I find out how my LOCALE is set? I didn't find anything about this.
The file extension is not properly written!
|
Mon 02 May 2005 02:21:49 AM UTC, comment #2:
That's correct. The number of "_" is according to the number of chars seen by Ocaml (may differ from the real number further to the encoding used).
The core is unable to convert the file name into a string as per your LOCALE param. How is set your LOCALE?
It is most likely your params (LANG & LOCALE) are not properly set or those params are too restrective to allow a proper conversion from the chars used in your file names.
Is the extension of the file properly written. Something like "________.png" or "________.ogg"?
|
Fri 29 Apr 2005 10:25:22 PM UTC, comment #1:
When a file is downloaded and commited, the file name in the incoming directory is changed to something like "______________________". The number of the "_" is variable and different each time. I think it is as long as the original file name, but I can't verify this right now.
The content of the file is OK and it is working when I manually rename the file.
Seems like some kind of character conversion error or something like that to me.
|
Fri 29 Apr 2005 10:12:51 PM UTC, original submission:
|