トップ 新規 編集 差分 一覧 ソース 検索 ヘルプ PDF RSS ログイン

相談所

お名前
件名
本文

ライセンスについて - aike (2010年07月18日 20時12分15秒)

漢字検索のデータ等のライセンスの明示をよろしくお願いします。

計算:8×7= お名前: コメント:

画像の削除依頼 - Mammalia (2009年04月23日 07時06分32秒)

私が間違って、「動物と植物2」「動物と植物3」というタイトルのJPG画像をUPしてしまい、削除の仕方が分からないので、どなたか削除の仕方を私に教えてください。よろしくお願いします。

  • Wikiページ作成ガイドライン」に記載の要領でログインした後、ページの編集画面を開くと、下の方の添付ファイルの一覧に「削除」というリンクが現れますので、それをクリックすれば削除できます。お試しください。なお、添付ファイルの削除方法をガイドラインページに記しておきました。 - やの (2009年04月25日 09時49分13秒)
計算:6×4= お名前: コメント:

新スパム対策 - やの (2007年10月27日 00時17分38秒)

スパムが激化してきたので、スパムフィルタを導入しました。操作上はこれまでと変わりありませんが、スパムらしいと判定された編集はエラーメッセージとともに却下されます。もし問題があるようでしたらご相談ください。

  • 和田研細丸ゴシック」の編集がスパム判定されていたのを発見したので、救出のうえ、再学習させておきました。 - やの (2008年01月05日 12時56分19秒)
  • Emacs」の編集がスパム判定されていたのを発見したので、救出・再学習させておきました。 - やの (2008年05月24日 19時21分40秒)
  • 和田研細丸ゴシック」の編集がスパム判定されていたのを救出・再学習させておきました。 - やの (2008年06月08日 12時40分26秒)
  • Emacs」の編集がスパム判定されていたのを救出・再学習させておきました。スパムばかり学習させたせいか判定が厳しいようでご迷惑をおかけしていますがよろしくお願いします。 - やの (2008年07月12日 23時04分44秒)
  • 遅くなりましたが、ApsalyMule-UCSの編集がスパム判定されていたのを救出しました。度々すみません。 - やの (2009年03月15日 12時54分50秒)
計算:3×8= お名前: コメント:

包摂規準に関する質問 - 金内 (2007年05月11日 01時20分06秒)

冊(册)の異体字で包摂規準連番94(適用除外規定なし)の三つ目の字は冊に包摂されるのでしょうか?

曾(曽)の異体字で包摂規準連番101(適用除外規定に曾曽の両区点が挙げられる)の三つ目の字は曾に包摂されるのでしょうか?

JIS漢字字典ではそれぞれ冊曾の字形例として挙げられています。

  • 包摂されるか否か、という問いに対しては、される、というのが答えではないかと思います。ただ、おそらく疑問は、冊と册のどちらの区点位置に包摂されるかということではないかと察します。思うに、「2点画の結合・分離」のセクションに冊の左右の突き出ない形を載せているのは妙で、「2点画の交差・延長」のセクションにあるべきではという気がします。 - やの (2007年05月13日 22時42分49秒)
  • 朗の旧字は 1-85-46 で表せるのでしょうか? ここで朗の旧字とは朗と比べて偏の形が異なるだけでなく、旁の月も旧字の月になっているものです。これは包摂規準連番36に関わる違いですが、1-85-46 に対しては 6.6.3.1.c で包摂規準を適用しないことになっています。 - 金内 (2007年05月21日 20時46分24秒)
計算:9×2= お名前: コメント:

画面サンプル等掲示のお願い - やの (2006年11月12日 08時01分49秒)

ソフトウェアの情報を記したページには、できれば画面サンプルをつけていただけると良いかと思います。実際のイメージがつかみやすいし、見て楽しいと思いますので。素敵な画像をお待ちしています! (画像の添付の仕方はWikiページ作成ガイドラインに記してあります)

