ノート:文字コード

ページのコンテンツが他言語でサポートされていません。

一覧の整理について[編集]

どなたか「2 文字集合/符号化方式」の再整理をお願いしたいです。まず、見出しの「漢字」なのに中華系のコードはともかく韓国系のコードが漢字とは違和感があります。アラビア文字はどこに入れるのでしょう?ISO/EUCなど大分類を入れるなら、JISも大分類をつけるべきかと思ったり。[1]にあるようなKS系のコードはどこに入れたものか、とか。MS-DOSやWindows3.1の日本語版でハングルを使いたかった一部の人が使っていたShift-KS(KWとも)なんてコードもどこに入れたらいいかわからない(多分、標準化団体はどこも定義していなかったかと。EUC-KRをEUC-JPtoShift-JISとほぼ同様にマッピングしたMS-DOS/Windows3.1フォントを使うことで日本語MS-DOS/Windows上でハングルを使っていた、高電社の製品などではKWと呼んで発売され、同社の現在のWin9x,XP等への対応製品にも使われている、といってもまたKWはKWでバージョン等によって細部に差異があったような気がするがうーんっと・・・)。 Kozawa 01:07 2004年3月25日 (UTC)

とりあえず、応急処置しておきました。oxhop 10:20 2004年3月27日 (UTC)

自己著書を理由とした文献削除について[編集]

『文字コードの世界』『インターネット時代の文字コード』『文字符号の歴史 欧米と日本編』が参考文献から削除されましたので、「ベンダごとの文字コード」と「印刷業界の文字集合」の多くがWikipedia:検証可能性を失いました。削除なさった方は、これらに対する検証可能性を確保するような、別のソースを追加するようお願いします。-- 安岡孝一 2006年7月14日 (金) 12:59


「自己著書だから消す」という方針は明らかに間違っています。別に偽名を騙ることだって出来るんですから。安岡さんの書籍は市販のものでは「CJKV」に次ぐ、非常に重要な参考書です。消す理由がまったく無いです。-- HIssakun 2006年7月14日 (金) 17:43

Wikipediaですから、自分の書いたものが他人に削除されてしまうのは、そもそも仕方ないんですよ。でも、Wikipedia:検証可能性を確保するために付加しておいた参考文献を、代替の文献もなしに削除されてしまった場合、当該文章のWikipedia:検証可能性はどうやって確保したらいいんでしょ? -- 安岡孝一 2006年7月14日 (金) 21:22 (JST)
検証の見地において安岡さんの著作が有用であることについて、僕はまったく異論がありません。僕は、安岡さんの著作物へのリンクを復活させたいと思っているのですが、よろしいでしょうか?利用者:24.126.230.222さんがこの議論に参加してくるとは思いがたいからです。彼はASCIIの項目に張った外部リンクを批判されたことを逆恨みしているとしか思えません。あまり彼に期待しないほうがいいと思います。 -- Hissakun 2006年7月15日 (土) 03:25 (JST)
テレックスでも同様のことが起こったので、とりあえず文字コードと共にrevertしました。¥記号は、…どうしましょう、まあ、英語の文献を読む気がある人には『文字符号の歴史 欧米と日本編』がなくても検証可能ですから、revertしなくてもいいかな…。-- 安岡孝一 2006年7月15日 (土) 9:42 (JST)

記述の整理[編集]

複数の項目にわたりますが、ここだけノートがあるようなのでここに報告しておきます。

ここ数日で、つぎの変更を行いました:

  1. 文字符号化方式に (MIMEの意味での) 「キャラクタセット」 (および JIS の意味での「符号化表現」) の記述を追加しました。
  2. ISO-2022ISO-2022-JP文字コードで、「文字コード」や「文字符号化方式」という用語で実際の符号化表現 (キャラクタセット) を指している箇所を、「キャラクタセット」にあらためました。
  3. 文字コードの節順を変えました。具体的には、概説その他の解説部分を先に出すようにし、文字コードを列挙している節を「文字コードの一覧 (一部)」としてまとめ、後ろに移動しました。

