PDO with firebird throws "�" ​when there is a "ñ" letter

Question

My table:

+--------+----------+
| U_COD  |  U_NAME  |
+--------+----------+
|   01   |  Daniel  |
+--------+----------+
|   02   |  Ñandu   |
+--------+----------+
|   03   |  Pañ     |
+--------+----------+

I am connecting and doing a simple query to my firebird database like this:

$host = 'firebird:dbname=my/dir/db_test.gdb;charset=UTF8';
$password = 'mypass';
$username = 'myuname';

try{
  $db = new PDO($host, $username, $password);
  $db->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
}catch(PDOException $e){
  echo "Failed: " . $e->getMessage();
}

$getData=$db->prepare("SELECT * FROM T_TEST ORDER BY U_NAME ASC");
$getData->execute();
$arrData=$getData->fetchAll(PDO::FETCH_ASSOC);
echo json_encode($arrData);

But when I run the file, all the values ​​that in my database include some "ñ" letter appear as null, like this:

[
    {"U_COD":"01","U_NAME":"Daniel"}, 
    {"U_COD":"02","U_NAME":null},
    {"U_COD":"03","U_NAME":null}
]

I would like to know what I'm doing wrong, let me know if you need any other details from my firebird database.

EDIT

a var_dump($arrData) shows the values but with a "�" when there should be a "ñ" letter:

array(3) {
  [0]=>
  array(2) {
    ["U_COD"]=>
    string(2) "01"
    ["U_NAME"]=>
    string(6) "Daniel"
  },
  array(2) {
    ["U_COD"]=>
    string(2) "02"
    ["U_NAME"]=>
    string(5) "�andu"
  },
  array(2) {
    ["U_COD"]=>
    string(2) "03"
    ["U_NAME"]=>
    string(3) "Pa�"
  }
}

Answer 1

The problem is that the character set of the column is NONE, and there is probably a mismatch between the bytes stored in the column (for example it was stored using an encoding like WIN1252), and your connection character set (UTF8). Given the source column has no explicit character set, Firebird cannot transliterate the characters to the connection character set, and instead the bytes are sent as is, and the byte for ñ is not valid in UTF8, so PHP replaces it with the unicode replacement character.

As a short term solution, you could try to explicitly specify the correct connection character set (eg WIN1252) or explicitly cast the column (eg cast(U_NAME as varchar(100) character set win1252)), but for the long term solution, you need to make sure that you define your columns with an explicit character set. In your current setup, you are likely logically corrupting your data if you write data from multiple applications, each using their own implicit or explicit connection character set (eg one application writes using WIN1252, another using UTF8, then - without an explicit character set of the column - one cannot correctly read data written by the other).