On Sunday 03 March 2002 13:55, Robin Berjon wrote: > On Sunday 03 March 2002 19:34, Tod Harter wrote: > > > Right.... apart from that tiny little nagging problem being that the > > > charset parameter on application/* is ILLEGAL. > > > > Perhaps... Anyway, the point is that "url-encoded" implies US-ASCII... > > Its common for user agents to ignore that, but since there is no > > mechanism for specifying the character set of a URL it is pretty much > > mandated. So if a form is REALLY URL encoded, then it must be ASCII, > > mustn't it? > > It ought to be, except that url-encoding can in fact encode any 8bit > charset, which means that it can also take most of the iso-8859-* family. A > number of browsers have that misbehaviour.
Maybe it can in the sense that it is POSSIBLE to do so. The problem is its definitely a boo-boo. I think a lot of what has happened with URL encoding is that vendors have gone and deployed file systems that use various encodings, then they seem incapable of making user agents that properly URL encode the resulting paths. Realistically even UTF-8 is a hack. ALL the software and standards need to be updated, badly. Ideally all software should be able to deal with any incoming encoding, and really everything should be UTF-16 internally. At least then you have a fighting chance of representing an encoding in a consistent internal form. I'd give it about 40 years... > > > Well, I have yet to have a form submitted to me and I wasn't able to > > process it. Doubtless it has happened somewhere to someone, but I've > > built and deployed at a rough guess 40 web applications over the last 8 > > years. Maybe I'm just lucky ;o). > > You're just lucky (or quite simply just working in english), it's happened > to me many times over the past year. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
