Encoding of generated SQL file

[Gregor Goldbach]

Hi list,

tedia2sql seems to generate iso-8859-1 (latin-1) files and seems to
ignore how the dia file is encoded.

Is there a way to tell tedia2sql to generate utf-8? Or is this a problem
of XML::DOM?

  Gregor

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Mike Ginou]

Gregor,

I admit to being incredibly naive about encodings, probably because I'm
an ignorant English speaking North American for whom ASCII is perfectly
adequate ;)

I don't believe there is any real thought put towards the file encoding
in tedia2sql. I don't believe that the encoding of the input file is
detected.

I presume the problem is that the SQL file that is generated is mangling
some of your names?

Patches would be welcome (of course!). Probably a good way to start
would be separate patches for the following:

- Detect the encoding of the input (dia) file.
- Add a command line switch to specify different encodings for the
output file.
- By default match the output encoding to the input encoding.

My ignorant opinion is that each of those actually seems reasonably
easy. But as I say, I've never really done much investigating about
encodings. For what it's worth though, the output file is built into a
string which is basically just piped straight into a file. I'm fairly
sure that this should make changing the output encoding relatively easy.
I'm sure there is an existing function that would simply take care of
the encoding automagically if the output file is openened for writing
and a specific encoding is specified.

-Mike

Gregor Goldbach wrote:

> Hi list,
>
> tedia2sql seems to generate iso-8859-1 (latin-1) files and seems to
> ignore how the dia file is encoded.
>
> Is there a way to tell tedia2sql to generate utf-8? Or is this a problem
> of XML::DOM?
>
>   Gregor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Gregor Goldbach]

Mike Ginou wrote:

> I don't believe that the encoding of the input file is
> detected.

You are right ;)

The problem is perl, I think (as usual). My dia file contains a
perfectly utf-8 encoded umlaut which becomes a perfectly encoded latin-1
 umlaut in the SQL file.

> I presume the problem is that the SQL file that is generated is mangling
> some of your names?

Well, actually just one. And it's just a comment.

> Patches would be welcome (of course!). Probably a good way to start
> would be separate patches for the following:
>
> - Detect the encoding of the input (dia) file.

Which perl can't. I think it would be best to 'use Encode' and set the
encoding on the input stream to somethings specified with a command line
switch.

> - Add a command line switch to specify different encodings for the
> output file.

Yes.

> - By default match the output encoding to the input encoding.

Yes.

> My ignorant opinion is that each of those actually seems reasonably
> easy. But as I say, I've never really done much investigating about
> encodings. For what it's worth though, the output file is built into a

Using the magic of Encode, converting is easy. However, *detecting* the
encoding can't be done.

> string which is basically just piped straight into a file. I'm fairly
> sure that this should make changing the output encoding relatively easy.

Yes, that's easy using Encode.

> I'm sure there is an existing function that would simply take care of
> the encoding automagically if the output file is openened for writing
> and a specific encoding is specified.

I might give it a try in the next few days. I understand 1.2.13b2 is
still the latest version?

  Gregor

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Gregor Goldbach]

Gregor Goldbach wrote:

> I might give it a try in the next few days.

A quick test showed that a simple

  use open ':locale';

is sufficient.

I haven't tried it under many environments, though.

  Gregor

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...