0

私は 26 の言語の翻訳を含む大規模なローカリゼーション システムを持っています。そのうちの 2 つは右から左 (アラビア語とヘブライ語) です。テストにより、ソフトウェア成果物に、翻訳者にまでさかのぼるいくつかの欠陥のある文字列が見つかりました (文字列の適切な位置にある RTL マーカーは含まれていません)。私はたまたま自分の IDE にいて、EF を使用して最近翻訳されたすべての文字列のリストを生成する簡単なコンソール アプリを作成しました。

今後これを QA プロセスに追加するために、クエリを実行するためのストアド プロシージャを作成したいと考えました。私の人生では、それを機能させることができず、キャラクターに対するクエリに関するドキュメントを見つけることができません。

私が見つけたのは、RTL マーカーが Unicode コードポイントの NCHAR(8207) または 16 進数の NCHAR(0x200F) であることです。私のデータベース照合順序は SQL_Latin1_General_CP1_CS_AS です。

ただし、次のようなクエリ:

declare @RTLM nchar
set @RTLM = NCHAR(8207)


  SELECT [Translation]
  FROM [dbo].[Translations]
  where Translation like '%' + @RTLM +'%'

GO

RTL マーカーが含まれているかどうかに関係なく、テーブル内のすべての文字列を返します。クエリで印刷可能な文字を探している場合、同じクエリは正常に機能します。16 進バージョンの NCHAR(0x200F) にも同じ動作が見られます。

何が起こっているのかについて考えている人はいますか?

4

1 に答える 1