機種依存文字(姓・名)のインポートについて | Community
Skip to main content
New Participant
June 14, 2017
Solved

機種依存文字(姓・名)のインポートについて

  • June 14, 2017
  • 4 replies
  • 413 views

JMUGの皆さま

お世話になっております。京セラドキュメントソリューションズ 小川と申します。

初めての投稿にて恐縮です。

"郞"や"髙"といった機種依存文字を含んだcsvファイルをインポートしようとすると永久的に処理が実行され、リロードするとエラーとなり、結果敵にインポートできません。

また、数百行リードがある場合は、どの行がエラーなのかをマルケトには表示されないため、目視などで対応が必要なようです。

皆さまは、どのように対応されておりますでしょうか?

※なお、弊社では、とりあえずは以下の360文字を含むリードが含まれていないかをエクセル関数にて検知し、

 該当リードを除外してインポートするようにしております。

【みんなの知識 ちょっと便利帳】使いたいときの HTML特殊文字 & 機種依存文字 - 漢字 (360文字)

何卒、よろしくお願い致します。

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Taishi_Yamada

@Yusaku Ogawa さん、こんにちは

この文字コード問題。意外と正しい答えに行き着くのが難しい話のと、知らないでor楽観して運用していると恐るべき事に陥る罠の1つなのでご注意ください。そんな私はマルケト運用初期のころに、悪夢の3万リード文字化け事件という経験をし、そこから気をつけるようになりました。

もしかしたら結論として「UTF-8変換はした上での症状ですよ」ということかもしれませんがその際はご了承ください。

コメントされた安藤さんも、もしや、まだ危険地帯におられるかもしれない。。。という気もしたので、私からもコメントさせて頂きます。

まず、大丈夫という認識はあったのですが、一応心配になったので、試しに「髙」の文字をFirst NameにしたListを作ってImportしましたが、特に問題なく処理されました(List Importは常に慎重)。下記の通りです。

UIは英語ですけど、そこは動作に関係ないです。

さて、これですが、"文字コード"は残念ながら今でも気をつけなければ行けない日本語の悩みの1つです。

そして、私もそうですが、なまじ長くコンピュータを触ってきた方ほど、今時の文字コードの扱いでハマる(=誤解がある)かもしれません。

「半角英数字は1バイト、全角は2バイト」と、思っている方!(=私も長らくそうでしたけど)。危険です。ご注意ください

今の常識は「全角は3バイト(だいたい)」です。そして、全角3バイトなおかげで、昔は機種依存文字だったものの多くが、依存文字のレッテルを剥がされています。

細かい話は長くなるので割愛しつつの説明ですが、Importに使うファイルをExcelで作業されたあとに文字コードをUTF-8に変更する処理を別途されていますか?マルケト含めて、今時のモダンなシステムは文字コードにUTF-8を使っています。UTF-8の場合、漢字の「髙」などもしっかりコードが割り振られているので文字が化けることは基本ありません。

こちら、その該当部分のMarketo Docsです。下記は英語の注意書き。

Import a List of People - Marketo Docs - Product Docs

同じ部分の日本語版の注意書きです。

後半に一行たされてますね。

残念ながらExcelはファイル保存時に直接文字コードをUTF-8にしてCSVを保存することができません。そのため、CSVに保存した後で、そのファイルを別のツールでShift-JIS→UTF-8に変換してあげる必要があります。

一番簡単なのは、Windowsなら「メモ帳」で可能です。メモ帳でCSVファイルを開いて、保存時に「UTF-8」というオプションが選べるのでそれで保存すればUTF-8形式のCSVファイルが完成します。

変換が面倒。。。ということであれば、Excelで"unicode形式"で保存したファイルを使う手段もあります(この場合、全ての文字が1文字4バイト)。それで読み込んでもImportできます。ただし。。。。私は気味が悪いので、手間ですがUTF-8に自前で変換したファイルをImportに使うようにしています。なぜなら、Marketoからアウトプットする(Webやメールなど)ときに使われる文字コードがUTF-8なので素直にそのままデータが流れてくれる(はずだ)からです。色々なトラウマがあるので慎重です

