1

技術的には UCS2-LE (BOM なし) ですが、UTF-16 の .NET で問題なくロードできるフラット ファイルがあります。これは、UCS-2 が UTF-16 よりも古い標準であるためだと理解しています。優先します。

ただし、私が興味を持っているのは、ファイルが実際に UCS-2 であるかどうかを判断できることです。私はこれが私が推測していることを意味することを知っています. 私は chardet の .NET ポート、IMultilang2 相互運用機能、および UTF-16 を介した UCS-2 の決定を引き出すために Novell によるいくつかのオープン ソースを試しましたが、成功しませんでした。UCS-2LE w/o BOM と無効/長すぎる UTF-8 の違いを判断できる手法は見つかりませんでした。

それらをバイトごとに検査し、それが可変長か固定長かを判断しようとする必要がありますか? 欠落しているコードポイントを探しますか? 問題は、これらのテキスト ファイルには特別なコードポイントがなく、標準的な西欧文字セットしかないことです。しかし、TextPad はそれらを BOM なしの UCS2-LE として保存し、UTF-16 に完全に準拠することを望むソフトウェアでの下流のファイル操作を複雑にします (ファイルを強制的にロードするだけでは機能しますが、ソフトウェアの要件では機能しません)。 ）。

4

1 に答える 1

3

このウィキペディアの記事セクションhttp://en.wikipedia.org/wiki/UTF-16では、基本的な多言語プレーン、BMPについて説明しています。BMPのすべてのコードポイントは、UTF-16とUCS-2の両方で同一です。TextPadがBMPをエンコードしているだけの場合は、ドキュメントをUTF-16またはUCS-2として扱うことができます。

問題が発生するのは、BMP外のコードポイントがエンコードされている場合です。UCS-2は、BMP外のコードポイントを表すことはできません。 http://en.wikipedia.org/wiki/Universal_Character_Set これにより、コードポイントがBMPの外部にある場合、UTF-16で処理できると想定されます。これは、ファイルを作成するプログラムがUCS-2を不適切に実行し、補助的な理由でBMPの外部のコードポイントを使用している場合に問題になる可能性があります。

UTFを読み取るほとんどのライブラリとプログラムでは、文字ごとにエンコードエラーが発生した場合の対処方法を指定できます（例外を発生させ、プレースホルダーに置き換え、単に無視します）。不適切なUCS-2ファイルがUTF-16としてこれらのいずれかを実行すると、エラーが発生します。ファイルの作成者がBMPの外部で何をしようとしていたかを理解することが、それらを適切に処理する唯一の方法です。

于 2012-06-05T00:21:01.720 に答える