AIIY
You might want to check the documentation before you make such
statements:
http://developer.android.com/intl/de/reference/java/lang/String.html#String(byte[])
Do *NOT*, under *ANY* circumstance, omit that second argument.
Just because it works, TODAY, on YOUR device, does not make
Ah, yes. I see that I just happened to luck out, as the file.encoding
property on my device must be (currently!) set to utf-8.
Thanks.
This begs another, related question: how do I know what encoding to
use, in the first place ... for a TextView in the Android environment?
If I cannot count on
PS: I am writing Android-specific code. The class I am using will
never work outside of the Android environment, for reasons that go
beyond the issue of character encoding.
So does this mean that in my case, I _should_ do the moral equivalent
of this?
String content = new String(bytes,
02.12.2010 13:47, HippoMan пишет:
This begs another, related question: how do I know what encoding to
use, in the first place ... for a TextView in the Android environment?
You don't. This is not a TextView encoding issue.
TextView works with Java strings, which are always Unicode.
If I
02.12.2010 13:54, HippoMan пишет:
PS: I am writing Android-specific code. The class I am using will
never work outside of the Android environment, for reasons that go
beyond the issue of character encoding.
So does this mean that in my case, I _should_ do the moral equivalent
of this?
Yes. I should have written this after drinking my morning coffee. On
my way to work, I woke up a little and remembered that this encoding
pertains to the _source_ (in my case, the epub bundle) and not the
_destination_ (the TextView).
Luckily, I know something about the source: epubs are supposed
Yes. I should have written this after drinking my morning coffee. On
my way to work, I woke up a little and remembered that this encoding
pertains to the _source_ (in my case, the epub bundle) and not the
_destination_ (the TextView).
Luckily, I know something about the source: epubs are supposed
Thank you.
I have checked the items that I am displaying, and all of them contain
tags like this:
meta http-equiv=Content-Type content=text/html; charset=utf-8/
In every case, the charset is specified as utf-8 or UTF-8.
Apparently, this is not sufficient to cause the text to be interpreted
It would help if you were more specific about the problem.
1) What Unicode character code are you setting in the TextView that displays
as garbage?
2) What exactly does garbage mean, rectangles, or unexpected characters like
upside down question marks, etc?
3) Please post the code you are using
Thank you very much.
1) I am not explicitly setting any unicode character code in the
TextView. I display data that exists within e-books that are stored in
epub format. I do not alter this data at all. I display it as is. Most
of this displays OK, but quotes look like the following garbage ...
PS: I forgot to add that after I build this map, I just do the
following to display the text within my TextView:
// this.section is a String which holds the name of the
// ebook section that I want to view. It must be a key
// to the above-mentioned LinkedHashMap containing the
//
OK. I figured it out after thinking more about what you said in your
item 3. I need to convert the bytes that come out of the zip file into
correct unicode. I changed the method as follows, and now it renders
the characters properly:
private boolean readEpubFile() {
FileInputStream f
... but I should actually use a ByteArrayOutputStream to avoid
breaking up unicode characters that might span the 65536-byte boundary
of my input buffer:
private boolean readEpubFile() {
FileInputStream f= null;
ZipInputStream z= null;
byte
I should clarify that I now don't need to do this:
String content = new String(bytes, UTF-8);
This is because java's default is unicode. I get the same result with
or without the second argument to the String constructor.
I now see that my original error resulted because I was converting to
Thanks. I'll check the content variable later today or tomorrow and
post back here.
In the mean time, I'm wondering if perhaps this isn't a unicode issue,
after all. Upon closer examination, it seems that the only characters
that appear as garbage in the data I'm examining are quote characters
It is not anything specifically to do with Microsoft:.
http://en.wikipedia.org/wiki/Mojibake
Double quote marks and apostrophes are frequent offenders. This is
because ASCII contains only a single character for each, but different
characters are used for the start and end quote marks. Short and
16 matches
Mail list logo
