点群OBJでBOM付き文字コードが問題になる理由
点群OBJをクラウド環境や点群処理環境へアップロードしたとき、ファイルが存在しているにもかかわらず、形式を認識できない、頂点データが見つからない、先頭行が不正である、解析処理を開始できないといったエラーが表示されることがあります。座標値やファイル容量に目立った異常がない場合は、OBJファイルの先頭に付加されたBOMが影響している可能性があります。
BOMはByte Order Markの略称で、Unicode形式のテキストファイルの先頭に置かれる識別情報です。UTF-8のBOMは、ファイル上ではEF BB BFという3バイトで記録されます。通常の文章を扱う環境では、この3バイトを文字コード判定の手掛かりとして利用したり、自動的に読み飛ばしたりすることがあります。
一方、OBJは行の先頭に記載された識別子を読み取り、データの種類を判定するテキスト形式です。頂点座標はv、テクスチャ座標はvt、頂点法線はvn、面はf、点要素はp、材質ファイルの参照はmtllibといった文字列から始まります。読込処理がBOMを適切に除外しない場合、最初の行が本来のvやmtllibではなく、見えない文字が付加された別の識別子として扱われる可能性があります。
たとえば、編集画面では最初の行が「v 100.000 200.000 5.000」と正常に見えていても、実際のバイト列ではvの前にUTF-8のBOMが存在している場合があります。人が画面で確認しただけでは違いが分かりにくいため、アップロード先で初めて問題が表面化することがあります。
ただし、BOM付きUTF-8のOBJが必ずエラーになるわけではありません。BOMを自動的に無視する読込処理であれば、そのまま読み込めることもあります。別の環境では問題なく開けたのに、特定のアップロード先では失敗するという現象が起こるのは、読込処理ごとにBOMへの対応が異なるためです。
このため、点群OBJの受け渡しでは「UTF-8で保存する」という条件だけでは不十分です。UTF-8のBOM付きなのか、UTF-8のBOMなしなのかまで区別する必要があります。アップロード先から文字コードの指定がない場合でも、互換性を重視するのであれば、UTF-8のBOMなしで保存しておく方法が候補になります。
BOMを除去するときは、単に先頭の数バイトを削ればよいとは限りません。対象がUTF-8のBOM付きであることを確認せずに先頭3バイトを削除すると、正常なOBJの先頭文字を壊すおそれがあります。また、UTF-16など別の文字コードで保存されている場合は、BOMだけを削除してもUTF-8にはなりません。ファイル全体の文字コードを判定し、正しく変換する必要があります。
修正前に確認したいOBJファイルの状態
BOMを修正する前に、元のOBJファイルを複製して保管します。文字コードの変換は見た目の文章だけを調整する簡単な作業に見えますが、処理方法によっては改行、空白、数値表記、ファイル末尾などが変化することがあります。変換前のファイルを残しておけば、問題が発生したときに頂点数や座標値を比較できます。
最初に確認したいのは、OBJがどのようなファイルと組み合わされているかです。頂点座標だけを含むOBJもあれば、面情報、法線、材質、テクスチャ画像を伴うOBJもあります。OBJ内にmtllibから始まる行がある場合は、外部のMTLファイルを参照しています。MTLもテキスト形式であるため、OBJと同様にBOMが付いている可能性があります。
次に、ファイルの先頭行を確認します。OBJの先頭は、コメントを示す記号、頂点を示すv、オブジェクト名を示すo、グループを示すg、材質ファイルを参照するmtllibなどから始まることがあります。先頭が必ずvになるとは限らないため、v以外なら異常だと判断しないことが大切です。
文字コードを表示できる編集機能がある場合は、UTF-8、UTF-8 BOM付き、UTF-8シグネチャ付き、UTF-16などの表示を確認します。環境によって名称が異なるため、「UTF-8」とだけ表示されるときは、保存時にBOMが付く仕様かどうかも確認します。
先頭のバイト列を調べられる場合は、EF BB BFで始まっているかを確認します。EF BB BFであればUTF-8のBOM付きである可能性が高い状態です。FF FEやFE FFなどで始まる場合は、UTF-16系で保存されている可能性があります。この場合は、先頭だけを削除するのではなく、ファイル全体を適切な文字コードとして読み込み、UTF-8のBOMなしへ変換します。
修正前には、ファイル容量、総行数、v行の件数、f行やp行の件数も控えておくと安心です。点群OBJでは数十万行から数千万行に達することがあり、全内容を目視で比較するのは現実的ではありません。変換前後の件数を照合できれば、BOMを除去する過程で行が欠けていないかを確認できます。
ファイルの最後の数行も確認します。大容量OBJでは、過去の保存処理が途中で止まり、ファイル末尾が欠けていることがあります。この場合、BOMを直してもアップロードエラーは解消しません。文字コードを直す前に、元ファイル自体が最後まで正常に出力されているかを確認する必要があります。
また、複数のOBJを単純に連結したファイルでは、ファイル途中にBOMが残ることがあります。2個目以降のOBJの先頭にあったBOMが、そのまま結合後の途中へ挿入されるためです。先頭のBOMを除去しただけでは、途中の行に不正な文字が残ります。複数ファイルを統合した経緯がある場合は、ファイル全体にU+FEFF相当の文字が混入していないかも確認します。
方法1 テキスト編集機能でUTF-8のBOMなしに保存する
比較的小さな点群OBJであれば、文字コードを指定できるテキスト編集機能を使い、UTF-8のBOMなしとして保存し直す方法が分かりやすいです。特別な変換処理を作らなくても実施できるため、単発のファイルを修正するときに向いています。
作業では、まず元のOBJを複製し、複製したファイルを開きます。開いた後に先頭行と末尾行を確認し、文字が欠けていないこと、各データが行単位で表示されていることを確かめます。文字化けが発生している場合は、そのまま上書きせず、正しい入力文字コードを指定して開き直します。
保存時には、UTF-8のBOMなし、UTF-8シグネチャなしなど、BOMを付加しない設定を選びます。設定名は編集環境によって異なります。「UTF-8」と「UTF-8 BOM付き」が別に表示されている場合は、通常のUTF-8がBOMなしを示すことがありますが、名称だけで判断せず、保存後に再確認することが重要です。
変換後のファイルは、元ファイルと異なる名前で保存します。修正前、修正後、確認済みの状態を区別できる名前にしておくと、誤って元のOBJをアップロードする事故を減らせます。ただし、OBJ内部から参照されるMTLの名前や、MTLから参照される画像の名前を変更するときは、参照行も一致させる必要があります。
保存が完了したら、一度ファイルを閉じてから再度開きます。編集画面上で保存操作が完了したように見えても、実際にどの文字コードで書き出されたかを確認できないことがあるためです。再度開いたときにUTF-8のBOMなしと判定されること、先頭行が正しく残っていることを確認します。
UTF-8のBOMだけを除去した場合、ファイルの実データは基本的に先頭の3バイト分だけ小さくなります。ただし、保存時に改行方式が変更された場合や、末尾の改行が追加された場合は、それ以上の差が生じることがあります。容量差だけで正常と判断せず、v行などの件数も照合します。
この方法は、大容量ファイルには向かない場合があります。点群OBJを一般的なテキスト編集機能で開くと、大量のメモリを使用し、読み込みや保存に時間がかかることがあります。保存処理中に強制終了すると、途中までしか書き出されていないファイルが残る可能性もあります。
大きなOBJを編集機能で扱う場合は、保存先の空き容量にも注意します。保存時に元ファイルと同程度の一時領域が必要になることがあるため、容量不足で処理が中断される可能性があります。数百MBから数GBのOBJを扱うときは、次に説明する逐次的な文字コード変換を検討した方が安全です。
方法2 文字コード変換処理で大容量OBJを修正する
大量のOBJをまとめて修正する場合や、一つのOBJが非常に大きい場合は、文字コード変換処理を利用する方法が適しています。ファイル全体を編集画面へ展開せず、一定量ずつ読み書きする処理であれば、使用するメモリを抑えながら変換できます。
変換処理で最初に行うのは、入力ファイルの文字コード判定です。先頭がEF BB BFであればUTF-8のBOM付きとして扱い、BOMを除外してUTF-8のBOMなしで出力します。UTF-16系のBOMを検出した場合は、その文字コードとして正しく復号し、文字列をUTF-8で再符号化します。
ここで避けたいのが、すべてのOBJに対して無条件に先頭3バイトを削除する処理です。BOMが付いていない正常なOBJに適用すると、先頭のvやコメント記号、mtllibの一部が削除されます。変換前にBOMの有無を判定し、検出した場合だけ除去する必要があります。
処理対象の選び方にも注意します。点群データのフォルダには、OBJ、MTL、画像、圧縮ファイル、管理資料などが混在している場合があります。画像や圧縮ファイルはバイナリデータであり、文字コード変換の対象にしてはいけません。対象をOBJとMTLなどのテキスト形式へ限定します。
一括変換では、元ファイルを直接上書きせず、変換後の保存先を分けます。処理中の障害や設定ミスによって複数ファイルが破損した場合でも、元データからやり直せるためです。変換後の検査が完了するまでは、元ファイルを削除しないようにします。
変換結果の記録も重要です。ファイル名、変換前の文字コード、BOMの種類、変換後の文字コード、処理日時、処理結果、変換前後の容量を記録します。BOMが付いていなかったファイルについては、変更せずに処理不要と記録すると、不必要な再保存を防げます。
大容量OBJを一定量ずつ処理するときは、文字の境界を正しく扱う必要があります。UTF-8の文字は1バイトだけでなく複数バイトで表現される場合があるため、任意の位置で分割すると文字化けが発生する可能性があります。単純に固定バイト数で読み取って文字列へ変換するのではなく、文字コード変換に対応した逐次読込を利用します。
座標行だけで構成されたOBJでは、半角英数字や記号が中心になるため問題が目立たないことがあります。しかし、コメント、オブジェクト名、材質名に日本語などが含まれている場合は、誤った分割による文字化けが起こり得ます。形状データだけが正常でも、材質名や参照名が変化すると別のエラーにつながります。
変換後は、UTF-8としてファイル全体を最後まで読み込めるか確認します。途中で復号エラーが発生する場合は、異なる文字コードの内容が混在しているか、バイナリデータが混入している可能性があります。エラー部分を無条件に削除または置換すると、OBJの識別子や数値が変化することがあるため、原因を確認してから対応します。
方法3 出力元の設定を見直してOBJを再作成する
BOM付きOBJが繰り返し作成される場合は、完成後のファイルを毎回修正するよりも、出力元の設定を見直す方が効率的です。手作業の修正では担当者による差が生じやすく、修正忘れや元ファイルの取り違えも起こりやすくなります。
OBJを書き出す工程に文字コード設定がある場合は、UTF-8のBOMなしを選択します。文字コードを選べない場合は、OBJ出力の直後に変換処理を実行し、アップロード用フォルダへBOMなしのファイルを保存する流れを作ります。
点群OBJの作成工程が複数段階に分かれている場合は、どの段階でBOMが付くかを特定します。最初に生成されたOBJにはBOMがなくても、コメントの追記、座標値の置換、ファイルの結合、名称変更などの後処理でBOMが付加されることがあります。
各工程の前後で先頭バイトを確認すれば、BOMを付加している処理を切り分けられます。原因となる工程が分かれば、その処理の保存設定だけを変更できるため、毎回完成ファイルを修正する必要がなくなります。
再出力するときは、文字コード以外の設定が変化していないかも確認します。出力条件を触ったことで、座標の小数桁数、単位、軸方向、原点、頂点数、面の生成方法が変わる可能性があります。BOMを直す目的で再出力した結果、位置や形状に別の差が生じないようにします。
特に、点群をOBJへ変換する際の構造には注意が必要です。頂点を示すv行だけを出力する場合、p行で点要素も定義する場合、近傍点から面を作成してf行を出力する場合があります。アップロード先がどの構造を受け入れるかによって、必要な出力設定は異なります。
BOMを除去しても「頂点がない」「面がない」などのエラーが残る場合は、アップロード先が点だけのOBJに対応していない可能性があります。反対に、点群として利用したいのに大量の面が生成されていると、ファイル容量や処理負荷が増えることがあります。
名称に使用する文字も確認します。オブジェクト名、グループ名、材質名、MTL名、画像名に日本語や空白が含まれていても正常に扱える環境はありますが、すべての読込処理が同じ対応をするとは限りません。互換性を優先するときは、半角英数字とアンダースコアなどを中心にした名称へ統一する方法があります。
ただし、BOMと日本語名は別の問題です。UTF-8のBOMなしであれば日本語を使用できる環境もあります。BOMを除去するために、必要な名称やコメントまで無条件に削除する必要はありません。アップロード先の対応範囲を確認し、必要な部分だけを変更します。
方法4 OBJとMTLをまとめて修正する
材質や色を伴う点群OBJでは、OBJだけでなくMTLも確認します。OBJ内のmtllib行は外部のMTLファイルを指定し、usemtl行は適用する材質名を指定します。MTL内ではnewmtl行などによって材質が定義されます。
OBJのBOMを除去したことで形状を読み込めるようになっても、MTLの先頭にBOMが残っていると、最初の材質定義を認識できない場合があります。その結果、点や面は表示されても色や材質が反映されないことがあります。
OBJとMTLは、同じ文字コード条件にそろえるのが管理しやすい方法です。両方をUTF-8のBOMなしで保存し、変換後に参照関係を確認します。ただし、文字コードをそろえただけでは参照切れを防げません。
OBJ内のmtllibに記載された名前と、実際のMTLファイル名が完全に一致しているかを確認します。大文字と小文字、全角と半角、空白の有無、拡張子の違いにも注意が必要です。作業環境では大文字と小文字を区別せずに開けても、アップロード先では別のファイルとして扱われることがあります。
OBJ内のusemtlとMTL内のnewmtlも一致させます。文字コード変換の途中で材質名が文字化けすると、見た目が似ていても異なる文字列になる可能性があります。材質が反映されないときは、名称をコピーして比較するだけでなく、不要な空白や見えない文字が残っていないかを確認します。
MTLが画像を参照している場合は、画像ファイル名も照合します。画像はテキスト形式ではないため、OBJやMTLと一緒に文字コード変換してはいけません。一括処理では、対象拡張子を明確に分ける必要があります。
OBJとMTLを圧縮してアップロードする場合は、修正前のファイルが圧縮対象に残っていないか確認します。同じフォルダ内に元ファイル、修正ファイル、バックアップファイルが混在すると、どれを読み込むべきか分かりにくくなります。アップロード用の新しいフォルダを作り、必要なファイルだけを配置すると安全です。
圧縮後は、一度別の確認用フォルダへ展開します。展開したOBJを基準に、MTLと画像へ到達できることを確認します。圧縮時に不要なフォルダ階層が追加されたり、ファイル名が変わったりしていないかも確認します。
材質が不要な点群OBJであれば、参照切れしたmtllibやusemtlを残す必要があるか検討します。ただし、不要と判断して削除するときも、元ファイルを保管し、形状や色の利用目的を確認してから作業します。BOM修正の範囲を超えて内容を変更すると、後から必要な情報を復元できなくなる可能性があります。
方法5 アップロード前の自動検査でBOMを検出する
点群OBJを継続的に扱う現場では、アップロードのたびに担当者が手作業でBOMを確認する方法では見落としが起こりやすくなります。アップロード前の自動検査にBOM判定を組み込むと、ファイルを受け取った段階で問題を検出できます。
自動検査では、まずOBJとMTLの先頭バイトを確認します。UTF-8のBOMを検出した場合は、BOM付きとして警告またはエラーを記録します。UTF-16系のBOMを検出した場合は、単純な除去ではなく文字コード変換が必要なファイルとして区別します。
BOMがない場合も、直ちに正常と判断しないことが大切です。ファイル全体をUTF-8として正しく読み込めるか確認し、途中に不正なバイト列がないかを調べます。BOMなしの別文字コードで保存されている場合、先頭だけを見ても判別できないことがあります。
次に、最初の有効行を検査します。空行やコメント行を除いた最初の行が、OBJとして扱える識別子から始まっているかを確認します。点群OBJではvが多く使われますが、o、g、mtllibなどが先に現れることもあるため、許可する識別子を一つに限定しないようにします。
ファイル全体の構文検査も行います。v行に必要な座標値があるか、座標を数値として読み取れるか、空の値や不正な文字が混入していないかを確認します。点の色を頂点行に追加する形式を利用する場合は、アップロード先がその列構成に対応しているかも確認します。
p行やf行を含む場合は、指定された頂点番号が存在する範囲内かを確認します。OBJの頂点番号は通常1から始まります。負の番号を利用する記述もありますが、すべてのアップロード先が同じように対応するとは限りません。互換性を優先するときは、受け入れ仕様に合わせた番号表現へ整えます。
MTLを参照している場合は、対象ファイルが存在するか、材質名が一致するか、画像の参照先が存在するかも検査します。BOMだけを直しても関連ファイルが欠けていれば、表示結果は完全になりません。
自動修正を行う場合は、元ファイルとは別の場所へ修正後のファイルを保存します。自動的にBOMを除去した後は、同じ構文検査をもう一度実施し、修正によって行数や頂点数が変化していないことを確認します。
検査結果には、ファイル名、BOMの有無、推定文字コード、頂点数、面数、関連ファイル、警告内容を記録します。担当者が結果を見たときに、文字コードの修正だけでよいのか、OBJの再出力が必要なのかを判断できる状態にします。
BOM除去後に確認すべきOBJの内容
BOMを除去した後は、ファイルをアップロードする前に内容の整合性を確認します。最初に、変換前後のv行の件数を比較します。BOMだけを修正した場合、頂点数が変化することは通常ありません。
p行、f行、vn行、vt行がある場合は、それぞれの件数も比較します。件数が減っているときは、保存処理の途中終了、改行の欠落、文字コード変換エラーなどが考えられます。件数が増えている場合も、改行の誤変換や重複出力が起きていないか確認します。
先頭行では、BOMが除去され、本来のコメント記号や識別子が最初の文字になっていることを確認します。末尾行では、ファイルが途中で切れていないかを確認します。大容量ファイルでは、先頭だけ正常でも末尾が欠けていることがあります。
座標値も一部抽出して比較します。文字コード変換だけであれば、数値そのものを変更する必要はありません。しかし、OBJを解析してから再出力する処理を使うと、小数桁数や指数表記が変更される場合があります。必要な測位精度を維持できる桁数が残っているか確認します。
改行が維持されていることも重要です。OBJは基本的に行単位で意味を持つため、保存時に改行が失われて一つの長い行になると、正常に解析できません。反対に、一つの座標行が途中で分割されてもエラーになります。
ファイル名や材質名に含まれる文字も確認します。BOM除去後に名称が文字化けしていないか、OBJとMTLの参照名が一致しているかを確認します。形状だけを利用する場合でも、解析処理が不正な参照行で停止する可能性があるため、不要な参照切れを放置しないようにします。
可能であれば、本番データと同じ条件で作成した小容量の確認用OBJを先にアップロードします。文字コード、圧縮方法、フォルダ構成、OBJの構造を短時間で検証できるため、大容量データの再アップロードを減らせます。
本番OBJをアップロードした後は、処理完了の表示だけでなく、点群の位置、向き、縮尺、範囲、欠落を確認します。アップロードに成功しても、座標系や単位の違いによって想定外の位置へ表示されることがあります。
色や材質を利用する場合は、それらも確認します。最初の材質だけが反映されない場合はMTL先頭のBOMが残っている可能性があります。すべての材質が欠ける場合は、MTLの参照名、配置、対応形式を確認します。
BOM以外に疑うべきアップロードエラーの原因
BOMを除去しても点群OBJをアップロードできない場合は、別の原因を切り分けます。BOMは先頭行の認識に影響する可能性がありますが、OBJのすべてのエラーを解決するものではありません。
最初に確認したいのは、ファイルが空ではないかという点です。出力処理が失敗して容量が0バイトになっていたり、ヘッダーだけで頂点行が存在しなかったりすると、文字コードが正しくても点群として読み込めません。
次に、頂点行の形式を確認します。一般的な頂点行では、vの後ろにX、Y、Zの座標値を記述します。列が不足している、区切りが不正である、数値の途中に文字が入っていると、解析できないことがあります。
小数点と桁区切りの扱いにも注意が必要です。座標値の小数点としてピリオドを想定する読込処理では、カンマを小数点として書いた値を正しく解釈できない可能性があります。また、桁区切りのカンマを含む座標値は、複数の値として扱われることがあります。
指数表記も確認します。大きな座標や非常に小さな値では指数表記が使われる場合があります。指数表記自体を扱える処理はありますが、すべてのアップロード先が同じ形式に対応するとは限りません。必要に応じて通常の小数表記へ変換します。
NaNや無限値など、通常の座標として扱いにくい値が含まれていないかも確認します。点群生成中の計算結果や欠損値がそのまま書き出されると、該当行で解析が止まる可能性があります。
点だけのOBJに対応しているかも重要です。v行だけを含むファイル、v行とp行を含むファイル、f行で面を定義したファイルでは構造が異なります。アップロード先がメッシュOBJだけを想定している場合、頂点だけの点群OBJは受け付けられないことがあります。
面を含むOBJでは、頂点番号の範囲を確認します。存在しない頂点を参照している、0を頂点番号として使っている、対応していない負の番号を使用していると、読込エラーになる可能性があります。
ファイル容量や頂点数の上限も確認します。形式として正しくても、アップロード可能な容量、展開後容量、処理可能な頂点数を超えている場合があります。圧縮ファイルが制限内でも、展開後のOBJが上限を超えることがあります。
圧縮ファイルの階層も確認します。OBJが深い階層に入っている、圧縮ファイルの中に別の圧縮ファイルがある、同名OBJが複数あると、対象ファイルを認識できない可能性があります。アップロード用の構成は必要最小限にします。
ファイル名に利用できない文字が含まれていないかも確認します。空白、全角記号、制御文字、非常に長い名前などは、環境によって問題になることがあります。OBJ、MTL、画像の参照関係を保ちながら、管理しやすい名前へ整理します。
点群OBJの受け渡しルールを標準化する
BOMに関するトラブルを繰り返さないためには、担当者ごとの判断に頼らず、点群OBJの出力条件と受け渡し条件を標準化することが重要です。「OBJ形式で保存する」という指示だけでは、文字コード、BOM、点要素、面要素、関連ファイルなどの条件が伝わりません。
文字コードについては、「UTF-8」とだけ記載せず、「UTF-8のBOMなし」と明記します。OBJとMTLは同じ文字コードへ統一し、画像は文字コード変換の対象外とすることも共有します。
OBJの構造については、v行のみでよいのか、p行が必要なのか、f行を含むメッシュが必要なのかを決めます。色を頂点行へ追加する場合は、列数や値の範囲も統一します。一般的なOBJの記述を拡張した頂点色は、環境によって対応が異なるため、受け入れ側で事前に確認します。
座標値については、単位、小数桁数、指数表記の可否、座標系、原点の扱いを決めます。文字コードが正常でも、単位や座標系が共有されていなければ、アップロード後の点群を正しく配置できません。
ファイル名の規則も設定します。案件、計測日、計測範囲、版番号などを一定の順序で記載すると、修正前後のファイルを識別しやすくなります。大文字と小文字の違いで参照切れが起こらないよう、使用する文字の範囲も決めます。
フォルダ構成では、OBJを中心にMTLと画像を配置し、不要なバックアップや中間ファイルをアップロード用フォルダへ入れないようにします。圧縮する場合は、展開後の構成も確認します。
修正履歴を残すことも大切です。どのファイルにBOMが付いていたか、どの方法で修正したか、変換後の頂点数が一致したか、誰が確認したかを記録します。同じ出力工程で問題が続く場合は、履歴から原因を追跡できます。
外部の担当者からOBJを受け取る場合は、提出条件を事前に共有します。BOMなしのUTF-8、必要なOBJ構造、関連ファイルの配置、圧縮方法を示すことで、提出後の差し戻しを減らせます。
すべての確認を手作業で行うと負担が増えるため、BOM判定、頂点数集計、参照ファイル確認などは可能な範囲で自動化します。担当者は、自動検査で警告された項目や、点群の見た目に関わる部分を中心に確認します。
まとめ
点群OBJのアップロード時に形式エラーや先頭行の解析エラーが発生した場合は、OBJの先頭に付いたBOMを確認することが重要です。UTF-8のBOMはEF BB BFという3バイトで記録され、BOMを適切に処理しない読込環境では、最初のvやmtllibなどを正しく認識できない可能性があります。
BOMを直す方法には、テキスト編集機能でUTF-8のBOMなしに保存する方法、大容量ファイル向けの文字コード変換処理を使う方法、出力元の設定を見直して再作成する方法、OBJとMTLをまとめて修正する方法、アップロード前の自動検査で検出する方法があります。
修正前には必ず元ファイルを保管し、現在の文字コードとBOMの種類を確認します。UTF-8のBOM付きであることを確認せず、無条件に先頭3バイトを削除してはいけません。UTF-16系の場合は、ファイル全体を正しい文字コードとして読み込み、UTF-8のBOMなしへ変換する必要があります。
修正後は、先頭行だけでなく、頂点数、面数、ファイル末尾、座標値、改行、MTLや画像の参照関係を確認します。アップロードに成功した後も、点群の位置、向き、縮尺、欠落、色を確認することが重要です。
BOMを除去してもエラーが残る場合は、OBJの構造、不正な座標値、頂点番号、ファイル容量、圧縮階層、関連ファイルの不足などを順番に切り分けます。原因を一度に推測するのではなく、文字コード、構文、参照関係、アップロード条件の順に確認すると、問題箇所を特定しやすくなります。
現場で取得した点群をOBJとして出力し、クラウド上で共有する運用では、計測からファイル作成、文字コード検査、アップロード確認までを一つの流れとして整えることが大切です。点群データの取得と活用をより円滑に進める際は、現場計測からデータ共有へつなげられるLRTK Phoneの活用も確認してみてください。