■これまでに行われた議論
・WinでCP50220 は Unicode からマルチバイト文字への変換でいわゆる半角カタカナを全角カタカナに置き換え
内部的には Unicode -> CP932 -> CP5022ｘ って変換な気もする
・人名をソートかけたらバストサイズ順の並びになる？
・Shift JIS や EUC-JP や Big5 や GB なんかをUnicode に変換してしまうと、ラウンドトリップは保証されるか
・単一情報をソースの文字コード(or 言語)情報なしに元に戻したい （統計的に文字の出現確率なんかを調べる）
・PC-98x1シリーズのMS-DOSはShift_JISだが漢字ROMはJIS、変換は何処で行っていた？
・0x5cをUnicodeにするときにバックスラッシュに置き換えるか円マークに置き換えるかで、逆変換時に結果が変わるの問題
・丸付き数字は機種依存文字か？。MSIME2007ではCP932に収録されてない文字は「環境依存文字」って表示。
Macではフォントによっては表示されないし、フォントによっては表示される
・Shift_JISと名乗っているCP932やISO-2022-JPと名乗っているCP50220を表示（Unicodeに変換）する際に
機種依存文字はサポートされるか？
・Safari文字コード変換のバグは
・Microsoft文字コード変換のバグは
・U+31F0..U+31FF（アイヌ語表記用小書きカタカナ）が入ってない件
・なぜ携帯業界はunicode化しないのか？
・このスレへの書き込みはブラウザが2chへ送り出す時点でUnicodeからShift_JISに変換しているのか
・文字化けに強いishフォーマットでエロ画像を交換する場合、ssより、s7のほうが化けにくい
・中国語の簡体字では、へんやつくりが簡略化されるなら、その文字も自動的に簡略化して表記する国家規格が有る
・中国語の「噁心」簡化政策によると「恶(U+6076)」に統一。口偏＋恶(U+6076)は普通に使われているがUnicodeにはない
・日本人のニーズが満たせないのも確かなので原規格分離（中国では「曾→曽」は簡体字と繁体字の違いとはみなされていないとか）
・UNICODEを扱うプログラムはサロゲートをぶったぎられた入力が渡されてくる場合にも備えろって→YES
・UnicodeとUTF-8の違いは？
・日本のCJK Ext.D Submissionに{魚針}が含まれてる件
U+9C75(魚箴)は強烈。いくら何でも違いすぎる。(魚針)
ひょっとしたら後で実は別字だったとか日本では異体字だが中国では別字とかになるかも知れんぞ。
中国ではってレベルじゃねーぞ。
・Windows Vista での「IME パッド - 文字一覧」の「JIS X 0213 （1面）」のバグ
UTF-16: 0x304B 0x309A → Unicode: U+FD61809A （間違い） （ISO/IEC10646はU+10FFFFまで）
サロゲートペアからコードポイントを引き出す計算を無理やり適用（間違い）
((0x304B - 0xD800) << 10) + (0x309A - 0xDC00) + 0x10000が 0xFD61809A になる。
・文字コードではインドカレーは飲み物か否か。カレーパンうまうま。
・CJK混在の漢字環境ってどうやって、切り分ければいいの？ → ムリです。
・Winzipで保存されるファイル名が文字化け→zipではコードページ情報が無い。直接zipファイルから切り出せ
・Unicodeは言語情報を直接扱わない。 多言語の混在表現は（unicodeでは）できないか
・Unicode文字列リストを各国言語を考慮してソートしたいんですが → ムリです。
・Unicodeサニタイズが面倒になるのか
・SJISとUNICODEの判別はどのようにすればいいですか？BOM。無ければ、統計判断。 ライブラリを使うが吉
・ところでケータイのUnicode対応度って実際どうよ？ → ウンコマークもUnicodeに追加されるんだな。
・WindowsXP で フォルダに使用できないフォルダ名はどうやって判定
→ ちょっとアホな方法だけど、%TEMP% フォルダの下で実際に作ってみて。本当に作成できるかどうかで判断。
・TwitterのWebインターフェイスからだと、サロゲートペアは2文字としてカウント。140字打てない 。
・Unicode 5.2で追加されたUnicodeSMP(第1面)、Unicode 5.1で未定義だったSMPのコードポイントや第15、第16面が
Windows7では表示されない。 → 和田研細丸ゴシック2004ARIBはARIB外字を含んでいる。
・WindowsXP SP3でMicrosoftのJIS2004フォント環境でサロゲートペア文字が表示されない。→
コントロールパネル-地域と言語のオプション-[言語]タブで
「複合文字や右から左方向に書く言語 (タイ語を含む) のファイルをインストールする」にチェック
・URLの%で続く2桁の0-9、A-Fへの変換は、UTF-8→urlencodeによる。RFC1738を嫁。
・菊紋、桐紋、葵紋などは文字か？海栗コードへの挿入は難しい。そこでTRONだ！！
・元号を安置する場所はJIS第三で確保済み。ウニコードでブロックを確保は政治力次第。
・元号は個人名ではない。特定の時間軸基準に数える年号を漢字で指す文字。
陛下の崩御後必ずしも元号が追号になるわけではない。むしろ違う場合が多い。昭和54年法律43号の元号法参照。
・文末でなければ"0"+ASCII7ビット、文末なら"1"+ASCII7ビットというエンコード。 → ヌル1バイトが貴重な時代からの負の遺産。
・Windows7出荷時に未定義だったコードポイントはフォント入れても豆腐になる。Unicode5.2は表示しない。欝だ。
・Unicode6ドラフトでPILE_OF_POO文字確定。ウニコードがもはやイミフ。SerifとSans-Serifで幅に違いは出る？
・shift-jisからUTF-8変換でサイズ1.5倍。でも圧縮すれば平均10％増加程度。用途に合わせて使うべし。
・「wchar_tは>849の嫁。>849の許可無くしてUTF16だの32だの無理矢理突っ込むのは許さん。」
・電子演算機では文字化けなんて飾りです。UTF-8/UTF16の人にはそれがわからんのですよ。
■単語一覧
・UTF-16は16ビット単位にエンコードするけど、サロゲートペアがある
表現できる文字空間はUTF-8と同じく20ビットとちょっと
・丸付き数字は機種依存文字か？MSIME2007ではCP932に収録されてない文字は「環境依存文字」って表示。
MacJapaneseではフォントによっては表示されないし、フォントによっては表示される。
今のMac（内部Unicodeアプリ）は、フォント依存ではなくアプリ依存。
似非ISO-2022-JPや似非Shift_JISのドキュメント中の丸付き数字は、
素直にAppleのAPIを使ってるアプリならゲタ（U+FFFD）になる。
・Mail.appではISO-2022-JPに収まらずCP932に収まるメールは、含まれる字種によって
charset=CP932で送信される場合とISO-2022-JP（もどき）で送信される場合がある
・MSでのウニコードとSJIS変換のバグ。
U+007E TILDE <-> Shift_JIS 0x7E OVERLINE
U+301C WAVE DASH -> Shift_JIS NA 【MSの問題】
U+FF5E FULLWIDTH TILDE <-> Shift_JIS 0x8160 WAVE DASH 【MSの問題】
・SafariでのウニコードとSJIS変換のバグ。
U+007E TILDE -> Shift_JIS 0x8160 WAVE DASH 【Safariの問題】
U+301C WAVE DASH <-> Shift_JIS 0x8160 WAVE DASH
U+FF5E FULLWIDTH TILDE <-> Shift_JIS NA
・winzipの規格ではファイル名のコードページ指定もしくは記録情報が存在しない。
解決策：取り合えず、MSWin+JPではShift-jisでファイル自体には保存されている。
MACOSX=Unicode,Unix=UTF/EUC/S-JISどれでもありえる。文字に関係なくLocalLangで
再変換しているので、それをしなければよい。
・charlenでの文字列長の判定はプラットフォームにより返り値が違う（機種依存文字等）。マニュアル嫁。
・JISのエスケープシーケンスが正しく認識されない本文とか。
'0x1b, 0x24, 0x42' という3バイトを先頭に、'0x1b, 0x28, 0x42' を末尾に追加汁。
あるいはhttp://masaka.dw.land.to/mr/jmr.phpとか。 取り敢えず復活させてみた
テンプレ？多すぎサーバ重すぎ
>>1
U+30B9 U+30EC U+7ACB U+3066 U+4E59 >>1 乙π
＜前スレのおさらい＞
ユニコードにきちんと対応してほしいフリーソフトは多い
IrfanView
Lhaz
FileSum Irvineはファイル名はスクリプトでなんとかなるけど階層フォルダは化けたままなんだよね
IrfanView 64bit はユニコード未対応
IrfanView 32bit はユニコード部分対応 (難有)
IPAmj明朝最新バージョンキター
変体仮名も使えるようになってた。
IPAmjはcmapを足しただけかな
濁点半濁点つき変体仮名のグリフを追加したわけではなさげ
きの𛀁【甲】
ひの𛀁【丙】
つちの𛀁【戊】
かの𛀁【庚】
みづの𛀁【壬】
そういえば変体仮名って絶対漢字のフォントバリエーションとして使われるな。
ラテン文字のところをキリル文字ギリシャ文字でちょっと異国情緒出したりするのと同じように
OS標準のフォントに変体仮名が入るのはまだ先の話かな。
Mac/iOSはAJ1準拠のフォントをバンドルしてるだけだから変体仮名のサポートもAJ1次第だろうな
AndroidもNoto CJKをバンドルしてるだけだからこっちもやはりフォントを作ってるAdobe次第か
Winはゴシック系フォントはUnicodeをフルカバーしようとしているようなんで可能性ありそうだけど
明朝系は1B000～1もスルーしてるんで変体仮名も放置と予想
28デフォルトの名無しさん2018/02/02(金) 07:09:07.07
変態さんかな？
変体仮名がOS標準のフォントに入ったら
ハンドルネームとかAAに使われるかな
よく有料フォントに正規版とお試し版があるけど
この２つのフォントファイルってシステム的に共存できるの？
それとも後から入れたほうに上書きされちゃう？
Windowsの場合フォントの内部名が違えば共存
同じなら上書き
上書きできたっけ?
先に入ってる方を消せって言われた気がする
思いついた絵文字を定期的に追加する文字コードになってしまったな
そのコードポイントは昔、□デを入れる事が提案されたが
○ンとか他の重要な文字の為にとっておくべきとかでSMPに追いやられたなんて事があったな。
元号組文字が重要な文字だと認められればそこになるだろうけど。
元号エリア用意して連番にするとして
何文字用意すれば良い？
44デフォルトの名無しさん2018/02/09(金) 19:31:27.80
>>43
とりあえず127個もあれば人類滅亡まで持つと思う U+32FF ??
U+337B 平成
U+337C 昭和
U+337D 大正
U+337E 明治
ここに入れるとコードポイント逆順でソートできるという利点が
あくまでもあれらは他の規格との互換用で通常は使用する事が推奨されていないのだがな。
たとえば平成はU+337B(㍻)を使うのではなくU+5E73(平)とU+6210(成)を並べる事が推奨されている。
最近では昭和時代～平成初期とは違ってワープロソフト等で任意の組み文字を表示、印刷するのが容易になったし、
使用出来る容量も多くなって1文字分のバイト数でも減らしたいなんて事は少なくなったし次の元号の組み文字は入るだろうか?
JIS X0213とかに入ればUnicodeにも追加せざるを得なくなるだろうが。
そういえば康熙部首とIDCに挟まれたU+2FE0～U+2FEFって空いてたよな。
どうしてもBMPがいいならそこを元号専用ブロックにするのはダメなのかな?
名称はJapanese Era NameとかGengoとかで。
16個あればよほどの事が無い限り今生きてる世代が生きてる間は大丈夫だろう。
絵文字の一種としてなら完全に新しい組文字でもすんなり入れられそうな雰囲気ある
そもそも元号に限らず組文字のコードはあまり使われないよな。
昔から機種依存文字(環境依存文字)だから使うな言われてきたのもあるけど。
でも明治、大正、昭和、平成の組文字㍾㍽㍼㍻はあるのに、
○○(新元号)が無いのはおかしい。UnicodeではBMPでないといかん。なんてゴネる人が出てくるのかな。
>>53
Unicodeの日本部隊はルール無視してでもねじ込みたがりだからな
今後も考えた上で場所を決めてほしい
過去のがないのは元々がJIS定義の字を収録してるだけだから
JISがこれからどうするかに歩調を合わせるべきだと思うけどね CJK統合漢字拡張GはSIPに入り切らなくなったからTIP(第3面)になるんだな。
古代漢字等がU+30000～に提案されてたが、それらはずれる事になるようだ。
で一昨年末に正式名称が決定したあのニホニウムを含む4元素の中国語名の漢字のうち
現時点でUnicode未収録なのは拡張GでなくURO末端部に追加する方針らしい。
68デフォルトの名無しさん2018/02/18(日) 09:20:31.63
合字なんて百害あって一利なしと判明
70デフォルトの名無しさん2018/02/20(火) 00:53:22.06
たかが文字のために複雑な処理を強いるからこういうことになる
合字なんてやめてビットマップで用意すりゃいいだろ
今の時代、そのくらいのリソースの余裕はあるだろう
単純な絵文字ならLINEスタンプの如く画像でもいいけど
そのテルグ語というのは文字を画像にしたところでどれほど処理が簡便になるのやら
うにコードって何でいっぱいあるの？
どれで保存しますかとか言われても知らんがな
UTF-16があれば十分だと思ったこともありました
>>76
UTF-32 でも全漢字を収録するわけではない
(文献学・学術用途には足りない）
のが悲しいところです UTF-8でもUTF-16でもUTF-32でも表せる文字数は同じはずだが
UTF-16の限界に合わせてUTF-8とUTF-32を途中から制限したというべきか。
>>75
BOMなしのUTF-8が選べればベスト
無理ならbigendian 81デフォルトの名無しさん2018/02/28(水) 21:23:27.95
>>79
ハァ？
UTF-32ならUTF-8の4倍の文字を表せるはずだろ >>80
あんがとー
＞ Windows付属のメモ帳では標準でBOMが追加されてしまうらしい
うにコード 詰んどるやんけ… 詰んでるのはメモ帳の方で
うんコード自体はまだ希望ある
>>76>>77
語りたくてしょうがない具合がキモいな wchar_t楽チンでいいんだけどなあ
UTF8なんてアメリカ人はASCIIと区別してないだろ
教育漢字フォントはわりと色んなメーカーから出てるが
>>92-94の反応を見ると知らない奴は知らない模様 IPAなんてまぎらわしい名前付けやがって大迷惑だわ
今からでも略称変えてほしいわ
19世紀からある団体と被せやがって
情報処理推進機構だから JSK にすればいいのに
なんか文字面ええやん
先日日本語キーボードに変えたら\でエスケープ出来なくて焦った
そして今まで知らぬうちにUnicodeでコード書いてたのに気付いた
もうバックスラッシュ=\の時代で無いんだな…
ちなみにMACだけどバックスラッシュはオプション+\で出せる
こんなアホ他に居るか分からんので役に立つか分からんが…
>>107
俺には「\でエスケープ出来なくて焦った」の\が本来言いたいであろうU+A5ではなく
ちゃんと5Cになっているように見えるんだが…… 112デフォルトの名無しさん2018/03/22(木) 06:22:34.04
>>111
ここは5chだからな
¥と¥の区別が付いてたまるか 117デフォルトの名無しさん2018/03/22(木) 12:06:59.42
2chブラウザの実装によるとしか
ちな>>112はBathyScapheからの書き込み まぎらわしいから5ちゃんじゃなくて005cHか0x5Cって書いてくれ
0x5c に限らず、ASCII 文字列は国によってフォント上さまざまに実装されてきた
Unicode の時代には、そんなフォントは存在してはいけないし、使用してもいけない
ASCIIもISO/IEC 646もJIS X 0201も
よもや半世紀50年(以上)も使い続けることになるとは思うまいて
ISO-2022シリーズはとっとと滅びてほしいんですが
>>115
本人だけど深読みし過ぎ
ガラケーだからユニコ(即ちバックスラッシュ)打てないだけです ＼と打ちたかったけどガラケーなので入力できなかったということか?
>>107は Macの日本語キーボードで\と入力するつもりだったのに
＼になってたということか? >>129
ああ全角の＼ならガラケーで打てたな
US仕様では当然半角＼キーで素直に半角＼が出て表示される、但しASCII環境ならASCIIで、ユニコならユニコで
長く日本仕様を離れていたので、昔の半角＼=半角￥という読み替えの古い常識で考えてしまい、
エスケープ用に半角＼の代用として半角￥記号を用いてしまった
しかし今やIDEもユニコで保存される時代(少なくともうちのは)、半角￥と半角＼はもはや違う文字なので別に扱われてしまった、と
ほんのつぶやき気分で書き込んだのになんか紛糾させてしまってて申し訳ない… 131デフォルトの名無しさん2018/03/24(土) 22:10:16.18
結局、業務でプログラミングするためのデスクトップ環境はWindows一択ってこと
日本語版ではキーボードの \ 打っても \ 打っても出るのは円記号だし
フォントも U+005C は全部円記号に直してあるから徹底してはいるよな……＞Windows
134デフォルトの名無しさん2018/03/25(日) 08:12:07.62
>>133
業務はWindows一択
個人でのプログラミング・ゲーム・動画編集はWindows
個人でのインターネット閲覧はMac
Macだと住所入力とかでシステムが求める全角ハイフンが入力できなくて困ることもあるけどそういうときはコピペで何とかしてる ウェブ屋さんはMac率200%くらいじゃないだろかね。
昔はWebObjects使うからMac、なんてのも聞いたけど、今はなんでMac選ぶんだろうね。
全員にMACBOOK一括支給されてるけど供給が大手で滞らないし管理しやすいからだろう
新品の充電器と本体のストックあり
せっかく準備期間を十分確保できる改元なのに新元号の公表を
極力遅らせようとするなんてどうかしてる
>>139
＞Shift-JIS 対応に関するお問い合わせも複数頂戴しており
Shift_JISは滅びぬ！何度でも甦るさ！ 昭和のときは平成の文字コードあらかじめ空けてあったんだよな
UNICODEではその辺のセンスないのか
144デフォルトの名無しさん2018/04/04(水) 17:37:38.50
>>143
ん？200個くらい空けてあるって確かこのスレで教えてもらったけど？ 145デフォルトの名無しさん2018/04/04(水) 17:39:15.43
空きが250あるかどうか知らないが日本の元号は既にそのくらいあるな
空けてあったんじゃなくて当時のJISコードがスカスカだっただけ
今回だって別にBMPにこだわらなければ場所はいくらでもある
>>146
どうせ良くも悪くも元号合字があるなら、せっかくだから過去のも入れてほしいなあ。南北朝のをどういう順番にするのがいいのかわからないけど。 >>148
南北朝のはスレッド二つにするべき
そこまでするならコードだけじゃなくて期間の情報も欲しい 文字以外のものを平気で文字コードに入れようとするような奴がいるからUNICODEが糞になったんだろうな
151デフォルトの名無しさん2018/04/07(土) 21:58:57.93
それな🙋絵文字を増やす動きは馬鹿すぎだわ🤔
絵文字なんざ煽るときとかおちょくるときにしか使わないんだから🤣
154デフォルトの名無しさん2018/04/08(日) 12:38:11.74
そんなん差別だろ😡全人類の顔を入れろや😤
>>153
どの天皇よりも聖徳太子のほうが使える気がする そういえば、たまにみかけるヨコハマタイヤのマークみたいな顔の活字ってUNICODEには入ってないのかな。
>>156
「写植記号BA-90」のことなら、一応ユニコード上では「U+1F31D FULL MOON WITH FACE」に相当するっぽいけど、そのままのデザインで収録しているフォントは無さげ
「GL-アンチックPlus」というフォントには私用領域のU+E012に収録されてるみたい
違う文字の話だったらゴメンね 日立のベーシックマスターもひらがな表示できたよね。
>>161
もしかして、EUC-JP の半角カタカナのことを言ってるのかな？ と思いながら元記事を見たけどよく分からん。
少なくとも「サイズが１」というのは「文字幅が1 (いわゆる半角文字)」と言いたいのだと感じた。 あーπだったか
πにしてもこの限られたなかに入ってるのはちょっとふしぎだ
>>162
MSXにはバッククォート ` もあるんだな
S1にはなかった… みなさんありがとうございました。
恐らくMSXの日本語文字のことのようですね。
確かにJISの「半角カタカナ」（というと某氏に粘着されそうですが^^;）は良く聞くのですが
ひらかなやまして漢字が１バイトで表現されていた時代もあったとは知りませんでした。
勉強になりました。
>>172
どうせ過疎スレなんだから答えてやれよハゲ 176デフォルトの名無しさん2018/04/11(水) 08:02:05.13
俺はハゲてる(´・ω・｀)
あの時代はVRAMに直接アクセスしてフォント書き換えるのが可能だったから漢字作るのも可能だったよね
まぁデフォルトて漢字用意してたのはMSXくらいしか知らないけど
普段使わないasciiコード255に「笑」を割り当てていたのを思い出してちょっと恥ずかしくなってみたり
>>178
そりゃPCGだろ。書き換えるための仕組みとして用意してたんだよ。
VRAMに書けるからどんな文字も表示できるってことなら今だって同じだ。 >>179
月火水…とかはMSXのと文字コードは違うけど並び方は同じだし
ひらがなとかは文字コードも同じだな >>162 >>180
細かいこと端折ってしまったみたいで済まなんだ
VPOKE命令だからてっきりVRAM直なのかと思ってたよ >>179
セミグラフィックの文字，今じゃほとんどUnicodeに収録されてるなぁ（もちろんUnicodeがPC-6000を念頭に置いてる訳ではないけども）
と思って眺めてたら，Unicodeに無さそうな文字が。
1/8-7,8,9の総和記号を三分割した文字は多分未来永劫Unicodeには収録されないだろうから，
完全にPC-6000独自の文字として歴史に残るねw そこまで大袈裟に言う必要があるかどうかは不問にするとしてさ。 セミグラフィックス
>>184
こんなのでフフッってなってしまった。
まだ4月始まったばっかりなのに疲れてるのかな… >>181
同じCGROM使ってたとか何か理由ありそう
P6の方は60の`を欠いてたけど >>183
あれ、確かUCS/Unicodeにも入ってなかったっけ？
……と思ったらUnicodeに入ってたのは三分割じゃなくて二分割だったか。うーん残念？
U+23B2 ⎲ SUMMATION TOP
U+23B3 ⎳ SUMMATION BOTTOM UCS/Unicodeっていう表現はどういう意味？
191デフォルトの名無しさん2018/04/14(土) 09:40:32.83
>>189
GNU/Linux みたいなもんだろ
知らんけど ISO-2022-JP/MIME
みたいなもんだと思ってた
>>189
微妙な違いはあれど「ucsやunicodeなどと呼ばれてるもの」みたいな意味で使ってるんじゃないかなー。
x64/amd64みたいな？ 戦争の場が宇宙に移ったということだろう
水鉄砲というよりもSFにありそうなレーザーガンっぽいしw
過去の文献のニュアンスが変わってしまいそうだが大丈夫か……
203デフォルトの名無しさん2018/04/27(金) 07:59:57.84
卍が表示できなくなるのはいつですか？
絵文字のデザインなんて前からコロコロ変わるゆるふわなものだってことじゃないの
U+1F3B1 BILLIARDS は例示ではキューと積まれたボールのデザインだったのに各メーカーは何が気に入らなかったのか知らんけど「8ボール」のデザインで実装
仕方ないので Unicode 12.0 では例示字形を変更し元々のキュー&ボールは U+1F93F BILLIARD GAMES として新たに追加(予定)とか
もう何でもありだなって思うわ。
元々auの絵文字が文字名はモヤイだけどグリフイメージがモアイだしなあ
そんでもってdocomo/Softbankへ送ると[モアイ]になるんだっけ？どっちだよｗ
新元号への対応に向けた検証とテスト ケースについて
https://blogs.technet.microsoft.com/jperablog/2018/05/01/test-case/
現時点で新元号は発表されておりませんが、新元号に対しても合字を用意すべく、
弊社では Unicode コンソーシアムや日本政府、業界団体とともに
Unicode 上の文字コードの確保や新しい字形の作成、フォントの更新について準備を進めております。
新しい合字のコード ポイント等については未確定の状況でございますが、
今一度、下記のような合字の表示、入力に問題がないかご確認ください。
また新元号の発表後に追加される合字を正しく表示するためにはフォントの更新 (合字のグリフの追加) が必要となりますため、
アプリケーションにてご使用のフォントについても確認が必要と想定されます。
- ㍻ (U+337B)
- ㍼ (U+337C)
- ㍽ (U+337D)
- ㍾ (U+337E)
また、合字を含めた検索や並べ替えについては、少々考慮が必要です。
弊社の Web 検索 "Bing" では、"㍻" を検索した際 ”㍻” と ”平成” の両方が検索されます。
一方、Word では "㍻" の検索の際には "㍻" のみが検索されます。
検索や並べ替えの動作についても正規化処理の状況によって異なる結果となることが予想されますため、
ご確認をいただくことをお勧めいたします。 213デフォルトの名無しさん2018/05/01(火) 21:40:31.70
年号に合字コード用意するのやめようぜ
普通に2文字使えばいいじゃん
どうしても組文字にしたければフォントじゃなくて
ワープロソフトとかDTPソフトにやらせてくれよ
フォントで合字するのは別にいいよ
わざわざ文字コードに入れるのがアホなんや
>>214
その「元号のサポート」って機種依存文字エリアに合字の年号を入れることを指してる？
時刻の表示形式の「平成XX年XX月XX日」みたいなののことじゃ・・・
合字は伝統文化じゃないよね別に 合字に関しては、直前２文字の表示幅を半分にする制御文字を追加すればいい気がする。
絵文字で肌色指定する制御文字がすでにあるので、それと同じ。
システムにフォント表示幅を変える機能が必要ではあるけど。
>>219
＞絵文字で肌色指定する制御文字がすでにある
そんなものあるの？Unicodeの理念からどんどん遠ざかっている気がする >>220
肌の黒い中国人とか表示可能。
👲👲🏻👲🏼👲🏽👲🏾👲🏿 あー失礼。直前2文字ごとじゃなくて直前1文字ごとに設定すればいいだけか。
223デフォルトの名無しさん2018/05/04(金) 00:29:10.94
>>219
ゼロ幅接合子が漢字を対象に使われた場合は、その漢字同士で合字を作るようにすればいい 1文字単位で半角幅化できれば合字いらなくなるでしょ。
文字幅セレクタなんてもんができてしまったら
EAWもfullwidth領域もなんだったんだってことになるだろw
227デフォルトの名無しさん2018/05/04(金) 09:03:45.93
単純に幅半分にしたら縦と横の線の太さがチグハグになりそう
フォント屋が頑張って調整すればいいか
>>228
白黒の2色じゃなくて中間色を使うアンチエリアスが必要。
フォント屋の仕事じゃなくてOSレベル(例：WindowsのClearType)の範疇。
印刷時の見栄えを一致させるには、当然、印刷機も中間色への対応が必要。 正体を単純に長体にすると視認性が落ちるからとCondensedやCompressedな書体を作ってるデザイナーが見たらガックリくるような話だな
このネタいつまで引っ張っても元号に文字コード割り当てようという考えが如何に頭が悪いかということを思い知らされるだけだ
235デフォルトの名無しさん2018/05/05(土) 09:14:26.61
これでその時点の元号を表示すればいいのか
<日本の元号を表すコード(共通)> <西暦年(100の位 : 6～20)を表す制御コード> <西暦年(0～99)を表す制御コード> <月(1～12)を表す制御コード> <日(1～31)を表す制御コード>
文字コードとプログラミングの区別ができない人は、このスレに書き込まないほうがいい。
>>235
順序はあるんだから
日本の元号を表すコード(共通)> <順序数コード>
で済むよね 全角文字を半角の幅で表示したい潜在需要は、中国や韓国にもあると思うます。
7pt文字から36pt文字までコードを割り当てれば十分だと思う。
243デフォルトの名無しさん2018/05/06(日) 02:15:11.15
>>239
<日本の元号を表すコード(共通)> <王朝を表す制御コード> <西暦年(100の位 : 6～20)を表す制御コード> <西暦年(0～99)を表す制御コード> <月(1～12)を表す制御コード> <日(1～31)を表す制御コード> 「制御コード」？ 普通の2進コードじゃイカンのか？
245デフォルトの名無しさん2018/05/06(日) 07:32:19.99
Unicodeの仕組みをよく知らないので
普通の2進コードを書けるならそれで
そんなコード作ったところで検索もできないし、妄想の域にすらない
そもそも漢字で書ける元号に合字が必要かって話だし、まったく方向がおかしい
ID隠してる奴なんてあぼーんしとけ
おかしなやつに構う奴も荒しだからな
Unicodeの次の概念とかはまだないのかな。それとももうみんなUnicodeに満足してしまっているのかね。
universeの次がmultiverseなんだから次はmulticodeだろうね。
それかikuracode
Progressive Unicode、略してPunicode
glicoodeというやつが開発されてなんか賞取ってた気がする
もう変な合成記号類は多数あるし、漢字合字開始、漢字合字終了の2文字だけ定義しとけばいいんじゃないかな。
そうすれば未来永劫大丈夫だ(フォントさえ準備すれば)。北の人とかでも使えるし、なんなら金印とかハンコとかも好きなだけ合成できる。
>>252
グリコが開発したプログラミング言語じゃないの？
文字コードと関係なくね？ 「祇園」のフォントというかグリフって間違ってるよね？
Win10とAndroidは同じっぽいけどどっちも間違いの気がする
>>239
20年以上前にとあるDBマネジメントシステムに関わっていたんだけど、和暦対応を導入しようかって話が出てときに南北朝の話で揉めたよｗ
あの時はどうやって解決したんだっけかな……西暦→和暦変換の関数にオプションを付けたんだっけかな？ (覚えてないやゴメン) >>257
明治5年以前は今使われている太陽暦とは違う暦、太陰太陽暦が使われていたんだけど
その変換はどうしてたんだろ スレ違い気味の自覚はあるのでほどほどにしときます……
>>258
和暦と西暦の相互変換が出来れば十分という要件だったので、それほど困らなかった気が。
西暦→和暦の変換は問題ないよね？
んで、和暦→西暦の変換では存在しない日付を指定したらエラーにしていたんじゃなかったかな。
(例:明治5年12月3日は存在しないため、西暦に変換しようとしてもエラー)
なお上記では西暦と表記してるけど、実際にはグレゴリオ暦とユリウス暦の違いを意識していた記憶がある。
ただし、どうやって解決していたのか思い出せない…… (使えなくてすみません)。 どうせスレチなら現代でも太陰暦に変換するツールが必要
例えば1月30日が存在するかどうかは年ごとに違っていたそうな
https://ja.wikipedia.org/wiki/%E9%96%8F%E6%9C%88
>太陰太陽暦では月の満ち欠けに基づく「30日」と「29日」の二つであり、
>「30日」を「大の月」、「29日」を「小の月」とする。
>しかもこの月の大小は、月の満ち欠けの仕方などによってその順番が年ごとに変わる。
>太陰太陽暦ではこの太陰暦の12ヶ月に、約3年に一度、1ヶ月を加え13ヶ月とし、
>季節とのずれをなるべく少なくする調整をする。この挿入された月を「閏月」という。
>しかしながら閏月をどの時期に入れるかについては、同じ時代でも地域によって食い違うことがあった。
>例えば日本では古来より西日本では伊勢暦、東日本では三島暦が主に用いられたが、
>時として閏月を挿入する時期が異なっていたので、日本国内で日付の異なる暦を使っていた事がある。 結局Alternative Unicodeはまだ存在しないのか……。
Unicodeの制定が1993年なことを考えると、そろそろ別の規格が立ち上がってもいい筈なんだけどな。
Unicodeの仕組みが余程完璧ならいざしらず。
Adobe、Apple、Facebook、Google、IBM、Microsoftといったコンピュータ業界の大会社がUnicode作ってるからなぁ
(実際あるのか知らないけど)他の方面からの立ち上がりに期待するしかないかと。
ローマ数字グリフはUnicodeではCJK互換用文字のように使用が推奨されないとどこかで読んだ記憶があるのですが、間違いでしょうか。
Wikipediaの当該項目を見てもそんなことは書いておらず、困惑してます。
もしも間違いなら積極的にローマ数字グリフを使っていきたいのですが……。
>>265
もしかして、これかな？
以下のページに「ただし、Unicodeの仕様では、これらは互換性用の文字であり、対応するラテン文字を用いる方が良いとされています。」という記載がある。
ローマ数字 - CyberLibrarian
http://www.asahi-net.or.jp/~ax2s-kmtn/ref/roman_num.html
Unicode Chart で Roman numerals (U+2160とか) を見てみると Compatibility decomposition mapping としてラテン文字が記載されている。
これを以って上記ページの筆者が「ラテン文字を用いる方が良い」と記載しているのなら、それは解釈が正しくないように思う。
あくまでも互換性があるよ、というだけの注記だと思うのだがどうだろうか。
ちなみに Compatibility decomposition mapping の説明は、こちら。
↓
Code Charts - Help and Links
https://unicode.org/charts/About.html#Key >>266
ありがとうございます。理解できました。 Unicodeの漢字構成文字ってどういうときに使うか分かりますか？
18.2 表意の説明の文字
表意文字説明文字: U+2FF0–U+2FFB
Unicode Standardには75,000以上のCJK統一的な表意文字が含まれていますが、非常にまれなCJK表意文字の何千もの文字はエンコードされていません。
エンコードのための追加の表意文字の目録の研究は続けられているが、潜在的な符号化可能な表意文字のセット全体が完全に使い果たされることはないと予想される。
特に、表意文字は引き続き作成され、そのような新しい硬貨は常にエンコードされません。
表意文字記述ブロックの12文字は、符号化されていない表意文字を参照する必要があるテキストの標準的な交換の仕組みを提供します。
エンコードされていない表意文字は、これらの文字と符号化された表意文字を使用して記述できます。読者はその記述から表意文字の精神的な絵を作成することができる。
このプロセスは、表意文字の正式な符号化とは異なります。符号化されていない表意文字の標準的な記述はありません。
記述された表意文字に割り当てられた意味はない。記述された表意文字には同値が定義されていません。概念的には、表意文字の説明は、
文字列<U+0065、U+0301>より英語のフレーズ「an ‘e’」に鋭いアクセントを付けたものに近い。
特に、表意文字記述ブロック内の文字のサポートでは、レンダリングエンジンは記述された文字のグラフィック外観を再作成する必要はありません。
また、ユーザーが表意文字を使用して表す可能性のある表意文字の多くは、Unicode標準の将来のバージョンで正式にコード化されることにも注意してください。
表意記述アルゴリズムは、実質的に全てのCJK表意文字を、それ自体が表意文字であるより小さな部分に分解することができるという事実に依存する。
Unicode標準ですでにエンコードされている表意文字の広い範囲は、符号化されていない表意文字の大部分が表意文字を使用して表現できることを意味します。
表象記述シーケンスは、主に符号化されていない表意文字を表すことを目的としていますが、符号化された表意文字を表すためにデータ交換に使用すべきではありませんが、教育的および分析的用途もあります。
たとえば、研究者は、U+86D9 蛙を「虫圭」としてデータベースに表現して、U+5A03 娃などの音声を共有する他の文字との間のリンクを提供することができます。
IRGは、このような方法で表意記述シーケンスを使用して、現行の作業のための、機械によって生成された最初の近似を提供するのに役立てています。
>>265 で「CJK互換用文字のように使用が推奨されない」とあるけど、その根拠ってどこにあるのか分かる方いますか？
日本語ウィキペディアには「後方互換性のために収録されており使用は推奨されない」と書かれてるけど、その根拠が明示されてないんですよね。
一応注釈も記載されてはいるんだけど、>>266と同じような資料なので「使用は推奨されない」とは読み取り難い気がする。
そこで英語ウィキペディアを見に行くと「for compatibility with east Asian character sets」とだけ書かれていて、「使用は推奨されない」という旨は一言も書いてない。
とまあ、こんなわけなので、この迷える子羊にどなたかご教示ください。 10646/Unicodeでは非推奨とまでは定めていないと思うよ
ローマ数字はShift_JISだと化けやすいんでローマ数字の使用そのものが悪みたいに
思ってる人がいるだけだと思う
0点、1点、2点、…とかMS明朝やゴシックに入ってるのを最初見た時、試合等の点数を表すためのものかと思ってた。
でも名称を調べて違う事を知った。そしてそれらは中国語のためのもので中国語では時刻の○時が○点になることも。
すまん送信ミス
>>280
初耳だった。俺もずっと日本語圏向けかと思ってたわ 日本語フォントの場合は点を時に
韓国語フォントの場合は시に
繁体字フォントの場合は點に
はダメなんだろうか。
日本語フォントの場合は時を時に
韓国語フォントの場合は時に
繁体字フォントの場合は時に
はダメなんだろうか。
CJK互換文字非推奨とかローマ数字非推奨とか、根拠の乏しいアピールがあちこちにあるのが気持ち悪い。
自分の好みを主張するのは構わないけど、Unicode でそのように提言されているかのように振る舞うのは気に入らない。
……という気持ちはどこにぶつければよいのだろうか？
取り敢えず>>266のリンク先の作者にぶつけるべきでは ㌀㌁㌂㌃㌄㌅㌆㌇㌈㌉
㌊㌋㌌㌍㌎㌏㌐㌑㌒㌓
㌔㌕㌖㌗㌘㌙㌚㌛㌜㌝
㌞㌟㌠㌡㌢㌣㌤㌥㌦㌧
㌨㌩㌪㌫㌬㌭㌮㌯㌰㌱
㌲㌳㌴㌵㌶㌷㌸㌹㌺㌻
㌼㌽㌾㌿㍀㍁㍂㍃㍄㍅
㍆㍇㍈㍉㍊㍋㍌㍍㍎㍏
㍐㍑㍒㍓㍔㍕㍖㍗㍘㍙
㍚㍛㍜㍝㍞㍟㍠㍡㍢㍣
㍤㍥㍦㍧㍨㍩㍪㍫㍬㍭
㍮㍯㍰㍱㍲㍳㍴㍵㍶㍷
㍸㍹㍺㍻㍼㍽㍾㍿
㎀㎁
㎂㎃㎄㎅㎆㎇㎈㎉㎊㎋
㎌㎍㎎㎏㎐㎑㎒㎓㎔㎕
㎖㎗㎘㎙㎚㎛㎜㎝㎞㎟
㎠㎡㎢㎣㎤㎥㎦㎧㎨㎩
㎪㎫㎬㎭㎮㎯㎰㎱㎲㎳
㎴㎵㎶㎷㎸㎹㎺㎻㎼㎽
㎾㎿㏀㏁㏂㏃㏄㏅㏆㏇
㏈㏉㏊㏋㏌㏍㏎㏏㏐㏑
㏒㏓㏔㏕㏖㏗㏘㏙㏚㏛
㏜㏝㏞㏟㏠㏡㏢㏣㏤㏥
㏦㏧㏨㏩㏪㏫㏬㏭㏮㏯
㏰㏱㏲㏳㏴㏵㏶㏷㏸㏹
㏺㏻㏼㏽㏾㏿
>>288
2バイト文字ってやはり狂っているな
なぜこのようなものまで一字で表示しようと考えたのか…
一字にすることで容量を節約できると考えたのだろうが、
その節約のために無駄な手間暇がかかり結果的にマイナスにしかならないという そんな餌で俺様が釣られクマ―― (AA略)
>>286
これは同意。都合良く乗っかているのは不快だね。
Unicodeを嫌ったりするのは個々の自由だけど、その概念を人々に誤認させるやり口は卑怯だ。
>>292
揚げ足だけど、話の流れ的には2バイトじゃないです……
あと互換文字の存在が許せない派の人々って、結合文字や絵文字も絶滅させたいと思っているのだろうか。
まあ絵文字が気に入らない人は多数いるのだろうとは思うｗ 295デフォルトの名無しさん2018/05/22(火) 00:47:54.81
○囲み文字の1字版と2字版のテストもおながいします
酔った勢いでレスしたら自演だった……恥ずかしい (いきなり酔いが覚めた)。
つまんないことしちゃってごめん、しばらく自重します。
絵文字そのものはどうとも思ってないけど
通常の文章の中で使われる矢印がある種の入力環境だと絵文字で入力されるみたいで
「←このように」が「⬅このように」ってなるのがすごく気持ち悪い。UnicodeというよりIMEに対する不満。
全角チルダがwindowsユーザーとmacユーザーで違うのも厄介
windows ～
mac 〜
>>299
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
文字化けしてますよ。 unicode と ISO10646 は互換性があるけど適用範囲とか微妙に違ったりする。
非推奨とかはISO/JISの方を念頭に置いた話ではなかろうか。
ローマ数字の話だよね？
ISO/IEC 10646にもそんな規定は無いような……コードチャートはUnicodeと同じもの使ってるし。
JIS X 0221の方は真面目に読んでないからよく分からんが……
でもISO/IEC 10646の国際一致規格な以上日本独自でそんな規定は入ってないと思うけど。
>>309
私は話題に割り込んだだけで、話題の出処がどこか知らないのでローマ数字限定かわからないけど、
「組」や「日本語文字レパートリ」とか、その辺の話が歪んでか大げさかで伝わってるじゃないかと。 ローマ数字やCJK互換用文字が「推奨されない」という記述がブログやWikipediaに散見されるけど、それって根拠が無いよね？ という話だと思って眺めてるよ。
こういう聞こえの良いデマを否定するのは体力がいるから面倒そうだよなー
>>312
いつものネット伝言ゲームじゃないか？
日本語での利用を前提として、うろ覚えだけど
1. ISO10646とユニコード規格は厳密に言えば同じではない(事実)
2. ISO10646 は部分実装を許しているための全ての文字が等価ではない(事実)
3. ISO/JIS は部分実装のために日本語向けの文字の組を決めてる(事実)
4. ユニコード実装するならば、日本語向けの文字の組のうち主要なもにには対応すべき(たんなる日本人の願望)
5. ネットなどで不特定多数との通信する前提の場合には、主要な組に入ってない文字は相手側で読めない可能性があるので推奨しない(どこかの個人の意見ならわからなくもない)
6. 日本語のための文字の組にはローマ数字は含まれていない(微妙、ISO規格本体にはまだ入ってないが、JISの参考になら含まれた気がする)
...
中略
...
99.ユニコード規格でローマ数字は推奨されない(デマ) > 6. 日本語のための文字の組にはローマ数字は含まれていない(微妙、ISO規格本体にはまだ入ってないが、JISの参考になら含まれた気がする)
昨年末の ISO10646の改訂でJISが参考で定義していた COMMON JAPANESE も正式にISO規格に取り込まれた模様。
ということでローマ数字は BASIC JAPANESE には含まれてないけど COMMON JAPANESE には含まれてるくらいの位置付け。
285 BASIC JAPANESE と 287 COMMON JAPANESE が 10646 に入ったのは10年前の ISO/IEC 10646:2003/Amd 3:2008 じゃないの？
昨年末の改訂とか正式にISO規格にって何の話？
もう JIS参考でも、amd でもなくて、正式規格本体にあるよ。情報古かったという話。
Amd3:2008 にあるんなら正式規格 ISO/IEC 10646:2012 にもあるかもしれん。確認できんけど。
規格本体に入ったのは ISO/IEC 10646:2011
素晴らしい。こういうちゃんとした情報は歓迎するよ。
そうか、CJK互換文字の利用は「推奨しない」と仕様書に明記されているんだね。覚えておこう。
「完全なラウンドトリップ互換性の為に提供するものであり、それ以外の使用は推奨しない」
だから問答無用で“should not be used”と言ってる訳じゃないけどね。
323デフォルトの名無しさん2018/05/28(月) 22:09:23.88
こまけえこたあいいんだよ
>>319
お前、その省略酷くないか。わざとか？
ソースちゃんと確認せずに信じる奴が悪いのか。
こうやってネット伝言ゲームでデマが広まるのか。 324は何を怒ってるんだ
319のフレーズは複数回出てきてその都度...の部分の規格書名が変わるだけだろうに
いやだからUnicode公式が推奨しないと言ってるのは事実なんだろ。デマじゃないじゃん。
なんでもかんでもデマ扱いすれば自分が偉くなったような錯覚になって気分が良いのかもしれないが
迷惑だよ、そういう態度は。
>>328
CJK互換文字の使用が推奨されないのは事実だけど、ローマ数字が推奨されないのはデマってことなんじゃないの。
それと2行目以降は蛇足だろ。 >>329
多分違う。
「CJK互換文字の一部には特定目的以外に使用すべきでない文字がある」が正しい。
318 はわざとか天然かは知らんが、CJK互換文字の一部にしか適用されないルールを、適用範囲の部分を抜かして引用して、あたかも全体に適用するルールであるかのように誤解する書き方をしてある。
あとは、それを鵜呑みした迂闊さんが「CJK互換文字は推奨されない(キリッ)」ってデマを広げる構図。 >>332
限定せずに「ラウンドトリップ用」って書いたらCJK互換文字全体だろ。
「JIS X 0213:2000のためのラウンドトリップ用」はその一部でしかない。 気に入らないなら自分で満足の行くように書き直して貼り付ければ？
典拠示されてるんだから。
そんな中途半端に書き直して貼り付けるからデマの元になるんだろ。反省しろ。
デマはどっちだよ……「CJK互換文字は」という文脈からは「CJK互換文字に含まれる全ての文字は」という意味しか受け取れないのだが？
「一部」なんていう表現はどっから湧き出てきたんだよ……。
>>337
おまえはどこの「文脈」を読んだんだ？
とりあえず本物の規格読んでこい。 339デフォルトの名無しさん2018/05/31(木) 12:04:29.61
ケチ付けるんなら他人を納得させられる論拠と出典を出せよ
それができないんなら『CJK互換文字の利用は「推奨しない」』が正解だ
>>319のリンク先の規格書で、ラウンドトリップ用だから使用を推奨しないとされているのは以下の3種類だけ。
全体を非推奨とはしていないな。
・U+FA30～U+FA6A (JIS X 0213:2000)
・U+FA6B～U+FA6D (ARIB STD-B24)
・U+FA70～U+FAD9 (KPS 10721-2000) 誰が誰かよくわかんないけど少なくともCJK互換漢字の一部に関しては
非推奨の根拠はあったってことでしょ
不正確だと思ったならそうじゃなくてこうだって言えばそれで済んだ話だろうに
そうせずにネチネチ言うばっかだから無駄に荒れる
>>343
一部でしかないのを全部のように言うから伝聞デマって言われたんだろ。 346デフォルトの名無しさん2018/06/01(金) 11:58:37.96
>>342
一般の開発者やユーザーは「CJK互換文字の利用は推奨しない」で覚えておいた方が漏れがなくて安心だな 規格書嫁とか無茶言うやつがいます。
あれは暗号で書いてあるので書いた人にも読めません。
あなたの能力の限界が人並み外れて低いからといって他人を同類扱いするのは良くない
>>346
お前のような拡大解釈したいやつは「ユニコードの利用は推奨しない」で覚えておけば漏れがなくて完璧だな。 >>346
CJK互換漢字 (CJK Compatibility Ideographs) : U+F900～U+FAFF と
CJK互換用文字 (CJK Compatibility) : U+3300～U+33FF は別物。
>>319で非推奨とされたのはCJK互換漢字(の一部)で、CJK互換文字ではない。 351デフォルトの名無しさん2018/06/01(金) 22:43:44.67
>>349-350
こまけえこたあいいんだよ
逆に覚えたらどうするんだよ
「CJK互換」と付いてる領域は非推奨と覚えれば簡単だろ >>351
何のためにこんな専門スレにいるんだろうな
いっその事「文字コードの利用は推奨しない」で覚えておけば漏れがなく簡単だな 既にデマは溢れてるので、今さら少しくらいデマが増えたところで、どうってことないという見方もあるが
規格の話をするなら細かい点を無視するとかありえない。
あえて >>350 にさらに細かい点をつっこむと
U+3300 - U+33FF は CJK互換ブロック(CJK Compatibility Block)
U+F900 - U+FAFF は CJK互換漢字ブロック(CJK Compatibility Ideograph Block)
とするのが正しいはずで「CJK互換文字」というのは表現は規格にはなかったと思う。
他にも
CJK Compatibility Forms (U+FE30 - UFE4F)
CJK Compatibility Ideograph Supplement (U+2F800 - U+2FA1D)
とかもあるので、勝手な名前とか使い始めるのはデマの元。 354デフォルトの名無しさん2018/06/02(土) 03:00:41.99
弊社の開発プロジェクトでは「CJK互換」と名の付く文字は一律使用禁止とします
Unicodeが公式に「利用を推奨しない」と明言しているのはCJK互換表意文字のそれも一部ってことはデマじゃないよね？
ここまでの議論読ませてもらったが
「利用を推奨しない」
と
「(他規格)との完全ラウンドトリップ互換を提供すためにユニコード規格に含まれている、それ以外の目的に使用すべきではない」
とだと規格上の意味が全然違う気がするんだが？
前者は利用の否定で、後者は利用目的の限定で利用は否定してない。
>>356
「全然」ではなくね？
少なくとも「利用を推奨しない」は後者の意味も含んでるでしょ。完全に数学的な含有じゃないにせよ。 「これは食べられません」
と
「電子レンジ調理専用」
Scheduled maintenance on June 2 and June 9 between 5am pst and 6pm pst. Expect down times of up to 5 hours while we upgrade the power feeds in our data center.
５ちゃんねるサーバ群が収容されているデータセンタにおいて給電装置の更新のため閲覧書き込みが出来なくなります
予定されている期間は以下の通りです
２０１８年６月２日（土）２１時から２０１８年６月３日（日）１０時
２０１８年６月９日（土）２１時から２０１８年６月３日（日）１０時
上記時間帯のうち最大５時間程度の停電が発生すると予想されています
不便をお掛けしますがよろしくお願い致します
>>359
?
＞２０１８年６月９日（土）２１時から２０１８年６月３日（日）１０時 >>342
マジか、マジだ
つまり最初に入ったKS X 1001/Big5/IBMは仕様書上では何も言われてなくて
後から入ったJIS X 0213とかは「ラウンドトリップ以外の使用は推奨しない」と明記なのか。
こんなことならJIS X 0213も無理してBMPに入れずにCNS 11643の残りと一緒にCJK統合漢字拡張Bに入れてもらえばよかったのに
(それが可能だったのかどうかは知らない)。 後半、ちょっと違うんでは？ JIS X 0213 の追加漢字は別に無理して BMP に入ってない。普通に Exntend の方に入ってる。
JIS X 0213 と Unicode の包摂基準の違いから1対多対応の部分があって、ラウンドトリップを保証したかったら互換文字が必要になった。
そして必要な互換漢字は少数で、たまたまBMPのCJK 互換漢字漢字ブロックの後半がガラ空きだったので、そこにつっこまれた。
って話だったと思う。
規格がいってるのは CJK互換漢字ブロックはもともと複数の文字コードとのラウンドトリップ用なんだけど、
指定した一部の範囲は "JIS X 0213:2000" とのラウンドトリップ専用で、他の文字コードとのラウンドトリップにも使うべきではないということ。
Unicode 11.0出たのか、つかもう一年経ったのか……。
> Five urgently needed CJK unified ideographs: three for newly standardized names of chemical elements, and two for Japan's government administration Moji Joho Kiban Project that includes ideographs for personal and place names
へー、これは知らなかった。
一昨年末に名称が正式決定したニホニウム等の元素を表す漢字がUROの末尾に追加になったんだな。
367デフォルトの名無しさん2018/06/08(金) 00:10:00.49
そんなもんで漢字増やすなや！
去年も書いたけど
Core Specification
Appendix D
Version History of the Standard
の漢字のとこの数字が足した数と合計で合わないんだよなぁ
48違うって何なんだろ。
CJK統合漢字のUROの空きコードポイントは残り16個か。次でとうとうU+9FF0番台になる。
それらも全部使い切ったらその次の少数の緊急に必要な漢字追加は拡張A末尾の空きU+40B6～Fを使う事になるのかな。
でそこも使い切ったらBMPへの漢字追加は本当に終わりで拡張BやC、D…の末尾の空きを使用ってことになるんだろうな。
文字列置換から除外するための一時退避の需要あるでしょ。
unicodeはプログラマが自由に使っていい領域ってどこだろう。
371デフォルトの名無しさん2018/06/09(土) 01:02:14.54
「外字」でウィキれ
>>371
回答ありがとう。
UnicodeのU+E000からU+E757あたりを使えばSJISにも対応できそう。 >>373
中身を見ればわかるけど漢字領域 (4e00 から 9efe) とかは
飛ばしてあるから全然違う。 >>376
収録されている全文字を取得するにはどうしたらいいかな… 381デフォルトの名無しさん2018/06/13(水) 00:45:51.71
どうなってんのこれ🤔
🌕🌔🌕🌕🌕🌕🌕🌕
🌕🌒🌕🌕🌕🌕🌕🌕
🌖🌓🌕🌕🌔🌕🌕🌕
🌖🌒🌕🌗🌑🌔🌕🌕
🌖🌑🌔🌘🌒🌕🌕🌕
🌕🌘🌑🌑🌑🌑🌒🌕
🌕🌕🌘🌑🌑🌑🌑🌒
🌕🌕🌖🌑🌑🌒🌗🌓
🌕🌕🌕🌘🌑🌑🌘🌔
🌕🌕🌖🌑🌑🌑🌘🌔
🌕🌕🌗🌑🌑🌑🌖🌔
🌕🌕🌕🌘🌑🌑🌕🌔
🌕🌕🌕🌗🌒🌘🌔🌕
🌕🌕🌕🌗🌒🌖🌒🌕
🌕🌕🌕🌗🌓🌕🌒🌕
5ちゃんでemojiのAAは文字数制限が厳しいからどうしても小さくなりがちだな
なにか問題でも？
🧙🧚🧛🧜🧝🧟
🧙🏻🧚🏻🧛🏻🧜🏻🧝🏻🧟🏻
🧙🏼🧚🏼🧛🏼🧜🏼🧝🏼🧟🏼
🧙🏽🧚🏽🧛🏽🧜🏽🧝🏽🧟🏽
🧙🏾🧚🏾🧛🏾🧜🏾🧝🏾🧟🏾
🧙🏿🧚🏿🧛🏿🧜🏿🧝🏿🧟🏿
ユニコードとUTF8は何が違うんでしょうか
どちらもユニコード？それとも別のコード？頭がおかしくなりそうです
SJISだけで全て丸く収まっていた平和な日本にとんだ黒船がやってきた・・・
387デフォルトの名無しさん2018/06/17(日) 12:38:22.96
>>384
まずはウィキってこい
その上で分からないことがあれば質問しろ Shift_JISだって文字集合違ったりベンダ固有拡張あったりで
全然丸く収まってないよ殴り合いだよ
MSのgithub買収でVSからclone出来ないリポジトリが増えて
SJIS消えてくれたらいいのに
っていうかwindowsの標準localeでUTF-8選びたいんだが
chcp65001はもういやバグだらけ
>>389
今のWindows10ではUTF-8選べるから人柱になってくれ linux つかってる俺はUTF8統一で隙はなかった。
そういえばGO言語ってソースコードはUTF8で書けって仕様で規定されてるんだな。(変な文字変数名に使えてビビった)
sjisはまだ許せる。utf16てめーはダメだ
内部コードに留めてメモリから外に出てこないでくれ
std::wstringがデフォルトでUTF-32になるLinux 64bit版のSTLにも同じこと言えんの？
char32_tのある今、wchar_tの存在価値なんて無いでしょ
環境依存する上にWindowsではUTF-16ということで1要素1文字の前提も崩れてるし
誰に賛成して、誰に反対しているかわからん。安価つけろ。
A社やG社始めメジャーなクラウド系サービスは全部UTF-8だな
意味がわからないよな
SJIS神話は何なのだろう
ジジイだけでなく中年や、中には学生にまであるよねww
学生なんて生まれたときからUTF-8の環境にいるはずで、
わざわざ使いにくい環境をどこで覚えてくるんだろうと怖くもあるww
日本語が２バイトで済む安心感じゃないの？
あと、最近の根拠もなく他国をおとしめて喜んでいる類の人達には、
日本専用のコード体系かっけーさすが日本すげーとか思ってそう。
>>402
日本のビジネスデータは全銀フォーマット等のような固定長が基本だから
文字のバイト数が可変のUTF8は向かないんだよね
うちのシステムでも、相手がUTF8で作ったテキストを送りつけてきて
大事故になったことがあった 日本はまだマシで英語しか知らない欧米の連中だと「文字は1バイト」が常識だから
多言語化してても日本語を表示すると半分しか表示されないとかザラ。
最近はライブラリの整備や（通常全角幅の）絵文字の浸透のおかげで欧米の保守層にも文字コードの概念が伝わってるけどね。
絵文字どころか10年以上前流行ったような古い日本の全角顔文字発掘してきて使ったりしてるよな最近
>>403
なるほど
だとするとEBCDIC対応を求められても不思議じゃないな utf-8で何も考えずにソートしたら漢字の並びが非直感的になるから
しぶしぶsjis
このスレは、Windowsを実務PCとして使ってない人が愚痴をこぼすスレですか。
ほんそれ。
Windows使ってりゃSJIS要求するのは普通だし、そのWindowsはレガシーとしてSJISを捨てられないだけだし。
神話とか日本専用コードとかｗ
Windowsの文字コード周りで唯一好きなのは改行コードが\r\nである点。
他の環境ではLFだけという実際に即していないコードだから嫌。
LFなら普通は「桁位置はそのままで次の行に」でしょ……
abc\n
de
↑こうなるべき。
Windowsは互換性のためしょうがない部分はあるが、そういうのは\e[でやってろって感じだな。
>>412
改行コードなんだから当たり前だろ。寝ぼけんな。
CR は改行コードじゃなくて復帰コードな。ラインプリンターに出してるわけじゃないので復帰コードが必要かどうかは仕様依存。 ラインプリンター由来じゃなくてタイプライター由来じゃないの
キャリッジリターン
ラインフィード
>>415
タイプライターに文字コードは必要ない。
正確にはテレタイプ端末とかテレプリンターとか呼ばれてた奴なんだが、要はラインプリンターだ。 じゃあラインプリンターにもキャリッジあるの？
ラインまるごと打つからラインプリンターなんだよねｗ
MACみたいにCRだけっていうのは病気だけど
CR+LFが来たら常にCR無視しておけばいいし
自分で出力するときはLFだけ出力しておけばいい
それだけ
Why is the line terminator CR+LF?
https://blogs.msdn.microsoft.com/oldnewthing/20040318-00/?p=40193
If you go to the various internet protocol documents, such as RFC 0821 (SMTP), RFC 1939 (POP), RFC 2060 (IMAP), or RFC 2616 (HTTP),
you'll see that they all specify CR+LF as the line termination sequence.
So the the real question is not "Why do CP/M, MS-DOS, and Win32 use CR+LF as the line terminator?"
but rather "Why did other people choose to differ from these standards documents and use some other line terminator?" そのブログは CR + LF を正当化してるけど、テキストファイルの改行は
単に行のデリミタであって、カーソルの移動を意味してるわけじゃないと思うんだよね
International Business Machines
HAL 9000
"I'm sorry, Dave, I'm afraid I can't do that."
>>421
だよな。テレタイプじゃないんだから10か13をLE(Line End)にすればいいんだ 一方でEBCDICはCRやLFとは別にNLを定義した。
ｺﾚが正解
つまり
carriage returnは行頭に復帰
line feedは行送り
CRだけなら何度も同じ行が上書きされる（行送りされない）
LFだけなら例えば3行だとこうなる
XXXXXXXX
XXXXXXXX
XXXXXXXX そんなこといいだしたら
ﾃﾞﾘﾐﾀなんかなんでもいいことになる
ただの文字ｺｰﾄﾞの羅列だからな
CRである必要もないしLFである必要もない
そもそもｷﾐﾗはｱﾎなこといってるﾜｹ
項目のﾃﾞﾘﾐﾀにｶﾝﾏつかったり水平ﾀﾌﾞ使ったりする
行のﾃﾞﾘﾐﾀだってなんでもいい
ﾊﾞｶはﾎﾝﾄ困るわぁ
>>429
だから決めだけの問題だから何でもいい。
ASCIIという文字コードの規約の問題。
実際にEBCDICは CR でも LF でもない制御コードを別途改行コードとして用意した。
ASCII については規格の策定時から LF を押す国際派(ISO)と CR+LF を押す国内派(ANS)が対立していて一意に決まってない。 制御コードであって文字ではないな。
少なくともASCIIとUnicodeでは。
>>420
その後に書いてある「I'm told that the ASCII committee changed the name of character 0x0A to "newline" around 1996, so the confusion level has been raised even higher.」
ってどういうことなんだろう？
ASCII委員会が1996年頃に0x0Aの名前をnewlineに変更して混乱が深まった？
ASCIIって1986年が最終改訂じゃないの？ コンピュータの出力装置がゴルフボールの電動タイプライターだった時代、
例えば「アンダーライン入りの文字」を打つ時は、普通に文字を打って、
「ラインフィードの無いキャリッジリターン」をやって、
アンダーラインだけを打っていたのだと思う。
すると、キャリッジリターンには、ラインフィードが付く場合と付かない
場合があり、両者は明確に区別できなければならないはず。
ASCIIコードが制定された時代から考えると、改行コードが「ＣＲ／ＬＦ」
になったのは、そうゆう趣旨かな？と思う。
>>438
キャリッジリターンは行頭に戻るだぞ
キャリッジリターンだと行頭の文字しかアンダーラインを打てないのでは？
バックスペースで1文字分戻ってアンダーラインを打ったり
文字を二度打ちして太字にしたりしてたと聞いたぞ unicodeになって重ね打ち的な概念復活してきてね？
>>439
重ね打ちをしたくないところはスペースを使えばいい
>コンピュータの出力装置がゴルフボールの電動タイプライターだった時代
スペースは何も印字せずに印字位置を一文字分進めるのであって
その位置の文字を空白で置き換えたり
その位置に空白を挿入するのではなかったのだから
昔読んだ本に、重ね打ちのためにバックスペースを使っている文書を
バックスペースを使えないプリンターでも重ね打ちできるように
変換するプログラムが載っていた
詳細は忘れたけど、CRとスペースを使うのだったと思う
>>438
それだと行頭に戻る機能だけをCRとして用意する理由にはなっても
行頭に戻る機能をLFに持たせない理由にはならないのではないか?
行頭に戻さずに行だけ変えることに当時は意味があったのかも知れないけど思いつかない escシーケンスでも改行せずに行頭に戻したり出来たからな
>当時は意味があったのかも知れないけど
紙の排出に使われてたぞ
>>443
コレクションタイプに全字画印字のキーってなかったっけ？
まさに"空白"を打てるやつ。 UTF-8Nというのは
だれかがﾃｷﾄｰにつけたUnicodeのｴﾝｺｰﾄﾞの名前
先に結論をいうとUTF-8NはBOMついてないUTF-8ということらしいからな
さらいえばUTF-8にBOMつける意味はほとんどない
とりあえず概要だけ書いといてやろう
BOMというのは、符号単位のｵｸﾃｯﾄの並びが
ﾘﾄﾙｴﾃﾞｨｱﾝかﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝか識別するためにﾌｧｲﾙの先頭にﾏｰｸされる
ちなみにそれぞれのｴﾝｺｰﾄﾞの符号単位はこんな感じなる
UTF-8：1つのｵｸﾃｯﾄ
UTF-16：2つのｵｸﾃｯﾄ
UTF-32：4つのｵｸﾃｯﾄ
つまり、UTF-8ではそんなﾏｰｸつけても意味がない
ｵｸﾃｯﾄが1つしかないからな、並びなんか関係ない
2つ以上の場合、ｵｸﾃｯﾄの順序がﾘﾄﾙｴﾃﾞｨｱﾝかﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝかで
数値の表現のされかたが変わる
CISC系のﾁｯﾌﾟだと数値の表現はﾘﾄﾙｴﾝﾃﾞｨｱﾝが多い
RISC系のﾁｯﾌﾟだと数値の表現はﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝが多い
つまり、CISC系のﾁｯﾌﾟでﾘﾄﾙｴﾃﾞｨｱﾝで保存されたﾌｧｲﾙなら
ｴﾝﾃﾞｨｱﾝを気にせずにﾌｧｲﾙに保存された数値をそのまま読むことができる
しかしﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝなら一旦ｵｸﾃｯﾄの並びを逆転させてから
数値を読みとる必要がある
RISC系のﾁｯﾌﾟならその逆になる
分かった？
わかんない。
なんで他のシステムで読む可能性のあるファイルなのに
フォーマットを決めないの？
>>443
> 行頭に戻さずに行だけ変えることに当時は意味があったのかも知れないけど思いつかない
例えば、ゴルフボールで次のようにタイプすることを考えてみる。（□はスペース）
□□□□□□□ＡＡ
□□□□□□□ＡＡ
□□□□□□□ＡＡ「ＣＲの無いＬＦ」「ＢＳ」「ＢＳ」ＡＡ
と打つと、行頭に戻すよりも速く打てると思うが。 CISC RISC って今は無意味だしエンディアンとは関係ない
関係あると思うのは知ってるCPUが少ないだけかと
あと上で重ね打ちが昔の話みたいに言ってるけど
man使ったことないの？
端末によるけどたいていアンダーラインがつくよ
>>443
CRとLFに分かれてるのは当時のハードウエアがそういう仕様だったから
画面制御のコンテキストで意味を求めてもしょうがない BOMの有無でCSVをexcelに読ませる際に文字化けするんだよね
そういう仕様だったから、ってのは何の考察にもなってない。
人類が争いをやめないのはそういう仕様になってるから。
>>450
>(manでは)端末によるけどたいていアンダーラインがつくよ
manでアンダーラインがつかないと言っている人はいないし、昔は
>バックスペースで1文字分戻ってアンダーラインを打ったり
>文字を二度打ちして太字にしたりしてた
というのとは別の話だろ >>453
そうなっていたのはなぜかという話をしているのに
「そうなっていたから」と返されてもな… >>449
速く打てるだろうけど、そういうことをやりたい状況ってどれぐらいあるんだろ
行頭へ戻すほうがずっと多いだろうし、その場合にCR LFと打つことに
なってもしかたないと思えるほど>>449の状況は多かったのだろうか
キーを一つ押せばCR LFと出るように設定できれば手間はかからずにすむけど
設定できたとしても改行に2文字使うのは変わらない
昔は記録用に紙テープを使っていたようで、行毎に1文字多く使うと
その分、紙テープの消費は多くなる
そうなってもしかたないと思えるほど>>449の状況は多かったのだろうか ちょっと関係ないがGoogle翻訳では改行は%0Aだね。
HTTP関連の改行コードはCRLFが多いと思うんだけど，珍しい。
むしろﾌｫｰﾏｯﾄがきまってる
ﾘﾄﾙｴﾝﾃﾞｨｱﾝの形式でもいいし
ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝの形式でもいいというﾌｫｰﾏｯﾄだからな
構成ｼｽﾃﾑがﾘﾄﾙｴﾝﾃﾞｨｱﾝの計算機が多い場合、ﾘﾄﾙｴﾝﾃﾞｨｱﾝで扱う方が有利
当然、構成ｼｽﾃﾑがﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝの計算機が多い場合、ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝで扱う方が有利になる
後処理の計算機のﾘｿｰｽ消費量を減らすために先にいちいち毎回ｴﾝﾃﾞｨｱﾝ変換するのもﾑﾀﾞだしな
ちなみにﾈｯﾄﾜｰｸのﾌﾟﾛﾄｺﾙの標準では歴史的な事情があって
ほぼ暗黙でﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝになってる
ﾄﾞｷｭﾒﾝﾄにｴﾝﾃﾞｨｱﾝが記載されてなければ
ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝとみなしてほぼ問題ない
ちなみにｷﾐﾗみたいな貧乏人が使ってるPCは
ほとんどﾘﾄﾙｴﾝﾃﾞｨｱﾝになる
やっぱり今時半角カタカナ使う人にはアレな人が多いのか
>>459
どっちでもいい＝決まってないだろ
頭悪いと半角カタカナが大好きになるのはなんでだぜ？ >>460
じゃあお前何使ってんだ？
貧乏人なのでスマフォ叩きながら質問。 やっぱりユニコードが諸悪の根源
あれが入って来てからコンピュータが扱いづらくなった
日本はSJISに統一しよう
Unicode程度でコンピューターを扱いずらくなる脳味噌って……同情するわ。
UTF-8 はバイト列を見て文字がわかりにくいのが難点
>>464
最初から 32 ビットにしなかったのが問題でしたね >>468
うーん、いやあ、あらためて考えると単に分かりづらいと思い込んでる
だけだったかも。JISX0208 の文字って３バイトになるでしょ。
あの 3バイトずつになるのがどうも慣れないだけだった。467 は撤回するよ BOMでｴﾝﾃﾞｨｱﾝが規定できるからな
そのようにﾌｫｰﾏｯﾄできまってる
数値の読みとりかたも一意に定まる
どっちでもいいというﾜｹではない
ﾊﾞｶはﾎﾝﾄ困るわぁ
つまり
ﾘﾄﾙｴﾝﾃﾞｨｱﾝで2つ以上のｵｸﾃｯﾄがあるのに
先頭にBOM入れないﾔﾂはｺﾞﾐｸｽﾞといえる
Javaのﾊﾞｲﾄｺｰﾄﾞに CAFE BABE が入ってないぐらいお話にならない
ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝならBOMなくてもｵﾚはよいとしようと考える
恐ろしいのは、PCを使う一般人はユニコードとかBOMとか全く知らないこと
IT技術とIT利用者のレベルのギャップがいつかデカい事件を起こすだろう
PC社会は薄氷の上を歩くような危うさの中に成り立っている
未だに半角とか全角を使用者に意識させるのが残念でならない
カタカナなんて文字としては一種類なんだから機械的に変換してしまうのが当たり前になって良さそうなのに
2ちゃんがSJISオンリーってのがそもそもはよなおせ
>>470
中国のGB 18030みたく1バイト/2バイト(EUC-CN)の上に4バイトを重ねる方法もあるけど
それならUTF-8の方がすっきりしてていいわな Unicodeのクソなところは、既存のコード体系を無視してるところだよな。
まさに欧米人のやり口そのもの。
Shift-JISが発音区別符号のついたラテン文字などをサポートしていればよかったのに。
>>478
jis やsjisとかと全く関係なく決められている事を言ってるのだと思うが、
それは中国の横やりだよ。
欧米人からすると、CJKのコードなんて、どうでもいいわけで。 >>464
文字列末尾からの逆方向検索を実装してごらんなさい。
もれなく SJIS に対する殺意が目覚めますよ。 >>482
ビット立てながら先頭から見ればいいだけじゃん？ 昔、Unicodeもない時代に全文検索ｴﾝｼﾞﾝ作ったことがあるが
ｲﾝﾃﾞｯｸｽ作るのにもﾏｯﾁﾝｸﾞ用に符号圧縮したﾃﾞｰﾀ作るのにも
設計がめんどいわ処理時間がかかるわだろうから
Shift_JISﾃﾞｰﾀから16bitのﾃﾞｰﾀに一旦変換してからそういったﾃﾞｰﾀを作成するようにしてたわ
要件が検索漏れｾﾞﾛ、ﾉｲｽﾞｾﾞﾛ、なおかつﾒﾃﾞｨｱは超ﾄﾛｲCD-ROMという
ありえない滅茶苦茶な内容だったからな
ｲﾝﾃﾞｸｻは大富豪な設計でないとやってられなかった
ｲﾝﾃﾞｯｸｽ作成にﾘｱﾙﾀｲﾑ性が要求されなかったからまだ救いがあったともいえる
その全文検索ｴﾝｼﾞﾝはｲﾝﾃﾞｯｸｽを大きくすればするほどｲﾝﾃﾞｯｸｽが大きくなるかわりに
最悪のｹｰｽの速度が速くなるという仕様にした（最低限必要な性能の要求水準に応えるため）
ｲﾝﾃﾞｯｸｽを大きくするということはｲﾝﾃﾞｯｸｽを作るのに当然時間がかかるということになる
いまはそれもとてつもなくﾃﾞｰﾀが増えてDVDになってる
ｲﾝﾃﾞｯｸｽもものすごい大きくなってる
で、その最悪のｹｰｽというのは、
符号圧縮されたﾃﾞｰﾀをﾏｯﾁﾝｸﾞする回数が増えることを意味する
ﾏｯﾁﾝｸﾞの条件はﾏｯﾁﾝｸﾞｷｰﾜｰﾄﾞから生成するｲﾝﾃﾞｯｸｽに含まれる符号圧縮された符号の組み合わせになる
そのﾏｯﾁﾝｸﾞｱﾙｺﾞﾘｽﾞﾑにBMHを使うことになる
で、このBMHというのは文字列ﾏｯﾁﾝｸﾞで非常に有効なｱﾙｺﾞﾘｽﾞﾑといえる
しかしShift_JISでは使えない
ﾕﾆｺｰﾄﾞならそのまんま使える
順方向からの文字列ﾏｯﾁﾝｸﾞですらShift_JISでは
こういった高速なﾏｯﾁﾝｸﾞｱﾙｺﾞﾘｽﾞﾑが使えない
いかにShift_JISがｳﾝｺかよくわかる典型的な例といっていい
>>488
> ｲﾝﾃﾞｯｸｽを大きくすればするほどｲﾝﾃﾞｯｸｽが大きくなる
髪を長くすればするほどロングになる 半角カタカナを多用されるとCOBOLで作ったんじゃないかと思っちゃうね
半角カナもそうだけど、全角英数も大概だよなぁ
経緯的なもんだろうけど、
未だに『住所はすべて全角で』みたいなWebフォーム有ったりするし
Unicodeって日本を優遇しすぎてない？ そう思うのは日本人の奢りなのかな。
例えば上で挙げられてる絵文字や全角英数、半角片仮名だって日本由来だし、
「CJK互換文字」と謳いつつ、キロメートルを一文字幅に短縮したやつとかも全部日本のJISコードとの互換性を保つために導入されてる訳じゃん。
そういうのってどうなのかなぁ。
自分は嬉しい（過去の、Shift-JISでエンコードされた文書が情報の欠損なく読めるから）んだけどね、もちろん。
>>495
線文字Aとか楔形文字拡張とか見ても同じこと言えるか？ 誰にも読めない、使えない、未解読の古代文字とか登録してるくらいだから、現代でも使用可能な文字なら余裕って話だ。
㍻（元号を一文字化したもの）とかあるからな
申請すれば何でも通るんじゃねーの
申請する権利のある人ならな。
大手OSメーカー、国家規格代表、ごく一部の文字専門家。
㍼、㍻などは、昔の（日本の）文字コードとの互換性を取るために
残しているだけ。だから、次の元号の合わせ文字は通らない。
>>502
もうコードの場所を確保してあるってMSの元号対応ブログで言ってたよ 先月のWG2ロンドン会議で32ffが予約された
>>501
申請者に権利なんてないよ。英文ができてフォントが作れるなら誰でも提案できる 空いてるとこにﾃｷﾄｰにいれてるだけやん
文字ｺｰﾄﾞが連続してないし
ひどいﾏｯﾋﾟﾝｸﾞされてるわ
元号は、これからもどんどん増えてゆくんだから、Unicodeに
「日本元号面」を作って、そこに入れるようにしてほしい。
ちなみに先に書いた全文検索ｴﾝｼﾞﾝでは
ｱｲｳｴｵもｱｲｳｴｵも
ｶﾞｷﾞｸﾞｹﾞｺﾞもガギグゲゴも
１２３４５も12345も
ａｂｃｄｅもabcdeも
同じ文字ｺｰﾄﾞとして扱ってる
つまりどっちでｷｰﾜｰﾄﾞ書いても当たる
見た目（つまりｸﾞﾘﾌ）が違うだけで同じだからな
しかし明治大正昭和平成を㍾㍽㍼㍻までは
やってない
すでにいろんなもんでその全文検索ｴﾝｼﾞﾝは使われてるが
ｺﾚで文句がきたことはない
つまりだれも気にしてない
こんな感じの内容からｲﾝﾃﾞｯｸｽやﾏｯﾁﾝｸﾞ用のﾃﾞｰﾀが作成される
ｶﾞｷﾞｸﾞｹﾞｺﾞ ガギグゲゴ ⇒ カ゛キ゛ク゛ケ゛コ゛
ｶﾟｷﾟｸﾟｹﾟｺﾟ ⇒ カ゜キ゜ク゜ケ゜コ゜
つまりｲﾝﾃﾞｯｸｽやﾏｯﾁﾝｸﾞ用のﾃﾞｰﾀを作る前に前処理で一気に痴漢することになる
で、ｷｰﾜｰﾄﾞをｶﾞｷﾞｸﾞｹﾞｺﾞやガギギゲゴやカ゛キ゛ク゛ケ゛コ゛にすると
カ゛キ゛ク゛ケ゛コ゛で検索することになる
つまりこの全文検索ｴﾝｼﾞﾝは濁音も半濁音も検索できる超優れものといえるのだ
俺はそういうのを考えるのが面倒だからUNICODE正規化だけしてる
おかげで平成と㍻もちゃんと検索でヒットする
ちなみに客ごとに置換辞書を作ってる
客ごとに要望が違うからな
客によってはいろんな要望をいってくる客もいる
その要望に応えるのも仕事だからな
で、そのなかに㍾㍽㍼㍻を置換した例はない
全角にﾏｯﾋﾟﾝｸﾞされてるasciiや半角ｶﾅの部分は
ｺﾚについてほぼ間違いなくみな同じ結論になる
それ以外で異なる特殊な部分は結構ある
文字ｺｰﾄﾞでｼﾉﾆﾑの部分もあれば、それ以外でｼﾉﾆﾑにしたい部分もあったりする
それは客の業務に依存する部分になるからな
考えるのはｷﾐじゃないﾜｹ
ｷﾐはただのﾄﾞｶﾀなﾜｹ
わかる？
客と良好な関係を保つには
できるだけ、それは仕様ですは避けないといけない
そしてそれを低いｺｽﾄで実現できないといけない
なにをしたいのかはっきりといってる部分については
こっちから客の業務についてどうこういう必要も理由もないし
こんなしょうもないことを実現するためにめっちゃｶﾈかかりますよとかいえるﾜｹもない
そういうことだ
>>507
次の次の次に予定されてる人が、女性に興味が持てない人だったり、
ジジイババアに囲まれて育つからババア専に育ったりするかもしれないぞ？ 絵文字の無茶な合成が有りなんだから
平と成をzwjでくっつけたら㍻になるとかでいいのに
魚 + ZWJ + 里 = 鯉
とか収拾がつかなくなる
次の元号組み文字はCP932やJISX0213には入るのかな？
月+光=胱とか
実際に胱を人名に使えるようにしてほしいという要望があるそうだ
自力でマッピングするnkfの遅さ。文化遺産だから保守され続けるのだろうけど。
ていうか確かそういう（漢字を結合する）のにピッタシな文字が用意されてた筈。
漢字表示文字だとかいう名称だったけど、検索してもそれらしい記事が引っ掛からんので
多分この名称は違う。
>>516
日本NBがBMPに専用のコードポイントを確保することにこだわった
BMPしか扱えず合成何それ？みたいなシステムが国内にいっぱい残ってるんだと >>524
キラキラネームつけるレベルの頭の人だよ？
そんな難しいことわかんないよ。 >>520
要望する人はそんなの気にしないんでしょ 合字と、ひとつの漢字が偏旁に分かれているのとはまた別だろ
胱を人名に使えるようにしてほしいと要望している人たちは
胱を月と光の合字のようなものと考えてるんだろうなって話だからな
しかし肉と光でなんで膀胱なんだろうな
光は頭の上に火を掲げる神聖な存在を表していたらしいけど
特殊な性癖の人が尿を聖水というのと関係があるのかしら
昔の知識じゃそんなこと分からんやろ
足りない頭ひねって考えろやボケナス
新元号がUnicode12にギリ間に合わないから12.1出そうかって話が出てきたか
えぇ そんな一国の事情でUnicode様が右往左往されるのですか！？
トルコリラの「も」みたいなやつ追加した時もほぼそれだけじゃなかったっけ？
JIS X 0212 補助漢字の残りはいつになったら……(´・ω・｀)
UTF-7の仕組みをはじめてしったが面倒くさいエンコードだった。
UTF-16と、BASE64に依存しててこれがなければ成立しないのかよ。
単体で存在するUTF-8とかと一緒かとおもってた。
元号の組文字に先行リリースするほどの価値があるかなぁ
何にしろ早くAJ18出してよ
来年の5月までまだ9ヶ月強あるのに今の時点でもうAJ1-7は2文字だけと決めてしまうなんて
候補の選定ってそんなに手間のかかるもんなのかねぇ
どの言語圏であれ、国家が絡めば、Unicode界隈ではおおごとだよ。日本の元号だってまさにそう。
あの絵文字どうしますかね、とかそういうレベルじゃないから。
AJ16が出て結構経つとはいえこの間JISの改訂があったわけでもないんで
意外とAJ18も数十～数百文字程度の小規模アップデートで終わるかも
元号が絵文字になるとVSによって色黒な昭和とか女性的な明治とかが生まれるのか
元号なんて漢字2文字並べて書けばいいからそんな急ぐ必要無いだろ。
組み文字はUnicode13以降でもいいだろ。
大国であれ小国であれ、一国家の行政が絡んでいるという時点で、急ぐ必要があるんだよ。
なにしろ影響を受ける人の桁数が違う。
文字の名前もグリフも未定だけどとりあえずコードポイントだけ押さえましたなんて
Unicode史に残る珍事だと思うわ
影響を受けやすいような手段を一国家の行政が採用している無能さを棚に上げてるから駄目なんだ
「ワシは知らん」とUnicodeが無視した場合、本来は1ベンダーにすぎないマイクロソフトがそのしわ寄せに対応することになり、
結局、マイクロソフトの独自拡張をUnicodeがしぶしぶ追認することになるので二度手間なんだよ。
北朝鮮の将軍様専用ハングルとか数文字は国家規格に入ってるにも関わらず
未だにUnicodeに入れて貰えてないよな。
元首の交代に伴って変更される紀年法をまだ使ってる国なんて他にあんのかね
まず無いだろうけど、もし新元号が現時点でUnicodeに無い漢字を使うものになったら
統合漢字のURO末端に緊急追加になるだろうな。
>>566
その前に国内のシステムがおかしくなるよ。
常用漢字から選んでくれないと。 >>564
そういえばあれって三代目用の文字もあるのかな？ 将軍様専用ハングル以外にUnicode未収録文字は縞模様の三角とか謎の記号がいくつかあったな。
北朝鮮で使われてるRed Star OSではUnicodeが使われてるけどこれらはPUAに割り当てられてる。
因みにWindowsの北朝鮮版は無い。
>>570
2012年頃の改訂で追加されたらしい。 新元号組み文字はJIS X0213には入れるのかな。
入れるとしたら㍻の1つ前の1面13区62点、シフトでJIS0x877D辺りか。
専用ハングルはなんで「金」とか「日」とか重複する文字を代ごとに別々に入れてるのか謎
文字コードとしては謎だろ
担当は何をしているのか
指摘どころか質問した時点で解雇されるルールでもあるのかよってくらいに謎だわ
やっぱおじいちゃんの金とおとうさんの正をを孫に使ったりしたら怒られるのかな。
グリフを見ただけで誰用の金なのかを見比べるスキルが必要になるんだろうな。
nkfコマンドってなにもオプション指定しないでも文字化け直してくれるんだなw
どうやってるのか知らなくて怖いが（普段はiconv(1)を使ってる）
>>579
今時EUC-jpが生きてるシステムってあるの？ 文字コードの自動判別は、100% 正確じゃない
間違うこともある
bit 順に意味があるんだろうけど
"\xC8\xFE\xC6\xFD"
なんでこれで自動検出できるかの説明が欲しい
UnicodeはUCS-4を基本形にして
UTF-8はUCS-4の圧縮版のような扱いでいいんじゃないか
UCS-4ならCode Chartsに書かれている値をそのまま使うから分かりやすいし
UTF-16は廃止してもいいと思う
WindowsのAPIがUTF-16ベースなのに廃止とか無理でしょ
pcre はutf8対応が不完全。無理もない話だけど。
文字コードのライブラリを作る人からすればutf8よりも、utf16やutf32の方が便利。
そのutf-8の問題は utf-16でもutf-32でも同じなのでは
seekがめんどくさいのがUTF-8の問題だと思うんだけど違うの？
UTF-16はUTF-8とUTF-32のデメリットを兼ね備えていて、
メリットが無いような気がする。
このスレに来るような人が、どうしてutf8とutf16/32が同じと思うのか不思議。
自力で文字判定処理をやったことがないスクリプト言語プログラミング一辺倒の人？
>>591
文字コードに習熟したプログラマしかここに来ちゃいけないのかい？
俺みたいにユニコードとUTFの違いすらよくわからない者が情報を求めて
ここに通うこともあるんだぜ pythonなんて内部の文字コードutf16だよ。
使う側が意識せずに済んでるってのがむしろ凄いわけで。
utf16要らないとか言ってる人は、事業仕分けでドヤ顔する民主党議員だわ。
仕分けしたからモリカケだけで済んでるんじゃないの？
本当だよ
無駄な予算にかけようとするこういうバカは消えてほしい
UTF-16はいきなり廃止するのは無理でも
新規設計非推奨くらいにはしてほしいよ
WinAPIでUTF-16使ってるから廃止は無理でしょ
UTF-16は世界中の文字を固定長で表せるようにすることが目標だったから
16bitではそれができないと分かった以上32bitに変えるべき
linux64bit版gccは、wchar_tやstd::wstringが既定でutf32だし、徐々に変わっていくでしょう。
win32->win64のタイミングで変えとけばよかったのに
>>600
ほんそれ
ついでにシステムロケールもUTF8はよ 必要な時にUTF32を使えればいいだけなのでそんなに深刻がらなくても大丈夫でしょ。
基本は8で臨時は32で答えが出ているよなあ
日本独自のJIS関係とかもう要らないし
そういえば新元号合字ってJIS X 0213とかCP932とかの系統にも入るのかな？
元号合字使ってるとこはUnicodeじゃない古いとこが多そうだからここに入れないと意味半減な気がするけど
印刷に使うワープロソフトはすべてunicode対応しているから大丈夫。
日本語とか東アジア言語はバイト数の面では
UTF8よりUTF16の方が有利になるのだが。
お経とかならそうかも
でも普通の日本語の文書はUTF-8で１バイトになる字がわりと使われてるよね
改行もバカにならない
エディタとかUTF-32に対応してないのが多いよな。
まあ、無駄が多いからな。最上位の1バイトは必ず0x00になるから。
余ってる場所を余計なことに使う奴が絶対出てきて、
それを根絶するのに凄い辛い思いをするからヤメレ。
もうこれ人類的に根絶できないんだろうね
一生これなんだろうね
そういえば、utf9というのもあったな。３６ビットコンピュータに最適だとか。
UTF-24を策定するべきだな。
全ての文字を24ビット(3バイト)で表す。
UTF-32の0x00で固定な最上位バイトを省くというので。
BMP外の文字だらけの文章には有利になるだろう。
>>623
だな、固定長はUTF-24、可変長はUTF-8でいいだろう UTF16はいらないとかUTF24がよいとか、変な書き込みする人、同一人物？
CPUのレジスタは32bitまたは64bitなので、1バイトをコピーするのも4バイトをコピーするのも時間コストは同じだよ。
1バイトと4バイトとかミクロの性能比較なんか殆ど意味無い
>>626
大ありですよ。
>>627
固定長の方が条件分岐が減るので処理速度が高く、プログラミングもしやすい。 >>626
ファイルサイズがでかくなればそれだけ処理をする回数が増えるからダイレクトに効いてくる。 CPUひとつあたりの処理速度は10年前とあまり変わってないけど、搭載できるメモリの量は劇的に増えた。
内部実装がUTF32になって文字列リソースが2～4倍になったとしても利用できるメモリはそれ以上に激増しているのでまったく問題なし。
むしろUTF16やUTF32のほうが頭打ちのCPUにも優しい、ということがわかるはず。
16は全然優しくない
24もアライメントを考えると優しくない
>>633
合成やセレクタを撤廃できるのなら128でいいよ UTF24とかメモリアクセス効率悪すぎるだろ。アライン考えろ。
情報交換用文字コードはエンディアンに依存しないUTF8。
内部用の文字コードはアクセス効率が良いUTF32。
貧乏人専用のUTF16。
それぞれ存在理由があるんだよ。
Windowsの場合、プログラムを何も改修することなくUTF16でサロゲートペアの絵文字を使えているでしょ。
もちろん、文字フォントを描画するAPI、つまりマイクロソフトの中の人が頑張っているからだが。
まぁ、Windowsプログラムで、動的に絵文字の肌色・髪色・性別などを変えようと思ったら、
UTF16のサロゲート処理を自分で行う必要があるけどね。
>>637
24が駄目なら8はもっと駄目なんでないの？ だからUTF8は内部利用じゃなくて情報交換用なんだろ。
SJISと取り決めてあるテキストデータにUTF8をぶっこんできた取引先があって
翌朝からの日本社会に大混乱を引き起こしかねない危機に晒された経験がある
UTF8滅ぶべしと俺は本気で思っている
エンコーディングは関係ないだろ。
決めごとを守れないその取引先と異常データを突っ込まれただけで混乱しちゃうプログラムの問題。
何年か前に、地域の緊急速報のテストメールか何かに
エンコーディングを混在させて文字化けを地域住民に送って混乱させたのあったな
メールテンプレートのエンコーディングと、流し込む本文で混在させちゃったみたいな
ないしほてし活復を語本日く書に左らか右どけい良もでき書横
中東の言語は確か右からだったよな
やろうと思えば簡単そう
sjisの～とcp932の～の違いって何？
～を入力して検索すると、sjisのほうはヒットしないんよね
>>650
「入力して検索する」
どうやって入力して何を検索するのか他人に分かるように書いたらどうか
入力側がUNICODEで変換不能とかじゃない 絵文字がんがん増えてるけど、ぱっと見で見分けが付かない微妙なの多いよなぁ
そのうち洗練されて象形文字になって、やがて漢字に…あれ?
この際1byteを32bitか64bitにしたらどうよ
1byteが8bitになったのはアルファベットや数字が固定長で表せて
2^nbitで処理しやすかったからなんだろうけど
1byteが32bitか64bitになればエンディアンの問題もなくなって分かりやすくなる
そうなんか？
16新数で2桁でちょうどいいからだと思ってた
あと 8bit を 1byte というけど
4bit のことをなんていうの？
>>657
8bitや16bitのCPUはどうすんの？ >>657
32bitでも、64bitでも、好きな長さを「word」と呼べばいい。
これで、エンディアンの問題もなくなって分かりやすくなるんだよな。 無理。各コンピュータ内部なら好きなビッド数にすれば良いけど、インターネットのほぼ全ての規格はオクテットが基準になってる。
インターネット全部作り直すくらいやらないと今更変更できない。
>>584
昔の ISO/IEC 10646 がそんな感じじゃなかったっけ？
UCS-4 が Four-Octet Canonical Form (4オクテット正規形) と呼ばれてて
UTF-8 や UTF-16 はあくまで Transformation Format だと。 UTF-32に統一できないなら、UTF-8を残そうがUTF-16を残そうが
どちらも大して変わんないんだよね。
UTF-8 も UTF-16 も既存OSの互換性を保つためにあるのだから
UTF-8はANSI互換性というメリットがあるというけれど
なんてことはない、Unix/Linuxの改修が大変だったから、
文字コードのエンコーディング方式自体を作ったってだけの話
互換性のために作ったものだよ
16bitにすべての文字を収めるのは不可能だが、仮に収まったとしたら
UTF-16はサロゲートペアなどなく1文字16bitというシンプルなものになっていた。
もし最初から32bit必要だと認識していれば、UTF-32という1文字32bitに
統一された素晴らしい文字コードになっていただろう
そしてWindowsはそれを標準文字コードとして採用しただろう。
（WindowsがUTF-16なのは、その頃はUnicode = UTF-16の前身のUCS-2 だったから）
結局固定長でないなら、どちらも面倒なことに大差ないし
互換性を保つために面倒な方式を残すのであれば、
それがUTF-8でもUTF-16でも同じこと
8も16も大して変わらないと言えばそうだけど、種類が少ないに越したことはないし
どっちかひとつ残すならやっぱり8なので、16には退場願いたいね
>>669
Windowsという重要な役目があるので無理だってわかってるだろ？ >>667
妄想は要らん
asciiとの互換性とosの改修は関係ない
16bitに収まったとしたらとか ifを言い出したらきりがない >>670
昔からMSは独自文字コードが大好きだからUNICODEからUTF-16が無くなっても問題ない >>671
> asciiとの互換性とosの改修は関係ない
大あり。C言語はASCII互換前提となっている。
具体的に言うと、文字列の終端文字が\0なので
UTF-16やUTF-32といった、1文字の中に\0が
含まれてる場合に対応できない
UTF-8でなければprintfなどの基本的でよく使われる関数
全てをUnicode対応に改修しなければならなかった。
もしくは捨て去さるかだ >>672
昔からUnicode対応なんですがーｗ UTF-16やUTF-32も1文字の中に\0が含まれているわけじゃないがな。
http://ash.jp/code/unitbl1.htm
41 41 41 41 0041 A
42 42 42 42 0042 B
43 43 43 43 0043 C
44 44 44 44 0044 D
45 45 45 45 0045 E
右から二番目がUTF16の文字コード
見ての通り基本のアルファベットの中に0x00が含まれてる
つまり ABCは、00 41 00 42 00 43 もしくは 41 00 42 00 43 00 という並びとなり
これをprintf等にわたすとASCII文字として1文字8bitと解釈し、
00を\0とみなすので途中で切れるか全く表示されなくなる 説明足らずな>>675が揚げ足取りだと思われると可愛そうなので（笑）
補足してあげると、UTF-16やUTF-32の1文字はそれぞれ16bit or 32bit で
16bitで\0、32bitで\0 は含まれてないと言いたいのだ
だが今は、printfなど1文字8bitと解釈する関数の話をしているので
8bitずつ見ていくと文字の途中に\0が含まれるのだ まあWindowsみたいにcharはロケール依存のままでwchar_tだけUnicodeという構成もあるので
UnixのUnicode対応にUTF-8が必須だったかというとわからんけどなー
>>680
え？ Unixもwchar_tはUnicodeだけど？ 正確には、既存のコードの多くは wchar_t が使われて無くて、
その対応が大変だっていう話
WindowsはOSすべてを自分たちで作ってるからどうにかなったが、
オープンソースで他人が作ったものの寄せ集めだと対応が大変だろうね
gcc は、 wchar_t を16bitと32bitでコンパイル時に選択できるようになっているので、のちのちWindows以上に厄介なことになるでしょう。
>>681
Linuxではそうだけど、Unix一般の話でいうとwchar_tはcharの多バイト文字をひとつの値で表せられるならなんでもいいし
実際BSDはcharがSJISならwchar_tはJISコード OSの中とかプログラム言語とかどうでもいい。
インターネットとかの通信プロトコルでオクテット(8bit)単位で交信、終端は0x0A 0x0Dとかの特定のオクテットコード列を使用とかになってるのが多数ある。
内部では好きなビット数で処理すれば良いけど、通信には8bit単位の処理系も必須。
ユニコード使うかどうか以前の問題。
wcharは、内部の符号化に依存しちゃいけないし、幅が 16bitか32bitかに依存するのもよくない
使うのがなかなか難しいね
但し、char と混在させるのは単なる誤り。printf に使うと途中で切れるとかいうのは使う側のミス
>>687
printfで途切れる云々は仮にLANG=C.UTF-16みたいなロケールがあったとしての話だろ？
isdigit等も実装できないし、規格上できないようになってるとは思うけど >>687
printfはchar（のポインタ）を受け取るんだから、wchar_tは使えないでしょ？
というかcharで表示できない文字だから、wchar_tが作られたというのが正しい
そうなると、printfだけでなく多くの文字列用関数に対して
charバージョンとwchar_tバージョンが必要になって、変更しなければいけなくなるよね
それが大変だからUnix/LinuxはUTF-16には対応するのは現実的に不可能
対応が簡単なUTF-8を作りました。という流れ。
>>689
> LANG=C.UTF-16みたいなロケールがあったとしての話だろ
Unix/LinuxはUTF-16に対応するの大変だから、
そんなロケールは実現できないだろうね
似たような理由EUC-JPは対応できたけど、SJISは対応できなかった
と思ったけど以下のような警告出るけど使えるのかｗ
> # localedef -f SHIFT_JIS -i ja_JP /usr/lib/locale/ja_JP.SJIS
> キャラクタマップ `SHIFT_JIS' は ASCII 互換ではありません, ロケールは ISO C に従っていません
こんなのまで見つけた
http://www.ossforum.jp/jossfiles/Linux_SJIS_Support.pdf
ダメ文字（文字の一部に\が含まれる場合）にさえ、あたらなければ大丈夫ってことなんかな
UTF-16と違って確率的には低いだろうけど >>662
シュメール文明の神アヌンナキたちの故郷の惑星のことかと思った >>690
> 似たような理由EUC-JPは対応できたけど、SJISは対応できなかった
kwsk >>693
だからダメ文字だって
http://ash.jp/code/code.htm
> また、2バイト文字の中に"\"(0x5C)を含むデータが存在するため、文字列がメタ処理されてしまい、文字化けする可能性があります。
LinuxやUnixに限った話ではないけど、
文字を1バイトずつ処理するようなもの（つまりcharポインタ）は
ASCIIと互換性がないと不具合の原因になる
だからSJISやUTF-16やUTF-32はLinuxやUnixで
ネイティブに処理するのは苦手なんだ 中途半端な多encoding対応で不具合が出たという話。要はバグ。
アホか、アホしか居ないか？
それともわざとボケてんのか？
なんで wchar_t の話と printf の話を一緒に語ってるんだ？
wprintf 🤔
>>696
だからprintfで実装されているものをwprintfに修正するのが大変だって話
またwopenfなどワイド文字対応の関数が存在しない場合も存在する。
それに単純に置き換えてしまうと、今度はASCII環境で動かなくなってしまう
なぜならwchar_tは16bit または 32bitという固定サイズなので
8bitのASCIIは扱えない（当然可変長バイトのUTF-8もwchar_tでは扱えない）
だからwchart_tというものが作られたけど、Linux/Unixはそれを使用して
ワイド文字列対応にするのは現実的に不可能と判断し、
printfで扱えるASCII互換のUTF-8を使うことにした ダウト
wchar_t で普通に ASCII も使える。当たり前。i18n でプログラム組んだことないだろ？
UNIX 系で utf8 が好まれる最大の理由は内部コードとかじゃなくて、ファイル名。
ファイル名に直接 0x00 が入れられないので。あとはネットワークまわり。
そりゃ16bit（つまりUTF-16）として書くか変換すりゃASCIIの範囲の文字列は
扱えるだろうさ、そうじゃなくて8bitのASCII文字が扱えないって話
charは1文字8bitとして定義されたものだが、UTF-8を扱う場合は可変長としても考えられる
wchar_tは16bit （または 環境によっては32bit）であるがUTF-16を扱う場合は16bit単位の可変長、
つまりサロゲートペアを扱える。しかしwchar_tは所詮16bit（または32bit）単位なので8bitは扱えない
そのためUTF-8のファイルを読み込むときには、wchar_tに変換して読み込まなければいけない。
例えば8bitのASCIIコードであれば残りの8bitを\x00で埋めた16bitのUTF-8に変換するとかしてだ。
このようにASCII互換のデータを扱うためには単純にchar型をwchar_t型に置換しただけでは
だめで変換処理が必要になる。それに対してUTF-8であれば、char型を可変長char型と
みなすことでそのまま扱うことができる。文字列の長さをカウントするときとか
1文字単位で処理しなければいけないところだけ、UTF-8を扱えるライブラリを使えば良い
訂正
そのためUTF-8のファイルを読み込むときには、wchar_tに変換しながら読み込まなければいけない。
例えば8bitのASCIIコードであれば残りの8bitを\x00で埋めた16bitのUTF-16に変換するとかしてだ。
ファイルシステムに記録された物理的encodingに依存したコーディングができる方が良いという主張かねぇ。
Windows標準のXmlLiteというXMLパーサーは、入力ファイルがどんな文字エンコードだろうと、
UTF16に適宜変換するようになっているので、プログラマに読み取り時の文字エンコード選択の余地はない。
>>701
内部ネイティブ文字コードがcharになっているLinux/Unixでは
char非互換の文字コードに対応するのが大変だったという主張
>>702
Windowsは内部ネイティブ文字コードがUnicode（UTF-16）だから
別にそれでいいのでは？
それにしても結果論ではあるけど、wchar_tは失敗だったねぇ
16bitでは足りないことは最初からわかっていたけど、たとえ32bitであっても
異字体セレクタやらで意味的な1文字のbit数が固定ではなくなってしまった。
固定でないならば単純な実装で文字を扱うのは不可能。
whar_t使うメリットが無くなってしまった。
まあその怪我の功名で絵文字に色がつけられるようになり、肌色の違いも
対応も可能になったんだけど、これも良かったんだか悪かったんだが。
ここまで来たら絵文字以外の文字も全て色変化対応にしたらって思う
そうすりゃエスケープシーケンスなしで色を付けられるよ
もはや文字コードじゃないね wchar_t のこと何もわかっていないのに適当なこと言ってるな。
wchar_t は一つのプログラムで複数の文字コードを切り換えて使うための仕組みで、外部用の多バイトコードから内部文字コードに変換するのは当たり前。
char を wchar_t に書き換えるだけで済むとか誰も思っていない。そんなの言うだけ恥かしい。
大きさも規格では少なくとも 8bit で sizeof(wchar_t) >= 1 というだけ。なので 8bit でも 64 bit でも何でも良い。
windows で UTF16、linux の glibc で UTF32 を wchar_t にいれてるのは勝手にそうしてるだけで、そうしないといけないという決まりはないし、そうじゃないOSも普通にある。内部コードなので何を入れてるかはプログラマやユーザが気にする必要はない。
あと「8bit のASCII」とか寝惚けたこと言ってるけどそんなこと言うやつは文字コードの話する資格ない。ASCII が 7bit というのは常識レベルの知識。
常識だし当たり前のことだから、
言ってることに間違いはないってことかな？
今時のまともな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."
ｶﾝﾍﾟｷな引用
やはりｵﾚのﾚｽはｶﾝﾍﾟｷ
会社のﾒｰﾙは勝手にﾒｰﾙに含まれる半角を全角にかえやがる
※ 必要で半角をいれてるからな
半角でﾌｫﾙﾀﾞ名つけるﾊﾞｶがいるせいで
その半角を含むﾊﾟｽに格納されてる資料のおいてあるﾊﾟｽを送ると
ﾒｰﾙ送ったあと一時期必ず文句がきてたからな
その資料にｱｸｾｽできないと
そんな場所ないと
うんざりしたから
この部分が半角ですと書いてやっても
ｱｸｾｽできないと返信が来る
何度か半角でﾌｫﾙﾀﾞ名つけたﾊﾞｶを探しだして
しばいたろかと思ったわ
しばくんじゃなくてフォルダ名を変更すれば済むじゃん
あんたタイムゾーンスレでずっとそういう趣旨のこと言ってるよねｗ
ﾌｫﾙﾀﾞ名は一回変更したわ
すると突然
半角以下にあるﾘﾝｸがすべてｱｸｾｽできなくって
みなが大騒ぎになったわ
そんなことやったのはだれだと
幸いｵﾚがやったとﾊﾞﾚずに済んだが
メールで送らなければいい
会社のメールを変えればいい
会社を変えればいい
半角君の発想だとこんな感じ
>>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でなければ半角カナ使って良いんですよ。
バカ「む、難しい言葉でごまかすな！」
やっぱりバカどもは
なんにもわかってないわ。。。
電子メールでいうテキストというのは
７ｂｉｔだけで表現されたもんをテキストといってるワケ
つまり、伝統的にａｓｃｉｉ（７ｂｉｔ）だけで表現されてるデータをテキストと呼称してる
昔は、７ｂｉｔのデータしかやりとりできなかったネットワークもあったからな
ｕｔｆ－８とかｓｈｉｆｔ－ｊｉｓとかな、メールでは意味不明なバイナリーなわけ
分かる？
そんなテキストもどきでも
いまでもプロトコルの規定どおり７ｂｉｔのデータ以外を発信してはいけないのは当然
Ｃｏｎｔｅｎｔ－Ｔｒａｎｓｆｅｒ－Ｅｎｃｏｄｉｎｇ： ７ｂｉｔ ← コレは絶対だからな
ｕｔｆ－８やｓｈｉｆｔ－ｊｉｓのテキストもどきならｂａｓｅ６４エンコードするとかしないといけない
そのままがいいならｕｎｉｃｏｄｅのエンコード形式でｕｔｆ－７という選択肢もある
お、書けた
ﾙｰﾀ再起動でも書けなかったのに
>>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やｵﾚみたいにきわめて常識的なこといってるﾔﾂが叩かれて
しったかﾃｷﾄｰなこといってる低学歴底辺知恵遅れが幅をきかせてるのがこの板だからな。。。
>Ｃｏｎｔｅｎｔ－Ｔｒａｎｓｆｅｒ－Ｅｎｃｏｄｉｎｇ： ７ｂｉｔ ← コレは絶対だからな
前世紀の遺物かよｗ
つかオマエ、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
漏れの知ってる答えは
１も２もそういうコード書く奴はクビ すいません 文字コードについて教えてほしいことがあります マジものの初心者なんですがどうかおねがいします
Unicodeの一種（？）で65280文字ある種類のものを、なんと呼ぶのでしょうか。
（最初の方は透明に見えるフォントで始まり、最後の方は全角英数などが割り当てられています
http://www.m-hoz.com/jsp/unicode.jsp?Bgn=0&;End=65536
このページと想定しているものはまったく同じです）
WikipediaなどでUnicodeの記事を読んだのですが、バージョンや面やサブセットなどたくさんの種類があり
私が利用したいと思っている65280文字を含むUnicodeの一集合のことをなんと呼べばいいのか分かりませんでした。
というか 正直、Unicodeというのは65280文字（0xFFFF番目ですから）までしかないものと思っていましたが
なんかそれを遥かに凌ぐ量の文字が収録されていると書いてあり 余計に混乱してしまいました
文字コードに関する知識がほとんどなく おかしい文章になってしまいすいません よろしくおねがいします。 >>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="ＭＳ Ｐ明朝,ＭＳ 明朝">これは明朝体を指定</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では済まないことくらい予測できた筈なのにね
>>771
アルファベット二十数文字しか使ってない奴らが
六万文字もあれば世界中全部の文字カバーできるよな
って雑に考えたから >>773
ちょっと漢字の知識があっても漢字が５万字くらいだろ？
漢字で5万使って残り1万5千だな、余裕だろって感じだったんだろうな >>774
まあ正直，日本人でも特段勉強してなかったらそういう感覚やろうしな で、ﾊﾞｶは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 のくせに
>>816
書き手と読み手で共通のルールを作ればいいだけのこと。
どのみちASCII文字しか使えないので禁則文字が必要。 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に絵文字顔文字なんかいれたんだ？
マルチバイト文字を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でもおなじみの「鬱」でしょうね
新聞で使う文字に限るなら「鑑」で、
本当の意味での常用漢字なら「襲う」と「驚く」でしょうね
本当に身近な字ですが無駄に画数多いよね！
子供の日記でも「～でおどろいた」と良く使われるフレーズなのにね！
>>903
看板と幟で確認出来るようだ
肝心な部分が隠れてるけど
他のアングルだと欝ってなかった 複雑な文様・難解な表記ほど有難いと思ってるやつがいるうちは漢字は世にはばかり続けるだろう
>>904
＞驛辯
辨・辧・瓣・辮・? かもしれませんよ…それらが合わさって弁になったんです メールも8bit文字ををBase64などでエンコードせずにそのまま送れるのが標準になってほしいよ
普段使っているメールサーバーにtelnetを使ってEHLOではなく従来のHELOでログインして
ヘッダーにshift jisをエンコードせずに入れたメールを送ってみたが問題なく送れたから
SMTPUTF8対応を明言していなくても8bitを送れるメールサーバーは結構あるんだろうけど
20年くらい前にfjで「8bit通らないMTAってまだどっかで稼働してるのかね？」って話をしてたような気がするが。
20年前でもほぼ8bitが通る状況だったならMUAの側も
8bit文字をエンコードせずに送る設定を用意してもよさそうだが
それができるMUAはあるんだろうか
>>903
店名って公的な機関に届け出る書類に記載したりすることあるのかな？
この漢字は使えたのだろうか... 税の申告書で屋号とか書く欄があったような無かったような
>>909
>問題なく送れた
おま環だけうまくいっても意味無いんだ ５ｃｈでは、スレッドによってか板によってか知りませんが、
Unicode文字が数値文字参照に化けたりって、どういう場合
なのでしょうか？
スレの立て方で決められるのでしょうか？
⇒設定方法など、どなたか詳細をご存知でしたらご教示願います。
それとも板ごとに決まっているのでしょうか？
⇒設定一覧など、どなたか詳細をご存知でしたらご教示願います。
基本的なことようですが、自分では検索でうまくヒットできません。
BBS_UNICODE=passでも、今は数値文字参照(10進数)だけが使えるんだよな。
以前は数値文字参照(16進数)も文字実体参照も使えたんだけど。
js使った変換ツールで変換してるわ。
>>921
へえ、知らなかった。
なんかある時期から使えなくなった気がして、
ちゃんとできてる書き込みが謎だったわ。10進限定とは。 とりあえず現状を試しておこう。
ハートの全角文字テスト
♥ → ♥
♥ → ♥
♥ → ♥
さて、どうかな？
顔文字はこれ以上増やすよりZWJを使って目とか口とかを組み合わせて
自分で作れるようにした方がいいと思う
>>926
全てにおいて角こそが至上であると妄信する一種のトランス状態
一例をだすと漫画「おれは直角」の主人公がそうである 横方向に Full Width 全角
縦方向に Full Width 倍角
？
ワープロ専用機時代、横倍角なんていう気持ち悪いのがあったな
HALF WIDTH (^-^)
FULL WIDTH （ ＾ ＿ ＾ ）
iconvの文字集合オプションに「EUC-JISX0213」っていうのがあったんだけど
これシステムはEUC-jpと認識するけど中にはJIS X 0213で定められた新しい文字を
入れられるって意味……じゃないよね。
というのはSKK-JISYOで使いたい異字体があったのでこのエンコーディングをしてみたけど無理だったので。
よう分からん。
EUC-JISX0213（JIS X 0213:2000ベース）は廃止されて、EUC-JIS-2004（JIS X 0213:2004ベース）になったってことでいいのか？
改訂のタイミングでX0213から-2004に名前が変わっただけってこと？
>>942
そゆこと。
実際にはEUC-JIS-2004が上位互換だし、ウィキペディアからの引用だけど、
>なお、この符号化方式はJIS X 0213の初版 (2000年) ではEUC-JISX0213と命名されていた。
>2004年改正におけるUCS互換漢字10文字の有無だけが異なるが、大きな違いではないためEUC-JIS-2004と同一視されることもある。
とのことなので、ほぼ同じものと思ってよい。 JISの漢字コードってたまにそういうのあるよね
２文字増えただけのJIS0208-1990とか
日本マイクロソフトやAdobeが改元対応を説明
https://pc.watch.impress.co.jp/docs/news/1157118.html
同社では、1993年に「マイクロソフト標準キャラクタセット」として、
相互運用を目的とした文字コードを策定しているが、
今回の新元号対応では同社独自の対応は行なわず、ベースとなる標準に準拠し、
Code Page 932/拡張文字を含むシフトJISでは対応を行なわないと説明。
Unicodeについては標準の対応に準じた更新を予定する。
フォント更新については、同社のシステム標準フォントである
MSゴシックやMeiryo UI、Yu Gothic UIなどで新元号に対応するとした。
なお、IME辞書の更新については、フォントを含むすべての更新作業後の対応となる。 え、これってひょっとして新元号合字が使えるのはUnicode系統だけで、
JIS X0208/SJIS/CP932系統では今後永遠に使えるようにならないってこと？
元号合字を必要としてるとこって、まさに未だそういう系統を使ってるとこだと思うんだけど…
JIS X 0213に入ったら
当然Shift_JISにもいれるべき
㍻ 2D5F
㍼ 2D6F
㍽ 2D6E
㍾ 2D6D
2D5Eが空いてる
和田研細丸ゴシックのU+32FFのグリフ
平成
の次
で吹いたｗ
しかし年号の余裕も言うほどないよな
10人くらいがばばーっと毎年のように亡くなって年号も変わったらどうするつもりなのだろう
なんだかんだで西暦が一番よねえ
もしくはネトウヨが言うような皇紀とやらにしちゃいなよ
人で変わらない数字って楽ちんよー
四桁にもなれば先頭はまず変わらないわけだし
そんなにしょっちゅう変わったらさすがに文字コード需要のほうがなくなりそうだが
どのみち継承者を今後10年で10人確保するのは無理なので…
既にある文字を組み合わせた合字が増え続けるとわかっているなら次の文字が半分の大きさであることを
表すコントロールコードを作ってしまってそれを付加した2文字を使った方が良いのではないか？
そうしないと延々と文字が増え続ける。
なんかプレッシャーに耐えかねてホモに走って断絶なんてことになりそうな気もするけどなあ
Unifontだと、32FFは
３２
ＦＦ (undefined)
だね。こうゆうのが、一番解りやすくていいんだけど、
なぜ他のフォントは、マネをしないんだろうか？
Firefoxとかはフォントにない文字は自動でその表示になるよね。
まあ、文字コードがどうとか関係ない大多数の人にとって、
そんなデバッグモードみたいな出力されても逆に意味不明だから広がらないんだろうな。
未収録のままにして他のフォントで表示してくれたほうがありがたいからなあ
それだな
グリフがあると自動フォールバックが利かなくなる
U+32FFは初期のUnicodeでは現在U+3004にあるJISマークだったんだな。
で、当時U+3004は記号扱いの「仝」で漢字扱いの「仝」(U+4EDD)とは区別してたらしい。
新元号はM/T/S/H以外が実用上望ましいんだよな。
Jか…いけるなあ。
囲みCJK文字/月ブロックは平成の次で全て埋まると思ったが、U+321Fがまだ空いてるな。
次の次の元号はもしその時になっても空きだったらそこになるのかな。
マジかよ圧倒的シェアのWindowsがBOM付きだからという理由で自分は全部BOM月にしてたのに梯子外されたのかよ
>>975
わざとらしい。Windowsのネイティブ文字コードはUTF16なんだから普通はUTF16を使うだろ
メモ帳で保存するときに、Unicodeを選んだらUTF16になる
UnicodeといえばUTF16のこと >>975
そもそも Byte Order Mark の必要のない UTF-8 に BOM を付けていることが論理的に矛盾していますよね >>978
UTF-8の使用によると、BOMは文書がUnicodeであることを
自動判定するためにも用いられるらしい
だから名前がおかしいってのはあるけど、機能的には仕様どおりの使い方 >>979
＞UTF-8の仕様によると、BOMは文書がUnicodeであることを自動判定するためにも用いられる
＞らしい
らしい、ですか…
本当にそうなのか確かめてみました。RFC3629 https://tools.ietf.org/html/rfc3629 の記述は
The UCS character U+FEFF "ZERO WIDTH NO-BREAK SPACE" is also known
informally as "BYTE ORDER MARK" (abbreviated "BOM").
BOM は本来は「ゼロ長割り込みなしスペース」という意味らしいですね…
ながながとあれやこれは書いてあったのですが結論はよくわからないです、誰か英語のできる人、どこを読めばいいか教えてください… ISO10646では誤解を受けそうなBOMという呼び名は使われていなくてSignatureと言うらしい。
現在ではU+FEFFは専らSignatureを表すものとして、もともとのゼロ幅ノーブレークスペースの意味で
使用することは推奨されていない。代わりにU+2060 WORD JOINERを使用することになっている。
やはり頭悪いのはunicodeと符号化を混同してる
文書は符号化されたunicodeということになる
2つ以上のｵｸﾃｯﾄを使う符号単位で
BOM入れないﾔﾂは池沼だからな
WindowsがなぜUTF-16のことをUnicodeといっているかというと、
Windows NT 初代の3.1（1994年）当時は世界中の文字は16bitで
全て表現できると思われていたからだよ。
Windows NTは最初からUnicodeに対応したOSなのだが、
当時はUnicode = 16bit = UTF-16が成り立っていた
それが間違っているとわかってUnicodeが21bitに拡張されたのが
Unicode 2.0 （1996年7月）
メモ帳がUTF-16をUnicodeと表現するのはその名残りだよ
そういう歴史を知らないで語ると恥をかく
寿司と言えば江戸だったから江戸前って名前になった、まで読んだ。
寿司と言えば江戸ではなかったから、
江戸の寿司と強調したいときは、わざわざ江戸前寿司というようになった
ではないのか？
押し寿司とかなれ寿司が寿司だよな。
酢で酸っぱくした寿司なんかフェイク寿司もいいところ。
火縄銃といえば種子島だから種子島って名前になった、まで読んだ
違うぞ。種子島の種とは、
子種のことだぞ。
種子島＝子種島＝ザーメン島
lud20221223191801ca
このスレへの固定リンク： http://5chb.net/r/tech/1516629503/ヒント：5chスレのurlに
http://xxxx.5ch
b.net/xxxx のように
bを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「文字コード総合スレ Part11 YouTube動画>1本 ->画像>8枚 」を見た人も見ています：
・文字コード総合スレ Part10
・文字コード総合スレ part13
・全国交通系ICカード総合スレ Part19【10種相互】
・全国ICカード総合スレ Part15 【10種相互利用】
・【TREK】トレック ロード総合スレ Part106【ROAD】
・【TREK】トレック ロード総合スレ Part110【ROAD】
・【TREK】トレック ロード総合スレ Part109【ROAD】
・顔文字板イベント総合スレ Part2
・【FF14】ヴォイドアーク・クリスタルタワー 24人レイド総合スレ Part1
・キーボード総合スレ Part10
・AGPビデオカード総合スレ Part33
・【FF14】24人レイド総合スレ Part10
・【FF14】24人レイド総合スレ Part12
・【TREK】トレック ロード総合スレ Part116【ROAD】
・【TREK】トレック ロード総合スレ Part118【ROAD】
・【TREK】トレック ロード総合スレ Part90【ROAD】
・【TREK】トレック ロード総合スレ Part96【ROAD】
・【TREK】トレック ロード総合スレ Part114【ROAD】
・【TREK】トレック ロード総合スレ Part94【ROAD】
・【TREK】トレック ロード総合スレ Part93【ROAD】
・【TREK】トレック ロード総合スレ Part99【ROAD】
・全国ICカード総合スレ Part17 【10種相互利用】 [無断転載禁止]
・【コウメマイルド】三浦マイルド総合スレ Part1
・キーボード総合スレ Part3
・キーボード総合スレ Part6
・ANAカード総合スレ part 168
・ハードボイルド総合スレ Part3
・コンパクトキーボード総合スレ Part8
・【FF14】24人レイド総合スレ Part19
・【FF14】24人レイド総合スレ Part7
・【FF14】24人レイド総合スレ Part2
・【FF14】24人レイド総合スレ Part6
・【TREK】トレック ロード総合スレ Part83【ROAD】
・【TREK】トレック ロード総合スレ Part84【ROAD】
・【TREK】トレック ロード総合スレ Part75【ROAD】
・【TREK】トレック ロード総合スレ Part84【ROAD】 ©2ch.net
・【TREK】トレック ロード総合スレ Part88【ROAD】 [無断転載禁止]
・【Switch】ゼルダの伝説 ティアーズ オブ ザ キングダム ウルトラハンド総合スレ Part12
・【Switch】ゼルダの伝説 ティアーズ オブ ザ キングダム ウルトラハンド総合スレ Part13
・レコード・CD総合スレッドPART1
・【Orchid Seed】オーキッドシード総合スレ Part7
・岡尚大くん総合スレ Part1
・スタプラ総合スレ part1
・燦鳥ノム総合スレ part1
・淵江高校総合スレ Part1
・弱小YouTuber総合スレ part1
・東海の高校 総合スレ Part11
・MMDドラマ総合スレ Part11
・若手女性声優総合スレ Part11
・五嶋みどり・五嶋龍総合スレ part1
・Burson Audio 総合スレ Part1
・非バイク専門店ウェア総合スレ Part1
・シマノロッド総合スレッド Part.6
・イオンモール長久手総合スレ Part1
・既製ドレスシャツ総合スレ part11
・ハロプロ研修生総合スレ Part1271
・ハロプロ研修生総合スレ Part1581
・ハロプロ研修生総合スレ Part1641
・ハロプロ研修生総合スレ Part1671
・【FF14】24人レイド総合スレ Part27
・ハロプロ研修生総合スレ Part1131
・既製ドレスシャツ総合スレ part11
・メンズフィジーク総合スレ Part11
・ハロプロ研修生総合スレ Part1461
・ハロプロ研修生総合スレ Part1231
20:53:30 up 3 days, 7:17, 7 users, load average: 9.39, 8.77, 8.96
in 3.5806090831757 sec
@3.5806090831757@0b7 on 121510
|
