On Tue, 28 Dec 2004 19:23:15 +0000, Eirikur Hrafnsson <[EMAIL PROTECTED]> wrote: > On 28.12.2004, at 18:53, Oliver Zeigermann wrote: > > On Tue, 28 Dec 2004 15:01:08 +0000, Eirikur Hrafnsson <[EMAIL PROTECTED]> > > wrote: > >> Fortunately, at least with Oracle and the thin driver, that works with > >> an ISO-8859-1 database since that encoding is a "subset" of UTF-8 and > >> has a 1-1 mapping in UTF-8. > >> However this makes Slide unusable with other "stranger" encodings such > >> as Russian UNLESS you have a unicode database. > > > > Yes, if you want to store unicode into you database the database will > > have to support it, right? > Yes of course but I don't want to store unicode in our case because we > are trying to add Slide to already running webapps that were created on > non-unicode databases. > I don't want for this project to have both Russian and Icelandic in the > same page, sorry for that misunderstanding. I know you need an unicode > database to do that and we have done that already. > Our problem only arose because the existing database was ISO-8859 > encoded.
No idea how to solve this. If your database has ISO-8859-1 (is it 1?) encoding you simply can not store Russian into it. A solution would be not to encode anything in the database, but leave it as bytes. Of course you can not search meaningful then... > > > >> I looked at the patch that Thomas put in Bugzilla and it looks like it > >> could work but I think the FAQ or the Wiki should contain clear > >> instructions on how to use Slide in a non UTF-8 environment. > > > > Still unclear to me what is a non UTF-8 environment. > : ) hehe ok sorry, > Non UTF-8 environment would be e.g. a Tomcat server that for some > reason has to be run in an ISO encoding. One reason is like in our case > that the existing DB is in ISO format and the JDBC driver might not be > able to convert UTF-8 to the encoding being used in the DB when we want > to save something (other than Slide stuff). Are you talking about content or URIs now? If things work alright, the URI should be a string and then there is no decoding/encoding issue any more. Content should be BLOBs anyhow... > > > >> Thanks for all the help guys, hope this will be resolved in the next > >> minor version. > > > > Could you clarify what "this" means in this context. > This meaning: > That Slide could run without having to use UTF-8 for the encoding. The > putMethod today will assume we are using utf-8 or the system default. PutMethod of the server? > However the WebDavResource will always use the clients system encoding > and there is no detection of the URLEncoding in the putMethod and > therefor the URI_STRING saved to the database is gibberish. (I > explained this in much more detail in a previous email). So it's a client issue? Can you propose a patch that allows to set how to encode the request URI? Maybe I am just no smart enough to help, sorry... Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