最後に、メールの送り先、Webの閲覧時などで、無事に入れた文字が正しく表示されるか?という心配についてですが、B2Bならちょっと昔のPCやスマートフォン程度なら問題ないので、そこまで心配しなくても良いかなと割り切ってます。B2Cでという場合、私はキャリアメールなどの今時事情に詳しくないので、そのあたりは分かりません(B2Bの担当なもので。。。)。

以上、ご参考までに。

最後に「Excelでunicode形式で保存したファイルそのまま多数Importしてるけど問題ないよ!」という方おられましたら教えてください。

-Yamada

4 replies

June 15, 2017

株式会社ビジョンの地藤と申します。

文字コードの件は解決されそうですのでエラーのお話ですが、インポート時にエラーになった場合はエラー箇所より以前のレコードはリードにインポート出来ていると認識しております。

私もマルケト歴は短いのですがファウンデーショントレーニングの際にエラーが起きた際の処理について疑問があり別途確認をした際に上記の返答をいただきました。

検証をしていないので、こうであると回答できず恐縮ですがエラーの際にご確認いただければと思います。

YusakuOgAuthor
New Participant
June 16, 2017

@地藤 祐史​ 様

ご返信ありがとうございます。

下記、インポートに関する情報、大変感謝致します。

今回は延々と読み込み画面が続いたためF5リロードをかけてしまったため、登録件数が0件になってしまいましたが、

次回の対応の参考とさせていただきます。

何卒、よろしくお願い致します。

June 15, 2017

@Yusaku Ogawa​ さま、Yamadaさまのご説明の通り、もしエンコード変換の処理をされていないようでしたら

 上手くインポートができない可能性があります。

 昔はMarketoのデータインポート実行ボタンを押した後、かなり処理に時間がかかったようで、

 永遠に読み込めないような印象も記憶していますが、今はしっかり改善されエンコード変換を行っていれば

 すんなりインポートできるはずです。Yamadaさまの検証通り、機種依存文字が原因で読み込めないわけではないと思います。

 また、Yamadaさまのアドバイス通り、インポート作業はやろうと思えばカンタンにできてしまうので、

 楽観&知識不足で進めてしまい、苦い思いを後でする例を散見していますので、ぜひ慎重に行っていただくと

 よろしいと思います。

@Taishi Yamada​ さま、追加のご説明ありがとうございました!

 私のご心配もありがとうございます。幸い文字コード変換は必ずUTF8に変換しているので、私の方は大丈夫です

 データインポートはDBを台無しにできるレベルの作業と認識しており、ルーティン作業の確認フローを徹底しています。

Taishi_Yamada
Community Manager
June 15, 2017

>>データインポートはDBを台無しにできるレベルの作業と認識しており

私も3万レコードの文字化けを発生させたときは苦労しました(しかも単に上書きができないレコードだったので修復が悲惨でしたね)。。。。

運用上、大事な点の1つですね

June 16, 2017

ああ・・・お察しします。ただ一度失敗すると、そのイチ作業が持っている本来のインパクトを知ることができますよね。

リードインポートは、Marketo操作の中でも日常的に発生&難度高で罠が満載と個人的に思って、

一個づつ慎重なルーティン作業を確立したのですが、みなさんはこんな大変な作業どうしているのかな?と漠然と思ってました。

外資企業などでは本国の権限のある一部の担当者にしかデータインポートさせないよう徹底してたりしますね。

データインポートは地味な内容なのであまり話題性がなく、今回有意義なディスカッションがでてきとても勉強になりました。

ありがとうございました!!

これからもよろしくお願いいたします

Taishi_Yamada
Taishi_YamadaAccepted solution
Community Manager
June 14, 2017

@Yusaku Ogawa さん、こんにちは

この文字コード問題。意外と正しい答えに行き着くのが難しい話のと、知らないでor楽観して運用していると恐るべき事に陥る罠の1つなのでご注意ください。そんな私はマルケト運用初期のころに、悪夢の3万リード文字化け事件という経験をし、そこから気をつけるようになりました。

もしかしたら結論として「UTF-8変換はした上での症状ですよ」ということかもしれませんがその際はご了承ください。

コメントされた安藤さんも、もしや、まだ危険地帯におられるかもしれない。。。という気もしたので、私からもコメントさせて頂きます。

まず、大丈夫という認識はあったのですが、一応心配になったので、試しに「髙」の文字をFirst NameにしたListを作ってImportしましたが、特に問題なく処理されました(List Importは常に慎重)。下記の通りです。

