文字コード総合スレ Part11
■ このスレッドは過去ログ倉庫に格納されています
で、ﾊﾞｶは5ﾏﾝの漢字全部読めるの？
で、ﾊﾞｶは5ﾏﾝの漢字全部書けるの？
で、ﾊﾞｶは5ﾏﾝの漢字全部使えるの？
で、ﾊﾞｶは5ﾏﾝの漢字全部使ってるの？ 卜部の卜
トﾅｶｲの卜
見た目でも違いなんかまったくわからない でもコンピュータに合わせて世界を
作り変えることができるなら、
65535文字に抑えるだろうな
サマータイムもない世の中
文字も16進数が基本かな
電気の流れもマイナスからプラスへだ 君が代によれば、天皇の世は八千代続くので、
元号の合字も８０００個必要になる。
Unicodeのどこかの面にまとめて確保できないものだろうか。 >>778
おおむね賛同するが
電流の流れが電子の流れと逆なのは電算機登場以前の話だぞ >電気の流れもマイナスからプラスへだ
これいつかやっても良いと思うけど
どこにどんな影響が出るんやろね
数学の外積の定義とかも変えたくなりそう >>782
電子がマイナスからプラスへと流れると電流がプラスからマイナスへ流れるという理解で問題ない 数字が連続してない符号化文字集合ってあるのかな。
EBCDICとかは英語が連続してないことで有名だけど。 C言語の規格で'0'から'9'は連続していることになってたと思うから
そうじゃない文字コードがあったとしてもとっくに淘汰されてるのでは 世界共通になる前に6と9のどちらかを変更しておいて欲しかった >>786
毎日のように使うのに、普通に気が付いてなかった。
おもしろい。
けど文字集合ではないなw
>>788
あと1と7 漢数字がそれが表わす数字順に並ばないって結構有名だったのか……恥かしい >>788
9って手で書くときはqみたいな形じゃない？
なんでコンピュータのフォントだと丸まるんだろう。 >>791
ビリヤードの玉なんかわざわざ区別のつかないような字形にした上で
区別が付くように線を引いてるんだぜ 1960年代1970年代では、
コーディングシート上で「O(オー）」」と「０（ゼロ９）とを
区別するために
Fortranは「「O（オー）」の上に傍線を書いたし、
COBOLでは、「０（ゼロ）」に斜線を引いて区別
してたような気がする。
「I（あい）」と「１（いち）」の場合は、「Ｉ（アイ）」を
小文字の「i」を使っていたような気がする。
なにぶん、古い話なので、間違っているかもしれないが
一応参考までに 斜線入りの0
VS使ってU+0030 U+FE00で表せるように
なってたんだな。 >>795
本当だ！
って、なぜVS？重ね書きでいいのだから合成では、って探したらU+0338 U+0030でもいいらしい……
二重収録…… まーーた「異字体」という概念を欧米のやつらがめちゃめちゃにしやがったな >>794
Dも横線入れたり、Uは必ず小文字のヒゲ書いたな
今でも手書きアルファベットでついやっちまうｗ 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次元的な配置の）コードとして
処理する」
っていう方法ではないのか。 ISOのダウンロードサイトがもう何年も
本文はちゃんとcharset=ISO-8859-1だと書いてるのに
HTTPヘッダでcharset=UTF-8宣言してて台無しになってる。
ASCIIはいいけどフランス語のとこがずっと文字化けしてるんだけど誰も気付かないのかね。
……と書き込もうと思って確認したらいつの間にか直ってたわ、ちっ 実際に使用されていた、おもしろい文字コードとかない？
例えばBaudot Codeは英数字がバラバラの順番で出現する、非直感的な配置になってる。 IEC646を使う事ももやめてUS-ASCIIに統一した方がいいよな。
それで問題が起きる時はフォントの方を変えて対処すればいい 絵文字はどんどん規格にない不文律が増えていくんだな 誰がunicodeに絵文字顔文字なんかいれたんだ？ https://en.wikipedia.org/wiki/Template:Smiley
ここの絵文字のソースコードを見ると<abbr>要素を使ってマークアップしてるんだけど
こういうのって一般的なのかな。 https://s.codepen.io/aardrian/debug/ENJdjN
ここでは
<span role="img" aria-label="Snowman">☃</span>
としてるね マルチバイト文字を2つのシングルバイト文字で囲いたい場合
マルチバイト文字の中にそのシングルバイト文字があった場合、囲えないんですけど
マルチバイト文字を理解しないで囲うにはどうしたらいいですか？ >>862
仮にUTF-32で処理したところで、今は合成やらIVSやらZWJやら絵文字やらで
特殊ルール満載で境界が曖昧なので、理解しないで1文字切り出すのは無理 U+2053のSWUNG DASHってどういうときに使うか分かる？
波ダッシュと同じ使い方でいいのかな。 ⁓
〜
〜
〜
~
~
￣
〜
〜
∼
〜
≁
∻
〰
~
￣
~
￣
〜 >>860
alia-label=属性は絵文字の音声読み上げが上手くできなかった時代の対処療法。
今はほとんどの（特に視覚障碍者が使うような）音声読み上げが絵文字に対応してるので
必要ないかと。role=属性をimgにするという案はいいね。 今でもASCII制御文字で使われている物はHT CR LFくらいかな？ ■ このスレッドは過去ログ倉庫に格納されています