1、2 について、「キャラクタセット」という用語を前面にだすかどうかについては議論の余地があるかもしれません。ただ、「文字符号化方式」とか「文字コード」として触れられているものの多くが、実は MIME のキャラクタセット名に使うことを想定してつけられたタグである (符号化文字集合や文字符号化方式の呼称ではない) ことから、このような整理を行いました。

あと 3 についてですが、あちこちの項目に「文字コード」(多くはキャラクタセット名) の一覧があるんですが、なんとかまとめられないもんでしょうかね。--Hatukanezumi 2007年1月14日 (日) 06:41 (UTC)[返信]

文字コードの一覧などとして分割したほうがいいかもしれませんね。各記事から参照(共有)する形にして。--fryed-peach 2007年2月22日 (木) 23:33 (UTC)[返信]

IETFの策定する規格は「国際的」「公的」ではないのか?[編集]

えーと、この間、つぎのような表現 (いずれも大意) を削除してきた者です。

  1. 「文字符号化法」という用語は国際規格を定める ISO では使っていない。
  2. 「文字符号化法」や「符号化文字集合」という用語はIETF で使っている用語だが、公的な規格を定める ISO や JIS では使っていない。

ISO は「国際標準化機構」という名称を持ちます。また、名称とは関係なく(つまり名称のせいでそうなっているというわけではなく)、多くの国・地域の標準化団体のサポートによって活動している組織ですし、実際に国際的 (国や地域の枠組を越えているという意味) な標準化の分野で、公的な影響力を持つ組織です (注: ここでは、規範性の評価に対して中立であろうとするため、あえて「規格」という言葉を避けて「標準化」という言葉を使います)

ただ、いっぽうで、IETFの枠組も、別の形で国際的な標準化で成果を挙げている標準化団体であり、公的な影響力を持っています (なお、名称は「インターネット」---「ネットワーク際」? --- を冠したものですね)。

ですので、あえて前者に「国際的」「公的」という形容をし、そのうえで、前者ではある用語を「用いない」と書くのは、記述が中立性に欠けるとおもうわけです。ある標準化団体がある用語を用いないこと自体は、事実ですから、記述することに問題はないでしょう。しかし、Wikipedia の方針に則して言えば、ある立場を強調してそれ以外を特殊なもの、本質的でないものとするような記述は、特に理由がないかぎり、避けるべきであるとおもわれます。

さらに、「文字コード」を概念的に「符号化文字集合」(CCS) と「文字符号化方式」(CES) とに分析することは、現実のさまざまな文字コードの実装状況を整理する上では、有用だと思われます。つまり、「分析してみるとこうなっている」と書いたうえで、「現実はこうなっている」と書いたほうが、読者の理解も容易な場合が多いとおもいます。

  • ちなみに、ISO/IEC 2022では、そのような記述の流れにするつもりで、現在改稿をすすめています。前半の ISO/IEC 2022 の解説そのものは「分析してみるとこうなっている」の部分であり、「ISO/IEC 2022#応用例」の節は「現実には多くの実装が、ISO/IEC 2022 に適合するかどうか疑わしい」というものになる予定です (もちろん ISO-2022-JPEUC-JP も例に挙げます)。しかし、だからといってそれらの実装が特殊であるとか、本質的でないとか受け取られるような記述にならないよう、注意したいとおもっています。

以上のことから、「符号化文字集合」や「文字符号化法」については、単に

  • IETFでは用いるが、ISO(やJIS)では用いない。

とだけ記述するべきだと考えます。 --Hatukanezumi 2007年2月2日 (金) 15:03 (UTC)[返信]

ISO/IEC 2022[編集]

ISO/IEC 2022 ですが、規格第1版のころの記述になってたので (おそらくen:ISO/IEC 2022の 06:21, 26 August 2006 の版からの翻訳)、全面加筆するとともに応用例などを加えました。内容のチェックをしていただけるとありがたいです。 --Hatukanezumi 2007年2月10日 (土) 02:04 (UTC)[返信]