そのため、ソフトウェア エンジニアリング コースの Move to Front Encoding/Decoding 課題に取り組んでおり、組み込みの ord() 関数を Python 3.3 で使用すると、コードの特定のポイントで間違った値が返されるようです。
1 ～ 120 のコード番号をエンコードする場合は、そのコード番号を 128 に加算するだけです。121 ～ 375 の番号の場合、2 バイトを使用します。最初のバイトは F9 で、次の 1 バイトがコード番号の一部であることを示します。 2 番目は実際のコード番号 (コード # - 128 でエンコード) です。たとえば、121 は F9 00 になります。
デコードするときに、F9 を読み込んで 2 番目のバイトをデコードするコードに移動した後、ord 関数で問題が発生するという問題が発生します。
私のコードは次のとおりです。
def decode_num(base_num, input_file):
if base_num <=248:
#coding for if the code is simply a one byte code from 1-120(will have been coded as 248)
return base_num-128
elif base_num == 249:
#coding for if the code is a two byte code, thus the first byte of the code will be 121
second_byte=ord(input_file.read(1))
return second_byte+121
F9 0D であるはずの 134 のコーディングに到達するまでは問題なく動作するようです。ord(input_file.read(1)) 呼び出しは、13 ではなく 10 を返します。デコードしようとしている mtf ファイルで、問題が発生している場所で hexdump が F9 0D を示していることを確認しました。現在取り組んでいるテスト ケースでは、2 バイト コードの 2 番目のバイトが 0D の場合にのみ発生します。0C と back は正常に動作し、0E と forward はすべて正常に動作します。
これを潜在的に引き起こしている可能性のあるアイデアはありますか? または、2バイトコード番号をデコードするための代替案はありますか?
編集: mtf ファイルが latin-1 でエンコードされることを忘れていました。それが違いを生むなら。