また、プログラミング言語などは、同様の理由でサンプルコードがあるとベターです。コマンドラインから実行するツールの場合は、コマンド実行例があると分かりやすいでしょう。

計算:5×3= お名前: コメント:

スパム対策にご注意 - やの (2006年09月04日 23時03分10秒)

このような辺境のサイトにもスパマーの魔の手が及んできたので、簡単なスパム対策をとっています。特定の文字列を含む場合にページが保存できないよう設定しています。

このため、もし普通にページを編集したのに保存がされないことがあったとしたら、偶然スパムよけに引っかかっている可能性があります (滅多にないと思いますが)。

不都合のある場合や不審な場合は、どうぞこちらの掲示板でご相談下さい。

  • 追加のスパム対策として、コメントする際に九九の答えを要求するようにしました。どの程度効果があるか見てみたいと思います。 - やの (2007年04月28日 16時12分56秒)
計算:7×1= お名前: コメント:

Re: ISO-2022-JP-2004 vs Unicode mapping table - えむけい (2006年06月06日 06時01分35秒)

ISO-2022-JP-2004の対応表ですが、ISO/IEC 646 IRVと重複する文字も漢字7ビット符号の対応表と同様に割り当てるのではないですか?

重複符号化になりますが、ISO-2022-JP-2004に関しては(EUC-JIS-2004Shift_JIS-2004と異なり)使用禁止も「慣用的な利用との互換」もJIS X 0213の附属書に規定されていません。

