雑談。
Python の文字コードサポートが整っているのは、Guido がヨーロッパ人だからなんだろうか。
以下うろおぼえにもとづく戯言。
ヨーロッパでは、ASCII の 128 文字に、アクセント記号付きアルファベットや各種記号などを加えた、8 ビット 256 文字の 1 バイト固定の文字コードを使っているのですが、困ったことに後半 128 文字の割り当てが規格によってばらばらで、しかもなまじ 1 バイト固定長のため、バイトの並び具合からの文字コードの推測が非現実的であるという問題があるそうで。ある意味これは Shift_JIS / ISO-2022-JP / EUC-JP の自動判別がそれなりの精度で効く日本語よりも深刻なわけです。だから、文字コードについてはアメリカ人がほんとにほんとにわかってないのだけ突出してるという状況なのかも。しかし影響力は大きいのでまたこれが。
で、ヨーロッパの事情からすると 8 ビット 256 マスのテーブルの「どこにどの文字が入っているか」という問題のとらえ方なので、「文字セット」という言い方がされるんじゃないかと思う。W3C の HTTP でも Content-Type: text/html; charset=iso-8859-1 ですよね。しかし日本語の文字コード事情からすると、文字集合（どの文字をどう並べた表を使うか）は JIS X 0208 なりなんなりで決まっていて、そのバイト表現（符号化方式）が違っているというのが問題になってくる。だから用語としては encoding のほうがしっくりくる（自分は）。encoding のほうが「文字の区点番号」と、その「区点番号のバイト表現」とを抽象化してるから、より一般的な概念じゃないかな。charset だとそこがまだ未分化な感じがする（文字の番号が即そのままバイト値）。
プログラムの変数名なんかは、encoding で統一してます。
Python では、
- encode
- 抽象的な概念としての「文字列」 → 具体的なバイト列表現
- 例:
u'いろは'.encode('shift_jis') - decode
- 抽象的な概念としての「文字列」 ← 具体的なバイト列表現
- 例:
'¥x82¥xa2¥x82¥xeb¥x82¥xcd'.decode('shift_jis')
というレイヤーがはっきりしてる（言うまでもないけど、矢印の左側が unicode オブジェクトで、右側が str オブジェクトということになる）ので、「文字コードを意識したプログラミング」がやりやすい。
しかしどうも世のなかには「文字コードを意識しないプログラミング」をしている時に問題がもっとも起きにくいのが文字コード処理に優れたプログラミング言語であると考える方々もいるようで。
……などとえらそうなことを書いてたら、掲示板をテストしていて気づいたことを書く時間がなくなってしまった。