Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/buf ByteChunk.java
And Craig thought it was a strange world when he contributed to j-t-c. ;-) - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 15, 2002 11:47 PM Subject: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/buf ByteChunk.java remm02/03/15 23:47:33 Modified:src/share/org/apache/tomcat/util/buf ByteChunk.java Log: - Port indexOf patch to 3.3. Feel free to -1. Revision ChangesPath -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/buf ByteChunk.java CharChunk.java
billbarker02/03/15 23:29:15 Modified:src/share/org/apache/tomcat/util/buf ByteChunk.java CharChunk.java Log: Porting fixes from j-t-c. Revision ChangesPath 1.10 +1 -1 jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java Index: ByteChunk.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- ByteChunk.java5 Feb 2002 22:06:18 - 1.9 +++ ByteChunk.java16 Mar 2002 07:29:15 - 1.10 @@ -403,8 +403,8 @@ System.arraycopy(buff, start, tmp, 0, end-start); buff = tmp; tmp = null; - start=0; end=end-start; + start=0; } // Conversion and getters 1.6 +1 -1 jakarta-tomcat/src/share/org/apache/tomcat/util/buf/CharChunk.java Index: CharChunk.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/buf/CharChunk.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- CharChunk.java5 Feb 2002 22:06:18 - 1.5 +++ CharChunk.java16 Mar 2002 07:29:15 - 1.6 @@ -431,8 +431,8 @@ System.arraycopy(buff, start, tmp, 0, end-start); buff = tmp; tmp = null; - start=0; end=end-start; + start=0; } // Conversion and getters -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/buf ByteChunk.java
remm02/03/15 23:47:33
Modified:src/share/org/apache/tomcat/util/buf ByteChunk.java
Log:
- Port indexOf patch to 3.3. Feel free to -1.
Revision ChangesPath
1.11 +7 -7
jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java
Index: ByteChunk.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ByteChunk.java16 Mar 2002 07:29:15 - 1.10
+++ ByteChunk.java16 Mar 2002 07:47:33 - 1.11
@@ -572,16 +572,16 @@
char first=src.charAt( srcOff );
// Look for first char
- int srcEnd=srcOff + srcLen;
-
- for( int i=myOff; i end - srcLen ; i++ ) {
+ int srcEnd = srcOff + srcLen;
+
+ for( int i=myOff+start; i = (end - srcLen); i++ ) {
if( buff[i] != first ) continue;
// found first char, now look for a match
- int myPos=i+1;
- for( int srcPos=srcOff; srcPos srcEnd; ) {
- if( buff[myPos++] != src.charAt( srcPos++ ))
+int myPos=i+1;
+ for( int srcPos=srcOff + 1; srcPos srcEnd; ) {
+if( buff[myPos++] != src.charAt( srcPos++ ))
break;
- if( srcPos==srcEnd ) return i; // found it
+if( srcPos==srcEnd ) return i-start; // found it
}
}
return -1;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/buf ByteChunk.java
i was looking at the diffs here because i was going to propagate this
change to jakarta-tomcat-connectors, but i'm no sure i understand this:
public int getOffset() {
- return getStart();
+ return getEnd();
}
perhaps i'm missing something, but it looks like the offset returned by
getOffset() should be the offset into the byte array contained in
ByteChunk, which would be the start position in this case, rather than
the end position.
also, if you look at the append() and equals() methods that take
ByteChunk's as arguments, if getOffset() returns the end position rather
than the start position, these methods won't work as intended. for
example, equals() will start comparing comparing bytes at the end of the
ByteChunk, rather than the start of it.
just a sanity check...
-kevin.
[EMAIL PROTECTED] wrote:
nacho 01/06/02 14:53:46
Modified:src/share/org/apache/tomcat/util/buf ByteChunk.java
Log:
Latest encoding fixes left some problems in the way.
Fixing a hack is a hazardous task..
Revision ChangesPath
1.5 +11 -10
jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java
Index: ByteChunk.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ByteChunk.java2001/05/27 23:16:19 1.4
+++ ByteChunk.java2001/06/02 21:53:46 1.5
@@ -208,12 +208,13 @@
public int getStart() {
return start;
}
-
+
public int getOffset() {
- return getStart();
+ return getEnd();
}
public void setOffset(int off) {
+if (end off ) end=off;
start=off;
}
@@ -263,7 +264,7 @@
{
append( (byte)c);
}
-
+
public void append( byte b )
throws IOException
{
@@ -275,13 +276,13 @@
}
buff[end++]=b;
}
-
+
public void append( ByteChunk src )
throws IOException
{
append( src.getBytes(), src.getOffset(), src.getLength());
}
-
+
/** Add data to the buffer
*/
public void append( byte src[], int off, int len )
@@ -297,7 +298,7 @@
end+=len;
return;
}
-
+
// if we have limit and we're below
if( len = limit - end ) {
// makeSpace will grow the buffer to the limit,
@@ -311,7 +312,7 @@
// buffer
// the buffer is already at ( or bigger than ) limit
-
+
// Optimization:
// If len-avail length ( i.e. after we fill the buffer with
// what we can, the remaining will fit in the buffer ) we'll just
@@ -327,12 +328,12 @@
int avail=limit-end;
System.arraycopy(src, off, buff, end, avail);
end += avail;
-
+
flushBuffer();
-
+
System.arraycopy(src, off+avail, buff, end, len - avail);
end+= len - avail;
-
+
} else {// len buf.length + avail
// long write - flush the buffer and write the rest
// directly from source
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/buf ByteChunk.java
perhaps i'm missing something, but it looks like the offset returned by getOffset() should be the offset into the byte array contained in ByteChunk, which would be the start position in this case, rather than the end position. From the point of view of the o.a.t.m.s.ajp13, now getOffset() has the correct behavior, at least now for me works, prior to that change ajp13 was unusable.., take a look in o.a.t.m.s.Ajp13.Ajp13Packet.appendString, There is some magic in the use of ob.setbyteOff and ob.getByteOff...as i understand this code.. ob.getByteOff is requiered to return the end of the last writed byte chunk ..perhaps a better aproach to this fix is to change ob.getOffset to use bb.getEnd instead os bb.getOffset..at least this will make the intention clearer.., in a really obscure code.. also, if you look at the append() and equals() methods that take ByteChunk's as arguments, if getOffset() returns the end position rather than the start position, these methods won't work as intended. for example, equals() will start comparing comparing bytes at the end of the ByteChunk, rather than the start of it. I reviewed it, and your are right for equals..but not for append..append is suppoused to use the end of the buffer not the start..so in append getOffset is suppoused to return end not the start... The better solution is to get rid of getOffset..and only use getStart or getEnd where needed... just a sanity check... Well done, OSS is great because of this comments..and the possibility to make them just-in-time..:))) -kevin. Saludos , Ignacio J. Ortega
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/buf ByteChunk.java
Ignacio J. Ortega wrote:
perhaps i'm missing something, but it looks like the offset
returned by
getOffset() should be the offset into the byte array contained in
ByteChunk, which would be the start position in this case, rather than
the end position.
From the point of view of the o.a.t.m.s.ajp13, now getOffset() has the
correct behavior, at least now for me works, prior to that change ajp13
was unusable.., take a look in o.a.t.m.s.Ajp13.Ajp13Packet.appendString,
There is some magic in the use of ob.setbyteOff and ob.getByteOff...as i
understand this code.. ob.getByteOff is requiered to return the end of
the last writed byte chunk ..perhaps a better aproach to this fix is to
change ob.getOffset to use bb.getEnd instead os bb.getOffset..at least
this will make the intention clearer.., in a really obscure code..
i see... kind of makes my head hurt :) i think you're probably right
about changing OutputBuffer.getOffset() -- i would make things clearer.
also, if you look at the append() and equals() methods that take
ByteChunk's as arguments, if getOffset() returns the end
position rather
than the start position, these methods won't work as intended. for
example, equals() will start comparing comparing bytes at the
end of the
ByteChunk, rather than the start of it.
I reviewed it, and your are right for equals..but not for append..append
is suppoused to use the end of the buffer not the start..so in append
getOffset is suppoused to return end not the start...
are you sure? here's the code i was looking at:
code snip
public void append( ByteChunk src )
throws IOException
{
append( src.getBytes(), src.getOffset(), src.getLength());
}
/** Add data to the buffer
*/
public void append( byte src[], int off, int len )
throws IOException
{
// will grow, up to limit
makeSpace( len );
// if we don't have limit: makeSpace can grow as it wants
if( limit 0 ) {
// assert: makeSpace made enough space
System.arraycopy( src, off, buff, end, len );
end+=len;
return;
}
// if we have limit and we're below
if( len = limit - end ) {
// makeSpace will grow the buffer to the limit,
// so we have space
System.arraycopy( src, off, buff, end, len );
end+=len;
return;
}
end code snip
it looks like when you call append(ByteChunk), the result will be an
IndexOutOfBoundsException. in fact, this code proves that:
public void testByteChunk() throws Exception {
System.out.println(testByteChunk);
byte[] b1 = new String(bytes1).getBytes();
byte[] b2 = new String(bytes2).getBytes();
ByteChunk bc1 = new ByteChunk();
ByteChunk bc2 = new ByteChunk();
bc1.setBytes(b1, 0, b1.length);
bc2.setBytes(b2, 0, b2.length);
String s1 = bc1.toString();
String s2 = bc2.toString();
System.out.println(s1 = + s1);
System.out.println(s2 = + s2);
bc1.append(bc2);
s1 = bc1.toString();
System.out.println(s1 = + s1);
}
i believe the solution here would be to have append(ByteChunk) look like
this:
public void append( ByteChunk src )
throws IOException
{
append( src.getBytes(), src.getStart(), src.getLength());
}
The better solution is to get rid of getOffset..and only use getStart or
getEnd where needed...
just a sanity check...
Well done, OSS is great because of this comments..and the possibility to
make them just-in-time..:)))
-kevin.
Saludos ,
Ignacio J. Ortega
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/buf ByteChunk.java
I reviewed it, and your are right for equals..but not for append..append is suppoused to use the end of the buffer not the start..so in append getOffset is suppoused to return end not the start... This is not true...append needs getStart too...finally i will make this changes: 1) use bb.getEnd in ob.getOffset as it seems this is the intention explained in the comment , to track the next free byte ( or the last writed byte as is used ) 2) use getStart instead of getOffset inside bb to make things a bit clearer.. I think this is the correct change..it works and pass tests .. ( you take me be storm just writing this message when received yours :)) thanks Saludos , Ignacio J. Ortega
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/buf ByteChunk.java
nacho 01/06/03 13:16:46
Modified:src/share/org/apache/tomcat/core OutputBuffer.java
src/share/org/apache/tomcat/util/buf ByteChunk.java
Log:
* Fix for ob.getByteOff hack...and reverting previous fix..
* Use getStart where needed on bb intead of getOffset, a bit clearer.
Submitted by: Kevin Seguin
Revision ChangesPath
1.18 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/core/OutputBuffer.java
Index: OutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/OutputBuffer.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- OutputBuffer.java 2001/05/26 17:46:46 1.17
+++ OutputBuffer.java 2001/06/03 20:16:46 1.18
@@ -148,7 +148,7 @@
* @deprecated Used only in Ajp13Packet for a hack
*/
public int getByteOff() {
- return bb.getOffset();
+ return bb.getEnd();
}
/** Set the write position in the byte buffer
1.6 +4 -4
jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java
Index: ByteChunk.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ByteChunk.java2001/06/02 21:53:46 1.5
+++ ByteChunk.java2001/06/03 20:16:46 1.6
@@ -210,7 +210,7 @@
}
public int getOffset() {
- return getEnd();
+ return getStart();
}
public void setOffset(int off) {
@@ -280,7 +280,7 @@
public void append( ByteChunk src )
throws IOException
{
- append( src.getBytes(), src.getOffset(), src.getLength());
+ append( src.getBytes(), src.getStart(), src.getLength());
}
/** Add data to the buffer
@@ -479,7 +479,7 @@
}
public boolean equals( ByteChunk bb ) {
- return equals( bb.getBytes(), bb.getOffset(), bb.getLength());
+ return equals( bb.getBytes(), bb.getStart(), bb.getLength());
}
public boolean equals( byte b2[], int off2, int len2) {
@@ -501,7 +501,7 @@
}
public boolean equals( CharChunk cc ) {
- return equals( cc.getChars(), cc.getOffset(), cc.getLength());
+ return equals( cc.getChars(), cc.getStart(), cc.getLength());
}
public boolean equals( char c2[], int off2, int len2) {
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/buf ByteChunk.java
nacho 01/06/02 14:53:46
Modified:src/share/org/apache/tomcat/util/buf ByteChunk.java
Log:
Latest encoding fixes left some problems in the way.
Fixing a hack is a hazardous task..
Revision ChangesPath
1.5 +11 -10
jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java
Index: ByteChunk.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ByteChunk.java2001/05/27 23:16:19 1.4
+++ ByteChunk.java2001/06/02 21:53:46 1.5
@@ -208,12 +208,13 @@
public int getStart() {
return start;
}
-
+
public int getOffset() {
- return getStart();
+ return getEnd();
}
public void setOffset(int off) {
+if (end off ) end=off;
start=off;
}
@@ -263,7 +264,7 @@
{
append( (byte)c);
}
-
+
public void append( byte b )
throws IOException
{
@@ -275,13 +276,13 @@
}
buff[end++]=b;
}
-
+
public void append( ByteChunk src )
throws IOException
{
append( src.getBytes(), src.getOffset(), src.getLength());
}
-
+
/** Add data to the buffer
*/
public void append( byte src[], int off, int len )
@@ -297,7 +298,7 @@
end+=len;
return;
}
-
+
// if we have limit and we're below
if( len = limit - end ) {
// makeSpace will grow the buffer to the limit,
@@ -311,7 +312,7 @@
// buffer
// the buffer is already at ( or bigger than ) limit
-
+
// Optimization:
// If len-avail length ( i.e. after we fill the buffer with
// what we can, the remaining will fit in the buffer ) we'll just
@@ -327,12 +328,12 @@
int avail=limit-end;
System.arraycopy(src, off, buff, end, avail);
end += avail;
-
+
flushBuffer();
-
+
System.arraycopy(src, off+avail, buff, end, len - avail);
end+= len - avail;
-
+
} else {// len buf.length + avail
// long write - flush the buffer and write the rest
// directly from source
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/buf ByteChunk.java CharChunk.java
costin 01/05/26 10:17:02
Modified:src/share/org/apache/tomcat/util/buf ByteChunk.java
CharChunk.java
Log:
Merged the resizable and flush-able buffer code from OutputBuffer.
Now the CharChunk and ByteChunk can be used as general-purpose buffers
( instead of StringBuffer for example ) - i.e. both input and output.
Most of the code is old and well tested ( has been part of OutputBuffer for
a while ), we just moved it here to be of more use.
We preserved all the old API, except for url decoding ( which has been
almost completely rewritten ).
Some methods are now deprecated and could be removed ( we haven't frozen the
API - if we ship 3.3 with those in it'll be hard to remove later ).
The caching of header conversion result should be part of MimeHeaders, and
not affect the buffers.
Revision ChangesPath
1.3 +313 -220
jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java
Index: ByteChunk.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ByteChunk.java2001/03/10 18:18:43 1.2
+++ ByteChunk.java2001/05/26 17:17:01 1.3
@@ -62,11 +62,9 @@
import java.text.*;
import java.util.*;
import java.io.Serializable;
+import java.io.IOException;
-/**
- * This class is used to represent a chunk of bytes, and
- * utilities to manipulate byte[].
- *
+/*
* In a server it is very important to be able to operate on
* the original byte[] without converting everything to chars.
* Some protocols are ASCII only, and some allow different
@@ -78,26 +76,60 @@
* For HTTP it is not very clear how the encoding of RequestURI
* and mime values can be determined, but it is a great advantage
* to be able to parse the request without converting to string.
+ */
+
+
+/**
+ * This class is used to represent a chunk of bytes, and
+ * utilities to manipulate byte[].
+ *
+ * The buffer can be modified and used for both input and output.
*
* @author [EMAIL PROTECTED]
* @author James Todd [[EMAIL PROTECTED]]
* @author Costin Manolache
*/
public final class ByteChunk implements Cloneable, Serializable {
+// Output interface, used when the buffer is filled.
+public static interface ByteOutputChannel {
+ /** Send the bytes ( usually the internal conversion buffer ).
+ * Expect 8k output if the buffer is full.
+ */
+ public void realWriteBytes( byte cbuf[], int off, int len)
+ throws IOException;
+}
+
+//
+
// byte[]
-private byte[] bytes;
-private int bytesOff;
-private int bytesLen;
+private byte[] buff;
+
+private int start=0;
+private int end;
+
private String enc;
-private boolean isSet=false;
+
+private boolean isSet=false; // XXX
+
+// How much can it grow, when data is added
+private int limit=-1;
+
+private ByteOutputChannel out=null;
+
+private boolean isOutput=false;
/**
* Creates a new, uninitialized ByteChunk object.
*/
public ByteChunk() {
}
+
+public ByteChunk( int initial ) {
+ allocate( initial, -1 );
+}
-public ByteChunk getClone() {
+//
+public ByteChunk getClone() {
try {
return (ByteChunk)this.clone();
} catch( Exception ex) {
@@ -106,18 +138,37 @@
}
public boolean isNull() {
- return ! isSet; // bytes==null;
+ return ! isSet; // buff==null;
}
/**
- * Resets the message bytes to an uninitialized state.
+ * Resets the message buff to an uninitialized state.
*/
public void recycle() {
- bytes = null;
+ // buff = null;
enc=null;
+ start=0;
+ end=0;
isSet=false;
}
+public void reset() {
+ buff=null;
+}
+
+// Setup
+
+public void allocate( int initial, int limit ) {
+ isOutput=true;
+ if( buff==null || buff.length initial ) {
+ buff=new byte[initial];
+ }
+ this.limit=limit;
+ start=0;
+ end=0;
+ isSet=true;
+}
+
/**
* Sets the message bytes to the specified subarray of bytes.
*
@@ -126,9 +177,9 @@
* @param len the length of the bytes
*/
public void setBytes(byte[] b, int off, int len) {
- bytes = b;
- bytesOff = off;
- bytesLen = len;
+ buff = b;
+ start = off;
+ end = start+ len;
isSet=true;
}
@@ -136,158 +187,249 @@
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/buf ByteChunk.java
costin 01/03/10 10:18:43
Modified:src/share/org/apache/tomcat/util/buf ByteChunk.java
Log:
First attempt to fix the UTF decoding bug.
This doesn't change the behavior - what worked before should work the
same ( i.e. bytes0x80 ). For chars 0x80 ( that didn't worked with
the previous code ) I cutpasted code from xerces.
The idea is to avoid using the (memory expensive) String( bytes[] ),
which proved to be a performance problem in many cases.
Xerces is doing exactly the same thing to optimize the conversion.
This works for UTF8 - for all other encodings the slow method is used.
There is another way to resolve the problem ( a trick similar with
OutputBuffer ), and we may implement it someday, but the hope is that
people will start using unicode as a clean and simple solution for
non-ascii charsets.
Netscape and IIS and most platforms already support UTF. ( that doesn't mean
we shouldn't deal with the other encodings )
( the code is untested - I need UTF examples, adding files in
various encoding with "strange" names to the test suite is still on the
todo list )
Revision ChangesPath
1.2 +85 -4
jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java
Index: ByteChunk.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ByteChunk.java2001/02/20 03:12:13 1.1
+++ ByteChunk.java2001/03/10 18:18:43 1.2
@@ -174,13 +174,94 @@
conversionBuff=new char[bytesLen];
}
+ // int j=bytesOff;
+ // for( int i=0; i bytesLen; i++ ) {
+ // conversionBuff[i]=(char)bytes[j++];
+ // }
+ int charsLen=byte2charUTF8();
+ if( charsLen==-1) return null; // or throw exception
+
+ return new String( conversionBuff, 0, charsLen);
+}
+
+
+private int byte2charUTF8() {
+ if( conversionBuff==null || bytesLen conversionBuff.length ) {
+ conversionBuff=new char[bytesLen];
+ }
+ // source: xerces' UTF8Reader.copyMultiByteCharData()
int j=bytesOff;
- for( int i=0; i bytesLen; i++ ) {
- conversionBuff[i]=(char)bytes[j++];
+ int charOff=0;
+ int end=j+bytesLen;
+ while( j end ) {
+ int b0=(int)bytes[j];
+
+ if( b0 0x80 ) {
+ conversionBuff[charOff]=(char)b0;
+ charOff++;
+ j++;
+ continue;
+ }
+ // 2 byte ?
+ if( j++ = end ) {
+ // ok, just ignore - we could throw exception
+ return -1;
+ }
+ int b1=(int)bytes[j];
+
+ // ok, let's the fun begin - we're handling UTF8
+ if ((0xe0 b0) == 0xc0) { // 110y 10xx (0x80 to 0x7ff)
+ int ch = ((0x1f b0)6) + (0x3f b1);
+ conversionBuff[charOff]=(char)ch;
+ charOff++;
+ continue;
+ }
+
+ if( j++ = end )
+ return -1;
+ int b2=(int)bytes[j];
+
+ if( (b0 0xf0 ) == 0xe0 ) {
+ if ((b0 == 0xED b1 = 0xA0) ||
+ (b0 == 0xEF b1 == 0xBF b2 = 0xBE)) {
+ return -1;
+ }
+
+ int ch = ((0x0f b0)12) + ((0x3f b1)6) + (0x3f b2);
+ conversionBuff[charOff]=(char)ch;
+ charOff++;
+ continue;
+ }
+
+ if( j++ = end )
+ return -1;
+ int b3=(int)bytes[j];
+
+ if (( 0xf8 b0 ) == 0xf0 ) {
+ if (b0 0xF4 || (b0 == 0xF4 b1 = 0x90))
+ return -1;
+ int ch = ((0x0f b0)18) + ((0x3f b1)12) +
+ ((0x3f b2)6) + (0x3f b3);
+
+ if (ch 0x1) {
+ conversionBuff[charOff]=(char)ch;
+ charOff++;
+ } else {
+ conversionBuff[charOff]=(char)(((ch-0x0001)10)+
+0xd800);
+ charOff++;
+ conversionBuff[charOff]=(char)(((ch-0x0001)0x3ff)+
+0xdc00);
+ charOff++;
+ }
+ continue;
+ } else {
+ return -1;
+ }
}
- return new String( conversionBuff, 0, bytesLen);
+ return charOff;
}
-
+
public int getInt()
{
return Ascii.parseInt(bytes, bytesOff,bytesLen);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
