文字コード総合スレ Part11
■ このスレッドは過去ログ倉庫に格納されています
wchar_t自体はcharset/encoding独立だとしても、実際にEUC-JPを格納する実装が 存在していたとは知らなかったな。 >>746 知らないなら、変な知ったかぶりせずに黙ってるべき。 実装によって色々差があるけど最上位ビットとかをフラグに使用して16ビットに詰め込んでたんだよ。 うろ覚えだけど、例えば 0021-007e に ascii 00a1-00fe に jis kana 2121-7e7e に 0208 a1a1-fefe に 0212 とか、そんな感じ。 やけに wchar_t にこだわる(かみつく)奴がいるけど理由がわからん 内部がどういうエンコーディングかはプログラマは意識する必要ないのに >>747 16ビットでなくて 32ビットで良いなら、今でも FreeBSD は EUC-JP をそのまま wchar_t に入れてる。 32bit なのでフラグ操作とかもなくて生のまま 0x008fa2be とか 0x00008ea0 とか。 低学歴低知能のククソニートどもや底辺ドカタどもは 自分がどんだけ知恵遅れなこと書いてるのか なかったことにししてる サマータイムスレでも同じだからな コイツラ >>742 漏れの知ってる答えは 1も2もそういうコード書く奴はクビ RFC 8369 - Internationalizing IPv6 Using 128-Bit Unicode https://tools.ietf.org/html/rfc8369 すいません 文字コードについて教えてほしいことがあります マジものの初心者なんですがどうかおねがいします Unicodeの一種(?)で65280文字ある種類のものを、なんと呼ぶのでしょうか。 (最初の方は透明に見えるフォントで始まり、最後の方は全角英数などが割り当てられています http://www.m-hoz.com/jsp/unicode.jsp?Bgn=0& ;End=65536 このページと想定しているものはまったく同じです) WikipediaなどでUnicodeの記事を読んだのですが、バージョンや面やサブセットなどたくさんの種類があり 私が利用したいと思っている65280文字を含むUnicodeの一集合のことをなんと呼べばいいのか分かりませんでした。 というか 正直、Unicodeというのは65280文字(0xFFFF番目ですから)までしかないものと思っていましたが なんかそれを遥かに凌ぐ量の文字が収録されていると書いてあり 余計に混乱してしまいました 文字コードに関する知識がほとんどなく おかしい文章になってしまいすいません よろしくおねがいします。 >>758 正直なところ何を言いたいのか理解できないのだが、Unicode で定義されている文字なら公式サイトで全部見られるよ。 Code Charts http://unicode.org/charts/ >>758 基本多言語面 https://ja.wikipedia.org/wiki/%E9%9D%A2_ (%E6%96%87%E5%AD%97%E3%82%B3%E3%83%BC%E3%83%89)#%E5%9F%BA%E6%9C%AC%E5%A4%9A%E8%A8%80%E8%AA%9E%E9%9D%A2 Unicodeは似てる文字を一つにまとめて約6万5000文字(16bit)に収めるぞーって 言っていたのが、案の定無理だと破綻し(だから言っただろうがバカメリケンが)、 21bitを使い最大で約111万文字収録可能になってる 最新のUnicode 11.0 では13万7439文字が収録されてる Unicodeはもはや文字コードじゃない 文字シーケンスというべきだろう 複数の文字を使って1文字を表している >>761 「基本多言語面」 ありがとうございます! すみません。言い方がボケナスで余計な労力をお掛けしました。 この言葉が知りたかったのです。 ちなみに極めてどうでもいいことですが マインクラフトというゲームのフォントを変えたいと思っており その為のフォントおよび文字コードの勉強していこうとしていたところでした。 HTML のフォント指定は、こういう感じ。 「html フォント指定」で検索! HTMLの文字コードは、UTF-8 <font face="候補1,候補2,候補3">フォントを変更します</font> <p><font face="MS P明朝,MS 明朝">これは明朝体を指定</font></p> それとも、マインクラフトはHTMLじゃないのか? >>762 合字はそうすることが自然だからそうなってるんだと思ってるんだけど、全部個別に文字コードを割り当てたほうがいいってこと? >>764 マインクラフトのフォントは ./assets/minecraft/textures/font というディレクトリに16ドットフォントが16列16行配置されたPNG形式の画像が0xFF枚格納されてる というような仕様になってますね HTMLはあんまり関係ないです。 Unicodeの公式サイト(http://unicode.org/ )で,Unicodeの最新安定バージョンがなにかを調べるにはどこを見ればいいんですかね。 今11.0だそうですが,他サイトの情報なので,なるべく本家本元の情報が欲しいんです。 >>768 ちゃんとメニューを見よう。 サイトの左側のメニューから The Unicode Standard プルダウンの中にある Latest Version を選べばよい。 というわけで、現時点では 11.0 が最新という認識で正解です。 Unicodeって,なんで初めに多バイト文字のことを考えなかったんだろう。 そもそも多バイト文字を統一するために設立したようなもんなんだから, 2^16では済まないことくらい予測できた筈なのにね The Unicode Blog: New Japanese Era http://blog.unicode.org/2018/09/new-japanese-era.html Unicodeの方でも記事になってたのか。 >>771 アルファベット二十数文字しか使ってない奴らが 六万文字もあれば世界中全部の文字カバーできるよな って雑に考えたから >>773 ちょっと漢字の知識があっても漢字が5万字くらいだろ? 漢字で5万使って残り1万5千だな、余裕だろって感じだったんだろうな >>774 まあ正直,日本人でも特段勉強してなかったらそういう感覚やろうしな で、バカは5マンの漢字全部読めるの? で、バカは5マンの漢字全部書けるの? で、バカは5マンの漢字全部使えるの? で、バカは5マンの漢字全部使ってるの? 卜部の卜 トナカイの卜 見た目でも違いなんかまったくわからない でもコンピュータに合わせて世界を 作り変えることができるなら、 65535文字に抑えるだろうな サマータイムもない世の中 文字も16進数が基本かな 電気の流れもマイナスからプラスへだ 君が代によれば、天皇の世は八千代続くので、 元号の合字も8000個必要になる。 Unicodeのどこかの面にまとめて確保できないものだろうか。 >>778 おおむね賛同するが 電流の流れが電子の流れと逆なのは電算機登場以前の話だぞ >電気の流れもマイナスからプラスへだ これいつかやっても良いと思うけど どこにどんな影響が出るんやろね 数学の外積の定義とかも変えたくなりそう >>782 電子がマイナスからプラスへと流れると電流がプラスからマイナスへ流れるという理解で問題ない 数字が連続してない符号化文字集合ってあるのかな。 EBCDICとかは英語が連続してないことで有名だけど。 C言語の規格で'0'から'9'は連続していることになってたと思うから そうじゃない文字コードがあったとしてもとっくに淘汰されてるのでは 世界共通になる前に6と9のどちらかを変更しておいて欲しかった >>786 毎日のように使うのに、普通に気が付いてなかった。 おもしろい。 けど文字集合ではないなw >>788 あと1と7 漢数字がそれが表わす数字順に並ばないって結構有名だったのか……恥かしい >>788 9って手で書くときはqみたいな形じゃない? なんでコンピュータのフォントだと丸まるんだろう。 >>791 ビリヤードの玉なんかわざわざ区別のつかないような字形にした上で 区別が付くように線を引いてるんだぜ 1960年代1970年代では、 コーディングシート上で「O(オー)」」と「0(ゼロ9)とを 区別するために Fortranは「「O(オー)」の上に傍線を書いたし、 COBOLでは、「0(ゼロ)」に斜線を引いて区別 してたような気がする。 「I(あい)」と「1(いち)」の場合は、「I(アイ)」を 小文字の「i」を使っていたような気がする。 なにぶん、古い話なので、間違っているかもしれないが 一応参考までに 斜線入りの0 VS使ってU+0030 U+FE00で表せるように なってたんだな。 >>795 本当だ! って、なぜVS?重ね書きでいいのだから合成では、って探したらU+0338 U+0030でもいいらしい…… 二重収録…… まーーた「異字体」という概念を欧米のやつらがめちゃめちゃにしやがったな >>794 Dも横線入れたり、Uは必ず小文字のヒゲ書いたな 今でも手書きアルファベットでついやっちまうw Unicodeをめちゃくちゃにしてるのは大昔の馬鹿な中国人 斜線入りゼロの全角版もU+FF10 U+FE00で規定しようとしてるな。 もうアホかと。 21bitも使わせるからそんな浪費するんだよ。16bitで我慢させておくべきだった。 多コードポイント文字(←?)なのでビット数関係ない むしろ、16bitに詰め込むために合成やVS、ZWJのような小細工が作られてしまって それが乱用されてる UCS-4でコードポイントで利用できる領域は21bitまでときまってる コードのレンジはMSBを除く31bitまで コードポイントのビット数とエンコードのビット数は関係ない 相変わらず低学歴知恵遅れは 意味不明なことばっかりいう >>804 知恵遅れは自分の思慮の浅さを認識出来ないから知恵遅れなんだぞ 仮に間違っていても何らかの意図や思惑があって発言したものを 意味不明と思考停止した時点で自分が馬鹿だと宣言するようなものだから 賢いつもりならもっと謙虚な態度を取るべきだ >>803 は複数のコードポイントのシーケンスで一文字を表す体系を採用した時点で コードポイントが何ビットかはそれほど重要な問題じゃないと言っているわけだし 基本面しかなかったころにUCS2でコードポイントを16bitで表現していたのだが 賢いつもりならそれを分かっててそんな馬鹿のことを書いてるのか? お、おう……ありがとう 「誰一人エンコーディングの話はしてねーだろ幻視かそれともセレクタ知らんのか」ぐらいは書こうとしたんだが >>796 U+0030 U+FE00は標準化されてるけどU+0030 U+0338の方はそうじゃない スラッシュ0っぽいものになるかもしれないという程度 あとVSは検索時には無視されるんで0030と等価になる >>807 従来のやり方に合わせるとU+0030 U+0338に対応するNFC形式を用意して検索は互換分解で対応ってならね? 逆にVSを検索時無視するという仕様を活用するなら、互換分解よりもそっちが良かったって文字が他に沢山ない? まあ、今更言ってもなんだ 訂正、合成文字の方が先だからU+0338 U+0030 なんで混同している人がいるのかえあからないけど合字と変種は別のものだよ。 合字はもとの文字と別物として扱われるのに対して、変種はあくまで同じ文字の字形違い。 すいません 「�����������d」 という文字列を解読したいです。 $ echo '<当該文字列>' | od -A xn -t x1 の結果は 000000 ef bf bd ef bf bd ef bf bd ef bf bd ef bf bd ef 000010 bf bd ef bf bd ef bf bd ef bf bd ef bf bd ef bf 000020 bd 64 のような感じです。 個人的には\0x0eや\0x0fが多く登場しているのでUTF-16あたりをUTF-8で解釈しているのかなとも思いまして iconv(1)などでどうにかしようとしました(iconv -c -f utf16 -t utf8)が 駄目でした。 どうかよろしくおねがいします。 >>811 utf8のEF BF BDは、utf16ではFFFD(非文字)。 例えば、エンコードに失敗した時に使われる。 >>813 なるほど。復元は無理ってことですね。thx URLエンコードとか16進文字列で表示してほしいよね。 文字化け文字列を表示されても途方に暮れる。 >>815 表示したい文字とそれ以外をどうやって区別させる? 低学歴知恵遅れの世界ではグリフが違うように見えれば その字じたいがもつ意味もかわる φと Φ の小さい字が小文字 ɸ だと一緒のはずなんだが環境によって違うのが困る unicode のくせに https://github.com/JuliaStrings/utf8proc これすばらしいね。 UTF8の煩雑な処理がC89という極めて汎用で互換性の高い言語で扱えるなんて。 ただUnicode11対応を謳ってる割には曖昧文字幅が考慮されてないのが難点 issueやPRを見てるとそれっぽい対応がされてるのかどうなのか……。 https://github.com/JuliaStrings/utf8proc/pull/83 👀 Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) >>816 書き手と読み手で共通のルールを作ればいいだけのこと。 どのみちASCII文字しか使えないので禁則文字が必要。 https://www.softek.co.jp/SPG/Pgi/performance52.html ここのページのエンコーディングって分かる? EUC-JPで読みこむと漢字だらけ Shift JISで読みこむと半角カナの「ス」だらけ UTF-8で読みこむと非文字だらけ chrome で開いたけど問題なく日本語出るぞ おまいのブラウザが糞なんじゃね ブラウザ経由せずに python でダウソしたら中身 UTF-8 のファイルが出来た <META http-equiv="Content-Type" content="text/html; charset=EUC-JP"> EUC-JP ってことになってるな 夜に見たときはFirefoxでもChromiumでもWaterfoxでも ID:lmrEE7TEが言うような文字化けになってたけど 今はFirefoxでもChromiumでもWaterfoxでも文字化けせずに見られる そのサイトのほうがおかしくなってたんじゃないか? apacheとかデフォでutf-8に強制変更とかあるからな >>825 同じく 夕べ、バイナリモードでgetしたhtmlが思いきり文字化けしてたわ あっっれ。 まさかなと思ってもう一度行ったら なんかちゃんと読めるようになってたわ。 うーん。向こうの不具合かな。とりあえずFirefoxに濡れ衣を着せてしまったことをお詫びします。 ただしFirefoxには http://www.am.ics.keio.ac.jp/ ~keisuke/lab/ptex218.html ↑このページが読めないという前科があるんだよね。 最近のブラウザは一時的に文字コード指定するメニュー無くなった >>829 そのページはサーバーでUTF-8決め打ちで送って来てる ファイル内に書かれたcharsetとどっちを優先するかって話なのかな http://www.am.ics.keio.ac.jp/ ~keisuke/lab/ptex218.htmlは WaterfoxやChromiumでも文字化けする Waterfoxだと文字コードの手動切り替えで対応できるけど 自動判定できない状況に陥っているのだからサイト側の問題なんだろうね HTTPはheaderみてそっち優先のブラウザばっかになってつまらんぬ そういえば、昔おまじない文字ってあったよな 「京」とか だいたい日本語TeXを使ってるのなら文字コードに関する知識はそれなりにある筈なんだけどなぁ >>829 EdgeでもIE11でも読めないぞ。 これもFirefoxのせいじゃない。 ちなみにw3mでは読めた。 >>832 サーバーがレスポンスヘッダで文字コードをUTF-8と返してるからそれに従ってるだけ。 そもそも自動判定しようとしてない。それなのにコンテンツはUTF-8以外(ISO-2022-JP)で出来てる。 要はサーバーの設定とコンテンツの不整合。 恐らくサーバー更新時に古いコンテンツのことを考慮してなかったんだろうな。 RedHat や CentOS のパッケージで Apache をインストールするとデフォルトで AddDefaultCharset UTF-8 が有効になっているのが原因。 この設定をコメントアウトし忘れると今回のようなことが起きてしまう。 これ、わりと迷惑度合いの高いデフォルト設定なんだよねえ…… UTF-8デフォルトはそれこそLinux機にとっては嬉しいんだけどねぇ ちなみにnghttp2というHTTP/2に特化したWebサーバーは HTTP/2の既定エンコーディングがUTF-8であるにもかかわらずなんとASCII。 いつの時代だよ……。しかも古いプロジェクトじゃなくてめっちゃ新しいのに……。 最近またUnicodeが分からなくなってしまった。 単にShift_JISのような 「一部コードを拡張マップ専用の文字にして後続のコードを その拡張マップ専用の文字のコードと連続した(つまり2次元的な配置の)コードとして 処理する」 っていう方法ではないのか。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる