String Problem

what do you mean by html format exactly?

Try this,

<b>TEST</b>
<i>Italics</i>

Sorry for not being clear.

I am passing the string as &lt;b&gt;TEST&lt;/b&gt;&lt;i&gt;Italics&lt;/i&gt;

Now I want it to be displayed with the HTML format correctly so it should print out TEST with the bold as well as Italics with italic words. Currently, it displayes
<b>TEST</b>
<i>Italics</i>

in my JSP.

Thanks
David

How are you passing it?

then you can insert it

<%= s %>

Is there any better way of doing that? Like JSTL perhaps?

The way I passed it is simply using the request object.

David

not really, at some point you need to replace those strings
you could use a tag for it, but that would just mean the tag would do the replaceAll().
ie. replaceAll() is what you need, where that is implemented is up to you :)

commons provides lib methods for doing it

http://jakarta.apache.org/commons/lang/api-release/org/apache/commons/lang/StringEscapeUtils.html

>>The way I passed it is simply using the request object.

Use URLEncoder\Decoder, then you won't need replacements

Thanks object for the links.

CEHJ, do you mean to encode or decode it first before sending it to JSP?

David

> Yes, encode the parameter before sending. This is the correct way to send such parameters, in fact.
> Decoding it will give you the original html

thats incorrect :)

Ok,

Thanks. objects, if CEHJ is incorrect, does it mean that we can only use replaceAll to do it?

David

> Thanks. objects, if CEHJ is incorrect, does it mean that we can only use replaceAll to do it?

thats right or a library that does it.
I'd suggest adding commons to your webapp and use the methods it provides. Lots of other useful stuff in there as well :)

>>if CEHJ is incorrect

Are you not curious as to *why* i'm 'incorrect'? ;-)

>>"Are you not curious as to *why* i'm 'incorrect'? ;-)"
That's why I am asking is that the only solution to objects and I assume that you are still following this thread and can give me the explanation ;)

David

The reponsibility for saying why it's 'incorrect' i think rests with the person who baldly stated it to be ;-)

You can simply test it of course:

<%=URLDecoder.decode(req.getParameter("html"), "UTF-8")%>

I'd actually be more interested in why he thinks url encoding has anything to do with this question :) Its completely unrelated, how is encoding a string and then decoding it going to change the contents of the string. It won't, the string will still be the same as it was originally at which point you'll need to do as I suggested.

In case there's any doubt, of course you would encode the String you wanted using URLEncoder, i.e. the actual html

I agree that object's suggestion is valid and should be working.

Okay, let's straight this thing out. I am going to test on what CEHJ is suggested. If it works, then it means that CEHJ's answer is also valid.

David

>>I am going to test on what CEHJ is suggested.

Don't forget to encode the actual html, not

>>&lt;b&gt;TEST&lt;/b&gt;&lt;i&gt;Italics&lt;/i&gt;

To help you decide which way is better, check the length of the resulting query string

Okay,

CEHJ is also valid but it is an alternative way of doing it. I think that objects solution is more accurate based on the original question that I have.

So I am going to split the points to both of you with objects receiving more points.

What two of you think?

David

> CEHJ is also valid but it is an alternative way of doing it.

No its not :) it totally unrelated

> I think that objects solution is more accurate based on the original question that I have.

CEHJ suggestion has nothing to do with the original question in fact.

>>
I think that objects solution is more accurate based on the original question that I have.
>>

I'd be interested to know why it's more accurate? It's actually less accurate for the following reasons:

1. it's not a standard way to pass parameters that need to be escaped
2 it occupies more space in the query string
3. if you ever pass additional parameters, you may need to use *two* encryption s hemes

objects,

I assume that you said that it is "unrelated" because it does not solve the problem originally. Am I right? However, in my opinion, CEHJ provides an alternative way of doing it albeit it does not solve the problem that I have.

In my opinion, wouldn't that be good to have a post that have the direct answer as well as an alternative so that people can get benefit most of it?

Please let me know what you think objects.

you may need to use *two* encryption s hemes=you may need to use *two* encoding schemes

CEHJ,

