I am also not so sure this really all that bad. I guess there are 3 scenarios
1: the archive standard is known to use a specific encoding 2: the encoding is specified inside the archive (which is similar to 1) 3: we have no clue about the encoding of the strings in the archive Unless I am missing something we are fine for 1+2 because as long as we create the strings as we should. It's up to the user of compress to turn this into something he can use on his platform. For 3 there is just no point. All we can do is provide a way to get the name and the user needs to figure out the conversion. Nothing we can do about it. So I guess we all we need to do is to be sure not to create Strings in the default encoding for 1+2. Or what am I missing? cheers -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
