This post is more than 5 years old
11 Posts
0
2677
XString: problems with nouns? (like ä,ö,ü)
Hello experts,
we succesfully implemented an interface to an EMC Centera system via XAM. We use the .NET Wrapper Version (1.0.57) and our cluster has CentraStar 4.2.0-3881-0-0 installed. So far so good.
I tested different documents, everything worked fine. But then, depending on the document type I wanted to store on the system, I received an exception. Well not really, becaus the errorToken of the exception was always NULL, so I had no clue what was going wrong. The error only occured when loading a file, it seemed that I always could save the file and I also received a valid XUID (see attachment "save.png").
After some "try and error" I finally found (a bug?): I'm saving various metadata in my xSet, one is the title of the document:
xSet.CreateField(FIELDNAME_TITLE, rowDOK.Titel); |
I found out, as soon as my document title contains nouns like ä,ö,ü the system fails to load the file (is it a serializing / encoding) problem? Could you please verify my problem and tell me, if I have to encode or do "something special" myself or if it's a problem in the API/VIM?
Any help would be appreciated,
best regards
Ivan Schnyder
DmitriKuznetsoi
14 Posts
0
November 27th, 2011 23:00
OK, I see.
Anyway I tried different aproaches, so far what has worked:
Using bytearray with CreateXStream worked perfectly! I was able to read and write back unicode text as bytes array without any issues. This does mean I have to revert to using only XStream instead of XString
Encoding string with base64 and using this for XString values. Worked perfectly here also (except when encoding Unicode UTF16 string it causes the actual text to be 2 times larger than usual, This can be countered with applying GZipStream afterwards, but I really don't want to go that far, just to be able to store a simple string )
DmitriKuznetsoi
14 Posts
0
November 24th, 2011 02:00
Hi, I have been checking this out, old post, I know, but it seems there is a problem here.
In XAM documentation it is specified that field name should be of type:
Now I made a simple test case with .NET XAM wrapper to see if this is the case:
P.S. Your formatting code is really broken.
I am using my own wrappers on top of this, but basically it calls:
XAM_CreateString
ivan_schnyder
11 Posts
0
November 24th, 2011 03:00
Thanks Dmitri for your response!
It's still a problem and we haven't found a solution yet. But just to clarify: the problem is not special characters in the fieldname, I get my error when I'm using special characteres in the fieldcontent.
Something like this (adapted to your code):
String stringValue1 = "äöüaaääöö"
String fieldName = "Title";
writer.WriteFieldValue(fieldName, stringValue1);
Does this work for you? I can save such content, but when I want to load:
String field1 = writer.GetFieldValue(fieldName);
I get an exception...
Thanks, best regards
Ivan
DmitriKuznetsoi
14 Posts
0
November 24th, 2011 04:00
Message was edited by: DmitriKuznetsoiv
ivan_schnyder
11 Posts
0
November 24th, 2011 05:00
Could you send me a set of your versions? I'm working with (64bit):
Centera VIM: 1.0.57
XAMSDK.dll: 1.0.0.0
FPCore.dll: 4.0.660.0
fpos64.dll: 3.2.281.0
fpparser64.dll: 3.2.48.0
FPStreams64:4.0.660.0
FPUtils64.dll: 4.0.660.0
FPXML64.dll: 4.0.660.0
Thanks
DmitriKuznetsoi
14 Posts
0
November 24th, 2011 05:00
My versions are:
Centera VIM: 1.0.103.0
XAMSDK.dll: 1.0.0.0
FPCore.dll: 4.0.698.0
fpos64.dll: 3.2.281.0
fpparser.dll: 3.2.48.0
FPStreams:4.0.698.0
FPUtils.dll: 4.0.698.0
FPXML.dll: 4.0.698.0
I think I am using 32 bit versions here...
ivan_schnyder
11 Posts
0
November 24th, 2011 06:00
Thanks,
so I updated all my dll to the latest (EMC Centera SDK for XAM 1.0 Patch 3 for Windows (32-bit and 64-bit and EMC Centera SDK for XAM VIM 1.0 Patch) - my VIM Version is now 1.0.115 but still the same error...
ivan_schnyder
11 Posts
0
November 28th, 2011 01:00
Thank you so much Dmitri!
Your hints took me to the solution: I tried the workaround with the XStream. It didn't work till I set the encoding on the array to UTF32. So after it finally worked with the XStream, I wrote myself two little methods and I can know succesfully write / read a normal "field" with the following code:
// Write
xSet.CreateField(FIELDNAME_TITLE, EncodeToBase64("äöüéàa"))
// Read
xSet.GetField(FIELDNAME_FILETYPE, xStringFieldContent);
string strField = DecodeFromBase64(xStringFieldContent);
// Methods
private string EncodeToBase64(string strToEncode)
{
byte[] toEncodeAsBytes = UTF32Encoding.Default.GetBytes(strToEncode);
return Convert.ToBase64String(toEncodeAsBytes);
}
private string DecodeFromBase64(string strEncodedData)
{
byte[] encodedDataAsBytes = Convert.FromBase64String(strEncodedData);
return UTF32Encoding.Default.GetString(encodedDataAsBytes);
}
Best regards and thank you one more time to analyse my problem!
Ivan
DmitriKuznetsoi
14 Posts
0
November 28th, 2011 02:00
Sure, that's good that it worked for you.
I see in this example you are using UTF32, but why ? AFAIK C# strings are UTF16, UTF32 doesn't add anything and just wastes space, you can even use UTF8 for this purpose which should work for most possible cases (and usually less space is needed for storage). And I proposed 2 solutions either base64 or XStream, you don't need to use both of them at the same time, just either one of them is enough.
For my solution I went with XStream and UTF16 encoded strings (just for the reason to avoid problems when using XString encoded in Base64 limit of 512 bytes, which means 256 characters for UTF16 and 128 for UTF32 in this case, XStream doesn't have this limit)
ivan_schnyder
11 Posts
0
November 28th, 2011 02:00
Hi Dmitri
you're absolutly right what concerns strings in c#, they are UTF16 by default, so UTF32 doesn't make any sense at all. But you also wrote:
And I proposed 2 solutions either base64 or XStream, you don't need to use both of them at the same time, just either one of them is enough.
I don't get that one, in my final solution I'm using this method:
xSet.CreateField(FIELDNAME_TITLE, "äöüéàa") // second parameter is type of XString,
So right know I'm just using the method with XString but before I pass the XString, I encode it to a base64 string, I'm not using the XStream method anymore? Maybe my last answer wasn't clear enough.
Best regards
DmitriKuznetsoi
14 Posts
0
November 28th, 2011 02:00
Ok, I got a little confused because you mentioned that you were using XStream, but couldn't find it in your example. I guess you are using only XString right now ?