◀一般トップへ
  • 3099 [事例報告]言語と文字化け
    • 3106 Re:[事例報告]言語と文字化け
      • 3107 Re2:[事例報告]言語と文字化け
        • 3109 Re3:[事例報告]言語と文字化け
          • 3306 Re4:[事例報告]言語と文字化け
            • 3382 Re:5; [事例報告]言語と文字化け
              • 3393 Re2:5; [事例報告]言語と文字化け

  • [3099] [事例報告]言語と文字化け ばく 2003年07月23日 23:50

    486-PenIIIまで、いろんな所で愛用させて頂いてます。
    表題の件ですが、多少特殊な条件下で使用すると、
    張り付けした日本語文字列が文字化け("?"になる)する
    ようです。

    101キーボードでも同じ操作で日本語/半角英数入力を
    切り替えるために、キーボードコンパネで、「英語」
    を追加。
    コピー元のアプリケーションが「英語」の時にコピー
    してサクラに張り付け→文字化け、となります。
    サクラエディタの言語モードは関係無いようです。
    また、ドラッグ&ドロップでは文字化けが起こらない
    ようです。
    サクラエディタからMozillaへの張り付けで文字化けを
    見たことがありますが、ちょっと詳細を確認出来てい
    ません。

    出来れば対応していただけると嬉しいですが、バグと
    言い切れたものでもないので、とりあえず事例報告
    ぐらいで書かせて頂きました。

    • [3106] Re:[事例報告]言語と文字化け 蒔田　信幸 2003年07月24日 21:12

      ▼ ばくさん
      > サクラエディタからMozillaへの張り付けで文字化けを見たことがありますが、ちょっと詳細を確認出来ていません。

      突然で、失礼します。
      お尋ねしますが、Sakura に貼り付ける前から既に"?"になっていませんか？

      • [3107] Re2:[事例報告]言語と文字化け みく 2003年07月24日 21:18


        http://www.geocities.jp/ht_deko/oldjunk.html

        にある、クリップボードフォーマット解析支援ツールが使えませんか。

        サクラは、CF_OEMTEXT を使ってるはずです。
        ＃ちなみに、CF_OEMTEXTだとAccessからの貼り付けでカラムの幅を超えるデータが切れます。

        • [3109] Re3:[事例報告]言語と文字化け ばく 2003年07月25日 00:39

          > http://www.geocities.jp/ht_deko/oldjunk.html
          > にある、クリップボードフォーマット解析支援ツールが使えませんか。
          > サクラは、CF_OEMTEXT を使ってるはずです。
          > ＃ちなみに、CF_OEMTEXTだとAccessからの貼り付けでカラムの幅を超えるデータが切れます。

          みく　様、

          ご紹介のツール、落として使ってみました。大当たりです。

          ・ソフト：IE5.0、Mozilla1.2.1
          ・ロケール：「英語(US)」、「日本語(IME2000、直接入力)」
          1.ソフト2種*ロケール2種、計4種の場合で、文章を選択→コピー
          2.それぞれのクリップボードの内容を、解析画面に現れた全てのフォーマットで保存。
          3.保存した.datファイルをサクラエディタで開き、内容を確認
          「入力ロケール」が「英語」の場合、CF_OEMTEXTが文字化けしているようです。
          一方、試した範囲では、CF_TEXTは文字化けしていませんでした。

          取り急ぎ報告まで・・・。

          • [3306] Re4:[事例報告]言語と文字化け wmlhq 2003年09月18日 10:50

            ▼ ばくさん
            > 「入力ロケール」が「英語」の場合、CF_OEMTEXTが文字化けしているようです。
            > 一方、試した範囲では、CF_TEXTは文字化けしていませんでした。

            CF_LOCALEを見ていないことが原因かも。ロケールが違ってたらLCMapStringで変換して。CF_LOCALEのデータが無かったら対処しようが無い。それはOEMCPを無視した側のバグということで。CF_OEMTEXTが信頼できないのであれば、CF_TEXTかCF_UNICODETEXTを見るべき（優先順位はCF_OEMTEXTの方が高いが）。SetThreadLocaleについては？

            • [3382] Re:5; [事例報告]言語と文字化け ばく 2003年10月15日 21:00

              申し訳ないですが、プライベートがばたばたしていて、しばらくチェック不可です。使用しているWindowsそのものは日本語版なので、誰でも出来る事なのですが・・・。
              ▼ wmlhqさん
              > CF_LOCALEを見ていないことが原因かも。ロケールが違ってたらLCMapStringで変換して。CF_LOCALEのデータが無かったら対処しようが無い。それはOEMCPを無視した側のバグということで。CF_OEMTEXTが信頼できないのであれば、CF_TEXTかCF_UNICODETEXTを見るべき（優先順位はCF_OEMTEXTの方が高いが）。SetThreadLocaleについては？

              • [3393] Re2:5; [事例報告]言語と文字化け wmlhq 2003年10月16日 11:49

                余計なことを言ってすみません。議論は、CF_OEMTEXTよりも標準的なCF_TEXTを使う方向で進んでいる。CF_TEXTならこの問題は間違いなく解決。
                # 国際化なら、GetThreadLocaleとGetDefaultUserLCIDを使う方針。