私は文字の配列を持っています。それらのいくつかは ASCII 128 と 130 の 10 進数です。それらを通常の文字として読み取ろうとしていますが、128 の代わりに 8218 を int として取得します (バイトにキャストして 26 を取得)。128 から 130 の間の数値を取得する必要があります。エンコーディングに関する記事をいくつか見つけました。エンコーディング 439 を使用する必要があると言う人もいます。
何か案は?
私は文字の配列を持っています。それらのいくつかは ASCII 128 と 130 の 10 進数です。それらを通常の文字として読み取ろうとしていますが、128 の代わりに 8218 を int として取得します (バイトにキャストして 26 を取得)。128 から 130 の間の数値を取得する必要があります。エンコーディングに関する記事をいくつか見つけました。エンコーディング 439 を使用する必要があると言う人もいます。
何か案は?
CLR環境のchar(System.Char)は、符号なし16ビットの数値であり、UTF-16コード単位です。Unicode標準、第3章、§3.9から:
コード単位:処理または交換のためにエンコードされたテキストの単位を表すことができる最小のビットの組み合わせ。
コードユニットは、コンピュータストレージの特定のユニットです。他の文字エンコード標準では、通常、8ビット単位として定義されたコード単位(つまり、オクテット)が使用されます。Unicode標準では、UTF-8エンコード形式の8ビットコードユニット、UTF-16エンコード形式の16ビットコードユニット、およびUTF-32エンコード形式の32ビットコードユニットを使用します。
コード単位は、情報業界ではコード値とも呼ばれます。
Unicode標準では、一部のコードユニットの特定の値を使用して、エンコードされた文字を単独で表すことはできません。この制限は、UTF-16の分離されたサロゲートコードユニットと、UTF-8のバイト80〜FFに適用されます。他の文字エンコード標準の実装にも同様の制限が適用されます。たとえば、SJIS(Shift-JIS)のバイト81–9F、E0–FCは、それ自体でエンコードされた文字を表すことはできません。
「ASCII」テキストは、CLRの世界に入ると、ASCIIではなくなります。ASCIIは7ビットエンコーディングであり、互換性のために、コードポイント0x00〜0x7FはすべてのUnicodeエンコーディング(UTF-8、-16、-24、-32)で維持されます。非Unicodeの世界では、0x80–0xFFには常に複数の文字マッピングがあります(EBCDICとASCIIの違いも見ていません)。一部のASCII実装もパリティ用に提供されています。上位ビットは、目的のパリティを維持するように設定されます。
おそらく、UTF-8エンコーダー/デコーダー(CLRのデフォルト)を使用して「ASCII」テキストを読んでいます。文字に期待する数値を取得するには、テキストが実際に使用されているエンコードに適したエンコード/デコーダーを使用してテキストを読み取る必要があります(Windows 1252?他の何か?)。
おそらく、あなたにとってより良いアプローチは、テキストのオクテットごとに、そのミニオンSystem.IO.FileStream
ではなく、を使用してバイナリとして読み取ることです。System.IO.TextReader
次に、生のオクテットを取得し、必要に応じてテキストに変換したり、生のオクテット値を計算したりできます。