I am comparing two sheets using ClosedXML in c#. But i need to first convert the international characters to normal characters and then continue with comparing. I am not getting the encode part. Kindly help me out.
Related
Using Oracle Business Intelligence Publisher 12.2.1.3.0 AKA, BI Publisher Enterprise.
I'm having trouble with accented characters, such as the ü character (the letter U with an umlaut/diaeresis). Sometimes they appear with the umlaut above the u, and sometimes to the right of the u.
I've learned that a u with an umlaut/diaeresis can be stored as
One character (composed)
latin small letter u with diaeresis
Two characters (decomposed)
latin small letter u
combining diaeresis
I originally thought it was a problem with the html2fo function, but that has proven incorrect. Some of my source data is stored composed, some decomposed.
The problem is with the decomposed form.
It's working fine when I generate HTML output, but appears incorrect in PDF output. PDF output shows the umlaut after the U, rather than above it.
PDF Output:
If I take the source data in Word, and export a PDF, the decomposed characters appear just fine.
How do I correct for this problem? Bug in BI Publisher maybe? I would not like to make a function to convert decomposed to composed characters if I can avoid it.
**** Update 1/16/2020 ****
Oracle has confirmed this is a Bug.
Bug: 29751368
I'm trying to reproduce a character conversion...
Essentially out of the Chinese word for Login. In this example the Chinese word for Login, "登录"should be converted into this text instead "µÇ¼".
It would be nice if there was a piece of software that did this for me already...
I've had this problem for a long time but I've been implementing this ugly hack on the backend to get around it.
Now I've decided to act as a real developer and deal with it.
My problem is that when parsing an XML feed with any of the Norwegian characters æ, ø or å in the title node, all the letters appearing before these special characters are ommitted.
So if the word is "Bålhuset" it only displays "ålhuset" - the funny thing is that æ,ø and å characters AFTER the initial problem character is included.
So if I put for example "ÅBålhuset", I will get "Bålhuset". So it seems it's only the first occurence of one of these special characters that will cause a problem.
Any help would be immensely appreciated!
-Chris
Try while you creating XML use CDATA tags like
<title><![CDATA[Transport "Bålhuset"Classic World's]]></title>
Also here is a list of HTML Tags and more cases XML with those characters is invalid, unless they are contained within a CDATA. Also try this Question hope with help you
Otherwise you need to use their special character code. If you want to represent ö you need to type ö please review like.
And Final XML with those characters is invalid, unless they are contained within a CDATA.
You can Validate you XML while creating and easily fix the bug.
What did it for me was getting the data in JSON and using the native JSON methods; no dropped characters and other sporadic behaviour.
So what that means to me is that there is an issue with NSXMLParser that makes it choke on international characters (the first occurence of which mind you) even though everything is in order with encoding etc.
I have some link resources with none latin characters like åäö
These are usually user uploaded files
The problem is that i am not successfull in encoding them
using filename.encodeAsURL seems to not encode it the right way
For example the character ö is turned into o%CC%88
Testing to type the same thing in firefox and copy the contents gives %C3%B6
What are the difference between these encodings and what should i use to get the correct encoding??
Both encodings are correct. You are actually seeing the encoding of two different strings.
The key here is noticing the o at the beginning of the string:
o%CC%88 is the letter o followed by Unicode Character Combining Diaeresis, which combines with the previous character when rendered.
%C3%B6 is Unicode Character Latin Small O With Diaeresis.
What you are seeing is that in the first case, the string entered is something like these two characters: o ¨, which are actually rendered as ö.
In the second case, it's the actual character ö.
My guess is you are seeing the difference between two different inputs.
Update based on below discussion: If you are dynamically processing Unicode characters, and you do not have control over the input methods, you can try to normalize the Unicode, using java.text.Normalizer (Java 1.6 or newer).
Normalizing attempts to ensure that all characters are consistently represented, so that accented characters are always represented by a combined character or always by the character+combining mark.
Rough example:
String.metaClass.normalizeUnicode = {
return java.text.Normalizer.normalize(delegate, java.text.Normalizer.Form.NFC)
}
input = input.normalizeUnicode()
There are four forms of normalization. I picked the one that seems to be best for your case based on the description of how they work, but you may prefer to try the other ones and see what works most consistently.
All that being said, if you are try to representing Unicode characters in a URL, and they are not being loaded and processed by the code directly, it's probably best to avoid using non-latin characters altogether. Not only does this have the benefit of consistently, but also significantly shorter and more legible URLs. boo.pdf is a lot easier to read than bo%CC%88o.pdf.
Could you suggest me a code or a library (possibly java) to convert digits (e.g. 24) in letters (e.g. twenty-four)? Obviously I need to change locale (from English to Italian).
Check this link: http://snippets.dzone.com/posts/show/3685
You'll have to translate the numbers into italian, but apart from that it should solve your problem.
/Klaus