文字コード総合スレ Part11
レス数が1000を超えています。これ以上書き込みはできません。
もう JIS参考でも、amd でもなくて、正式規格本体にあるよ。情報古かったという話。
Amd3:2008 にあるんなら正式規格 ISO/IEC 10646:2012 にもあるかもしれん。確認できんけど。 規格本体に入ったのは ISO/IEC 10646:2011 >>286,312
CJK互換文字のラウンドトリップ用のものはUnicode規格書に明記されてる
> They are included in the Unicode Standard to provide full round-trip compatibility
> with the ideographic repertoire of ... and should not be used for any other purpose.
http://www.unicode.org/versions/Unicode10.0.0/ch18.pdf#page=21 素晴らしい。こういうちゃんとした情報は歓迎するよ。
そうか、CJK互換文字の利用は「推奨しない」と仕様書に明記されているんだね。覚えておこう。 「完全なラウンドトリップ互換性の為に提供するものであり、それ以外の使用は推奨しない」
だから問答無用で“should not be used”と言ってる訳じゃないけどね。 >>319
お前、その省略酷くないか。わざとか?
ソースちゃんと確認せずに信じる奴が悪いのか。
こうやってネット伝言ゲームでデマが広まるのか。 324は何を怒ってるんだ
319のフレーズは複数回出てきてその都度...の部分の規格書名が変わるだけだろうに いやだからUnicode公式が推奨しないと言ってるのは事実なんだろ。デマじゃないじゃん。
なんでもかんでもデマ扱いすれば自分が偉くなったような錯覚になって気分が良いのかもしれないが
迷惑だよ、そういう態度は。 >>328
CJK互換文字の使用が推奨されないのは事実だけど、ローマ数字が推奨されないのはデマってことなんじゃないの。
それと2行目以降は蛇足だろ。 >>329
多分違う。
「CJK互換文字の一部には特定目的以外に使用すべきでない文字がある」が正しい。
318 はわざとか天然かは知らんが、CJK互換文字の一部にしか適用されないルールを、適用範囲の部分を抜かして引用して、あたかも全体に適用するルールであるかのように誤解する書き方をしてある。
あとは、それを鵜呑みした迂闊さんが「CJK互換文字は推奨されない(キリッ)」ってデマを広げる構図。 >>332
限定せずに「ラウンドトリップ用」って書いたらCJK互換文字全体だろ。
「JIS X 0213:2000のためのラウンドトリップ用」はその一部でしかない。 気に入らないなら自分で満足の行くように書き直して貼り付ければ?
典拠示されてるんだから。 そんな中途半端に書き直して貼り付けるからデマの元になるんだろ。反省しろ。 デマはどっちだよ……「CJK互換文字は」という文脈からは「CJK互換文字に含まれる全ての文字は」という意味しか受け取れないのだが?
「一部」なんていう表現はどっから湧き出てきたんだよ……。 >>337
おまえはどこの「文脈」を読んだんだ?
とりあえず本物の規格読んでこい。 ケチ付けるんなら他人を納得させられる論拠と出典を出せよ
それができないんなら『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
一部でしかないのを全部のように言うから伝聞デマって言われたんだろ。 >>342
一般の開発者やユーザーは「CJK互換文字の利用は推奨しない」で覚えておいた方が漏れがなくて安心だな 規格書嫁とか無茶言うやつがいます。
あれは暗号で書いてあるので書いた人にも読めません。 あなたの能力の限界が人並み外れて低いからといって他人を同類扱いするのは良くない >>346
お前のような拡大解釈したいやつは「ユニコードの利用は推奨しない」で覚えておけば漏れがなくて完璧だな。 >>346
CJK互換漢字 (CJK Compatibility Ideographs) : U+F900〜U+FAFF と
CJK互換用文字 (CJK Compatibility) : U+3300〜U+33FF は別物。
>>319で非推奨とされたのはCJK互換漢字(の一部)で、CJK互換文字ではない。 >>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)
とかもあるので、勝手な名前とか使い始めるのはデマの元。 弊社の開発プロジェクトでは「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.
5ちゃんねるサーバ群が収容されているデータセンタにおいて給電装置の更新のため閲覧書き込みが出来なくなります
予定されている期間は以下の通りです
2018年6月2日(土)21時から2018年6月3日(日)10時
2018年6月9日(土)21時から2018年6月3日(日)10時
上記時間帯のうち最大5時間程度の停電が発生すると予想されています
不便をお掛けしますがよろしくお願い致します >>359
?
>2018年6月9日(土)21時から2018年6月3日(日)10時 >>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の末尾に追加になったんだな。 去年も書いたけど
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
回答ありがとう。
UnicodeのU+E000からU+E757あたりを使えばSJISにも対応できそう。 curl 'http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt' | wc -l
とやると
32292
と返ってきたんだけど、つまり今現在Unicodeには32292文字が収録されていると思っていいのかな。 >>373
中身を見ればわかるけど漢字領域 (4e00 から 9efe) とかは
飛ばしてあるから全然違う。 Android P Beta 2、グリーンサラダの絵文字からゆで卵が消える | スラド デベロッパー
https://developers.srad.jp/story/18/06/09/0621201/
ゆで卵を入れる多様性は許されないのか ジェンダーの方もなんか過剰だよね。政治的な活動家でもいるのかね
サラダの絵文字からGoogle、「卵」を排除 生産者団体が異議、「卵を返せ」論争に
https://www.j-cast.com/2018/06/09330966.html?p=all >>376
収録されている全文字を取得するにはどうしたらいいかな… どうなってんのこれ🤔
🌕🌔🌕🌕🌕🌕🌕🌕
🌕🌒🌕🌕🌕🌕🌕🌕
🌖🌓🌕🌕🌔🌕🌕🌕
🌖🌒🌕🌗🌑🌔🌕🌕
🌖🌑🌔🌘🌒🌕🌕🌕
🌕🌘🌑🌑🌑🌑🌒🌕
🌕🌕🌘🌑🌑🌑🌑🌒
🌕🌕🌖🌑🌑🌒🌗🌓
🌕🌕🌕🌘🌑🌑🌘🌔
🌕🌕🌖🌑🌑🌑🌘🌔
🌕🌕🌗🌑🌑🌑🌖🌔
🌕🌕🌕🌘🌑🌑🌕🌔
🌕🌕🌕🌗🌒🌘🌔🌕
🌕🌕🌕🌗🌒🌖🌒🌕
🌕🌕🌕🌗🌓🌕🌒🌕 5ちゃんでemojiのAAは文字数制限が厳しいからどうしても小さくなりがちだな なにか問題でも?
🧙🧚🧛🧜🧝🧟
🧙🏻🧚🏻🧛🏻🧜🏻🧝🏻🧟🏻
🧙🏼🧚🏼🧛🏼🧜🏼🧝🏼🧟🏼
🧙🏽🧚🏽🧛🏽🧜🏽🧝🏽🧟🏽
🧙🏾🧚🏾🧛🏾🧜🏾🧝🏾🧟🏾
🧙🏿🧚🏿🧛🏿🧜🏿🧝🏿🧟🏿 ユニコードとUTF8は何が違うんでしょうか
どちらもユニコード?それとも別のコード?頭がおかしくなりそうです
SJISだけで全て丸く収まっていた平和な日本にとんだ黒船がやってきた・・・ >>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 日本語が2バイトで済む安心感じゃないの?
あと、最近の根拠もなく他国をおとしめて喜んでいる類の人達には、
日本専用のコード体系かっけーさすが日本すげーとか思ってそう。 >>402
日本のビジネスデータは全銀フォーマット等のような固定長が基本だから
文字のバイト数が可変のUTF8は向かないんだよね
うちのシステムでも、相手がUTF8で作ったテキストを送りつけてきて
大事故になったことがあった 日本はまだマシで英語しか知らない欧米の連中だと「文字は1バイト」が常識だから
多言語化してても日本語を表示すると半分しか表示されないとかザラ。
最近はライブラリの整備や(通常全角幅の)絵文字の浸透のおかげで欧米の保守層にも文字コードの概念が伝わってるけどね。 絵文字どころか10年以上前流行ったような古い日本の全角顔文字発掘してきて使ったりしてるよな最近 >>403
なるほど
だとするとEBCDIC対応を求められても不思議じゃないな utf-8で何も考えずにソートしたら漢字の並びが非直感的になるから
しぶしぶsjis このスレは、Windowsを実務PCとして使ってない人が愚痴をこぼすスレですか。 ほんそれ。
Windows使ってりゃSJIS要求するのは普通だし、そのWindowsはレガシーとしてSJISを捨てられないだけだし。
神話とか日本専用コードとかw Windowsの文字コード周りで唯一好きなのは改行コードが\r\nである点。
他の環境ではLFだけという実際に即していないコードだから嫌。
LFなら普通は「桁位置はそのままで次の行に」でしょ……
abc\n
de
↑こうなるべき。 Windowsは互換性のためしょうがない部分はあるが、そういうのは\e[でやってろって感じだな。 >>412
改行コードなんだから当たり前だろ。寝ぼけんな。
CR は改行コードじゃなくて復帰コードな。ラインプリンターに出してるわけじゃないので復帰コードが必要かどうかは仕様依存。 ラインプリンター由来じゃなくてタイプライター由来じゃないの
キャリッジリターン
ラインフィード >>415
タイプライターに文字コードは必要ない。
正確にはテレタイプ端末とかテレプリンターとか呼ばれてた奴なんだが、要はラインプリンターだ。 ラインまるごと打つからラインプリンターなんだよねw 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を定義した。 コレが正解
https://i.stack.imgur.com/e4xm6.jpg
つまり
carriage returnは行頭に復帰
line feedは行送り
CRだけなら何度も同じ行が上書きされる(行送りされない)
LFだけなら例えば3行だとこうなる
XXXXXXXX
XXXXXXXX
XXXXXXXX >>426
何自慢げに周回遅れなこと書いてんだ?
それ前提の議論だぞ?
>>417見ろや そんなこといいだしたら
デリミタなんかなんでもいいことになる
ただの文字コードの羅列だからな
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コードが制定された時代から考えると、改行コードが「CR/LF」
になったのは、そうゆう趣旨かな?と思う。 >>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
> 行頭に戻さずに行だけ変えることに当時は意味があったのかも知れないけど思いつかない
例えば、ゴルフボールで次のようにタイプすることを考えてみる。(□はスペース)
□□□□□□□AA
□□□□□□□AA
□□□□□□□AA「CRの無いLF」「BS」「BS」AA
と打つと、行頭に戻すよりも速く打てると思うが。 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バイトになるでしょ。
あの 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メーカー、国家規格代表、ごく一部の文字専門家。 潤A~などは、昔の(日本の)文字コードとの互換性を取るために
残しているだけ。だから、次の元号の合わせ文字は通らない。 >>502
もうコードの場所を確保してあるってMSの元号対応ブログで言ってたよ 先月のWG2ロンドン会議で32ffが予約された
>>501
申請者に権利なんてないよ。英文ができてフォントが作れるなら誰でも提案できる 空いてるとこにテキトーにいれてるだけやん
文字コードが連続してないし
ひどいマッピングされてるわ 元号は、これからもどんどん増えてゆくんだから、Unicodeに
「日本元号面」を作って、そこに入れるようにしてほしい。 ちなみに先に書いた全文検索エンジンでは
アイウエオもアイウエオも
ガギグゲゴもガギグゲゴも
12345も12345も
abcdeもabcdeも
同じ文字コードとして扱ってる
つまりどっちでキーワード書いても当たる
見た目(つまりグリフ)が違うだけで同じだからな
しかし明治大正昭和平成を合紫順~までは
やってない
すでにいろんなもんでその全文検索エンジンは使われてるが
コレで文句がきたことはない
つまりだれも気にしてない こんな感じの内容からインデックスやマッチング用のデータが作成される
ガギグゲゴ ガギグゲゴ ⇒ カ゛キ゛ク゛ケ゛コ゛
カ゚キ゚ク゚ケ゚コ゚ ⇒ カ゜キ゜ク゜ケ゜コ゜
つまりインデックスやマッチング用のデータを作る前に前処理で一気に痴漢することになる
で、キーワードをガギグゲゴやガギギゲゴやカ゛キ゛ク゛ケ゛コ゛にすると
カ゛キ゛ク゛ケ゛コ゛で検索することになる
つまりこの全文検索エンジンは濁音も半濁音も検索できる超優れものといえるのだ 俺はそういうのを考えるのが面倒だからUNICODE正規化だけしてる
おかげで平成と~もちゃんと検索でヒットする ちなみに客ごとに置換辞書を作ってる
客ごとに要望が違うからな
客によってはいろんな要望をいってくる客もいる
その要望に応えるのも仕事だからな
で、そのなかに合紫順~を置換した例はない
全角にマッピングされてるasciiや半角カナの部分は
コレについてほぼ間違いなくみな同じ結論になる
それ以外で異なる特殊な部分は結構ある
文字コードでシノニムの部分もあれば、それ以外でシノニムにしたい部分もあったりする
それは客の業務に依存する部分になるからな 考えるのはキミじゃないワケ
キミはただのドカタなワケ
わかる?
客と良好な関係を保つには
できるだけ、それは仕様ですは避けないといけない
そしてそれを低いコストで実現できないといけない
なにをしたいのかはっきりといってる部分については
こっちから客の業務についてどうこういう必要も理由もないし
こんなしょうもないことを実現するためにめっちゃカネかかりますよとかいえるワケもない
そういうことだ >>507
次の次の次に予定されてる人が、女性に興味が持てない人だったり、
ジジイババアに囲まれて育つからババア専に育ったりするかもしれないぞ? 絵文字の無茶な合成が有りなんだから
平と成をzwjでくっつけたら~になるとかでいいのに 魚 + ZWJ + 里 = 鯉
とか収拾がつかなくなる 次の元号組み文字はCP932やJISX0213には入るのかな? 月+光=胱とか
実際に胱を人名に使えるようにしてほしいという要望があるそうだ 自力でマッピングするnkfの遅さ。文化遺産だから保守され続けるのだろうけど。 ていうか確かそういう(漢字を結合する)のにピッタシな文字が用意されてた筈。
漢字表示文字だとかいう名称だったけど、検索してもそれらしい記事が引っ掛からんので
多分この名称は違う。 >>516
日本NBがBMPに専用のコードポイントを確保することにこだわった
BMPしか扱えず合成何それ?みたいなシステムが国内にいっぱい残ってるんだと >>524
キラキラネームつけるレベルの頭の人だよ?
そんな難しいことわかんないよ。 >>520
要望する人はそんなの気にしないんでしょ >>526
アンカ間違えた
>>524
要望する人はそんなの気にしないんでしょ 合字と、ひとつの漢字が偏旁に分かれているのとはまた別だろ 胱を人名に使えるようにしてほしいと要望している人たちは
胱を月と光の合字のようなものと考えてるんだろうなって話だからな しかし肉と光でなんで膀胱なんだろうな
光は頭の上に火を掲げる神聖な存在を表していたらしいけど
特殊な性癖の人が尿を聖水というのと関係があるのかしら >>530
https://blog.goo.ne.jp/ishiseiji/e/0177ce8e642676c6cffe2e87b0fc4766
胱 コウ 月部にく
解字 「月(からだ)+光(ひろがる)」 の会意形声。身体の中で尿をためておく袋状のもの。尿がたまってくると袋がひろがる。
意味 「膀胱ボウコウ」(ゆばりぶくろ)に使われる字。旁ボウも光コウも、ひろがる意。これに肉月をつけて身体のなかで尿をためて拡がる器官を表した。 昔の知識じゃそんなこと分からんやろ
足りない頭ひねって考えろやボケナス 新元号が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で1バイトになる字がわりと使われてるよね
改行もバカにならない エディタとかUTF-32に対応してないのが多いよな。
まあ、無駄が多いからな。最上位の1バイトは必ず0x00になるから。 余ってる場所を余計なことに使う奴が絶対出てきて、
それを根絶するのに凄い辛い思いをするからヤメレ。 もうこれ人類的に根絶できないんだろうね
一生これなんだろうね そういえば、utf9というのもあったな。36ビットコンピュータに最適だとか。 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対応なんですがーw 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は対応できなかった
と思ったけど以下のような警告出るけど使えるのかw
> # 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."
カンペキな引用
やはりオレのレスはカンペキ 会社のメールは勝手にメールに含まれる半角を全角にかえやがる
※ 必要で半角をいれてるからな
半角でフォルダ名つけるバカがいるせいで
その半角を含むパスに格納されてる資料のおいてあるパスを送ると
メール送ったあと一時期必ず文句がきてたからな
その資料にアクセスできないと
そんな場所ないと
うんざりしたから
この部分が半角ですと書いてやっても
アクセスできないと返信が来る
何度か半角でフォルダ名つけたバカを探しだして
しばいたろかと思ったわ しばくんじゃなくてフォルダ名を変更すれば済むじゃん
あんたタイムゾーンスレでずっとそういう趣旨のこと言ってるよねw フォルダ名は一回変更したわ
すると突然
半角以下にあるリンクがすべてアクセスできなくって
みなが大騒ぎになったわ
そんなことやったのはだれだと
幸いオレがやったとバレずに済んだが メールで送らなければいい
会社のメールを変えればいい
会社を変えればいい
半角君の発想だとこんな感じ >>718
そいつは勘違いしてるよ。
Linux/UnixはUTF-16などASCIIと互換性がない文字コードに
対応するのが大変だからUTF-8を作ったという話をしてるのにそれをわかってない
UTF-16に対応しようと思ったら、あちこちで使われてるcharをwchar_tに変えないといけない
printfですら使うことができない。まあ現実的に不可能だわな
最初からUnicode(UTF-16)対応として設計開発された
Windows NTとは違うわけだ >>719
詳しい解説サンクス
wchar_t 難し杉ない? 外国人は鼻ほじりながら「おまいら大変だなー」と同情してるだろうな
charで全て賄える文字文化圏が羨ましい >外国人は鼻ほじりながら「おまいら大変だなー」と同情してる
その手の輩も今はemojiに対応するために結局Unicodeと向き合わなくちゃならなくなってるけどな >>717
フォルダ名に半角カナ使うなとか原始人かよw バカ「半角カナを使うと文字化けするんだぞ!使うの禁止!」
それは昔メールでよく使われていたISO-2022-JPに半角カナがないのが
理由なのでSJISやEUC-JP、今の主流のUnicodeにはあてはまりません。
ISO-2022-JPでなければ半角カナ使って良いんですよ。
バカ「む、難しい言葉でごまかすな!」 やっぱりバカどもは
なんにもわかってないわ。。。
電子メールでいうテキストというのは
7bitだけで表現されたもんをテキストといってるワケ
つまり、伝統的にascii(7bit)だけで表現されてるデータをテキストと呼称してる
昔は、7bitのデータしかやりとりできなかったネットワークもあったからな
utf−8とかshift−jisとかな、メールでは意味不明なバイナリーなわけ
分かる?
そんなテキストもどきでも
いまでもプロトコルの規定どおり7bitのデータ以外を発信してはいけないのは当然
Content−Transfer−Encoding: 7bit ← コレは絶対だからな
utf−8やshift−jisのテキストもどきならbase64エンコードするとかしないといけない
そのままがいいならunicodeのエンコード形式でutf−7という選択肢もある お、書けた
ルータ再起動でも書けなかったのに
>>727のレスをサクラで半角全角変換するだけで書けた
どの部分がよくなかったのかよくわからん
サーバーが>>727のレスをセキュリティブロックではじいてるみたいだったからな
まあいいか 日本のすべてのシステムではずっとな
メールのテキスト表示まで保証されてるのはiso-2022-jpにマッピングできる文字だけだからな
iso-2022-jpにマッピングできない文字はそもそも保証されてない
※ JISにマッピングできないUnicodeやShift半角カナなんか保証してない
※ 最低でもiso-2022-jpのフォントなら日本のどのシステムにも用意できてるハズだからな
※ そうでないとテキストすら表示できない
保証されなくてもいいなら、そのままばっちいままのテキストもどきをエンコードして発信すればいいワケ
別にUTF-8、Shift_JISで送ってはいけないということはない
※ UTF-8なんかもともとエンコードされてるオクテットをさらに7bitにエンコードしてから発信することになる
わかった? 結論をいえば
受信されるシステムで最終的にそのシステム用にデコードまでできて
表示まできるのなら問題ない
それだったら受信したヤツも腹もたたない
表示できないメールもらったら腹立つだろ
デコード未対応だったり未対応形式だったりするエロ動画をしらずにダウソしてな、
そのエロ動画が再生できないのと同じぐらいの強いイラダチを感じるハズだからな ホントなこの板は低学歴底辺知恵遅れのゴミクズしかいないのがよく分かるわ
> あと「8bit のASCII」とか寝惚けたこと言ってるけどそんなこと言うやつは文字コードの話する資格ない。
> ASCII が 7bit というのは常識レベルの知識。
ID:HgLxU9xgやオレみたいにきわめて常識的なこといってるヤツが叩かれて
しったかテキトーなこといってる低学歴底辺知恵遅れが幅をきかせてるのがこの板だからな。。。 >Content−Transfer−Encoding: 7bit ← コレは絶対だからな
前世紀の遺物かよw
つかオマエ、mohtaみたいでキモいんだが。 MIME-Version: 1.0
MIME-Versionは1.0しかない
ホントな知恵遅れがいってることは
いつも意味が分からない 低学歴底辺知恵遅れの世界にプロトコルなんかないからな
低学歴底辺知恵遅れドカタは
ネットワークのプログラムなんかやらないから関係ない 低学歴底辺知恵遅れと
まともな人間の間では
そもそも意思疎通は不可能
プロトコルがまったく違う
低学歴底辺知恵遅れ特有のプロトコルがあるらしいが
オレはそのプロトコルがまったく分からない 氏名における「」や「𠮷」や「乭」 | yasuokaの日記 | スラド
https://srad.jp/~yasuoka/journal/623209/
読売の元の記事貼ろうと思ったらネット上には無かった……。
JIS X 0213ベースなのか?
戸籍統一文字と住基ネット文字コードの擦り合わせしたデータベースはどうするんだあれ UNICODEで恥ずかしい書き込みしてた人が
大量レスでスレ流ししてるようにしか見えない ID:yTcXDgUV
連投してID赤くしてたら誰もレス読まないぞ >>739
>ID赤くしてたら
皆が皆、専用ブラウザを使っているとは限らないのでは? unicode の議論と wchar_t の議論を混ぜるやつは素人。
unicode が普及するすっと前から wchar_t は普通に使われてる。 そりゃ使われてるかどうかで言えば使われてるだろうけど。
そんなことよりも技術的な所気にならない?
問1 16bitのwchar_tで1バイト または 3バイトのEUC-JPを
扱う場合メモリイメージはどのようになるでしょうか?
問2 32bitのwchar_tで1バイトのEUC-JPを扱う場合
メモリイメージはどのようになるでしょうか?
答えわかる?意外すぎてびっくりするよ。 16bitのwchar_tや32bitのwchar_tの使い方(エンコーディング)によるとしか >>743
そういう答えの場合は、知ってる実装を一つだけでもいいので答えてくれればいいよ >>744
コンパイラとか libc を設計する奴以外は内部実装関係ないやろ。内部実装に依存したら移植性が無くなる。
知りたかったらlibcのソース嫁。最近の linux の glibc ならUCS4に統一。昔のunixだと EUCコードそのまま16ビットでフラグ付きで入れてた。 > 昔のunixだと EUCコードそのまま16ビットでフラグ付きで入れてた。
それはwchar_tが32bitってことかな?
16bitでは不可能だよね? wchar_t自体はcharset/encoding独立だとしても、実際にEUC-JPを格納する実装が
存在していたとは知らなかったな。 >>746
知らないなら、変な知ったかぶりせずに黙ってるべき。
実装によって色々差があるけど最上位ビットとかをフラグに使用して16ビットに詰め込んでたんだよ。
うろ覚えだけど、例えば
0021-007e に ascii
00a1-00fe に jis kana
2121-7e7e に 0208
a1a1-fefe に 0212
とか、そんな感じ。 やけに wchar_t にこだわる(かみつく)奴がいるけど理由がわからん
内部がどういうエンコーディングかはプログラマは意識する必要ないのに >>747
16ビットでなくて 32ビットで良いなら、今でも FreeBSD は EUC-JP をそのまま wchar_t に入れてる。
32bit なのでフラグ操作とかもなくて生のまま 0x008fa2be とか 0x00008ea0 とか。 低学歴低知能のククソニートどもや底辺ドカタどもは
自分がどんだけ知恵遅れなこと書いてるのか
なかったことにししてる
サマータイムスレでも同じだからな
コイツラ >>742
漏れの知ってる答えは
1も2もそういうコード書く奴はクビ RFC 8369 - Internationalizing IPv6 Using 128-Bit Unicode
https://tools.ietf.org/html/rfc8369 すいません 文字コードについて教えてほしいことがあります マジものの初心者なんですがどうかおねがいします
Unicodeの一種(?)で65280文字ある種類のものを、なんと呼ぶのでしょうか。
(最初の方は透明に見えるフォントで始まり、最後の方は全角英数などが割り当てられています
http://www.m-hoz.com/jsp/unicode.jsp?Bgn=0&End=65536
このページと想定しているものはまったく同じです)
WikipediaなどでUnicodeの記事を読んだのですが、バージョンや面やサブセットなどたくさんの種類があり
私が利用したいと思っている65280文字を含むUnicodeの一集合のことをなんと呼べばいいのか分かりませんでした。
というか 正直、Unicodeというのは65280文字(0xFFFF番目ですから)までしかないものと思っていましたが
なんかそれを遥かに凌ぐ量の文字が収録されていると書いてあり 余計に混乱してしまいました
文字コードに関する知識がほとんどなく おかしい文章になってしまいすいません よろしくおねがいします。 >>758
正直なところ何を言いたいのか理解できないのだが、Unicode で定義されている文字なら公式サイトで全部見られるよ。
Code Charts
http://unicode.org/charts/ >>758
基本多言語面
https://ja.wikipedia.org/wiki/%E9%9D%A2_(%E6%96%87%E5%AD%97%E3%82%B3%E3%83%BC%E3%83%89)#%E5%9F%BA%E6%9C%AC%E5%A4%9A%E8%A8%80%E8%AA%9E%E9%9D%A2
Unicodeは似てる文字を一つにまとめて約6万5000文字(16bit)に収めるぞーって
言っていたのが、案の定無理だと破綻し(だから言っただろうがバカメリケンが)、
21bitを使い最大で約111万文字収録可能になってる
最新のUnicode 11.0 では13万7439文字が収録されてる Unicodeはもはや文字コードじゃない
文字シーケンスというべきだろう
複数の文字を使って1文字を表している >>761
「基本多言語面」
ありがとうございます! すみません。言い方がボケナスで余計な労力をお掛けしました。
この言葉が知りたかったのです。
ちなみに極めてどうでもいいことですが
マインクラフトというゲームのフォントを変えたいと思っており
その為のフォントおよび文字コードの勉強していこうとしていたところでした。 HTML のフォント指定は、こういう感じ。
「html フォント指定」で検索!
HTMLの文字コードは、UTF-8
<font face="候補1,候補2,候補3">フォントを変更します</font>
<p><font face="MS P明朝,MS 明朝">これは明朝体を指定</font></p>
それとも、マインクラフトはHTMLじゃないのか? >>762
合字はそうすることが自然だからそうなってるんだと思ってるんだけど、全部個別に文字コードを割り当てたほうがいいってこと? >>764
マインクラフトのフォントは
./assets/minecraft/textures/font
というディレクトリに16ドットフォントが16列16行配置されたPNG形式の画像が0xFF枚格納されてる
というような仕様になってますね
HTMLはあんまり関係ないです。 Unicodeの公式サイト(http://unicode.org/)で,Unicodeの最新安定バージョンがなにかを調べるにはどこを見ればいいんですかね。
今11.0だそうですが,他サイトの情報なので,なるべく本家本元の情報が欲しいんです。 >>768
ちゃんとメニューを見よう。
サイトの左側のメニューから The Unicode Standard プルダウンの中にある Latest Version を選べばよい。
というわけで、現時点では 11.0 が最新という認識で正解です。 Unicodeって,なんで初めに多バイト文字のことを考えなかったんだろう。
そもそも多バイト文字を統一するために設立したようなもんなんだから,
2^16では済まないことくらい予測できた筈なのにね The Unicode Blog: New Japanese Era
http://blog.unicode.org/2018/09/new-japanese-era.html
Unicodeの方でも記事になってたのか。 >>771
アルファベット二十数文字しか使ってない奴らが
六万文字もあれば世界中全部の文字カバーできるよな
って雑に考えたから >>773
ちょっと漢字の知識があっても漢字が5万字くらいだろ?
漢字で5万使って残り1万5千だな、余裕だろって感じだったんだろうな >>774
まあ正直,日本人でも特段勉強してなかったらそういう感覚やろうしな で、バカは5マンの漢字全部読めるの?
で、バカは5マンの漢字全部書けるの?
で、バカは5マンの漢字全部使えるの?
で、バカは5マンの漢字全部使ってるの? 卜部の卜
トナカイの卜
見た目でも違いなんかまったくわからない でもコンピュータに合わせて世界を
作り変えることができるなら、
65535文字に抑えるだろうな
サマータイムもない世の中
文字も16進数が基本かな
電気の流れもマイナスからプラスへだ 君が代によれば、天皇の世は八千代続くので、
元号の合字も8000個必要になる。
Unicodeのどこかの面にまとめて確保できないものだろうか。 >>778
おおむね賛同するが
電流の流れが電子の流れと逆なのは電算機登場以前の話だぞ >電気の流れもマイナスからプラスへだ
これいつかやっても良いと思うけど
どこにどんな影響が出るんやろね
数学の外積の定義とかも変えたくなりそう >>782
電子がマイナスからプラスへと流れると電流がプラスからマイナスへ流れるという理解で問題ない 数字が連続してない符号化文字集合ってあるのかな。
EBCDICとかは英語が連続してないことで有名だけど。 C言語の規格で'0'から'9'は連続していることになってたと思うから
そうじゃない文字コードがあったとしてもとっくに淘汰されてるのでは 世界共通になる前に6と9のどちらかを変更しておいて欲しかった >>786
毎日のように使うのに、普通に気が付いてなかった。
おもしろい。
けど文字集合ではないなw
>>788
あと1と7 漢数字がそれが表わす数字順に並ばないって結構有名だったのか……恥かしい >>788
9って手で書くときはqみたいな形じゃない?
なんでコンピュータのフォントだと丸まるんだろう。 >>791
ビリヤードの玉なんかわざわざ区別のつかないような字形にした上で
区別が付くように線を引いてるんだぜ 1960年代1970年代では、
コーディングシート上で「O(オー)」」と「0(ゼロ9)とを
区別するために
Fortranは「「O(オー)」の上に傍線を書いたし、
COBOLでは、「0(ゼロ)」に斜線を引いて区別
してたような気がする。
「I(あい)」と「1(いち)」の場合は、「I(アイ)」を
小文字の「i」を使っていたような気がする。
なにぶん、古い話なので、間違っているかもしれないが
一応参考までに 斜線入りの0
VS使ってU+0030 U+FE00で表せるように
なってたんだな。 >>795
本当だ!
って、なぜVS?重ね書きでいいのだから合成では、って探したらU+0338 U+0030でもいいらしい……
二重収録…… まーーた「異字体」という概念を欧米のやつらがめちゃめちゃにしやがったな >>794
Dも横線入れたり、Uは必ず小文字のヒゲ書いたな
今でも手書きアルファベットでついやっちまうw Unicodeをめちゃくちゃにしてるのは大昔の馬鹿な中国人 斜線入りゼロの全角版もU+FF10 U+FE00で規定しようとしてるな。
もうアホかと。 21bitも使わせるからそんな浪費するんだよ。16bitで我慢させておくべきだった。 多コードポイント文字(←?)なのでビット数関係ない
むしろ、16bitに詰め込むために合成やVS、ZWJのような小細工が作られてしまって
それが乱用されてる UCS-4でコードポイントで利用できる領域は21bitまでときまってる
コードのレンジはMSBを除く31bitまで
コードポイントのビット数とエンコードのビット数は関係ない
相変わらず低学歴知恵遅れは
意味不明なことばっかりいう >>804
知恵遅れは自分の思慮の浅さを認識出来ないから知恵遅れなんだぞ
仮に間違っていても何らかの意図や思惑があって発言したものを
意味不明と思考停止した時点で自分が馬鹿だと宣言するようなものだから
賢いつもりならもっと謙虚な態度を取るべきだ
>>803は複数のコードポイントのシーケンスで一文字を表す体系を採用した時点で
コードポイントが何ビットかはそれほど重要な問題じゃないと言っているわけだし
基本面しかなかったころにUCS2でコードポイントを16bitで表現していたのだが
賢いつもりならそれを分かっててそんな馬鹿のことを書いてるのか? お、おう……ありがとう
「誰一人エンコーディングの話はしてねーだろ幻視かそれともセレクタ知らんのか」ぐらいは書こうとしたんだが >>796
U+0030 U+FE00は標準化されてるけどU+0030 U+0338の方はそうじゃない
スラッシュ0っぽいものになるかもしれないという程度
あとVSは検索時には無視されるんで0030と等価になる >>807
従来のやり方に合わせるとU+0030 U+0338に対応するNFC形式を用意して検索は互換分解で対応ってならね?
逆にVSを検索時無視するという仕様を活用するなら、互換分解よりもそっちが良かったって文字が他に沢山ない?
まあ、今更言ってもなんだ 訂正、合成文字の方が先だからU+0338 U+0030 なんで混同している人がいるのかえあからないけど合字と変種は別のものだよ。
合字はもとの文字と別物として扱われるのに対して、変種はあくまで同じ文字の字形違い。 すいません
「�����������d」
という文字列を解読したいです。
$ echo '<当該文字列>' | od -A xn -t x1
の結果は
000000 ef bf bd ef bf bd ef bf bd ef bf bd ef bf bd ef
000010 bf bd ef bf bd ef bf bd ef bf bd ef bf bd ef bf
000020 bd 64
のような感じです。
個人的には\0x0eや\0x0fが多く登場しているのでUTF-16あたりをUTF-8で解釈しているのかなとも思いまして
iconv(1)などでどうにかしようとしました(iconv -c -f utf16 -t utf8)が 駄目でした。
どうかよろしくおねがいします。 >>811
utf8のEF BF BDは、utf16ではFFFD(非文字)。
例えば、エンコードに失敗した時に使われる。 >>813
なるほど。復元は無理ってことですね。thx URLエンコードとか16進文字列で表示してほしいよね。
文字化け文字列を表示されても途方に暮れる。 >>815
表示したい文字とそれ以外をどうやって区別させる? 低学歴知恵遅れの世界ではグリフが違うように見えれば
その字じたいがもつ意味もかわる φと Φ の小さい字が小文字 ɸ だと一緒のはずなんだが環境によって違うのが困る unicode のくせに https://github.com/JuliaStrings/utf8proc
これすばらしいね。
UTF8の煩雑な処理がC89という極めて汎用で互換性の高い言語で扱えるなんて。
ただUnicode11対応を謳ってる割には曖昧文字幅が考慮されてないのが難点
issueやPRを見てるとそれっぽい対応がされてるのかどうなのか……。
https://github.com/JuliaStrings/utf8proc/pull/83 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) >>816
書き手と読み手で共通のルールを作ればいいだけのこと。
どのみちASCII文字しか使えないので禁則文字が必要。 https://www.softek.co.jp/SPG/Pgi/performance52.html
ここのページのエンコーディングって分かる?
EUC-JPで読みこむと漢字だらけ
Shift JISで読みこむと半角カナの「ス」だらけ
UTF-8で読みこむと非文字だらけ chrome で開いたけど問題なく日本語出るぞ
おまいのブラウザが糞なんじゃね
ブラウザ経由せずに python でダウソしたら中身 UTF-8 のファイルが出来た
<META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
EUC-JP ってことになってるな 夜に見たときはFirefoxでもChromiumでもWaterfoxでも
ID:lmrEE7TEが言うような文字化けになってたけど
今はFirefoxでもChromiumでもWaterfoxでも文字化けせずに見られる
そのサイトのほうがおかしくなってたんじゃないか? apacheとかデフォでutf-8に強制変更とかあるからな >>825
同じく
夕べ、バイナリモードでgetしたhtmlが思いきり文字化けしてたわ あっっれ。
まさかなと思ってもう一度行ったら なんかちゃんと読めるようになってたわ。
うーん。向こうの不具合かな。とりあえずFirefoxに濡れ衣を着せてしまったことをお詫びします。
ただしFirefoxには
http://www.am.ics.keio.ac.jp/~keisuke/lab/ptex218.html
↑このページが読めないという前科があるんだよね。 最近のブラウザは一時的に文字コード指定するメニュー無くなった >>829
そのページはサーバーでUTF-8決め打ちで送って来てる
ファイル内に書かれたcharsetとどっちを優先するかって話なのかな http://www.am.ics.keio.ac.jp/~keisuke/lab/ptex218.htmlは
WaterfoxやChromiumでも文字化けする
Waterfoxだと文字コードの手動切り替えで対応できるけど
自動判定できない状況に陥っているのだからサイト側の問題なんだろうね HTTPはheaderみてそっち優先のブラウザばっかになってつまらんぬ そういえば、昔おまじない文字ってあったよな
「京」とか だいたい日本語TeXを使ってるのなら文字コードに関する知識はそれなりにある筈なんだけどなぁ >>829
EdgeでもIE11でも読めないぞ。
これもFirefoxのせいじゃない。
ちなみにw3mでは読めた。
>>832
サーバーがレスポンスヘッダで文字コードをUTF-8と返してるからそれに従ってるだけ。
そもそも自動判定しようとしてない。それなのにコンテンツはUTF-8以外(ISO-2022-JP)で出来てる。
要はサーバーの設定とコンテンツの不整合。
恐らくサーバー更新時に古いコンテンツのことを考慮してなかったんだろうな。 RedHat や CentOS のパッケージで Apache をインストールするとデフォルトで AddDefaultCharset UTF-8 が有効になっているのが原因。
この設定をコメントアウトし忘れると今回のようなことが起きてしまう。
これ、わりと迷惑度合いの高いデフォルト設定なんだよねえ…… UTF-8デフォルトはそれこそLinux機にとっては嬉しいんだけどねぇ
ちなみにnghttp2というHTTP/2に特化したWebサーバーは
HTTP/2の既定エンコーディングがUTF-8であるにもかかわらずなんとASCII。
いつの時代だよ……。しかも古いプロジェクトじゃなくてめっちゃ新しいのに……。 最近またUnicodeが分からなくなってしまった。
単にShift_JISのような
「一部コードを拡張マップ専用の文字にして後続のコードを
その拡張マップ専用の文字のコードと連続した(つまり2次元的な配置の)コードとして
処理する」
っていう方法ではないのか。 ISOのダウンロードサイトがもう何年も
本文はちゃんとcharset=ISO-8859-1だと書いてるのに
HTTPヘッダでcharset=UTF-8宣言してて台無しになってる。
ASCIIはいいけどフランス語のとこがずっと文字化けしてるんだけど誰も気付かないのかね。
……と書き込もうと思って確認したらいつの間にか直ってたわ、ちっ 実際に使用されていた、おもしろい文字コードとかない?
例えばBaudot Codeは英数字がバラバラの順番で出現する、非直感的な配置になってる。 IEC646を使う事ももやめてUS-ASCIIに統一した方がいいよな。
それで問題が起きる時はフォントの方を変えて対処すればいい 絵文字はどんどん規格にない不文律が増えていくんだな 誰がunicodeに絵文字顔文字なんかいれたんだ? https://en.wikipedia.org/wiki/Template:Smiley
ここの絵文字のソースコードを見ると<abbr>要素を使ってマークアップしてるんだけど
こういうのって一般的なのかな。 https://s.codepen.io/aardrian/debug/ENJdjN
ここでは
<span role="img" aria-label="Snowman">☃</span>
としてるね マルチバイト文字を2つのシングルバイト文字で囲いたい場合
マルチバイト文字の中にそのシングルバイト文字があった場合、囲えないんですけど
マルチバイト文字を理解しないで囲うにはどうしたらいいですか? >>862
仮にUTF-32で処理したところで、今は合成やらIVSやらZWJやら絵文字やらで
特殊ルール満載で境界が曖昧なので、理解しないで1文字切り出すのは無理 U+2053のSWUNG DASHってどういうときに使うか分かる?
波ダッシュと同じ使い方でいいのかな。 ⁓
〜
〜
〜
~
~
 ̄
〜
〜
∼
〜
≁
∻
〰
~
 ̄
~
 ̄
〜 >>860
alia-label=属性は絵文字の音声読み上げが上手くできなかった時代の対処療法。
今はほとんどの(特に視覚障碍者が使うような)音声読み上げが絵文字に対応してるので
必要ないかと。role=属性をimgにするという案はいいね。 今でもASCII制御文字で使われている物はHT CR LFくらいかな? NUL SO SI ESC SPACE DEL 辺りも使うかな ^cはシグナルを送るキーとして使われてるだけで改ページの意味があるわけではないからなあ
とはいえ改ページとしてのFFがあるテキストファイルもたまにある Win32APIのMessageBoxはテキストに0x03が含まれてるとゴニョゴニョ Unicodeの概念そのものは好きだけど
太字の「>」とか 要る? そういう太字にしたり斜体にしたりするのはワードプロセッサーや写植システムの役割だろう。 知らんけどもともとどっかにあったんじゃないの?
とりあえずなんでも拾っとくことこそUnicodeの概念とやらの本質じゃないの? なんでも拾っておくってなら、CJKまとめるなんて暴挙はなかったろ 別々の集合からならまとめても元に戻せるから矛盾しないぞ >>887
それは16ビットで収めるためのMSの暴挙 絵文字排除するはずだったのに何のための文字コードだったのか むしろいちいちフォントなんか使わずに画像使えばいい 記号類にもUnihan Databaseみたいな典拠集積したやつを作っておくべきだったなとは思う。 「画数の多い文字」として知られているけれども本当に実用されていた文字なのか誰も確認できず、
しかし「画数の多い文字の例」として使われているために少なくともそれ以後は実在していると考えるしかないという >>899
じゃあ実用されていた漢字で一番画数が多いのはなんですか? 実用なら身も蓋もありませんが親鸞の「鸞」と、2chでもおなじみの「鬱」でしょうね
新聞で使う文字に限るなら「鑑」で、
本当の意味での常用漢字なら「襲う」と「驚く」でしょうね
本当に身近な字ですが無駄に画数多いよね!
子供の日記でも「〜でおどろいた」と良く使われるフレーズなのにね! https://map.goo.ne.jp/place/22001814283/
浜松市に「たいと(雲雲雲龍龍龍)」という四川料理店があるが、
これで「実用化」されたことになるだろう。 複雑な文様・難解な表記ほど有難いと思ってるやつがいるうちは漢字は世にはばかり続けるだろう >>904
>驛辯
辨・辧・瓣・辮・? かもしれませんよ…それらが合わさって弁になったんです メールも8bit文字ををBase64などでエンコードせずにそのまま送れるのが標準になってほしいよ
普段使っているメールサーバーにtelnetを使ってEHLOではなく従来のHELOでログインして
ヘッダーにshift jisをエンコードせずに入れたメールを送ってみたが問題なく送れたから
SMTPUTF8対応を明言していなくても8bitを送れるメールサーバーは結構あるんだろうけど 20年くらい前にfjで「8bit通らないMTAってまだどっかで稼働してるのかね?」って話をしてたような気がするが。 20年前でもほぼ8bitが通る状況だったならMUAの側も
8bit文字をエンコードせずに送る設定を用意してもよさそうだが
それができるMUAはあるんだろうか >>903
店名って公的な機関に届け出る書類に記載したりすることあるのかな?
この漢字は使えたのだろうか... 税の申告書で屋号とか書く欄があったような無かったような https://hitosara.com/0005040173/
既になくなってしまったみたい
文字だけでなく読みさえも実在の怪しい「おとど」のほうは元気なようだが >>909
>問題なく送れた
おま環だけうまくいっても意味無いんだ 5chでは、スレッドによってか板によってか知りませんが、
Unicode文字が数値文字参照に化けたりって、どういう場合
なのでしょうか?
スレの立て方で決められるのでしょうか?
⇒設定方法など、どなたか詳細をご存知でしたらご教示願います。
それとも板ごとに決まっているのでしょうか?
⇒設定一覧など、どなたか詳細をご存知でしたらご教示願います。
基本的なことようですが、自分では検索でうまくヒットできません。 BBS_UNICODE=passでも、今は数値文字参照(10進数)だけが使えるんだよな。
以前は数値文字参照(16進数)も文字実体参照も使えたんだけど。
js使った変換ツールで変換してるわ。 >>921
へえ、知らなかった。
なんかある時期から使えなくなった気がして、
ちゃんとできてる書き込みが謎だったわ。10進限定とは。 とりあえず現状を試しておこう。
ハートの全角文字テスト
♥ → ♥
♥ → ♥
♥ → ♥
さて、どうかな? 📛 日本人には幼稚園児の名札に見える絵文字は、外国人には何なのかさっぱりわからず『燃えるトーフ』と呼ばれていた - Togetter
https://togetter.com/li/1292538 顔文字はこれ以上増やすよりZWJを使って目とか口とかを組み合わせて
自分で作れるようにした方がいいと思う >>926
全てにおいて角こそが至上であると妄信する一種のトランス状態
一例をだすと漫画「おれは直角」の主人公がそうである 横方向に Full Width 全角
縦方向に Full Width 倍角
? ワープロ専用機時代、横倍角なんていう気持ち悪いのがあったな HALF WIDTH (^-^)
FULL WIDTH ( ^ _ ^ ) iconvの文字集合オプションに「EUC-JISX0213」っていうのがあったんだけど
これシステムはEUC-jpと認識するけど中にはJIS X 0213で定められた新しい文字を
入れられるって意味……じゃないよね。
というのはSKK-JISYOで使いたい異字体があったのでこのエンコーディングをしてみたけど無理だったので。 >>933
少しぐらいは調べろよ……検索したら幾らでも情報が出てくるよ。
EUC-JPの一種だけど今は廃止されてる。
EUC-JIS-2004 - Wikipedia
https://ja.wikipedia.org/wiki/EUC-JIS-2004
EUC-JISX0213 ‐ 通信用語の基礎知識
https://www.wdic.org/w/WDIC/EUC-JISX0213 よう分からん。
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の漢字コードってたまにそういうのあるよね
2文字増えただけの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のグリフ
平成
の次
で吹いたw しかし年号の余裕も言うほどないよな
10人くらいがばばーっと毎年のように亡くなって年号も変わったらどうするつもりなのだろう
なんだかんだで西暦が一番よねえ
もしくはネトウヨが言うような皇紀とやらにしちゃいなよ
人で変わらない数字って楽ちんよー
四桁にもなれば先頭はまず変わらないわけだし そんなにしょっちゅう変わったらさすがに文字コード需要のほうがなくなりそうだが どのみち継承者を今後10年で10人確保するのは無理なので… 既にある文字を組み合わせた合字が増え続けるとわかっているなら次の文字が半分の大きさであることを
表すコントロールコードを作ってしまってそれを付加した2文字を使った方が良いのではないか?
そうしないと延々と文字が増え続ける。 なんかプレッシャーに耐えかねてホモに走って断絶なんてことになりそうな気もするけどなあ Unifontだと、32FFは
32
FF (undefined)
だね。こうゆうのが、一番解りやすくていいんだけど、
なぜ他のフォントは、マネをしないんだろうか? Firefoxとかはフォントにない文字は自動でその表示になるよね。
まあ、文字コードがどうとか関係ない大多数の人にとって、
そんなデバッグモードみたいな出力されても逆に意味不明だから広がらないんだろうな。 未収録のままにして他のフォントで表示してくれたほうがありがたいからなあ それだな
グリフがあると自動フォールバックが利かなくなる U+32FFは初期のUnicodeでは現在U+3004にあるJISマークだったんだな。
で、当時U+3004は記号扱いの「仝」で漢字扱いの「仝」(U+4EDD)とは区別してたらしい。 新元号はM/T/S/H以外が実用上望ましいんだよな。
Jか…いけるなあ。 囲みCJK文字/月ブロックは平成の次で全て埋まると思ったが、U+321Fがまだ空いてるな。
次の次の元号はもしその時になっても空きだったらそこになるのかな。 Windows 10 Insider Preview、メモ帳でBOMなしのUTF-8が選択可能に | スラド デベロッパー
https://developers.srad.jp/story/18/12/14/0345249/
ついに マジかよ圧倒的シェアの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と表現するのはその名残りだよ
そういう歴史を知らないで語ると恥をかく 寿司と言えば江戸だったから江戸前って名前になった、まで読んだ。 寿司と言えば江戸ではなかったから、
江戸の寿司と強調したいときは、わざわざ江戸前寿司というようになった
ではないのか? 押し寿司とかなれ寿司が寿司だよな。
酢で酸っぱくした寿司なんかフェイク寿司もいいところ。 火縄銃といえば種子島だから種子島って名前になった、まで読んだ 違うぞ。種子島の種とは、
子種のことだぞ。
種子島=子種島=ザーメン島 このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 329日 2時間 3分 30秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。