XML returned by web service with encoding error

Question

Hello, I have an XML that returns from a webservice with encoding errors, on encoding XML is like UTF-8 but it doesn’t display accents correctly and I can’t detect which correct encoding it should be. I have no information as to how it is stored in the original database or any other of the type, I just get back the same. here an example of how I receive XML:

<?xml version="1.0" encoding="UTF-8"?>
<test>
<title>Muitos cientistas intrØpidos se aventura no coraĿªo dos dois vulcıes mais explosivos do planeta</title>
</test>

How can I convert/detect encoding and fix accent errors? Is there any way to convert this characters after generator by the webservice or this correction can only be done in the webservice itself once the XML has already been generated?

Note: I have tried functions like iconv, utf8_decode, mb_convert_encode.

Thanks in advance.

Answer 1

In this case a solution would be, you make a map with the patterns of encoding returned, and replace them, example :

<?php 
$arr = array("Ø" => "é","Ŀ" => "ç","ª" => "ã", "ı" => "õ"); 
$word = "Muitos cientistas intrØpidos se aventura no coraĿªo dos dois vulcıes mais explosivos do planeta"; 
echo strtr($word,$arr); 
?> 

See working on Ideone

Answer 2

You are already receiving the data incorrectly and therefore it will be virtually impossible detect the coding that information is coming in.

My recommendation is that you check the routine that is generating XML and perform a correction on it.

Some important details: The XML standard defines the character encoding in your header with the <?xml version="1.0" encoding="UTF-8"?>. The routine that will read this data must respect this encoding and use it to read the data. If the encoding is different from the one reported in the file, XML is invalid.

Answer 3

When I had this problem, the file that generated my XML was saved with ANSI encoding , I just changed the file format to UTF-8 and it worked.

Answer 4

There are a couple of typical mistakes that lead to these kinds of situations. In this case there was a conversion to utf8 of a latin1 but indicating that it was something else (in this case ISO6937).

Solution with Iconv:

iconv -f utf8 -t ISO6937 x.xml | iconv -f latin1 -t utf8

Explanation : But how to arrive and this miraculous "ISO6937"?: Reverse the process with all known encodings and see the right ones!

1: which existing encodes known by iconv? -- iconv -l

2: reverse the process for everyone (creating a file _encode):

for a in `iconv -l | cut -d/ -f 1 `
do   
   iconv -c -f utf8 -t $a x.xml | iconv -f latin1 -t utf8 > _$a
done

3: look for your products that have produced the desired result (and choose a):

$ grep -l 'intrépido.*coração.*vulcões' _* 
_ANSI_X3.110
_ANSI_X3.110-1983
_CSA_T500
_CSISO103T618BIT
_CSISO90
_CSISO99NAPLPS
_ISO6937
_ISO_6937
_ISO_6937:1992
.... 

some of these names are alias of the same chaset