Am Mittwoch den, 6. M�rz 2002, um 14:50, schrieb Pill, Juergen:
> Hello Stefan, > > You are totally right! Neither the server nor the client can > guess, what the > encoding is the other is talking. Definitely UTF-8 would make life more > easy, if only all (or at least the most important once speak UTF-8). > Unfortunately WebFolders does not and IE can be put into a mode to talk > platform specific encoding. This was the reason why we made the > server use a > configurable encoding. If the clients are MS centric use platform > specific > encoding, else use UTF-8. Currently, until MS will use UTF-8 in > WebFolders > too. Slide/Tomcat should nevertheless default to UTF-8. The new versions of WebFolder available with MS Sharepoint, do use UTF-8 as encoding and defaulting to any other encoding than UTF-8 will fail. A MS SharePoint Server in a international company has exactly the same problem. That's why MS is interested in pushing a fixed WebFolder client out (if it is not in XP yet). Detection of non UTF-8 is acutally quite good. Someone wrote a statistical analysis and the odds are ok. I don't have that link handy right now... //Stefan > We tested Japanese clients with Japanese servers (same for > German). If you > try to access a Japanese server with a German client this will > fail (due to > different used encodings). > > Best regards > > Juergen > > > -----Original Message----- > From: Stefan Eissing [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 06, 2002 11.54 AM > To: Slide Users Mailing List > Subject: Re: Special letters > > J�rgen, > > have a look at > > http://www.w3.org/International/O-URL-and-ident.html > > for a recommendation about defaults in uri character > encodings. > > Am Mittwoch den, 6. M�rz 2002, um 11:30, schrieb Pill, Juergen: > >> Hello, >> >> The client will send a URI encoded in a specific encoding. This >> encoding may >> vary from client to client, e.g. IE send UTF-8, WebFolders send a >> platform >> specific encoding (in US and Germany this is ISO...) at least on >> Windows >> 2000. > true. > >> The server will accept encoded URLs based on a default encoding >> (defaultEncoding = new >> java.io.InputStreamReader(System.in).getEncoding()) >> or to be set in slide.properties >> (org.apache.slide.urlEncoding=xxxxxx). > This is no good. How should a client guess what encoding the server > uses? > The only interoperable way is to have a standard encoding, namely > UTF-8. > >> The client and server encoding must be identical, when the >> character set >> extends US-ASCII. Unfortunately most (all?) clients do not send >> infos about >> the used encoding when the URL was encoded. This lets the server >> to guess or >> make the accepted encoding to be set via a parameter. (does >> someone know an >> algorithm to decide from an encoded URL the used encoding?) > How should a client announce the encoding used? The "charset" parameter > in tomcat is proprietary, AFAIK. I'd be interested why tomcat went the > charset=xxx way in URIs instead of following W3C recommendations. > > The algorithm is to look if the octets are valid UTF-8 (pretty > easy) and > if not, fall back to, well, 8859-1, I'd assume as the most commonly > used _other_ encoding. A server could have setup parameters for the > fallback > encoding(s). > >> With above changes we got Japanese and German characters to work >> properly. > If the server is installed on a german windows? > >> >> Best regards, >> >> Juergen >> >> >> >> >> -----Original Message----- >> From: Stefan Eissing [mailto:[EMAIL PROTECTED]] >> Sent: Tuesday, March 05, 2002 17.47 PM >> To: Slide Users Mailing List >> Subject: Re: Special letters >> >> Well, depending on which client is making the request on Windows >> (webfolder, IE or Office), it uses utf-8 or (on my german win2k >> installation) 8859-1 as character encoding for uris. >> >> A server can try to fallback to 8859-1 if the uri does not >> look like valid utf-8... >> >> The best test case is still the euro sign. >> >> Am Dienstag den, 5. M�rz 2002, um 17:32, schrieb Remy Maucherat: >> >>>> This sounds like Slide/Tomcat is not defaulting to UTF-8 encoded >>>> URIs. >>> >>> I am think it does. I've had a lot more success with TeamDrive, >>> or when >>> using an HTTP browser to access the server, so it may be i18n >>> problems with >>> the current MS client. >>> (I'm not sure 100% about that; it's just my current theory) >>> >>> Remy >>> >>> >>> -- >>> To unsubscribe, e-mail: <mailto:slide-user- >>> [EMAIL PROTECTED]> >>> For additional commands, e-mail: <mailto:slide-user- >>> [EMAIL PROTECTED]> >>> >> >> >> >> >> -- >> To unsubscribe, e-mail: <mailto:slide-user- >> [EMAIL PROTECTED]> >> For additional commands, e-mail: <mailto:slide-user- >> [EMAIL PROTECTED]> >> >> -- >> To unsubscribe, e-mail: <mailto:slide-user- >> [EMAIL PROTECTED]> >> For additional commands, e-mail: <mailto:slide-user- >> [EMAIL PROTECTED]> >> > > > > > -- > To unsubscribe, e-mail: <mailto:slide-user- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:slide-user- > [EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:slide-user- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:slide-user- > [EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
