BugTrack/246

UTF-8化したPukiWikiで、「～」の入った文字列が「〜」に化ける†

• ページ: BugTrack
• 投稿者: reimy
• 優先順位: 重要
• 状態: 保留
• カテゴリー: その他
• 投稿日: 2003-03-04 (火) 23:37:21
• バージョン:

メッセージ†

「～」の入った文字列をcopyして、UTF-8化したPukiWikiのフォームでpasteすると「〜」に文字化けする。

IMEから「～」を入力した場合は化けない。

しろくろのへやでは化けないので、PHP 4.3.0なら○。PHP 4.2.2なら×なのかな?

• 少し状況がわかってきました。pasteして更新した直後の表示では化けないようです。ところが、そのページを再更新すると化けます。 -- reimy 2003-03-07 (金) 22:16:28
  • 化けるときは、そのページのすべての「～」(xff5e)が「〜」(x301c)に化けます。手入力、pasteの違いはないようです。--reimy 2003-03-07 (金) 22:18:40
• PukiWiki側で対策とれないですかねぇ… -- reimy 2003-03-12 (水) 23:35:35
• 恐らく、init.php内のmb_detect_encodingが文字コードの判別に失敗しているんだと思うんですが、失敗したか否かを判別する有効な手段が…ありません。 X( -- ぱんだ 2003-03-13 (木) 15:05:55
• ちょっと調べてみましたが、Unicodeにおける各社ベンダとのマッピングの違いによるようです。cf. XML 日本語プロファイル, 変換表がベンダーによって異なる -- masao 2003-03-13 (木) 15:12:02
  • 知りませんでした。参考になります。 -- ぱんだ 2003-03-13 (木) 15:23:52
  • ということは、PHP 4.2.2とPHP 4.3.0はベンダーが異なる? 困ったもんだ… -- reimy 2003-03-13 (木) 21:27:43
• 暫定的な対策 -- reimy 2003-04-04 (金) 01:55:05

  ソースを書き換えるタイプのユーザー定義に「 '〜' => '～',」を追加して対処(pukiwiki.ini.phpで記述するときは〜と記述するのではなく〜を直書きすること)。泥縄的ですが…

  • PukiWiki-officialの雑談で、EUC-JPであっても、MacOS Xのsafariで書き込みをした場合に「～」が「〜」に文字化けするという報告があったけど、上記と同じ処理を組み込んでおけば防げるのではないかな? -- reimy 2003-04-04 (金) 02:32:08
    • iconv --list を実行するとサポートしているキャラクタセットが、いっぱい表示されますけど、普通に考えたら、例えば SJIStoJIS とか、EUCJPtoSJIS などのように、個別なキャラクタセット間の変換ロジックをコーディングするのではなく、何か基準となるキャラクタセット経由で変換するのが素直なはずなので、となると、GNU のiconv を利用している環境では、意識しないところで、Unicode経由で変換されていることが原因で文字化けが発生しているのでしょう。ということで、個別指定で、治ると思われます。--upk 2003-04-22 (火) 00:49:36
    • 補足ですが、古では、libiconv であり、現在では、glibc に iconv が組み込まれているので、その環境下だと、影響間違いなしですね。-- upk now
  • だとすると、他にもポンド記号やセント記号なども必要と言う事になるのでしょうか？ちなみにJavaの場合には ￠ ￡ ～ ∥ などこの辺のものが変換が必要でした。全部で６、７個あったような気がしますが失念しました。 -- ishii 2003-04-04 (金) 02:50:42
    • このパッチを参考にしてもらうと思い出すかなぁ？ -- upk 2003-04-22 (火) 00:35:18
  • 直接書くのは解らない人もいると思われるので \x301c とかの方がよさそうですね。 -- ishii 2003-04-04 (金) 03:33:49
• 横からすいません、試さずに書きますが php.ini の mbstring.* の値を全て UTF-8 にするのでは解決しないのでしょうか？ソースがEUCだからまずいのかな… -- ishii 2003-04-04 (金) 02:30:52
  • ソースもすべてUTF-8ですよ。PHP 4.3.0未満のmbstringそのもののバグ(変換テーブルの仕様の違い)なんです。 -- reimy 2003-04-04 (金) 02:33:01
  • あー、なんかJAVAでも1.3と1.4で変換テーブルが変わってて困ったことがあったような… X( -- ishii 2003-04-04 (金) 02:39:14
• 新人の入門編として、このバグを追っかけてみようかと思います (本質的に、PukiWikiの問題では無さそうなので、PukiWikiプログラム担当の入門にはならないか‥‥)。とりあえず、PHP4.3.0とPHP4.2.3について、mbstring拡張モジュールにおけるunicode変換テーブル（と思われるヘッダファイル）のdiffを取ってみましたが、日本語に関するテーブルに差異は無いようです。PHP4.3.0から、中国語、韓国語、ロシア語に（試験的に）対応するなど、mbstring拡張モジュールが大幅に変更されていますので（それ以前のPHPは、UTF-8をサポートしているものの、基本的には日本語のみに対応）、その辺のからみですかね？ バグが出るサーバーのphpinfo()を見せてもらえると有難いのですが。憶測ですが、結局のところはPHP4.3.0未満のmbstringはまずいので、解決するためには、mbstringに頼らずに、自前でコード変換をする、ってことになると思いますが‥‥。 -- 三浦克介 2003-04-22 (火) 08:42:25
• 4.2.2でのphpinfo()のmbstring -- reimy 2003-04-22 (火) 13:23:22
  
  • バグの状態を再現する為、configure command や mbstring.encoding_translation などの設定状況を見たいのですが、phpinfo の出力をオープンにしろというのは、セキュリティ上の問題が多く、無理な注文でしたね。ごめんなさい。とりあえず、PHP 4.2.x + UTF-8なPukiWikiをセットアップしてみます。バグが再現しない場合は、さらに情報提供をお願いするかもしれません。 -- 三浦克介 2003-04-22 (火) 17:52:21
    • いえいえ。すでにPHPを4.3.1に入れ替えてしまってるため、4.2.2当時のphpinfoの出力が手元に無いもので(^^;; -- reimy 2003-04-23 (水) 01:36:36
• mbstringの代用というと、PukiWiki/1.4/UTF-8化で使用するjcode_1.34が使えますね。これも日本語だけのサポートですが。 -- reimy 2003-04-22 (火) 13:26:51
  • jcode.php で事が済めば楽で良いのですが、ダメな場合は、PHP4.3.xのコードを参考に、jcode.phpを拡張することも視野に入れてます。 -- 三浦克介 2003-04-22 (火) 17:52:52
• この手の問題は、原因をハッキリさせておかないと、別の文字でも同様な問題が出てきて、何度も対策をしないといけなくなりがちです。時間はかかりますが、キッチリデバッグしておきたいと思います。仕事＆子育ての合間にやりますので、時間がかかると思いますが、ご容赦を。 -- 三浦克介 2003-04-22 (火) 17:53:28
• たしか、nkf 2.0の初期のもの(2.0.2よりも前のもの)*1やMacOS Xのsafari beta1*2でもチルダや～の文字化けが発生したので、関連してるかもしれません。 -- reimy 2003-04-23 (水) 01:42:45
• FreeBSD 4.6.2-RELEASE + Apache/1.3.26 + PHP/4.2.1 + UTF-8化 PukiWiki/1.4rc2 の組み合せをセットアップし、試して見ましたが、バグは再現しませんでした。どうやら、PHP4.3.0未満の問題でもないようです。サーバーで使われているライブラリの問題でしょうか。バグの再現がデバッグの第一歩ですので、バグを再現可能な方、サーバーの情報をできるだけ詳細にお教えください。phpinfo() の全出力をお送りいただくのが手っ取り早いです (テキストのみ、コピー＆ペーストしてお送り頂ければ結構です)。あと、クライアントの問題の可能性も捨てきれませんので、クライアントの情報（お使いのPCのOS、バージョン、ブラウザ）もお教え下さい。公開Webにこれらの情報を掲載するのは、セキュリティ上の問題があろうかと思いますので、私個人宛にメールして頂ければ結構です。 -- 三浦克介 2003-04-23 (水) 12:26:49
  • glibc の版など絡みませんかね？ -- upk 2003-04-24 (木) 13:35:15
• 分からない所もありますが、だいたいの原因が推定できました。長くなりますが、ご容赦を。 -- 三浦克介 2003-04-24 (木) 11:58:06
  • 結論から言うと、サーバーでコードが変化しているのではなく、クライアント (ブラウザ) で変化しており、サーバーのPHPが4.3.0以上か否かは本質的には関 係無いはずです。
  • このように推測した理由は、以下のような事実からです。
    • JIS/EUC/SJISからunicodeへの変換の仕方は、OS、ライブラリ、アプリケーションの種類、およびそれらのバージョンにより、若干の差異がある。差があるのは、以下の12文字。

      JIS X 0208/ISO 646 IRV	unicode
      0x5c(\)	0x005c 0x00a5
      0x7E(~)	0x007e 0x203e
      0x2131(￣)	0x203e 0xffe3
      0x213d(―)	0x2014 0x2015
      0x2140(＼)	0x005c 0xff3c
      0x2141(～)	0x301c 0xff5e
      0x2142(∥)	0x2016 0x2225
      0x215d(－)	0x2212 0xff0d
      0x216f(￥)	0xffe5 0x00a5
      0x2171(￠)	0x00a2 0xffe0
      0x2172(￡)	0x00a3 0xffe1
      0x224c(￢)	0x00ac 0xffe2

    • unicodeからJIS/EUC/SJISへの変換も、僅かながら差異があるようである。
    • PHP のmbstringは、iconvやglibcといった外部のライブラリに頼らずに、自前でunicode変換テーブルを持ってコード変換を行っている。
    • PHP 4.2.xとPHP 4.3.x の間に、日本語に関するunicode変換テーブルの差異は無い。
    • PHP 4.2.3リリースノートによれば、mbstringに関するいくつかのバグが修正されている。このバグの詳細までは調べていないが、JIS/EUC/SJIS->unicodeの変換はテーブルルックアップにより変換されており、バグの入り込む余地は少ない。修正されたバグは、コード検出や他のコード変換に関る部分と思われる。
    • PHP 4.3.0から、韓国語、中国語、ロシア語が試験的にサポートされている。しかし、日本語に関る変換には、基本的に影響は無いはずである。
    • UTF-8化PukiWikiでは、mb_internal_encoding('UTF-8') により、内部エンコーディングをUTF-8にしている。また、全てのPHPスクリプト、スキン、wikiデータもUTF-8化されている（CSSはSJISだが、これはPHPの処理には無関係)。従って、ブラウザから送られてくるGET/POSTのデータがUTF-8でない場合に、一度だけUTF-8への変換が行われる。ブラウザからUTF-8のデータが送られて来た場合は、一切コード変換せずに、出力される。
  • では何故、reimyさんが経験された、PHP4.2.2のサーバーのページで文字化けが生じ、PHP4.3.0のページで発生しない、といったことが起こるのか？ これが、分からない所です。
    • ほとんどあてずっぽですが、内部コードとしてJIS/EUC/SJISとUnicodeを併用していて、状況によって使い分けているブラウザがあるのではないかと考えられます。例えば、サーバーからUTF-8のデータを受け取った時、内容が全てJIS/EUC/SJISに変換可能であれば、これらのコードに変換して内部処理を行い、JIS/EUC/SJISへ変換できない文字が含まれている場合は、unicodeのまま処理する、というような処理をするブラウザであれば、見るページによって、ブラウザ内部でコード変換が起こったり、起こらなかったりします。前述のようなページがたまたまPHP4.2.xの上にあり、後述のようなページがたまたまPHP4.3.xの上にあったということではないでしょうか？
    • PHP4.2.xとPHP4.3.xで、HTTPプロトコルヘッダが違うのかな？というのも確認しましたが、特に変わっていませんでした。
  • 対策：ブラウザ側でコードが変わってしまう恐れのある文字は、pukiWikiの側で強制的に統一すべきと思います。
    • 統一するといっても、コードの重複があるので、ソース書き換え型ユーザー定義での置換が使えないですねぇ。-- reimy 2003-04-24 (木) 14:01:02

                     ○     ×
      x5c(\)       x005c  x00a5     x00a5 → x005c 重複
      x7E(~)       x007e  x203e     x203e → x007e 重複
      x2131(￣)    xffe3  x203e     x203e → xffe3 重複
      x213d(―)    x2015  x2014     x2014 → x2015
      x2140(＼)    xff3c  x005c     x005c → xff3c 重複
      x2141(～)    xff5e  x301c     x301c → xff5e
      x2142(∥)    x2225  x2016     x2016 → x2225
      x215d(－)    xff0d  x2212     x2212 → xff0d
      x216f(￥)    xffe5  x00a5     x00a5 → xffe5 重複
      x2171(￠)    xffe0  x00a2     x00a2 → xffe0
      x2172(￡)    xffe1  x00a3     x00a3 → xffe1
      x224c(￢)    xffe2  x00ac     x00ac → xffe2

      重複コードをどのように変換するか問題ですね。この重複するコードってus-asciiとjisでの差異(backslashとyen、overbarとtilde)をそのまま引きずってるわけかぁ…。

• とりあえず、重複しないものだけをソース書き換え型ユーザー定義に登録。-- reimy 2003-04-24 (木) 14:23:36
  • '—' => '―',
    '〜' => '～',
    '‖' => '∥',
    '−' => '－',
    '¢' => '￠',
    '£' => '￡',
    '¬' => '￢',
• マイクロソフトのサポート技術情報にもSHIFT-JISとUTF-8との相互変換(Code Page 932テーブル)の「既知の問題」が掲載されてますね。根が深い… -- reimy 2004-03-01 (月) 02:40:11
  • エンコーディングの問題は、ほんと、厄介です。早く、どれかに統一されると良いのですが・・・。 -- 三浦克介 2004-03-03 (水) 18:01:28

• BugTrack
• 開発版
  • リポジトリ
  • 開発日記
• :CategoryDev
  • PukiWiki2
  • PukiWiki/1.5
  • PukiWiki/1.4
  • PukiWiki/1.3
  • メーリングリスト
  • 開発談義
  • 雑談
• 開発者向け情報
  • Books
  • プラグイン

最新の16件