残りのバイト列はストリームから再びデータを読み取ったときに手に入る。受信したデータは、逐次文字列にデコード(復号)して、あなたのアプリケーションの表示ルーチンに渡さなければならない。ここでいやな予感がするはずだ。単独で存在することを許されない、半端なバイトになってしまっているからだ。このように、ひとつの文字を複数のバイト列で表すようなエンコーディングでは、受け取ったデータがかならずしも文字の境界にそろっているとは限らない。バイト表現の文字の前半分かを判別できるという特徴がある(「日本語と文字コード」)。バイトとあわせてひとつの文字を表現している。バイト単独でひとつの文字を表している。この知識を利用すれば、文字列の境界を見つけることはけしてむずかしくはない。先頭から受信したデータをパースする関数を書いてもいいし、正規表現でマッチングさせてもいい。バイトは次の受信データの先頭につなげるために取っておく。いうコードをたくさん書いていたのではないかと思われる。いうバッファリング機構を実装してしまうと、受信するデータのエンコーディングが変わったときに、バッファリング機構のコードもそれにあわせて書き換えなければならない。いうものが見つかった。これこそ、ほしかったものそのもので、やってほしかったことのすべてを引き受けてくれる。早く知っとくべきだった。おなじ思いをほかの人には味わってほしくないので、いまこれを書いている。使いかたを以下で説明します。クラスで、実際の逐次デコードにはそのインスタンスを使う。クラスを手に入れなければならない。クラスを返すというものになっている。いわゆるファクトリ関数だ。このためコードはちょっと回りくどく見えるかもしれない。Decoder()モジュールをインポートしたあとは一行で次のように書いてもおなじこと。メソッドに食わせていけばよい。decoder.decode(x[13:])u'\u30a4\u30bd\u30f3'このように、文字境界の途中で切れていても、つながっているところまでの文字列をデコードして返してくれる。