Hello, again!
> >I created excel file with proper russian simbols, try to read it through
the
> >models and pay attention to the 16bit string in SST. So I suspected that
MS
> >Excel stores russian sibols as Unicode.
> >I have found that org.apache.poi.hssf.model.Workbook has method stub:
> > public int addSSTString(String string) {
> > return addSSTString(string, false);
> > }
> >I tried to change it to
> > public int addSSTString(String string) {
> > return addSSTString(string, true);
> > }
> >And... it worked. :)
> >But only for the SST records. The sheet name was still not encoded to
> >russian properly (not Unicode, I suppose).
> >
> >
> So it looks like auto detection (which used to work) does not work any
> longer.
I looked at autodetection, as I see it works properly
(the part, where the String is checked for including symbols with code >
255),
but the problem with Russian, that Russian encodings use codes with code >
127, so this autocheck do not detect the code.
In CP1251 russian character has codes range (197 - 255), in CP886 the codes
range is not solid and starts with 128 code.
With cells encoding it is my misreading of the manual and code. Sorry.
I have founded that setting encoding for the cells works pretty well:
hssfCell.setEncoding( HSSFCell.ENCODING_UTF_16 );
hssfCell.setCellValue( cellValue );
And here it is!
Thank you for the help. :)
> Can you supply a patch which:
> 1. allows you to add strings and define them as unicode
> 2. maintains your abillity to encode in non-unicode.
So this kind of path is not needed - nothing to patch.
> >Also while reading the file I saw that sheet name unicode support is
absent?
> >( "HSSF ����" it has read as "H S S F ", but "����" it converted to
> >""5" ).
> >
> >So, is it supported to make 16bit (Unicode) every string entry of the
excel
> >file (inculding sheet name, etc...) ?
> >
> I believe so. We don't yet support 16-bit unicode strings for sheet
> names. If someone supplies a patch for this
> I will gladly apply it.
I tried to do it, but with no results, yet. :( I was confused understanding
how the strings are serialized and deserialized. Could you tell or point me
at the place (or chunk of code) where it is described and coded.
> We should:
>
> 1. Allow you to define that you wish to write in Unicode
> 2. Upon reading use unicode if the unicode flag is set.
Understand, thanks.
> >Sincerely yours, Sergei Kozello.
> >
> >PS: while building the jakarta-poi-1.8.0-dev I found that
> >org.apache.poi.hssf.record.TestSSTRecord has a failure. Is it OK?
> >
> I would suppose not. Can you provide more information? Which test?
> Any exception info
> printed?
Sure, I found it while looking at the jUnit reports, here it is from the
jUnit testcases (building info):
Running org.apache.poi.hssf.record.TestSSTRecord
Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 5,879 sec
TEST org.apache.poi.hssf.record.TestSSTRecord FAILED
PS: while building I encoutered the build error:
in org.apache.poi.hssf.contrib.view.SViewerPanel
line 87: SVTableCellRenderer rnd = new SVTableCellRenderer(wb);
but the class org.apache.poi.hssf.contrib.view.SVTableCellRenderer has only
one constructor:
public SVTableCellRenderer(HSSFWorkbook wb, HSSFSheet st)
{...}
and no public SVTableCellRenderer( HSSFWorkbook wb ) {...}
so build failed. :(
