为何node-firebird返回字节缓冲区而非字符串？如何将列值存入变量？

Hey there! Let's tackle your two issues step by step—first the Buffer problem with VARCHAR fields, then how to properly store your query results and return them to the client.

1. VARCHAR字段显示为Buffer的原因及修复 #

This happens because the node-firebird library defaults to returning raw byte buffers for string fields in Firebird, especially when there's no explicit character set mapping configured between your database and Node.js environment. Firebird stores strings as byte streams, and without telling the library how to decode those bytes into readable strings, Node.js uses Buffer to represent the raw data.

You have two straightforward fixes:

方法一：手动将Buffer转换为字符串 #

After fetching your query results, iterate through the rows and convert any Buffer fields to strings using the correct character set (match this to your Firebird database's charset—common options are utf8 or iso-8859-1):

db.query('SELECT * FROM GEMPRESA', function(err, result) {
  if (err) throw err;
  // Transform Buffer fields to readable strings
  const formattedResults = result.map(row => {
    const transformedRow = {...row};
    for (const key in transformedRow) {
      if (Buffer.isBuffer(transformedRow[key])) {
        transformedRow[key] = transformedRow[key].toString('utf8'); // Adjust charset if needed
      }
    }
    return transformedRow;
  });
  console.log(formattedResults); // Now you'll see "CITY: UBERABA"
  db.detach();
});

方法二：配置连接时指定字符集 #

Add a charset property to your connection options that matches your Firebird database's character set. This tells the library to automatically decode bytes into strings for you:

const options = {
  host: '127.0.0.1',
  database: 'C:/Users/alexandrefelix.GREENCANE/Desktop/Aulas/backend-firebird/src/TGA.FDB',
  user: 'SYSDBA',
  password: 'masterkey',
  charset: 'UTF8' // Use your database's actual charset here
};

2. Storing Query Results in a Variable & Fixing Async Flow #

Your current code has a critical async issue: you're returning the "Hello World" response before the database query finishes, and you're destroying the connection pool immediately (which can break the ongoing query). Let's refactor this using async/await to make the logic clearer and ensure you capture the results properly.

Here's the improved code:

const firebird = require('node-firebird');
const express = require('express');
const app = express();

// Create connection pool ONCE (not per request)
const options = {
  host: '127.0.0.1',
  database: 'C:/Users/alexandrefelix.GREENCANE/Desktop/Aulas/backend-firebird/src/TGA.FDB',
  user: 'SYSDBA',
  password: 'masterkey',
  charset: 'UTF8' // Add charset to avoid Buffer issues
};
const pool = firebird.pool(5, options);

app.get('/', async (req, res) => {
  let dbConnection;
  try {
    // Get a connection from the pool
    dbConnection = await new Promise((resolve, reject) => {
      pool.get((err, conn) => err ? reject(err) : resolve(conn));
    });

    // Execute query and get results
    const queryResults = await new Promise((resolve, reject) => {
      dbConnection.query('SELECT * FROM GEMPRESA', (err, data) => err ? reject(err) : resolve(data));
    });

    // Store results in a variable (you can manipulate this data here)
    const companyData = queryResults;
    console.log('Fetched company data:', companyData);

    // Return the actual data to the client
    res.json({ message: 'Data fetched successfully', data: companyData });
  } catch (err) {
    console.error('Error fetching data:', err);
    res.status(500).json({ error: 'Failed to retrieve data from database' });
  } finally {
    // Always release the connection back to the pool
    if (dbConnection) {
      dbConnection.detach();
    }
    // Only destroy the pool when the app shuts down, not per request
    // process.on('exit', () => pool.destroy());
  }
});

app.listen(3333, () => {
  console.log('Server running at http://localhost:3333');
});

Key improvements here: #

• Global connection pool: We create the pool once when the app starts, not every time a request comes in (this saves resources).
• Async/await for readability: No more nested callbacks—we handle async operations in a linear, easy-to-follow way.
• Proper error handling: Using try/catch ensures we catch and report any database errors to the client.
• Timely response: We only send the response after the query completes, so the client gets the actual database data instead of a placeholder message.
• Connection cleanup: The finally block guarantees we release the database connection back to the pool, preventing leaks.

内容的提问来源于stack exchange，提问作者Alexandre Felix