Re: [vfs] is there any way to treat a file in a zip-file to a FileObject?
many thanks! Bernd Eckenfels 于2020年7月24日周五 下午3:21写道： > Yes, the VFS providers can be nested and the access is controlled by a > layered URL, something like zip:file:/dir/1.zip!2.jpg can be resolved into > a FileObject. > > The second example here does the same for entries in a JAR file: > https://commons.apache.org/proper/commons-vfs/api.html > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > ____ > Von: Xeno Amess > Gesendet: Friday, July 24, 2020 7:51:07 AM > An: user@commons.apache.org > Betreff: [vfs] is there any way to treat a file in a zip-file to a > FileObject? > > As title. > for example, 2.jpg is in 1.zip, and what I want is a FileObject > representing 2.jpg, but I don't want to extract it to a virtual file, what > I want is read/write it directly treating it as a FileObject. > Is there any ways in doing this? > If not, should I implement one? >
[vfs] is there any way to treat a file in a zip-file to a FileObject?
As title. for example, 2.jpg is in 1.zip, and what I want is a FileObject representing 2.jpg, but I don't want to extract it to a virtual file, what I want is read/write it directly treating it as a FileObject. Is there any ways in doing this? If not, should I implement one?
Re: [commons-lang3] potential bug in CharSequenceUtils?
yes it is really a bug.
I created a fix pr (with test codes) at
https://github.com/apache/commons-lang/pull/529
check in it when you guys have time.
Xeno Amess 于2020年4月29日周三 上午5:04写道：
> well when I look at StringUtil I found something like this.
>
> final char c1 = cs.charAt(index1++);
> final char c2 = substring.charAt(index2++);
>
> if (c1 == c2) {
> continue;
> }
>
> if (!ignoreCase) {
> return false;
> }
>
> // The same check as in String.regionMatches():
> if (Character.toUpperCase(c1) != Character.toUpperCase(c2)
> && Character.toLowerCase(c1) != Character.toLowerCase(c2)) {
> return false;
> }
>
> But it actually is not quite same to what in String.regionMatches.
> the code part in String.regionMatches. in JKD8 is actually
>
> char c1 = ta[to++];
> char c2 = pa[po++];
> if (c1 == c2) {
> continue;
> }
> if (ignoreCase) {
> // If characters don't match but case may be ignored,
> // try converting both characters to uppercase.
> // If the results match, then the comparison scan should
> // continue.
> char u1 = Character.toUpperCase(c1);
> char u2 = Character.toUpperCase(c2);
> if (u1 == u2) {
> continue;
> }
> // Unfortunately, conversion to uppercase does not work properly
> // for the Georgian alphabet, which has strange rules about case
> // conversion. So we need to make one last check before
> // exiting.
> if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
> continue;
> }
> }
>
> see, the chars to invoke Character.toLowerCase is actually u1 and u2, but
> according to logic in CharSequenceUtils they should be c1 and c2.
> If they are functional equal, then why oracle guys create the two
> variables u1 and u2? That is a waste of time then.
> So I think it might be a bug.
> But me myself know nothing about Georgian.
> Is there anybody familiar with Georgian alphabet and willing to do further
> debug about this?
>
>
>
[commons-lang3] potential bug in CharSequenceUtils?
well when I look at StringUtil I found something like this.
final char c1 = cs.charAt(index1++);
final char c2 = substring.charAt(index2++);
if (c1 == c2) {
continue;
}
if (!ignoreCase) {
return false;
}
// The same check as in String.regionMatches():
if (Character.toUpperCase(c1) != Character.toUpperCase(c2)
&& Character.toLowerCase(c1) != Character.toLowerCase(c2)) {
return false;
}
But it actually is not quite same to what in String.regionMatches.
the code part in String.regionMatches. in JKD8 is actually
char c1 = ta[to++];
char c2 = pa[po++];
if (c1 == c2) {
continue;
}
if (ignoreCase) {
// If characters don't match but case may be ignored,
// try converting both characters to uppercase.
// If the results match, then the comparison scan should
// continue.
char u1 = Character.toUpperCase(c1);
char u2 = Character.toUpperCase(c2);
if (u1 == u2) {
continue;
}
// Unfortunately, conversion to uppercase does not work properly
// for the Georgian alphabet, which has strange rules about case
// conversion. So we need to make one last check before
// exiting.
if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
continue;
}
}
see, the chars to invoke Character.toLowerCase is actually u1 and u2, but
according to logic in CharSequenceUtils they should be c1 and c2.
If they are functional equal, then why oracle guys create the two variables
u1 and u2? That is a waste of time then.
So I think it might be a bug.
But me myself know nothing about Georgian.
Is there anybody familiar with Georgian alphabet and willing to do further
debug about this?
question about org.apache.commons.collections.list.SetUniqueList
Lets see the codes.
/**
* Factory method to create a SetList using the supplied list to retain order.
*
* If the list contains duplicates, these are removed (first indexed one kept).
* A HashSet is used for the set behaviour.
*
* @param list the list to decorate, must not be null
* @throws IllegalArgumentException if list is null
*/
public static SetUniqueList decorate(List list) {
if (list == null) {
throw new IllegalArgumentException("List must not be null");
}
if (list.isEmpty()) {
return new SetUniqueList(list, new HashSet());
} else {
List temp = new ArrayList(list);
list.clear();
SetUniqueList sl = new SetUniqueList(list, new HashSet());
sl.addAll(temp);
return sl;
}
}
What confused me is that why we do not create a new List for empty List?
if (list.isEmpty()) {
return new SetUniqueList(list, new HashSet());
} else {
What is the reason for doing this?
