Complete.Org: Mailing Lists: Archives: gopher: September 2008:
[gopher] Re: Multilingual Gopher Support (was Re: Gopherness)

[gopher] Re: Multilingual Gopher Support (was Re: Gopherness)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: gopher@xxxxxxxxxxxx
Subject: [gopher] Re: Multilingual Gopher Support (was Re: Gopherness)
From: Cameron Kaiser <spectre@xxxxxxxxxxxx>
Date: Tue, 30 Sep 2008 16:19:23 -0700 (PDT)
Reply-to: gopher@xxxxxxxxxxxx

> I switched it to UTF-8 with BOM and although the BOM appears in FF2 =20
> (as a '?' at the start of the file), it now looks fine in lynx.
> The characters in question obviously weren't 7-bit ASCII, I had two =20
> '=C3=A9's on one line, and the output in lynx was that the links drawn =
> didn't match the links that were highlighted when you pressed 'down', =20
> such that navigating the page produced erroneous drawing in the =20
> terminal.

I'm not surprised, Lynx does not have much history with non-7bit encodings.

> I have also since discovered that URLs such as /h/linguistics/yol=C5=8Bu/=
> are not requested correctly. No URL escaping of the unicode characters =
> is performed, and ^K whatever that's supposed to mean: '/h/linguistics/=
> yol^Ku' instead of  '/h/linguistics/yol%C5%8Bu/'.

You mean the client does not request them correctly, or the server does not
process the request correctly? I would probably call 8-bit Gopher handling
"undefined." However, if Unicode characters (or any non 7-bit entity) were
in a gopher selector, I don't think URL encoding them is really in the spir=
of the RFC either.

------------------------------------ personal:
/ --
  Cameron Kaiser * Floodgap Systems * * ckaiser@floodgap.c=
-- Don't Be Evil. -- Paul Buchheit ----------------------------------------=

[Prev in Thread] Current Thread [Next in Thread]