パスワードを忘れた？ アカウント作成
Close
383736 journal

Oliverの日記： test.slashdot.jp TODO (随時更新) 47

日記 by Oliver

test.slashdot.jpのテスト、開始当初はチューニング不足でOOM状態でswap stormになり実質停止したりしたが、いまでは安定して動いている様だ。こまかい指摘は多数いただいているが、致命的なバグはいまのところ発見されてない。これから友達データも含めた新しいデータを移行する前に、各所に分散しているバグ報告をTODOの形でここにまとめる、随時更新する。

  • アツイコメントのスラッシュボックスの中身がオカシイ? (#757145)
  • コメント数が多すぎて分割される時、ネストだと切れ目がおかしい? (#757827)
  • ユーザ設定で、トップページの設定を保存すると並び順が変わってしまう (#75682)
  • 「ユーザスペース」スラッシュボックスで使えるタグが制限されるようになった。使えるタグを明記。自己紹介や署名欄も (#75682)
  • コメントフィルタの整理・移行
  • linuxkernelセクションのスラッシュボックスをlinuxセクション用に変更 → 移行スクリプトに組み入れ
  • ケータイ版。現時点ではまだノータッチ
  • サイドバーのチェック
  • 記事本文の終わりに(none) -> 広告のテスト
  • 空白のない長い文章に空白が強制挿入されるが、日本語はブラウザがやるので対象外に
  • モデレーションの詳細以下の邦訳 (#756541以下のスレッド)
  • FoFの邦訳 -> 再びストーリ立てて案を募集

  • IDN未対応->「日本語.jp]へのリンク (test上のコメン ト)

  • トピック増強。本家からいくつか持ってきたり、真面目なモノ以外には日記用に「エロ」を増やしたり、ついに鉄道をいれてもいいかな、と思ったり
  • メッセージで発送されるメールのSubject:がMIME-encodedなUTF-8。これで間違いではないが、完璧にするならISO-2022-JPに (タレコミ)
  • データ移行時に全角逆斜線が半角逆斜線に誤変換 (#758774)
  • article.plで表示されるユーザプロファイルが不評？非表示に？

解決済：

  • セクションページで左上のユーザ情報のリンクが/section/~foo/になっていて404 (タレコミ)
  • タレコミページの連絡先欄に二重括弧 (タレコミ)
  • Copyright表記の2005年対応 (test上のコメント)
  • コメント設定の誤植：「スコアを表示しない (しきい値は適用さる」->「適用される」、「インデックスに溢れる」->「に漏れる 」or「インデックスモードへ移行」あたり (#756582)
  • パスワード変更画面の誤植：「認証クッキーが無効なり」→「認証クッキーが無効になり」 (test上のコメント)
  • ログイン設定のマシン種別が未訳 (#757549)
  • 日記へのコメントだけウェブでメッセージが飛ばない? (#757719) →テンプレートがバグってて発送されてなかった
  • 各Indexページの「もっと読む」のリンクがストーリーの所属セクションへのモノじゃない
  • モデレーションの任意のスコア補正が設定できなくなっていたNoGoodさんの日記とタレコミ)→本家仕様でバリバリにハードコードされてたので改善 ([Slashdotjp-dev 303])
  • M2の「see context」リンクが抜けてる? (test上のコメント)
  • M2で初期状態ではラジオボタンが未選択(test上のコメント)
  • 自身のユーザ情報のスラッシュボックスにメールアドレスが「非表示」設定でも表示される (#75682) →バグではなく仕様、が変更
  • コメントのメッセージ：自分自身もしくは自分がACとしてコメントした場合は発送されない?　(タレコミ) →自分自身の場合発送されないのは仕様。ACが発送されないのはメッセージの設定にある「しきい値」が設定されてない場合のデフォルトが1だったから。0に変更
  • delとinsタグを許可するタグのリストに追加。citeとdatetime属性をそれぞれ許可。(NoGoodさんの要望)
  • firefoxで本来不要な横スクロールバーが出る (test上のコメント)
  • アイコンを表示しない設定時のトピック表示 (#756781)
  • 静的ページの「もっと読む」リンクが/slash/slash/風に間違ってる→解決、残ってるのは静的ページ再構築時に修正される
  • 一部ユーザが日記があるにもかかわらずユーザ情報のページには「日記を書いてないと表示される」(タレコミ) →　要約として抽出される日記の一行目が短い場合のバグ。users.pl 1.8で修正。正規表現はパーザーになったつもりで分解していけば、いつかは理解できる。
  • ライトモードで一部 white-on-white (#757357)→ IF user.light式で回避。CSSを使った抜本的対策が必要。が、ライトモードなUAはちゃんとCSSに対応してる？
  • 掲載記事の時間が強制的に20分未来→すぐに記事が表示されない本家仕様(編集者からの指摘)、0秒未来に設定してたらperlのIFでは偽と判定されてしまう。Ruby慣れしすぎだ。
  • 「公衆端末」の解説 →メインのログインフォームで解説：10分有効のクッキーがアクセスの度に期限更新
  • 「公衆端末」チェック状態でログインに失敗しても、チェックが消えない
  • 本家からSupercomputing, Math, Imput Devicesトピックもってくる
  • ストーリー表示画面右上、ユーザボックスからユーザ情報へのリンクが間違い。 gSkin.rootdir -> constants.absolutedir
  • 各セクション内のページで左上のロゴのリンクが各セクションのページをさしていたのが不評だったので、本当のトップページに変更
  • 最大パスワード長が減った？ログインできない (#757193) →前から20文字だった。超初期に一時的に32文字と表示だけされていた可能性はアリ

ちなみに、友達データの公開を発表してからの縁切りは約80件で、全体の0.4%。2-3人がガバっと整理した分が大半の様だ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

test.slashdot.jp TODO (随時更新) More

  • トピク増強 (スコア:1)

    by targz (14071) on 2005年06月27日 16時38分 (#758790) 日記
    ＞ついに鉄道をいれてもいいかな、と思ったり

    鉄道よりは「運輸」か「交通」の方がいいかと思っています。バス・船・飛行機の話題も扱えますから。

    • Re:トピク増強 (スコア:1)

      by NyaNya (12681) on 2005年06月28日 0時09分 (#759014) 日記
      たーべーもーのー。

      日記を意識してトピ増やすなら食品関係を是非是非。
      まぁわたしが使うかはともかくとして、需要はあると思いますよ。
      シェア
      親コメント

    • Re:トピク増強 (スコア:1)

      by loli (26882) on 2005年06月30日 21時29分 (#760587)
      食事。
      旅行。
      韓国or韓流orドラマ。
      iPod　etc（アップル・音楽・携帯通信？？
      覚え書き。
      あと、*んこ。（カス日記（ネタじゃないよ

      よろすくです。
      シェア
      親コメント

      • Re:トピク増強 (スコア:1)

        by targz (14071) on 2005年07月01日 16時41分 (#761112) 日記
        ＞iPod

        これはわたしも希望します。iPod+iTunes という名前でもいいですが、iPod だけのがいいかな。
        1つの社会現象となってしまったモノだけに独立トピックを作るに相応しいでしょう。

        ＞*んこ。（カス日記（ネタじゃないよ

        ごめんなさい。意味が分かりません……。

        あと、ありそうで出てないのは、
        ・USB
        ・Ethernet
        ・WiFi
        でしょうか。なんか USB トピックには「親指 USB メモリ」「USB 扇風機」のようなデバイスねたばっかりになりそうな気もしますが、それはそれで一興でしょう。
        シェア
        親コメント
    • Firefox。
      いや、Mozilla [slashdot.jp]の絵では合わないというだけで。
      シェア
      親コメント
  • 今回、トモダチデータを移行されたようですね。
    警告に従い、あらかじめ
    トモダチリストを全部削除しておいたのですが、

    testで７ユーザーほど「復活」してました。

    おまけに本番環境でも１ユーザー「復活」してました。

    いまさらFoF導入の是非を論じる気などありません。
    せめて、ほっといてくれませんか。
    • 本番環境からデータを取っているので、本番環境で消さない限り、いくらtest上で消したところ、データ移行時にtestで復活します。現時点でもisiさんは本番環境で友達を数人設定しているので、これらを本番環境で消さない限り、次の移行時にはまたtestで公開されます。

      本番環境で勝手に復活した、という報告はにわか信じられません。ちゃんと消えてなかった、確認を行ったということはありませんか？本番環境のDBには一切、手を加えてませんし、自然復活というのも原理上難しいです。
      シェア
      親コメント
      • 6月13日ごろ、本番環境、および旧テストスラッシュそれぞれで日記全エントリおよびトモダチリストの全ての削除を行いました。

        本番環境、旧テストスラッシュそれぞれで、削除され一切登録されていない状態になっていることを確認しています。

        その後、旧テストラッシュが閉鎖されたのを見て、6月15日の日記エントリを登録しました。
        6月23日に現行のテストスラッシュ公開がアナウンスされましたが、本番環境のトモダチリストは未登録、「あなたはまだ友達を作っていません．（あるいは，友達になったひとがまだ日記を書いてないんでしょう）」という表示のままでした。

        6月27日に本番環境のトモダチリストにひとりが「復活」していることに気がつき、テストスラッシュも確認して7人ほどの「復活」を確認しました。

        現在、改めて本番環境、現テストスラッシュでトモダチリストの削除を行い、一切登録されていない状態になっていることを確認しています。(なお、日記は現環境では6月15日と6月27日、現テストスラッシュでは6月15日のエントリが登録されています。これは正常な状態ですね）

        いま、管理者として私のトモダチリストを確認し、だれかが登録されているように見えるなら異状であるといえるでしょう。

        また、次回トモダチリスト移行後に「復活」現象が発生するかどうかで、異状の有無を確認できるでしょう。
        シェア
        親コメント
        • 非常に興味深いです。追加情報を元にもっと詳しくコードを追ったところ、現行システムの仕様というかバグが復活現象と絡んでいる事が分かりました。

          というのも、現行のシステムは日記のアンテナとして位置づけられているので、友達一覧 [srad.jp]にでてくるのは日記を書いている友達だけなのがコードから読み取れました。友達登録のURLをイヂって本来なら友達登録できない、日記を書いてないユーザを登録していたり、友達が日記を全削除した場合はリストに表示されませんが、友達データとしては残っています。

          FoFデータへの変換は日記の有無に関係なく、友達データだけを元にしているので、これまでは表示されていなかった人が登場するという、「復活」現象になります。現行システム上でも、日記を書いてなくて失踪状態(?)だった友達が再び日記を書くと復活します。

          ユーザインタフェースの友達リストが空になっている事を目視したisiさんと、データベースをみて友達データがあると確認した自分の視点の違いに気がつかないまま、まるでisiさんに操作ミスなどの落度があるかの様な書き方をしてしまい、申し訳ありませんでした。削除したい意志を明確にしてらっしゃるので、残っていたisiさん分の友達データはすべて手動で抹消させていただきました。

          TODOメモ：

          被友達登録されているが日記を書いていないユーザの数、約250
          それらユーザが絡む友達リストに出ていない友達関係の数、約1100

          調査方法：select distinct friend from journal_friends where friend not in (select uid from journals);

          さて、これらはどうすべきか。移行前に友達関係を設定したユーザが自力で削除することができないので、そのまま移行してしまうのはマズイ。かといって、勝手にぜんぶ削除してしまうのもあまりヨクナイ。が、ユーザはその友達関係の存在を認識していない可能性が大きい。dead codeな現行システムに数行パッチ以上に手をいれる工数は割けない。トレードオフを考えて、やっぱり一律削除か？
          シェア
          親コメント
          • というのも、現行のシステムは日記のアンテナとして位置づけられているので、友達一覧 [srad.jp]にでてくるのは日記を書いている友達だけなのがコードから読み取れました。友達登録のURLをイヂって本来なら友達登録できない、日記を書いてないユーザを登録していたり、友達が日記を全削除した場合はリストに表示されませんが、友達データとしては残っています。
            一部ユーザには有名な話ですねー。
            わたしも以前日記に書いた(一番下あたり) [srad.jp]ことありますし、
            その時のコメント [srad.jp]で、有効活用(？)してる例も出ました。
            さて、これらはどうすべきか。移行前に友達関係を設定したユーザが自力で削除することができないので、そのまま移行してしまうのはマズイ。かといって、勝手にぜんぶ削除してしまうのもあまりヨクナイ。
            一括削除はんたーい。
            確かにそのまま移行はまずそうですが、
            でも勝手に消されるのはそれはそれで困るかも。

            で、一つ思いついた方法としては、
            「被友達登録されているが日記を書いていないユーザ」に、
            ダミー日記エントリを強制投稿してしまう。
            てのはどうでしょうか？

            まぁこれはこれでかなり乱暴だと思いますが、
            こうすれば友達リストには出てきますよね。
            移行直前の数日前に強制投稿→移行後には削除
            としておけば、被害は少なそうですし。
            シェア
            親コメント
            • ちょっと読解力が不足気味な状態なので、勘違いしていたらごめんなさい。
              > 「被友達登録されているが日記を書いていないユーザ」に、
              > ダミー日記エントリを強制投稿してしまう。
              > てのはどうでしょうか？

              > まぁこれはこれでかなり乱暴だと思いますが、
              > こうすれば友達リストには出てきますよね。

              とのことですが、NyaNya さんは二重の意味で勘違いなさっているように読めます。

              まず、「友達リストには出てくる」の部分。
              最初の isi さんの要望は「出てこない様にして欲しい」と言っている様に私には読み取れました。
              そのため、NyaNya さんの案ではかえって isi さんの要望と反対の方向へ流れていってしまうように読めます。

              次に日記エントリのないユーザが友達リストに表示されない、という件。
              これは現行のシステムがそうなっている、という話で、testslash の方では表示されます（今確認したばかりですが）。
              いずれ消えるのでリンクは貼りませんが、testslash の私のユーザ情報の friends 欄を御覧下さい。
              既に御存知とは思いますが、各ユーザのユーザ情報を表示させれば、「Relation」という Friend or Foe 関係の変更設定ページへのリンクがあります。
              したがって、復活現象が起きた時でも、ユーザが一手間かければ削除できるわけですが、移行時にまとめてやってしまおう、というのが Oliver さんの案、と認識しています。

              以上のような理由で、私の認識では NyaNya さんの案より Oliiver さんの案のほうが妥当だと思います。
              # よりよい第三の案はきっとどなたかが提案して下さるでしょう ;-p

              --
              mobile ID portable_NoGood [slashdot.jp] 併用中
              シェア
              親コメント
              • しまった。一行すっぽり抜けてしまった。申し訳ありません．
                > いずれ消えるのでリンクは貼りませんが、testslash の私のユーザ情報の friends 欄を御覧下さい。

                > 既に御存知とは思いますが、各ユーザのユーザ情報を表示させれば、「Relation」という Friend or Foe 関係の変更設定ページへのリンクがあります。

                の間に、「日記エントリのない view さんというユーザを Friend 登録してあります。」という文章を脳内挿入して下さい。

                # 全く無関係ですが、黒くて楕円形の人間の敵、「G」を投稿フィルタの文章に盛り込むのは勘弁して下さい (;_;

                --
                mobile ID portable_NoGood [slashdot.jp] 併用中
                シェア
                親コメント
              • ぅぅ二重に勘違いされてる気が。
                ＃てかこの案で一番肝心な、
                ＃「移行直前の数日前に強制投稿→移行後には削除 とすれば～」
                ＃が引用されてないのは何故？
                まず、「友達リストには出てくる」の部分。
                最初の isi さんの要望は「出てこない様にして欲しい」と言っている様に私には読み取れました。
                わたしは「(少なくとも)移行後の環境では」出てこないようにして欲しい、と読みました。
                ので、「移行前の数日」見せれば(ユーザが整理できるので)良いかなと。
                次に日記エントリのないユーザが友達リストに表示されない、という件。
                これは現行のシステムがそうなっている、という話で、testslash の方では表示されます（今確認したばかりですが）。
                これは知ってます。
                あのコメント投稿前に自分の Friends を確認したので。
                ＃わたしは5人ほど「表示されてない友達」がいます
                だからこそ、一括削除には反対なわけで。
                自分のリストの一部も削除されてしまうわけですから。

                ＃「ガバッと整理した」2～3人のために、
                ＃250人のお友達リストに手をつけるってのはちょっと・・・
                シェア
                親コメント
              • ちょっと勘違いされている気配なので、わたしの案の補足など。
                このコメント [srad.jp]で書いた案は、
                移行直前の数日前に、
                「被友達登録されているが日記を書いていないユーザ」に、
                ダミー日記エントリを強制投稿してしまう
                ↓
                友達登録されているユーザは全部リストに表示されるようになるので、
                「整理」したいユーザは自分でリスト削除とかする
                ↓
                ～～～～～移行作業開始～～～～～
                ↓
                ダミー日記エントリを全削除
                ↓
                ～～～～～移行作業終了～～～～～
                ↓
                新システム運用開始
                という流れです。
                「移行前に」「自分の意思で」削除できるようにして欲しい、
                ってのがポイント。
                ただし、日記を「消した」ユーザの意思は無視する格好になります。

                あと、この案は、
                「dead codeな現行システムに数行パッチ以上に手をいれる工数」より、
                「ダミー日記エントリを強制投稿＆全削除する工数」のが少ないのが前提になってます。
                ここはコード読んでないので分からないんですけど、
                まぁ実行するのはわたしじゃないですし（ぉぃ


                あ、あともう一つの案として、
                (見えないお友達を含め)リスト全削除したい人は、運営にメールする。
                てのがあります。
                これは「"ガバっと整理"したい人数が少ない」てのが前提。
                でないと運営の手間が大きそうですし。
                シェア
                親コメント
              • はぅ、やっぱり勘違いしてました、というか二ついただいたコメントをよく読んで理解できました。
                > 「移行前に」「自分の意思で」削除できるようにして欲しい
                この２点のポイントをすっかり読み飛ばしてたっぽいです（汗
                --
                mobile ID portable_NoGood [slashdot.jp] 併用中
                シェア
                親コメント
          • お返事が遅くなりました。
            対応、ありがとうございました。

            TODOについて対応される際には、
            十分な事前アナウンスをお願いします。
            どのような手法を取るにせよ、事前のアナウンスが
            Oliverさんの工数以上に負荷を減らすことになると思います。
            シェア
            親コメント
  • 「携帯通信」を「携帯電話」と「通信」に分離することを提案します。
    今のままだと、ケータイデンワのHWネタも通信事業ネタもすべて携帯通信なので、ちと違和感が(^^;

    「鉄道」トピックはNyaNyaさんが仰るように、「運輸」または「交通」と大枠で括った方が扱いやすいですね。
    • 同じ理屈で「アニメ・マンガ」もそれぞれ独立すべきだと思いますし、「Digital」なんていう今は亡き企業のトピックはさすがに不要じゃないかとも思います。
      「スポーツ」もメジャードコロは独立させても良いと思いますし、この際ですからトピック全般を見直す時期が来た、と診るべきじゃないでしょうか。

      # 「ゲーム」から「Quake」だけ独立してるのは「3D ベンチマーク」とか「（他のゲームの基礎となる）レンダリングエンジン」とかの意味合いもあるのかな？とか。

      --
      mobile ID portable_NoGood [slashdot.jp] 併用中
      シェア
      親コメント
    • 重要な点は、こういうトコロでは本家に右へならえではなく、/.-J のオリジナリティというか差別化を図って逆輸入してもらう、くらいの意気込みでやったほうがよいのでは？という趣旨が述べたかったのです。
      # 勘違いというか、誤解されてしまうと困るので一応。
      --
      mobile ID portable_NoGood [slashdot.jp] 併用中
      シェア
      親コメント
      • 同意します。こういうのこそwikiでやるべきかも。
        /.J Wiki [osdn.jp]にでもページを作って、現在のtest.slashdot.jpで設定されているトピックの構造を書いて、それに対して追加と削除と変更をワイワイやっていくのが効率いいかもしれません。

        で、トピックの一覧まではテキストに抜き出しましたが、さすがに独断でやっちゃっていいものかどうか不明なので、待機中。
        どうでしょう？ ＞ Oliver氏
        シェア
        親コメント
        • > こういうのこそwikiでやるべきかも。
          基本的には同意なんですけど、Wiki の性質上荒らされたりするのが心配です。
          荒れるだけならいいんですけど、折角の成果をさっぱり削除されちゃい得るので…
          > さすがに独断でやっちゃっていいものかどうか不明
          そうですね。最低限告知だけは先にしておかないと後で無駄な批判で荒れそう、という点も心配ではあります。
          # この点については反省しています（後悔はしていませんが）。

          今後この件に関しては slashmaster の判断に委ねます（ということにしておきます）。

          --
          mobile ID portable_NoGood [slashdot.jp] 併用中
          シェア
          親コメント

    • Wikiで議論するかなんて話もでてますが、忘れてしまうかもしれないし今のうちに案をいくつか挙げときます。長文御免。

      • 法（アイコン図案：天秤、書類の束）
      • 著作権（丸Cマーク）
      • ライセンス（書類の束、EULAの文面の一部、握手している手）

      現在「政治」「法廷」「パテント」「GNU」などがありますが、それらでカバーしきれない話題も多いでしょう。「法」は法案なども含むトピックカテゴリとして。

      • インターネット標準または標準仕様（RFCやW3Cなどの文字を組み合わせたもの）
      • ウェブ（「http://」と見えているロケーションバーの一部）

      ウェブに関する特定の話題を「インターネット」とするのは違和感がありますし、「リンク」でカバーしきれないものもあるでしょう。また『電車男』などのウェブ上の流行ものが話題になったとして、そこでトピック「インターネット」ってのも変でしょうし。

      • Yahoo、Wikipedia、はてな（使えるならそれぞれのロゴ）

      「AOL」があるぐらいならこれらがあってもよかろうと思ったんですが、なくてもいいかも。「クリエイティブコモンズ」も考えたけど、特定の日記エントリをCCライセンスにしたいと思った人がトピック「CC」を選択したりして、使い方が紛らわしいんじゃないかと問題になりそうな気がします。CCライセンスの話題があっても「ライセンス」があればそれで済むでしょう。

      • テーブルゲーム（チェスか将棋の駒、碁石）
      • パズル（本家の凸型の物体アイコン、ルービックキューブ）

      「ゲーム」の細分化。

      • モータースポーツ（タイヤ、車のエンジン）

      野球やサッカーなどにあわせた細分化の必要はないと思います。個人的には日記で野球ネタも書いているんですが、それら競技のみでストーリーになることは少なそうだし（ソフトバンクなどの参入話、阪神仕様の製品、Yahoo!BBスタジアムと、野球そのものだけでストーリーになっていない）、あれもこれもとなるとキリがない。F1はそれ自体でストーリーになっているし、「モータースポーツ」はあって良いと思います。

      シェア
      親コメント

    • Re:トピック増強案 (スコア:1)

      by NyaNya (12681) on 2005年06月30日 22時02分 (#760602) 日記
      いあ、わたしはそんなこと仰ってませんが・・・(=-_-;=)

      ＃このコメント [srad.jp]のことですよね？
      シェア
      親コメント

  • 文字化けします… (スコア:1)

    by hinata (6921) on 2005年06月30日 16時02分 (#760431) 日記
    ユーザ設定の『署名』『自己紹介』に日本語が入りません。
    MacOS9.2のIE5.1.6使用です。

    文字が化けるのには慣れっこなオールドMacユーザーですが…とりあえず一言ご報告を。そんな風に見えているひとも（ほんの数パーセントかもしれませんが）いてるんですよーっという表明になれば…。

    我慢してくれって言われそうですが。
    • 御使用の環境で、ユーザの環境設定によりデフォルトエンコードを「Unicode（UTF-8）」に設定できますか？
      もしできるなら、そのように設定を変更してからもう一度試して結果をコメントして下さい。

      # このようにすることでクライアント側の原因が一つ減るはずです。
      ## 私の推論に誤りがあれば御指摘下さい＞識者および slashmaster

      --
      mobile ID portable_NoGood [slashdot.jp] 併用中
      シェア
      親コメント

      • Re:文字化けします… (スコア:1)

        by hinata (6921) on 2005年06月30日 22時36分 (#760621) 日記
        IEの初期設定の「言語・フォント」というところで変更する…のですよね。そうだと仮定して実験してみました。
        そもそも、日本語には
        自動判別
        JIS
        シフトJIS
        EUC
        の四項目しかありません。ご指摘のUnicodeは見あたらないようです。とりあえずかたっぱしから変更して試してみましたが、文字化けは直りませんでした。
        シェア
        親コメント
        • > 四項目しかありません。ご指摘のUnicodeは見あたらないようです。
          公開β告知 [srad.jp]の際に文字コードは UTF-8（Unicode）を使用している旨の記述があるので、クライアントが UTF-8 を送信できず、サーバがクライアントの送信してきた文字コードを UTF-8 に変換できない、という状態だと思います。

          サーバ側で様々な文字コードを解釈できるのが理想的な状態というか本質的な解決策なのかもしれませんが、手っ取り早い方法としては hinata さんの方で歩み寄って UTF-8 の使えるウェブブラウズ環境を整えることで解決できるのではないかと思います。

          大変申し訳ありませんが、hinata さんの環境は私の使った事が無いモノなので、私が助言できるのはここまでです。
          # だ、誰か続きを…（汗

          --
          mobile ID portable_NoGood [slashdot.jp] 併用中
          シェア
          親コメント
    • 新システムでは文字コードをUTF-8で統一しています。通常はブラウザが表示の文字コードにあわせて送信するデータの文字コードも変換してから投稿するのですが、念のためにUTF-8 → ASCII → EUC-JP → Shift_JIS → 7bit JISの順番で文字コードを推測して変換する処理も入れてあります。どのような文字がどのようなコードで入ってしまっているのか見るために、もう一度test上に署名と自己紹介を入れ、文字化け状態で置いておいてもらえますか？今晩、帰宅後にチェックします。

      よろしくお願いします。
      シェア
      親コメント
      • 未調査で記事を見て、そのまま返事を書いています。常識だったらごめんなさい。
        > 念のためにUTF-8 → ASCII → EUC-JP → Shift_JIS → 7bit JISの順番で文字コードを推測
        この部分なんですが、所謂デファクトスタンダードな処理手順なんですか？
        # オライリーの CJK 本が見たい瞬間…

        直感的には 日→英→日→日→日、と推測しているようで、なんだか不安になってきます。
        どんな方法がより良いのかは判りませんが、私は UTF-8 → ISO 2022-JP(7bit JIS?) → EUC-JP → Shift_JIS → ASCII、という推測順序の方が良さゲに思います。
        # 私見ですが、UTF-8, ISO 2022-JP は今後も活用されるコード、EUC-JP, Shift_JIS は現状のスタンダードだが衰退する（させるべき）、最後の砦が ASCII、という感じ。

        なお、余談ですが、UTF-8 に導入によって所謂 CJK 統一コードとなったわけですが、C な国のコードや K の国のコードを恒常的に使用するユーザが現れた場合の挙動、というのはある程度確認なさっているのでしょうか？

        最初に公開βが告知された時、（今は消えている）テスト用の記事へのコメントに CJK コードのテストコメントと思われるものが散見されましたが、タレコみや日記、記事本文や、本スレッドの趣旨である署名や自己紹介欄などへの適用がイマイチ心配です。
        # そういえば、Perl に tait モードというのがあることを思い出しましたが、活用なさってますよね？

        --
        mobile ID portable_NoGood [slashdot.jp] 併用中
        シェア
        親コメント
        • 言語で判断しているのではなく、言語は基本的に日本語だと仮定して、文字コードがPOSTされうる頻度と判別のし易さ順に並べています。

          ページの文字コードはUTF-8なので、普通のブラウザだとPOSTされるデータもUTF-8で送られてきます。また、UTF-8なバイト列はとても特徴的なので判別がかなり確実にできますので、一番目です。

          ASCIIはhigh-bitがひとつも立っていないバイト列なので、確実に判別できます。UTF-8だが日本語などが一文字も含まれてない場合はASCIIと等価です。頻度が比較的高く、誤判定もまずないので、二番目です。

          EUC-JPとShift_JISは自動判別が必ずうまくいくわけではありません。現在の環境がEUC-JPなため、判別できない場合はEUC-JP優先にしました。

          7bit JISは完全にトチ狂ったブラウザのためのオマケです。

          NoGoodさんは文字集合と文字コードを少し混同してませんか？UTF-8はCJKだけでなくいろいろな言語の文字を含む文字集合であるUnicodeのエンコーディングです。ASCIIは(基本的には)Alpha-Numericな文字のみ、EUC-JPとShift_JISは細かい違いはあれど基本的にはおなじ日本語の文字をカバーする同じ文字集合の異なるエンコーディングです。

          新システムでは文字集合としてUnicodeを採用しています。そして、そのUnicodeのすべてを表現する文字コードとしてUTF-8を使っています。上に上げられている他の文字コードはいずれもUTF-8より表現できる文字が少ないです。文字コードの推測にはUTF-8とASCII以外は日本語用の文字コードしか推測対象に入ってないので、中国語や韓国語用の文字コード（例えばBig5やEUC-KR)で何かがPOSTされてくると、誤判定(例えばEUC-KRとEUC-JPは判定不可な気がします)されるか、変換不可で弾かれます。同じハングル文字でもUTF-8だと意図通りに受付けられます。

          UTF-8で表現できる範囲内では特に使える文字種は制限していないので、現地のローカルな文字コードではなくUTF-8でPOSTすれば、コメントや日記、記事本文や自己紹介、署名など、あらゆるものを韓国語や中国語だけでなく、右から左にかかれるアラビア語、更には古代ルーン文字などで書く事が技術的には可能です。将来、なんらかの理由によりどうしても避けられない限り、日本語の文字のみの文字集合に制限する、という事は考えていません。
          シェア
          親コメント

  • Firefox (スコア:1)

    by cwind (23872) on 2005年07月01日 11時02分 (#760854)
    > firefoxで本来不要な横スクロールバーが出る (test上のコメント)
    これ、解決済みになってますけど、うちの環境だとまだ出てます。
    …うちだけ!?

    ♯いや、あまり気にしてないんですけど(^^;
    --
    cWind - 情報は自ら求める者の元に集う

    • Re:Firefox (スコア:1)

      by targz (14071) on 2005年07月01日 16時31分 (#761108) 日記
      ＞これ、解決済みになってますけど、うちの環境だとまだ出てます。

      環境は何でしょう? Windows 版 / Mac 版 FireFox 1.0.4 両方とも出ませんでした。
      まだキャッシュに古い HTML が残っている可能性もあるので、キャッシュクリアしてみるとどうでしょう?

      ひょっとすると実は本番環境を見てしまっていたとか、そういうオチだったりしませんか?
      シェア
      親コメント

      • Re:Firefox (スコア:1)

        by cwind (23872) on 2005年07月03日 2時12分 (#761811)
        あ、ちゃんと解決していました(汗。

        ＞ひょっとすると実は本番環境を見てしまっていたとか、そういうオチだったりしませんか?

        もはや覚えていないですが、そういうオチかも…。
        ご迷惑おかけしました。
        --
        cWind - 情報は自ら求める者の元に集う
        シェア
        親コメント

  • もう終了？FoF名称 (スコア:1)

    by loli (26882) on 2005年07月02日 14時04分 (#761584)
    とりあえずFriend等の適当な名称にして、その説明を個々でカスタマイズできれば良いかなぁ.だってまとまんないんでしょ？
    ＃Foes;(´д｀;)　　＞ベタ
    私は４つのうちFreaksの意味を間違ってました。（辞書で調べると、どっちかつうと熱狂的ﾌｧｿ＝ｽﾄｰｶｰ=好いてくれる人って感じだったけど）
    頭いい人ばかりではないので、英語だと意味がわかりませんっ!!
    ←頭悪い人
    あっだから日本語の説明が必要なのか・・
    みんなは理解できてるのかもですが、もしそうでないなら
    ＃(´д｀;);(○○（ユーザ名）を嫌ってる人)
    といった具合に（名称は自由で）説明文だけ決めていただけたら考えないですむんでは？
    青○とか緑○とかのちっこいアイコンも、何だか微妙でどっちなのか（好きか嫌いか）わかりづらい。
    「好き」はハートとか（乙女？）そうじゃなくても嫌いのほうを×マークとかに変えたらわかりやすいかもです.

    • Re:もう終了？FoF名称 (スコア:1)

      by targz (14071) on 2005年07月03日 0時06分 (#761756) 日記
      ここで議論するより、ストーリーの関連コメント [srad.jp]以降で議論した方がいいように思います。

      ＞その説明を個々でカスタマイズできれば良いかなぁ.

      これはわたしは反対です。各人が friend/foe の意味がめいめいに変えてしまうと fan/freak が意味をなさなくなってしまうからです。fan/freak が見えなければ (==自分の friend/foe リストが他人に見えなければ)、friend/foe をどう使おうが個人の自由だとは思いますが。

      # 極論すれば、ある人が friend を「嫌な奴」という意味にしてしまうと、困ったとになります。理由は考えてみてください。

      ＞私は４つのうちFreaksの意味を間違ってました。（辞書で調べると、どっちかつうと熱狂的ﾌｧｿ＝ｽﾄｰｶｰ=好いてくれる人って感じだったけど）

      freak は原語自体がちょっと無理があるような気がします。4つとも f で始まる言葉ばかりを使うという言葉遊びをするために freak という言葉を探してきたはずです。なかなかよく考えてありますが、直感的ではないように思います。

      ＞頭いい人ばかりではないので、英語だと意味がわかりませんっ!!
      ＞←頭悪い人

      以前にも、どういう日本語を当てたらいいかのストーリーがあったのですが、そのときは、どういう使い方をすればいいか分かんなかったので、いい案が出ませんでした (ストーリーは探してみてください)。

      とはいえ、今回も、「言葉が分かんないから使い方が分かんない」「使い方が分かんないから訳語が決まらない」というループに陥りそうで、難儀ではあります。
      シェア
      親コメント

      • Re:もう終了？FoF名称 (スコア:1)

        by loli (26882) on 2005年07月05日 13時56分 (#762869)
        ふむー、そうですな。
        どうでもいいけどここの「ストーリー」はすーぐ古くなりますな。

        ＞これはわたしは反対です。各人が friend/foe の意味がめいめいに変えてしまうと fan/freak が意味をなさなくなってしまうからです。

        確かに。

        ＞4つとも f で始まる言葉ばかりを使うという言葉遊びをするために freak という言葉を探してきたはずです

        それでこんな強引な命名？なのですね・・。
        ジャパンなんだからいっそ日本語を当てちゃえば？とも思ったり。
        F・・F・・Fujii（思い浮かばず
        シェア
        親コメント

  • ユーザ名に font color="#FFFFFF"が (スコア:0)

    by Anonymous Coward on 2005年06月28日 19時43分 (#759533)
    ログインした状態で、他のユーザの【関係】（例えば、Anonymous Coward (1) との関係 [srad.jp]を表示すると、ユーザ名のところに font color="#FFFFFF"のタグがついていて見えなくなっています。
typodupeerror

コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell