19 Apr
2010
19 Apr
'10
12:03 p.m.
I just recently discovered that actual browsers are displaying utf-8 safe url encodet URL
paths as the right characters. Meaning
http://en.wikipedia.org/wiki/Gew%C3%BCrztraminer
actually displays
http://en.wikipedia.org/wiki/Gewürztraminer
As far as I can see in pier the URL path is tightly coupled to the name of a structure.
And structure names are restricted to only a few characters. The comments in the code
reason this for safe usage in some object protocols. What would be the way to go if I want
to enable those types of URLs? What are the problematic cases if a structure name could
consist of non-7bit characters?
thanks,
Norbert
19 Apr
19 Apr
7:49 p.m.
2010/4/19 Norbert Hartl <norbert(a)hartl.name>me>:
I just recently discovered that actual browsers are
displaying utf-8 safe url encodet URL paths as the right characters. Meaning
http://en.wikipedia.org/wiki/Gew%C3%BCrztraminer
actually displays
http://en.wikipedia.org/wiki/Gewürztraminer
Nice, isn't it?
As far as I can see in pier the URL path is tightly
coupled to the name of a structure. And structure names are restricted to only a few
characters. The comments in the code reason this for safe usage in some object protocols.
What would be the way to go if I want to enable those types of URLs? What are the
problematic cases if a structure name could consist of non-7bit characters?
The following comes to my mind:
- If you post the second link with umlauts, if might cause problems if
the server is not in utf-8, ie5 or some non-modern browser user agent.
- If you use WAKomEncoded(39) (which you should) and go beyond Latin-1
(e.g. €) you enter the wonderful world of WideStrings.
- There might round trip problems with external systems (files, databases, ...)
I summary you might run into bugs, but then again someone has to in
order to get them fixed.
Cheers
Philippe
7:53 p.m.
In Sophie the URI subsystem was *fixed* to ensure the path data was UTF-8 and HTTP
correct.
However what we found (a couple of years back) was that different browsers had different
opinions about
what to do for every UTF-8 character. At the time we decided the differences were bugs,
hopefully they have
been fixed now since I recall you can? now have domains with UTF-8 characters.
On 2010-04-19, at 10:49 AM, Philippe Marschall wrote:
2010/4/19 Norbert Hartl <norbert(a)hartl.name>me>:
--
===========================================================================
John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
I just recently discovered that actual browsers
are displaying utf-8 safe url encodet URL paths as the right characters. Meaning
http://en.wikipedia.org/wiki/Gew%C3%BCrztraminer
actually displays
http://en.wikipedia.org/wiki/Gewürztraminer
Nice, isn't it?
8:20 p.m.
2010/4/19 John M McIntosh <johnmci(a)smalltalkconsulting.com>om>:
In Sophie the URI subsystem was *fixed* to ensure the
path data was UTF-8 and HTTP correct.
However what we found (a couple of years back) was that different browsers had different
opinions about
what to do for every UTF-8 character. At the time we decided the differences were bugs,
hopefully they have
been fixed now since I recall you can? now have domains with UTF-8 characters.
For domains that's easy because there's only one standard. It has
nothing to do with UTF-8 but uses punycode. For the path and the query
there are 3 standards one says ASCII, one says Latin-1 and one says
UTF-8. There is no way of knowing before making a request whether the
server accepts Latin-1 or UTF-8.
Cheers
Philippe
5361
days inactive
5361
days old
3 comments
3 participants
participants (3)
-
John M McIntosh -
Norbert Hartl -
Philippe Marschall