この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
DI部プリセールスエンジニアの兼本です。
Microsoft SQL Serverには固定長テキストデータ型として、char型とnchar型、可変長テキストデータ型として、varchar型とnvarchar型というデータ型が用意されています。
nchar型、nvarchar型の用途は明確で、日本語を含むマルチバイト文字をUnicoderとして格納したいときに使います。
char型とvarchar型はASCIのようなシングルバイトの文字列を格納するときに使うのが主流だと私は思っていますが、SQL Serverは、Shift-JISのデータもちゃんと格納してくれてしまうので（笑）、結構な確率でvarchar型のフィールドに日本語文字列が格納されています。
理想を言えば、そんなnchar型やnvarchar型にスキーマ変更して欲しいところですが、なかなかそうもいかないのが人の世の常です。
そんなとき、Alteryxではどうなる？
では本題です。 これらのデータをAlteryxで読み込んだとき、どのような動作になるでしょうか。 まずは、nvarchar型のデータを読み込んだ場合の動作です。
2019年4月1日と言えば新元号「令和」、「令和」といえば典拠は「万葉集」ということで、下記サイトで公開されている万葉集のテキストデータをSQL Serverに取り込んでみました。
元データがUTF-8なので、nvarchar型のカラムを持つテーブルを用意してインサートしました。
CREATE TABLE [dbo].[manyou_data_utf8](
[歌番号] [nvarchar](255) NULL,
[題詞] [nvarchar](255) NULL,
[原文] [nvarchar](873) NULL,
[訓読] [nvarchar](max) NULL,
[仮名] [nvarchar](max) NULL,
[左注] [nvarchar](292) NULL,
[校異] [nvarchar](423) NULL,
[事項] [nvarchar](255) NULL,
[寛永版本] [nvarchar](max) NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GOAlteryxでは、以下のようなシンプルなワークフローを作成します。
実行すると、以下のように結果を正しく取得できていることがわかります。
Alteryxで定義されたメタデータを見ると、nvarchar型のカラムはそれぞれ「V_WString」型というデータ型にマッピングされていることがわかります。
「V_WString」型はAlteryxではUnicodeを扱える文字列型で、日本語を含むマルチバイト文字を使いたいときには、このデータ型を指定する必要があります。
データベースのカラムがvarchar型だったら？
次にvarchar型のカラムを使ったテーブルを用意します。 ダウンロードしたテキストデータはUTF-8なので、テキストエディタなどで開いてShift-JISに変換して保存し直しました。 いくつかのテキストに対して文字コードを正しく変換できない旨を示す警告が出たのですが、今回の検証には影響しないので、無視します。
CREATE TABLE [dbo].[manyou_data_sjis](
[歌番号] [varchar](255) NULL,
[題詞] [varchar](max) NULL,
[原文] [varchar](max) NULL,
[訓読] [varchar](max) NULL,
[仮名] [varchar](max) NULL,
[左注] [varchar](max) NULL,
[校異] [varchar](max) NULL,
[事項] [varchar](max) NULL,
[寛永版本] [varchar](max) NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GOこのテーブルに作成したShif-JISのデータをインサートし、先ほどと同様のワークフローを作成して実行します。
ワークフローを実行すると、以下のように日本語テキストの部分が文字化けしていることがわかります。
メタデータを見ると、varchar型のデータはすべてV_String型というASCI文字しか扱えないデータ型にマッピングされています。
またこれらのデータは文字コードがShift-JISで送信されているため、このままでは日本語テキストを期待通りに表示することはできません。 でも、まだ諦めないでください。
データ自体は正しく受け取っているので、Shift-JISのデータをUnicodeに変換し、変換したデータをV_WString型のフィールドに格納してあげれば日本語テキストとして期待する結果で表示できるんです。
具体的には、以下のような処理をします。
選択ツール
選択ツールでは、V_String型のフィールド（この例では「題詞」）をV_WString型というUnicodeデータを扱えるデータ型に変更しています。
フォーミュラツール
フォーミュラツールでは、ConvertFromCodePage()という第一引数で渡した文字列の文字コードを第二引数で指定した文字コードからUnicodeに変換する関数を使用しています。「932」は「Shift-JIS」を意味しています。
この処理の結果、「題詞」フィールドに期待する日本語テキストが表示できました。
ただ、この作業を全てのフィールドに対して行うのはちょっと骨が折れますね。こういうときは先人の知恵に頼りましょう。 結構昔のエントリですが、複数フィールドフォーミュラを使って、同様の処理を一括で実行する方法が紹介されています。
先ほどのワークフローを複数フィールドフォーミュラを使うように変更します。
複数フィールドフォーミュラ
設定は以下の通り。最下段に型の不一致に関する警告が出ていますが、私の環境では正常に実行することができました。
実行結果を確認すると、日本語テキストがすべて変換されていることがわかります。
In-Databaseツールではどうなるの？
はい、In-Databaseツールを使ったときも同様に日本語が文字化けします。 しかしながら、フィルタIn-DBツールなどで日本語を指定することは問題なくできるため、大きく影響を受けるのは閲覧In-DBツールのみです。 これはAlteryxからSQL Serverに対してSQLクエリを実行する際にはUnicodeでSQL文を発行しているためと考えられます。 例えば、In-Databaseツールを使って「初春令月」という文字列でフィルタリングするELT処理を作成します。
実行すると32件のデータがヒットしました。
念の為、元になったCSVデータをExcelで検索したところ、32件のデータがヒットすることが確認できました。
まとめ
今回はSQL Serverのvarchar型データに含まれる日本語テキストが文字化けした場合の対処についてご紹介いたしました。
Alteryxの導入なら、クラスメソッドにおまかせください
日本初のAlteryxビジネスパートナーであるクラスメソッドが、Alteryxの導入から活用方法までサポートします。14日間の無料トライアルも実施中ですので、お気軽にご相談ください。
2
