文字コード総合スレ Part11
レス数が900を超えています。1000を超えると表示できなくなるよ。
訂正、合成文字の方が先だから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くらいかな？ NUL SO SI ESC SPACE DEL 辺りも使うかな ^cはシグナルを送るキーとして使われてるだけで改ページの意味があるわけではないからなあ
とはいえ改ページとしてのFFがあるテキストファイルもたまにある Win32APIのMessageBoxはテキストに0x03が含まれてるとゴニョゴニョ Unicodeの概念そのものは好きだけど
太字の「>」とか 要る？ そういう太字にしたり斜体にしたりするのはワードプロセッサーや写植システムの役割だろう。 知らんけどもともとどっかにあったんじゃないの？
とりあえずなんでも拾っとくことこそUnicodeの概念とやらの本質じゃないの？ なんでも拾っておくってなら、CJKまとめるなんて暴挙はなかったろ 別々の集合からならまとめても元に戻せるから矛盾しないぞ >>887
それは16ビットで収めるためのMSの暴挙 絵文字排除するはずだったのに何のための文字コードだったのか むしろいちいちﾌｫﾝﾄなんか使わずに画像使えばいい 記号類にもUnihan Databaseみたいな典拠集積したやつを作っておくべきだったなとは思う。 「画数の多い文字」として知られているけれども本当に実用されていた文字なのか誰も確認できず、
しかし「画数の多い文字の例」として使われているために少なくともそれ以後は実在していると考えるしかないという >>899
じゃあ実用されていた漢字で一番画数が多いのはなんですか？ 実用なら身も蓋もありませんが親鸞の「鸞」と、2chでもおなじみの「鬱」でしょうね
新聞で使う文字に限るなら「鑑」で、
本当の意味での常用漢字なら「襲う」と「驚く」でしょうね
本当に身近な字ですが無駄に画数多いよね！
子供の日記でも「〜でおどろいた」と良く使われるフレーズなのにね！ https://map.goo.ne.jp/place/22001814283/
浜松市に「たいと(雲雲雲龍龍龍)」という四川料理店があるが、
これで「実用化」されたことになるだろう。 複雑な文様・難解な表記ほど有難いと思ってるやつがいるうちは漢字は世にはばかり続けるだろう >>904
＞驛辯
辨・辧・瓣・辮・? かもしれませんよ…それらが合わさって弁になったんです メールも8bit文字ををBase64などでエンコードせずにそのまま送れるのが標準になってほしいよ
普段使っているメールサーバーにtelnetを使ってEHLOではなく従来のHELOでログインして
ヘッダーにshift jisをエンコードせずに入れたメールを送ってみたが問題なく送れたから
SMTPUTF8対応を明言していなくても8bitを送れるメールサーバーは結構あるんだろうけど レス数が900を超えています。1000を超えると表示できなくなるよ。
