文字コード総合スレ part13
レス数が1000を超えています。これ以上書き込みはできません。
「コマンドプロンプトはcp932（SJIS）である」はウソ
Windows NTの標準の文字コードであるUnicode（UTF16-LE）の
テキストファイルを作り、chcp 932のままtypeコマンドで表示してみましょう
文字化けせずに表示されますね？
（フォントがない場合は表示されないがそれ以外は問題ない）
これは明らかにコマンドプロンプトがUnicodeで動作している証拠です。
コマンドプロンプトがUnicode動いているという証明はこれで十分だと思いますが、
もし仮に反論があるならその根拠を言ってくれれば説明を追加します。
（根拠なしにcp932にきまってるだろ！みたいなものは一言で潰しますのでよろしく） まとめ要らないと思う
前後の文脈読まないと意味不明なの多いし >>2
最近は元々入ってる「コマンド プロンプト」よりも
VSで一緒に入る「開発者コマンド プロンプト for VS 201X」
とか使ってる
同じじゃないかって言われるかも知れないけど違う うん同じなのは知ってる
昔のコマンドプロンプトは chcp 65001 してもバグってたけど
今のは chcp 65001 しなくても utf-8 で動くから快適 ああバグはあるわ
うっかりバイナリで変なパターン出力すると
コマンド プロンプト は落ちないのに Chrome が落ちたりするんだ
ホントは保護されてないといけないメモリを壊す観たい 「うわー、ID:uIgOlo/V 君て博識なんだね。私も試してみるね。
「コマンドプロンプトを開いて…と
「それで “漢字”と入力したファイル k を UTF16 LE で保存と…
「よし準備完了！
--
C:\>od -x k
0000000 feff 6f22 5b57 000d 000a
0000012
C:\>type k
漢字
C:\>copy k con
・"oW[
1 個のファイルをコピーしました。
C:\>cat k
・"oW[
C:\>type k | od -t x1
0000000 8a bf 8e 9a 0d 0a
0000006
C:\>
--
「あれれ？ ID:uIgOlo/V 君、なんかおかしいよ？ どうして？
「“「コマンドプロンプトはcp932（SJIS）である」はウソ”なんだよね？ >>10
いつの間にkの中身が書き換わってるの？
何やだ怖い君のPCおかしいよ >>39
cmd /?
/A 内部コマンドの出力結果を ANSI でパイプまたはファイルに出力します。
/U 内部コマンドの出力結果を Unicode でパイプまたはファイルに出力します。 デフォは /A なんだろ
そんで /A のときは
chcp の値に依存するんだろ
パイプで常に cp932 になると思ったら間違い >>2 の結論は間違いだけど
>「コマンドプロンプトはcp932（SJIS）である」はウソ
ここだけは合ってる >>14
> >>2 の結論は間違いだけど
間違ってる「結論」とはどの部分？ >>2の結論は一行目。つまりお前が合ってると言った部分だろう？
>「コマンドプロンプトはcp932（SJIS）である」はウソ >>13
> /A 内部コマンドの出力結果を ANSI でパイプまたはファイルに出力します。
では画面へは何コードで出力しているでしょうか？
答えはUincode。なぜならUnicode文字が文字化けせずに出力できているから 普通に読んだら結論はこっち
>これは明らかにコマンドプロンプトがUnicodeで動作している証拠です。
圧倒的に国語力が無いか
論理思考が出来ない人なんだろう >>19
証拠があって、結論が出るんだろ？
大丈夫か？国語力の問題か？ 最初に結論を書くっていう有名な国語的テクニックを知らないのかな？ 「絵文字 知られざる舞台裏」
私たちがスマホなどで日常的に使っている絵文字。
この絵文字は、“世界共通言語”として管理されており、絵文字の新規採用をめぐり、様々な団体がロビー活動を行っている。
“共通言語”として世界的に規格が統一されている絵文字。
アメリカの大手ＩＴ企業などからなる団体が、新たな絵文字の採用を決定しており、認定を求めて様々な団体がロビー活動を行っている。
番組では、白ワインの絵文字採用を求める醸造家などのロビー活動を取材。
絵文字は、どのようなプロセスで決定されてゆくのか、その知られざる世界を描く。
原題：Ｂａｃｋｌｉｇｈｔ： Ｂｅｙｏｎｄ Ｅｍｏｊｉ （オランダ ２０１９年）
https://www.nhk.jp/p/wdoc/ts/88Z7X45XZY/episode/te/2QGK3QN6JJ/ >>22
>“世界共通言語”
>アメリカの大手ＩＴ企業などからなる団体
NHK的な物言い、いいねw
でも、「言語」 って?
これ、カリフォルニアのワイナリーの話かな?
そこのMLに登録するとサブジェクトに絵文字の入ったメールを送ってくるとかなんとかw ドレスデン・コデックス
マドリー・コデックス
パリ・コデックス
グロリア・コデックス 本編観たけどつまらなさ過ぎて途中で寝てしまった
IBM Apple Microsoft Google Facebook あたりの名前はちゃんと言ってたと思う 一部思い出した
NHKらしくほとんど黒人とLGBTの話ばかりだったんだが
私の造ったEmojiが登録されたって自慢気に中国人研究者っぽいおばさんが出て来て
チベットの旗は候補に出たけど登録は見送られた
チベットの旗が登録されることは今後も無いでしょう
って笑いながらインタビューに答えてた ↑「ナチ強制収容所のバッジ」というページ。他に人が見なくていいように。 そのうち絵文字が第2エスペラントになりそうな勢いだな 言ってもThis is a pen.も表現できないぞ 架空発注繰り返してもらえるくらい強力なコネが欲しい >>31
日本語がURLでエンコードされると長いよなあ
日本語1文字がアスキー9文字って... 誰だよこんなの考えたの
あともう一つなんだけ、ぷよぷよみたいな名前の 次スレはここでいいのかな？
>>48
文字コードが決まってない(なかった)んだから仕方ないじゃない もともと ascii のみ。ascii の中でも一部使えない文字があるので、それは %エンコードする。
だったのが国際化にはUTF-8を使えに拡張された。
文字コードが決まってなかったわけではない。
あとURLにSJISとかUTF-16送ってくるやつは滅びろ。今すぐ滅びろ。 文字コードの勉強中です
Windowsで使われている文字コードはCP932（Shift-JISの拡張版）ということまで分かりました。 IMEパッドで理解を深めようとしているのですが、分からないことがあるのでご教示お願いします。
・IMEパッドの「シフトJIS」はCP932のことを指していると思っていいですか？
・IMEパッドの「JIS X 0208」はCP932の文字集合だと思っていいですか？
・だとすると「JIS X 0208」と｢シフトJIS」は一対一で対応すると思いますが、「シフトJIS」にあって「JIS X 0208」に無い文字（①やⅠなど)があるのはなぜですか？
過疎っているようですがご回答いただけると幸いです 勉強してるなら、理由も考えてみなよ
他人に丸投げするのは勉強とはいわない 仮定に対して反例が確認できたんだから仮定が誤ってたということだよ >>57
すごく大まかな説明をすると、
Windowsで使われているShiftJISの文字コードはMicroSoft版方言に侵されてて純正のShiftJISではない
「CP932」という言い方では純正ShiftJISなのかそれともMicroSoft版・Mac版・IBM版その他の方言なのか分からない
（まあ一般にはCP932という言い方をするとMS版のことを指す
明示的にMS版のCP932だということを示す際には、MS932とかWindows31Jとかいう呼び方をする）
なので
１つ目は、その「CP932」が指すものによる、純正ShiftJISを想定しているなら厳密には違う
２つ目は・・・・これもごくごく大まかに言ってしまうと「JIS X 0208」はシフトさせてないおおもとのJIS漢字コードのこと
（なのでShiftJISとはコード体系が違う。計算でシフトさせることで簡単にJIS⇔ShiftJISが導出できるけど）
３つ目のは、違ってる箇所の具体例がまさに丸数字とかの特殊文字に該当してる
というかこれは歴史的経緯によるものだからなあ、後世からみたら理不尽の塊でしかないだろう
理由を考えてみろと言われて分かるわけがないよ 文字集合のはなしと、符号化方式のはなしと、符号化文字集合のはなしと、文字コードのはなしを混同している人が多いな。 JIS X 0208/JIS X 0213の表はJISが決めたやつ
シフト JISの表はMicrosoftが決めたやつ
この二つは歴史的経緯で色々違いがあります
くらいの理解でいいんじゃないか そういえば、昔の*nixで日本語環境整えるのに、
このあたりが理解できないとまともな日本語表示すら出来なかったような >>57
>「JIS X 0208」と｢シフトJIS」は一対一で対応する
違う 行きつけのオシャレ美容院からのLINEの文末にいつも必ず絵文字の“うんち”が付いてて謎だったが、原因が判明したかもしれない「大事故じゃん…」 - Togetter
https://togetter.com/li/1721407
十年くらい前に同じ内容聞いた気がするけどまだ直ってないのかこれ いまだにどこかの段階でShiftJISでエンコードしてるの?
ってここ(5ch)も人のこと言えんけどw 昔の〓〓〓のように外に出す絵文字〓全部〓に変換するのはどう〓〓 どうみても禿銀行が悪いのに
docomoの皆さん気を付けてくださいって
可笑しくないか？
どうみても武漢ウィルスなのに
世界中が迷惑受けてるのと同じ構図 キャリアメールならそれぞれの絵文字に変換出来るだろうけど UTN #43: Unihan Database Property “kStrange”
http://www.unicode.org/notes/tn43/
Ken先生の新作 文字コードにうんこの絵文字とか入れた奴らはﾀﾋんで詫びて うんこは大事だぞ？
人にもよるが多くの人が毎日これと付きあうことになる
うんこを出したことない人間はいないのだ
うんこは君の健康状態を教えてくれる大切な友達だ
そしてもし君がうんこを出すことを拒否したら、君は死ぬことになる うんこが分解されて植物や動物の栄養になって
また君らの口に入ってることを忘れてはならない 分解というのは要するに菌などの微生物がその生物にとっての栄養を吸収し不要になったものを
捨てるというのが繰り返された結果であり、要するに菌のウンコである。この菌のウンコが人間に
とって問題ない場合、それは腐敗とは呼ばれず発酵と呼ばれる。納豆やヨーグルト、またアルコール
などがそれである。人間は直接摂取できないが植物にとっては栄養となる場合は肥料として使われる。 https://ja.wikipedia.org/wiki/%E4%BA%BA%E5%B7%A5%E8%82%9B%E9%96%80
コロストミーの場合、排泄方法は自然排便法と洗腸法がある。
自然排便法とは排泄口から自然に排泄される便をパウチで受けて処理する方法であり、
洗腸法とは一定量の微温水をストーマから注入し、強制的に排便を促進させる方法である。
自然排便法は、便意に従った排泄方法であり一般的に負担が少ないことが特長である。
パウチについては、不時の排泄に備えた常時装着が必要なためその使用量が増加し、
粘着剤によりストーマ周辺の皮膚にかぶれやただれを招き易い。 イスラム教指導者、笑顔の絵文字に使用制限の宗教令 バングラデシュ：AFPBB News
https://www.afpbb.com/articles/-/3353309
2021年6月24日 19:03 8bitバイトなんて使ってるの人間くらいのもんだよな
地球生物は全て6bit(64値)でエンコードしてるわけだし、スタンダードに倣うべき
古き良きPDP、DEC SIXBIT もしDNAストレージが実用化&普及したらな
数十年と数億年の資産相互運用性を秤にかけるかもしれない SFはほっといて、生化学なら遺伝子記法のAmbiScriptのフォントをユニコに入れて欲しい
とても可読性が高いけど、今のところ専用フォント入れなきゃならんのでつらい
https://en.m.wikipedia.org/wiki/Nucleic_acid_notation >>92
64値ってコドンのこと? ヌクレオチドが基本単位だと思えば4値... 素子はATGCの4値で、最小アドレス単位が3塩基コドンで1ワード=64bit(情報量の単位としてのビット)
ということでは >3塩基コドンで1ワード
正解
っていうか実質使えないものもあるんやろ？
武漢コロナには人工物である証拠がーって言ってるのもそのあたりの痕跡が見付かってるから インストラクションコードとして等価なのを数えなければ実質20くらいだけど、大体独自の制御コード、開始、終了、スプライシング(コメントアウト)、プリプロセッサマクロ的な役割を持っててフルに使ってるよ
そろそろスレチ… あやふやな事柄をブーリアン型で定義するとだいたい後悔する 精神障害者だけど精神障害者絵文字もないよね？
どういう図柄にすべきかと問われると困るけど
自治体からは
|+|
|♥|
みたいなキーホルダー貰ったけど誰も認知してないよねきっと
障害者用駐車場だけ空いてたりするけど停めていいか迷う、何故か必ず車椅子マークだし 入れて定着したら定着したで煽りに使われるだけになりそう まあ虹色の旗も別に煽りに使われてる感じはないから杞憂かもしれん。 >>107
山手線の優先席でそのマークを見せつけて席を譲らせようとした白人がいたな。 倒したプレイヤーのカードを獲得できるから強いほどどんどん増えていく WindowsでシフトJISを廃止する設定があるのだが
開発用PCではこれをオンにしたほうがいいな
シフトJIS廃止するだけで起動しなくなる日本製のアプリや読めなくなるReadmeが山ほどあることに気付ける Macでも似たようなのがあるな。.CFUserTextEncoding
もはやCarbonアプリはないけども、誰か使ってるのかな? ↑どうやって文字コードの話につなげればいいのだろう Mac上の文字コード環境（歴史的経緯、API等）とか? 駄目すか? w >>115
あんたが死んだあとの話になるだろう
マイクロソフトは言い出してから、早くても20年は実行に移さないから。 もはや存在しないキャリッジをリターンし続けるMac MacさんもいまはUnix手術でLFになったのでは？！ それで言うとMacさんが手術を受けたんではなく
別人の脳に「私はMacだ」という意識を移植したんだと思ってる このスレでいいいかはわかりませんが、教えてください
購入したDAPの再生順（ファイルの並び順）が、01-10-02-03-...09-11-21-12-22-13-23...というファイル名順になるのですが、
これはどういった文字コード順なのでしょうか
また、正しい順序で再生させるにはどうファイル名を付けるといいでしょうか
なおファイル転送順ではないようです ファイルシステム(FAT32かexFAT?)のエントリー順だったりして >>132
メーカーが中国でサポート窓口なさそうなので…
他のフォルダ内も同じ順番なので、ファイル名に関係してそうではあるんですが
>>133
そう思ってUMSSORTというソフトで昇順にしたんですが、それでも同じなんですよね DAPに限らず、メディアプレーヤーって結構メタ情報見てるぜ？
トラック名とかトラック番号とか。 >>135
困るんですよ…
>>136
MP3Tagで曲順はちゃんと埋め込んでるんですよね
トラック名が何であろうと、別のアルバムでも同じ数字の順序なんです… どうせ全角半角とか、特殊数字とか使ってるだけでは？
ファイル名の数字付け直してみては？ >>138
すべて半角数字です
同じMP3をfoobarやandroidのpowerampに送った場合は問題なく数字順に再生されるので、ファイル名に問題はないと思います
ダミーで数字だけふったファイルを入れても同じでした
文字コード云々ではなくなにかDAP側での仕様なのかもしれませんね
みなさんスレ違いな話題にお返事くださりありがとうございました たぶん別メーカーのDAPだけど、先頭に00を付けたら回避できるって書かれてる気がするから試してみては
https://www.amazon.co.uk/review/R1DDVSAU2A2YWL/ >>140
おお、わざわざありがとうございます 同じ症状ですね
しかし00と000追加も試しましたがだめでした シティポップの野良のzipファイルを開くときに、韓国語のエンコーディングを選ぶと
日本語のファイル名が正しく展開された。その他のレガシーなエンコーディングでは
駄目。これってどうなってるのかな。
ちな韓国語の場合はEUCとMSのエンコーディングが基本的に同じ?
シティポップってやっぱ日本以外でも聴かれてるんだねーって、違うか。 gb2312なのに日本語で書かれたスパムを受け取ったこと無いかい？
ksx1001にも日本の文字は含まれている。 あれってなんでなん？
何か使い道あったん？
使わないけど精々100文字程度だから入れとくかーぐらいのこと？ 韓国は日本に併合された状態が30年以上続いてたわけで、その間に日本の文字が広まったんだろ
ksx1001制定時にも使われてたから入れたんじゃないか？ 平仮名と片仮名のワ行のウ、片仮名のヤ行のイ、片仮名のヤ行のエ(現代のエと区別する為に作られたイとエが合体したような字)
も追加されたんだな。 わ行は
ゐゑ
ヰヱ
や行のエ？
イとエの合体ってどんな字？ いや変体仮名と同じKana Extended-Aに押し込まれただけであって変体仮名扱いではない
主流の文字と重複した仮名のことを変体仮名って言ってるわけだから
既登録のやつとかぶってないYI/YE/WUはただの仮名 越後とか会津あたりの、いとえが混ざった奴を表す平仮名はないの？
鉛筆がインピツになったり駅がイキになったりするやつ WU は見たことあるけどカタカナの YE とか YI って実例があるんだろうか？ どの漢字由来か見当がつかない。 Hentaiganaとはちゃんと区別されてHistoric Hiragana/Katakanaなんだな。 Wikipediaによると片仮名のヤ行イは「以」に由来、ヤ行エは「延」に由来するらしい。
ヤ行エは現代のエと同じ、ア行の方が違う形でU+1B000の「衣」に由来する字としてた事もあるらしい。
平仮名のヤ行イは「以」を崩した字でU+1B006,HENTAIGANA LETTER I-1と統合っぽい。 歴史文脈以外での使い方を考えよう
ウェーイ → ヱーイ
みたいに
イエーイに使えるか？ 恵比寿
戎
恵比須
蛭子
夷
胡
どれが由来だろう 変体仮名が思うより変態で感心した。
私はくせ字だが日記を始め手書きも多く残すつもりだから、
遠い未来に自分のくせ字がひとつでも加わればこれ以上ない喜びだな。 元字が同じただの癖字じゃ無理だろｗ
それより慶応を广K广Oと書くようなやつのほうがよっぽど収録しがいがある 葬祭の下側がアルファベットになってて
艹
死 タヌ
SO SAI
みたいなやつを見かけたことがあるんだけど
これもう文字じゃなくてロゴタイプじゃねと思った 新しい絵文字出てもAndroidのバージョン古いと見れないのつらいわー
フォントだけなんだから絵文字だけ別枠で配信してくれないかしら >>183
>フォントだけなんだから
そいつはどうかな そういやandroidはフォント入れ替えたり足したりできないのかな？ 字形なんて個人の好みに過ぎんよそでやれ（ 文字コード原理主義） そそ
僕らは直が線対称だったり刃が切れなそうだったり反がハーイしそうでも気にならんよな？ >>192
CJK 漢字統合の悪い後遺症なんですが、なんで CJK 漢字統合とかやってしまったの？ でも統合しなかったらしなかったで
「見た目同じだけど検索に引っかからない文字」
がOCRとか素人入力とかで大量に使われてそれはそれでアレだったんだろうなあ >>194
黄色い猿の使ってる文字の区別なんかできねーよ
ということだろう 漢字をあいまい検索するなら同義文字のデータベースを別途用意するのが正しい
CJK漢字統合では中途半端
バイオリンとヴァイオリンのように漢字に限らない問題だし 正しいのはわかるが未だに
サンプル
ｻﾝﾌﾟﾙ
みたいなのさえ余裕で同一視してくれないやつ多いしなあ
統合なしだと現状と同レベルの利便性は特別な投資をしないと享受できないものになってた気がするんだよな ジャパニーズ絵文字をユニコードに入れまくったのは性犯罪と言える。
反省せよ！ >>194
CJK別にすると16bitに収まらなかったから
けどそんなことはもう問題になってない
32bitで扱わないといけないのみんな知ってるし
外部表現はUTF-8だし >>195
そういう目的のためにCJK統合されたわけじゃない
だから役には立たない
そもそも新字旧字さえ同一文字とみなさないCJK統合文字の同一視を嬉しい奴なんか居ない >>200
世界統一基準のルールでやろうとすると実績ベースでやるしかない
Gmailの中の人が日本のキャリア携帯メールの絵文字対応する時に
Google独自の他社非互換の対応をするのではなくて標準に入れたのは英断
数千万人が使ってる文字の流通基盤作った ヴィトンとゔぃとんをあいまい検索で同キーワード扱いするにはMecabのような分かちライブラリが必要になる Mecab用の新語辞書mecab-ipadic-NEologdの更新が2020年9月で止まってる
https://github.com/neologd/mecab-ipadic-neologd システムが英語設定のときに日本語を表示させると、中国語の字形で表示される
ことが多い気がする。Google先生に日本語の漢字を入力して検索しても、中国語の記事が
優先して出てくるような。
これはどういうことなんだ.... 前半について言えば、日本語環境以外では中文フォントが優先利用されるようになっているからだろう。 中国人が天安門事件についてググりやすくするための配慮だろjk 中国語って言っても繁体字でしょ？
フォールバック先としては適切では？ 「直」とかが明らかに日中で形が違うのに同じコードポイントなのが問題で、誤字にしか見えない
許容範囲は「今」くらいまで もはや「安」と「あ」を同じ文字だって言ってるレベルだもんな 形の問題で論じるとaとかgとかのバリエーションと同列の「字形が違うだけ」になってしまうような >>213
日本語において「令」の書き方が複数あるのは、どちらも使われていて同じものと認識されているから、字形が違うで済むし同じコードポイントで良い。aやgのバリエーションの違いに相当。
しかし中国語の「直」の字形は日本ではあまり一般的ではなく、同じものと認識できない可能性が高いから別にすべき。由来が同じでもすでに別物で、pとπのようなもの。
どこまでを同じものと認識するかは言語や文化が違えば当然異なるから、やはり統合漢字は無理がある。
もっと言えば、トルコ語アルファベットの大文字小文字の扱いや、全角半角の同一視の問題も根は同じ。
テキスト中に表を書くための罫線素片が全角と半角を統合とかアホとしか言いようがない。 ＞書き方が複数あるのは、どちらも使われていて同じものと認識されているから、字形が違うで済む
それがね、「人の名前を正確に書かないなんて失礼でしょ！」って、包摂されてるレベルの異体字を正確に表現することを求める人、結構いるんです…。
同じものだと認識してる人の範囲、実は案外狭くて、板挟みになってるところにしわ寄せがいってるだけかもしれません…。 >>217
お前の先祖が字をちゃんと覚えて無かっただけだろが
と言ってやりたい >>216
CJK統合が困るならサロゲートペアを使いなさい >>216>>217
異体字が重要なら異体字セレクタを使いなさい
Winのメモ帳、Macのテキストエディット、Adobe Readerでさえ対応してるのだから >>216
どの文字を同じとみなすかは
JIS X 0208の段階でも問題になってきたし
ISO-8859-*でさえ問題だった
応用ごとに同値関係を定義するしかない
たとえば
かちょう
がちょう
は索引で横並びかどうかなど
これは国ごとに応用ごとに違う
この辺りの知識はUnicodeのお陰で劇的に広まった
失敗がなかったなんて極端な事は言わないが
文字処理におけるUnicodeの貢献は大きい
唯一のテストベッド
最近のレスの知識レベルは20年前に戻ったかのようだ >>217
しわ寄せなんてもないですよ
戸籍をデジタル化した時点で
後のUnicodeの文字集合採用ルールに従えば
異体字セレクタで全て扱えるべきですし
そうなっています
典拠がいまだ見つからない文字ですら扱えるべきなんです
どこかでもう使ってるかもしれないから >>221
どゆこと?
サロゲートペアでCJKの字形の使い分けができるってこと? 異体字セレクタ
https://ja.m.wikipedia.org/wiki/%E7%95%B0%E4%BD%93%E5%AD%97%E3%82%BB%E3%83%AC%E3%82%AF%E3%82%BF#:~:text=%E7%95%B0%E4%BD%93%E5%AD%97%E3%82%BB%E3%83%AC%E3%82%AF%E3%82%BF%20(%E8%8B%B1%3A%20Variation,(%E9%81%B8%E6%8A%9E%E5%AD%90)%20%E3%81%A7%E3%81%82%E3%82%8B%E3%80%82 >>224
「かな漢字変換」ならぬ「漢字カナ変換」を開発ωして
年金情報ぶっ壊したのが厚生省ωω >>226
現状では言語によって異なる異体字 (図参照) のようなケースを異体字セレクタで区別することができない。
って書いてあるけど？ IPAの発音記号あたり、中途半端に特定の文字だけ専用に用意するよりIPA専用記号として全部一式きれいに揃えたほうがわかりやすいんじゃないかって思うわ
どこまで普通のラテンを使っていいのか直感的じゃなさすぎてつらい IEコンポーネントブラウザだと絵文字は基本的に白黒で表示されるイメージだったけど、
一部の絵文字はフルカラーになるのね。何が違うんだろう？
なんとなく、追加時期が新しいものがフルカラーになってそうなイメージ。
Unicode 6 😂
Unicode 7 🙂
Unicode 8 🤗
Unicode 9 🤧
Unicode 10 🤮
Unicode 11 🥺
Unicode 12 🥱
Unicode 13 🥲 >>231だと7まで白黒で8からフルカラーに見える >>231
こっちではこう表示されているよ。Windows10のPCでjaneStyleで見ている。
https://imgur.com/McdjAOh Chrome ブラウザだと顔文字が出るな。フルカラー。スマホの Android の ChMate でも同じ。
但しPCの方は Unicode 13 が□で出ている。インストールされているフォントの問題かな。 フォントとフォントのレンダリングライブラリ（含Unicodeの処理）的な >>231
PC版Firefox 93、PaleMoonだとおk、
古いFirefox45だとコード番号のある□
PC版Chrome、Edge、絵文字プラグインを入れたJaneStyleだと、Unicode 13（一番下）は□
Edgeがダメとか、MS終わってるだろw
ちなみに、この文字はこれな
🥲 Smiling Face with Tear Emoji
https://emojipedia.org/smiling-face-with-tear/ >>237
全部Unicode 13（>>231 一番下）の文字の話ね Firefox系では、TwemojiMozilla.ttf というフォントファイルで表示しているようだ
古いFirefoxにもこれをインストールしたら表示できたけど、その他は相変わらずダメだった
何か他の要因があるのか？ >>236 および >>231 で表示できてる≒そのUnicodeバージョンに対応している
で説明できる感じ? 昔はEmojiOneMozilla.ttfだったのに IEってかTridentは今後どうなるんだろう
新絵文字対応は更新され続けるのかな >>237
フォント指定したらwin10 edgeでもちゃんと表示できてるぞ
文字コードスレなんだからそのくらい試そうぜ 今は正しいフォントを指定してない場合にも表示可能なフォントがあれば自動で代替フォントで
表示するようになってるのが多いけどね。Win 10の特定のアプリ/APIでは違うということかな。 絵文字系のフォントを指定すれば表示できたとしても
普通の文字はどうするんだ、ということになるな ほんとだ、フォントデベロッパーって（別にシャレのつもりはない）
まあフォントのデザイナーではないだろうから、Notoみたいに各言語のグリフが統合されたような
フォントセットを作るぞーとかそんなノリ? Windows11 で(一部の)設定ファイル等が BOM無しUTF-8に変わったみたいな話が聞こえてきてるけど、文字コードまわりはどんな感じ？
お前のマシンは古すぎるので11は無理っていわれて試せないので誰か教えて。 \rはPowerShellの複数行コマンド履歴を履歴ファイルConsoleHost_history.txtに保持するために必要だよ
ConsoleHost_history.txtはWindows10でもBOM無しUTF-8だよ
Powershellを開いて explorer /select,(Get-PSReadLineOption).HistorySavePath で見つかるはず 厳密に言うと、(Get-PSReadLineOption).HistorySavePathでは普通の改行は\r\nで複数行にまたがる時に\nが使われている
\rがあればこそできる使い分け ConsoleHost_history.txt は CRLF だったが
\r を無くせってのは単独の CR を無くせって意味か？ ネットワークプロトコルの世界ではCRLF（\r\n）だから、
改行コードが統一されることはないだろうな ㏍という組文字がすっかり今までと違う使われ方されるようになったンだわ 「ヒモを育てる」(紐育)と書いてニューヨークと読む test
[🏳🌈] F09F8FB3 EFB88F E2808D F09F8C88 (Rainbow Flag)
[🏳] F09F8FB3 (U+1F3F3 Flag)
[VS-16] EFB88F (U+FE0F Variation Selector)
[ZWJ] E2808D (U+200D ZERO Width Joiner)
[🌈] F09F8C88 (U+1F308 Rainbow) >>263
winny や share で exe ファイルを踏ませるために共有するファイルのファイル名に小細工をするやり方として10年前には流行っていたやり方ですね
パクリ論文もいいところ、ケンブリッジも堕ちたものですねえ… 具体的な手法が各言語にはどのように適用できて、どのエディターが是弱で、どのエディターが対策できてるか、とかはちゃんとした研究だと思うが？
ニュース記事とかはどこが新規なのか曖昧にして、注目を集めたりするので中身を追いかけないと。 初めて正しい情報に遭遇した気がする
https://onihusube.hatenaぶろぐ.com/entry/2020/04/03/211442 Mecab用の新語辞書mecab-ipadic-NEologdを使ってるンだが、mecabコマンドを-Oyomi オプションつきで呼ぶと、komuroが「コームロコーポレーション」に変換されて困るンだわ komuroが以下のように解析されてしまうンだわ
ko 名詞,固有名詞,人名,一般,*,*,ko,コー,コー
muro 名詞,固有名詞,組織,*,*,*,ムロコーポレーション,ムロコーポレーション,ムロコーポレーション >>271
辞書を自分で編集したらいいんじゃないの? >>273
無論、英語力は話すまでもない
とっくにしてるンだわ
komuroのほかにもC++のキーワード「iostream」が「ioストリーム」と変換されたりとか色々厄介なンだわ フォルダを意味する絵文字とファイルを意味する絵文字があれば味気ないlsコマンドが少しはにぎやかになると思うんだ >>276
コマンドラインの出力に emoji 使うのは迷惑極まるのでやめろ。そんなやつは素直にGUIでも使ってろ。 最近は絵文字使うコマンドラインツールが増えてきた気がする。特にmac
確かに見やすいし仮に表示できなくても豆腐が見えるだけだし別にいいんじゃね
Net-Unicode規格？に従ってるかはよくわからん ふと気付いたが豆腐そのものの絵文字ってないんだな
グリフがない文字の通称、あるいはtofu on fireと、豆腐と文字コードは縁が深いのに ANSI Colorによる強調を使わずに絵文字による強調を使うのが主流になっていきそうな気がするよ
例えば、ビルドログのエラーをパイプリダイレクト先でも強調したい時に気軽に使える
⛔ build failed 以下の文字は、とりあえず色付き絵文字で注目させたい時に使えそう
🔴 🔵 🔶 🔷 🔸 🔹 🟠 🟡 🟢 🟣 🟤 🟥 🟦 🟧 🟨 🟩 🟪 🟫 >>280
notoは名前変えなきゃいけなくなるじゃん 一私企業が文字コードを独占利用するなんて横暴だ
〠
🚅
㍾ 〄
↑これ永遠にこのまま変わらないのかね ✅ Build Success
💯 Build Success
絵文字の意味よりも色が重要かも 💮 WHITE FLOWER (U+1F4AE)は、macOSとiOSの場合「大変よくできました」って日本語が縦書きされてるんだよな >>292
元の絵文字は「花丸」だった。赤ペンでぐるぐる丸を書く感じの。
Mac上でグリフがデザインされたとき、やや拡大解釈気味に「大変よくできました」の花の
スタンプになった。
その後他社はこれに引きずられたのか、赤線で花のイラストにした。結局Unicodeの名前も
White Flowerになってしまった。
これとおんなじかと https://youtu.be/8guQ43WGcjQ?t=268 ゆうて鉄砲が水鉄砲になるみたいなのもあるからな
規格がどうだろうと大手がこぞって無視したらそうなってしまうのな 読み手に色で注目を促したいだけならANSI Colorみたいに文字列そのものの色を変える必要ないんだよな
文字列の手前に色付き絵文字を配置するだけでも同じ効果があるので、例えば重要な情報がログが埋もれてしまうのを緩和できる https://emojipedia.org/white-flower/ の記述を信じると「大変よくできました」が
入っているデザインがMSも含めて半分ぐらいあるけど、自分のWin10で軽く試すと
花の真ん中はただの点々だなあ。 >>296
今時のテキストエディタは絵文字ちゃんと表示できるし、その方向はいいなあ 以前ログを何かのチャット経由で送ってもらったら、勝手に絵文字に変換するフィルターが
かかっていたようで、えらいことになってた
たとえばdebugという文字列が虫の絵になってたりして、面白くてログの内容が入ってこなかった 大昔ここでもそういうやつの話題見たことあるな
Webフォントで、絵文字に対応する英単語ごとに複数文字の合字として入ってるの
やっぱ弊害のほうが大きいよな 勝手に置換するのが問題であって絵文字は関係ないがな 絵文字を使ったログというのはこういうやつかな
ttps://spin.atomicobject.com/2019/10/15/faster-debugging-emoji/ 端末の文字列を色付けする従来のANSI Colorだとパイプやリダイレクトや画面テキストコピペで情報が失われてしまうけど
絵文字だと情報が失われない利点がある Visual Studioでビルドしてると単色テキストでログが画面に出力されるんだけど、
コマンドプロンプトとかでmsbuild使ってビルドするとテキストが色分けされているのがわかる。
何が言いたいかというと、Visual Studioでさえログから色情報が捨てられて、もったいないことになっているよ、という話 絵文字か... めんどくさい。
文字コードが実質統一されたことで文字化けは減ったかも知れんが、絵文字を下手に触って
文字化け（絵化け?）する場合がありそう。 >>306
絵文字は実害が出る前に国際化未対応の不具合を見つけるのに役立ってきたよ
ま、絵文字が化けることそれ自体が実害だというなら実害なのかもしれんが
🛠工事中
🛠工事中 なるほど。まあ国際化というか正しいUnicodeの扱い方? のような気もするが。
え、Unicodeを使うこと＝国際化だって? あとはやたら中立を求めてくるやつ? 文化ガーとか
肌の色ガーとか性別ガーとか。
しかし、単に「工事中」と言っても含まれるメッセージには「工事中だから入ってくんな」とか
「工事中なので待っててね）」とかがあるような。
それは後者かな。IDEとかでありがちな。前者は日本由来の🚧はどうでしょう。 ま確かに最近はいかにICUを正しく使うかみたいな感じはある... 自分の界隈では Windows10だとU+1F6E0とU+FE0Fの連続で以下画像と似た絵文字が表示されるはず
https://uc-emoji.azureedge.net/orig/18/83d86f5c30039ddf01bcb271f219a2.png
2chの挙動なんか怪しい、とりあえず
🛠 U+1F6E0(ハンマーとレンチ) U+FE0F(バリエーションセレクター16) の組み合わせでハンマーとレンチ絵文字を表示するテスト
🛠 再現した
どうも5ch(2chじゃなかった)に投稿する時にU+FE0F(バリエーションセレクター16)が捨てられてしまうようだ 以下サイトは、U+FE0F(バリエーションセレクター16が付随したハンマーとレンチの絵文字をクリップボードにコピーできる
https://emojigraph.org/ja/hammer-and-wrench/
ちなみにWindows10標準機能の「Win+.(ドット)」ショートカットキーで利用可能な絵文字パッドで選択できるハンマーとレンチは、なぜかU+FE0Fが捨てられた状態で取得される >>314
macOSやiOSの場合は、U+FE0Fなしでも色付き絵文字として見かけ上まったく同じに表示されるので区別がつきにくいね AndroidもmacOS,iOSと同じく「バリエーションセレクター16」なしでも「ハンマーとレンチ」を色付き表示できている
「バリエーションセレクター16」の有無で「ハンマーとレンチ」の表示が異なることを確認できているのはWindows10のみ
他のOSは手元にないのでわからない >>315
ちな逆にVS15(U+FE0E)でテキストスタイルにできるけど、これはならないな、俺環では。
これに関しては絵文字でしか持っていないということかな?
テキストスタイルで持ってるフォントをインストールしたら違うとか。 >>280
豆腐のグリフはあるからいいんじゃないですか 色付き絵文字のデザインは各ベンダーが独自性にこだわってくれても構わないんだが、
色付き絵文字になるかどうかの規則性だけは統一してほしい OSベンダーとは別にFireFoxなどWebブラウザベンダーも独自に絵文字対応しており、以下の文字列が国旗で表示される
🇦🇨 🇦🇩 🇦🇪 🇦🇫 🇦🇬 🇦🇮 🇦🇱 🇦🇲 Windowsシステムでの国旗の絵文字はアルファベットで示すのはなぜ？
https://www.emojiall.com/ja/blog/321
すべての「国」が国際的に承認されるわけではなく、地域の旗も公式と非公式に分ける場合があります。Microsoftは国際テック企業として、政治的な問題や紛争を避けるため、いっそそれらの旗の絵文字を地域インジケーターシンボルで表示すると決定しました。 >>304
vscodeに関しては知らんけど、コンソールへ出力吐いたりフィルタ的なプログラムは大体オプションで選べるようになってるはず
出力先がターミナルならスルーして、それ以外なら落とすのがデフォルト動作であることが多い なんか下位区分の地域コードってイギリスだけなん？
日本の都道府県も使えるようになれば神奈川県旗とかいろいろ使い勝手がよさそうだと思うんだけど シクロヘキサノール置いときますね
⎔-OH
⬡-OH 🎍あけましておめでとうございます🎍
意外と鏡餅の絵文字ってないのですね🤔 お正月 絵文字
https://lets-emoji.com/newyear-emoji/
このページには凧が書いてないな(正月に限ったものではないが)。
U+1FA81 が凧ね。
鏡餅と独楽はUnicodeにないので欲しいところだ。 絵文字でやたら日本ぽいものは一番最初のときに入ったやつだろうなあ。
めんことか、ローカル文化的な絵文字を入れるのは今ってどうなんだろう。
そういえばベーゴマは形を変えベイブレードという名前になりアニメ化され
日本以外にも広まりつつあるので、いつか絵文字になる可能性が?? 何せUnicodeの絵文字の名前は日本語読みの emoji だもんな。英語圏ではちょっと誤解されてるようではあるが。
https://youpouch.com/2017/06/20/440108/ オフィス系アプリでフィルタの意味で使われることが多い漏斗の絵文字があってもよさそうなのにないね、漏斗 💾を「保存」メニューで見ても意味不明のまま使っている人も多いんだろうなあ。
他にもあるだろうか。 インスタントコーヒーしか飲まない人にはわからない、と。 理科の実験でろ過やるでしょ
今どきのナウなヤングは、やらないの？ >>341
ちょっと話それるけど小中学生ぐらいの頃ずっと
「ダイアログ」は「選択肢がある小さいウィンドウ」、
「ウィザード」は「順番に設定させる仕組み」を表す英語なんだと思ってたわ もしかして日本ってもうIRGの会議に参加してない？
https://appsrv.cse.cuhk.edu.hk/~irg/irg/irg58/IRG58.htm
去年はActivity Report用に割り当てられた文書番号IRGN2455は結局使われずじまい
今年は番号割り当て自体がされていない状態 でもutf8には冗長コードの問題があるから内部処理コードには向いてな 互換漢字とか合成順序とかあるので重複コーディングがあるといえばある。規格を正しく運用すれば対応できる（例外あり）
一方でUTF8も規格が改定されて最短表現のみが正当とされることになったので、規格を正しく運用すれば対応できる。 やがてストレージはPB単位が普通になりメインメモリはTBが当たり前になると、1文字が4バイトでも誰も気にしなくなる。
その時組み込み用の小さいマイコンはメモリがGB単位。SSDのストレージがTB単位。32TBで800円ぐらい。 >>353
当分の間は問題化しないというだけであり、理論上は問題がある
time_t型が64bitになったことで桁あふれが起きる時期が先送りされたのと似た問題 >>357
Unicodeコードポイントの最大値は未来永劫U+10FFFFであると定められているので
32bitで足りなくなることはあり得ない。 未来永劫ではなく現時点でしょ
未来なんて誰にもわからない
👽地球外生命体とコンタクトすれば全人類だけではなく地球外生命体の文字コードも網羅しなければならなくなる UTF-32の話をしているのにバカな事言わないで貰えますか？ コンソーシアムがとち狂って個人のポートレートや企業ロゴを文字コードに採用したらあっという間に枯渇できる 過去・現在・未来の人類ひとりひとりに固有Unicode文字を割り当てたらあっという間に枯渇できるから安心してほしい
つまり歴代天皇や君も僕も人柱だ やがて emoji に埋め尽くされ32bitでは足りなくなる すべての人がUTF文字コードとして記録されていくなんてすばらしいじゃないか
お墓いらずだ Unicodeが共同墓地として利用される日が来ないと言い切れるか？ 👱🏿♀
すでに32bitに収まってないやんけ
フルカラー&ゲーミング肌色も遠くないかもねー vimにcocプラグイン入れて:CocUpdateコマンド使うと、
以下のような点字図形文字を使った待機アニメーションが出力されるね
⠇⠋⠙⠸⠴⠦
なるほど上手いなと思ったんだけど、既知？ マルチプラットフォームなツールなのにMac版だけ点字クルクルアニメなのを見た気がする。何だったかな U+2572を使えばMSゴシックなどバックスラッシュが円マークで表示されるフォントでもそれらしく表示できるので以下のように待機アニメーションが可能
╲|/- あー思い出した、日本ファルコムの「ザナドゥ」って名前の昔のPCゲームで魔法Needleがまさに >>378 だった
魔法の描画が特殊な文字フォントとして表示される不思議なゲームだった ゲームは独自文字コードの話なんかがあるとわくわくしちゃう TeraTerm でフォントを MSゴシックにして送受信UTF-8にして LANG=ja_JP.UTF-8 になっている Linux から
perl -e 'binmode STDOUT,":utf8";print "\x{2572}\n"'
をやったら "?" が出た。
TeraTerm いまいちだな。 記憶補正されてたみたいなので修正。ニードルの描画はバーティカルバーとハイフンを使わない。
╲/のみ。以下が実際のゲーム画面
[PC-88] Dragon Slayer II - Xanadu (1985) (Nihon Falcom)
https://youtu.be/QcQpec98nCA?t=397 Tera Pad も、新し目の文字には対応していない
だから漏れは、サクラエディタに移行した 今日日Windows標準アプリのメモ帳(notepad.exe)でさえ╲を表示できるというのに デバッグ機能をもちいてnppを開くようにしているので、
メモ帳を見ることもない（できない） >>389
Oracleになって一瞬でオワコンになったねOOo。 今日の某クイズ系YouTuberの問題。
俺らなら朝飯前だよな？
U+25CBは何の記号？ >>383
＞Tera Pad も、新し目の文字には対応していない
あれは新しい文字とかの区分でなく表示の仕様上の理由で使えるフォントが制限されてるだけ
テキストエディタの使い勝手の思想そのものが古いツール >>398
スーパーとかのレシートに書かれてる品目名もそういう後方互換性で半角になってるの？ 半角カタカナって意味でしょ
>>401 は行間読めない人？ HALFWIDTH KATAKANAって半角じゃないの それ全銀とは別の、HALFWIDTHとFULLWIDTHの両方を含んでる規格の話じゃね？ >>400
どうなんだろうね
幅が半分で長い名前を表示ときに便利ということで使われてるほうが多いんじゃないかな
数字も個々の商品の価格は半角、合計額は全角で表示してたり 国際化意識してない日本語環境においては、
表示、印字された日本語を見て全角とか半角になってるとか言うのは特におかしいことはないよ
JIS規格（「日本語文書の組版方法」）上、正しい表現 文字コードとフォントの違いがわかってないやつが多いな。 >>408
例えば「小田急線に乗りたい」と息子が言ったとする。そしていざ、小田急線のホームにつくと「違う」と言い出し、乗ろうとしない。よくよく聞いてみると息子の希望は、「小田急3000型の急行小田原行きに、新宿から小田原まで乗りたい」ということだったりする。
わかるかぁ！と思ったのを思い出した >>403
規格にもhalfwidthあるじゃん
明らかに半角からとった名前だしそれを半角と呼ぶのはおかしくないだろ 半角二次元っていう板があるから
そこで聞いてくるといいよ >>406
近所のコンビニのレシートでは所在地に全角数字、電話番号に半角数字が使われ
ドラッグストアのレシートでは所在地に半角数字、電話番号に全角数字が使われてる >>411
半角という一つの言葉にhalf widthって訳語を当てたんだろ 「半角」は元々は活字の半分の面積を意味する印刷業界用語だよ 活字における四角形の4つの角すべてを使用するから全角 C勉強初心者なのだが文字コードの壁にぶち当たった
日本語使わなきゃいいだけなんだろうが例題は原文が日本語だし
それを英語に直して打ち込んで、出力結果の確認も英語でやるとかしんどすぎる 間違ってC++相談室スレに書き込んでしまったので改めて書き込む
半角全角使うな厨が絶滅しますように (AA略 >>420
そうです。英語があまり得意ではありません。
日本語の入門書で学習しているのですが、その本が特に開発環境を指定しておらず、
自分が準備した開発環境(エディタがShift-JISらしいです)で例題を打ち込むと問題が起こります。
特定の文字に対処する方法はあるようなのですが、環境を変えて根本的な解決ができないか、と調べておりましたが、
そちらも色々ややこしそうで、結局全部英語でやらなきゃいけないのかなぁ、と。 半角カナ使う人に理由をきいてみたら、1バイトでもファイルサイズを減らすためと言われたのには色々驚いた
ちなみに文字コードはUTF-8 >>422
真っ当なエディタ使え
フリーでいいものがいくらでもあるぞ >>425
ありがとうございます。
もう少し調べて設定を変えてみたら、作成済のexeファイル起動したときコマンドプロンプトで文字化けが起こったので、今のままじゃ対応できなさそうな感じです。
世の中の全ソフトがUTFなら問題は起こらないんだろうなあ。 CP932 とか、ファイルパスにUTF-16 ？ とか使っているのは、Windows だけでしょ？
Linux は、UTF-8 で統一されている
全言語はLinux用
Windows用言語は、C# のみ。
特殊なのは、Windows用のネイティブアプリを作る場合だけ。
普通にウェブ開発する場合は、Linux。
サーバー・クラウド・Docker も、すべてLinuxだから
開発者がLinuxしかいない。
それでWindowsでも、WSL2 でLinuxが使えるようにした 真面目にやりたいならwindowsしか持ってないってのはまずいってわけか
初心者向けの学習ならごまかしつつ進められるところはあるのかもしれないが >>400
レシートに印字できる文字数やレジに登録できる文字数に制限がある
全角で表示しきれればいいけどだいたい足りないので半角で登録する
店舗名や住所などは３行とか４行表示できたりするのでスペース文字とかで調整して印字させたりした
１０年ぐらい前の話だけどな Shift JISであればWindowsのコマンドプロンプトで文字化けはしない
全てが文字化けするのか"表"のように特定の文字だけ化けるのか
コンパイラは何を使っているのか等々もう少し詳しく書かないとわからん WSL2, Ubuntu 18.04 で、Ruby の1-liner なら、これで日本語文字列が表示される。
ファイルパスに日本語が含まれていても、WSL2 が変換して正常に処理される
/mnt/c は、Windows 側のCドライブ
chomp で末尾の改行を削除して、1行ずつ処理する。
:encoding "extenc:intenc" の形で、外部/内部エンコーディングを指定する
ファイルがUTF-8 の場合
ruby -e 'File.foreach( "/mnt/c/Users/Owner/Documents/ファイル.txt", chomp: true ) { |line| puts line; break }'
ファイルがCP932 の場合
ruby -e 'File.foreach( "/mnt/c/Users/Owner/Documents/ファイル.txt", encoding: "CP932:UTF-8", chomp: true ) { |line| puts line; break }' >>430
特定の文字だけアウトです
本格的なのは別にあるのは知ってますが勉強用なら見やすいのがいいかなと思ってEasyIDECで始めたのでコンパイラはTinyCかと思います
対策調べてたらShiftJISで書くのがそもそもの間違いみたいな話があり困っておりました Windows 専用の環境依存文字じゃないの？
①、丸で囲まれた1とか、
髙、はしご高とか
CP932 の文字かも。
たぶん、sjis に含まれていないのかも
Shift_JIS, CP932(Windows-31J)の違いを調べてみれば？ >>432
多分ダメ文字だね
ソ噂浬欺圭構蚕十申曾箪貼能表暴予禄兔喀媾彌拿杤歃濬畚秉綵臀藹觸軆鐔饅鷭
は2byte目が0x5cなのでエスケープ文字と誤認識して文字化けする
ダメ文字の後に半角￥を入れることで回避はできる
printf("表\示");
Borland C++のフリーの日本語版はもう手に入らないんだっけ 開発環境はVisual Studio Community使えば良いのでは あとはソースをUTF-8で編集してビルドしてコマンドプロンプトでchcp 65001としてUTF-8に切り替えてから実行するとか
コマンドプロンプトのフォントはMSゴシックとかにしておいた方がいいと思う ありがとうございます
色々考えた結果学習は>>434の方法で続けてみることにします >>434の方法でも同じエラーが発生する
Shift-JISがゴミであることが分かった
コマンドプロンプトからいじるの面倒だしPC買い直す余裕ないしプログラム学習おわり PC買い直す必要まではないのか
しかし先が思いやられるのでプログラム学習はやめにするよ
特に目標があったわけでもないし
ありがとう SJISのような日本ローカルのキャラクタセットを外国が意識してくれると思っている方がおかしい。 それはそうなんだが英語力を専門書読めるレベルに上げるなんて今更無理
日本語を母語として20年生きてきた普通の人がプログラミングやるなんて無理なんじゃない？ 全てを英語で学習するのが最良なのは間違いなさそうだが
全ての日本人プログラマーがそうしてる訳ではないよな？
どこかに道はあるような気はするが…もうどうでもいいわ OSがwindowsで設定言語が日本語なのでどこかで詰むのではないかと不安 ダメ文字って、20～30年前の話じゃないの？
sjis が鬼門だから、日本人開発者は皆、Mac を使う。
プログラミング学校もMac限定
Windows 10 Home 版で、
VSCode, WSL2, Linux, Docker Desktop などが出来たのは、ここ2～3年
これでようやく、WindowsがMacと争えるようになった
Microsoft がLinux技術者を大量に採用して、WindowsからLinuxへ移行したから >>427
に書いたけど、全言語がBOM無しUTF-8 で、Linux 用
だから、これ以外の物がダメ。
つまり、Windows と、sjis がダメ
クラウドのすべての基幹技術が、Docker で、
AWS, Kubernetes, CircleCI などで使われている。
DockerはLinux の技術だから、
Microsoft も、Linux Foundation に入っている
Linuxを使わないと、インターネット・コンピューターが動かない ・日本語でプログラミングの勉強しようと思ったら基本的にwindowsは使ってはいけない
・ここ数年はwindowsでもやれないことはない
ってこと？
とはいえ未だにコマンドプロンプトは良くなさそうだし学習ストップが無難か 自分みたいな年寄りはともかく、家にwindowsしかない普通の家庭の子どもが何かのきっかけでプログラミングに興味を持ったとき、そこから先に進む可能性を閉ざしてしまうのが日本ってことになるな 日本語で得られる範囲は対したことが無いので、将来への不安とか考えなくても良いよ プログラミングの勉強する前に英語の勉強しろってことだな
手遅れ感が否めないけど すべてのシステムは、インターネット・クラウドにあるから、
それを作っているのがLinux なので、全言語はLinux用に作ってある。
だから、全言語BOM無しUTF-8 を使っている
Windows(C#), iPhone(Swift), Android(Dart)など各端末用の言語は、特殊な部類
特にWindowsは、sjis 正確にはCP932 を使っていて、
こういうエンコードを知っている外人は、まずいない
だから、外人が作ったUTF-8, Linux用のコードを、
Windows用にコンパイルしても、日本語でバグる
だから、Ruby on Rails でも、Cloud 9 でクラウド開発するか、Mac を使う。
プログラミング学校もそう
YouTube のRailsの動画でも、
Windows 10, VSCode, WSL2, Linux, Docker Desktop などは、つい最近 Microsoft(MS)のCEO・バルマーが「Linux はガン」と言って毛嫌いしていたけど、
すべてのシステムがクラウド・Linux へ移行して、世の中に取り残されてしまった
MSに残ったのは、Office だけ
それで、MSはLinux技術者を大量に雇い、
Linux Foundation にも入って、Linuxに貢献することにした
それと取り残されているのが、CP932。
世界はUTF-8になっている バルマーって昔壇上で叫んでた変なおっさんか
それはともかく
自分が英語できなさすぎるからかも知れんがMacのUI苦手でな…
もし学習するなら普段使い用とはPC自体分けたほうが良いのかもしれんな
そんな金はないが Ruby on Rails みたいなウェブ開発は、Linux だから、
Cloud 9 みたいなクラウド開発を勧められる
ローカルPC なら、Mac 上に、Virtual Box でLinuxを入れる。
どこのプログラミング学校でもそう
Windows 10 Home, VSCode, WSL2, Linux, Docker Desktop は、つい最近
ローカル開発では、Mac/Windows上に、Linuxを入れるから、
2つのOS が動くから、メモリ16GB 以上は欲しい。
32GBが推奨
初心者は必ず、Linux, Dockerを学ぶ
Windows(C#), iPhone(Swift), Android(Dart)など各端末用の言語・アプリは、特殊な部類 1990年に補助漢字が制定されたときに
シフトJISを置き換えようとする動きは全く無かったのかな >>458
当時は無かった。PCにもプリンターにも漢字ROMとか積んでたような時代なのでコストに合わないと思われたのかもしれん。
ちなみに DOS/V は補助漢字と同じ年、1990年の年末に登場。 >>439
同じエラーって具体的にどんなエラーが出てるの？
でダメ文字の所で出るのかね
上にも書いてる人がいるけどかなりの初心者っぽいのでVisualStudioCommunity使った方がいいんじゃない
あとC以外の言語から始めた方がいいと思う
あと変な人が力説してますがLinuxの方が敷居が高いですよ
いままでの書き込みみてもLinux入れてターミナルでソース編集してコンパイルまで到達できそうにない
cp932は互換性のために残ってるだけで内部はWindowsNTの時点でUnicodeです
コマンドプロンプトもUTF8に出来るしWindoesTerminalとか出てきてるしメモ帳すらUTF8対応してるというのに >>460
\を入れようが何しようが、ダメ文字入ってるプログラムはコンパイルできませんと言われますね
あとLinuxのターミナルの表示は学生時代に見たことがあって、
ああいうのに首突っ込むのは後でいいのかな、と思った
もっと分かりやすいところから始めようとした
それでEasyIDECなんぞ入れてしまったんですが…
VisualStudioCommunity、Windowsでは一般的らしいですね
全工程でShiftJISが介在しないようにするには色々いじらないといけないらしく
自分のPCで可能なのか問題が起こらないのか調べてみてます ずぶの素人は文字コードのことなんか忘れて素直にVisualStudio使う正道いけば何ら問題ないんだ >>461
ダメ文字ごときでコンパイルできないってのも変な話だね
EazyIDECでざっと検索したけどコンパイラが日本語非対応かつ規格古いからお薦めしないみたいな回答がいくつも出てきたよ
まあVisualStudioがいいんじゃね
基本的に日本語版と銘打っている開発環境であれば文字化けは発生しません
あとプログラム言語の勉強をしたいんであればC言語はやめた方がいいと思う >>454
今のMSの稼ぎ頭はAzureだぞ
まぁ、AzureのVMの半数はLinuxが動いているらしいが >>463
VisualStudioを試してみた結果
問題のプログラムをShift-JISにしたプロジェクトとUTF-8にしたプロジェクトが、両方普通にデバッグ可能なので
VisualStudioの設定がどうなってるのか分からない
というかVisualStudioの各ウィンドウの表示や設定項目の意味が分からない
教科書を先に進めることは可能になりそうなのは良いが、上記問題をどこまで放置して良いのやら…
色々アドバイス頂きありがとうございます。 VisualStudio のマニュアルを読もうという気はないのか? 文字コードスレでやる話じゃない
その程度の判断すら出来ないピーマンに
ドキュメントを読むなんて発想があったら
そっちの方がビックリしてしまう それな
ここはグリフの出来栄えを品評するスレだから 皆さん5月ですよ。
カープストリーマーが多用される季節ですね ＿＿＿＿＿＿
`=､;;;;;,,,,,,,:::,,,,,;;;;;,,,,`""''';;;;,, ､__
,.-'ﾞ''''',='";;;;;;;;",-,,;;;;;;ﾞ;;;;;;;;;l;;;;`,､
／ `ｰ-...,;;;;;;;;;;;;,-‐/;;;;;;';;;;;;;;;;;;
./ `''''''""i;;;;;;;;ヽ
l ■ |,,,____/ |;;;;} カシワモーチ！
| |.:::::/ ■ ﾉ;;;;}
ヽ、 |:::/ _,／;;;'゛
`ヽ､_ |/ _,,.,;‐';;;;゛゛
"'''=ｰ;‐---‐‐'';';"-''"゛
~~~~￣´
-､,,;;;､;;,、
(･∀･ };;) ｶｼﾜﾓｰﾁ! ／＼⌒ヽﾍﾟﾀﾝ
／ ／⌒)ﾉ ﾍﾟﾀﾝ
∧＿∧ ＼ （( ∧＿∧
（； ´Д｀））' ））（・∀・ ；）
/ ⌒ノ （ ⌒ヽ⊂⌒ヽ
.（O ﾉ )￣￣￣(）__ ）
）_）＿） （;;;;;;;;;;;;;;;;;;;）（＿（
＿＿ ＿＿ ＿＿_ ＿＿＿＿＿ ＿＿＿＿_ ___ ___ ___
| | / / | ／/ | /＿＿ __/ [][] ＿| |_| |＿_ _| |_
| |. / / / / / /￣￣|. l / / | ＿ | |_ ﾚ'~￣|
| | / / / / / /. ／ / | |___ ￣| | / / / ／| |
| | / / / / / ￣￣ ／ ＼＿_| | | ￣ /_ / | |_
| |. / / / / / /￣￣￣ |＿| |__| ＼/
| |/ / / /. / /
|. / / / / /
| /. ／ | ./ /
￣￣￣ ￣￣￣. ￣￣ 今、一般的に利用できる技術で詰め込むとして
300dpi 10point くらいのサイズだとマイクロQRコードM4 つかって35バイト当たりが正解か。 媒体は紙でも画面でも木簡だろうと。
一般人の購入・所持してるレベルの普通の技術で、普通の文字サイズの全角文字(縦横比１:1)に情報を入れるとして、どれくらいまで実用的だろうかという考察。 ハレーションてにじみ効果のことなのに、さもすごいことのように使うよね
破裂とハレーションがごっちゃになってるのかな そもそも文字コードに色とか必要？
HTMLとかのプレゼンテーション層でやるべきだろ。 必要でしょ
中央アジアで使われていた紋章タムガもUnicode登録すべきだと思うよ
それなら貴族や大名の家紋も登録しろみたいな話になるかもしれんが、タムガは別 タムガは中国の漢字を元に考案されたという説がある
漢字からして絵文字のようなものだから、絵文字がダメなら漢字もダメだろう
さらに突き詰めれば、漢字を含む表意文字は広義の絵文字だから、表意文字も禁止しなければならなくなる >>489
それは昔のauとjフォンに言ってあげて 色付き絵文字は、従来のANSI Colorのように色情報を捨てられる恐れがないという利点もある
わかりやすい例を挙げると、コピペすると色情報はあっさりと失われたりするけど、絵文字ならその心配がない 絵文字は表意文字の発展形のようなものだと思えば
漢字は特定の物や概念を共通の文字で表現できる、この機能が進展したと 漢字と違うのは、書体がまだ確立されてないところかなあ
00年代の絵文字入りメールを今見るとガラケーでの表示とは別物に見える
今から20年後も、今のiOSやAndroidの絵文字デザインとは別物になってるだろう
アイコンとかのUIパーツは5年ぐらいのスパンで流行が変わっていってるし 漢字の成り立ちを考えたら、絵文字は大幅な退化な気がする そもそも、架空の文字は登録しないとか言ってたのに絵文字はどうなのよ その問いに答えるには「架空の文字」を明確に定義する必要がある ダンサーがオルガになったり汗が射精だったりして
あくまでも絵としか捉えられていないのが現実 文字として使われていなかったものを、勝手に作って文字と強弁して登録した罪。
それが絵文字。
だったら俺もクリンゴン文字とか山田文字とか作って登録できるし、CJK分離漢字も登録できる。 ソビエト連邦旗の☭「鎌と槌」U+262Dがとっくの昔に絵文字登録されているのだから、クリミア・ハン国旗のタムガも絵文字登録されてしかるべき
https://en.wikipedia.org/wiki/Crimean_Khanate >>505
最強ロボ ダイオージャを知らない人にもわかるように書きなよ その界隈の人はクスリとくるジョークなのだろうけど理解できないのがもどかしいな >>507
確かにそうかも
オデッサ作戦が始まる5日前、ブライトに塩の不足を訴え出たのはタムガではなくタムラだし UIのテキストで「情報」を意味する小文字のiに○を使いたいんだけど、
U+1F6C8というのがどうもそれらしい。けどBMPじゃないし文字化けとかするかな?
BMPだとU+24D8がほぼ同じ文字だけど、やっぱ意味的にはU+1F6C8を使うべきかな?
さらにU+2139も"Information Source"という名で、VSのU+FE0Fを付けると四角で囲った
やつになるようだけど、絵文字に頼るのもあれかなあ Tcl/TkはBMP外つまりサロゲートペア領域に対応してないので移植時は要注意 >>509
UIは実はAlexaだったのですが、U+1F6C8を使ってみたら見事にトーフが。ちょっと意外
テキストエンジンは何なんだろう。グリフをあまり持ってないとか?
とりあえずU+24D8は化けないようなのでこれでしのぎます アレクサ 「Echo Showシリーズは、これまで作られた中で最も信頼のおける
スマートスピーカーです。 ミスなどありえません。」 いつの間にか全板で絵文字(や他のUnicode文字)が書き込めるようになってたのね 文字コードがSJISなので文字化けしてたってだけで、禁止されていたわけではなかったような >>530
SETTING.TXTでBBS_UNICODE=changeと指定されてる板はサーバが同じでも絵文字使えなかったんだよ
今はこの設定が無視されてるみたい どの板でもスレタイに絵文字入れれるのかな
絵文字入ってるとかわいいよね 文字コードスレなんだから文字コードだろ
文字コードU+1F9AA総合スレ 全文字、全単語に絵文字を作って割り当てるとどうなる
よく使われる単語ほどいい絵文字になるようにする 今まで牡蠣の殻開けを何千個もやったけど真珠を見たことはないなあ ・フリーランスに立ちはだかる「常駐」の壁。慣例を打ち壊し、
“テレワーク”案件3割→8割へと成長を遂げた「クラウドテック」の軌跡
・リモートワーク求人専門サイト「プロリモート」がリニューアルオープン、
業務委託契約の求職者と企業をマッチング
・1/3以上が採用につながる高マッチング率、リモートワーク×エンジニア・デザイナー専門の
人材紹介サービス「ReworkerAgent」正式リリース場所からも時間からも自由な働き方を実現！
・『ReWorks（リワークス）』リモートワーク特化型転職サイトとして 3月5日 リニューアル
・副業・兼業マッチングサービス「クラウドリンクス」登録者数2万人突破
中小企業で進む副業人材の採用、96％が継続採用を希望
・フリーランスが活用できる「最大1,000～3,000万円・補助率50%～75%」の
『ものづくり・商業・サービス補助金』とは？概要や条件を解説
・茨城県日立市、県外からの「テレワーク移住者」に最大151万円の助成金
・長野市、市内に移転・事業所設置し、移住することで最大550万円の支援金を支給 絵文字というのは象形文字への先祖返りみたいなものかもしれない
古代においては象形文字は書くのが大変で簡略化されて漢字になったが
その結果抽象的になりネイティブな言語利用者以外には理解しにくいものに
今なら絵文字のままの利用も可能で、ノンネイティブでも意味がわかるようなものに
なったり... しないか 視認性・可読性を無視してやたら細部に拘ってる辺り、象形文字未満だな
並べてみても中々違いが分からないような微妙なのが増えすぎ
子供が落書きを楽しんでる段階に見える まあ漢字でも柿落としみたいなのもあるしわからんもんはわからんよ 絵文字と象形文字は違うものだよ。
象形文字は本物の文字なので意味だけでなく音を兼ね備えてていて、言葉や文章を一意に表現できる。
絵文字は名前に文字って入ってるけど、本物の文字としては不十分で絵文字だけ文章を表現するのは困難。
絵文字は象形文字以前の状態といえる。 少なくとも三大古代文字の漢字、楔形文字、ヒエログリフのいずれも、そして意味が解読できているその他の象形文字も音と意味の両方から作られていることが明らかになっている。 絵文字って漢字かななりアルファベットなりと組み合わせて使うわけだから単独で使えるかで評価する必要はなくない？ ユニコードで文字コードを割り当てられるのは最大何文字で
現在割り当て済みなのは何文字で
どれくらいのペースで増え続けてるの? Unicode - Wikipedia
https://ja.m.wikipedia.org/wiki/Unicode#%E5%90%84%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%81%A8%E3%81%9D%E3%81%AE%E7%89%B9%E5%BE%B4
Unicode14.0(2021.10) - 144,697/1,112,064文字 (登録済み:約13%)
年平均4584文字増えていて、面を考慮せず単純な文字数ベースで考える且つこのままのペースで増え続けると仮定した場合、210年後(2231年)に全領域が埋まる計算になる 未収録のマイナー文字体系が210年後まで続くかっていうとなさそう
絵文字とかもあと10年ぐらいしてめぼしいものが埋まると「もうさすがにいらんやろ」みたいな空気になって新設は細っていくんじゃね 「こんだけ余裕がありゃあ大丈夫だろう」と思ってたものがあっという間に埋まってしまうことは良くある。歴史は繰り返す。 というとどういうのだろうか
①②③④…を(1000000)とかまで登録するとか？ 配色じゃないの
ハートはいろんな色あるけど他はまだ色ないし
あとは肌の色のバリエーションがもっと細かく定義されるようになるとか >>562
UTF-8 がどのように拡張されるのか、それが楽しみですね
さて皆さんの予想は？ >>567
UTF-8 も、どこまでも可変長にできるわけではないですよ、 UTF-8 は同じ方式でバイト数増やすとしたら6バイトまでで、6バイトにした場合は31bitまでしかビット数がない。
(第一バイトが 1111110x、第二バイト以降が 10xxxxxx なので 1+6*5 = 31)
素直にそのままの値を使うとしたら U+7FFFFFFF が限界になる。
幾らなんでもこんだけありゃ大丈夫だろう。
という考えは甘い。 もしものときにはShift_UTF-8みたいなのができるだろ 今の21bitですら使いきれずに持て余しているからあんな糞絵文字ばっかり追加しているわけだろう。 >>569
うっ
UTF-8 を展開した結果を32ビット長に格納しているが足りないのか、痛いところを突かれてしまった 2007年当時の話だけど、毎年1000文字ずつエンコードしていっても
コードポイント使い切るまで800年以上かかるって
http://www.unicode.org/mail-arch/unicode-ml/y2007-m06/0034.html
これ書いた当時は年間944文字ペースで符号化していて文字数は減少傾向とも UTF8だけならUTF16のサロゲート領域がまるまる空きなのでそこを先導バイトに使えば4000倍以上にはできる。
あとはUTF16とUTF32は捨ててUTF64を導入で。 >>575
UTF64の導入か…現時点ではめんどくさくってしかたがないですねえ 先頭のバイトで長さが判別できる特徴を残したいなら長くなるけど、先頭0xFEで12バイト、先頭0xFFで24バイト長とかにすれば、138ビットまで拡張できるな。 >>576
心配するな現時点で今の21ビットが足りなくなる可能性は皆無。使用されている全部の文字を登録しても足りる。
絵文字増やしても個々の違いが判別できなくなるので文字として役に立たなくなるし、新たに創作文字を大量導入とか、単語に文字コード割当とか、アホなことしないと当面埋まることはない。
よし甲骨文字と金文と篆書と隷書の字体やその変化にも個別文字コード割当だとかやれば埋まりそうだが。 U+1D400..U+1D7FFみたいなのが収録されてるんだから
なんか理屈をでっち上げれば、明朝とゴシックと丸ゴシックと教科書体それぞれ3ウェイトずつぐらいはいけるのでは？ 地球外の惑星人の言語が見つかりだしたらあっという間に埋まるだろう >>579
明朝体とゴシック体を丸ごと登録はありえないけど、甲骨文字、金文、篆書あたりの楷書より古い字体は古代文字扱いで丸ごと登録とか、可能性がゼロではないんだよな。
現在の漢字では失われて甲骨・金文にしかない文字とかもあるので。 音が出るコードが U+0007 以外にも沢山作られて・・・ >>582
よし、パパ全ての音階を符号化しちゃうぞ。
といっても半音単位で人間の耳に聞こえる音と楽譜にある長さ全部登録しても余裕そうだが。楽器ごとに別の符号を準備するか？ 日本の変体仮名もマイナー過ぎるもの以外はあらかた登録されことを踏まえると、第三漢字面は甲骨文字等で埋まることになりそう（実際に登録された場合、今後数百年で最後の大規模登録になるはず） どれだけ文字が増えてもASCIIとの互換性は維持しなきゃいけないんだろうなぁ 甲骨文字はまだ研究中できちんと体系化できてなくて、これとあれは同じ文字だと思っていたが実は別の文字だったとか、見た目全然違うけど同じ文字とか、いまだにやってるし、研究者によって意見が違ったりする。
登録するとなるとかなり先になりそう、もしくは見切り発車的に現状の字形の見た目だけで登録するか。 >>562
文字に関しては、時代が進めば解析できていない古代文字がわかるようになるわけではない。
宇宙人が現れないかぎりは、絵文字が増える程度。 可能性としてはフォントごとに文字が登録されることになると収まらなくなるな。 >>589
いや、古代文字の解析はちょっとづつでも進んでるよ。それで埋まったりしないだろうけど。
あとユニコードには意味不明のまま形だけで登録されている古代文字もあるので、解析されてなくても良いという。 >>591
はっきり言ってわからないことはわからない。遠い過去のことを必死に解明しようとなんてしない。 >>595
森とか品とかは日常的に使ってるわけですし 鮮は鱻と羴の組み合わさった漢字、という説もあるようですね 巧言令色鮮し仁
こうげんれいしょくすくなしじん
（「論語‐学而」にみえる孔子の説いたことば）
ことば巧みで表情をとりつくろっている人は、かえって仁の心が欠けているものだの意。 鱼は魚の簡体字のようだが、ソース分離のパティーンなのかな 澁→渋みたいに3つ並んでるやつの下2つを＞＜で省略するのって日本ローカル？ ......🐟............
䲜䲜䲜䲜䲜䲜䲜䲜
䲜䲜䲜䲜䲜䲜䲜䲜 ..凹..凹..凹..凹..
..........凸...... Unicodeバージョン 15.0リリース ―CJKの表意文字など4,489文字が追加
https://gihyo.jp/article/2022/09/unicode15 絵文字の文字数はあまり増えてないけど、合成パターンが派手に増えて、面倒過ぎることに。 絵文字はいいから
歩と香杏桂圭銀全金飛龍角馬王玉
の逆さ文字を登録してほしい >>619
環境によって逆向きにされるかもしれないのはだめじゃない？
逆だと意味がひっくり返るんだから ちゃんと盤面が表示される保証がないといけないですよね >>617
王は逆向きに配置されることはありえません、無駄な仕事ご苦労なことです >>620
確かにそうなんだよね。。。ただ、年次のUnicode規格が社会に浸透していく過渡期には常に付きまとう問題であって異字体に限った話ではないように思える
それと同時に、異字体（少なくとも漢字の異字体）に意味の違いを含めてしまう（意味の違いを見出す運用を前提としてしまう）と問題が生じることのわかりやすいモデルケースでもあるとも思った >>622
古のドラクエで使われた「り」メソッドであって、実は何もしていないという >>624
んなことわかってんだよ、アホンダラ、死ね >>623
異議を唱えます
本来漢字に正字と異字という区別はなく、どの漢字も平等であるべきなんですよ
Unicode はすべての字（letter and character) を収録する、という建前である以上、異字体コレクターの存在自体が自己矛盾と考えます
CJK 漢字統合など、ダメリカ様の都合で決まった醜悪な存在、でも、結局 16 ビットに収まらなかったという体たらくになりましたよね… >>623
未対応で何も表示されないだけならいいのよ
未対応で逆のものが表示されるのは困るのよ 異体字セレクターでも新コードポイントでもフォント作ってくれれば問題ないよ。
それより同じ漢字を複数箇所に登録するのをやめてくれ。基本漢字はあれだけ無理矢理ユニファイしたくせに、その後はチェック甘くて完全に同じ字形が新規登録されることがある。 >>629
もし良ければ、近年の具体例を教えて欲しい 閉て
>>630
どれくらい近年を求めてるのかは知らんが
私が気づいたのは U+3588 と U+439B の（老/口）とか。
これどう見ても同じ漢字を口部と老部に二重登録しただけやろ。
U+29FCE と U+29FD7 の（予鳥）の違いとかもわからん。 >>631
20年以上前に追加された文字同士を例にとって「チェックが甘くて...新規登録されることが"ある"」と表現するのはどうかと思うよ（「あった」ならまだしも...）
当時と現在のチェック体制を事実上同一視した上で「やめてくれ」と懇願する姿勢も同様 >>632
基本漢字とその後って言ってるのに、最近って言いかえるお前の定義ってどうなってるの？
問題は問題だろ、それともお前全チェックして、俺がたまたま気づいたこの2つ以外は問題がないと言い切れるの？ >>634
よくある言語の優先順位ってどういうときに役立つのかよく知らなかったりw
例えば 1.英語 2.日本語としていても、英語と日本語が混ざったドキュメントの場合に
日本語部分が中国フォントで処理されたり。この挙動には関係ない設定なのかな?
中国語のフォントもひらがなとか持ってるから、フォントのコードセットだけ見て
その中国語のフォントが日本語もおkとされて使われてたりする?
（たしかfontconfigとかそんな挙動だった記憶が）
日本語と認識してるが中国フォントで表示しているのか日本語と認識してもいないのか >>635
アプリが対応しているかとか、フォントが対応しているかとか色々ある。
最近のオープンタイプ形式のフォントとかだと同じ文字コードに複数の字形を持っていて、アプリが対応していれば言語設定に従って字体を自動的に切り替えてくれたりする。アプリが対応してなければデフォルトの字形が使われる。 結局>>634に書いてあることのうち、ユーザー側の言語情報というのはあまり重要じゃ
なくてデータ側の言語情報というのがより大事なのかなと
ぶっちゃけコンピュータの利用というのは圧倒的に向こうからやってくるデータの
処理だし。ユーザの言語設定が日本語でも、中国語のテキストが来たらそれは
中国語のフォントで処理してほしい >>637
データ側に言語情報があったあら、レンダリングやレイアウトにその言語情報を使うのは基本中の基本で、当たり前過ぎて議論の対象にならんのでは。
データに言語情報がない場合にどのようにするかという問題。手抜きアプリだとフォントのデフォルトを使う。そしてフォントのデフォルトが中国字形になってるとか良くある。 >>638
言語情報が付いてなかったら本当は言語推定とかした方がいいと思うけどね
文字コードで言語統合してしまった分、分離のコストを支払う必要があるということ
ユーザーの設定は推定できなかった場合の最後の手段かな
普通は言語推定とかいちいちしないからユーザー設定頼みのみと >>639
言語タグが英語で文章も英語でその中に漢字で「骨」の一文字だけ含まれてる場合はどの国の字体で表示すベき？
言語推定とか無意味、字体推定とかできれば別だが、そんなの論理的に不可能。 >>635みたいに優先順位の設定がある場合は
一度英語と判定した文書中でも漢字が出てきたらそれに立ち返って参考にすべきかもしれない、
みたいな考え方はあり得るかも。 青空文庫がCP932しばり(Shift_JISではない)なのはなぜなんだぜ？ >>640
もちろん最後の手段に近い話だよ
Unicode自体は、マルチリンガルはあまり考えてないわけでしょ。事実上
一つのコードセットをいろんなモノリンガルで使うのが基本。だからUnicodeだけで
マルチリンガルがいけてなくても当た前
Unicodeの英語の中に一個だけ「骨」とかもうね、責めるならUnicodeの中の人をw
その上で、多少はどうにかするなら、という話 今から unicode を何とかするのなら完全 IVS化かなあ。
IVS の登録を全面拡大して、漢字を書く際には著者が使用した字体のIVSをつける。
IVSのついていない漢字は「著者が字体にこだわりは無く読者の好み字体で表示することを指定した」というルールにする。
字体にこだわるとテキストのサイズが増えるけど今の環境なら特に問題にはならないだろ。 1文字ずつつけるんじゃなくて新たに囲み用の言語指定マーク作ってもいいんでは？
既にLTR/RTL指定とか「ここからここまでルビ」みたいなマークがあるんだから。
どっちの方法でも実効性が現れるかどうかは「メジャーな環境が(入力ユーザーが気にしていなくても)デフォルトで付けるかどうか」次第だけど、
完全IVS化だと漢字圏のテキストがほぼ倍になる、そんなのをデフォルトにする判断を各社が果たしてするんだろうか？ >>645
普通の人は字体にこだわらないから付けないだろうし、字体にこだわる著者はサイズが倍以上になってもつけるだろうし選択権が著者側にあるのが良いと思うんだよな。もはやテキストサイズとか誤差の範囲でけちる理由ないし。
日本語と中国語が混じった国際的な文章を書きたい場合とか、1文字単位で指定できるのが重要というか。 >>644
たしかにそうすればCJK混在のテキストであっても、文字単位でそれぞれ正確に字体を表示できるね
ただし、そのままでは視覚的に「1. 完全IVS化仕様に基づいてIVSで修飾された漢字」と「2. 既存の個別コードポイントの漢字」の区別ができないが故に、テキスト作成時にIMEやエディタ側でその違いを視認できるような仕組みが必要になる気がする
それから、上記1,2双方の漢字を検索等で相互にマッチさせるにはUNICODE正規化仕様に手を入れればよいのだろうか？あまり詳しくないけど、その実現手段がない場合は色々とカオスな状況を招きそう
当たり前だけど、当該仕様を必要とする漢字圏のテキストサイズが倍近くなってしまう点もなかなかにキツい（それでも非漢字圏の言語に対する圧倒的な情報密度は揺るぎないが...） >>647
検索に関しては今の正規化検索が仕様通り実装されてれば、そのままでいけると思う。 >>650
異体字セレクタは正規化の対象外である一方で無視可能な結合クラス0の結合文字なので、表示／検索系での無視する／しない、個別に可視化する／しないのような制御の対象にできる。
規格本体には手を入れなくても、そのままでも大丈夫だろうという意味。もちろんアプリの対応はいるし、IVDの大幅拡張がいるのだけど。 >>646
普通の人がつけなかったら今回の元の話の解決(緩和)にならないと思う。
日本語IMEで入力したらデフォで日本語書体指定になっている、というのが必要かと。 >>652
元の話で言えば、利用者はレンダリングの際に言語情報ではなく、好みの字形情報を渡すようにしようということになるだけだよ。
著者が特定の字形を指定している場合はその字形で表示される。著者が字形を指定しない場合は読者の好みの字形で表示される。
字形情報と言語情報は別ベクトルなので一緒くたに扱うのはやめようとい話。
もしこの方法が普及したら字形にこだわりの強い日本人は、緩やかに差異のある漢字全てにIVSをつけるように移行して行くと思う。（サイズが小さいメリットより字形の指定が出来るメリットが上回ると考える人が多くなりそうという予想） たどればわかるが元の話は海外産ゲームの日本語とかの話題だよ >>655
ゲームがユーザ情報の好みの字体を使用するようになれば良いのにねという意味だけど。何か矛盾してる？ >>654>>656
「ユーザ情報」ってのがわからんがその枠組みだとユーザーじゃなくてゲーム製作(日本語版製作)側がIVS付けるかどうかにかかってくるんじゃないの？
で、ユーザーの声を聴いてIVS付けてくれるような体制のとこは現時点でも日本語フォント指定ぐらいできるんでIVSの出る幕はないような。 字形と言語は固定の関係ではない、という思想が根っこにあるのは理解したけど、20世紀後半以降の各国の漢字政策を経て固まった今現在の現実に即した思想かどうかは正直疑問。
増殖してしまった異体字について「本来は同じもの」と言ったところでどうしようもないのと似た理想論な感じがする。 >>658
でもな、日本国内でも古い本や文献を引用したり、人名地名とかだと台湾と同じ字体が出てきたりするんだよ。これに中国繁体字のタグ付けるのは間違ってると思わないか？ >>660
だから、そういう話だよ。いまのところ IVD が不十分なので役に立たないけど。 どの方式にしろ、この問題の解消のためには入力環境側がデフォルトで字形情報を埋め込まないとだめなのよ。
受け手になる現代の日本語話者にとって許容範囲外の字形に化ける可能性があるのに入力者にはそれが見通せないんだから。 今どきのEメールのエンコーディングって何が標準ですか?
gmailで試したら、MIMEでUTF-8 + Base64になりましたけど（かつテキストの属性の有無で
htmlかplainのマルチパートになる）、これって「標準」?
ISO-2022-JPとかあまり使わない感じ? GmailもThunderbirdもUTF-8だけになってしまいましたね。デファクトスタンダードなのかな? 今でも7ビットの制約とかあるんだっけ
いずれにせよMIMEのエンコードをするから別にISO-2022-JPじゃなくてもいいと 実は7bit制約もインターネットの場合は存在しない。
昔ながらの個別メール網とメール交換する際の互換性のために7bitが必要だっただけだが、そういうのは滅びたかゲートウェイで7－8変換するようになったので。
そういう意味で生UTF8で十分。 えっと、RFC（現在は何番かな... 5322でおk?）に書いてあるUS-ASCII、というのは
生きてるわけですよね?
その上でMIMEを使えと >>669
そうだよ。US-ASCII 以外の文字コードを使用する場合は原則MIMEヘッダーで本文の文字コードを指定しなければならない。
原則というのは
・送信者と受信者の間で暗黙もしくは明示の合意がある場合は例外。
・多くのメール・クライアントは文字コードを自動推定をする機能があるのでMIMEヘッダーを省略してもたいてい機能する。
・その後に、RFC6531 で SMTPUTF8 が導入され、RFC6532でメールヘッダーもUTF8対応に拡張されている。
要はデフォルトを US-ASCII から UTF8 に置き換える方向で進んでいる。
インターネットは一気に全体が更新されるわけではないので従来的なやり方が安全といえるけど、ユーザーがメールクライアントを更新したら裏で勝手にUTF8になっている可能性がある。 >>671
ASCIIに関しては便利なやつね。それ以外は効率が落ちるという
まるでUTF-8のようなw
基本的な日本語が2バイトで収まるエンコーディングは無理かのう... ってUTF-16かw
いえ、UTF-8とUTF-16のいいとこ取りはできないかなあと >>672
みんな大好きシフトJISなんてどうですか >>674
ドコモかauかソフバンの拡張を正式採用したらいくらかは入ったことにできる 文字コードの、それもパーセントエンコードに詳しい方教えてください。
たとえば、π(pi)をパーセントエンコードすると、%CF%80ですが、このCF、80を生成するプログラムが本に掲載されていたので
解読しています。
πに対応するコードである、960を64で割った商15をさらに、15 Or 192で論理和を求めると207となって、
207を16進数で表すと、CFを求められるとする過程はわかったのですが、
最後の論理和を求めるところで、なぜ論理和が使われるのかということと、相手に192という値が選ばれているのかが
皆目わかりません。
論理和と論理積を解説するサイトを見ても、True と False のペアを評価するのみで
この手の応用について解説されるサイトは無さそうでした。
コードはNo.128 ～ No.2047 (0080～07FF)の範囲でお願いします。 >>677
パーセントエンコードの仕様はよく分からんけど、対象のコードポイントをUTF8で符号化した値そのまんまっぽい気がする
UTF8のバイト表現は可変長なので、各バイト毎に「桁」を示すbitパターンがある >>679
ありがとうございます。
各バイト毎に「桁」を示すbitパターンが、110X XXXX と 10XX XXXX のことだと思いますが、
論理和、論理積を 適用すると、前者の場合、X XXXX がどんなビットが来ようとも
110X XXXX が損なわれずに出てくる感じですかね？
まだ全容がわかったわけではないですが、上記イメージで捉えるようにしてみます。 Wikipedia のUTF-8 の所に、ビットパターンの規則が書いてある
1バイト目について、
先頭ビットが0なら、1バイト文字
110なら、2バイト文字
1110なら、3バイト文字
1111なら、4バイト文字
2バイト目以降は、先頭ビットが10で始まる 全身verと顔verがある動物と無い動物があるのはどういうわけなんだぜ🦖🦕？ 履歴書にバストアップ写真貼付
っていうの観て豊胸写真貼るくらいおばかなレス au PAYプリペイドカードで取引履歴が表示されない不具合 中、朝、住、今、荻、塚などが含まれる加盟店で
https://www.itmedia.co.jp/news/articles/2302/08/news159.html
これはどういう原理？ >>689
完全に推測だけど、UTF16 にCP1292用とかの特殊処理をしたとか？
そのせいで 0x92 や 0x94 などを含む一部の文字が使えなくなった。 >>690
訂正、UTF16じゃなくてSJIS/CP932だな。 >>690
もいっこミス、CP1292はCP1252のタイポ。英語Windowsで使われるやつのつもり。 だからSJISを英語版Windows用のライブラリかフレームワークで処理しちゃったんだろ。
例に上がってるのがどれも該当文字。 Windows, CP932, UTF16 を使っているシステムは、ヤバイ
その点、Linux はUTF8 だけ LinuxもUnicode文字のパースにはUTF32使ってるでしょ。じゃないと基本多言語面以外の文字を正しく使えないから。 パースパースってここは西オーストラリア州かよ🐨🇦🇺🏴🦘 Linux は内部的には、UTF32 も使っているけど、外には出ない。
外部とはUTF8 で統一されている
Windows のCP 何々みたいなものは地獄。
他国語のCPを誰も知らない
例えば日本人だと、CP932 しか知らない。
逆に外人は、誰もCP932を知らない
つまり、外人同士が意思疎通できないシステム
ただし、Linuxでも、iconv を使うけど、
Ruby では非推奨になって、NKF を使う
今では、CP932とか日本語を扱えるのは、Rubyだけだろ。
外人は誰も、CP932など知らない 中 9286 ← 判る
朝 92a9 ← 判る
住 8f5a ← 判らん
今 8da1 ← 判らん
荻 89ac ← 判らん
塚 92cb ← 判る 荻は 948b では？
cp1252 の 0x81 0x8d 0x8f 0x90 0x9d の5文字は未定義文字なので、ライブラリによってはエラーになる。
0x92 と 0x94 はクォートで特殊処理される可能性がある。 互換性を簡単に切り捨てられたLinuxと、互換性を維持しなくてはならないMS-DOSとWindowsを比べるのはただの阿呆。 当時ISO2022 という規格があったのに
CP932 などというふざけた規格を作ったのが悪い 別にふざけてたわけじゃない
当時の日本のPCはJIS X 0201との互換性のほうが重要だったってだけ えっと、JISX0201 は ISO2022 に従ってますよ
CP932 なんていらんかったんや シフトJISの主目的はバイト数の節約なので、ISO2022系は許容できなかったんだよ。
当時のPCとしては1バイトでさえ貴重な資源だった。
メモリの容量が100万倍になった現在から見たら笑い話だけど。 >>706
マイクロソフトは悪くいうのに、IBMは悪くいわないのか？ >>706
日本語がマルチバイトの先駆けだったので、中国は何もかも楽だった。 >>710
中国語とかのコードって普通に片仮名平仮名入ってるよね >>709
EBCDICのこと？だってその頃はISO2022ないじゃん
でも、System 360 は素晴らしいと思うよ EBCDICなんでアルファベットのコードの真ん中に穴を開けたのか? >>713
パンチカードがBCDだったから。16進数でいう A～F が使えなかった。 >>712
IBM932は問題ないのか？
SJISは拡張部分の定義がバラバラ。
JISはもっとひどかったから、まだいいんだが、UTF-8とUTF-16の混在という問題はまだ解決していない。
マイクロソフトのSJISは日本語キャラクタセットの統一という成功を収めたが、UTF-8とSJISの相性が悪いのはどうにもならない。
日本人が日本語のキャラクタセットを決められない状況では、中国人が決める日本語キャラクタセットに日本人は従うしかない。 SJIS は時代遅れ。結論が出てるんだから捨てれば良い。
何が統一なんだか。一瞬足りとも統一されたことなんて無かった。 >>716
SJISで統一して成功したシステムは多い。
UNIXとWindowsの組み合わせではSJISでの統一が正解だった。 >>715
時系列が無茶苦茶
CP932が作られたかIBM932が生まれた
何故わざわざ空けてあるC1領域を使ってしまったのか >>717
UTF-8以前の話なら
UNIXとWindows混在ならEUCが正解 >>720
IBMは昔からわざとちょっと変な仕様追加するのが好きで
M$と不仲になってさらにその傾向が増長したのでは >>721
それは逆だ。Windowsを使っていると無意識にSJISになるので、UNIX側をSJISにすればポンコツがいても問題は発生しにくい。 UTF8出来てから30年、RFCになってから20年にもなるのに未だにSJISとかアホか
お前らもう20世紀に帰れ。今の時代に不要な人材 この話の流れはともかくとして、SJIS人材は、必要。 そう言えば eucjp-open と Unicode にはあるのに windows--31j に無い文字って結構沢山あるのな。 Windows では環境依存文字扱いになってメモ帳に入力できるが UTF-8 にしないと保存出来ない。 >>724
Windowsは表面がSJIS、内部がUTF-16だ。
これをUTF-8にすべて置き換えるには、あと数十年はかかる。 >>727
メモ帳を進化させて、環境依存文字がないようにUTF-8の文字を使うようにしたから、自動的にUTF-8になる。 これから先Windows上でテキストファイル作る時には
文字コード何にするのが一番いいの？BOM無しUTF-8？ 今のところSJISかBOM付きUTF8のどっちかだと思う これから先って言うならBOM無しUTF-8だろうな
メモ帳も前はUTF-8にするとBOMを強制的に付けてきたけど、今はBOM無しUTF-8が標準になったし SJISが生き残ってるうちはBOM付きの方が自動判別が確実で便利だけど SJISでしか動かないツールをメインに使ってるんじゃなければUTF-8に全面移行するのが正解。
当然BOMとかも不要。 Windows環境でBOMを付けて困ることなんてないんだから、付けられるなら付けておいた方がいいでしょ
むしろBOMなしのメリットが思いつかない
ExcelとかBOMつけないとcsvが文字化けしたりするし 令和になってもう5年になるのにいまだにsjisなんてありえない
あとbomつきutfも2010年代ならともかくWin81もIE11も死に絶えてる現代で許されるわけがない
結論:BOMなしUTF8以外の選択肢はありえない UTF16も内部処理コードとしての賞味期限は切れてるしな
2030年位には世の中すべてUTF8で統一されるだろう >>737
日本語や中国語はUTF-8だと処理が面倒なんだよな
UTF-8は将来、UTF-32に置き換わるだろう。 日本語とか中国語が特にめんどうという話は聞いたことがない。どういうこと？ UTF-16が持て囃されたのももはや4半世紀以上前なんだが
日本語も中国語もUTF-16の範疇で何ら問題なく処理できるはずなのに
どんな処理系でいまだに扱いが面倒なのか教えてほしいな
まあ具体例を聞いたら「そんなゴミとっとと廃棄処分しろ」という乾燥にしかならない気もするけど UTF32にはUTF16同様にエンディアンの問題があるから入出力形式には向かない
まぁ、UTF8にはUTF8で冗長コードの問題があるわけだが……UTF8をコードポイント単位で読み込んで処理するのが一番確実と思う >>740
UTF-8は文字によって1バイトで済むなら1バイトで表現する。
これはアルファベットを使用している欧米人には都合がいいが、漢字を使っている日本人、中国人などでは、その漢字は何バイトなのか常に意識しなくてはならなくなる。
近い将来、4バイトで統一した方が楽という話になる。
特に中国が世界の中心になると、中華人民共和国が推奨しているキャラクタセット GB2312は2バイトで一文字をあらわすキャラクタセット。
日本語のように1～2バイトで表現するから、UTF-8のように1バイト文字、2バイト文字、3バイト文字、4バイト文字、5バイト文字と何バイト使うのかわからないキャラクタセットは嫌う。
中国語EUCとUTF-8は相性が悪い。 GB2312をUTF-8に置き換えようとしても、面倒くせえだけだと思うは中華人民共和国も同じ。 みんな言うことバラバラｗ 結局なにが良いんだよう？ >>743
寝ぼけるな。
欧米でもアクセント付きの文字やちゃんとしたクォートとか使えばバイト数増える。
さらに合成アクセント、合成文字、異体字セレクタ、絵文字合成、国旗とかもろもろあって固定長にはならない。UTF32使っても可変長。 文字をいろいろ表そうとリガチャ導入したのは失敗だと思う >>746
UTF-32は一文字が32ビットで、4バイト単位で文字を表現するから、漢字一文字を4バイトで表現している中国のキャラクタセットと相性がいい。
UTF-8は一文字が何バイトなのかわからないから困るんだぞ？
日本語や中国語は、UTF-8だと2バイト文字というものがほぼ存在しない。
1バイト文字か3～4バイト文字の混合だったから、UTF-8よりUTF-32の方がシンプルになる。
さすがに32ビットではなく、64ビットにしようというのは、かなり未来の話だろう。 >>746
話が矛盾しているぞ。UTF-8もUTF-32も同じ批判ができるなら、UTF-32の方がシンプルだろ？ うわあ「GB2312」ときたかあ
2000年以前の知識からアップデートできてないゴミ以下の化石の認識なら、
まあ>743みたいなことを言い出すのも納得だわ
当の中国政府すら「GB2312までしか対応できないようなソフトウェア製品は流通禁止」なんて言い出してから
すでに15年以上経過してるのにいったいお前はどれだけぼーっと生きてきたんだ？
>>745 繰り返すけどBOMなしUTF8以外もはやありえない おそらくだけど>743は知識が古すぎて
>>746が挙げてる用語がそれぞれどういう意味を持ってるのか何一つ理解できていないだろう
これでは会話が成立しない
もしくは知識があるうえで>748や>749みたいなことを言い出してる可能性もないわけではないが
仮にそうであったとすれば頭が悪すぎてなおのこと会話が成立しないと思われる 正直、UTF-8にBOMつけるんなら
ISO2022 でいいやんと思う >>750
わかった、あなたとマイクロソフトのメモ帳を信じることにするｗ これからは UTF－8 に統一されるんだから BOM は不要
過去の遺物になることが確定してるんだがら、可能な限り早く BOM 無しに移行せよ >>757
わかった、俺もあなたとマイクロソフトのメモ帳を信じることにするｗ UTF-8にBOMは要らんし付けてはいけない
未だにBOM言うてるのは老害ゴミ
異体字セレクタとか観たら卒倒して死んじゃうんじゃないか いまだにBOM言ってるのはたしかに老害だな。signatureって言え。 Excelにutf8食わすときに必要だし、Windows Searchもutf-8はBOM付き前提で、この状況は未だにかわってない
BOMなし教の人はWindow使ってないんじゃないの？w 最終的にはBOM無しUTF-8に統一されるべきだと思うけど
移行期の今はまだBOM付きの方が現実的で無難
まずはWindowsやOffice等主要ツールがBOM無しUTF-8前提になってくれないと >>762
天下のMicrosoft様がメモ帳の初期値をBOM無しUTF-8になさっておられる
ExcelとかWindows Searchとかもいずれ追随するんじゃねーの？ >>763
世の中から既存のものを含めた全てのSJISテキストファイルが消えてなくなればBOMなし対応になるだろうが、果たして何年かかるかな レジストリスクリプトなど、windowsのユニコードが未だutf16leという現状で
utf8w/obomに統一とか時期尚早でしょ Windows のシステムロケールをUTF8に設定すればExcellとかOffice系もBOM無しでいけるんじゃないの？ Excel の先頭BOMとかいう愚かな仕様も早く無くなってほしい
テキスト開くときにエンコーディングを指定できればいいだけだよね >>768
だからシステム・ロケール UTF8 に変更すれば BOM いらない。
お前らがシステム・ローケルをSJISに設定してSJIS優先にしてるから、それに従ってBOM無しをSJISとみなしてるだけ。
単に設定の問題。エクセルは悪くない BOMがあって困った経験はJavaしかないなあ
BOM付きを標準していいくらいじゃないかな Windowsの古い資源と共存するためにもUTF-8/16/32はBOM付きを必須にしたほうがいい
BOMを廃止して良いことなど何もないのが現実。今どきにBOMに対応してないほうがおかしい そもそもネットの通信でも、MacでもLinuxでもUTF-8にBOMつけたりしない。
UTF-8にBOMつけたのは過去のWindowsだけって時点でゴミなのわかるだろ。そのWindowsだってデフォルトでは付けない方向に舵を切った。
今時BOM必要って言ってるのは時代の変化についてこれなくて、過去の環境に生き続けたいロートルだけ。 >>772
BOMがついているファイルを扱えないと機会損失にしかならない。
これは純粋なビジネス上の問題。LinuxとMacが少数派であることの理由のひとつにもなってる >>772
UTF-8なんて使っているのが過去の環境に生き続けたい（ASCIIが素通しになる）ロートルだけだろ。 エンジン開発での競争に敗れた国がこぞってEV化を推進しようとするのと似た構図。
シェアを持っているWindowsには業務アプリケーション遺産に対する責任がある。負け組のLinuxとMacにはそれがない。 うわあ頭がおかしいのが複数湧いてる（ひょっとして同一人物の別IDだったりして）
意図的に間違ったことをあえて逆張りで言ってるのか本気で信じてるのかどっちなんだろう
UTF8を使うのがロートルって、こいつの言ってる「過去」ってまさかWindows以前のMS-DOSの時代のことか
あとUTF-16やUTF-32のテキストファイルなんて
規格上定義されてることは知ってるけど現物にお目にかかったことなんかないし
そもそもUTF-16やUTF-32なんて元々BOM必須だろうよ
過去の負の遺産がある以上アプリケーションとしてはBOMありファイルの読み込みには対応しなきゃダメだろうけどさ
今後作成するファイルでUTF-16/32を選ぶのは論外だし、UTF-8で保存するならBOMをつける必要などどこにもないだろうよ >>700
Windowsは内部的にはUTF16で統一されてるよ
そこはLinuxよりも優れた設計 > UTF-8で保存するならBOMをつける必要などどこにもないだろうよ
BOMをつけないと他の文字コードとの区別ができなくて
文字化けしてしまう だいたいUTF-8のBOMはUnicodeの正式な仕様なのだから
対応してないほうが悪い LinuxとかmacOSとかUnixはUnicodeの対応が遅れていて
LANG=C.UTF-8でさえPOSIXで標準化されていない
Unicodeを正しく扱えないコマンドがある >>780
いったいいつの時代の話をしてるんだ
具体的なコマンド名とディストリビューションを挙げてみろや >>768 >>769
Mac上のExcelは、どうするのが正解?
以前「CSVで日本語が化けるぞ」と言われて、よくわからなかったからググったら「UTF-16なら
大丈夫」とあったので、そうしたら文句を言われなくなったのでよかったらしいw
Excel以外でCSVを使うとき、例えばpandasとかUTF-16でも大丈夫なんだっけ? 今後はファイルや外部通信はUTF-8がデフォルトになる
逆にいうとBOMついてないのは全てUTF-8とみなされる
よってUTF-8にBOMは不要
この単純なロジックが理解できないやつはかわいそう >>783
> 今後はファイルや外部通信はUTF-8がデフォルトになる
ならないよ。
誤った認識を前提に議論するのは意味がない。
スレのレベルが低下して無駄な書き込みが増えるだけなので、この話題はもうやめてくれ。 文字コードを自動判別するためにBOMを使うってのがダメだな
BOMと思ったコードが違うエンコーディングの可能性があるんだから
Windows だけで閉じておいてほしいから、通信回線には流さないで >>777
> Windowsは内部的にはUTF16で統一されてるよ
ワイドキャラクタがUTF-16で統一されているという意味なら
Linuxも20年以上前のglibc-2.0からUTF-32で統一されているよ
ワイドキャラクタ以外アプリ等が独自に他の符号化方式を
採用している場合があるのも同じ >>785
そもそも誰も自動判別の正確性を担保できないからBOMがあるんだろ
Windowsを除外したビジネスで成り立つならそれでいいが、現実はそうじゃない。
他人が対応するのを待つのは無能な人のすることだよ。 過去にプログラミングやったことない人が急にスマホ開発に配属されて、自分が対応するのではなく他人が対応するのを待ってるあたりに頭悪いのが伝わってくる。
プログラミングの才能ないし、むいてないからプログラミングから離れたほうがいいと思う。 逆だね。BOMなんかじゃ判別できない
だって，FEってソーンのコードだもの Windows プログラマってほんとどうしてこんなに喧嘩を売るの？
世の中の文字コードがCP932 とUTF-16しかないと思っているよね もう少し正確にいうと，テキストファイルから
文字のエンコーディングを推測することはほとんど不可能
文字のエンコーディングはアウトオブバンドで送る必要がある
ISO2022 はエスケープシーケンスというアウトオブバンド転送を定義していた
ちゃんと定義するなら，UTF-8も Byte order mark ではなく
エンコーディングを指定するアウトオブバンドシーケンスを定義すべきという話
なんか議論が噛み合ってなかったので それで，Windows は先頭にBOM を入れるというのをアウトオブバンドで決めてる訳
だから，Windows で勝手にしてね。Windows 以外には送らないでって話 もうさ、結論出ないからこうしたら？
今後新たに作成するテキストファイルはBOM無しUTF-8で書く
今後のソフトはBOM有りBOM無し両方のUTF-8を読めるように作る 急にスレのレベルが下がった感じ。同じ人がID変えて書き込んでるんだろうか。
このスレに独り善がりな理想論を書き込む人は、プログラマ適性がないから転職しなさい。 >>792
Windowsではとか言ってる時点で国際化とか文字コードのこと全く知らない無知だろ。単に「日本語Windows」で使われてたCP932がUTF-8のBOMとかぶってなかっただけ。
英語Windowsで使われてたCP1252とかは EF BB BF にもそれぞれ文字が割当れらてるのでBOMとかあっても区別できばない。他の多くの文字コードもそうだし、CP932/SJIS なんかより断然現有の資産も多い。
おま国事情でたまたまうまくいってるだけなんて、一般化や標準化されるわけないだろ >>796
792の返信にしたけど、792を批判したいわけではなくて、WindowsではBOMが便利という一般論を否定したかっただけ。
それは単なる日本しか知らない蛙仕草。 「ぼくのかんがえたさいきょうの文字コード処理パッチ適用」を自腹で開発して、自腹ですべての顧客のデバイスに入れればいいだけ。
すべてはカネ次第。カネを出す人が仕様を決めればいい。それだけ。 海外ではこうとか、本来こうあるべきとか、どうでも良いんだよ
日本語のテキストファイルを読み込むプログラムの仕様としてSJIS/UTF8自動判別にした場合、
確実に文字化けしないのはBOM付きUTF-8だけという事実は考慮すべき >>796
CP1252でEF BB BFって文字はあっても意味を成さない謎の文字列だし、極稀なパターン
完璧ではなくとも、実用上ほぼ問題ない精度で判別出来るでしょ
とうのWindowsがそういう風に利用してるのだし ïÿ¿を有意な先頭文字列とする利点と欠点を考えて決断すればいいだけのこと WindowsやエクセルとBOMは関係ないとおもうんだが
とくにマイクロソフトが開発したり、始めたわけではなく
採用前からBOMありのユニコードがあってたまたまBOMありフォーマットを使っただけでは?
ちがうのか? >>799
そもそも自動判別は悪という流れになってることすら知らないんだな。
セキュリティホールやバグの温床になるので文字コードの自動判別はなくすのが世界の流れ。特に確実性のない自動判別は害悪でしかない。 >>786
> Linuxも20年以上前のglibc-2.0からUTF-32で統一されているよ
それでマウントとったつもりだろうが
Windows NTがUnicodeに対応したのは30年前だ >>804
世界には多数の文字コードがあるわけで
完全な自動判別は不可能だって知らないの？ >>783
> 逆にいうとBOMついてないのは全てUTF-8とみなされる
> よってUTF-8にBOMは不要
あのー、Unicode以外の全ての文字コードにはBOMがついてないんですけど？ >>781
> 具体的なコマンド名とディストリビューションを挙げてみろや
echo あいうえお | mawk '{ print length($0) }'
15 まだunicode以外の文字コードを使う気かよ
化石なん？ >>781
echo あいうえお | dash -c 'read line; echo ${#line}'
15 >>809
今すぐこれまでの資産をUnicodeに変換してみせろよｗ UTF-8はPlan 9かららしい
Linuxに勝てなかったPlan 9 2009/02/09
「Plan 9」はUNIXが生まれたベル研究所で、次世代UNIXとして開発されていた分散OSだ。
UNIXやC言語を生み出したケン・トンプソン、デニス・リッチー、ロブ・パイクらのチームが、当時UNIXが抱えていた限界を打ち破るために、ネットワークやGUIを最初からUNIXの設計思想に基づいて取り入れた先進的なOSだった。
UNIXの大きな特徴として、デバイスをファイルにマッピングして抽象化するというものがある。ところが、こうした初期設計時の抽象化から漏れるAPIが増えた。
そうして漏れつつあった各種リソースを、再びUNIX的なファイルシステムのツリーにマップし、抽象度と統一性の高いインターフェイスを用意したのがPlan 9だった。
ファイルとして扱えるのは一般に想像するようなハードウェアデバイスだけではなく、あらゆるリソースが対象となった。
TCP/IPなどのネットワーク関連の操作も「/net」というディレクトリを使って行うなど徹底していた。
Plan 9はなぜ失敗したのか？
マーケティングに熱心でなかったからとか、さまざまな理由付けが可能だが、Plan 9が普及しなかった理由は結局のところ、旧来のUNIXを置き換えるほどには先進的ではなかったからだ、というのがレイモンド氏の答えだ。
Plan 9に比べれば、確かにUNIXはきしみ音が聞こえてガタピシいうし、明らかにさび付いたところもあるのだが、そのポジションを維持するために必要な仕事はちゃんとこなせていた、という。
LinuxやBSD系UNIXには、Plan 9由来の機能がいくつか取り込まれている。
稼働中のプロセスをモニタしたり操作するための「/proc」と呼ばれるファイルシステムは、Plan 9のものだし、
Linuxでスレッドを生成するシステムコール「clone」は、レイモンド氏によればPlan 9の「rfork」をモデルにしているという。
すべてをファイルのように扱うという意味でいえば、LinuxのFUSEもPlan 9の影響下にある。
現在、FUSEを使ったファイルシステムには、ftpfsはもちろん、flickrfsやBloggerFS、TracFSなどさまざまな実装がある。
今やOSばかりかインターネット全体にも利用範囲を広げた感があるUTF-8も、Plan 9のために考案されたエンコーディングだという。
https://atmarkit.itmedia.co.jp/news/analysis/200902/09/future.html >>781
echo あいうえお | cut -b 4-
いうえお 間違えた
echo あいうえお | cut -c 4-
いうえお 業界人ですら認識ちがいのある文字コード。素人に説明するの超絶に面倒。 エンコーディングの話をしているのに Unicode とは？ 流れからしてピントのずれたレスに反応するほどのことでもないかなって >>814
そもそも -c オプションは現在 -b （バイト指定）と同じ動きというのが仕様なので文字コードもくそもない。
マニュアル嫁。 >>815
いや、このスレは素人が跋扈してるだけに過ぎないと思うが。
文字コードやネット・プロトコルの専門家で、「今後は外部は UTF-8 がデフォルト」って以外の意見は聞いたことがない。 >>817
スルーしてないだろ
ちゃんと読めよ
わざとか？ >>819
どこにも同じ動きとは書いていない
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html
-b list
Cut based on a list of bytes. Each selected byte shall be output unless the -n option is also specified.
It shall not be an error to select bytes not present in the input line.
-c list
Cut based on a list of characters. Each selected character shall be output.
It shall not be an error to select characters not present in the input line. >>822
linux なら linux のマニュアル嫁。 >>823
お前か誰かしらんが、どのディストリでUnicodeに
対応してないって聞かれたから
Linuxは全て対応してないと答えたんだが？
Linuxは対応してないといった俺の指摘に対して
Linuxは対応してないのが仕様だと答えるアホ
macOSのcutはちゃんとUnicodeに対応してる
対応してないディストリを聞かれたから答えただけだ それにmawkやdashが対応してないという話からも逃げてるな
Unicodeに完全対応してねーんだよ >>825
話の流れを見る限り、お前が内部コードと外部コードの区別がついてないんじゃないか？ macOSはUNIXといってるからawkもちゃんとロケール対応してるべき? SUSのバージョンにもよる?
gawkは対応してるみたいね >>826
付いているし、そんな質問されても意味がない 現実的っていうのはEUC-JPで書かれた
ウェブサイトが見れなくなるってこと？ 文字のエンコーディングは通信相手同士で取り決めろということ
相手がEUC-JPで送ってくるならこっちもEUC-JPで受け取れば良いこと 今後はファイルや外部通信はUTF-8がデフォルトになる
デフォルトの意味が理解できないド素人がいるみたいなので書いておくと
「アプリは特に文字コードの指定が無かった場合はUTF-8で出力するべき、指定が無かった場合はUTF-8として読み込むべきである」ということ
つまりBOMが無くてもUTF-8とみなすべきなので、UTF-8にBOMは不要 >>832
お前が気まぐれに「不要」と宣言したら、他人は良きように計らってくれるとでも思っているのか？
BOM付き文字列が送り込まれた時にどのように処理するかを決めないことには、なにも進まないぞ 通信はともかく、問題は過去に作成された膨大な数のUTF-8以外のファイルだ
とりあえず開いてみて、文字化けしたらエンコードを指定して開き直してみろ?
そんな対応じゃクレームが大量に来るし、PC苦手な人じゃ教わっても対応出来ないだろ ロバストネス原則(ポステルの法則)
https://makitani.net/shimauma/robustness-principle
ロバストネス原則(robustness principle)とは、「あなたがすることは厳密に、あなたが他人から受けることには寛容に (be conservative in what you do, be liberal in what you accept from others.)」というシステムやソフトウェアの開発における考え方、開発指針のこと。「送信は厳密に、受信は寛容に」とも言い換えられる。「堅牢性原則」。
他のシステムとの間で通信を行う際、処理をして送信する側は厳格なデータの仕様に準拠するべきだが、利用するユーザー側には入力データの多様性を許容して使い勝手を損なわないようにするべきである、というものである。
アメリカのコンピューター科学者でインターネットの創始者の1人であるジョン・ポステル(Jonathan Bruce Postel)が初期のTCPを規定したRFC 793において示した一節であり、それが一般化され知られるようになったものである。ジョン・ポステルにちなんで「ポステルの法則 (Postel’s law)」とも呼ばれる。 >>831
だからUTF-8を前提にできないってことだろ >>832
> 今後はファイルや外部通信はUTF-8がデフォルトになる
だーかーら、既存のHTMLとかでEUC-JPとかが使われてるから
UTF-8以外を切り捨てられないっての アップデートされずEUC-JPのまま捨て置かれたドキュメントの価値などもはや「歴史的な」価値しかない
Webブラウザで閲覧できれば十分、新しく作るシステムでいまさら対応する必要性など皆無
2000年前後の知識しか持ち合わせていない老害がいくらギャーギャー騒ごうとも
時代遅れなエンコーディングに対応するような愚を犯してはならない
毅然としてUTF-8以外を切り捨てるべし >>839みたいに「切り捨てる」とか強い表現を使う人は、既得権からあぶれた失うものがない負け組が好んで使う言葉。
ネットでは威勢が良く見えても現実世界では切り捨てる側ではなく切り捨てられる側。ルサンチマンを抱えている。 「～べき」とか語っていいのはカネを出す側であって、「～べき」はカネで雇われる側にすぎない技術者が使っていい表現ではない。 >>835
そういう歴史的なコンテクストでいうならRFC 793じゃなくて761を引用すべきでしょ よりによってShift_JISの5chでイキってて笑っちゃうんすよね ユニコード規格 Unicode Standard にも UTF-8 の BOM は付けても良い(may)けど、非推奨(not recommended)って明記されてるのに、どうしても付けさせたいや奴がいるのはわかった >>839
だから歴史的な価値が高いものをお前は捨てるのかって言ってるんだよ >>845
非推奨だけど付けて良いわけで何の問題もないだろ >>847
だから、お前が一人でつける分には勝手にしろ
つけるべきか聞かれたら、「非推奨なのでつけるな」が正解。 つけたいじゃなくて、対応できないと困ると言ってるだけでしょう つまり入力をどするかは置いといて、出力にがBOMはつけるなでFA? >>843
逆にShift_JISでも文字参照さえ使えれば問題ないという
それに言語タグみたいのもあると便利だし、もうプレーンテキストを廃止して
マークアップ系で情報のやり取りをすればいいとか ドレスコードを守らない客を門前払いするかを判断するのは雇われコックではない。経営者や管理人だ。 UTF-8にBOMは付けるなでFA
付いてるやつ受け取ったらドンマイ 付けるなと規定されているところなら付けないし
付けろと規定されているところならつける
指定が無ければ俺は付ける コロナ禍でマスクするのは世間体のためばかりとは限らない。
マスクしてないと入店拒否されかねないからね。
マスクしている人を入店拒否するのは反ワクチンかな。 >>853みたいにクライアントとサーバーの切り分けできてない人、頭悪そうに見えてしまうから良く考えてから書き込んだほうがいい
BOMのせいで挙動がおかしくなることはないので、みなBOMをつけるようになる。それが現実。 >>856
ねえよ。規格で非推奨ってなってるの出力して誤動作したら出力した方の責任。業務プログラムなら非推奨を理由に改修要求や損害賠償請求できる。規格の非推奨にはそれだけの効力がある。
趣味でやる分に好きにすれば良いけど、実務にはかかわるな。 >>856
>>BOMのせいで挙動がおかしくなることはないので
少なくとも linux のシェルスクリプト、perl, python スクリプト等は BOM つけるとエラーになって起動できない。 Windows環境はどんどんBOMつきが当たり前になっていくから、サービス提供者はBOM対応が事実上必須になる
非推奨だからとかつけるなとか、およそ現実を見てないね >>860
そのマイクロソフトがBOM無しをデフォに変更したんだがな。
妄想と現実の区別がついてないんじゃないか？ >>861
許容するようになっただけで、規定ではない。規定はあくまでシステムコードページ。
技術板だから嘘つくのは慎め >>862
じゃあメモ帳のデフォルトがBOM無しに変更された理由は何？
妄想くんには説明できんだろw >>863
Windows Subsystem for Linuxのためじゃないかな？
上にもあるとおりunix系のアプリの中にはutf8のBOM未対応のまま（というか今更いじれない？）の状態になっているからな
良くも悪しくも歴史的にメモ帳は機能がしょぼすぎてその他の一般業務向けでの影響力はほとんどない状態だから、
Excelとかに比べれば変更しやすいという後ろ向きな理由もあるだろう ていうかあれか、パイプを使ったテキストのやりとり等とBOMの相性が悪そうだから、コンソール系のアプリでBOM対応は面倒だわな >>865
いや、webの標準はunix系のコンソールアプリでしょ？ リンク貼った人がいるので正解は
Microsoft の主張は「WEBの標準はASCIIと互換性のある BOM 無しの UTF-8 だから、それに合わせるため変更した。これは重要な改善である。後方互換性のためにBOMつきも可能にしといた」
BOMなしは改善、BOMつき後方互換性って明言してる。 ASCIIのような化石との互換性は要らない。UTF16以上を推奨し、UTF8はASCII文字出現率が
99.5%以上のファイルに限り許容するのが良い。 Windows10では、デバッグ機能で別のエディタを起動してるから
メモ帳を使ったことないというか、どんなだったかも思い出せない MSはデフォルトを変更しただけで
BOMにも対応している
つまり完璧にUnicodeに対応している もうUTF－16にはWindowsの内部コード以外の役割はないんだ
文字コード戦争はとっくにUTF-8の勝利で終結したんだ ネットの普及が決め手だった
残念ながら負け犬がどんだけ吠えても現実は変わらないんだ
ほら、どんどん吠えて、（愉悦 恥ずかしい無知野郎だなぁｗ
JavaもJavaScriptも内部コードはUTF-16だってーのに >>873
UTF-16でどうやって絵文字処理してるのか不思議なんだよなあ
サロゲート処理必要なのに 🪟🍎🐧 >>868
>これは重要な改善である。
甘いなあ
文字コードの自動判定を入れた、ということは、今後はUTF-8と認識できない可能性が生じる事を意味する
皮肉な話だが、文字コード自動判定のせいで事実上、BOM必須になる JavaのStringとか、もう開き直っちゃってる感じで「文字とはUTF-16のバイトのことでーす」
って感じじゃん。ただの16ビットの配列と何が違うんだっけあれ
まともな文字列処理をするには別途ライブラリが確実にいる。面倒じゃのう BOMは文字コード自動判定をスキップする顔パスのようなもの。BOMを無くしたいという意向とは裏腹に、今後BOMは益々増える。
それが現実。 関所を沢山作ったせいで、ますます関所破りのバッドノウハウが普及する >>874
通りすがりだが、お前は論外
ググってトップに「Java/Javascriptは内部コードでUTF-16が使われています」と書かれていたのを読んだのだろうが、BOMつけるか論争をしている人達割り込むツッコミ方じゃねぇw
他人を煽る前に自身の読解力と理解力を見直して出直してこいw 外部コードは自動認識うんぬんより ASCII との互換性が重要なのだ
Linux だの Mac だのの Unix 系は ASCII との互換性が必須なので BOM 無し UTF-8 以外に選択肢がないし
RFC とかネットの標準もそれに引きずられて るし
Windows 外部コードの unicode 化はこれから本番だけど、今まで CP932, CP1252 みたいにASCII互換は大前提で来たので互換維持した方がトータルのコストは低い
結局ASCIIと互換性のないBOM付きのUTF-8だの、UTF-16だのが外部コードとして主流になる世界は来ないのだよ UTF-8を使い始めたのは、
Fedora 1でデフォルトのシステム・ロケールになったときだから、
もう19年か、早いもんだ
RedHatの頃のEUC-JPに戻す誘惑にも負けずに苦労したことを思い出す >>881
> ググってトップに「Java/Javascriptは内部コードでUTF-16が使われています」と書かれていたのを読んだのだろうが、
それはお前だろｗ
JavaやJavaScriptがUTF-16を使っていることなんか
ちょっと昔のことを知ってりゃ誰だってわかることなんだよ
そりゃそうだろUTF-8ができたのが、JavaやJavaScriptが出来るよりも後なんだから そもそもUnicodeといえばUTF-16のことで、いまでもUTF-16のことをUnicodeと呼ぶことが多い。
Windows、JavaなどはUTF-16を先進的だと思って取り入れたから、UTF-8への対応が難しい。
UTF-8も一長一短があって、容量とマシンスペックの問題がなんとかなってきたから、UTF-8に向かっているが、この面倒くさいキャラクタセットは、1バイト文字がどのキャラクタセットなのかわからないというデメリットがある。
2バイト以上使う文字では、何のメリットもなく、言葉を表現するには明らかに退化している。 > Windows、JavaなどはUTF-16を先進的だと思って取り入れたから、UTF-8への対応が難しい。
いや難しくはないぞｗ
Windowsは現にUTF-8に対応している >>885
>１バイト文字がどのキャラクタセットなのかわからないというデメリットがある。
>2バイト以上使う文字では、何のメリットもなく、言葉を表現するには明らかに退化している。
全く意味がわからない。誰か理解できる人いる？ 配列の添え字での文字編集はUTF32でもだめな場合があるから諦めるべき
可変長なコードとして扱うようにしないどこかで破綻するよ
まぁ、そういう文字列操作のライブラリでこれ使えみたいのはたぶんないから、自前で用意する必要があると思うが >>888
でも、どうせちゃんとした説明できないんでしょ。規格の用語使って技術的に正確に言える？
文字集合(chatacter set)と符号化(encoding)の違い理解してる？ ちょっと前まで文字コード総合スレは名ばかりの実質絵文字スレだったのに
今は文字コード総合スレは名ばかりの実質BOMスレになったのか >>884
> そりゃそうだろUTF-8ができたのが、JavaやJavaScriptが出来るよりも後なんだから
UTF-8は1992年9月にFSS-UTFとして提案されたのが初出
JavaとJavaScriptはどちらも1995年がファーストリリース >>889
>自前で用意する必要があると思うが
無理ゲーでしょ 単純なUTF-32配列だとEMOJI MODIFIERなどに対処できない。すでにUTF-32でも可変長に対応必須が前提になってる。 >>891
BOMでUTF-8とCP932を区別したい人が暴れてるだけでしょ
BOMにそんな機能ないのに >>895
Unicode signatureとしてそのような用途として使ってよいと書いてある >>890
だから理解してるって言ってるだろｗ
お前が今知ったばかりだからってｗｗｗ >>895
バイトオーダーの無いUTF-8のBOMにそれ以外に何の意味が utf8-bomで保存するソフトもutf8-bomを受け付けないソフトもそういう仕様だと謳えばどっちもありだろう。
自分の主義主張と合わないのは許せないという奴が困ったちゃんなだけで。 >>897
規格はちゃんと読もう。
・UTF-8 のBOMは必要でもなければ推奨でもない。
・それにもかかわらず、UTF-16などからの変換やsignature として、BOMに遭遇するかもしれない
の2点だよ。CP932なんて眼中にないし、「使って良い(may use)」ではなく、「遭遇するかも(may encounter)」だよ >>896
UTF-8がUnicodeに入ったのはUTF-16と同じ1996年だけど
UTF-8がJavaやJavaScriptより前から存在していたことに
変わりはないぞ 規格に入ったことを基準にするならShiftJISは1997年に
生まれたことになるんだけど、それでいいの? >>901
>・UTF-8 のBOMは必要でもなければ推奨でもない。
禁止されてなくて許可されてるのだから
UTF-8 のBOMは仕様として正しいということだね
やれやれｗ
UTF-16の前身のUCS-2のことも知らないようだ
> UTF-8がJavaやJavaScriptより前から存在していたことに
Unicode団体と関係ないところが考えて
まだ標準化されてないものに対応するわけ無いやろｗ >>901
英語苦手なやつのために解説しとくと may encounter の may は「許可」ではなく、「可能性」の may だからな。
これを根拠に使って良いとはならないからな。単に過去の経緯や不出来なシステムの可能性に注意喚起してる項目。 >>903
ShiftJISならそうだろうな
それ以前は別の名前だったってだけだが >>905
使って良いになるだろｗ
可能性があるんだから https://youneedaken.hate
nablog.com/entry/2022/10/11/104904
MAY
MAY (してもよい) は、選択的な要件を表す場合に使います。
OPTIONAL (選択してもよい) も同じ使い方をします。 >>907
お前は、赤信号横断するやつに遭遇する可能性があるって書いてあったら、赤信号で渡って良いって考える？ >>909
赤信号は横断しちゃダメと決められているけどBOMは禁止されてる？ 先に英語の勉強した方がいいんじゃない？
いや日本語の読解力を鍛える方が先か >>904
> まだ標準化されてないものに対応するわけ無いやろｗ
ShiftJISは1980年代に各ベンダーが勝手に実装していて、
微妙に差異があったから1997年にJISで規格化した
UTF-8も1992年にPlan9で提案実装したものを1996年に
Unicodeで規格化した
どっちも実装が先 そろそろ議論を終わろう。テンプレに
Q. UTF-8 に BOM は必要ですか？
A. 不要です。規格書にそう明記されています。
とか入れとけば良いやろ。ここまでなら確定事実なので。 >>909
> お前は、赤信号横断するやつに遭遇する可能性があるって書いてあったら、赤信号で渡って良いって考える？
何言ってるんだ？ 「赤信号は渡っていけない」って書いてあるだろ
赤信号のどこにMAYが出てくるんだよ？ >>913
勝手に実装しているものはShiftJISではない
名前が違う >>916
日本語読めない人かな？
日本語勉強中の外国人かもしれないので丁寧に説明すると、日本語の
「AだったらBですか？」という文はAという仮定のもとでBが成り立つかの論理を問う構文だよ。Aは仮定なんだから真偽とかは誰も問題にしてない。日本人なら小学校低学年の国語で習うよ。
今回のは「Xに遭遇する可能性がある」という命題から「Xしても良い」という結論が導けるかが問われている。Xは任意の変数(BOMでも赤信号横断でも、自己矛盾してなければ何でも可)
あと日本語苦手なら条件反射で書き込む前にさかのぼって話の流れを確認した方がいいね。がんばれ >>918
つまり、UTF-8にBOMを付けてはならないと規格に明記されているなら付けるべきじゃないってことだろ。 >>918
お前のいう喩えはおかしい
× 赤信号横断するやつ（UTF-8 BOM）に遭遇する可能性がある
○ 赤信号で横断しても良い（UTF-8 BOMを使っても良い）が非推奨
赤信号で横断しても良いが非推奨なんてどこにも書いてないのだから
UTF-8 BOMのたと終えになってない
頭悪いならレスバ仕掛けてくるなよｗ >>922
規格には「BOM使って良い」とは書かれないぞ。
規格に書かれてるのは「不要かつ非推奨だがBOMに遭遇するかもしれない」だけだぞ。 https://www.unicode.org/versions/Unicode15.0.0/UnicodeStandard-15.0.pdf
ここの40ページにBOMが許可されてるって書いてある
Table 2-4. The Seven Unicode Encoding Schemes
Encoding Scheme: UTF-8
Endian Order: N/A
BOM Allowed?: yes その仕様書の130ページ
UTF-8 encoding scheme に
While there is obviously no need for a byte order signature when using UTF-8,
の項目を読んでみたら？ >>925
許可（BOM Allowed）は書いてありますが、禁止とは書かれてませんね。
非推奨は禁止という意味ではないですね 翻訳しときますよ
While there is obviously no need for a byte order signature when using UTF-8,
there are occasions when processes convert UTF-16 or UTF-32 data containing a byte order mark into UTF-8.
UTF-8を使用する場合、バイトオーダー署名は明らかに不要（訳注 禁止ではない）であるが、
プロセスがバイトオーダーマークを含むUTF-16やUTF-32のデータをUTF-8に変換する場合がある。
（訳注 つまり UTF-8 に BOM が含まれることがある）
Its usage at the beginning of a UTF-8 data stream is neither required nor recommended by the Unicode Standard,
but its presence does not affect conformance to the UTF-8 encoding scheme.
UTF-8データストリームの冒頭で使用することは UTF-8データストリームの先頭での使用は、
Unicode Standardでは必須でも推奨でもありませんが、その存在はUTF-8エンコーディングスキームへ
の適合性に影響を与えず、UTF-8エンコーディングスキームへの適合性に影響を与えません。
（訳注 ここからも必須でも推奨でもないだけで、適合性に影響を与えないと書いてある）
Identification of the <EF BB BF> byte sequence at the beginning of a data stream can, however,
be taken as a near-certain indication that the data stream is using the UTF-8 encoding scheme.
データストリームの先頭の<EF BB BF>バイト列の識別は、そのデータストリームがUTF-8エンコーディング方式を
使用していることをほぼ確実に示すものと見なすことができる。
（訳注 UTF-8を使用していると確実に示すという意味だから使っていいということ） 結局
禁止とも使えとも明記されてない
書かれているには「不要で非推奨」だな。 Unicodeの仕様としてはBOMは合法
もし禁止してるとしたらそれはそのアプリやサービスの独自仕様 >>929
合法とはまた変な表現を出して来たな。規格の準拠性に影響を与えないと言いたいのならそれは正しい。
でも「不要で非推奨」な。つまり「利用者や通信相手の許可無く使うこうとは >>927
>プロセスがバイトオーダーマークを含むUTF-16やUTF-32のデータをUTF-8に変換する場合がある。
>（訳注 つまり UTF-8 に BOM が含まれることがある）
訳注を善意的に解釈すると
間抜けな変換ツールによる変換時にそのまま先頭のBOMが残ることはあるかも知れないが
新たなプレーンテキストにはBOMは入れないでくれって読めるな >>627
>Unicode Standardでは必須でも推奨でもありませんが、その存在はUTF-8エンコーディングスキームへ
>の適合性に影響を与えず、UTF-8エンコーディングスキームへの適合性に影響を与えません。
>（訳注 ここからも必須でも推奨でもないだけで、適合性に影響を与えないと書いてある）
漏れは改行コードは LF だけ派なんだけど
君は CR+LF 必須だと思ってる？ 読み手がBOM付きデータをどう扱うかは、経営の話であって技術の話ではない。
サービスサポートするファイル形式を減らすことで生じる機会損失の軽重を判断するのは経営の領分であって技術の領分ではないから。 >>935
規格書の話してるのに経営とか言い出すアホ。規格書に「BOMは不要」って書かれてたのがよっぽど悔しいのかね。
規格は法律じゃないんだから、お前は経営判断wで無視してもいいよ。利用者や通信相手が納得してるのなら規格なんて読まなくて良い。オレオレ実装でOK。
ただし技術の話しないんならスレチ、よそでやれ。 >>936
逆だよ。
「BOMをつけるな」は経営の話。
BOMつきにうまく対処することは技術の話。 技術的に対応できるのであれば、
それに対応するのに割くリソースというかコストをどう考えるかが問題になるもんな
BOMなしで統一しているところにBOM付きが紛れ込めば、
必然的にそれに対応しなければならない
その対応分のリソースを他に振り分けることが有用であるから、
「BOMをつけるな」というのはコストの話ではある 切符を買わずに乗ってきた客がいた場合、切符を売ることなく摘まみだすかどうかは鉄道会社や車掌が決めることであって、技術者である機関士の領分じゃないんだよ 「非推奨のものを他人に勧めるな。隠れてこっそり使う分には誰も困らないので、こっそりやれ、ここに書き込むな」
ここまでの結論。 >>932
解釈する余地はない
許可されてるって書いてあるんだから
https://www.unicode.org/versions/Unicode15.0.0/UnicodeStandard-15.0.pdf
ここの40ページにBOMが許可されてるって書いてある
Table 2-4. The Seven Unicode Encoding Schemes
Encoding Scheme: UTF-8
Endian Order: N/A
BOM Allowed?: yes うわー、まだやってんのか？
とっくに結論は出ただろうに、、、 お互いが自分の意見こそ結論だって言いあってるからね 結論はBOM Allowed?: yesとでてるのに
それを認めたくないのでしょう もともと BOM をつけろというやつと BOM は不要というやつがいて、規格に BOM は不要で非推奨と書かれていることが判明した。
BOM をつけろと言ってた側が互換性のために BOM を付けても規格準拠というのを理由に土俵際でねばってる。
どうやっても BOM は不要という結論にしかならないのに。 つけろ派と不要派じゃなくて
つけてもいい派とつけるな派の争いに見えるんだけど >>948
つけろ派は押されてトーンダウンした。
勝手につける分には一人も反対していない。
人に推奨して良いかどうかが今の境界線 >>950
技術的に何が正しいか議論してるのに、話を逸して誤魔化そうとしてるやつがいるだけ。技術的には
「規格では不要、ついでに非推奨。非推奨のものを他人に勧めるな。勝手に使う分には好きにしろ」
で合意が取れるはずなんだが。 >>947
> 規格に BOM は不要で非推奨と書かれていることが判明した。
ちゃんと基礎知識を身につけろ
BOMはバイトオーダーマークの略で、UTF-16などのために作られた仕様
互換性のためじゃねーよ。Unicodeで必要だからBOMが作られたんだろ
でUTF-8は1バイト単位の可変長だから、BOMはいらないはずだって主張するやつが出てきた
ところがどっこいBOMにははUnicode Signatureの意味があることが判明した
（知っている人にとっては常識）
そしてUTF-8でBOMは仕様違反だとか禁止とか言ってるやつのトーン下がって
「非推奨だから付けたらだめ」みたいな屁理屈を言い始めたが
PDFにBOM Allowed?: yesという文言が見つかって、ゲームオーバーっていうのが
これまでの流れだ >>951
ちゃんと「規格で許可されている」って書こうね
これは事実なんだから
それができないから、嘲笑されてる お前ら何もわかってないな
各サービスに複雑な文字コード自動判定処理が追加されたことで、
UTF-8/16/32であることをオレオレ自己申告して複雑な文字コード自動判定をスキップするBOMの存在価値はかえって高まったのだ >>952
脳内で歪んだか？
過去レス見直しても「規格に禁止と書いてある」と主張してるやつは一人もいないぞ
「規格に不要かつ非推奨って書いてある」と主張してるやつは多数いる >>953
だから勝手につける分にはつけていいだろ。
「許可、不要、非推奨」なのは認めるんだな？ 復唱してみろ。 >>955
だからなんで「規格で許可されている」を消すんだよ？
「規格で許可されているが、必須ではなく推奨もしていないと書いてある」だろうが
Its usage at the beginning of a UTF-8 data stream is neither required nor recommended by the Unicode Standard,
but its presence does not affect conformance to the UTF-8 encoding scheme.
UTF-8データストリームの冒頭で使用することは UTF-8データストリームの先頭での使用は、
Unicode Standardでは必須でも推奨でもありませんが、その存在はUTF-8エンコーディングスキームへ
の適合性に影響を与えず、UTF-8エンコーディングスキームへの適合性に影響を与えません。
neither required nor recommended
→ neither 必須 nor 推奨
→ 必須ではなく、推奨でもない
不要は unnecessary だ
訳ぐらい間違えんな >>956
「許可されている。必須ではない。推奨されていない。」と認めるわけだぞ。
BOM Allowed?: yes
neither required nor recommended
書いてあるとおりだ。 >>946
付けろとは描いてないだろ
それがすべてだ >>958
それでいいよ。技術的には不要でも必須でもないでも同じ意味だ。
必須でなくて非推奨なものの他人につけろっていったり、対応を要求したりしなければOK。 >>948
つけてもいいということはつけなくてもいいということだ
要らないものをつけるためには理由が必要
その理由があまりにもくらだんから全部却下されてるのが今の流れ > 要らないものをつけるためには理由が必要
だから何度もUnicode Signatureって
書いてあるって話をしてるんだがな 文字コードが統一されているシステムなら(意味が無いから)BOMは付けない
他の文字コードも扱うシステムなら(識別子として)BOMを付けるか検討する
で良いじゃん 書き忘れた
他の文字コードも扱うシステムでも、文字列以外から文字コードが分かるならそちらを使い、BOMは付けない
BOMが欲しくなるのはSJISとUTF-8等が混在するWindowsのファイル
ファイルのメタデータとして文字コードが設定出来れば良いのに windowsなら
hoge.utf8.txt
hoge.sjis.txt
で解決
しらんけど ファイルの拡張属性にでも，TextEncoding を加えておけば良いんでは？ いや、そこまでしてBOMを避ける理由がわからん
BOMでなければなんでもいいのかよw >>968
好きな理由1つ選んで
・UTF-8の最大の特徴はASCIIと上位互換、BOMをつけたら台無しになる
・今はUTF-8 はBOM無しが主流
・将来の外部コードはUTF-8のBOM無しになることがほぼ確定している
・移行期だけのために余計なものをつけたくない
・BOMつきだと動かないシステムがある
・文字コードの自動判定はバグやセキュリホールの温床になるので削除したい
・SJISとか時代遅れのものはもう使用してない
・BOMの曖昧さはセキュリティホールになる可能性がある
・ZWNBS との曖昧さがいやらしい
・規格で非推奨のものは避けたい
・ファイルの接続とか分割やファイル名操作などに曖昧さがあるのはいや
・不要なものを付ける理由が思いつかない
・とにかく嫌い
他にも理由はあるだろうけど、人それぞれ BOMを付けておくと都合がいいケースがたまたまあっただけ ・移行期だからこそBOMで他のエンコーディングと区別できるようにしておきたい場合がある
・BOMなしだと動かないシステムがある
・文字コードの自動判定はバグやセキュリホールの温床になるのでBOMを付けておきたい
・SJISはJIS X 0208で標準化されている現役の規格
・今のUnicodeの規格ではZWNBSP(U+FEFF)ではなくWORD JOINER(U+2060)の使用が強く推奨されているのでBOMとの曖昧性は起きない
・規格で許可されてるものを無理に避ける必要はない
・許可されているものを避ける理由が思いつかない すべてはカネ次第。カネを出す人が決めればいいだけ。つまり経営マターってこと。 > ・文字コードの自動判定はバグやセキュリホールの温床になるのでBOMを付けておきたい
BOM付けてリスク変わる？ そりゃ変わるだろ、BOMが付いてれば判定ミスがなくなる BOM見てUTF-8だってのは自動判定の一要素でしかないしBOMなし対応いらなくなるわけじゃないから変わらないと思うんだけどな
ユーザー視点の話なら一つ前のと同じこと言ってるわけだし >>975
ゴールポストを動かすように自動判定の定義を動かすのはみっともないからやめとけ >>975
BOMは99.999%正しく判定できる自動判定だよ
実質完全に判定できるといっても過言じゃない。 >>977
自動判定のセキュリティ・リスクはそういうところじゃないよ。認識率100％でも起こる、むしろそっちが攻撃に使い易い。セキュリティまわりは勉強したことない素人が思いつくほど単純じゃない。 >>978
BOMによる自動判定だけなら先頭の数バイトの固定パターンを見るだけの単純なものだから
バグの入り込む余地はかなり小さくなるだろ >>978
つまり世の中のテキストエディタからEUC-JP対応を削除しろって話をしてるの？ 仕様で文字コードが固定されていようがBOMで判断しようが
不正データを読んで変なことにならないようにすることと全く関係ないだろ
もしかして「文字コードの自動判定」という機能単体の話でBOMチェックだけならば堅牢だって趣旨だったのか 「文字コードの自動判定にはセキュリティリスクがある」
↓
BOMによる判定も自動判定だ
↓
だからBOMにセキュリティリスクがある
なにこの三段論法w BOMがあればデータチェックをスキップしていいと考えるやつがいることを想定するなら確かに心理的セキュリティリスクが存在することにはなる
でもそんな話はしていないんだよなあ
俺の起点は>>971に対するものでこれは>>969を受けてのものだから最初からBOMによる自動判定の話だし >>984
すげー単純な例だとバイナリファイルの先頭に UTF-8 BOM つけてテキストに偽装、ファイアウォールやウィルスチェックをすり抜ける。うかつなソフトが自動判別してBOMを外して次段に渡してマルウェア発動。
アホみたいだがこんなんで実際に被害が出てるんだぜ。実際はこんな単純じゃなくてもっと複雑で発見され難い攻撃ができる。 >>971
ZWNBS についてだが uniccode standard には
「BOMが不要な場合には先頭の U+FEFF は後方互換性のために ZWNBS と解釈される」という規定がある。
これと「UTF-8 に BOM は不要」という規定を合わせると...入力処理系の実装はどうなる？ 曖昧さがあるだろ。 >>986
BOMをなくすとバイナリとして扱うのか？
それともテキストして扱うのか？ >>987
まずお前の言う「入力処理系」が何なのか説明しろ
「あれが困る」みたいな曖昧な言い方をするな バイナリとして扱ったとしてもデータとして使うのか?
それとも実行可能ファイルとして使うのか?
後者はもう BOMの使い方を大きく離脱しているな >>980
ついでにSJIS対応もISO2022JP対応も削除で お前だろ
ってかBOMは許可されてるのに
そういう例外を持ってきてわーわー騒ごうとするのは頭が悪い シェルスクリプトが万が一BOM付きshebangを解釈するようになったとしても
catはどう処理されるんだろ
面倒だから止めてるんだろうな 昔のmsysのcat.exeは0x0Aを勝手に0x0D0x0Aに変換して出力する仕様だったので、人知れず泣いた人多かったんじゃないかと思う
>>997
BOMをスキップするオプションとか追加すれば対処できるんじゃまいか binaryオプション付けなければwin上で0d0aにされても文句言えない罠
しかしデフォでbom無であるべきで
デフォがbom付になるのは許すまじ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 972日 15時間 57分 1秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
