Table Encoding LP8

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Table Encoding LP8

Wade Maxfield
I've been following the thread on Page encoding, and have a related problem.

Characters are not displaying correctly on a
rendered page, things like the accented e in
café, and other high characters. Instead a
diamond with a question mark displays, or even a
tab like, arrow and bar character.

I've tried many of the suggestions in other
threads, but without much luck.  Characters do
show correctly in the SQL Query Browser. After
much playing around I found that if I don't
specify the -table parameter in my sql inlines,
then the characters will display correctly in my
pages, which is the opposite of what the
documentation suggests.
The tables that this is happening with are all
utf8 according to Navicat, and have been set as
UTF-8 in the SiteAdmin (Set Up > Data Sources >
Tables)

Changing the encoding in SiteAdmin back to
iso-8859-1 will also get the pages displaying
correctly (which is strange since they are utf8
tables).

Any suggestions as to why this is happening would be muchly appreciated.





Set up details:

Mac OS X 10.3.8
Lasso 8.0.3 (and now 8.0.4)
MySQL 4.1.9 standard

The table is utf8 according to Navicat
Set Up > Site > Settings   Default page encoding is set to UTF-8
Set Up > Data Sources > Tables  The table in question is set to UTF-8
All my lasso files are saved as UTF-8 (with BOM) from BBEdit

I've tried setting [content_type: 'text/html; charset=UTF-8'] as per Bil's post
I've removed my meta tag from the page, it was
<meta http-equiv="content-type" content="text/html; charset=utf-8" />

  -Wade

--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Table Encoding LP8

Bil Corry
> I've been following the thread on Page encoding,
> and have a related problem.

I have a guess.  When I started using MySQL 4.1, I thought it would be worldly
of me to make my tables UTF-8 encoded.  I then started using it with MySQL only
to find collation problems that could only be corrected by prefixing every sql
query with the SET NAMES command.  The issue was I couldn't get the built-in
MySQL connector to connect to MySQL in anything other than ISO-8859-1.  So I
gave up and switched back to ISO-8859-1 for my tables.

So my guess is perhaps you're seeing it too.  MySQL will return data in the
character encoding the client specifies (which my guess is ISO-8859-1), even if
the table is UTF-8.  So MySQL returns ISO-8859-1, but telling Lasso it's UTF-8
causes Lasso to munge the data since it's really ISO-8859-1.  That's why telling
Lasso it's ISO-8859-1 (or omitting -table) makes it work.

Anyhow, that's my guess.

To test it, set the table encoding back to UTF-8, then execute a query that
forces MySQL to return UTF-8:

        SET NAMES 'UTF-8';
        SELECT myAccentedChars
        FROM myUTF8Table;

Does Lasso now correctly show the characters?

One workaround Marc Vos contributed was to use the JDBC connector instead of the
MySQL connector.  You can set the default character set to UTF-8 in the
connection string.

More about MySQL and how it handles character sets and connections is here:

http://dev.mysql.com/doc/mysql/en/charset-connection.html



- Bil

------

Bil Corry
[hidden email]

Enterprise internet application development and security consulting
  http://www.fivegeeks.com/

Tools for Rapid Lasso Development
  http://www.lassoware.com/
 
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of
Wade Maxfield
Sent: Saturday, May 28, 2005 11:15 PM
To: [hidden email]
Subject: Table Encoding LP8

I've been following the thread on Page encoding, and have a related problem.

Characters are not displaying correctly on a
rendered page, things like the accented e in
café, and other high characters. Instead a
diamond with a question mark displays, or even a
tab like, arrow and bar character.

I've tried many of the suggestions in other
threads, but without much luck.  Characters do
show correctly in the SQL Query Browser. After
much playing around I found that if I don't
specify the -table parameter in my sql inlines,
then the characters will display correctly in my
pages, which is the opposite of what the
documentation suggests.
The tables that this is happening with are all
utf8 according to Navicat, and have been set as
UTF-8 in the SiteAdmin (Set Up > Data Sources >
Tables)

