[Gambas-user] Problem with Conv() and XmlWrite

Luigi Carlotto md9327 at ...120...
Sun Dec 28 01:20:51 CET 2008


Il giorno sab, 27/12/2008 alle 19.58 +0100, Luigi Carlotto ha scritto:

> The strings do not contain characters of “Carriage Return” or “Line
> Feed”, but only space; if you have noticed interruptions, it is only a
> problem with the mail, or the editor using the function cut&paste.
> Probably, the option of “wrapping” of the editor, divides the line
> through spaces, but in the code all in a same and only string are
> comprised.
> 
> The sql commandos are, sometimes, composed from more of a word key,
> and they do not have sense if dealt in separate way; an example could
> be the definition of a PostgreSQL field of type “timestamp with time
> zones”. For program requirements, I have had to list in exact way, all
> the words key of the language sql, used from the motor of the
> database.
> 
> I have already executed the test on the single characters of the
> string, and I have not evidenced anomalous situations.
> As I have already written, the problem verification in phase of
> passage of the string to function XML; the conversion executed from
> Conv() is very well.
> If I execute “PRINT Conv(sType, “UTF-8”, “ASCII”)” from Console, the
> string it comes visualized in corrected way, with any LANG.
> 
> You perfectly have reason on the anomalous use of the attributes, but
> I have had to use this logic because of an other problem, that I have
> uncovered using the gb.xml library; it seems that it is not way to
> read xml files, composed from tag multilevel.
> With my tests, I have verified that the use of a hierarchical
> structure, with advanced levels to 2, does not come read, that is,
> they come only read the tag of first and second level; if a third
> level is present, comes ignored, etc. 
> 
> Like in other languages, the document xml begins with tag
> “root” (level 1), to which they are connected of the elements (level
> 2); Every element has, in its turn (attributes to part), a series
> under elements (level 3), and thus via, in hierarchical way.
> The methods of the library do not allow to read these ulterior
> elements, for which they have been forced to use a structure with 2
> single levels, and the attributes for the values of the single
> element.
> 
> But to part this, probably, and as I had supposed, exists some problem
> in the writing of attributes much large; but the single anomaly
> verification with the use of an Asian language, while with the
> European languages all it works well.
> 
> It pardons me for my English bad one.
> 
> 


I have modified the procedures of reading/writing of XML files,
following your relative suggestion I use to it of the elements
(eliminating the attributes).
In spite of this modification, the problem still remains…
I send new file, in attached, so that it can be read with browser or a
editor of text, to eliminate problems of reading of invisible
characters.
The error code is always the same one:

encoding error : output conversion failed due to conv error, bytes 0xE5
0x31 0x32 0xE5
I/O error : encoder error
Error: Error writing XML data
Code: -1

I have divided the code, so as to verify if the problem is caused from
the conversion (Conv), or from the writing xml; you I can confirm that
the error verification in correspondence of the writing xml, while the
conversion comes made correctly.

With the exception of the byte 0x31 (character “1”) and 0x32 (character
“2”), character 0xE5 (224 binary) does not come understood; in effects,
using PRINT Chr (224) in Gambas Console, they come printed two
rectangles white. This character, but, is not present in the string
where the program jams; the string is: ”--,/*, *“ (excluded apexes). The
same string comes many times over saved, in the same function, but the
program jams alone on the last one.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgdesigner2.conf
Type: application/xml
Size: 7612 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20081228/1d45ec77/attachment.wsdl>


More information about the User mailing list