This is a classic encoding problem. You are using a different character set to interpret the data coming from the database than the character set that you used to store the data in the database, OR you're using a different character set to display the page than the character set you used to store the data in the database.
Since the rest of the page seems to display Urdu correctly, I'm going to assume you're either storing or retrieving the strings in the database incorrectly. How are you storing the strings? How are you getting them out of the database?
If you can figure out what the old encoding scheme was, you should be able to dump the defective items, convert them to the proper encoding, and reload them.
A thought occurs to me - you can use an ETL utility (like Pentaho DI/Kettle) to setup this process without having to do any arduous coding (after all, that's what you want to do: ETL - Extract, Transform and (re)Load). Dump the offending items out as text files (make sure you have a multi-lingual text editor!) using different encoding schemes for the source until you get something readable, then you can create the part of the pipeline that reloads with the repaired values. Needless to say, you should backup the database first - or better yet, clone the database and do your experiments on the clone copy.
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.
If you are using a rototiller, you are doing it wrong. Even on this tiny ad:
SKIP - a book about connecting industrious people with elderly land owners