TYPO3 Core

I got the same problem with German umlauts. But everything worked fine after setting TYPO3_CONF_ VARS['BE'] ['forceCharset'] to utf-8 in the install tool.
Already inserted content has also been converted to utf-8 then.

Nevertheless, it is not correct to create an xml-Structure without the header. And this fixes the bug for every charset. :)

Problem still remains in Version 4.0beta1, although full PHP5-Compatibilty is offered and should be tested.

The problem is, for saving xml-Strings right charsets and xml-headers will be set. But for internal reasons, xml-strings without any headers will be used. This forces the descriped errors.

To know what i mean, simply look at the content of the $xmlValue-variable in line 1530 of tcemain Revision: 1.65 after saving an flexform (for example the new accessible tables).

Hi,
do you have time to have a look at this issue? That would be great :-) I don't have a deep experience in this.

Sebastian

I just turned the suggested solution into a unified diff patch.

Does this patch mean, "No Correction in Core" or should i test this patch only. If so, the patch works for me, but its only a not decorative workaround and i corrected it, in missing the whole overview, the same.

But the same behaviour appears in class.t3lib_tceforms.php,v 1.68.2.3 Line: 1895. The speaking method t3lib_div::xmlGetHeaderAttribs before runs also empty because of getting an headerless input.

The whole correction for PHP5 compatibility must situated at another File/Line. If i find time i will debug along, but you might be faster.

Syntactically the output of t3lib_div::array2xml must be corrected.

This will caused many problems with extensions, that not expected an fully xml-file or corrected the wrong output by themself (doubled xml-headers occurs).

But every workaround makes correction of the wrong output more difficult, so the version change to 4.0 is a good reason to place such an hard difference. For compatibility reasons this can be parameterized by TS.

Side effects in tcemain near the patched part (and the patch himself) and in method remapListedDBRecords() where the xml-output will be extended with a header before writing to db (Lines 1561 and 3609 in Rev.1.65).

I have edit in class.t3lib_div.php the xml2array function:

if ((double)phpversion()>=5) {
unset($ereg_result);
ereg('^[[:space:]]*<\?xml[^>]*encoding[[:space:]]*=[[:space:]]*"([^"]*)"',substr($string,0,200),$ereg_result);

$theCharset = $ereg_result¹ ? $ereg_result¹ : ($TYPO3_CONF_VARS['BE']['forceCharset'] ? $TYPO3_CONF_VARS['BE']['forceCharset'] : 'iso-8859-1');
xml_parser_set_option($parser, XML_OPTION_TARGET_ENCODING, $theCharset); // us-ascii / utf-8 / iso-8859-1

if($ereg_result==NULL) {

$string='<?xml version="1.0" encoding="'.$theCharset.'" standalone="yes" ?>'.$string;
  }
//xml_parser_set_option($parser, 'UTF-8', $theCharset);
}

Also a good idea. A workaround, but really a good idea to prevent side-effects. Could be a patch for 4.0. For 4.5 should be an overwhole correctionen the goal.

Hi Guys,

I finally had a look at this. Yes, PHP before version 5 was tolerant and didn't choke over the charset of the content. I think it sucks that they don't allow that anymore. The reason why we don't tag XML content in TYPO3 is because we use a global charset.
Anyway, I have added a new function array2xml_cs() which will add the XML prologue. The charset is taken from forceCharset if available, otherwise from LANG->charset and finally guessed. However, this definitely leads to trouble if people are using multiple backend languages but not forceCharset.
So now; either people manually add the XML prologue when using array2xml() OR they use array2xml_cs(). This should fix it for the future.

But what about the past; the problem is all the XML content which doesn't have the prologue! Recently I had a weird problem with a site moving from a PHP4 server to PHP5 and exactly this became a problem: That data structures were stored without prologue and contained iso-8859-1 chars! So one could argue that xml2array() executed under php5 should look for a prologue in the input XML and if not found add one assuming the charset like array2xml_cs() does today...

Well ,for now the issue is fixed for array2xml() but we could open a new discussion about the other one.