UIは英語ですけど、そこは動作に関係ないです。

さて、これですが、"文字コード"は残念ながら今でも気をつけなければ行けない日本語の悩みの1つです。

そして、私もそうですが、なまじ長くコンピュータを触ってきた方ほど、今時の文字コードの扱いでハマる(=誤解がある)かもしれません。

「半角英数字は1バイト、全角は2バイト」と、思っている方!(=私も長らくそうでしたけど)。危険です。ご注意ください

今の常識は「全角は3バイト(だいたい)」です。そして、全角3バイトなおかげで、昔は機種依存文字だったものの多くが、依存文字のレッテルを剥がされています。

細かい話は長くなるので割愛しつつの説明ですが、Importに使うファイルをExcelで作業されたあとに文字コードをUTF-8に変更する処理を別途されていますか?マルケト含めて、今時のモダンなシステムは文字コードにUTF-8を使っています。UTF-8の場合、漢字の「髙」などもしっかりコードが割り振られているので文字が化けることは基本ありません。

こちら、その該当部分のMarketo Docsです。下記は英語の注意書き。

Import a List of People - Marketo Docs - Product Docs

同じ部分の日本語版の注意書きです。

後半に一行たされてますね。

残念ながらExcelはファイル保存時に直接文字コードをUTF-8にしてCSVを保存することができません。そのため、CSVに保存した後で、そのファイルを別のツールでShift-JIS→UTF-8に変換してあげる必要があります。

一番簡単なのは、Windowsなら「メモ帳」で可能です。メモ帳でCSVファイルを開いて、保存時に「UTF-8」というオプションが選べるのでそれで保存すればUTF-8形式のCSVファイルが完成します。

変換が面倒。。。ということであれば、Excelで"unicode形式"で保存したファイルを使う手段もあります(この場合、全ての文字が1文字4バイト)。それで読み込んでもImportできます。ただし。。。。私は気味が悪いので、手間ですがUTF-8に自前で変換したファイルをImportに使うようにしています。なぜなら、Marketoからアウトプットする(Webやメールなど)ときに使われる文字コードがUTF-8なので素直にそのままデータが流れてくれる(はずだ)からです。色々なトラウマがあるので慎重です

最後に、メールの送り先、Webの閲覧時などで、無事に入れた文字が正しく表示されるか?という心配についてですが、B2Bならちょっと昔のPCやスマートフォン程度なら問題ないので、そこまで心配しなくても良いかなと割り切ってます。B2Cでという場合、私はキャリアメールなどの今時事情に詳しくないので、そのあたりは分かりません(B2Bの担当なもので。。。)。

以上、ご参考までに。

最後に「Excelでunicode形式で保存したファイルそのまま多数Importしてるけど問題ないよ!」という方おられましたら教えてください。

-Yamada

YusakuOgAuthor
New Participant
June 15, 2017

@Taishi Yamada 様

ご返信いただき有難うございます。

また、検証まで実施いただき、大変感謝申し上げます。

私自身、文字コードについてあまり知識がないままに業務を進めておりましたので

改めて最低限の知識は勉強しておくべきだと感じました。

私の方で実施したテストについて少し補足させていただきます。

以下のような内容でテストインポートcsvを作成

Excel2016であれば、「名前を付けて保存」の際に、

下部にある"ツール(L)"⇒"Webオプション"⇒"エンコード"⇒"このドキュメントを保存する形式(S):"⇒"Unicode(UTF-8)"を選択

にて文字コード指定保存ができるようです。

今回はこちらを使って文字コード指定保存を行いました。

マルケトにて、上記のcsvファイルをインポートしようと試みましたが

以下の画面から先のステップへ進むことができませんでした。

何卒、よろしくお願い致します。

Taishi_Yamada
Community Manager
June 15, 2017

@Yusaku Ogawa​さん、

やはり、その罠にハマってしまいましたか。。。ええ、私も最初そのオプションでぬか喜びした者です。

実はそのオプション「Webオプション」と書かれているとおり、「html形式で保存したときのみ」有効なオプションなのです。

CSVで保存したときには、そのオプションは作用しないようです。

実際のファイルの中身をバイナリエディタでコード確認してみると、下記のようになります。

