Re: lynx-dev URLs with raw 8-bit chars (was: lynx: have bug)

[Leonid Pauzner]

25-Mar-99 02:45 Klaus Weide wrote:
> On Mon, 22 Mar 1999, Leonid Pauzner wrote:

>> That is what I want - UTF-8 when possible by default
>> with drawback to %xx raw bytes by a hot key.

> It seems that you should be able to get this by a simple change:

Something like this (will try later, probably we should restrict
expanding of &entities; or so).  Think about renaming
TRANSLATE_AND_UNESCAPE_TO_STD() to TRANSLATE_HREF_ATTRIBUTE()

> #if OLD
> #define TRANSLATE_AND_UNESCAPE_TO_STD(s) \
>         LYUCFullyTranslateString(s, ATTR_CS_IN, ATTR_CS_IN, NO, NO, YES, 
> st_URL)
> #else
> #define TRANSLATE_AND_UNESCAPE_TO_STD(s) \
>         LYUCFullyTranslateString(s, ATTR_CS_IN, \
>                                     (LeonidsNewFlag ? me->inUCLYhndl : UTF8), 
> \
>                                   NO, NO, YES, st_URL)
> #endif

> This is untested.  I don't know what happens for characters that cannot
> be translated from ATTR_CS_IN (which will normally be either UTF8 or
me->>inUCLYhndl [which should be the transmission charset]).

>    Klaus


22-Mar-99 18:21 Klaus Weide wrote:
>> instead of UCLYFullyTranslate() call
>> (and I have not seen character entities in HREF= in the reality).

> And I have not seen either that or raw characters in HREF= in reality -
> can you offer an example for the last one?

One example I know of -  www.job.ru :)
This is essentially in Russian language (so may be a problem to test for you).

Briefly, you submit form with your preferences, next time you click CGI and
got redirection to result page (OK).
Unfortunately, this redirected URL contain open 8bit text for location area
(russian "Moscow", instead of sending a number or latin acronym) but there is
no problem at this stage - lynx redirection implementation never translate
URLs. The problem we get later: the result page is of 25 or 50 entries only
and have a link "Next 50 matches" near the bottom which is HREF= url with 8
bit text and this got broken.

I _guess_ they chose so misguiding method because they are misguided by a
support of different russian codepages (win-1251, koi8-r, etc) so urls should
survive the translating of httpd/proxy so cannot escape bytes directly because
its mapping should corresponds to page charset, and theirs CGI does not
support utf-8.