mldonkey-bugs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Mldonkey-bugs] [bug #9102] [CJK] File names in Downloads and search res


From: su_blanc
Subject: [Mldonkey-bugs] [bug #9102] [CJK] File names in Downloads and search results Web UI page
Date: Tue, 3 May 2005 06:15:27 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910

Follow-up Comment #19, bug #9102 (project mldonkey):

@spiralvoice:
right now, the filename_conversions option is a bit tricky, doesn't it?

a- What does prevent the user to put a pair (97, ">") in
filename_conversions? The consequences are huge if I'm a windows user,
because your loop will never fallback to the safe replacement of chars for
windows .... and I won't be able to commit any file if the file name contains
'a'.

b- Shouldn't we rename "The conversions to apply on characters depending on
their ASCII code" to "The conversions to apply on characters to fallback to
an ASCII string".
Even this option is too dangerous as it is coded because there no check that
the replacement string consists strictly in ASCII chars and there is no check
that the char I want to replace is included in the range 0x00 to 0xFF (OCaml
char is 8 bits and Ocaml int is 31 bits!). So anyway we are able to convert
only chars that are in the 0x00 to 0xFF range, which is very limited in
comparison with UTF-8 characters.

c- Another example, if I am Arabic and I use the filename_conversions option
as is, I will get some issue to understand why the arabic letter LAM (in
ISO-8859-6: 0xe4 == 228) is replaced by "ae" in my filename.

I think you should change as follows:

1) create conversions functions for safe checking:
let safe_int8 i =
  if i > 255
    then failwith (Printf.sprintf "Cannot convert character if higher than
255 [%i].\n" i)
    else i

let safe_ascii s =
  for i = 0 to String.length s - 1 do
    if int_of_char s.[i] > 127
      then failwith (Printf.sprintf "%c is not an ASCII character.\n" s.[i])
  done;
  s

let value_to_int8 v =
  let i = Options.value_to_int v in
  safe_int8 i

let int8_to_value i =
  let i = safe_int8 i in
  Options.int_to_value i

let value_to_ascii v =
  let s = Options.value_to_string v in
  safe_ascii s

let ascii_to_value s =
  let s = safe_ascii s in
  Options.string_to_value s

let ascii_option =
    define_option_class "Ascii"
    value_to_ascii ascii_to_value

let int8_option =
    define_option_class "Int8"
    value_to_int8 int8_to_value

2) define option filename_conversions:

let filename_conversions = define_expert_option current_section
    ["filename_conversions"] 
    "The conversions to apply on characters to fallback to an ASCII string"
    (list_option (tuple2_option (int8_option, ascii_option))) []

3) make sure the default value is []. the user has to choose.

4) in CommonInteractive.canonize_basename, make sure that the characters '/',
'\\' are replaced (as well as for windows ':', '*', '?', '"', '<', '>', '|',
'%'). That's not case now.

But no, CommonInteractive.canonize_basename, option filename_conversion and
Charset.to_locale may be complementary. Despite they fallback to '_', they
don't do it for the same purpose.
Charset.to_locale make sure we have a string that is as per LOCALE in any
case (even if the final string is not 'human' readable), but
filename_conversions option doesn't.

Another solution (less elegant than Charset.to_locale + filename_conversions
option) would have been to convert any string going through
CommonInteractive.canonize_basename in ASCII string:

+-----------------------------------------------------+
| for i = 0 to String.length s - 1 do                 |
|   s.[i] <- char_of_int (int_of_char s.[i] land 127) |
| done                                                |
+-----------------------------------------------------+

the result may be unreadable but it's working anywhere.

@Amorphous:
yes ANSI_X3.4-1968 is an alias of ASCII (range is 0x00 to 0x7F - 128 chars).
very limited to convert strings ...



    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?func=detailitem&item_id=9102>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]