文字コード総合スレ Part11
■ このスレッドは過去ログ倉庫に格納されています
常識だし当たり前のことだから、 言ってることに間違いはないってことかな? 今時のまともなMUAでいわゆる半角カナに対応できないものってあるかな? fj全盛の20年前ならいざ知らず。 C/C++ The C and C++ standard libraries include a number of facilities for dealing with wide characters and strings composed of them. The wide characters are defined using datatype wchar_t, which in the original C90 standard was defined as "an integral type whose range of values can represent distinct codes for all members of the largest extended character set specified among the supported locales" (ISO 9899:1990 §4.1.5) Both C and C++ introduced fixed-size character types char16_t and char32_t in the 2011 revisions of their respective standards to provide unambiguous representation of 16-bit and 32-bit Unicode transformation formats, leaving wchar_t implementation-defined. The ISO/IEC 10646:2003 Unicode standard 4.0 says that: "The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers." カンペキな引用 やはりオレのレスはカンペキ 会社のメールは勝手にメールに含まれる半角を全角にかえやがる ※ 必要で半角をいれてるからな 半角でフォルダ名つけるバカがいるせいで その半角を含むパスに格納されてる資料のおいてあるパスを送ると メール送ったあと一時期必ず文句がきてたからな その資料にアクセスできないと そんな場所ないと うんざりしたから この部分が半角ですと書いてやっても アクセスできないと返信が来る 何度か半角でフォルダ名つけたバカを探しだして しばいたろかと思ったわ しばくんじゃなくてフォルダ名を変更すれば済むじゃん あんたタイムゾーンスレでずっとそういう趣旨のこと言ってるよねw フォルダ名は一回変更したわ すると突然 半角以下にあるリンクがすべてアクセスできなくって みなが大騒ぎになったわ そんなことやったのはだれだと 幸いオレがやったとバレずに済んだが メールで送らなければいい 会社のメールを変えればいい 会社を変えればいい 半角君の発想だとこんな感じ >>718 そいつは勘違いしてるよ。 Linux/UnixはUTF-16などASCIIと互換性がない文字コードに 対応するのが大変だからUTF-8を作ったという話をしてるのにそれをわかってない UTF-16に対応しようと思ったら、あちこちで使われてるcharをwchar_tに変えないといけない printfですら使うことができない。まあ現実的に不可能だわな 最初からUnicode(UTF-16)対応として設計開発された Windows NTとは違うわけだ >>719 詳しい解説サンクス wchar_t 難し杉ない? 外国人は鼻ほじりながら「おまいら大変だなー」と同情してるだろうな charで全て賄える文字文化圏が羨ましい >外国人は鼻ほじりながら「おまいら大変だなー」と同情してる その手の輩も今はemojiに対応するために結局Unicodeと向き合わなくちゃならなくなってるけどな >>717 フォルダ名に半角カナ使うなとか原始人かよw バカ「半角カナを使うと文字化けするんだぞ!使うの禁止!」 それは昔メールでよく使われていたISO-2022-JPに半角カナがないのが 理由なのでSJISやEUC-JP、今の主流のUnicodeにはあてはまりません。 ISO-2022-JPでなければ半角カナ使って良いんですよ。 バカ「む、難しい言葉でごまかすな!」 やっぱりバカどもは なんにもわかってないわ。。。 電子メールでいうテキストというのは 7bitだけで表現されたもんをテキストといってるワケ つまり、伝統的にascii(7bit)だけで表現されてるデータをテキストと呼称してる 昔は、7bitのデータしかやりとりできなかったネットワークもあったからな utf−8とかshift−jisとかな、メールでは意味不明なバイナリーなわけ 分かる? そんなテキストもどきでも いまでもプロトコルの規定どおり7bitのデータ以外を発信してはいけないのは当然 Content−Transfer−Encoding: 7bit ← コレは絶対だからな utf−8やshift−jisのテキストもどきならbase64エンコードするとかしないといけない そのままがいいならunicodeのエンコード形式でutf−7という選択肢もある お、書けた ルータ再起動でも書けなかったのに >>727 のレスをサクラで半角全角変換するだけで書けた どの部分がよくなかったのかよくわからん サーバーが>>727 のレスをセキュリティブロックではじいてるみたいだったからな まあいいか 日本のすべてのシステムではずっとな メールのテキスト表示まで保証されてるのはiso-2022-jpにマッピングできる文字だけだからな iso-2022-jpにマッピングできない文字はそもそも保証されてない ※ JISにマッピングできないUnicodeやShift半角カナなんか保証してない ※ 最低でもiso-2022-jpのフォントなら日本のどのシステムにも用意できてるハズだからな ※ そうでないとテキストすら表示できない 保証されなくてもいいなら、そのままばっちいままのテキストもどきをエンコードして発信すればいいワケ 別にUTF-8、Shift_JISで送ってはいけないということはない ※ UTF-8なんかもともとエンコードされてるオクテットをさらに7bitにエンコードしてから発信することになる わかった? 結論をいえば 受信されるシステムで最終的にそのシステム用にデコードまでできて 表示まできるのなら問題ない それだったら受信したヤツも腹もたたない 表示できないメールもらったら腹立つだろ デコード未対応だったり未対応形式だったりするエロ動画をしらずにダウソしてな、 そのエロ動画が再生できないのと同じぐらいの強いイラダチを感じるハズだからな ホントなこの板は低学歴底辺知恵遅れのゴミクズしかいないのがよく分かるわ > あと「8bit のASCII」とか寝惚けたこと言ってるけどそんなこと言うやつは文字コードの話する資格ない。 > ASCII が 7bit というのは常識レベルの知識。 ID:HgLxU9xgやオレみたいにきわめて常識的なこといってるヤツが叩かれて しったかテキトーなこといってる低学歴底辺知恵遅れが幅をきかせてるのがこの板だからな。。。 >Content−Transfer−Encoding: 7bit ← コレは絶対だからな 前世紀の遺物かよw つかオマエ、mohtaみたいでキモいんだが。 MIME-Version: 1.0 MIME-Versionは1.0しかない ホントな知恵遅れがいってることは いつも意味が分からない 低学歴底辺知恵遅れの世界にプロトコルなんかないからな 低学歴底辺知恵遅れドカタは ネットワークのプログラムなんかやらないから関係ない 低学歴底辺知恵遅れと まともな人間の間では そもそも意思疎通は不可能 プロトコルがまったく違う 低学歴底辺知恵遅れ特有のプロトコルがあるらしいが オレはそのプロトコルがまったく分からない 氏名における「」や「𠮷」や「乭」 | yasuokaの日記 | スラド https://srad.jp/ ~yasuoka/journal/623209/ 読売の元の記事貼ろうと思ったらネット上には無かった……。 JIS X 0213ベースなのか? 戸籍統一文字と住基ネット文字コードの擦り合わせしたデータベースはどうするんだあれ UNICODEで恥ずかしい書き込みしてた人が 大量レスでスレ流ししてるようにしか見えない ID:yTcXDgUV 連投してID赤くしてたら誰もレス読まないぞ >>739 >ID赤くしてたら 皆が皆、専用ブラウザを使っているとは限らないのでは? unicode の議論と wchar_t の議論を混ぜるやつは素人。 unicode が普及するすっと前から wchar_t は普通に使われてる。 そりゃ使われてるかどうかで言えば使われてるだろうけど。 そんなことよりも技術的な所気にならない? 問1 16bitのwchar_tで1バイト または 3バイトのEUC-JPを 扱う場合メモリイメージはどのようになるでしょうか? 問2 32bitのwchar_tで1バイトのEUC-JPを扱う場合 メモリイメージはどのようになるでしょうか? 答えわかる?意外すぎてびっくりするよ。 16bitのwchar_tや32bitのwchar_tの使い方(エンコーディング)によるとしか >>743 そういう答えの場合は、知ってる実装を一つだけでもいいので答えてくれればいいよ >>744 コンパイラとか libc を設計する奴以外は内部実装関係ないやろ。内部実装に依存したら移植性が無くなる。 知りたかったらlibcのソース嫁。最近の linux の glibc ならUCS4に統一。昔のunixだと EUCコードそのまま16ビットでフラグ付きで入れてた。 > 昔のunixだと EUCコードそのまま16ビットでフラグ付きで入れてた。 それはwchar_tが32bitってことかな? 16bitでは不可能だよね? 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を検索時無視するという仕様を活用するなら、互換分解よりもそっちが良かったって文字が他に沢山ない? まあ、今更言ってもなんだ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる