GeoJSONを使うと、点・線・面などの位置情報と、名称、住所、管理番号、現場メモ、分類名などの属性情報をひとつのデータとして扱えます。ところが、座標は正しく表示されているのに、属性欄の日本語だけが「���」や意味不明な記号列になってしまうことがあります。これは、GeoJSONそのものが日本語に弱いからではなく、作成、変換、保存、配信、読み込みのどこかで文字コードの扱いがずれている場合に起こることが多いです。
この記事では、「geojson 使い方」を調べている実務担当者向けに、日本語属性が文字化けする主な原因と、現場で試しやすい4つの直し方を解説します。単にファイルを開き直すだけでなく、変換前データ、保存形式、ブラウザ表示、共有時の設定まで確認できるように整理します。
GeoJSONで日本語属性が文字化けする基本原因
GeoJSONは、地物の形状を示すgeometryと、名称や分類などを入れるpropertiesを組み合わせて扱う形式です。日本語の文字化けが起きる場合、多くは座標値ではなくproperties内の属性名や属性値に問題が出ます。たとえば、地物の位置は地図上に正しく出ているのに、地点名、施設名、住所、点検コメント、担当区分だけが読めなくなる状態です。これは、位置情報の計算ミスというより、テキストの読み取り方の問題として切り分けると原因を追いやすくなります。
GeoJSONはJSONを基礎にした地理空間データ交換形式で、地物、属性、空間範囲などをJSONオブジェクトとして表現します。外部のシステム間でJSONを交換する場合はUTF-8で扱うことが基本になるため、日本語属性の文字化け対策では、まずGeoJSONファイルがUTF-8として保存・受け渡しされているかを確認します。ここを曖昧にしたまま変換や配信だけを直しても、同じ文字化けを繰り返すことがあります。
文字化けは、文字そのものが壊れている場合と、文字は残っているのに読み方だけを間違えている場合があります。たとえば、作成元のデータが国内向けの古い文字コードで保存されていて、それをUTF-8として読み込んだ場合、日本語のバイト列が別の文字として解釈されます。逆に、UTF-8で作ったGeoJSONを、別の文字コードだと決めつけて開いた場合も同じように崩れます。見た目は同じ文字化けでも、元データが壊れているのか、読み込み側の判定が誤っているのかで対処が変わります。
実務でよくあるのは、表形式データからGeoJSONを作成したときの文字コード混在です。地点名や住所を含むCSV、台帳から出力した属性一覧、測量成果や点検記録から取り出した一覧表などを変換してGeoJSONを作る場合、変換前の表データがUTF-8ではないことがあります。その状態でGeoJSON変換だけを行うと、座標列は数値なので問題なく見えても、日本語の属性列だけが崩れることがあります。つまり、GeoJSONを書き出す段階だけでなく、GeoJSONになる前のデータをどう保存していたかも重要です。
また、ファイル自体は正しいUTF-8でも、ウェブ上で表示するときに文字化けするケースがあります。これは、ファイルの中身ではなく、配信時の種類指定や読み込み処理が原因です。地図表示用のページでGeoJSONを読み込むとき、サーバーがGeoJSONやJSONとして適切に返していなかったり、読み込み側の処理がテキストを誤った前提で扱っていたりすると、ファイルを単体で開いたときは正常なのに、地図画面では文字化けするという状態になります。
もうひとつ注意したいのは、エスケープ表記と文字化けの違いです。GeoJSONの中で日本語が「\u」から始まる英数字の並びで表示されることがあります。これは必ずしも文字化けではありません。JSONでは文字をエスケープして表現できるため、表示ツールや出力処理によっては、日本語をそのままではなくコード表現で保存する場合があります。読み込み後に正しい日本語として表示されるなら、データとしては正常に扱われている可能性があります。ただし、エスケープされた文字列をさらに別の処理で再変換したときに崩れることがあるため、最終的にどの画面でどう見えるかを確認する必要があります。
日本語属性の文字化けは、単独の原因だけでなく、複数の小さなずれが重なって起きることもあります。変換前の表データは国内向けの文字コード、GeoJSONへの変換時はUTF-8、共有先のサーバーでは別の前提、閲覧側のブラウザでは自動判定というように、各段階の扱いがそろっていないと、どこかで文字が崩れます。したがって、修正では「とりあえず別名保存する」だけでなく、作成元から閲覧先までの流れをひとつの経路として確認することが大切です。
直し方1：GeoJSONファイルをUTF-8で保存し直す
最初に試すべき直し方は、GeoJSONファイルそのものをUTF-8で保存し直すことです。特に、ファイルを開いたときに日本語が読めたり読めなかったりする場合、保存時の文字コードが不安定になっている可能性があります。GeoJSONはテキストとして確認できる形式なので、文字コードを確認できる汎用的なテキスト編集環境で開き、文字コードをUTF-8に指定して保存し直すだけで改善することがあります。
ただし、注意点があります。文字化けした状態の表示をそのまま保存すると、壊れた文字列が確定してしまう場合があります。たとえば、もともとは「境界点」だった属性値が、文字化けした記号列として表示され、その状態で上書き保存されると、元の日本語に戻す手がかりが失われることがあります。そのため、修正前には必ず元ファイルを複製しておき、作業用ファイルで試すのが安全です。現場データでは、一度壊した属性を再入力する手間が大きくなるため、バックアップは小さな手順に見えて非常に重要です。
保存し直すときは、単に拡張子を変えるだけでは不十分です。ファイル名を「.json」から「.geojson」に変えても、中身の文字コードは変わりません。反対に、拡張子が「.geojson」でも、中身が別の文字コードで保存されていれば文字化けは起こります。拡張子はファイルの種類を示す目印であり、文字コードそのものを直す機能ではないと考えると整理しやすいです。
UTF-8で保存し直したら、次にJSONとしての構造が崩れていないかを確認します。文字化け修正の途中で、引用符、カンマ、波括弧、角括弧などを誤って消してしまうと、文字は読めてもGeoJSONとして読み込めなくなります。GeoJSONの属性はpropertiesの中にキーと値の組み合わせとして入るため、日本語属性を修正するときも、文字列の前後にある引用符を消さないようにします。住所やメモにダブルクォートや改行が混じる場合は、JSONの書式として正しく扱われているかも確認します。
現場での確認では、文字化けしていた属性を数件だけ選び、修正後のファイルで同じ地物のpropertiesを見比べると効率的です。全件を目視するのは大変なので、地名、施設名、住所、長いメモ、記号を含む項目など、崩れやすい文字を含むレコードを代表として確認します。たとえば、漢字、ひらがな、カタカナ、全角数字、丸括弧、長音符、全角スペースを含む属性が正しく表示されるかを見ると、単純な英数字だけを確認するより問題を見つけやすくなります。
UTF-8で保存し直しても改善しない場合は、ファイルを開く前の時点で既に文字列が壊れている可能性があります。この場合、GeoJSONファイル側だけを修正しても元の日本語には戻りません。元になった表データ、台帳、変換前ファイル、手入力時の記録などを確認し、文字化けしていない段階のデータから再生成する必要があります。つまり、直し方1は最初の切り分けとして有効ですが、万能な復元方法ではありません。
また、UTF-8にはBOM付きとBOMなしの違いがあります。GeoJSONをウェブ配信や外部連携で扱う場合は、BOMなしのUTF-8を基本にするほうが安全です。JSONの受け渡しでは、BOMが付いていることで読み込み側の実装によって扱いが分かれる場合があるためです。特定の社内ツールでBOM付きが必要な場合でも、その環境だけの例外として扱い、納品用や公開用のGeoJSONでは、出力側、確認側、共有側で同じ前提を決めておくことが重要です。
直し方2：変換前データの文字コードをそろえる
GeoJSONの日本語属性が文字化けすると、ついGeoJSONファイルだけを直そうとしがちです。しかし実務では、GeoJSONは最終成果物であり、その前に表形式データ、点検記録、測量メモ、台帳属性、図面由来の属性などが存在することが多いです。変換前データの文字コードがそろっていないと、GeoJSONを何度作り直しても同じ文字化けを繰り返します。
たとえば、地点の緯度経度を含むCSVに、地点名、住所、管理部署、点検結果、備考を入れてGeoJSONへ変換する場面を考えます。座標列は半角数字と記号が中心なので、文字コードの違いに気づきにくいです。一方で、属性列には日本語が入るため、変換時の読み取り文字コードがずれると、そこだけが文字化けします。このとき、変換後のGeoJSONをUTF-8で保存しても、変換時点で誤って解釈された文字はそのまま出力されるため、問題は残ります。
そのため、変換前のCSVや属性一覧を開く段階で、文字コードを確認する必要があります。表形式データを扱う環境によっては、保存時に自動で特定の文字コードを選ぶことがあります。別の環境で開いたときに日本語が崩れる場合は、GeoJSON変換に進む前に、元の表をUTF-8として保存し直してから変換するのが安全です。特に、複数人が別々の環境で編集したデータを結合する場合は、同じ列名に見えてもファイルごとに文字コードが違うことがあります。
変換前データでは、列名も重要です。propertiesに入る属性名は、CSVなどの列名からそのまま作られることがあります。列名が「地点名」「住所」「点検結果」のような日本語の場合、列名の文字化けがそのままGeoJSONのキー名の文字化けになります。値だけでなく、属性名も日本語で扱うなら、列名の文字コードも確認対象に含めます。属性名が崩れると、表示だけでなく検索、絞り込み、ラベル表示、集計処理にも影響するため、値の文字化けより深刻な場合があります。
一方で、日本語の属性名を必ず避けるべきというわけではありません。現場担当者が読みやすい日本語属性名は、運用上のメリットがあります。ただし、外部システムとの連携、長期保存、プログラム処理、複数案件での再利用を考える場合は、属性名を安定した半角英数字にし、表示用の名称や説明を別途管理する方法もあります。たとえば、内部処理用のキーは短く一定にし、表示画面では日本語ラベルに置き換える運用にすると、文字化けだけでなく表記ゆれの管理もしやすくなります。
変換前データをそろえるときは、ひとつの代表ファイルだけで確認しないことも大切です。現場データは日ごと、班ごと、エリアごとに分かれていることがあります。ある日のファイルはUTF-8でも、別の日のファイルは違う文字コードで保存されている場合があります。複数ファイルを一括変換する前に、同じ形式、同じ文字コード、同じ列構成になっているかを確認しておくと、後工程での手戻りを減らせます。
また、別形式からGeoJSONへ変換する場合、変換ツールの入力設定も見落としやすいポイントです。入力ファイルの文字コードを自動判定に任せると、短い日本語や記号が少ないファイルでは誤判定されることがあります。可能であれば、入力側の文字コードを明示し、出力側をUTF-8に指定します。自動判定に頼る場合でも、変換後のGeoJSONを数件だけでなく、文字種類の多い属性まで確認することが必要です。
直し方3：配信時と読み込み時の文字コード設定を見直す
GeoJSONファイルを単体で開くと日本語が正しく見えるのに、地図画面や共有ページで読み込むと文字化けする場合は、配信時と読み込み時の設定を見直します。このケースでは、ファイルそのものは壊れていない可能性があります。問題は、ファイルを受け渡す途中で「このテキストをどのように読み込むか」という前提が正しく伝わっていないことです。
ウェブ上でGeoJSONを扱う場合、サーバーはファイルの種類に関する情報を付けて返すことがあります。GeoJSONであれば、利用環境に応じてapplication/geo+jsonやapplication/jsonなど、JSONとして扱える種類で配信されているかを確認します。あわせて、ファイルの実体がUTF-8で保存され、読み込み側もUTF-8のJSONとして処理しているかを見ます。種類指定や文字コードの前提が古い設定のままになっていると、読み込み側が誤った方法でテキストを解釈し、propertiesの日本語だけが崩れることがあります。
特に、地図表示用のページでGeoJSONを読み込む処理を組んでいる場合は、ファイルをどの形式として取得しているかを確認します。JSONとして直接読み込む処理なのか、テキストとして取得してから自分で解析しているのかによって、注意点が変わります。テキストとして取得してから加工する場合、途中で別の文字コードとして扱ってしまう余地が増えます。不要な再変換を挟まず、UTF-8のGeoJSONをそのままJSONとして扱う流れにしたほうが、文字化けの原因を減らしやすくなります。
また、圧縮ファイルや一括ダウンロードを経由する場合も注意が必要です。GeoJSON単体では正常でも、圧縮前後の処理、アップロード時の変換、サーバー側の保存処理、ダウンロード時の再生成処理で文字が崩れることがあります。ファイル共有の途中で中身が自動変換されていないか、アップロードしたファイルとダウンロードしたファイルの内容が一致しているかを確認すると、どこで崩れているかを切り分けられます。
ブラウザで表示したときだけ文字化けする場合、画面上のラベル表示やポップアップ表示の処理も確認します。GeoJSONのpropertiesは正しく読めているのに、表示用にHTML文字列を組み立てる段階でエスケープ処理を誤ると、画面上では読みにくい表示になります。これは文字コードの問題ではなく、表示処理の問題です。属性値を地図上に出すときは、元のpropertiesの値、表示用に加工した値、最終的に画面に出た値を分けて確認すると原因が見つけやすくなります。
配信時の設定を見直すときは、サーバー側だけでなく、手元で確認する方法もそろえる必要があります。担当者ごとに別の開き方をしていると、ある人は正常、別の人は文字化けという状態になり、原因が曖昧になります。GeoJSONを確認するときは、テキスト編集環境での確認、JSONとしての構文確認、地図画面での表示確認を分け、どの段階で文字が崩れるかを記録します。ファイル単体で正常、配信後に異常なら、保存形式より配信設定や表示処理を疑うという判断ができます。
さらに、ローカル環境で直接ファイルを開いて確認している場合と、サーバー経由で読み込んでいる場合では挙動が異なることがあります。ローカルで問題ないから本番でも問題ないとは限りません。納品や公開を前提にするGeoJSONでは、最終的に利用者がアクセスする経路で確認することが重要です。共有先がブラウザなのか、別のGIS環境なのか、業務システムなのかによって、文字コードの扱いに差が出るため、最終利用環境での確認を省かないようにします。
直し方4：属性名と属性値の運用ルールを決める
日本語属性の文字化けを根本的に減らすには、個別ファイルを直すだけでなく、属性名と属性値の運用ルールを決めることが大切です。GeoJSONは自由度が高く、propertiesの中には任意の項目を入れられます。この自由度は便利ですが、担当者ごとに列名、表記、記号、空欄の扱いが違うと、変換時や共有時のトラブルが増えます。
まず決めたいのは、属性名を日本語にするのか、半角英数字にするのかという方針です。日本語の属性名は現場で見たときに意味が分かりやすく、データを確認する担当者にとって扱いやすいです。一方で、外部連携やプログラム処理では、半角英数字のキーのほうが安定しやすい場合があります。どちらが絶対に正しいというより、案件の目的に合わせて統一することが重要です。途中で「住所」と「所在地」と「address」が混在すると、文字化け以前に属性の対応関係が分かりにくくなります。
属性値については、使用する文字の範囲をある程度決めておくと安全です。漢字やかなを使うこと自体は問題ありませんが、環境依存になりやすい特殊記号、見た目が似ている全角半角の混在、不要な改行、先頭や末尾の空白、長すぎるメモ欄などは、後工程で問題を起こすことがあります。現場メモをそのまま属性に入れる場合も、改行をどう扱うか、写真番号や管理番号をどの形式で書くか、未確認の値をどう表すかを決めておくと、変換後の確認が楽になります。
日本語属性では、同じ意味の表記ゆれも問題になります。たとえば、「未確認」「未調査」「確認前」が混在していると、地図上の色分けや絞り込みで意図した分類にならないことがあります。これは文字化けではありませんが、文字化け修正と同じタイミングで見直すと効果があります。GeoJSONを実務で使う目的は、位置と属性を正しく結びつけて判断に使うことです。読める日本語に戻すだけでなく、属性として使いやすい表現にそろえることが大切です。
運用ルールには、保存形式も含めます。作成元データはUTF-8で保存する、GeoJSON出力時もUTF-8にする、納品前に代表レコードの日本語属性を確認する、共有先では最終表示を確認する、というように、作業段階ごとの確認点を決めておきます。担当者が変わっても同じ品質で出力できるようにするには、個人の経験に頼るより、短い手順書として残しておくほうが有効です。
また、サンプルデータを用意しておくと再発防止に役立ちます。たとえば、日本語の地点名、住所、長い備考、全角記号、半角英数字を含むテスト用のFeatureを作っておきます。新しい変換手順や共有方法を使う前に、そのサンプルGeoJSONを通して表示を確認すれば、日本語属性が崩れる環境かどうかを早めに判断できます。実データで問題が出てから調査するより、事前に小さなサンプルで確認するほうが安全です。
属性名と属性値のルールは、現場の使いやすさとデータ連携の安定性の両方を見て決めます。現場で読みやすい日本語表記を残しながら、内部処理用のキーを安定させる方法もあります。たとえば、属性キーは半角英数字にして、表示名や説明文は日本語で別管理する運用です。逆に、チーム内利用が中心で、外部連携が少ないなら、日本語属性名を使いながら文字コード管理を徹底する方法もあります。大切なのは、案件ごとに場当たり的に変えないことです。
文字化けを見つけたときの実務確認手順
GeoJSONの日本語属性が文字化けしたときは、いきなり全体を作り直すのではなく、どの段階で崩れているかを順に確認します。最初に見るべきなのは、GeoJSONファイルをテキストとして開いたときの状態です。この時点でproperties内の日本語が既に崩れているなら、保存時または変換時に問題が起きている可能性が高いです。ファイル内では正常なのに、地図画面でだけ崩れるなら、配信や表示処理を疑います。
次に、変換前データを確認します。元のCSVや属性一覧で日本語が正しく表示されているか、別の環境で開いても同じように読めるかを見ます。変換前データが文字化けしているなら、GeoJSON側ではなく元データの復旧が必要です。変換前データが正常で、変換後だけ崩れるなら、変換処理の入力文字コード設定、出力文字コード設定、列名の扱いを確認します。この切り分けをしないまま修正すると、毎回同じ場所で失敗します。
その次に、GeoJSONとしての構造を確認します。文字化けを直そうとして手編集した結果、JSONの構文が崩れていないかを見る必要があります。日本語が読めるようになっても、FeatureCollection、features、geometry、propertiesの構造が崩れていると、地図表示やデータ連携では使えません。文字コードの確認と構文の確認は別の作業として扱うと、問題を混同しにくくなります。
座標表示の不具合と文字化けも分けて考えます。GeoJSONでは座標の扱いに決まった前提があり、経度・緯度の順番や座標参照の解釈を誤ると、地物が意図しない場所に表示されます。これは日本語属性の文字化けとは別問題です。地図上の位置がずれているうえに属性も文字化けしている場合、ひとつの原因で両方が起きているとは限りません。座標は座標、属性文字列は文字コードとして、それぞれ確認したほうが原因を見誤りません。
共有先での確認では、最終利用者と同じ経路でファイルを開くことが大切です。作成担当者の手元では問題がなくても、閲覧用ページ、社内共有、納品先の確認環境で文字化けすることがあります。この場合、ファイルそのものではなく、共有経路の中で文字コードの前提や読み込み処理が変わっている可能性があります。最終確認では、ファイルを直接見るだけでなく、実際の地図表示、属性ポップアップ、検索、ラベル表示まで確認します。
確認対象の属性は、短い名称だけに絞らないようにします。短い漢字だけでは問題が見えない場合があります。住所、長い備考、括弧を含む名称、全角数字、カタカナ、記号、空欄、同じ列に数値と文字が混じる項目などを確認すると、実務で起こりやすい崩れを見つけやすくなります。点検結果や現場メモをGeoJSONに入れる場合は、文章量が多い項目ほど注意が必要です。
修正後は、ファイル名や保存場所だけでなく、修正内容も記録しておくと再発防止になります。たとえば、元データの文字コードをUTF-8に統一した、変換設定を変更した、配信時の種類指定を見直した、属性名を統一した、というように、何を直したのかを残します。次回同じようなデータを作るときに、過去の修正履歴がそのままチェックリストになります。文字化けは一度直して終わりではなく、運用に戻すことが重要です。
まとめ：GeoJSONの日本語属性は作成から共有まで一貫管理する
GeoJSONの日本語属性が文字化けする主な原因は、GeoJSONが日本語に対応していないことではなく、文字コードの前提が作成元、変換処理、保存形式、配信設定、読み込み処理の間でそろっていないことです。座標が正しく表示されているのに属性だけが崩れる場合は、properties内の日本語文字列がどの段階で誤って解釈されたかを確認します。
直し方としては、まずGeoJSONファイルをUTF-8で保存し直し、次に変換前データの文字コードをそろえます。それでも表示時だけ崩れる場合は、サーバーからの配信設定や読み込み処理を見直します。さらに、属性名と属性値の運用ルールを決めておけば、同じような文字化けを繰り返しにくくなります。個別ファイルの応急処置だけでなく、作成から共有までの流れを整えることが、実務ではもっとも効果的です。
GeoJSONは、位置情報と属性情報を軽く扱える便利な形式ですが、現場で使うデータには地名、住所、点検コメント、写真説明、管理番号など、日本語の重要な情報が多く含まれます。文字化けしたまま共有すると、地図上の位置は分かっても、何を示す点なのか、どの状態なのか、誰が確認すべきなのかが伝わりません。だからこそ、日本語属性を正しく残す運用は、単なる見た目の修正ではなく、現場情報の信頼性を守る作業です。
現場で取得した位置情報、写真、メモをあとからGeoJSONや関連データとして活用したい場合は、記録時点から文字情報と位置情報を一緒に整理しておくことが大切です。入力時の文字コード、属性名のルール、出力時のUTF-8保存、共有先での表示確認までを一連の手順にしておけば、GeoJSON運用の入口から出口までを安定させやすくなります。