Changing the encoding in SiteAdmin back to
iso-8859-1 will also get the pages displaying
correctly (which is strange since they are utf8
tables).

Any suggestions as to why this is happening would be muchly appreciated.





Set up details:

Mac OS X 10.3.8
Lasso 8.0.3 (and now 8.0.4)
MySQL 4.1.9 standard

The table is utf8 according to Navicat
Set Up > Site > Settings   Default page encoding is set to UTF-8
Set Up > Data Sources > Tables  The table in question is set to UTF-8
All my lasso files are saved as UTF-8 (with BOM) from BBEdit

I've tried setting [content_type: 'text/html; charset=UTF-8'] as per Bil's post
I've removed my meta tag from the page, it was
<meta http-equiv="content-type" content="text/html; charset=utf-8" />

  -Wade



--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Table Encoding LP8

Wade Maxfield
In reply to this post by Wade Maxfield
>  > I've been following the thread on Page encoding,
>>  and have a related problem.
>
>I have a guess.  When I started using MySQL 4.1, I thought it would be worldly
>of me to make my tables UTF-8 encoded.  I then started using it with
>MySQL only
>to find collation problems that could only be corrected by prefixing every sql
>query with the SET NAMES command.  The issue was I couldn't get the built-in
>MySQL connector to connect to MySQL in anything other than ISO-8859-1.  So I
>gave up and switched back to ISO-8859-1 for my tables.
>
>So my guess is perhaps you're seeing it too.  MySQL will return data in the
>character encoding the client specifies (which my guess is
>ISO-8859-1), even if
>the table is UTF-8.  So MySQL returns ISO-8859-1, but telling Lasso it's UTF-8
>causes Lasso to munge the data since it's really ISO-8859-1.  That's
>why telling
>Lasso it's ISO-8859-1 (or omitting -table) makes it work.
>
>Anyhow, that's my guess.
>
>To test it, set the table encoding back to UTF-8, then execute a query that
>forces MySQL to return UTF-8:
>
> SET NAMES 'UTF-8';
> SELECT myAccentedChars
> FROM myUTF8Table;
>
>Does Lasso now correctly show the characters?
>
>One workaround Marc Vos contributed was to use the JDBC connector
>instead of the
>MySQL connector.  You can set the default character set to UTF-8 in the
>connection string.
>
>More about MySQL and how it handles character sets and connections is here:
>
>http://dev.mysql.com/doc/mysql/en/charset-connection.html
>
>- Bil
>

Thanks Bil,

I tried the SET NAMES 'UTF-8' and got no results back at all.
Checking through the console log, and found a MySQL error "1115,
Unknown character set: 'UTF-8'", so for everyone playing along at
home, the correct syntax for MySQL 4.1.x is

SET NAMES 'utf8';
SELECT ...

And like magic the results were returned correctly as you predicted.
I had a bit of a play with using the JDBC connector today, but gave
up after an hour with no success.  May try it again tomorrow when I
have a bit more time.

Going forward I can see 3 options:

1. Set all the table encoding settings to ISO-8859-1 even though they're not.
2. Prefix all my SELECT statements with SET NAMES. I can't see any
real performance issue with this, but only works as long as I do all
my DB stuff using -sql.
3. Revert my tables back to ISO-8859-1 as UTF-8 isn't a must have for
what I am doing. I just went that way since it it was the IN THING.

There must be a performance impact in doing option 1, but I can't see
any thing really measurable with what I've been playing with so far.
But I think I'll go with option 1. for the mean time.

- Wade

--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Table Encoding LP8

Bil Corry
In reply to this post by Wade Maxfield
> And like magic the results were returned correctly as you predicted.

So it appears the MySQL connector will only connect using ISO-8859-1.  Or we're
doing something wrong.


> 2. Prefix all my SELECT statements with SET NAMES. I can't see any
> real performance issue with this, but only works as long as I do all
> my DB stuff using -sql.

You can use nested inlines to allow using SET NAMES with regular Lasso inlines.



- Bil

------

Bil Corry
[hidden email]

Enterprise internet application development and security consulting
  http://www.fivegeeks.com/

Tools for Rapid Lasso Development
  http://www.lassoware.com/
 
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of
Wade Maxfield
Sent: Sunday, May 29, 2005 11:33 PM
To: [hidden email]
Subject: Re: Table Encoding LP8

>  > I've been following the thread on Page encoding,
>>  and have a related problem.
>
>I have a guess.  When I started using MySQL 4.1, I thought it would be worldly
>of me to make my tables UTF-8 encoded.  I then started using it with
>MySQL only
>to find collation problems that could only be corrected by prefixing every sql
>query with the SET NAMES command.  The issue was I couldn't get the built-in
>MySQL connector to connect to MySQL in anything other than ISO-8859-1.  So I
>gave up and switched back to ISO-8859-1 for my tables.
>
>So my guess is perhaps you're seeing it too.  MySQL will return data in the
>character encoding the client specifies (which my guess is
>ISO-8859-1), even if
>the table is UTF-8.  So MySQL returns ISO-8859-1, but telling Lasso it's UTF-8
>causes Lasso to munge the data since it's really ISO-8859-1.  That's
>why telling
>Lasso it's ISO-8859-1 (or omitting -table) makes it work.
>
>Anyhow, that's my guess.
>
>To test it, set the table encoding back to UTF-8, then execute a query that
>forces MySQL to return UTF-8:
>
> SET NAMES 'UTF-8';
> SELECT myAccentedChars
> FROM myUTF8Table;
>
>Does Lasso now correctly show the characters?
>
>One workaround Marc Vos contributed was to use the JDBC connector
>instead of the
>MySQL connector.  You can set the default character set to UTF-8 in the
>connection string.
>
>More about MySQL and how it handles character sets and connections is here:
>
>http://dev.mysql.com/doc/mysql/en/charset-connection.html
>
>- Bil
>

Thanks Bil,

I tried the SET NAMES 'UTF-8' and got no results back at all.
Checking through the console log, and found a MySQL error "1115,
Unknown character set: 'UTF-8'", so for everyone playing along at
home, the correct syntax for MySQL 4.1.x is

SET NAMES 'utf8';
SELECT ...

And like magic the results were returned correctly as you predicted.
I had a bit of a play with using the JDBC connector today, but gave
up after an hour with no success.  May try it again tomorrow when I
have a bit more time.

Going forward I can see 3 options:

1. Set all the table encoding settings to ISO-8859-1 even though they're not.
2. Prefix all my SELECT statements with SET NAMES. I can't see any
real performance issue with this, but only works as long as I do all
my DB stuff using -sql.
3. Revert my tables back to ISO-8859-1 as UTF-8 isn't a must have for
what I am doing. I just went that way since it it was the IN THING.

There must be a performance impact in doing option 1, but I can't see
any thing really measurable with what I've been playing with so far.
But I think I'll go with option 1. for the mean time.

- Wade



--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Table Encoding LP8

cJJUNnH41s90Y
In reply to this post by Wade Maxfield
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Table Encoding LP8

Bil Corry
In reply to this post by Wade Maxfield
> It will connect using its default charset, which happens to be ISO-8859-1.

Well, as a client Lasso can specify the default charset with each connection opened.  Or at least that's my understanding of it from here:

http://dev.mysql.com/doc/mysql/en/charset-connection.html


So from previous conversations about this topic, I believe specifying the -table param of the inline should cause Lasso to open a connection to MySQL using the table's charset (as selected in Lasso Admin) so then you receive the data back in the same charset from MySQL.  But it appears Lasso doesn't do that.


- Bil

------

Bil Corry
[hidden email]

Enterprise internet application development and security consulting
  http://www.fivegeeks.com/

