is not used any more and exists only for history. Post new tickets on the Github account. n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#571 closed bug (invalid)

"&" char in entities get escaped, and it shouldn't

Reported by: Julien Owned by: Julien
Priority: normal Milestone:
Component: jelix Version: 1.0.3
Severity: normal Keywords:
Cc: Blocked By:
Blocking: Documentation needed: no
Hosting Provider: Php version:


As I worked on ticket #543 (which is closed now because it was invalid), I noticed the following bug :

having that string in a property file :

test = My title with entities & others (10 > 2<5)

and having a controller method doing this :

function index() {
$rep = $this->getResponse('html');
$rep->title = jLocale::get('test.test');

I'm getting the following HTML source code :

<title>My title with entities &amp;amp; others (10 &amp;gt; 2&amp;lt;5)</title>

I'm getting the same result if I use the escxml modifier in the HTML body.

So I think that the "&" char must be converted to "&amp;", except if it is followed by chars that will match something like

([a-z]+|#[0-9]+); // will match things like &eacute; and &#233;

I think it's the only way to safely allow entities use in jLocale strings.

Is that report valid, or should I forget about it ?

Change History (7)

comment:1 Changed 13 years ago by Julien

  • Owner set to Julien
  • Status changed from new to assigned

comment:2 Changed 13 years ago by laurentj

  • Resolution set to invalid
  • Status changed from assigned to closed

This bug is invalid because you can do this simply:

test = My title with entities & others (10 > 2<5)

I don't know why you want to put html entities in the locale.

comment:3 Changed 13 years ago by Julien

Ok, my example string only had HTML entities in it, which was not the best example.

As I said, I noticed it while working on old ticket #543, reported by brunto.

He wanted to be be able to use strings like :

titre_page = Titre momentan&#233;

wich will produce the following html code :

Titre momentan&amp;#233;

so the "é" sign will not appear as excepted.

So I think we need to fix this (then I let you reopen this ticket) or we should explain in the doc that entities usage it not supported and thus "forbidden".

comment:4 Changed 13 years ago by laurentj

This is problem in jResponseHtml, not in jLocale. jLocale MUSTN'T do some HTML escaping or else, because a locale can be used for everything, not only to be included in an HTML page.

However, if we have to check such entities in jResponseHtml, we have to do it for all values on which jResponseHtml applies htmlspecialchars. So we have to replace htmlspecialchars by a preg_replace for example. How about performance ?

An other issue: if we really want to escape this entities, how do we do ? Do we have to provide both escxml and escxml2 ?

I would like also to know a good reason to put html entities in a locale, even though we can use the charset we want (so html entities is useless in a locale). If we want to use characters which don't exist in the charset we use, we can use UTF-8 instead of using html entities.

comment:5 Changed 13 years ago by Julien

I'm 100% ok with you.

I didn't say it was related to jLocale, but based my report on brunto's try to use UTF-8 entities in jLocale strings (#543). I just noticed that the problem occured when rendered in HTML (auto-escaped for the <title> value, or escaped with the escxml modifier).

I don't see any reason for using entities in locale strings either. At least, I don't really want to patch anything about that, but I think we should add to the documentation that using entities in jLocale strings is not good, because of escaping treatments in HTML rendering.

If we do not, people may try to use entities, and report "invalid bugs", because that feature is not supported.

I suggest adding some warning in the documentation.

comment:6 Changed 13 years ago by laurentj

Ok, I update the documentation.

comment:7 Changed 13 years ago by Julien

Thanks, I think it's the best way to solve this problem.

Note: See TracTickets for help on using tickets.