TSNETWiki

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• UTF8フラグ へ行く。
  • 1 (2011-10-09 (日) 12:15:48)
  • 2 (2011-10-09 (日) 12:15:48)
  • 3 (2011-10-09 (日) 19:47:19)
  • 4 (2011-10-10 (月) 00:48:00)
  • 5 (2011-10-12 (水) 12:45:34)
  • 6 (2011-10-13 (木) 18:55:23)
  • 7 (2011-10-13 (木) 18:55:23)
  • 8 (2011-10-13 (木) 18:55:23)
  • 9 (2011-10-13 (木) 18:55:23)
  • 10 (2011-10-13 (木) 18:55:23)
  • 11 (2011-10-13 (木) 18:55:23)
  • 12 (2011-10-27 (木) 10:41:25)
  • 13 (2011-10-27 (木) 10:41:25)
  • 14 (2022-07-21 (木) 20:49:10)
  • 15 (2022-08-19 (金) 17:04:43)
  • 16 (2022-08-31 (水) 01:06:38)
  • 17 (2022-09-02 (金) 09:55:53)
  • 18 (2022-09-04 (日) 18:39:44)
  • 19 (2022-09-12 (月) 09:59:23)

---

Perl | Sjis.pm | EUCJP.pm | UTF2.pm | jacode.pl | Char.pm

UTF8フラグに関する情報

• UTF8 フラグあれこれ
• 図解: Perl と Unicode 文字列
• Perl 5.8.x Unicode関連
• Perl5.8でUTF-8のメモ
• use Encode;
• perl - utf8::is_utf8("\x{ff}") == 0
• perl - use utf8; #って何だ?

UTF8フラグは何が間違っているのか？

• 「文字列」という用語をアプリケーションプログラマとインタプリタの間で共有できないものにしてしまった。
• システムが利用者に合わせてくれず、利用者がシステムに合わせなければならない。
• アプリケーションプログラマは自分が扱う文字列の他にインタプリタのための文字列も扱う必要が生じて、仕事が増えた。
• UTF8フラグの状態遷移(ONからOFF、およびOFFからON)は直交しておらず、事態をさらに複雑にした。
• せっかくUnicodeを開発してモードを排除したにも関わらず、UTF8フラグによってまたモード式に戻ってしまう。

文字とコンピュータ

• コンピュータは文字を扱うことはできないため、個々の文字に割当てられた数値を扱う。
• 数値の処理結果を利用して「文字を扱っていることにしている」のは人間の脳の働きである。
• とあるバイト列がバイナリデータなのか文字列なのかは人間にしか区別することはできない。
• 心のないコンピュータにはこれらの区別を行うことができない。
• UTF8フラグはこれらの２つをコンピュータによって区別する試みであったが、必ずしも利用者の心と一致する結果とはならない。

どのように解決するか？

• システム的にはバイナリのバイト列と文字列を区別なく扱い、それらの区別は人間が行うという従来の方法に戻す。
• 文字列はバイナリのバイト列としても扱えるのはもちろんのこと、バイナリのバイト列は文字列としても扱えるように戻す。
• 一度に扱う符号化方式はひとつだけにする。
• UTF8フラグを使用しないようにする。

将来に向かって

• 同様の失敗を繰り返さないよう、UTF8フラグおよびこれらの知見を公開し保存する。
• WindowsでPerl 5.8/5.10を使うモンじゃない
• Shift-JISテキストを正しく扱う
• UTF-8フラグの立て方・降ろし方
• Perl::utf8.pm
• utf8::is_utf8 considered harmful

PerlのUTF8フラグは必要なものですか？

選択肢	投票
UTF8フラグは必要不可欠	1
UTF8フラグはないほうがよい	5
わからない	0
その他	0