in reply to Re^2: LTR character in links
in thread LTR character in links

I get the extra LTR characters if I try to follow that link. Don't you?

Replies are listed 'Best First'.
Re^4: LTR character in links
by ikegami (Patriarch) on Jun 20, 2023 at 19:10 UTC

    No. The link provided by PerlMonks is to https://metacpan.org/pod/Business%3A%3AStripe%3A%3ASubscription.

    Screenshot of HTML (And no, it contains no hidden/special characters.)

    If you get something else, your browser (incl extensions) or your proxy is changing something.

      The source in my home node has this...

      <p>CPAN Releases</p> <p><a href="https://metacpan.org/pod/Business::Stripe::WebCheckout">Bu +siness::Stripe::WebCheckout</a><br /> <a href="https://metacpan.org/pod/Business::Stripe::Subs&#x200E;crip&# +x200E;tion">Business::Stripe::Subs&#x200E;crip&#x200E;tion</a><br /> <a href="https://metacpan.org/pod/Business::Stripe::Webhook">Business: +:Stripe::Webhook</a></p> <p><a href="https://metacpan.org/pod/AI::Embedding">AI::Embedding</a>< +/p>
      It is the &x200E; characters that should not be there...

      They were not put there when I edited my profile but somehow PM is adding them and I cannot get rid of them...do they not look like that to you?

      I've turned off all browser extensions and checked on another machine with a freshly installed Chrome browser with no extensions.

        but somehow PM is adding them and I cannot get rid of them.

        Indeed, I can reproduce for profiles pages. For profile pages (but not for SoPW pages), instances of script are replaced with s&#x200E;crip&#x200E;t.

        This is presumably a security measure. However, I can't imagine why this measure would be needed for profile pages if it isn't needed for SoPW pages. I therefore consider this a bug.

        Workaround: Use &#x73;cript instead of script. (&#x53; for an uppercase S.) For example,

        <a href="https://metacpan.org/pod/Business::Stripe::Sub&#x73;cription" +>Business::Stripe::Sub&#x73;cription</a>

        The hack is applied after the expansion of [mod://] and similar, so they can't be used as a workaround.