All text values, and all fields (which are text only), contain only 8 bit characters, null terminated if less than the maximum length for the field. The character encoding is 8 bit US ASCII.
Originally posted by Richard Jackson:
In DataInput interface, there are writeUTF(String str) and writeBytes(String s) methods.
There is a sentence in instructions.html,
According to request of instructions,which one is more appropriate to write String into file?
It looks simple but I have been confused for a long time.Please comment and clarify!
The character encoding is 8 bit US ASCII.
Originally posted by Ed Green:
I'm currently not specifying a char set on the way in or out, and don't seem to be experiencing any problems..
Originally posted by Michal Charemza:
Firstly, have you thought about coverting to a Sring and then using trim() and indexOf() to remove spaces and find the zero delimeter? This may result in cleaner code - although I'm not sure about the efficiency. I think I will use the String methods in mine as it is cleaner, and it is not "re-inventing the wheel".
Also, according to the Charset api, the ISO-8859-1 charset must be supported by every implementation of the Java platform. Does that mean that the UnsupportedEncodingException should never be thrown?
Perhaps an assert(false) is good here instead. I'm not really sure about assertions though, beyond what was required for the programmer exam.
Does anyone think that putting an "assert(false)" is a bad idea in a catch clause? I know I just suggested it, but the assertion and exception together do seem a bit pointless somehow: the exception is supposed to do things in case things go wrong, but the assert(false) in there means that things should never go wrong.
[ September 02, 2004: Message edited by: Michal Charemza ][/QB]
Originally posted by peter wooster:
Assertions ... meant to be caught during testing, since they are not enabled in production use.