On 28.12.2004, at 18:53, Oliver Zeigermann wrote:
On Tue, 28 Dec 2004 15:01:08 +0000, Eirikur Hrafnsson <[EMAIL PROTECTED]> wrote:No but maybe my case is not that common. We are implementing our own Webdav "Explorer" in JSF (Java Server Faces/in page similar to the slide servlet but with features ;) within the same webapp running Slide so in our case the URIEncoding and Page encoding/System encoding is always the same.Of course I spoke to soon...
The problem with this setup is that you get mixed encodings. I want to
use ISO-8859-1 for the default system encoding
(-Dfile.encoding="ISO-8859-1") but I have to have the URLEncoding=UTF-8
setting in tomcat for Slide to work. Now when you ask the Request what
encoding it is using it will then tell it's using ISO-8859-1 when it
Hmmm, not quite sure if I understand this. What method are you using to query the request which URI encoding it is using? In my opinion and understanding of the HTTP protocol there is no way to tell except by convention. Are you sure you are not confusing this with the encoding of the text body?
Since our webdav "client" is querying the same server and encoding its own links it has to have the same URIEncoding as Slide. (And that would be UTF-8 since Slide only really supports UTF-8)
fact it is always decoding with UTF-8. Forms will then work ok (at least with POST) but links with special characters in the attributes (GET) will not since the attribute will be encoded in ISO but decoded in UTF-8.
So...with all my babble aside the ONLY solution is to set everything to
UTF-8, file.encoding, the page encoding (in html) and the tomcat
variable URIEncoding in server.xml.
I do not understand this probably because I am ignorant. Could you explain, please?
I tried using ISO-8859-1 for the default encoding and page encoding but request.getParameter(..) will always return the value utf-8 decoded because of the Tomcat parameter. I cannot in any way get the non-decoded parameter because the request does not offer me that.
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.
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?
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.
: ) hehe ok sorry,
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.
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).
This meaning:
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.
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. 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).
Cheers
Eirikur S. Hrafnsson, [EMAIL PROTECTED] Chief Software Engineer Idega Software http://www.idega.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