>>"1. it's not a standard way to pass parameters that need to be escaped"
It may be true but currently, this is the String that is passed by the third party system so there is nothing I can do. So I assume that objects hits the point correctly. But I am not saying that you are wrong! Your solution may be practical if the third party would like to implement it as well in which they don't

What do you think?

>>it does not solve the problem that I have

Why doesn't it? If it doesn't then it's useless ;-)

>>"Why doesn't it? If it doesn't then it's useless ;-)"
The reason is in my previous comment CEHJ ;)

Its not an alternative, the encoding/decoding of the parameters is already handled for you. Otherwise you would not be recieving them.

            System.out.println(URLDecoder.decode("&lt;b&gt;TEST&lt;/b&gt;&lt;i&gt;Italics&lt;/i&gt;", "UTF8"));

output:

&lt;b&gt;TEST&lt;/b&gt;&lt;i&gt;Italics&lt;/i&gt;

Wow, thats useful :-D

>>this is the String that is passed by the third party system so there is nothing I can do.

Well if it's not *you* that's passing the string, then you can't alter it, but that's not what you said ;-)

>>I am passing the string as &lt;b&gt;TEST&lt;/b&gt;&lt;i&gt;Italics&lt;/i&gt;

If you'd said

'I am receiving a string as &lt;b&gt;TEST&lt;/b&gt;&lt;i&gt;Italics&lt;/i&gt;'

then i wouldn't have wasted my time ;-)

>>"Well if it's not *you* that's passing the string, then you can't alter it, but that's not what you said ;-)"
Maybe I should mention it earlier.

>>"If I pass the string like"
This is what I am saying.

Apologized for that.

objects, CEHJ solution will work if you have encoded it previously before passing it.

I am not going to go further about this and I will stick with objects get more points and CEHJ get less points but it is a split.

What you think?

its really irrelevant where the string comes from , at some point you have to change it as I suggested which is what you were asking :)

> CEHJ solution will work if you have encoded it previously before passing it.

No it won't :-D

>>"at some point you have to change it as I suggested which is what you were asking :)"
That is why I think that you deserve more points

In fact it has already been encoded before sending, and decoded when recieved as I mentioned above.
ie. CEHJ is suggesting something that is already occurring.

>>"CEHJ is suggesting something that is already occurring."
It is mainly my fault as CEHJ wouldn't waste much time if I said that I received it from third party which I can't control. But if people are reading this post, I think that they will get a benefit by looking at what CEHJ's suggested. Don;t you think so?

So objects, what are you proposing?

That is just my judgement. If any of two of you think that it should not be. Let me know, I just want everybody to be happy and not to be offended :)

David

> It is mainly my fault as CEHJ wouldn't waste much time if I said that I received it from third party which I can't control.

Where it comes from doesn't make any difference. They are already encoding the parameter as required, they cannot avoid doing that.

> I think that they will get a benefit by looking at what CEHJ's suggested. Don;t you think so?

No, because what he is suggesting is already being done. It has absolutely nothing to do with your problem.
Suggesting to do it again is a pointless waste of time.

Ok,

Let's ask Venabili to be the judge. I will agree to what Venabili suggests. I hope that everyone is happy about it.

Before that, I would like to thank you for all of you who has responded to my questions.

Thanks
David

objects, CEHJ,

I am not going to be available soon. I will be back tonight

no need to waster her time. I don't mind what you do really, just want you to understand better as CEHJ's comment's are actually quite misleading.

just be aware that your parameter is already being encoded and decoded :)
it has nothing to do with the problem at hand.

>>>>"at some point you have to change it as I suggested which is what you were asking :)"

My previous comments therefore apply to how *they* are passing the parameter. If they had passed it as html you wouldn't have to change it

> If they had passed it as html you wouldn't have to change itIf they had passed it as html you wouldn't have to change it

rotfl, well thats stating the extremely obvious :)  And if that was the case the question wouldn't need to be asked, so again not at all relevant.

Thanks guys,

I hope that everyone is happy about this.

David

:-)

> Yes, encode the parameter before sending. This is the correct way to send such parameters, in fact.
> Decoding it will give you the original html

fine by me, though for the benefit of others reading the question that comment is incorrect.
See my earlier comments for an explanation :)

Thanks objects and CEHJ.

David