#953 1.3.36 r6528 UTF8 characters messed up on from the DB

1.3
closed-fixed
Chris Travers
None
5
2014-01-21
2014-01-18
Pongracz Istvan
No

It seems one or more of the last modifications caused an issue in the UTF8 rendering.
UTF8 strings from the DB shown as messed texts.
Like this: Pályázatnélkül Demó Kft.

1 Attachments

Discussion

  • Confirmed, installing brand new DB with stock 1.3.36 (svn r6528) produces the same effect.

    Firefox and Chromium, same.

     
    Last edit: Pongracz Istvan 2014-01-18
  • Erik Huelsmann
    Erik Huelsmann
    2014-01-19

    This patch fixes it:

    Index: lsmb-1.3/LedgerSMB/Template/HTML.pm

    --- lsmb-1.3/LedgerSMB/Template/HTML.pm (revision 6551)
    +++ lsmb-1.3/LedgerSMB/Template/HTML.pm (working copy)
    @@ -72,8 +72,10 @@
    push @{$vars}, preprocess( $_ );
    }
    } elsif (!$type) {
    + utf8::decode($rawvars);
    return escapeHTML($rawvars);
    } elsif ($type eq 'SCALAR' or $type eq 'Math::BigInt::GMP') {
    + utf8::decode($$rawvars);
    return escapeHTML($$rawvars);
    } elsif ($type eq 'CODE'){
    return $rawvars;

    But: WHY?!

    everywhere in the code, there are settings to transform PG input to utf8, so, this shouldn't be necessary....

     
  • I can confirm, it partially solved the issue.
    I still have it in the AR/Invoice dropdown.

     
  • Erik Huelsmann
    Erik Huelsmann
    2014-01-20

    Adding ", pg_enable_utf8 => 1"

    to the connect request in db_init (right after the AutoCommit => 0 which is already there) fixes the AR Transaction/AR Invoice dropdown for me.

    The fix seems to be to add that to any and all DBI->connect calls. Going to try that now.

     
  • I can confirm, Adding ", pg_enable_utf8 => 1" did the trick.

    I can see, the code usually use the following snippet:
    DBI->connect( $form->{dbconnect}, $form->{dbuser},
    $form->{dbpasswd} )
    or $form->dberror( FILE . ':' . LINE );
    $dbh->{pg_enable_utf8} = 1;

    Please note the $dbh->{pg_enable_utf8} = 1;

    This command seems missing in some places.
    With this modification the initial trick (+ utf8::decode($$rawvars);) is not necessary.

     
  • Chris fixed it in [r6577]
    Confirmed, it works well.

     

    Related

    Commit: [r6577]

    • status: open --> closed-fixed
    • assigned_to: Chris Travers