1つ目が、普通にExcel 2016でCSV保存したファイル。「髙」と一文字書いたものです。

髙はFBFCが該当します。

2つ目が、CSV保存した後、メモ帳でUTF-8を選んで保存したファイルです。

髙の文字がE9AB99のUTF-8のコードに変わっています(その前のEFBBBFはメモ帳が自動的に付けてしまうコードで無視して構いません)

3つ目が、例のWebオプションからエンコードUTF-8を選んで、CSV保存したファイルです。

ですが、内容が1つ目のファイルと同じですね。ようするにUTF-8で保存されていない。ということです。

Marketoの仕様としては、ShiftJISでもImportは可能なので、Importが終わらないというのは別の問題とも考えられますが、ファイルの保存としてはUTF-8になっていないのでご注意ください。

ただ。。。。もう少し厳密に言うと、ShiftJISのオリジナルのコード表には「髙」は入っていないのです。Microsoftが独自に拡張した文字コード体系でFBFCとして示されています。

ここから先、完全な推測なんですが。。。。たしかMySQL(Marketoが使っているDB)には文字コードを変換するモジュールがありまして、それにはShift-JISとは別にそのMS独自拡張のShift-JIS版があるのです。もしかしたら、Marketoは前者は使えるようにしているが、後者は対応していない。。。。ということがあるのカモしれません。

いずれにしても、UTF-8に確実に変換したファイルを扱うのが余計な問題に当たらなくて済むことには変わらないですね。

June 14, 2017

小川さま、はじめまして。株式会社メジャースの安藤と申します。

MarketoでもMarketo以外のシステムでも数え切れないほどデータインポートをしてきた経験があり、

機種依存文字で苦い思い出も多々あります。

直接の回答にはならないと思うので恐縮ですが、何かお役に立つことがあれば幸いです。

基本的に、機種依存文字が幸いインポートできたとしても、その後思わぬトラブルを招くことがあり、

私は極力排除するようにしています。

例えば、はしごの"髙"は姓に多くありますが、トークン設定したメール内で「髙橋さま」としたい場合、

Marketoでは上手く表示できても「髙橋さま」ご本人が受領したメールでは「?$%#橋さま」という残念な文字化け現象で

クレームが発生することは十分に考えられます。機種依存文字である限り、あくまでメーラーに依存するので仕方ない現象です。

(クレームがないのはこれまで見過ごしてくれてラッキー、という程度と思います)

株式会社をPCで変換した際に出る略称の㈱も同じく依存文字なので、

このような文字はインポート手前のデータ整理の段階で、一般的な文字に置換してからインポートしています。

㈱⇒株式会社

姓名を勝手に修正するのは、ご本人が名乗る実際の漢字ではないのでそれはそれで失礼だと思うのですが、

データ管理上、しかたない妥協と割り切っています。

標準化した名前でメールを受け取るのと、文字化けした名前でメールを受け取るのでは、

また標準化されている方が心理的にましと思いますし・・・

ただ、何でもかんでも毎回機種依存文字の修正は手間がかかり、

インポート作業は頻繁に発生するので工数に対し効果が低いと思います。

そのため私は機種依存文字は本当に頻繁に見かける文字「㈱」など以外は、あまり気にせずインポートしています。

その代わり、メールで姓名のトークンをしない、など、リードとのコミュニケーションフローの中で

少しでもリスク排除できるプロセスを常に検討しています。(その方が圧倒的に楽なので・・・)

また、Marketoに読み込めないのはサポートデスクにフォローアップしていただいた方が良いと思います。

YusakuOgAuthor
New Participant
June 15, 2017

安藤様

ご返信いただき有難うございます。

まだMarketoローンチパック受講中の身である私にとって、コメントいただいた内容は大変勉強になります。

弊社でも、機種依存文字は極力排除する方向で検討していくようできればと思います。

>ご本人が受領したメールでは「?$%#橋さま」という残念な文字化け現象でクレームが発生することは十分に考えられます

>メールで姓名のトークンをしない、など、リードとのコミュニケーションフローの中で少しでもリスク排除できるプロセスを常に検討

上記のような視点は、全く持てていなかったため、大変有り難く存じます。

是非、社内メンバーにも共有させていただき、議論を進めてまいります。

何卒、よろしくお願い致します。