Tools for Rapid Lasso Development
  http://www.lassoware.com/
 
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of noah williamsson
Sent: Monday, May 30, 2005 2:51 AM
To: [hidden email]
Subject: Re: Table Encoding LP8

[hidden email] wrote:
>>  And like magic the results were returned correctly as you predicted.
>
> So it appears the MySQL connector will only connect using ISO-8859-1.
>  Or we're
> doing something wrong.

It will connect using its default charset, which happens to be ISO-8859-1.

Try something like this (btw, there are collation* vars too):
         '<br>Default charset <br>\n';
         inline: $site_user, -database='tng', -sql='SHOW VARIABLES LIKE
"char%"';
         records; (field: 'Variable_name') +'    =       ' + (field:
'Value') + '<br>\n'; /records;
         /inline;

         '<br>With NAMES utf8<br>\n';
         inline: $site_user, -database='tng', -sql='SET NAMES "utf8";
SHOW VARIABLES LIKE "char%"';
         records; (field: 'Variable_name') +'    =       ' + (field:
'Value') + '<br>\n'; /records;
         /inline;


The output will be similar to the following, depending on your
configuration:

   Default charset
   character_set_client = latin1
   character_set_connection = latin1
   character_set_database = utf8
   character_set_results = latin1
   character_set_server = latin1
   character_set_system = utf8
   character_sets_dir = /usr/share/mysql/charsets/

   With NAMES utf8
   character_set_client = utf8
   character_set_connection = utf8
   character_set_database = utf8
   character_set_results = utf8
   character_set_server = latin1
   character_set_system = utf8
   character_sets_dir = /usr/share/mysql/charsets/

What these means are explained in the mysql reference manual on charsets
linked previously in this thread.


>
>
>>  2. Prefix all my SELECT statements with SET NAMES. I can't see any
>>  real performance issue with this, but only works as long as I do all
>>  my DB stuff using -sql.
>
> You can use nested inlines to allow using SET NAMES with regular Lasso
> inlines.
>

I haven't been able to insert a character that's not represented in
latin1 (&euro; for example) in my test table yet, not even using SET NAMES.
Am i doing anything wrong here?
Or does Lasso convert the whole query string to iso-8859-1
before passing it down to libmysqlclient?


Here's my test table
--------------------
mysql> show create table test\G
*************************** 1. row ***************************
        Table: test
Create Table: CREATE TABLE `test` (
   `txt` text collate utf8_swedish_ci NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_swedish_ci


..and the code i used
---------------------
// Truncate table
inline: $site_user, -database='tng', -sql='TRUNCATE test';
         if: (error_currenterror: -errorcode); 'Error 1: ' +
error_currenterror; /if;
/inline;

// Try insert a non-ISO-8859-1 character using -sql
var: 'q' = 'SET NAMES "utf8";INSERT INTO test VALUES("' + (encode_sql:
(decode_html: '&euro;')) + '")';
inline: $site_user, -database='tng', -sql=$q;
         'Query 1: ' + $q + '<br>\n';
         if: (error_currenterror: -errorcode); 'Error 2: ' +
error_currenterror; /if;
/inline;

// Try insert it using a standard inline
inline: $site_user, -database='tng', -table='test', 'txt'=(decode_html:
'&euro;'), -add;
         if: (error_currenterror: -errorcode); 'Error 3: ' +
error_currenterror; /if;
/inline;

// Display the two rows
inline: $site_user, -database='tng', -sql='SET NAMES "utf8" ; SELECT
HEX(txt) AS txt FROM test';
         if: (error_currenterror: -errorcode); 'Error 4: ' +
error_currenterror; /if;
         records;
                 'Row ' + loop_count + ' [' + (field: 'txt') + ']<br>\n';
         /records;
/inline;


Test 1 output - table encoding set to ISO-8859-1 (default)
----------------------------------------------------------
   Query 1: SET NAMES "utf8";INSERT INTO test VALUES("€")
   Row 1 [1A]
   Row 2 [1A]


Test 2 output - table encoding set to utf-8
-------------------------------------------
   Query 1: SET NAMES "utf8";INSERT INTO test VALUES("€")
   Row 1 [1A]
   Row 2 [C3A2E2809AC2AC]


Seems like there's a loss of information when it's not possible to
represent the data in iso-8859-1.

   -- noah

--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage



--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Table Encoding LP8

Michael Coninx
In reply to this post by Wade Maxfield
noah williamsson wrote:

Since Noah gave the example of trying to save the euro sign, I can
confirm that this
is a problem I also am experiencing.

(The following text I already send to Omnipilot as well, so far no reply...)

Problem saving windows-1252 characters

I have been trying to get Lasso 7 to correctly save characters like the
euro sign (?) in MySql, but haven't
succeeded yet. When I submit a form, Lasso encodes the characters
correctly when I output
them on the processing format file, however saving those characters in
MySql goes wrong.

I tried this with LP 7.1.1. and Embedded MySql 4.0.16, and with LP
7.1.3. and Embedded MySql 4.1.9.
Both have UTF-8 as default encoding in Lasso Admin, and are on Mac OS 10.3.x
with WebStar V as Webserver.

On out test server with LP 7.1.3. I tried to use the new -EncodeType
tag, and also changed the character set
of the MySql column I saved the text in to UTF-8, but the characters
still get screwed up...

Do I have to check all input and change the extended Windows-1252
characters to their
html entities to solve this manually, or is this a bug in Lasso's MySql
connector maybe?
In theory certainly the new MySql 4.1.9 should have no problems
whatsoever to save
these kind of characters correctly.

All following windows-1252 characters are saved incorrect: (attached an
UTF text file version)

? &euro; EURO SIGN
? &sbquo; SINGLE LOW-9 QUOTATION MARK
? &fnof; LATIN SMALL LETTER F WITH HOOK
? &bdquo; DOUBLE LOW-9 QUOTATION MARK
? &hellip; HORIZONTAL ELLIPSIS
? &dagger; DAGGER
? &Dagger; DOUBLE DAGGER
? &circ; MODIFIER LETTER CIRCUMFLEX ACCENT
? &permil; PER MILLE SIGN
? &Scaron; LATIN CAPITAL LETTER S WITH CARON
? &lsaquo; SINGLE LEFT-POINTING ANGLE QUOTATION MARK
? &OElig; LATIN CAPITAL LIGATURE OE
? &#381; LATIN CAPITAL LETTER Z WITH CARON
? &lsquo; LEFT SINGLE QUOTATION MARK
? &rsquo; RIGHT SINGLE QUOTATION MARK
? &ldquo; LEFT DOUBLE QUOTATION MARK
? &rdquo; RIGHT DOUBLE QUOTATION MARK
? &bull; BULLET
? &ndash; EN DASH
? &mdash; EM DASH
? &tilde; SMALL TILDE
? &trade; TRADE MARK SIGN
? &scaron; LATIN SMALL LETTER S WITH CARON
? &rsaquo; SINGLE RIGHT-POINTING ANGLE QUOTATION MARK
? &oelig; LATIN SMALL LIGATURE OE
? &#382; LATIN SMALL LETTER Z WITH CARON
? &Yuml; LATIN CAPITAL LETTER Y WITH DIAERESIS

Anyone able to save these characters correctly in MySql using
LP 7.1.1. or 7.1.3. ?

Michael

> [hidden email] wrote:
>
>>>  And like magic the results were returned correctly as you predicted.
>>
>>
>> So it appears the MySQL connector will only connect using ISO-8859-1.
>>  Or we're
>> doing something wrong.
>
>
> It will connect using its default charset, which happens to be
> ISO-8859-1.
>
> Try something like this (btw, there are collation* vars too):
>         '<br>Default charset <br>\n';
>         inline: $site_user, -database='tng', -sql='SHOW VARIABLES LIKE
> "char%"';
>         records; (field: 'Variable_name') +'    =       ' + (field:
> 'Value') + '<br>\n'; /records;
>         /inline;
>
>         '<br>With NAMES utf8<br>\n';
>         inline: $site_user, -database='tng', -sql='SET NAMES "utf8";
> SHOW VARIABLES LIKE "char%"';
>         records; (field: 'Variable_name') +'    =       ' + (field:
> 'Value') + '<br>\n'; /records;
>         /inline;
>
> The output will be similar to the following, depending on your
> configuration:
>
>   Default charset
>   character_set_client = latin1
>   character_set_connection = latin1
>   character_set_database = utf8
>   character_set_results = latin1
>   character_set_server = latin1
>   character_set_system = utf8
>   character_sets_dir = /usr/share/mysql/charsets/
>
>   With NAMES utf8
>   character_set_client = utf8
>   character_set_connection = utf8
>   character_set_database = utf8
>   character_set_results = utf8
>   character_set_server = latin1
>   character_set_system = utf8
>   character_sets_dir = /usr/share/mysql/charsets/
>
> What these means are explained in the mysql reference manual on
> charsets linked previously in this thread.
>
>>
>>
>>>  2. Prefix all my SELECT statements with SET NAMES. I can't see any
>>>  real performance issue with this, but only works as long as I do all
>>>  my DB stuff using -sql.
>>
>>
>> You can use nested inlines to allow using SET NAMES with regular
>> Lasso inlines.
>>
>
> I haven't been able to insert a character that's not represented in
> latin1 (&euro; for example) in my test table yet, not even using SET
> NAMES.
> Am i doing anything wrong here?
> Or does Lasso convert the whole query string to iso-8859-1
> before passing it down to libmysqlclient?
>
> Here's my test table
> --------------------
> mysql> show create table test\G
> *************************** 1. row ***************************
>        Table: test
> Create Table: CREATE TABLE `test` (
>   `txt` text collate utf8_swedish_ci NOT NULL
> ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_swedish_ci
>
> ..and the code i used
> ---------------------
> // Truncate table
> inline: $site_user, -database='tng', -sql='TRUNCATE test';
>         if: (error_currenterror: -errorcode); 'Error 1: ' +
> error_currenterror; /if;
> /inline;
>
> // Try insert a non-ISO-8859-1 character using -sql
> var: 'q' = 'SET NAMES "utf8";INSERT INTO test VALUES("' + (encode_sql:
> (decode_html: '&euro;')) + '")';
> inline: $site_user, -database='tng', -sql=$q;
>         'Query 1: ' + $q + '<br>\n';
>         if: (error_currenterror: -errorcode); 'Error 2: ' +
> error_currenterror; /if;
> /inline;
>
> // Try insert it using a standard inline
> inline: $site_user, -database='tng', -table='test',
> 'txt'=(decode_html: '&euro;'), -add;
>         if: (error_currenterror: -errorcode); 'Error 3: ' +
> error_currenterror; /if;
> /inline;
>
> // Display the two rows
> inline: $site_user, -database='tng', -sql='SET NAMES "utf8" ; SELECT
> HEX(txt) AS txt FROM test';
>         if: (error_currenterror: -errorcode); 'Error 4: ' +
> error_currenterror; /if;
>         records;
>                 'Row ' + loop_count + ' [' + (field: 'txt') + ']<br>\n';
>         /records;
> /inline;
>
> Test 1 output - table encoding set to ISO-8859-1 (default)
> ----------------------------------------------------------
>   Query 1: SET NAMES "utf8";INSERT INTO test VALUES("?")
>   Row 1 [1A]
>   Row 2 [1A]
>
> Test 2 output - table encoding set to utf-8
> -------------------------------------------
>   Query 1: SET NAMES "utf8";INSERT INTO test VALUES("?")
>   Row 1 [1A]
>   Row 2 [C3A2E2809AC2AC]
>
> Seems like there's a loss of information when it's not possible to
> represent the data in iso-8859-1.
>
>   -- noah
>


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage