#4263 (ok 4.1.7) Japanese character encoding not working properly when exporting from phpmyadmin.



I have been experiencing a problem that phpmyadmin does not encode the data to chosen charcter set when exporting as CSV file by export.php.

It's not only CSV format but perhaps all of kind of format available on export.php.

My database MySQL5.1 is set to use UTF-8 as its character set and I use Japanese character incuding Kanji. I can see them correctly on phpmyadmin when I execute SQL on it but when exporting the result of a query to a file they get corrupted.

I have found the solution and I would like you to include it to the future fix.

Adding "'knjenc'," into the array $post_params will fix this problem.

"$GLOBALS['knjenc']" is needed on line 336 of export.php to encode SQL query result into the user choice encoding but it it not in the array "$GLOBALS" as it is not in the array "$post_params".

I would like you to confirm this is the right way of fixing this problem and put same kind of fix in the near future release if possible.

Best regards,
Yukihisa Kitagawa


  • Madhura Jayaratne

    Hi Yukihisa,
    First of all I must tell you that my knowledge on Japanese encoding is very minimal.
    But looking at the code, if you chose Japanese as phpMyAdmin's interface language and then try to export a table you should see a couple of radio buttons to chose the correct encoding at the bottom of Export page.
    Can you do that and see whether the problem still persists.

  • Madhura Jayaratne

    • status: open --> pending
  • Yukihisa Kitagawa

    Hello Madhura,
    Thank you for your quick responce.
    Yes. When I choose Japanese as phpMyAdmin's interface language I see a couple of radio buttons which are 'none','EUC','SJIS'.

    I chose SJIS to export UTF-8 coded data expecting the data will be exported SJIS encoded but I got UTF-8 coded data.

    so I did some investigation to the export.php and the Export page.

    at the Export page, when I use japanese as its language I can see those html code.

    <form method="post" action="export.php" name="dump">
    <div class="exportoptions" id="kanji_encoding"><h3>エンコーディングへの変換:</h3>
    <li> <input type="radio" name="knjenc" value="" checked="checked" id="kj-none"><label for="kj-none">なし</label>
    <input type="radio" name="knjenc" value="EUC-JP" id="kj-euc"><label for="kj-euc">EUC</label>
    <input type="radio" name="knjenc" value="SJIS" id="kj-sjis"><label for="kj-sjis">SJIS</label>
    <li> <input type="checkbox" name="xkana" value="kana" id="kj-kana">
    <label for="kj-kana">全角カナへ変換する</label><br>

    This means export.php need to recognize the value I chose by the radio buttons with the name "knjec" and the value whatever I choose.

    Now I look at export.php.

    144 foreach ($post_params as $one_post_param) {
    145 if (isset($_POST[$one_post_param])) {
    146 $GLOBALS[$one_post_param] = $_POST[$one_post_param];
    147 }
    148 }

    this code shows that POSTed values are put into the array '$GLOBALS', and the array key is taken from the array called "$post_params".

    in this case the array "$post_params" has to have 'knjenc' as its value otherwise $GLOBALS won't have the value posted from the Export page named 'knjenc'.

    the value "$GLOBALS['knjenc']" is needed on line 336 of export.php.

    332 // Kanji encoding convert feature
    333 if ($GLOBALS['output_kanji_conversion']) {
    334 $line = PMA_Kanji_strConv(
    335 $line,
    336 $GLOBALS['knjenc'],
    337 isset($GLOBALS['xkana']) ? $GLOBALS['xkana'] : ''
    338 );
    339 }

    this is what I have found.


    Last edit: Yukihisa Kitagawa 2014-02-03
  • Madhura Jayaratne

    • assigned_to: Madhura Jayaratne
  • Madhura Jayaratne

    • summary: Japanese character encoding not working properly when exporting from phpmyadmin. --> (ok 4.1.7) Japanese character encoding not working properly when exporting from phpmyadmin.
    • status: pending --> resolved
    • Priority: 6 --> 1
  • Yukihisa Kitagawa

    Thank you for fixing the problems!


  • Marc Delisle

    Marc Delisle - 2014-02-09
    • Status: resolved --> fixed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks