アカウント名:
パスワード:
主に、企業がウェブ上でお詫び文書を公開するときとかに、すでに使われているようです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
すごい文字コードを考えた! (スコア:4, おもしろおかしい)
64x64ピクセルとしましょう。
その64x64=4096個のピクセルに対して、それぞれ1ビットを
割り当てます。すると、1文字を4096ビットつまり512バイトで
表現できます。
このようにすれば、あらゆる漢字を表現できますし、それにも
かかわらず、字形とコードの対応は自明ですので、目的とする
コードは簡単に見つけることができます。収録文字が多すぎて
目的の文字が探せないなんて問題とも無縁です。
現状のTRONコードでは、Unicodeへのアンチテーゼとしてか、
要望のあった文字は必ず収録するようにしているみたいですが、
この文字コードの場合は、収録の必要すらありません。
あらかじめ、あらゆる文字が収録されているのですから。
この文字コードを、次世代のTRONで採用してもらえないでしょうか?
誰だ、「これなんてビッ...」だなんて言う奴は?
Re:すごい文字コードを考えた! (スコア:3, すばらしい洞察)
1文字513バイトにすべきです。
Re:すごい文字コードを考えた! (スコア:1, おもしろおかしい)
なんてものが必要になるんです。64x64とかじゃなくて、たとえば
A4全体くらいをまるまるピクセルで表現してしまうような、
「文書コード」という概念を提案します。
そうすれば、改行文字なんてものは不要になります。
# 拡張子はBMPがいいですか?それともTIF?PNG?
Re:すごい文字コードを考えた! (スコア:1)
手書き?
天琉陳(Teruching)
Re:すごい文字コードを考えた! (スコア:1, おもしろおかしい)
旧来の文字コードにおいても、入力時には、様々な支援プログラムや
補助データを用意するのが普通です。たとえば、ローマ字変換や
仮名漢字変換のためのソフトウェアや、仮名漢字変換のための辞書
などです。これらは、用意したほうが便利ですが、絶対に必須と
いうわけではありません。その証拠に、T-CODEのような、
日本語辞書を必要としない入力方法も存在します。最悪、
文字コード直接入力だってできます。(不便ですが)。
64x64文字コードや「文書コード」でも、事情は同じです。不便を
耐え忍ぶのであれば、文字/文書コード直接入力でもOKです。ただ、便利な
環境を構築するなら、旧来の文字コード体系では「フォントファイル」と
呼ばれるような字形辞書があるとよいと思います。もちろん、旧来の
文字コードに対してもT-CODEやSKKのような様々な入力方法が考案されて
いるように、64x64文字コードや「文書コード」に対しても、直線ツール、
ドット描きツールなどを備えた入力方法などを考案することができます。
字形辞書と組み合わせれば、旧来の入力方法をそのまま使うことも
できます。手書きもOKですよ。
余談になりますが、お気づきかもしれませんが、64x64文字コードや
「文書コード」においては、表示に際してフォントを必要としません。
なぜなら、コードがそのまま字形を表現しているからです。
したがって、文書のやりとりに際して従来のPDFなどでありがちだった、
フォントがないための文字化けなどの問題とは無縁です。
Re:すごい文字コードを考えた! (スコア:0)
THCがいいと思います。
http://thcomp.org/ (スコア:0)
>type read.me
Re:すごい文字コードを考えた! (スコア:0)
主に、企業がウェブ上でお詫び文書を公開するときとかに、すでに使われているようです。
Re:すごい文字コードを考えた! (スコア:2, おもしろおかしい)
Re:すごい文字コードを考えた! (スコア:0)
Re:すごい文字コードを考えた! (スコア:1)
それなんてブラックポーション?
タブレット中毒者。
Re:すごい文字コードを考えた! (スコア:1, 荒らし)
Re:すごい文字コードを考えた! (スコア:1)
256階調も用意する必要はないと思いますが、最低4階調くらいは必要なのでは。余裕を見て8階調とすると、1ピクセルに対して3ビット。
つまり一文字1.5KB。
Re:すごい文字コードを考えた! (スコア:1)
#それなんてPD(ry