もったいないので、うｐしてみる。
ただ、お蔵入りしていたあけあって毒入りです。うわはははｈ ヽ(;´Д`)ノ
−−−−−−−−−−−−−−−−−−−−−−−
前回、「firefox EUCが最低」という記事において、ちょっとタイトルが下品だったこともあり、
各方面からお叱りのお言葉を頂いた。
深く反省したい。
ところで、ネットでいくつかご意見を拾ってみると、どうもIEがJIS X 212（補助漢字）を
サポートしていないのが規格違反、Firefoxを責めるのは筋違い。という意見を持つ方が結構いらっしゃるみたい。
IEがEUC-JPのWebページの表示・送受信にCP51932というEUC-JPとは似て非なる文字コードを使っている事はたしかで、
そこに弁解の余地はないのだが、昔はみんなJIS X 212なんか使わないのがマナーだ。とか言われていたのに今はクライアントソフトの欠陥扱いなのね(n'ω'`)
時代は変わるなぁ。
さてさて、そんなこんなでモヤモヤしたものを抱えているうちに、Web検索で、MySQLのMLの過去ログ公開ページにてEUC-JPでは補助漢字はオプショナルという意見をみかけたので（おお、よく見たら、これって森山さんの投稿なのね）
ちょいと定義を調べてみました。
興味のある人は以下のリンクと前後のスレッド文章を適当にあさってみてくださいな。
つ http://www.mysql.gr.jp/mysqlml/mysql/msg/12389
まず、IANAのcharset registryのEUC-JPの定義はこちら
ソース http://www.iana.org/assignments/character-sets
Name: Extended_UNIX_Code_Packed_Format_for_Japanese
MIBenum: 18
Source: Standardized by OSF, UNIX International, and UNIX Systems
Laboratories Pacific. Uses ISO 2022 rules to select
code set 0: JIS Roman (a single 7-bit byte set)
code set 1: JIS X0208-1990 (a double 8-bit byte set)
restricted to A0-FF in both bytes
code set 2: Half Width Katakana (a single 7-bit byte set)
requiring SS2 as the character prefix
code set 3: JIS X0212-1990 (a double 7-bit byte set)
restricted to A0-FF in both bytes
requiring SS3 as the character prefix
Alias: csEUCPkdFmtJapanese
Alias: EUC-JP (preferred MIME name)
これを見ると残念ながら、RFCでも国や標準団体の決めたデジュール・スタンダードでもないので、規格番号とかがなく、「いわゆるEUC-JP」というちょっと悲しいポインタになっていることがわかる。
いちおうUIとかOSFとかいう文字はあるので、
僕が聞いたことがある説の中で一番トンデモな「EUC-JPとはJIS X 213 EUCの事である！」
という説は却下していいと思うが、それ以上は業界の暗黙の合意に頼っているのが現状である。
ところで、これ、将来MSやJIS委員会が自分のスペックの片隅にOSFとかUNIX Internationalとか
いう文字をいれたら「うちのEUCこそはEUC-JPの正式な定義である」と名乗れるんですかね。
＃ いやいや、もちろん冗談ですぞヽ(;´Д`)ノ
でも、まあ、業界内のだいたいの合意というものはあるようで、
UNIX SYSTEM V リリース 4 日本語環境共通規約 第１版
1992/7/10 初版発行
ISBN: 4-8101-8359-7
トッパン
または
UI-OSF 日本語環境実装規約
Version 1.1
1993 年5 月21 日
UI-OSF Japanese Localization Group
を典拠にあげる人が多かった。
んで、まずは「UNIX SYSTEM V リリース 4 日本語環境共通規約 第１版」のほうを
めくってみると（今持ってる人は少ないと思うが）
P11
2.1.2 日本語文字セットに関する共通規約
ここでは各プラットフォームメーカがサポートすべき文字セットについて述べます
(1) サポートを必須とする文字セット
各プラットフォームメーカは以下の文字セットのサポートを必須とします。なお、ここで「文字セットのサポート」とは：
− 日本語を扱うプログラムは以下の文字セットを日本語として正しく処理できること。
− 入出力装置が日本語を扱える場合、以下の文字セットの入力や表示、印刷が可能なこと
を示します。
・ ASCII
・ JIS X 208-1990
ただし以下の点に注意が必要です
（中略）
(2) サポートを推奨する文字セット
以下の文字セットはサポートを推奨しますが、これは必須ではありません（レベル２です）。
・ JIS X 201-1976 カタカナ
以下の文字セットは現在サポートを義務付けませんが、将来的にはサポートが必要となるでしょう。
・ JIS X 0212-1990 補助漢字
となっており、なるほど、たしかにJIS X 201カタカナとJIS X 212は必須じゃないね。
次はUI-OSF 日本語環境実装規約を見てみる。こっちはWebでPDFが公開されている。
教えてくださった沼田先生に感謝。
附属書D (参考) 応用プログラム開発者向けのガイド
D.1.1 共通日本語文字集合日本語文字集合としては，次に示す文字集合が共通に使用できます。
(1) ISO 646 IRV (ASCII) 又はJIS X 0201 ローマ字用7 単位符号
(2) JIS X 0208 情報交換用漢字符号
D.1.2 多くの実装で使用できる日本語文字集合
次に示す文字集合は，この実装規約が提供を推奨しているものです。ただし，提供を義務付けられてはいませんので，この文字集合が使えない実装もあります。特に，シフトJIS を使用する場合，C1 制御文字及びJIS X 0212 情報交換用漢字符号{補助漢字は使用できません。
(1) JIS X 0201 片仮名用図形キャラクタ
(2) ISO 6429 が規定するC1 制御文字
(3) JIS X 0212 情報交換用漢字符号{補助漢字
となっており、やはりJIS X 201 や JIS X 212は必須じゃないとされている。
ただし、前述のトッパン本とはややニュアンスが異なるようである。
ただ、この規格書、どうもよく分からないのが、付属C,D全体
（ようするにこの辺で引用しているあたりの章全体）が「参考」情報とされており、
規格本体からはずされてしまっている。
規格と関係ないところで、実装が必須かどうかを定義するってそれ一体何の意味があるのよ？！
と疑問に思わなくも無いが、
出典[UI-OSF-USLP 共同技術資料:日本語EUC の定義と解説(1991 年12 月12 日)]
という一文があったので、もしかしたら、出典は別にあってこっちはタダの引用だよん。
という意思表示のつもりだったのかもしれない。
ただ、この[UI-OSF-USLP 共同技術資料:日本語EUC の定義と解説(1991 年12 月12 日)]という
規格書はいまや完全に入手不可能なので、何が書いてあったのか全然分からない。
まとめると
・EUC-JPの明確な定義はある
・しかし、それはRFCやISOの規格にはなっていない
・JIS X 201(半角カタカナ）と JIS X 212(補助漢字）は必須ではないと書いてある
・しかしながら、書いてある本から察するにどう考えても適用範囲はいわゆるUNIXに限られそう
・んじゃ、UI-OSFに入っていないOSはどう解釈すべきかというと・・・・
世間にまったく合意がないように思える
・たぶん、MSは自分は適用範囲外だから、ルールを逸脱して好き勝手やっても問題ない。
と思って、今のあやしげなIE上のEUC-JPの実装になっていると思われ
・でも、Web上での世間の声を聞いていると、逆に、EUC-JPの文字セット定義は
IANAのcharset registry定義で「定義」されていて、「必須じゃない」という文章が
適用範囲外なので、WindowsはUnixと異なり補助漢字実装必須なんだ。
IEが補助漢字実装しないの許せーーんヽ(;´Д`)ノ
とでも、思っているとしか思えない、IEの補助漢字未実装を責める声多数
うーむ、一体何がここまで混乱を招いた原因なんですかね？
なんとなく、EUC-JPの典拠規格が手に入りにく杉。というのが根本的に問題な気がするけど・・・
あと、つくづく思ったのは昔とは補助漢字の位置づけが変わったな。ということ。
昔は、んなもん使えるマシンの方が少なかったのでネットワーク上でんなもん使うやつがおバカという共通認識があったと思うのですよ。
それがUnicodeの普及によってJIS X 212が使えるマシンのほうが多数派になっちゃったから、規定がいいかげんなEUC-JPは色々運用に不都合が出てきている気がする。
やはり、いっそのことEUCは捨てて、みんなでUTF-8に移行するしかないんかね？
＃携帯サイト問題（携帯電話はUnicodeをサポート事が多い）は残るけど
・・・時代は変わった！
どっちなのさ？！ ランキング！
とお叱りを頂いてしまいました。
えっと、誤解です。
multipart/form-dataを使っても状況はまったく変わらないことが分かったので説明を省略しただけです。
誤解をとくために前回の調査結果を簡単にまとめさせてください。
・Webの世界でEUCといったらCP51932がデファクトスタンダードである
・これは本来のEUCから補助漢字をなくして、かわりにWindows機種依存文字を
追加したものである。
・しかし、FirefoxだけはCP51932+補助漢字という独自拡張EUCを採用している。
・これはURL Encoding の％エスケープを解いたあとのデータが補助漢字に
ついて生EUCとするか、数値文字参照とするか、という違いとして現れてくる。
・結果、IEで送信した文字列は内容によらず、IEでもFirefoxでも見れる。
でも、Firefoxで送信した文字列は補助漢字が含まれていると、
Firefoxでしか見れない。
という結論が得られた。
つまり、％エスケープをほどいた後の話なので％エスケープをしない multipart/form-data でも状況はまったく変わらないのです。
さて、この件、世間様の反応をちょいと調べてみるとBlog界では結構大きな問題になっていることが分かる。
たとえば、はてなアイデアで「文字化け」で登録されているバグのうち、すくなくとも
・Unicodeのページから文字を取得する各サービス(ダイアリ(含むasinページ)、
アンテナ)で、EUC-JPに変換できない文字および3バイトEUCになる文字は
数値文字参照にしてほしい
・コメント欄でフランス語などが文字化けしないようにしてほしい。
・機種依存文字の自動置換もしくは警告。特に○付き数字は利用例が多いが
Macでは(日)(月)(火)もしくは！”＃などと見え、意味が伝わり難い。
人力検索は公共性が高いので配慮を。
・ユーザから投稿された投稿内容のうち、0x8f で始まる
JIS補助漢字を(非漢字のものだけでも)数値文字参照に変換する。
IE での文字化け防止のため。 http://d.hatena.ne.jp/fenestrae/20050519#c
以上のトラブルは、このFirefoxのUglyな仕様に起因している。
じゃあ、もじらな人々がどういった反応をしているかというと
Bugzilla-jp: bug4873 EUC-JPエンコーダは補助漢字を変換すべきではない において
この問題、私はmixiで知ったんですけど、mixiは&を&に変換しないので、数値文字参
照が送信されても数値文字参照として表示されず、文字として置換表示されますので、こ
のようないい加減なWebアプリでは、ある意味問題無いというか、だからこそ問題が出た
というか。
で、もし数値文字参照として送信した場合なんですが、多くのWebアプリケーションが
やっているように、&を&に置き換えていた場合、結局ただのregressionにしかならな
いと思うんですよ。
とmixiが悪いという見解。
私、ぜんぜん知らなかったんですけれども多くのWebアプリケーションは&を
& に置換しているはず。という主張。
ソースが示されていないので、じゃあなぜ数値文字参照を送っているIEは困っていないのかが
分かりませんでした。
（IEを無視しているWebアプリケーションってあるのかしらん）
ただ、Linuxのユーザグループなんかでは、EUC-JPの使用率高そうな気がしますが、そう
いったところでFedora以外のLinuxが標準で使っているEUC-JPの文字のうちの一部が生で
使えなくなる、ということの方が問題な感じがします。
その後、この発言が WONT-FIX への流れを決めてしまったように見えるが、この発言で数値文字参照を出力することにより困難が生じるコミュニティやソフトウェアの名前は一切明らかになっていないように思える。
ハングルとかが数値文字参照で送られてくるのは処理できるのに、補助漢字が数値文字参照で送られてくると発狂するソフトウェアって逆に難しいと思う・・・・
さらに調査を続けると、Mozillaで数値文字参照で送出する仕様が実装されたのは比較的最近であることが分かった。
すくなくとも、MozillaのEUCの実装よりかはだいぶ後。
Bugzilla bug-117422 トルコ語が文字化けするぞ。というバグ
が 2001-12-30 04:12 PDT にOpenされ、そこで、
コメント１９ において
For example, if user put in "abc" + Two chinese characters + "eft" , the unicode
converter will convert "abc" . in 6.2.1, it will convert to "abc" + two question
mark + "eft" since we set the error behavior to repalce fallback to '?' but
someone remove that code (in the current GetEncoder, youc can see that part of
code got commented out ). this is very bad because user could type "Software "
+ Japanese names + " hardware car" when they search google. if we convert to
"software ??? hardware car" then at least the search engine can match "software"
"hardware" and "car", but the current behavior will only send out "software"
the "?" approach is not idea but acceptable. However, when I look at IE6, it
seems they use NCR to encode these "cannot be converted" character, this is not
specified in any standard but nor any standard currently address this issue. I
think it is better to fix this to the IE6-non-standard way, instead of to fix it
to the old Netscape-non-standard way. And since there are currently no standard
which address it, we don't need to worry about standard issue here.
この問題は標準がなく、IEもNetscapeも独自拡張だが、IEの方法のほうがスジがいいので
そちらに挙動を変えよう。
という発言が通って 2002-03-01 12:46 PDT に check-in および verifyが完了している。
本当はこの時にEUC-JPも直せばGoodだったんだけど、まあトルコ語問題で始まったバグをいちいちウォッチしてられないというのも想像に難くないので、ある意味仕方ないのかな。
さて、時は進んで2006年今現在、いまさらEUC-JPのエンコーディング方法を変えるのはどうなのだろう、という議論は識者と一度してみたい。
僕は変えたほうがいいと思っているのだけれど。
僕の知っている範囲で列挙すると論点は以下
・現在のWeb環境でサーバ側のソフトはほぼ漏れなくUnicodeで動作している
（Javaとかperlとか）
・現在のFirefoxの送出するEUCは独自拡張EUCなのでサーバー側で
Unicodeに変換するときに "EUC-JP"→"Unicode" 変換をおこなっても、
"CP51932" → "Unicode" 変換をおこなっても文字化けする
・"CP51932" → "Unicode" コンバータをFirefox独自拡張にも
対応してもらうのは極めて困難が予想される。
CP51932は独自拡張とはいえ、Microsoftが仕様をMSDNや書籍で提示して
将来も変更しない事を明言しているので
海外のメンテナにもURLあそこの仕様を実装したよん。で通じるけれども、
Firefoxのはドキュメントなし独自拡張。
かつIEと違ってデファクトの地位も握っていない。
・もし、サーバー側で個別対処するのであれば
（この時点でサーバ屋さんから猛反発来そうだ）、
Unicodeに変換する前に "補助漢字" → "数値文字参照" 変換を
しなければならないが、
現在の多くのスクリプト言語でそれは不可能である。
かってに、Unicode変換されてしまうケースが多いから。
・通信相手がFirefoxに限られIEの事を考えなくてもよいクローズドな環境で、
かつ補助漢字が3byteで送出されてくると
期待するソフトがあった場合にFirefoxを数値文字参照を送るように変更すると
レベルダウン修正になるがはたしてそんな環境・ソフトは実在するか
・（僕が詳しくないので誰か教えて）Mac では数値文字参照と生EUC補助漢字の
どちらが幸せなのか。
この件に関しては、はてなの中の人とかもじらの中の人とかレガシーエンコーディングプロジェクトの識者の面々とかと今後議論していきたい。あんまりツテがないので大変だけど ;-<
で、ここで終わるとユーザにとって前向きな記事にならないので、もうちょっと対処療法織り交ぜ柔軟に考えてみる。
たぶん、ユーザが幸せになるには以下の方法のどれかを実行すれば言いと思う（排他条件じゃないので注意）
１．GreacemonkeyスクリプトをつくってサーバーにPOSTする前に
数値文字参照に変換
ユーザがわざわざインストールしないといけないのが欠点だが、
たとえばフランス語が文字化けして
死ぬほど困ってる人だったら入れてくれるかも。
（Greacemonkeyって何？ってひとはこちらをどぞ
http://firefox.geckodev.org/index.php?Greasemonkey）
２．JavaScript libraryでサーバーにPOSTする前に数値文字参照に変換
１と似ているけれども、普通のJavascriptライブラリとして提供。
Blogの管理者がこのScriptを設置してくれれば
文字化けがなおるというもの。
１と違い、エンドユーザは明示的にインストールする必要がないのが長所。
はてなのようなユーザーが自分のScriptを置けないようなブログでは使えないのが欠点。
３．補助漢字to数値文字参照 perl library を提供
まあ、Blogのバックエンドはperlが多いだろうと勝手に決めうって
補助漢字を数値文字参照に変換するライブラリを
つくってブログ屋さんに組み込んでよーと宣伝していくというい方法。
ある意味正攻法。うまくいったらクライアント側で何も
対処がいらないって意味で。
でも汚い。激しく汚い。
しかもこういう日本語決めうち特殊処理はi18nなソフトでは
決して受け入れられない。
４．CP51932コンバータをFirefox独自拡張に対応
もう、CP51932を文字通りの意味じゃなくWebで流通してる
EUCという広い意味でとらえてFirefox拡張も
受け入れてしまうという案。
残念なことにFirefox EUCは仕様が公開されていない
（実装が仕様）状態なので、このコンバータが
コミュニティに受け入れられる可能性はきわめて低い。
５．Firefoxを直す
本文でも書いたけど、補助漢字を３バイトEUCで送ってくれないと
破綻するソフトって実在するの？
ってのが争点かと。
実在したらレベルダウン修正になってしまいますからね。
４以外は僕でも出来そうな気がするので（５はパッチが受け入れるか極めて怪しいけど）、意見がある人は○○キボンヌ とかだけでもコメント残して言ってくれるとうれしい。
追記：
５を望む人はここじゃなく、Bugzillaで意思表明をしてもらったほうがいいかな。ここで意思表明してもチラシの裏なので
初稿では僕の書き方が悪かったです。ごめん
では！
「セーブ・ザ・オウガィ」プロジェクトに改名されました
・・・だって、http://blog.livedoor.jp/dankogai/archives/50480727.htmlのトラックバッグが文字化けしてるんだもの(n'ω'`)
オーガも感動！ ランキング！
で、最近ヒトサマのBlogを見ているとBlog界もやっぱりまだまだ文字化けにあふれているようだ。
例えば、浅倉様のはてなもそろそろEncode::EUCJPMSを使ってくれないかなあ 、
および404 Blog Not Found様のあなたは何の役に立つのか?というエントリのhyoshikさんの ①（まるいち）という文字というエントリからのトラックバックをみるとはてなの吐き出すRSSやPingは「〜」「①」は化けるらしい
と、いうわけで、いささか興味がわいたのでちょっと色々調べてみた。
文字化けの原因として、
・ブラウザ側の問題
・サーバー側の問題
・その複合原因
とあるが、今回はブラウザの挙動のみを対象にした。
調査対象のブラウザは以下を選んだ
IE: 6.0.2900.2180.xpsp_sp2_gdr.050301-1519
Firefox: 1.5.0.3
Opera: 8.53(Build 7722)
ちなみに当サイトに訪れるユーザのブラウザの割合は以下のような感じで、
順位 ブラウザ名 パーセント
--------------------------------------
1 Internet Explorer 6 66.19%
2 Firefox 24.44%
3 Safari 2.12%
4 Opera 8 1.28%
5 Internet Explorer 7 1.07%
6 Internet Explorer 5.5 0.94%
7 Opera 8 0.55%
8 Netscape 7 0.48%
9 Internet Explorer 5.0 0.47%
10 Opera 9 0.16%
11 Camino 0.10%
12 Opera 7 0.10%
13 NetFront 0.09%
14 Opera 9 0.05%
15 Netscape 6 0.02%
16 Opera 7 0.02%
17 DoCoMo 0.02%
18 Internet Explorer 4 0.01%
19 Netscape 8 0.01%
20 その他 1.80%
バージョン違い、亜種をまとめると
IE系 68.68%
Mozilla系 25.05%
Opera系 2.16%
Safari 2.12%
その他 1.91%
という感じでIEとFirefoxだけがちゃんと調べないといけなくて、あとは誤差って感じだ。
調べ方は単純、自分のはてなダイアリーの日記欄に色々なブラウザで同じコメント書いてみて、 etherealでパケットキャプチャー。
どのような文字コードを送出しているか調べるというものだ。（ちなみに、はてなダイアリーの文字コードはEUC-JPである）
脱線だが有名Blogの文字コードをいくつか調べたところ
ブログサーバ 文字コード
---------------------------
はてな EUC-JP
FC2 EUC-JP
livedoor EUC-JP
ココログ UTF-8
という結果になったので、EUCとUTF-8さえ押さえれば、Blog界の文字化け問題の対応としてはだいたいＯＫと言えそうである。
まず、ASCII文字（アルファベット）
書き込み文字列 abc
------------------------------
IE abc
Firefox abc
Opera abc
すべて同じ結果。
ASCIIしか使わない限りにおいて文字化けは発生しないという、非常に当たり前の結果になった。
次、JIS X 208 のひらがな
書き込み文字列 あいう
--------------------------------------
IE %A4%A2%A4%A4%A4%A6
Firefox %A4%A2%A4%A4%A4%A6
Opera %A4%A2%A4%A4%A4%A6
すべて同じ結果。
さすがに、この程度では文字化けしない。まあ当たり前である。
ここで、規格の復習。
HTMLの規格上、ブラウザは文字列をPOSTするのに、
「文字コードヲタクで集まってピザとビールを楽しむ会」に参加してきた。
（うそ、本当はレガシーエンコーディング変換機能の開発オフラインミーティング）
ちょっと（だいぶ)遅刻してしまいご迷惑をおかけしてしまったのだが、
いやー、ヲタク同士の極めて濃ゆい会話を堪能させていただいた。
普段リアルで顔を会わせる面子で文字コードで盛り上がるなんて不可能だから
こういう集まりは素直にうれしい。
さて、あの場で酒の勢いでいろいろと放言してしまったのだが、
たぶん、今日の酒の量だとほとんどの人は明日には忘れ去られていると思うので
改めてこのブログで意思表明をしたい。
・ISO2022-JP-MSは撤回してほしい、世の中で求められているのは
Outlook Expressが送ってくる拡張ISO2022-JPを受信できることであって
それ以外のエンコーディングは必要ない。
スジがいいとか悪いとかは関係ない。CP5022xでいいじゃん。
現実重視！
・英語ホームページを作って欲しい。アメリカ人の
「なぜUnicode.orgに登録されているマッピングテーブルではダメなの？」
という疑問に答えることはコミュニティに受け入れられる上で極めて重要。
（あってるかどうか自分では確認できないコードをacceptしろと言われるメンテナ
の気持ちを考えよう。そら嫌がるよ）
また、ドキュメントがなければ結局新規ソフトはどんどん森山さん実装と
非互換の実装をしていくので事態はどんどん悪化していく。
・今回開発したレガシーにやさしい変換方式は、
Unicode.orgに登録されているマッピングテーブルと同じファイル形式でも
公開してほしい。
世の中のソフト会社のi18n対応ってのは極めて冷遇されていて、１流の技術者は
コア部分の開発、２流の技術者がnlsサポートみたいなアサインは珍しくない。
するとどうなるかというと、現状、Unicode.orgのマッピングテーブルからコードを
自動生成して対応する。みたいな話は腐るほどある
（特に僕が以前いた組み込みの世界のミドルウェアでは）
だから、ファイルフォーマットに不備があろうがなかろうが、Unicode.orgの
形式重要。ある種のデファクトだから。
・日本の技術者にも、なんでこんなにマッピングがいるのか理解していない技術者は
腐るほどいる。
だから、レガシーエンコーディングWikiに、これこれこういう状況ではｘｘという
ソフトがこういう送り方をしてくるから受信側でこの変換方式をしていしないと
非互換になって困ってしまうんだ、的な使い方の情報必要。
これがないとマッピングテーブルが増えた分だけ混乱して、
間違った使い方をする人が必ず出てきて非互換がより悪化する
・これはコミュニティの働きかけの問題になってしまうが、
現在の、Windows互換にしようと思ったら、
ｘｘというソフトではCP932と指定する必要があり、
ｙｙというソフトではSJIS-msと指定する必要があり
ｚｚというソフトではMS932と指定する必要があり
また、別のソフトではCP943Cと指定する必要があり、
かつそれをやってもｘという文字とｙという文字は変換ルールが違うので
文字化け。という状況は無くさなければならないという強い意志をもって欲しい。
（現状、バッドノウハウの塊）
私はWindows31Jと指定したときにソフト・言語によらずマッピングルールが一意に
定まる世界を望む。
そうでなければ、相互運用など出来ない。名前重要！
同じものに同じ名前が付くように働きかけをして欲しい。
・今回進めているレガシーエンコーディングプロジェクトを知らない人はまだ
いっぱいいる。
（てゆーか、僕は知らなかったっす（＞＜；）
もっと宣伝、宣伝。
無論、僕も出来る範囲でお手伝いさせていただきますゆえ・・・
ところで、僕はeucJP-msとCP50932がなぜ両方必要なのかをまだ理解できてません。
だれか教えてくださませ。
お願い
P.S. 芝野いいんちょーと初めて議論させていただきました。やっぱいいんちょーは違うぜ
委員長！ ランキング！