Re: source encoding (was: Some suggestions for documentation)
Brought to you by:
bs_php,
nigelswinson
From: Peter R. <php...@pe...> - 2002-05-31 19:35:55
|
On Thursday 23 May 2002 09:25, Peter Robins wrote: > > ok, I will try and get this done (and tested!) next week. have looked further into this and find there is no problem. In fact, it looks like the PHP manual is wrong. What the source encoding function in expat does is _override_ the encoding given in the file. So, if your xml file is defined as utf-8, it will be read in and processed as utf-8. As I can't think of any reason why you would want to override the file encoding, I see no reason for writing a function to do it! However, whilst investigating this, I came across another phpxpath feature that I wasn't aware of before. Why does the handling of the xml PI and other header info such as dtd differ between exportAsXml and exportToFile? As default, exportAsXml keeps it, whereas exportToFile drops it. Is not the main difference between these 2 functions that exportToFile, er, well, writes the xml to a file? This is neatly illustrated by the test suite. Take for example the simple-test files provided. These are defined as latin1, and if you change them using >127 characters such as accented ones, according to the display the encoding in the output file is latin1. However if you look at the actual file created, you find the encoding has disappeared, in other words it is now supposedly in utf-8. This should mean the display is screwy if you load this file in the test suite, but doesn't because the script doesn't define the html charset, so if your browser, like mine, uses latin1 as default, the display looks correct - in other words, the 2 errors cancel each other out. nice one :-) |