つまりFULLWIDTHに割り当てる根拠がありません(参考として「Fullwidth:」を付けるのはかまわないと思いますが)。

  • おや。どうもそのように読めますね。JIS X 0208の附属書2 (RFC1468符号化表現) も同様のように見えます。これはどう解釈すれば良いのでしょう。規格の誤り? - やの (2006年06月07日 23時42分45秒)
  • 私は誤りではなく、ISO-2022-JP的に文字集合を切り替えて使う場合に重複符号化が発生する可能性があるのは仕様なのだと解釈しています。実際、たとえば1b 24 42と1b 24 28 51ではほとんどの文字が重複していますが、それを理由にどちらかの使用を禁止されたりはしていません(1b 24 42の一部の文字は使用禁止ですが、重複符号化を理由としているわけではありません)。SuikaWikiの図形文字の一意な符号化が参考になると思います。 - えむけい (2006年06月08日 12時47分09秒)
  • うーん、するとUnicodeに変換したときに「全角・半角」の区別が保存されなくなりますよね。それに、ISO-2022-JP{-3|-2004}で「全角英数」を"FULLWIDTH"の方に変換している実装は全部間違いということになってしまいますけど、それで良いのでしょうか? - やの (2006年06月08日 22時44分50秒)
  • そもそもJIS X 0213の英数字は「全角」ではないので、区別が保存されないのはそういうものでは? というしか。EUC-JIS-2004Shift_JIS-2004ですら同じJIS X 0213の文字が「半角」になったり「全角」になったりしてますし。規格を字義どおりに解釈するなら、ISO-2022-JP{-3|-2004}でFULLWIDTHに割り当てる実装は「全部間違い」としかいいようがないです。XML MOJI 00655は私のお気に入りの言葉です。川俣氏がWindowsの変換表の誤りに関してダブルスタンダードなのは残念というほかありませんが。 - えむけい (2006年06月09日 09時03分54秒)
  • JIS X 0213:2000の本体の9.符号拡張法、9.2には、「JIS X 0201又はISO/IEC646と漢字集合とを同時に指示する場合、これまでの慣用的な利用との互換を目的としてだけ、附属書5表2に規定される文字をJIS X 0201又はISO/IEC 646とで規定される文字とは異なった図形文字として用いてもよい。」とあります。しかし附属書2から本体9.を参照できるのかどうかは、よく分かりません。 - さだひろ (2006年06月10日 10時09分43秒)
  • もう少し考えてみましたが、本体9.2も附属書2も漢字集合として本体6.5.1で規定するものを用いる点では共通しています。すると、附属書2が、本体9.2における「JIS X 0202の符号拡張法を主とする環境で」に該当するのかどうかなのでしょうが、どうなのでしょう... - さだひろ (2006年06月10日 10時28分00秒)
  • 上で「全角・半角」という言葉を使ったのは便宜のためです。本質的には、同じ文字に異なる符号化表現を重複して割り当てている場合に、コード変換で重複が失われないようにするようUnicodeでは配慮されており、それがfullwidth/halfwidth formの意義である筈です(「互換漢字」の存在もその目的)。とすれば、ISO-2022-JPでfullwidth formを使わない理由は存在しないはずだと言うのが私の意見です。規格は字義通り解釈しなければならないと言うのは当然のことですが、規格の誤りを発見し改められるようにすることも大事なことだと思います。 - やの (2006年06月14日 23時21分36秒)
  • えっと、JIS X 0213:2000において、EUC-JISX0213が附属書5を参照しているのに、ISO-2022-JP-3が附属書5を参照していなかった理由ですけど、これ、ISO/IEC 2022を厳密に解釈したら、こうなったというだけのことです。EUC-JISX0213の場合は、G0とG1に「同じ名前」の文字(たとえばLATIN CAPITAL LETTER A)が収録されてるので、そのままだとG1の1-3-33とかが使えなくなっちゃいますよね。で、それが困る人は代替名称にするわけです。でも、ISO-2022-JP-3はG0を変えながら使うので、「同じ名前」の文字が同時にG0には現れない。ですので、ISO/IEC 646 IRVの4/1もJIS X 0213の1-3-33もどちらも使えるので、ISO/IEC 2022上はあえて代替名称を使う理由がないわけです。じゃあ、ISO-2022-JP-3では代替名称を使っちゃいけないか、っていうと、それはもちろん「慣用的な利用との互換」のためには使ってもかまわないわけで、それがわざわざ附属書5を独立させている理由でもあるわけです。 - 安岡孝一 (2006年06月25日 22時07分36秒)
  • あ、そうか、やのさんは、JIS X 0213での「名前」を、JIS X 0221-1の「名前」と同一視してらっしゃるんですね。それ、厳密には違いますよ。JIS X 0213での「名前」は、JIS X 0202の5.3でいう「名前」でもあるんです。その意味で、JIS X 0213:2000附属書5には、あえてUCSを示さなかったんです。ただ、1-1-17の代替名称をドタンバで「FULLWIDTH OVERLINE」にできなかった(理由はJIS X 0221-1:2001附属書P参照)のは、いまだもってクヤシかったりしますけど。 - 安岡孝一 (2006年06月26日 00時10分27秒)
  • なるほど、附属書5は独立しているから附属書2から参照しても構わないと。考えてみれば附属書4や6も参照するわけだから、附属書5だけ参照してはいけない理由はないですよね。言われてみれば単純なことでした。 - やの (2006年06月29日 22時17分41秒)
計算:3×8= お名前: コメント:

可能な限り作者とライセンスの表示を - 泊何水 (2006年03月02日 13時00分24秒)

各種ソフトウェアの作者の名前とライセンスを可能な限り明記した方が良いと思います。中には単独販売禁止とか制限があるものもありますから。

  • もちろん作者に敬意を示すためにも。 - 泊何水 (2006年03月02日 13時03分17秒)
  • リンク先を参照すれば分かることではありますが、簡単に記しておいた方が便利かもしれませんね。 - やの (2006年03月02日 22時27分13秒)
計算:2×5= お名前: コメント:

相談所設置 - やの (2006年03月02日 07時56分24秒)

Wikiの編集に関する相談所を設置してみました。こんな場合どうしよう、こうしたいのだが良い方法があるか、等々お気軽にどうぞ。

計算:5×5= お名前: コメント:

[ 1 ]

最終更新時間:2006年03月02日 07時54分52秒