IT業界におけるベストプラクティスは時々変化していくものですが、テキストファイルにおける特定の非表示文字の管理はその一例です。EOL(End of Line)文字は、特にバージョン管理システムでの統合に合わせて進化してきました。同じように、UnicodeテキストファイルのBOM(Byte Order Mark)は、あまり使われなくなってきています。
4D v19 R2では、4Dはこれらの変化に沿うようにスムーズに進化しており、より柔軟な対応が可能です。
前提情報
行末(EOL)
テキストファイルの行は、EOL(End of Line)文字で区切られていることは皆さんご存じのことと思います。Windowsでは、これは2つの文字の組み合わせになっています。
- キャリッジリターン(#13、CR)と
- ラインフィード(#10、LF)です。
macOSでは、CR文字のみでした。
Gitのようなバージョン管理システムでは、CRをEOL文字として管理できないため、代わりにLFを使う必要があります。
バイトオーダーマーク(BOM)
Unicodeテキストファイルには、使用する文字セットを定義するByte Order Markという非表示の先頭のバイトがあることも皆さんご存じでしょう。
4Dは、Unicodeを導入する際、現在のベストプラクティスに従いました。それはつまりデフォルトでBOMつきのテキストファイルを書きだすということです。しかし、UTF-8が標準的なテキストファイルのフォーマットになりつつあるため、BOMはあまり使われなくなってきています。
テキストファイルに関する4Dの新しい規則
今後、4Dは、GitHubなどのバージョン管理システムを多用する現代のトレンドに従って、テキストファイルを書き出す際にはBOMなしのテキストファイルを作成します。また、macOSでは、LFを行末L文字として使用します。これは、4DSettings、4dm、4DFormなど、4Dから書き出された全てのファイルに対して、完全に自動で行われます。
以前の4Dバージョンでファイルを開く場合、たとえ4D v19 R2移行で書き出されたものであっても、問題は発生しません。これらの以前のバージョンも、BOMなしの、EOL文字としてLFを使うファイルを開くことができるからです。
互換性の設定
古いデータベースにおいてこの新しい動作を取り込みたいですか？データベース設定内の新しい互換性設定を使用すると、TEXT TO DOCUMENTコマンドとFile.setText()関数においてオプションの “charSet “と “breakMode “引数がない場合、BOMなしのファイルを生成し、macOSでEOL文字としてLFを使用することができます。これは完全に自動化されており、この新しい動作の恩恵を受けるためにソースコードを書き換える必要はありません。
新しい文字セット
新しい互換性設定は、 TEXT TO DOCUMENT およびFile.setText()に対して、”charSet” と “breakMode” オプション引数なしで使用された場合に適用されます。
EOL文字については変更はありません。 “breakMode “パラメータを使用して指定することができます。
同じように、 TEXT TO DOCUMENTとFile.setText() が生成するファイルがBOMを含むかどうか正確に定義したい場合もあります。そのためには、”UTF-8-no-bom” や “UTF-16-no-bom” など、”-no-bom” で終わる Unicode 文字セットを定義することで、BOM のないファイルを書き込むようにします。BOM付きのファイルを書き込むには、”UTF-8 “や “UTF-16 “などの”-no-bom “を付けない既存の文字セットを引き続き使用することができます。