Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Add feature to bind as SQLWCHAR

オープン
#292 コメント 19 件 リアクション 6 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
30/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
javascript, node.js, sql
領域
databases

調査の方向性

SQL_CHAR、SQL_VARCHAR、SQL_CLOB のバインディング動作から始め、issue に記載されている SQL_C_CHAR と SQL_C_WCHAR のパスを比較してください。例 #284、#290、#291 を確認し、完成した変更で UNICODE 時に常に SQLWCHAR を使用するべきか、実行時オプションを提供するべきかを判断し、選択した動作をテストでカバーしてください。

索引モデルが issue の本文から書いたものです。

説明

confirmed

Windows is very UTF-16 centric while Node.js is very UTF-8 centric. While it can also handle UTF-16, it does not deal with other encodings well at all (at least in the NAPI addon). As a result, the package has been built as UNICODE since July 2020. This has fixed many encoding issues, since various strings are now passed back and forth using UTF-16 without issue. However, when binding, SQL_CHAR, SQL_VARCHAR, and SQL_CLOB types are still bound as SQL_C_CHAR, not SQL_C_WCHAR. This works most of the time, but there have been many issues when databases are in the native Windows encoding (which outside of an experimental feature is never UTF-8). See #284 #290 and #291 for examples.

While some drivers have settings to use UTF-8 instead, that is driver-specific and not all do. It would be much better to either always bind as SQLWCHAR when UNICODE is defined (ie. Windows) or add a runtime option to enable it (enabled by default when UNICODE is?)

主要言語
JavaScript
スター
159
フォーク
92
平均マージ
5時間 59分
マージ済み PR(30日)
3

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

IBM/node-odbc のほかの issue

IBM/node-odbc の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。