■ このスレッドは過去ログ倉庫に格納されています
文字コード総合スレ Part12
- 1 ：デフォルトの名無しさん：2018/12/17(月) 16:48:24.47 ID:Pfqpaohb.net
- プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
UTF-8、Shift_JIS、JIS、EUC、Unicode、UCS、サロゲートペア、コードポイント、文字コード判定、
合成文字、ソート、TRON、外字コード、その他について語り合いましょう。
各言語での文字列の扱いについての質問もOKです。
基本マッターリ、ささ、茶でもどうぞ。
■過去スレ
文字コード総合スレ part1 http://pc11.2ch.net/test/read.cgi/tech/1031028205/
文字コード総合スレ part2 http://pc11.2ch.net/test/read.cgi/tech/1143375639/
文字コード総合スレ part3 http://pc11.2ch.net/test/read.cgi/tech/1180250376/
文字コード総合スレ part4 http://pc11.2ch.net/test/read.cgi/tech/1228052369/
（スレ再利用）UnicodeとUTF-8の違いは？ http://pc12.2ch.net/test/read.cgi/tech/1177930957/
（隔離スレ）UnicodeとUTF-8の違いは？ その2 http://pc12.2ch.net/test/read.cgi/tech/1274937437/
文字コード総合スレ part5 http://pc12.2ch.net/test/read.cgi/tech/1236529563/
文字コード総合スレ part6 http://hibari.2ch.net/test/read.cgi/tech/1278923059/
文字コード総合スレ part7 http://toro.2ch.net/test/read.cgi/tech/1306595564/
文字コード総合スレ part8 http://peace.2ch.net/test/read.cgi/tech/1354248962/
文字コード総合スレ part9 http://peace.2ch.net/test/read.cgi/tech/1401301779/
文字コード総合スレ Part10 http://mevius.2ch.net/test/read.cgi/tech/1444822140/
文字コード総合スレ Part11 http://mevius.5ch.net/test/read.cgi/tech/1516629503/
- 2 ：デフォルトの名無しさん：2018/12/17(月) 16:49:24.92 ID:Pfqpaohb.net
- ■参考サイト
Unicode Home Page
http://www.unicode.org/
Java Character Encodings
http://www.ingrid.org/java/i18n/encoding/
euc.JP: tech docs, BeOS tools
http://euc.jp/
IANA: Character Sets
http://www.iana.org/assignments/character-sets
Legacy Encoding Project
http://sourceforge.jp/projects/legacy-encoding/
CP50220
森山さんの説明
http://lists.sourceforge.jp/mailman/archives/legacy-encoding-talk-ja/2006-March/000002.html
JIS X 4061
日本語文字列照合順番
http://www.jisc.go.jp/
- 3 ：デフォルトの名無しさん：2018/12/17(月) 16:50:24.77 ID:Pfqpaohb.net
- ■これまでに行われた議論
・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のほうが化けにくい
- 4 ：デフォルトの名無しさん：2018/12/17(月) 16:51:24.91 ID:Pfqpaohb.net
- ・中国語の簡体字では、へんやつくりが簡略化されるなら、その文字も自動的に簡略化して表記する国家規格が有る
・中国語の「噁心」簡化政策によると「恶(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サニタイズが面倒になるのか
- 5 ：デフォルトの名無しさん：2018/12/17(月) 16:52:24.56 ID:Pfqpaohb.net
- ・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の人にはそれがわからんのですよ。
- 6 ：デフォルトの名無しさん：2018/12/17(月) 16:53:24.65 ID:Pfqpaohb.net
- もうひとつの過去スレ:
文字コード統一スレ 1文字目
http://pc8.2ch.net/test/read.cgi/tech/1109171258/
隔離スレ:
UnicodeとUTF-8の違いは？
http://pc12.2ch.net/test/read.cgi/tech/1177930957/
UnicodeとUTF-8の違いは？ その2
http://hibari.2ch.net/test/read.cgi/tech/1274937437/
UnicodeとUTF-8の違いは？ その2
http://toro.2ch.net/test/read.cgi/tech/1291075205/
UnicodeとUTF-8の違い4(インディアン隔離スレ)
http://toro.2ch.net/test/read.cgi/tech/1342963035/
- 7 ：デフォルトの名無しさん：2018/12/17(月) 16:54:24.71 ID:Pfqpaohb.net
- ■ライブラリ
IBM Globalization - ICU
http://www-306.ibm.com/software/globalization/icu/
NKF32.DLL
http://www.vector.co.jp/soft/win95/util/se020949.html
バベル
http://tricklib.com/cxx/ex/babel/
バベルの文字コード判定で使ってる日本語文書内での各文字の出現頻度データです。
http://tricklib.com/cxx/ex/babel/scoremap.csv
mlang
http://msdn.microsoft.com/ja-jp/library/aa767865(en-us).aspx
iconv
http://www.gnu.org/software/libiconv/
ICU
http://www.icu-project.org/
- 8 ：デフォルトの名無しさん：2018/12/17(月) 16:55:24.40 ID:Pfqpaohb.net
- ■単語一覧
・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とか。
- 9 ：デフォルトの名無しさん：2018/12/17(月) 16:56:24.69 ID:Pfqpaohb.net
- JTC1/SC2/WG2 - ISO/IEC 10646 - UCS
http://std.dkuug.dk/JTC1/SC2/WG2/
ISO/IEC JTC1/SC2/WG2/IRG
Ideographic Rapporteur Group
http://appsrv.cse.cuhk.edu.hk/~irg/
- 10 ：デフォルトの名無しさん：2018/12/17(月) 16:58:24.64 ID:Pfqpaohb.net
- 前スレが終了間近だったので立てました。
追加するサイトなどあればよろしくお願いします。
- 11 ：デフォルトの名無しさん：2018/12/17(月) 20:17:00.51 ID:WCs/11MM.net
- 文字コード総合スレ Part12
https://mevius.5ch.net/test/read.cgi/tech/1544931495/
- 12 ：デフォルトの名無しさん：2018/12/18(火) 10:08:11.45 ID:xxM0ZIZ4.net
- >>1
U+30B9 U+30EC U+7ACB U+3066 U+4E59
- 13 ：デフォルトの名無しさん：2018/12/18(火) 11:22:14.11 ID:/M0/bFGF.net
- >>11 の本スレ推奨
Part 13 になったら起こしてくれ
- 14 ：デフォルトの名無しさん：2019/03/08(金) 14:51:30.23 ID:uMMKH+w1.net
- 一応メモ
https://qiita.com/yumetodo/items/54e1a8230dbf513ea85b
- 15 ：森& ：2019/03/09(土) 06:47:26.73 ID:ZOfzHyh2.net
- C++17
非推奨の詳細
wstring_convert<...>
codecvt_utf8_utf16<...>
codecvt_utf8<...>
codecvt<...>
Unicodeの文字コード変換を行うこれらのクラスは、不正なコードポイントに対する
安全なエラー処理の方法を提供していなかったため、セキュリティ上の欠陥があった。
仕様もあいまいであったため、不正なコードポイントに対してどのように振る舞うかも
不明であった。
Unicode以外のShift_JISやBig5といった文字コードの利用が急激に減少している。
標準ライブラリでの現代的なUnicodeの変換機能は非常に必要とされているが、
<codecvt>とそれに関連する機能の設計はお粗末なものだった。
将来より良いものを作るために、これらの機能は非推奨とする。
標準ライブラリにUnicodeの文字コード変換をする代替機能はないため、
他の専門特化した文字コード変換のライブラリを使用すること。
https://cpprefjp.github.io/reference/locale/wstring_convert
https://ja.cppreference.com/w/cpp/locale/codecvt_utf8_utf16
どれ使えばええの？
森鷗外𠮟る
- 16 ：デフォルトの名無しさん：2019/03/09(土) 07:24:12.96 ID:h0df79AA.net
- C++自体が非推奨
- 17 ：デフォルトの名無しさん：2019/03/09(土) 16:56:18.99 ID:kfZA3URW.net
- C++11の糞仕様がずっと放置されてる
本スレ消費はよ
- 18 ：デフォルトの名無しさん：2019/03/10(日) 00:54:02.53 ID:ktyeDSUM.net
- C++の次の改訂ではC++の全ての仕様が削除されるべき
- 19 ：デフォルトの名無しさん：2019/03/10(日) 17:40:35.50 ID:uFsYqTSV.net
- CJKが頑張って苦情入れたら非推奨にされましたとさ
https://twitter.com/theoridetech/status/933329866392444929
(deleted an unsolicited ad)
- 20 ：デフォルトの名無しさん：2019/03/10(日) 17:47:41.69 ID:yzd/Af8M.net
- リョウくんにお返事貰ってるな。
- 21 ：デフォルトの名無しさん：2019/03/10(日) 18:01:51.00 ID:uFsYqTSV.net
- 非推奨というより使用禁止レベルの糞やでcodecvt
- 22 ：さまよえる蟻人間 ：2019/03/10(日) 18:05:00.62 ID:eLFCjw3Q.net
- https://github.com/katahiromz/iconv_wrap
使ってね。
- 23 ：デフォルトの名無しさん：2019/03/11(月) 04:49:49.14 ID:pTTv+VC9.net
- 本当に怖い文字コードの話
なんか貼れないので分割
heppoko.
hatenadiary.
jp/
entry/
2018/04/28/184559
- 24 ：デフォルトの名無しさん：2019/03/11(月) 08:44:07.99 ID:u2Hto+zd.net
- ツイッターで#テクノロジー犯罪と検索して、まじでやばいことを四代目澄田会の幹部がやってる
被害者に対して暴力団以外にタゲそらしをしてるがやってるのは暴力団で普段外に出ることが少ないため遊びで公共の電波と同じような電波を使って殺人をしてる
統失はほとんどが作られた病気で実際は電波によって音声送信や思考盗聴ができることが最近明らかになりつつある
警察や病院では病気としてマニュアル化されてしまっているのが現状で被害者は泣き寝入りしてる
被害者がリアルタイムで多い現状を知って、被害者間でしか本当の事だと認知できていない
実際にできると思われていない事だから、ただの幻聴ではない実際に頭の中で会話ができる
できないことだと思われているからこそ真面目に被害を訴えてる
海外でも周知されつつあることを知ってほしい。
このままだとどんどん被害が広がる一方
#テクノロジー犯罪
#四代目澄田会
- 25 ：デフォルトの名無しさん：2019/03/11(月) 13:01:21.07 ID:qRllmJaM.net
- >>218
ㇹ゚ン゚'ㇳ̃ヴ゙ニ゙コ゚ヮヰ文̂字̠コ゚−ト゚ノ゙ㇵナ゚ㇱ
- 26 ：デフォルトの名無しさん：2019/03/11(月) 14:24:48.05 ID:hfHU2O5u.net
- char_traits の length って信用していいの？
- 27 ：デフォルトの名無しさん：2019/03/12(火) 03:51:12.13 ID:FSVt1tPQ.net
- 若干違和感ある部分も
絵文字がある種のUnicodeバグを世界から一掃しつつある件について
note.mu/
ruiu/n/nc9d93a45c2ec
- 28 ：デフォルトの名無しさん：2019/07/12(金) 14:43:41.63 ID:q8HbeEfz.net
- Unicodeが出してるiconvみたいな変換ライブライあるじゃん？
あれどうなん？
- 29 ：デフォルトの名無しさん：2019/12/25(水) 20:38:30.91 ID:N+K1pmuB.net
- なんか文字追加されたね。
https://unicode.org/charts/beta/nameslist/
- 30 ：デフォルトの名無しさん：2019/12/27(金) 08:43:18.71 ID:GMT90LLU.net
- と思ったらUnicode 13発行されるのか。
- 31 ：デフォルトの名無しさん：2020/04/11(土) 19:22:36.64 ID:md0SvLvZ.net
- またUnicode.orgのサーバー落ちてる……
- 32 ：デフォルトの名無しさん：2020/06/17(水) 21:52:52.20 ID:5H4oQmhP.net
- https://abs-0.twimg.com/emoji/v2/svg/1f6f8.svg
- 33 ：デフォルトの名無しさん：2020/07/03(金) 16:13:30.65 ID:o8JvC3od.net
- 文字コード総合スレ Part12
https://mevius.5ch.net/test/read.cgi/tech/1544931495/
が1000行ったけどこっち再利用するのかな?
- 34 ：デフォルトの名無しさん：2020/07/03(金) 20:55:14 ID:elbfDzqw.net
- 重複スレが残ってたのか
Part13立てちゃった
- 35 ：デフォルトの名無しさん：2020/07/03(金) 23:14:01.31 ID:uIgOlo/V.net
- 「コマンドプロンプトはcp932（SJIS）である」はウソ
Windows NTの標準の文字コードであるUnicode（UTF16-LE）の
テキストファイルを作り、chcp 932のままtypeコマンドで表示してみましょう
文字化けせずに表示されますね？
（フォントがない場合は表示されないがそれ以外は問題ない）
これは明らかにコマンドプロンプトがUnicodeで動作している証拠です。
コマンドプロンプトがUnicode動いているという証明はこれで十分だと思いますが、
もし仮に反論があるならその根拠を言ってくれれば説明を追加します。
（根拠なしにcp932にきまってるだろ！みたいなものは一言で潰しますのでよろしく）
- 36 ：デフォルトの名無しさん：2020/07/03(金) 23:59:01.41 ID:2ewiuNjd.net
- >>34
責任持って誘導しろ
https://mevius.5ch.net/test/read.cgi/tech/1593777227/
- 37 ：デフォルトの名無しさん：2020/07/04(土) 00:12:44.08 ID:xxQcNpXl.net
- ヒラキ゛ノ角コ゛シック
- 38 ：デフォルトの名無しさん：2020/07/04(土) 02:05:01.27 ID:Vdunr+kB.net
- MS Gothic = ＭＳ ゴシック
MS PGothic = ＭＳ Ｐゴシック
MS UI Gothic = MS UI Gothic
- 39 ：デフォルトの名無しさん：2020/07/04(土) 21:58:35.22 ID:0DTN05zS.net
- 「うわー、ID:uIgOlo/V 君て博識なんだね。私も試してみるね。
「コマンドプロンプトを開いて…と
「それで “漢字”と入力したファイル k を UTF16 LE で保存と…
「よし準備完了！
--
C:\>od -x k
0000000 feff 6f22 5b57 000d 000a
0000012
C:\>type k
漢字
C:\>copy k con
・"oW[
1 個のファイルをコピーしました。
C:\>cat k
・"oW[
C:\>type k | od -t x1
0000000 8a bf 8e 9a 0d 0a
0000006
C:\>
--
「あれれ？ ID:uIgOlo/V 君、なんかおかしいよ？ どうして？
「“「コマンドプロンプトはcp932（SJIS）である」はウソ”なんだよね？
- 40 ：デフォルトの名無しさん：2020/07/04(土) 22:21:02.22 ID:xxQcNpXl.net
- cmd /U /C echo Hello | od -t x1
- 41 ：デフォルトの名無しさん：2020/07/04(土) 23:31:46.91 ID:M3d71N9d.net
- >>39
cmd /?
/A 内部コマンドの出力結果を ANSI でパイプまたはファイルに出力します。
/U 内部コマンドの出力結果を Unicode でパイプまたはファイルに出力します。
- 42 ：デフォルトの名無しさん：2020/07/05(日) 12:27:30.05 ID:dKznqT0V.net
- >>39
chcp 65001
- 43 ：デフォルトの名無しさん：2020/07/05(日) 13:58:13.31 ID:jQ41esUI.net
- というか、コマンドプロンプトにCP932にない文字を貼り付けて普通に出力できている時点で
コマンドプロンプトが特定のコードページに依存していないと気づくだろ。
echo 六四清场
- 44 ：デフォルトの名無しさん：2020/07/05(日) 14:04:49.45 ID:jQ41esUI.net
- mingwのcatやgrepをコマンドプロンプトから呼び出すと一時的にchcp 65001な状態になって画面出力される。
- 45 ：デフォルトの名無しさん：2020/07/05(日) 21:04:09.52 ID:M+BkbwUs.net
- >>44
それはコマンドプロンプトがUTF-16なので、
mingwのcatやgrepがUTF-8で出力すると文字化けするからだね
- 46 ：デフォルトの名無しさん：2020/07/05(日) 23:20:17.80 ID:jQ41esUI.net
- >>45
コマンドプロンプトがUTF-16なので、
mingwのcatやgrepがSJISで出力すると文字化けするからだね
という論法も成り立つが。
- 47 ：デフォルトの名無しさん：2020/07/06(月) 01:59:06.09 ID:T074ZQpk.net
- mingwのcatやgrepでSJISにない文字も表示できるので
その論法は成り立たない
- 48 ：デフォルトの名無しさん：2020/07/06(月) 10:35:57.48 ID:vjiPzzt6.net
- SJISちゃんのことは早く忘れろ
- 49 ：デフォルトの名無しさん：2020/07/07(火) 00:26:29.24 ID:wqab1oeP.net
- やだーExcelのマクロファイルSJISだもん
- 50 ：デフォルトの名無しさん：2020/07/08(水) 17:17:18.70 ID:h0xUNipw.net
- Office文書自体はOOXMLでUTF-8になったのに
マクロは未だにShift_JISなのか。
- 51 ：デフォルトの名無しさん：2020/07/09(木) 09:25:45.33 ID:vrNDocOm.net
- 唐突かつ広範な主張
マウントスタート
主観的な理由
地に足のつかない結論
わずかな文章に愚かさが詰め込まれていて揶揄せずにおれない
- 52 ：デフォルトの名無しさん：2020/07/18(土) 13:33:37.82 ID:uRU3MGLx.net
- 知られざる顔文字の世界
https://www.hottolink.co.jp/blog/20161114_66202/
- 53 ：デフォルトの名無しさん：2020/07/20(月) 21:19:31.88 ID:SNT5szCU.net
- AppleとGoogle、世界絵文字デーに新絵文字を披露
https://www.itmedia.co.jp/news/articles/2007/20/news053.html
- 54 ：デフォルトの名無しさん：2020/07/21(火) 11:54:04.73 ID:+OCbOnRh.net
- 絵文字の話題鹿無いのか
- 55 ：デフォルトの名無しさん：2020/07/21(火) 11:57:01.74 ID:SHIoqAPz.net
- もうそろそろ音文字もできてほしいよね
- 56 ：デフォルトの名無しさん：2020/07/21(火) 19:48:37.21 ID:yq9jKXcW.net
- 昔懐かしMIDI復活
- 57 ：デフォルトの名無しさん：2020/07/22(水) 01:25:29.84 ID:u6QrHnkl.net
- いつかはアニメ文字も作られるのかな?
- 58 ：デフォルトの名無しさん：2020/07/22(水) 03:14:08.06 ID:WLvtiBEO.net
- >>57
iモードにあったような無かったような
- 59 ：デフォルトの名無しさん：2020/07/22(水) 03:39:38 ID:IIwMuy9z.net
- <MARQUEE><BLINK>動きがあるのは気が散るからやめてほしいな</BLINK></MARQUEE>
- 60 ：デフォルトの名無しさん：2020/07/22(水) 07:25:55.44 ID:IySnQNum.net
- 懐かしのって
初音ミクとかMIDIで出来てるだろ
- 61 ：デフォルトの名無しさん：2020/07/22(水) 11:49:19 ID:J4Vacr3k.net
- >>59
<ITALIC><BIG>旧タグなら書き込めるんだw</BIG></ITALIC>
- 62 ：デフォルトの名無しさん：2020/07/24(金) 03:27:13.24 ID:6ZonvnML.net
- 音文字か。そう言えば Ctrl+G (7) は BELL だったような。
ASCIIだけか? Unicode だと決まってないんだっけ？
- 63 ：デフォルトの名無しさん：2020/07/24(金) 03:43:48.92 ID:5ghYNMX+.net
- マザボのブザーでも鳴るの？
- 64 ：デフォルトの名無しさん：2020/07/24(金) 05:05:05 ID:6ZonvnML.net
- さあ? 処理するプログラムに寄るんだろうな。
Windows のコマンドプロンプトで 7 のコード出力してみたら音が出たよ。
- 65 ：デフォルトの名無しさん：2020/07/24(金) 05:05:33 ID:6ZonvnML.net
- BIOSのビープ音ではなく Windows 側のサウンドの設定が関係しているんだろうと思う。
- 66 ：デフォルトの名無しさん：2020/07/24(金) 10:07:32.92 ID:gSKUw3+G.net
- UnicodeでもU+0007はBELL CHARACTER
- 67 ：デフォルトの名無しさん：2020/07/24(金) 10:53:36.75 ID:qMgm686n.net
- printf("\x7\n");
- 68 ：デフォルトの名無しさん：2020/07/24(金) 11:02:13.19 ID:kTZ1cNqr.net
- マザボのビープスピーカではなくサウンドデバイスで鳴らすようになったのはwin7以降だっけ
- 69 ：デフォルトの名無しさん：2020/07/24(金) 11:14:24.17 ID:f4UMJCtp.net
- 2000ジャマイカ
- 70 ：デフォルトの名無しさん：2020/07/24(金) 17:43:05.10 ID:YBlLKE+B.net
- 2000の時代に練習した時はprintfでビープ鳴ってた
- 71 ：デフォルトの名無しさん：2020/07/24(金) 18:43:29.22 ID:sQG3RcOn.net
- >>68
普通に考えりゃvista以降からでしょう
7かvistaかで本体beep鳴らすapi叩いたらpcmでがっかりだったのは覚えてる
apiだとATのbios同様周波数や長さ指定できて遊べたんだがな
同時にいじられるとよくないから切られたんでしょう
- 72 ：デフォルトの名無しさん：2020/07/24(金) 19:01:43.86 ID:vNSj5xVg.net
- なついなぁ。
Win32API Beep()
https://docs.microsoft.com/en-us/windows/win32/api/utilapiset/nf-utilapiset-beep
- 73 ：デフォルトの名無しさん：2020/07/24(金) 19:18:02.12 ID:yBBtjj2V.net
- beep用スピーカーがマザーボードから省略され始めたんだよ。
- 74 ：デフォルトの名無しさん：2020/07/24(金) 19:22:19.50 ID:7vmGBdx3.net
- 昔は音を鳴らせるアプリは一つだけだった。
いつからか複数のアプリが同時に鳴らせるようになったんだが
いつからだっけな
- 75 ：デフォルトの名無しさん：2020/07/25(土) 00:55:48.04 ID:W2vK2AQR.net
- うろ覚えだが、ビープスピーカーで力業で音楽演奏するソフトがあったような気がする
- 76 ：デフォルトの名無しさん：2020/07/30(木) 04:08:23.78 ID:y8VtuE5G.net
- >>66
Unicode では ALERT
または BEL
- 77 ：デフォルトの名無しさん：2020/07/30(木) 16:30:24.90 ID:EPvquY9v.net
- tab は \t
だから
bell は \b
と思ってた時期がある
- 78 ：デフォルトの名無しさん：2020/07/30(木) 16:41:49.22 ID:TNnZNpws.net
- 合わせると
食べる
- 79 ：デフォルトの名無しさん：2020/07/31(金) 22:29:23 ID:j/9/9lyu.net
- >>77
\bの本当の意味ってなんだっけ。
- 80 ：デフォルトの名無しさん：2020/07/31(金) 22:33:31 ID:LZrfPAZb.net
- バックスペース
- 81 ：デフォルトの名無しさん：2020/07/31(金) 22:42:27 ID:LZrfPAZb.net
- しかしこういうのってティッカーテープとかテレタイプの時代にさかのぼるらしいね。
現物を見たことはないが用語だけはいろいろ残っているという。
- 82 ：デフォルトの名無しさん：2020/08/01(土) 01:00:50.03 ID:WNKlelSF.net
- 遠隔で物理CR/LFは夢がある
- 83 ：デフォルトの名無しさん：2020/08/01(土) 18:43:21 ID:6JQgXAfu.net
- 一番夢があるのは肯定応答とかかな。
というのも，改行やエスケープとかはもちろん，場合によっては警鈴なんかも
未だに現役なのに対して，「肯定応答」という意味で^Fが使われているのを見たことがないから。
^Fはもう，各ベンダーごとに都合の良い，全く違う制御シーケンスになっちゃってる。
- 84 ：デフォルトの名無しさん：2020/08/01(土) 19:03:29.73 ID:hFu7PbvL.net
- NAK
- 85 ：デフォルトの名無しさん：2020/08/26(水) 16:48:18 ID:P4l77+uM.net
- 毎日新聞ニュースさんはTwitterを使っています 「天皇陛下即位のお祝い品のリストと写真を㏋で公開 宮内庁」 / Twitter
https://
twi
tter.com/
mainichijpnews/status/1297833742753439744
HPが合字の㏋ (U+33CB)に
- 86 ：デフォルトの名無しさん：2020/08/26(水) 17:29:56.14 ID:tn5jjKWE.net
- 正規化のせいやな。
知らんけど。
- 87 ：デフォルトの名無しさん：2020/08/27(木) 00:37:34.21 ID:Jx+0/WN9.net
- いまだに手書き、あるいは印刷した紙で原稿を入れてくる記者がいて、
入稿をOCRで文字起こししたらHPをその合字の方に認識、そのまま放置、とか?
ちなみにこれってHorse Powerでよかったですか?
- 88 ：デフォルトの名無しさん：2020/08/27(木) 11:49:50.52 ID:igmT7d/I.net
- 馬力
- 89 ：デフォルトの名無しさん：2020/09/02(水) 16:48:23.22 ID:wDhsuzOT.net
- そう言えば中国のGB 18030が改訂されるって話はどうなったんだろう？
何年か前にKenが最終原案を見たよって言ってた気がしたけど、続報がない。
- 90 ：デフォルトの名無しさん：2020/09/02(水) 23:24:39 ID:jWdQ7Iud.net
- その後Kenの姿を見た者はいないという
- 91 ：デフォルトの名無しさん：2020/09/03(木) 15:58:49 ID:ACS7FND0.net
- 13対応の花園もﾏﾀﾞｰ?
- 92 ：デフォルトの名無しさん：2020/09/20(日) 08:14:38.84 ID:BIMERbR5.net
- Emoji 13.1 - Now final, to be widely available in 2021
http://blog.unicode.org/2020/09/emoji-131-now-final-to-be-widely.html
- 93 ：デフォルトの名無しさん：2020/09/20(日) 18:04:46.19 ID:j6+bQw5M.net
- Androidの絵文字追加がOSバージョンアップ前提だから取り残される環境が多すぎるんだよな
どうにかアプリ枠で配信してくれたらいいのに
- 94 ：デフォルトの名無しさん：2020/09/20(日) 18:46:29.19 ID:RjVJO5D2.net
- woman with beard
誰得？
- 95 ：デフォルトの名無しさん：2020/09/20(日) 18:47:31.92 ID:RjVJO5D2.net
- https://www.unicode.org/announcements/emoji-13-1-annc-couples.jpg
最初から顔に色なんか付けなきゃ良かったのに
- 96 ：デフォルトの名無しさん：2020/09/20(日) 20:32:09.64 ID:69fdZo9j.net
- だっぷるがつけちゃったんだもん
- 97 ：デフォルトの名無しさん：2020/09/21(月) 00:08:08.68 ID:fGf6DMu1.net
- 顔に色が無いと全部白人に観えるんだろ
黒い顔だけ造っておけばよかった
- 98 ：デフォルトの名無しさん：2020/09/21(月) 09:05:25.63 ID:apXLM6YN.net
- そもそも文字コードになんで色情報なんか含めたんだろ
あれも発端はPCがらみだっけ？
- 99 ：デフォルトの名無しさん：2020/09/21(月) 10:33:58.83 ID:13UcesYH.net
- 俺は良かったと思うけどな。おかげで文章としての表現力が上がった。
- 100 ：デフォルトの名無しさん：2020/09/21(月) 10:35:23.80 ID:13UcesYH.net
- 一夫多妻を表す絵文字はつくらないのかね？
- 101 ：デフォルトの名無しさん：2020/09/21(月) 10:44:58.40 ID:M8W5JifW.net
- 姦
嬲
嫐
- 102 ：デフォルトの名無しさん：2020/09/21(月) 17:50:51.21 ID:ttv6HIBF.net
- >>95
そっか、これコードを結合していくと作れるんだ。面白い。
男＋白肌＋ハート＋男＋黒肌 みたいな。
仕組みは面白いが、処理する側は大変そうw
あとキーボードの絵文字パレットとか、全パターン表示しないといけないのかな?
- 103 ：デフォルトの名無しさん：2020/09/21(月) 18:17:56.53 ID:fI5zzMAW.net
- > 仕組みは面白いが、処理する側は大変そうw
うん。だから個々の人が処理するんじゃなくて
OS標準のテキスト処理として実装されたから素晴らしいんだよ
普通に文字を出力すれば、絵文字対応になるから
- 104 ：デフォルトの名無しさん：2020/09/21(月) 18:45:37.15 ID:ttv6HIBF.net
- >>103
OSレベルでテキストのレンダリングとかめんどくさくなったはいうまでもなく、
一般のデベロッパもユニコード文字列をうかつに処理できなくなった罠。
ま、 ちゃんとAPIを使えとか、そういうことで、それはいいことなのかもしれないけど。
- 105 ：デフォルトの名無しさん：2020/09/21(月) 19:08:16.33 ID:sDzSgcbr.net
- ユニコードはウィルスなので送らないでください
- 106 ：デフォルトの名無しさん：2020/09/21(月) 19:45:05.95 ID:LKcGYABn.net
- >>104
それは絵文字以前の話だけどね。
Unicodeの当初の目標でも16bit固定＝C言語の終端文字である\0が1文字の中に
含まれる事があるので、文字はUnicodeとして扱わなければいけないことが決定していた。
Unix/Linux系ではC言語の終端文字である\0を避けるためにUTF-8を採用したが
可変長バイトだから、これもUnicodeとして扱わなければいけない。
どちらにしろちゃんとAPIを使えという話は避けられなかったんだよ。
そして絵文字のおかげでサロゲートペアが必要となる文字への対応が進むといういい結果をもたらしたｗ
- 107 ：デフォルトの名無しさん：2020/09/21(月) 21:02:01.32 ID:XIYZJxnC.net
- 想定しないといけない1文字の長さを具体的有限にしてくれないかなあ
- 108 ：デフォルトの名無しさん：2020/09/21(月) 21:15:43.93 ID:GxzcHgtD.net
- アキラメロン
最終的には複数の文字を組み合わせて64 x 64 ドットに
自由なアイコンを作れるようになるだろう
- 109 ：デフォルトの名無しさん：2020/09/21(月) 23:04:34.98 ID:dVFtF0fU.net
- 今時ピクセルは無いだろ。
SVG埋め込みの方が可能性がある。
- 110 ：デフォルトの名無しさん：2020/09/22(火) 03:30:53.25 ID:EwzeVKsQ.net
- >Unix/Linux系ではC言語の終端文字である\0を避けるためにUTF-8を採用したが
これは違うんじゃまいか
結果的にそうなっただけであって
意図してそうした訳じゃない
- 111 ：デフォルトの名無しさん：2020/09/22(火) 03:34:39.51 ID:Ab752W48.net
- >>110
意図してUTF-8を作ったんだよ
本来はUnicodeにはUTF-16しか無かった。
外部機関があとから作り出したもの。それがUnicode本家に採用された
- 112 ：デフォルトの名無しさん：2020/09/22(火) 05:08:49.52 ID:w/6Y1Cd5.net
- UTF8の方がUTF16より歴史が古いよ。
ユニコードが国際規格になる前からある。
- 113 ：デフォルトの名無しさん：2020/09/22(火) 11:24:31.43 ID:X1mK+PSm.net
- >>98
NTTDoCoMo・au・Softbankの絵文字の時点でカラーになってたじゃん
互換性を保つために必要
- 114 ：デフォルトの名無しさん：2020/09/22(火) 11:58:02.00 ID:UY6+hZuP.net
- >>112
> UTF8の方がUTF16より歴史が古いよ。
> ユニコードが国際規格になる前からある。
いちいちすぐバレる適当なウソつくんじゃねーよ
https://ja.wikipedia.org/wiki/Unicode#%E6%AD%B4%E5%8F%B2
1991年10月 Unicode 1.0.0 7,161文字 初期バージョン、16ビットの文字コード
1992年6月 Unicode 1.0.1 28,359文字 CJK統合漢字を導入
https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt
> UTF-8 was designed, in front of my eyes, on a
> placemat in a New Jersey diner one night in September or so 1992.
UTF-8は1992年9月に私の目の前で設計された
> We had used the original UTF from ISO 10646
> to make Plan 9 support 16-bit characters, but we hated it.
Plan 9で16ビット文字をサポートするためにISO 10646の
オリジナルのUTFを使用していた が私たちはそれを嫌っていました。
> However, UCS and its UTF variant do not protect
> null bytes and/or the ASCII slash ("/") making these character encodings
> incompatible with existing Unix implementations.
しかしUCSとその亜種であるUTFはヌル文字とスラッシュを保護せず
存在するUnixの実装と互換性がありません。
- 115 ：デフォルトの名無しさん：2020/09/22(火) 12:07:37.87 ID:EwzeVKsQ.net
- それは単にカラーで表示していただけで色情報を持っていたわけじゃないだろ。
発端はやっぱり肌色の問題だったらしい。
https://internet.watch.impress.co.jp/docs/special/670150.html
- 116 ：デフォルトの名無しさん：2020/09/22(火) 14:22:08.65 ID:iCejn/78.net
- ナメック星人用に緑の肌もあるの？
- 117 ：デフォルトの名無しさん：2020/09/22(火) 15:07:13.30 ID:pk1eyzkq.net
- >>114
わかっていないのはお前
UCS-2≠UTF-16
1991年のUnicode 1.0.0の時点ではUnicodeの符号化文字は2バイトのみだったから2バイト固定長符号化
文字集合や符号化方式のUCS-2は当然存在していたが、サロゲートペアを使って1文字を2バイトまたは
4バイトで表現する符号化方式のUTF-16はこの時点では存在していない(存在できない)
Unicode 1.1.0より前にFSS-UTFという名称でファイルシステム安全な符号化方式として現在のUTF-8が
Plan9向けに策定され1993年のUnicode 1.1.0で導入
ttps://www.unicode.org/versions/Unicode1.1.0/appF.pdf
1996年のUnicode 2.0.0でサロゲートペアが導入されたのでサロゲートペアを利用する符号化方式の
UTF-16が概念として登場(まだ概念のみでUTF-16という名称はついていないはず)
ttp://unicode.org/versions/Unicode2.0.0/
FSS-UTFがUTF-2を経てUTF-8という名称になったのは同じくUnicode 2.0.0
ttp://www.unicode.org/versions/Unicode2.0.0/appA.pdf
ISO/IEC 10646としてはUTF-16もUTF-8も1996/10/15発行のAMD 1とAMD 2で策定
- 118 ：デフォルトの名無しさん：2020/09/22(火) 15:35:18.08 ID:6o8of7S0.net
- >>117
UTF-16という名称はついてないはずとかお前の希望はいらん
証拠もってこいや
- 119 ：デフォルトの名無しさん：2020/09/22(火) 15:37:16.35 ID:6o8of7S0.net
- > UTF8の方がUTF16より歴史が古いよ。
> ユニコードが国際規格になる前からある。
ユニコードってなにか知ってますか？
Unicode 1.0もユニコードなんですがｗ
- 120 ：デフォルトの名無しさん：2020/09/22(火) 15:37:46.01 ID:6o8of7S0.net
- さてユニコードが国際規格になる前とはいつのことでしょうかねｗ
- 121 ：デフォルトの名無しさん：2020/09/22(火) 16:12:08.88 ID:uF0JvJPV.net
- TkライブラリがいまだにUCS-2のままなのはなぜなんだぜ？
- 122 ：デフォルトの名無しさん：2020/09/22(火) 22:03:17.96 ID:72aYjsjv.net
- >>98
文字の色が意味を持つトンパ文字なんてのもあるから
どのみち色情報は必要になったんじゃない？
- 123 ：デフォルトの名無しさん：2020/09/22(火) 22:08:31.29 ID:6VKGlvlr.net
- utf8の歴史は知らんけど7zやrar5のヘッダの64bit値の可変長は影響されて出てきたもんだと思ってるわ
- 124 ：デフォルトの名無しさん：2020/09/22(火) 22:17:21.12 ID:qhIXHkhL.net
- 可変長の数値といえばMIDIかなー
- 125 ：デフォルトの名無しさん：2020/09/23(水) 03:28:56.77 ID:mCjrd8MP.net
- 答え出てるじゃん
UTF8方式が発明されたのは1992年
UTF16方式は1995年
国際規格(ISO)になったのは1996年
- 126 ：デフォルトの名無しさん：2020/09/23(水) 08:26:01.74 ID:+jrDbaEU.net
- Unicode 1.0.0 (October, 1991)
http://www.unicode.org/versions/components-1.0.0.html
- 127 ：デフォルトの名無しさん：2020/09/23(水) 08:34:33.77 ID:7Cl+Ulja.net
- Unicodeは業界規格であって国際規格ではない
国際規格なのはISO/IEC 10646で初版は1993年
文字コード関係で専門用語を雑に扱うと議論が混乱するから正確に用語を使え
- 128 ：デフォルトの名無しさん：2020/09/23(水) 09:04:10.27 ID:mCjrd8MP.net
- さらに ISO 10646 の 1993 年版は Unicode とは厳密には異なる文字コード規格。
1996年版と Unicode 2.0 で両者が統一された。
- 129 ：デフォルトの名無しさん：2020/09/23(水) 09:07:37.04 ID:irsqaiS+.net
- >>125
UCS-2はUTF-8より前からあったんだが？
話理解してる？UTF-8はUCS-2（UTF-16）で困ったから
外部機関が作り出したものって話をしてる
- 130 ：デフォルトの名無しさん：2020/09/23(水) 09:08:10.50 ID:irsqaiS+.net
- この話
110 名前：デフォルトの名無しさん[] 投稿日：2020/09/22(火) 03:30:53.25 ID:EwzeVKsQ [1/2]
>Unix/Linux系ではC言語の終端文字である\0を避けるためにUTF-8を採用したが
これは違うんじゃまいか
結果的にそうなっただけであって
意図してそうした訳じゃない
111 名前：デフォルトの名無しさん[sage] 投稿日：2020/09/22(火) 03:34:39.51 ID:Ab752W48
>>110
意図してUTF-8を作ったんだよ
本来はUnicodeにはUTF-16しか無かった。
外部機関があとから作り出したもの。それがUnicode本家に採用された
- 131 ：デフォルトの名無しさん：2020/09/23(水) 09:10:39.13 ID:irsqaiS+.net
- > UTF8方式が発明されたのは1992年
当時はUTF8という名前ではなかった。UTF-16と同時につけられた名前
最初はUTF-1という名前があった。
これの改良版としてPlan9が考えたものを採用しUTF-8と名付けた
- 132 ：デフォルトの名無しさん：2020/09/23(水) 09:47:37.94 ID:hJkRvCZv.net
- >>124
この板では ruby だろ常考
- 133 ：デフォルトの名無しさん：2020/09/23(水) 12:40:50.21 ID:mCjrd8MP.net
- かなり誤解しているやつがいるので業界規格(Unicode)と国際規格(ISO-10646)の反発と協調の歴史をまとめた細い部分は間違ってるかもしれないので、捕捉よろしく。
U: 業界規格(Unicode) およびその源流、I: 国際規格(ISO-10646)およびその源流
U:(0) 1980年、Xerox が独自の統一文字コードを作る
- XCCS: Xerox Character Code Standard
- 16-bit 固定長
- 漢字は日本漢字(JIS X 0208),(この時点で GB2313 とか無かった)
- Unicode とは互換性はないが、アイデアの元となった
I:(1) 1983年、国際標準規格(ISO)として統合文字コードの検討開始
- この時点では 16 bit の文字コードを想定していた
I:(2) 1984年、ISO で統一文字コード用の専用ワーキンググループ設置
- IOO-10646 という番号が決まる
I:(3) 1985年、ISO 10646 の検討案(DP 10646)が出される
- 16 bit で漢字は非統合
- 主に漢字国から拡張性(収容可能な文字数)の不足についてクレームが出る
U:(4) 1987年 Xerox の Becker と Collins が統一文字コードの研究を開始
- これが後の Unicode になる
- 16 bit 固定長で各国の漢字を統合
U:(5) 1989年 Unicode Draft 1 〜 Final Draft が発表される
- 16 bit の文字コードで最大約6万字が収容可能
I:(6) 1990年、ISO-10646 の最初の草案(DIS 10646-1)が発表される
- この時点では Unicode とは全く異なる文字コード
- 16 bit では文字数が明らかに足りないので 32bit 文字コードに
- それに合わせて基本多言語面(BMP)という考え方を導入
(続く)
- 134 ：デフォルトの名無しさん：2020/09/23(水) 12:41:36.26 ID:mCjrd8MP.net
- U:(7) 1991年、業界団体として The Unicode Consortium が結成
- Unicode を業界共通規格にすることを目指す業界団体
- 初期メンバーは Xerox, Apple, IBM, Microsoft, など
U:(8) 1991年、The Unicode Consortium によって Unicode 1.0 vol.1 が策定
- 16ビット固定長文字コード
- 厳密にいえば結合文字とかあるので可変長だけど、約6万字しか実装できない
I:(9) 1992年、 ISO-10646 の第二の草案(DIS 10646-2)が発表
- 改良して Unicode と親和性を高くしたもの
- 31bit 文字コード (UCS: Universal Coded Character Set)
- 基本多言語面(BMP)に Unicode をそのまま採用
- 基本は4バイト文字コードとして実装(UCS-4 と命名)
- Unicode 部分(当時)のみの 2バイトの実装水準も許可(UCS-2 と命名)
I:(10) 1992年、UCS-4 の ASCII との互換性のある可変長符号化方式が考案
- UCS Transfomation Format (UTF)と呼ばれ、後に UTF-1 と呼ばれる
I:(11) 1992年、Plan9/Unix のファイルシステムで使用できる別の UTF が考案
- File System Safe UTF と名付けられ、UTF-2 とも呼ばれる。
- これが後に UTF-8 と呼ばれるようになる
I:(12) 1993年、ISO/IEC 10646-1:1993 が正式に国際規格化
- BMP に Unicode 1.1 を採用しているため Unicode の上位互換
- あくまで 31bit の文字コード規格で、16 bit の Unicode とは別の文字規格
- Unicode側へも 32bitへの拡張を打診したが領域を食い過ぎといって断わられた
- UTF-1 は規格の付録に採用されているが、UTF-8 はまだ採用されてない
(続く)
- 135 ：デフォルトの名無しさん：2020/09/23(水) 12:43:30.64 ID:mCjrd8MP.net
- U:(13) 1995年、サロゲートペアの考案
- Unicode 側でもあいつぐ文字の追加要求で 16 bit では破綻することが明らかに
- 現行の 2バイト方式と互換性のある拡張方式が必要
- これが後に UTF-16 と呼ばれる
X:(14) 1995年、Unicode と ISO で協調していくことに合意
- BMP 以外の面も Unicode と ISO-10646 で同じ文字を採用する
- 最大文字数はサロゲートペアで表現可能な 16面までとする
U:(15) 1996年、Unicode2.0 を発表
- 2面以降を採用
- 2面以降を符号化にサロゲートペア(UTF-16)方式を採用
- UTF-8 方式も 付録A にて記載
I:(16) 1996年、ISO-10646 を追補(Amendment)で改訂
- あくまで 31 bit だが 17面以降を永久に実装しないことに
- (13)の方式を UTF-16 という名前で採用(Amd1)
- (11)の方式を UTF-8 という名前で採用(Amd2)
- UTF-1 を廃止
- その他文字の追加/変更の追補によって Unicode 2.0 と完全互換に
その後も協調しながらアップデート
(以上)
- 136 ：デフォルトの名無しさん：2020/09/23(水) 12:50:04.51 ID:YfY3TQQ4.net
- >補足よろしく
わろす
- 137 ：デフォルトの名無しさん：2020/09/23(水) 12:51:35.74 ID:irsqaiS+.net
- つまり>>106は正しいということ
> Unicodeの当初の目標でも16bit固定＝C言語の終端文字である\0が1文字の中に
> 含まれる事があるので、文字はUnicodeとして扱わなければいけないことが決定していた。
> Unix/Linux系ではC言語の終端文字である\0を避けるためにUTF-8を採用したが
> 可変長バイトだから、これもUnicodeとして扱わなければいけない。
- 138 ：デフォルトの名無しさん：2020/09/23(水) 13:42:18.16 ID:mCjrd8MP.net
- >>137
厳密には違う。
UTF-1 の時点で 0x00 は入らないくて C言語で使用可能。
でも / が 2バイト目以降にが入ってるので Unix 等のファイルシステムで使えない欠点があった。
これを改良するために考案されたのが FSS-UTF (UTF-2)、のちに UTF-8 と命名。
- 139 ：デフォルトの名無しさん：2020/09/23(水) 13:50:08.66 ID:BgUeNus/.net
- >>137
業界規格としてのUnicodeは符号化方式（今のUTF-16）について，
Cやシェルのことを考えていなかったけど，
それが国際標準になる時に，
符号化方式の一つとしてUTF-8を採用してCやシェルを考慮した，
ってこと？
- 140 ：デフォルトの名無しさん：2020/09/23(水) 13:59:02.67 ID:mCjrd8MP.net
- 重要なのは FSS-UTF (後のUTF-8) は 16 bit の業界 Unicode を符号化するために考案されたのではなくて、31 bit の国際規格 UCS-4 を符号化するために考案されたということ。
その後、Unicode が 17 bit 以上に拡張される時にサロゲートペアが考案されて、それを国際規格側では UTF-16 と名付けた。
だから UTF-8 にサロゲートペア入れるやつは×ね。
- 141 ：デフォルトの名無しさん：2020/09/23(水) 15:18:09.77 ID:7/mhYxCT.net
- ルーピー儲であふれてるスレ
- 142 ：デフォルトの名無しさん：2020/09/23(水) 20:40:55.14 ID:FfABxMH0.net
- >>125
で、UTF-8が国際標準に入ったのは何時なの？
なんで開発された年と標準化された年を比較してるの？
- 143 ：デフォルトの名無しさん：2020/09/24(木) 01:15:56.19 ID:2TpuCg1t.net
- >>142
だれもそんな比較してない。よく読め
UTF8方式が提案された年とUTF16方式が提案された年を比較してる。
- 144 ：デフォルトの名無しさん：2020/09/24(木) 01:22:18.61 ID:27/WCIy4.net
- >>143
え？なんでそんな話してるの？
それの何が重要なの？
- 145 ：デフォルトの名無しさん：2020/09/24(木) 01:26:57.76 ID:27/WCIy4.net
- UTF16がUCS2と違うというのなら、サロゲートペアの話でもしてるんだろうが
サロゲートペアが登場してるなら16bitでは収まらないと諦めた後であるということ
だからUCS4がすでに登場している
そしてUCS4があるからこそ、UTF-8からUCS4に変換するロジックを作ることができる
つまりUTF-8があるなら、UCS4がありUTF-16もあったことになる
- 146 ：デフォルトの名無しさん：2020/09/24(木) 01:48:26.24 ID:2TpuCg1t.net
- >>145
何？ その超理論、詳しく教えて？
どうやったらサロゲートペアより前に UTF16が存在できるの？
どの規格書に書いてある用語使ってるの？
- 147 ：デフォルトの名無しさん：2020/09/24(木) 08:50:32.68 ID:hsn7nUMR.net
- >>112 のツッコミ方が完全に間違ってるんだよな。
Unicodeには16bitエンコーディングしかなかったところに
後から8bitエンコーディングが追加されたって話なんだから
そこでツッコむべきはUTF-16という用語を使うのが間違っているという点。
それなのにあさっての方向にツッコむもんだから話がこじれる。
- 148 ：デフォルトの名無しさん：2020/09/24(木) 09:22:54.19 ID:2TpuCg1t.net
- >>147
だから、それも違うんだ。
Unicode に固定長エンコーディングしか無かったのは正しい。
一方で UTF-8 は Unicode のために作られらのでは無くて国際規格の UCS-4 のために作られた。
その後に Unicode と国際規格が事実上統合された。
- 149 ：デフォルトの名無しさん：2020/09/24(木) 10:38:14.21 ID:27/WCIy4.net
- UTFがUCSにTransformするフォーマットの略って知らないのかな？
- 150 ：デフォルトの名無しさん：2020/09/24(木) 11:57:01.94 ID:2TpuCg1t.net
- >>149
細かいこ指摘だけど UCS に Tranmsform するのではなくて、UCS から Transform がより正確だよ。
- 151 ：デフォルトの名無しさん：2020/09/24(木) 12:55:17.64 ID:2TpuCg1t.net
- 簡単な用語定義 (※元々は ISO における用語、後に Unicode にも取り入れられた)
ユニコード・コンソーシアムが定めている文字コードを「Unicode」という
国際規格委員会が ISO-10646 で定めている文字コードを「UCS」という
国際規格 UCS を 32 bit 固定長で符号化したものを「UCS-4」と呼ぶ
国際規格 UCS の BMP だけを 16 bit 固定長で符号化した簡易実装を「UCS-2」と呼ぶ(後に廃止)
第一次国際規格(1993年)の付録に定められた UCS の 8-bit 可変長符号化を「UTF」(UCS 変形フォーマットの意味)と呼ぶ(後に廃止)
国際規格の追補(1996年)で追加された UCS の 8-bit 可変長符号化を「UTF-8」と呼ぶ
国際規格の追補(1996年)で追加された UCS のサロゲートペアを用いた 16-bit 可変長フォーマットを「UTF-16」と呼ぶ
備考
UCS-2 は Unicode 1.1 とほぼ互換になるように定められた
UTF-16 は Unicode 2.0 (サロゲートペア有)と互換になるように定められた
後に定められた「UTF-32 」と UCS-4 は実質的に同じもの
UTF は UTF-8 と区別するために UTF-1 と呼ばれるようになった
UTF-8 は規格化される前は FSS-UTF とか UTF-2 などと呼ばれていた
- 152 ：デフォルトの名無しさん：2020/09/24(木) 13:18:02.55 ID:2TpuCg1t.net
- 以上の用語定義で UTF-8 導入の経緯は
Unicode はもともと内部 16 bit、外部 16 bit の使用法を前提にしていたが、国際規格では内部 32 bit、外部 8 bit可変長で実装することも想定していた。
このための外部用 8 bit 可変長文字コードとして最初に提案されたのが、UTF (UTF-1) 方式。
だだこの UTF-1 方式は Unix のファイル名等に使えないという欠点があっったので、すぐに改良版の FSS-UTF (UTF-8) 方式が提案され、そっちで実装が進んだ。
第一次規格(1993年)では時間的に変更が間に合わなくて UTF-1 方式の方が規格書の付録に記載されたが、後から追補(1996年)によって UTF-1 方式と UTF-8 方式を入れ換えた。
- 153 ：デフォルトの名無しさん：2020/09/24(木) 20:34:57.66 ID:anZxJGRt.net
- UTF-8の祖先にUTF-1があるから歴史が古いんだと言えるなら、同じ論理で
UTF-16の祖先にUCS-2を直接使用する原ユニコードがあるとも言えるんじゃね？
- 154 ：デフォルトの名無しさん：2020/09/24(木) 23:00:01.78 ID:2TpuCg1t.net
- UTF-1 があるから歴史が古いなんて言ってる人いないけど、どこ見てるの。
UTF-1 のすぐ後に UTF-8 が提案されてて間は1年もないよ。寝惚けてるの？
- 155 ：デフォルトの名無しさん：2020/09/24(木) 23:04:21.45 ID:4CFVaDi9.net
- 論点はそこじゃなくてUTF-8はUnix系でUTF-16に対応できなかったから
しかたなく作ったものだって話だろ
外部が作って後からUnicodeに追加された仕様
- 156 ：デフォルトの名無しさん：2020/09/24(木) 23:19:57.03 ID:KWqR4FD9.net
- あきらめろ。
UTF-8 は Unicode ではなく UCS 用に作られた。
UTF-8 は欠陥のある UTF−1 の代わりにするために作られた。
UTF-8 が考案された時には UTF-16 は影も形も無かった。
- 157 ：デフォルトの名無しさん：2020/09/24(木) 23:22:52.82 ID:2TpuCg1t.net
- >>155
だから、それが間違いって指摘してるんだが
- 158 ：デフォルトの名無しさん：2020/09/24(木) 23:31:22.25 ID:tp/LFCei.net
- >>157
UTF-8が開発された経緯
https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt
> UTF-8 was designed, in front of my eyes, on a
> placemat in a New Jersey diner one night in September or so 1992.
UTF-8は1992年9月に私の目の前で設計された
> We had used the original UTF from ISO 10646
> to make Plan 9 support 16-bit characters, but we hated it.
Plan 9で16ビット文字をサポートするためにISO 10646の
オリジナルのUTFを使用していた が私たちはそれを嫌っていました。
> However, UCS and its UTF variant do not protect
> null bytes and/or the ASCII slash ("/") making these character encodings
> incompatible with existing Unix implementations.
しかしUCSとその亜種であるUTFはヌル文字とスラッシュを保護せず
存在するUnixの実装と互換性がありません。
- 159 ：デフォルトの名無しさん：2020/09/25(金) 01:42:25.42 ID:gzmvGmy3.net
- >>158
そこに書かれている original UTF というのは UTF-1 のことで UTF-16 のことじゃないぞ。
ちゃんと理解できてるか？
- 160 ：デフォルトの名無しさん：2020/09/25(金) 02:18:28.45 ID:N+dUj7Ty.net
- だからUnicodeに対応するためにUCS-2ではなくてUTF-1を使ってたんだろ
UnixがUCS-2に対応するのは現実的に不可能だったから
- 161 ：デフォルトの名無しさん：2020/09/25(金) 02:46:48.42 ID:4J6tgyym.net
- >>156
> UTF-8 が考案された時には UTF-16 は影も形も無かった。
UTF16の直接の先祖のUnicode1.0の符号化方式が厳然と存在してるのに影も形もないはないな
- 162 ：デフォルトの名無しさん：2020/09/25(金) 02:48:35.22 ID:gzmvGmy3.net
- >>160
だから、それ、お前の妄想だろ。不可能とかどこにも書かれてない。
実際やろうと思えばできる。素人じゃあるまいし。Ken って誰だか知ってるか？
ただ、互換性がないから嫌っていたという話。
Windows とかはしょちゅう非互換な変更を加えるけど、Unix とかは文化として相互の協調動作を重視するんだ。
それで、可能な限り非互換な変更を避けようとする、仕方がない場合にはやるけど。
実際問題 Plan-9 には UCS-2 と UTF-1 の両方が既に開発済みで、リリース間近だった。
ちょうど、その時に X/Open comitee の人から電話がかかって来て、UTF の改良について相談されたので、速攻でより互換性の高い新しい符号((UTF-8)を設計して提案したという話。
- 163 ：デフォルトの名無しさん：2020/09/25(金) 02:51:32.21 ID:gzmvGmy3.net
- >>161
そんな見苦しい言い分けしても、お前の間違いはごまかせないんだぜ。
- 164 ：デフォルトの名無しさん：2020/09/25(金) 03:18:37.40 ID:4J6tgyym.net
- お前の間違いってどれよ、挙げてみｗｗｗお前が思ってるお前の発言は多分俺の発言じゃないから
一人を相手にしてると思ってるなら大間違い
- 165 ：デフォルトの名無しさん：2020/09/25(金) 03:20:48.06 ID:N+dUj7Ty.net
- >>162
書いてある
> However, UCS and its UTF variant do not protect
> null bytes and/or the ASCII slash ("/") making these character encodings
> incompatible with existing Unix implementations.
しかしUCSとその亜種であるUTFはヌル文字とスラッシュを保護せず
存在するUnixの実装と互換性がありません。
- 166 ：デフォルトの名無しさん：2020/09/25(金) 04:05:10.29 ID:gzmvGmy3.net
- >>165
互換性がないとしか書いてないようだが？
- 167 ：デフォルトの名無しさん：2020/09/25(金) 08:01:55.95 ID:N+dUj7Ty.net
- だからOSの方を書き換えるのが現実的に不可能だったんだろ
- 168 ：デフォルトの名無しさん：2020/09/25(金) 08:06:49.98 ID:Joe/ViIu.net
- >>162
＞ Windows とかはしょちゅう非互換な変更を加える
これって何のギャグよ
- 169 ：デフォルトの名無しさん：2020/09/25(金) 08:14:51.08 ID:ElnYG5aU.net
- 互換性がないから嫌いとしか読めん
現実に各社 Unix でも Linux でも UTF-16 実装してるんだよなあ。
不可能とは？
- 170 ：デフォルトの名無しさん：2020/09/25(金) 08:19:51.13 ID:N+dUj7Ty.net
- 不可能なのは各コマンドをUTF-16対応にすること
- 171 ：デフォルトの名無しさん：2020/09/25(金) 09:16:58.00 ID:gzmvGmy3.net
- なんで？
プログラムと API を書き換えれば、普通にできるよ。
実際 Windows はそれをやったわけだし。
- 172 ：デフォルトの名無しさん：2020/09/25(金) 09:28:26.81 ID:ElnYG5aU.net
- >>171
Mivrosoft は愚直に全てのプログラムを書き換えた。
UNIX陣営は UTF-8 を発明して、その手間を大幅に省いた、天才。って話だわな。
- 173 ：デフォルトの名無しさん：2020/09/25(金) 09:31:02.93 ID:N+dUj7Ty.net
- >>171
永遠の時間があればできるだろうなって話
Windows NTは最初のバージョンからUnicode対応だった
- 174 ：デフォルトの名無しさん：2020/09/25(金) 09:36:14.75 ID:gzmvGmy3.net
- 逆だろ、Unicode 対応のために DOS-FAT から NTFS に非互換な変更したってだけだろ。
DOS-FAT はあまりにもダメダメなので、他の理由でも置き換えるのが必須だったので決断は簡単だった。
一方 UNIX 系の FS は FAT に比べれば良くできてたので、置き換える意欲に乏しかった。
- 175 ：デフォルトの名無しさん：2020/09/25(金) 10:34:03.53 ID:N+dUj7Ty.net
- DOSは最初からSJISなんていう、これまたUnix系では（完全に）対応することができない
文字コードに対応してるわけでその理屈はおかしい
更に言うなら1995年に発売されたNT3.5（NT系としては2つ目のバージョン）に
搭載されているFATは長いファイル名をサポートし文字コードはUTF-16を使う
https://en.wikipedia.org/wiki/File_Allocation_Table#Long_file_names
> One of the user experience goals for the designers of Windows 95 was
> the ability to use long filenames (LFNs?up to 255 UTF-16 code units long)
- 176 ：デフォルトの名無しさん：2020/09/25(金) 11:53:51.78 ID:ET4Ww2dt.net
- DOS-FATなんて使われてない用語を使ってるのは、印象操作でも目論んでるようにしか見えないが
FATの正統後継であるexFATは今も使われてるしSDカードの標準のファイルシステムとして公式採用されてる
だめだめの部分がなにか知らんがとっくに改良されておりよくできたファイルの一つとなってる
- 177 ：デフォルトの名無しさん：2020/09/25(金) 11:57:18.65 ID:ElnYG5aU.net
- お前はネットで検索した情報を知ったかする前に、まずは時系列順に並べ替えてみろ。
- 178 ：デフォルトの名無しさん：2020/09/25(金) 12:43:52.40 ID:fcTjdC6n.net
- >>177
それはお前がやるべきことだ
なぜ俺が不利になる（？）ようなことを
俺がわざわざ調べないといけないんだｗ
反論があるならお前がしろ
自分が反論できないからって相手に反論の
材料を探させるという間抜けをするな
やるわけねーだろアホｗ
- 179 ：デフォルトの名無しさん：2020/09/25(金) 14:19:51.56 ID:ElnYG5aU.net
- ちゃんと調べれば自分が間違っていることに気づくぞ、というアドバイスなんだが。
不都合な真実は知りたくないというのなら、永遠に間違って理解してろ。
残念ながらお前は技術者には向いてないんだろうと思う。
- 180 ：デフォルトの名無しさん：2020/09/25(金) 14:27:52.78 ID:Aqlkxpe2.net
- ANSI文字列を扱うAPIをいまだに保守し続けているWindows
デフォルトエンコーディングをEUCから突然UTF-8に切り替えたunix
互換性を軽視しているのはどちらでしょう
- 181 ：デフォルトの名無しさん：2020/09/25(金) 14:29:21.59 ID:6tDTZ4vt.net
- >>179
調べてた結果正しかったです。調べたくない人が事実を知りたくないだと思います（笑）
- 182 ：デフォルトの名無しさん：2020/09/25(金) 16:02:35.34 ID:ElnYG5aU.net
- 調べなくても、その辺の時系列はよく知ってるんだよ。当時、リアルタイムでおっかけてたので。
時系列誤解して、知ってるやつなら絶対に間違えないレベルの主張してるのがいたので指摘しとこうかと思っただけ。
お前は知りたくなければ知らなくて良いよ。
十分に事実は書いたので、後から奇特にもこのスレ覗きに来て、お前の妄言に惑わされる奴もいないだろうし。
p.s. 上から目線なのはジジイなので許せ。
- 183 ：：2020/09/25(金) 21:10:47.40 ID:DCkHs+Bt.net
- >>180
その unix とやらの具体的で正式な OS の名称を教えてください…
- 184 ：デフォルトの名無しさん：2020/09/25(金) 21:18:32.55 ID:K0BToZeX.net
- しょっちゅう非互換な変更を加えるWindowsって具体的にはどれの事よ
- 185 ：デフォルトの名無しさん：2020/09/25(金) 21:22:39.15 ID:K0BToZeX.net
- https://docs.microsoft.com/ja-jp/archive/blogs/nakama/win10waas-part5a
カーネル依存性のないデスクトップアプリの場合、少なくとも「まったく動作しなくなる」といった致命的な問題はほとんど出ないと思います。
Windows 7 で動作していた .NET 3.5 のアプリのほとんどは、Windows 10 上の .NET 3.5 でもまず十中八九動作するはずで、
先行検証しているあるお客様からは、「まるで非互換問題が出てこないんだけれども、名前だけ変えてお金稼ごうとしてない？」とか言われたことがあるぐらいです；。
- 186 ：デフォルトの名無しさん：2020/09/25(金) 21:53:11.91 ID:jsxvfqFg.net
- >>185
マイクロソフトは互換性が高いと主張しています。それは事実だと思いますが
それでも断定はできないし保証はできないので検証は必要です。
ただしお客様の方で検証していただければお金は不要です。
問題があった場合は有償でサポートしますが対応に時間がかかることがあるので
余裕を持ったスケジュールで行ってください。
って言えば良いんかな？
- 187 ：デフォルトの名無しさん：2020/09/26(土) 04:29:55.57 ID:V6Zu3iZf.net
- >>183
そんなUNIXは存在しない。
Unix系の OS は Unicode よりずっと前に複数文字コード対応終わってるので。
MacOS を Unix だと主張するなら、違うかもしれない。解釈次第。
- 188 ：デフォルトの名無しさん：2020/09/26(土) 05:50:51.04 ID:dJRFq1YT.net
- > Unix系の OS は Unicode よりずっと前に複数文字コード対応終わってるので。
それはASCIIと互換性がある文字コードだけ
LinuxはSJISに対応しようと頑張ったやつがあるが
ASCIIと互換性がないので不完全なまま終了した
http://ossforum.jp/jossfiles/Linux_SJIS_Support.pdf
> なぜ Linux で Shift JIS ロケールがサポートされない
> 現在、日本で利用されている多くの Linux ディストリビューションでも、Unicode 系の UTF-8 がデ
> フォルトとされ、Shift JIS ロケールが用意されているケースでも、利用は推奨されていない。
> 1. Ｌｉｎｕｘの文字処理ライブラリ関数は、Unicode を扱うことを基本としているため、本ライブラリ
> 関数を使ってインプリメントされた Linux システムコマンドでは、ファイルデータの中の文字
> 処理や、ファイル名の処理で、Unicode は正しく扱えても、Shift JIS は扱えないことがある。
> 2. Shift JIS データの処理は、「特別」な扱いとなり、メールクライアント Thunderbird など、個々
> のミドルウェアに多大な開発負担を負わせている。
> 3. 特に、正統 Shift JIS ロケール sjis では、 0x5C=U+00A5 というマッピングのために、オープ
> ン系プログラム（Ｃ言語、Java など）の動作が保証されない。cp932 などでは問題ない。
- 189 ：デフォルトの名無しさん：2020/09/26(土) 05:52:24.09 ID:dJRFq1YT.net
- ちなみにWindows NTは最初のバージョンから複数文字コード対応が終わっている
UTF-16（初期はUCS-2）がOSの標準文字コードだからね
- 190 ：デフォルトの名無しさん：2020/09/26(土) 08:35:16.23 ID:4p5kvQE6.net
- その定義だと WindowsNT は ShiftJIS に対応してないんだなこれが。
あくまで対応しているのは CP932 なんだ。
Linux は正しく ShiftJIS を規格書どおりに実装している。
問題は CP932 と ShiftJIS を後出しで別物にしちゃったマイクロソフトにある。
だから Linux でMS互換の文字コードを使いたい場合、ShiftJIS ではなく CP932 と設定する必要がある。
- 191 ：デフォルトの名無しさん：2020/09/26(土) 09:57:54.54 ID:dJRFq1YT.net
- >>190
だからLinuxはCP932に完全対応できずに終わったって言ってるじゃん
話すり替えるなよ
- 192 ：デフォルトの名無しさん：2020/09/26(土) 10:55:23.76 ID:HIxn44p8.net
- そういえば CP932 は ASCII 互換だったな。
（互換だったということにマイクロソフトがした）
- 193 ：デフォルトの名無しさん：2020/09/26(土) 11:00:49.52 ID:ToQOodFb.net
- https://shellscript.sunone.me/character_code.html
＞古くから UNIX の日本語環境では EUC-JP が標準の文字コードとして使用されてきた
https://gihyo.jp/lifestyle/serial/01/ganshiki-soushi/0069
＞EUC-JPはUNIX系OSに採用されてワークステーションに，ISO-2022-JP(の前身であるJUNETコード)は電子メールやネットニュースなどインターネットを中心に広まっていきました。
https://codeaid.jp/blog/exchange-utf8/
＞UnixはEUC、WindowsはShift_JIS、MacはMacJapaneseやUTF-8など異なったエンコードタイプでテキストを扱います。
http://www.monyo.com/technical/samba/docs/Japanese-HOWTO-3.0.ja.txt
＞オープンソースの Linux、FreeBSD や、Solaris、IRIX、Tru64 UNIX といった商用 UNIX では、日本語のロケールとして通常 EUC-JP を利用しています
あとどれだけの情報を出せば納得するのかな？ww
- 194 ：デフォルトの名無しさん：2020/09/26(土) 11:16:52.56 ID:lj7tia+j.net
- >>191
話そらしてるようにしか読めないのなら、それがお前の知識の限界ってやつだ。
- 195 ：デフォルトの名無しさん：2020/09/26(土) 11:18:06.83 ID:lj7tia+j.net
- >>193
ちなみに Sony の NEWS とか知ってる？
- 196 ：デフォルトの名無しさん：2020/09/26(土) 14:37:10.24 ID:ER2LZL5Z.net
- plamoっって久々に観たわ
- 197 ：デフォルトの名無しさん：2020/09/26(土) 15:20:39.47 ID:dJRFq1YT.net
- >>192
マイクロソフトはCP932がASCII互換なんて言ってないよ
それもあってかWindowsではANSIという呼び方をしている
- 198 ：デフォルトの名無しさん：2020/09/26(土) 15:23:26.93 ID:dJRFq1YT.net
- >>194
話をそらしてるのはお前でしょ。Linux および Unix が CP932 または ShiftJIS に対応してないって話なのに
Windowsがー、ShiftJISじゃなくてー、CP932なんだーってWindowsの話にすり替えてる
Linux および Unix の話に戻しましょう。
Linux および Unix が CP932 または ShiftJIS に完全対応してない
>>193にも書いてあるように日本語はASCII互換のEUC-JPを使っていた
- 199 ：デフォルトの名無しさん：2020/09/26(土) 15:35:39.57 ID:nz56jET8.net
- AIXはCP932系のCP943がデフォルトだったしSolarisも一応PCKというのを提供していた。
使うコマンド全てちゃんとlocaleに従う国際化していればできる話。
- 200 ：デフォルトの名無しさん：2020/09/26(土) 15:56:41.68 ID:HIxn44p8.net
- どんどんボロが出るな。
お前のういう ANSI と ASCII の違いって何。
Linux において Shift_JIS と CP932 の違いはわかる？
Sony の NEWS って知ってる？
- 201 ：デフォルトの名無しさん：2020/09/26(土) 15:59:25.33 ID:HIxn44p8.net
- >>199
IBM の Shift JIS とか教えてやんなよw
にわか君の脳がバグってこれまで以上に面白いことになりそう。
- 202 ：デフォルトの名無しさん：2020/09/26(土) 16:25:27.51 ID:Xs9MiFl7.net
- NEWSとX68kは欲しかったな
- 203 ：デフォルトの名無しさん：2020/09/26(土) 16:26:57.63 ID:QQeUS8EE.net
- かつて、シフトJISは皆同じものであった。
その名は様々であったが、人々はシフトJISを使って互いに話し合うことができた。
ほんとは空き領域にメーカー独自に文字を追加してたり、外字領域として使っていたりしたが、同じものと主張していた。
傲慢になった人々はさらに多くの文字を要求した。
お怒りになられた神は Unicode をもたらされた。
各社が勝手気儘に Unicode とシフトJISの変換表を定義したので、ひとつのシフトJISは沢山のシフトJISに分割された。
人々は互いに言葉が通じなくなった。
- 204 ：デフォルトの名無しさん：2020/09/26(土) 16:47:43.71 ID:htO/NqgS.net
- 故・永井一郎氏でナレーションをつけたらガンダムみあってよいね。
- 205 ：デフォルトの名無しさん：2020/09/26(土) 17:05:55.71 ID:iJutkljl.net
- >>203
パソコン通信の時代
「文字化け」はノイズでテキストデータが一部壊れることを意味していた
文字化けをなくすしくみとして「MNP」があったけどそれも今では違う意味で使われている
- 206 ：デフォルトの名無しさん：2020/09/26(土) 17:45:01.52 ID:P5ZUvIL5.net
- 以前、GB18030の話したときの感じだと、素人集団だし、あまり他人のことをとやかく言っても仕方ないのでは。
- 207 ：デフォルトの名無しさん：2020/09/26(土) 21:16:56.96 ID:v2ZzDIc8.net
- Why is the default 8-bit codepage called "ANSI"?
https://devblogs.microsoft.com/oldnewthing/20040531-00/?p=39103
Why is the OEM code page often called ANSI?
https://devblogs.microsoft.com/oldnewthing/20051027-37/?p=33593
- 208 ：デフォルトの名無しさん：2020/09/26(土) 21:54:59.76 ID:BUinzsCm.net
- ｲｲﾈ
- 209 ：デフォルトの名無しさん：2020/09/27(日) 00:06:12.54 ID:YQFWAWcL.net
- あんざいでいいのかな
- 210 ：デフォルトの名無しさん：2020/09/27(日) 01:32:39.82 ID:m5Rqyw0A.net
- あきらめたんじゃなかったのかオヤジ…
- 211 ：デフォルトの名無しさん：2020/09/27(日) 01:58:25.37 ID:UrweFCig.net
- ANSI の本来の意味は「アメリカ国会標準協会」、日本の JIS にあたる。
一般的な読みは「アンシー」。
もちろん文字コードだけを規定しているのでなくて、色々な規格を決めてる。
でも日本で俗に文字コードのことを JIS って呼ぶ感じで、ANSI って呼んじゃう。
ちなみに ASCII のアメリカ規格での正式な名称は ANSI X3.4 だった。(国際規格だとISO 646 IRV)
Windows の人たちは ASCII だけでなくて ASCII 系の拡張コードを全て ANSI って呼ぶ(ことが多い)。
(もちろん正式名称ではないので、正式なドキュメントでは使用しない)。
- 212 ：デフォルトの名無しさん：2020/09/27(日) 02:03:10.77 ID:UrweFCig.net
- 国会じゃねえ、国家だ、「アメリカ国家標準協会」
- 213 ：デフォルトの名無しさん：2020/09/27(日) 14:48:04.56 ID:UbuOwcm8.net
- あまり詳しくないけどShiftJISの規格書とかあるんだな
- 214 ：デフォルトの名無しさん：2020/09/27(日) 17:40:16.09 ID:UrweFCig.net
- JIS X 0208 に「シフト符号化」として規格がある。Linux の SHIFT-JIS は基本これに従っている。
でも各社が空領域に勝手に追加した文字は、使ってはいけないことになってるのでマイクロソフトの CP932 とかとは完全な互換ではない。
- 215 ：デフォルトの名無しさん：2020/09/27(日) 18:22:15.82 ID:I+ot45zN.net
- もともとShiftJISはマイクロソフトといくつかの会社で共同開発したものだよ
だからマイクロソフトがオリジナルと言っていい。
そこにNECやIBMなどが空き領域に勝手に文字を追加した。
CP932はマイクロソフトが作った文字コード（文字集合）であるが
マイクロソフトが勝手に文字を追加したのではなく、
NECやIBMの独自拡張を互換性を維持するように統合したもの
ShiftJISの亜種で困るのは、MacJapanese
アップルも同じく勝手に空き領域の文字を追加した上に同じ文字コードに
違う文字を割り当ててる。そのせいでMacとのデータのやり取りで
丸囲み数字とかで文字化けが発生する原因となった。少しは互換性を考えろって
ここに詳しく書いてあるよ
https://wiki.suikawiki.org/n/%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%BD%E3%83%95%E3%83%88%E6%A8%99%E6%BA%96%E3%82%AD%E3%83%A3%E3%83%A9%E3%82%AF%E3%82%BF%E3%82%BB%E3%83%83%E3%83%88
- 216 ：デフォルトの名無しさん：2020/09/27(日) 19:50:11.19 ID:UrweFCig.net
- そこにも書いてあるけど、最初に作られたシフトJIS には追加文字は無かった。
その後に各社が勝手に文字を追加していった。マイクロソフトもその後から互換性を無視した追加した一社。
JIS がシフト符号化方式を規格化する時の特定の会社に肩入れするわけにはいかないので、本来の空領域は使用禁止という方針を維持した。
Linux も OSS で多くの会社が開発に参加しているので、特定の会社には肩入れできないので、中立な JIS 規格のものを選ばざえる得なかった。
- 217 ：デフォルトの名無しさん：2020/09/27(日) 20:01:06.53 ID:duNnLcqR.net
- > マイクロソフトもその後から互換性を無視した追加した一社。
何を追加したというの？
- 218 ：デフォルトの名無しさん：2020/09/27(日) 20:02:45.37 ID:duNnLcqR.net
- > Linux も OSS で多くの会社が開発に参加しているので、特定の会社には肩入れできないので、中立な JIS 規格のものを選ばざえる得なかった。
多くのソフトはCP932とかいう名前で対応してるけど？
- 219 ：デフォルトの名無しさん：2020/09/27(日) 20:16:06.46 ID:PpIfQt3T.net
- 何この馬鹿
- 220 ：デフォルトの名無しさん：2020/09/27(日) 20:42:09.15 ID:UrweFCig.net
- >> 217
もともとマイクロソフトの CP932 には追加文字は無かったんだけベンダー各社が勝手に文字を追加することを許していた。
Microsoft は Windows 3.1 を出す時に NEC と IMB が拡張した文字を参考に独自に CP932 に文字を追加し、さらに各社が勝手に Windows に文字を追加することを禁止した。
つまりマイクロソフト CP932 には昔ながらのものと、拡張されたものと2種類がある。
インターネットの正式規格(IANA)には後者に Windows-3.1J として登録されている。
両者を区別した場合に俗に後者を MS932 と呼ぶ人たちもいる。
- 221 ：デフォルトの名無しさん：2020/09/27(日) 20:55:03.90 ID:UrweFCig.net
- >>218
そう。Linux では Shift_JIS と CP932 は別の文字コードという扱いになってる。
- 222 ：デフォルトの名無しさん：2020/09/27(日) 21:07:18.47 ID:xq8pY9v9.net
- なんか主張がブレまくってる気がするけど、結局どういうことを主張したいの？
- 223 ：デフォルトの名無しさん：2020/09/27(日) 21:09:23.04 ID:UrweFCig.net
- SHIFT JIS には種類がいっぱいある。同じ名前でも同じものだとは思うな。互換性はない。
- 224 ：デフォルトの名無しさん：2020/09/27(日) 22:15:06.93 ID:duNnLcqR.net
- >>220
> Microsoft は Windows 3.1 を出す時に NEC と IMB が拡張した文字を参考に独自に CP932 に文字を追加し、さらに各社が勝手に Windows に文字を追加することを禁止した。
だから、NECとIBMとの互換性を保つように、それら両方の文字集合を含んだCP932を作ったことでしょう？
そう言ってるじゃん
そしてさらにそこから拡張して混乱を招かないように禁止したんだね
それは当然の行為だね
> つまりマイクロソフト CP932 には昔ながらのものと、拡張されたものと2種類がある。
昔ながらのもの？なにそれ。Windows-3.1J ？MS932？同じものだけど
いちいち書いてる所探してやるの面倒くさいなと思ったけどすぐ見つかったｗ
最初にこっちを見つけてくればよかったね
Shift_JIS、CP932、MS932、Windows-31J
http://una.soragoto.net/topics/13.html
- 225 ：デフォルトの名無しさん：2020/09/27(日) 23:12:33.54 ID:G6Rp/5vA.net
- nkfだと、sjisとcp932で扱いが異なる。
最初sjisでうまくいかないで、cp932だとうまくいった。
俺にとってのcp932事始め。
- 226 ：デフォルトの名無しさん：2020/09/27(日) 23:17:27.83 ID:xq8pY9v9.net
- 結局、Linuxがどうたら言っていた話はなんの関係があったんだろうか
- 227 ：デフォルトの名無しさん：2020/09/27(日) 23:21:06.50 ID:duNnLcqR.net
- https://weblabo.oscasierra.net/shift_jis-windows31j/
ここにはちゃんと最初の時点ではShiftJISとCP932は同じものって書いてあるな
CP932はもともとMS内部での呼び名だしな
そしてあとからNECとIBMが独自に拡張した
それじゃいろいろと困るから、あらためてMSがそれらを取り込んでCP932として再定義した。
IANAではWindows-31JでありJavaではMS932という名前になった。
MacJapaneseはどういう経緯で作ったんだろうな
NECやIBMのことなんかも考えず、アップルがShiftJISを勝手に拡張したのか？
- 228 ：デフォルトの名無しさん：2020/09/28(月) 00:29:11.65 ID:yUM2IYPL.net
- 2022も一枚岩じゃねーのにMSシフトだけ悪者かよw
- 229 ：デフォルトの名無しさん：2020/09/28(月) 00:45:44.06 ID:IvlPnhNT.net
- そういやEUC-JPも亜種が多かったね
- 230 ：デフォルトの名無しさん：2020/09/28(月) 02:22:56.82 ID:LFNRA5Wr.net
- 技術の話だからな、誰が邪悪で誰が正義とかはないぞ。
種類が多数あるから気をつけろ。あえて言えば非互換な変更は可能な限り避けろ。
あと別に NEC と IBM だけが独自拡張してたわではないぞ。
Apple や Fujitsu を始めとして他も各社独自拡張してた。
マイクロソフトはビジネス上の都合で普及してた NEC と IBM のもののみから取捨選択した。
そこそこ普及してたけどライバルだった Apple のもは無視した(互換にする理由が無かった)。
- 231 ：デフォルトの名無しさん：2020/09/28(月) 03:00:06.80 ID:aMwTz6q2.net
- code page 932 って元々MSじゃなくて IBM の規格だけどな。
IBM が作った OS/2 とうのがあってな。それ用の文字コード名だった。
MS は IBM が OS/2 を作るのに技術協力しててな、その後に Windows 作る時にその用語をそのまま使った。
MS が拡張する前の CP932 を IBM 932 と呼ぶ人がいるのはこれが理由。
- 232 ：デフォルトの名無しさん：2020/09/28(月) 03:09:14.91 ID:Btw2QdlH.net
- うちがIBM社から依頼されて制作したのが始まり。
当時は広く調査する手段が無く、偏りがある事は認める。
- 233 ：デフォルトの名無しさん：2020/09/28(月) 03:09:23.25 ID:LFNRA5Wr.net
- >>231
そういえば IBM は律義なので、文字を追加して互換性のないやつは CP943 とか別の番号を割当てて名前を変えてたんだよな。
MS はその辺を参考に文字を追加したやつも CP932 と呼び続けたのは何でだろう。
- 234 ：デフォルトの名無しさん：2020/09/28(月) 03:39:47.21 ID:IvlPnhNT.net
- >>233
CP932はどちらもMSが作ったコードページでMSとしては互換性があるからじゃないの？
Unicodeにバージョンがあっても文字集合が違うように
オリジナルの CP932（=ShiftJIS ）があって、そこに文字集合を
拡張したいわば CP932 2.0 という扱いだから名前を変える必要がない
IBMのは別会社だから、別の名前にするのはそこまで不思議じゃないかな
むしろNECがなんでCP932を使ってるかのほうが気になるけど
NECもMS-DOSを使っていたからかな
最初のMS製のCP932は1982年に作られて、NECとIBMが独自拡張したのは1983年なんだね
アップルは1991年にそれまた独自で拡張してる
そして再構成されたCP932ができたのは1993年のようだ
- 235 ：デフォルトの名無しさん：2020/09/28(月) 04:20:00.06 ID:LFNRA5Wr.net
- code page 番号での管理は IBM が汎用機時代からずっとやってきた名前で、
マイクロソフトは後から、その番号をそのまま採用したって聞いたけど、違うの？
- 236 ：デフォルトの名無しさん：2020/09/28(月) 05:06:08.90 ID:IvlPnhNT.net
- >>235
もともとMSとIBMは1990年代まで協力してOS開発をしてた
例えばIBM PC用のPC-DOSはMS-DOSをリネームしたもの
だから共通のコードページを使用するのは当たり前
1990年代以降にOS開発の協力をやめてからはそれぞれ独立して
コードページを管理してる
古くはIBMが使っていた用語のようだがCP932がなんかができた時期は共同開発なんだろう
MS等数社でShiftJISの仕様を作ってそれをOSに実装するときにCP932という管理番号が与えられた
https://en.wikipedia.org/wiki/Code_page
- 237 ：デフォルトの名無しさん：2020/09/28(月) 09:14:02.90 ID:8EXAUbY4.net
- 共通のコードページを使うようになったのはいつから？
そこが曖昧なんだよな。
マイクロソフトは元々 CP932 とは呼んでなかったという意見があるみたいなんだが。
- 238 ：デフォルトの名無しさん：2020/09/28(月) 09:33:14.92 ID:UEVgwzRH.net
- >>234
NEC は厳密に言えば CP932 に文字を追加したわけではないからなあ。
NEC や Fujitsu がやったのは漢字ROMの空き領域に字形を追加した。
これをやると OS とか文字コードに関係無く使える漢字が増える。CP/M でも BASIC でも。
- 239 ：デフォルトの名無しさん：2020/09/28(月) 09:42:09.44 ID:ZQPU+aZv.net
- ANSI先生、シフトジスがめんどくさいです...
>>227
HTMLでcharset=Shift_JISであっても実際はWindows-31Jだったりする。
巷の大概のブラウザはWindows-31Jにしかない文字があっても開ける。はしご高とか。
そうやってある意味グダグダになっていく（った）わけやね。でもしょうがないのかな。
厳密な挙動をしても「えーこのブラウザ文字化けするー」とか言われちゃうのがオチだし。
ま、HTMLはもうだいぶUTF-8になってきてるし、いっかw
- 240 ：デフォルトの名無しさん：2020/09/28(月) 10:30:21.69 ID:IvlPnhNT.net
- >>237
元々というのがいつの話か知らんが、chcp "MS-DOS 3.3" で検索したら
海外のMS-DOS3.3（1987年）にはCHCPコマンドがあったようだね
http://radioc.web.fc2.com/column/pc98bas/internal-version-of-msdos-33.html
https://www.pcjs.org/documents/books/mspl13/msdos/encyclopedia/appendix-a/
ここからCP932が存在したということにはならないけど
今と同じコードページはMS-DOS当時使われていた
そこに別のものを使うとは思えないな
当時は日本ではほぼNECの独占状態で、日本専用なわけだから
コードページの切り替えはないしCHCPは存在しないから
日本では知られてなかっただけじゃないの？
- 241 ：デフォルトの名無しさん：2020/09/28(月) 10:39:54.81 ID:Uhat3CEo.net
- >>238
NEC の汎用機に文字が追加された。もちろんSJIS関係ない。
NEC の汎用機の端末として使えるようにするために PC9801 の漢字ROM は NEC追加文字が含まれて状態で発売された。
ちばみに IBM拡張漢字ROMは別売オプション。
PC9801 に MS-DOS を移植したら、あーら不思議、最初から使える文字が増えてた。
という順序だな。
- 242 ：デフォルトの名無しさん：2020/09/28(月) 10:41:07.34 ID:IvlPnhNT.net
- >>238
MS-DOS、漢字ROMの時代はOSが知っているのは文字コードだけで
そこで表示されるフォントはハードウェア搭載されてるものだったからね
ShiftJIS系は全て同じものとして扱うことしかできなかった
勝手に違う文字コードに化けさせるわけには行かないし
細かい文字コードを区別できるようになったのはフォントをOSで
処理するようになったWindowsから
だからそのときに改めて統一する必要がでてきた
- 243 ：デフォルトの名無しさん：2020/09/28(月) 10:45:58.86 ID:Uhat3CEo.net
- >>240
最初(1982年)からCP932だったという主張は撤回するのん？
- 244 ：デフォルトの名無しさん：2020/09/28(月) 10:46:31.48 ID:IvlPnhNT.net
- NEC独自の文字としては2バイト系半角文字がお気に入りだったな
数字やアルファベットが縦長で、全角半角混ぜても違和感ないんだよ
2バイトだけど文字幅は1バイトと同じでな
表示位置の調整の計算は、2バイトは1バイトの倍として
計算するだけでは駄目だったんだよ
1文字ずつ見ていって文字コードの範囲をみて計算する必要がある
ライブラリもなかったしC言語で実装するのはすっげーめんどくさかったクソ仕様
- 245 ：デフォルトの名無しさん：2020/09/28(月) 10:47:44.81 ID:IvlPnhNT.net
- >>243
してないよ。MS-DOSでは最初からCPxxxというコード体系が使われていたと言ってる
当時は日本で広まっていないだけ
- 246 ：デフォルトの名無しさん：2020/09/28(月) 11:04:04.80 ID:PU8P18gE.net
- >>245
推測とかじゃなくて、その根拠が知りたいんだが。どこ情報？
- 247 ：デフォルトの名無しさん：2020/09/28(月) 11:07:15.33 ID:cf3OGOhX.net
- あ、別に否定してるわけじゃないよ。
世間一般に曖昧なんでちゃんとした根拠があるなら知りたい。
- 248 ：デフォルトの名無しさん：2020/09/28(月) 11:21:20.86 ID:IvlPnhNT.net
- >>246
そんなに答えを求めてるなら「今となってはわからない」が正解じゃねｗ
少なくともCP932が使われていなかったという根拠はないからね
- 249 ：：2020/09/28(月) 19:55:51.42 ID:iFBbxDDj.net
- もう、PC98 に搭載されている漢字 ROM が正義、とするのがいいかと
で、PC9801 各シリーズおよび PC9821 各シリーズで差異があるかどうかが問題
私の一番すきな 98 は 98FA なので、98FA が正義でありたい
- 250 ：デフォルトの名無しさん：2020/09/28(月) 20:15:42.82 ID:LpDzonCU.net
- □□□□□□□□□□□□□□□□□□□□□□□□□
□□■□■■□□□□■■□□■■■□□□■■■□□
□■■□□□□■□■□□□□□□□■□□□□□■□
□□■□■□□■□□□□□□□□□□□□□□□□□
□■□□■□□■□□□□□□□□□□□□□□□□□
□□□■■■□■□□■■□■□□□□□■□□□□□
□□□■■□□□■□□□□□■■■■□□■■■■□
□□□□□□□□□□□□□□□□□□□□□□□□□
- 251 ：デフォルトの名無しさん：2020/09/28(月) 21:40:36.46 ID:o1iMmVBZ.net
- https://ja.wikipedia.org/wiki/Microsoftコードページ932
1982年(JIS X 0208-1983策定の前年)、JIS C 6226(JIS X 0208)を複雑にシフトさせた文字符号化方式としてShift_JISが誕生した。
この符号化方式(を利用した拡張符号化文字集合)は、マイクロソフトによりMS-DOSにおける標準日本語コードとして採用され、
「コードページ 932 (CP932)」という管理番号を与えられた。
しかし、マイクロソフトは、MS-DOSにおける唯一の日本語用コードページである「CP932」を、OEMメーカーの自由に任せていた。
そのため、NECのPC-9800シリーズ、IBMのPS/55 シリーズ、富士通のFMRシリーズなどは全て、MS-DOSを搭載し
文字符号化方式もShift_JISを採用しているコンピュータであるにもかかわらず、登録されている文字集合がバラバラだった。
- 252 ：デフォルトの名無しさん：2020/09/28(月) 21:49:17.49 ID:TR69hVPT.net
- jawpをソースにするなよ
- 253 ：デフォルトの名無しさん：2020/09/28(月) 22:15:52.03 ID:F7s1Ev+m.net
- 当時としてはMS-DOSはコンピュータで動くOSの１つでしかないのに
マイクロソフトがコンピュータに搭載する文字集合を決めるなって話だろ
- 254 ：：2020/09/28(月) 22:32:50.70 ID:iFBbxDDj.net
- >>253
そういう意見など、奴らは無視して漢字を 16ビットに無理やり押し込めにかかり、
あわてた中日韓が妥協させられてできあがったのが CJK 漢字統合
月日は流れ、結局 16 ビットの中に世界の文字を押し込めることなど出来ないと奴らが悟った後には、醜い CJK 漢字統合だけが残されたのであった…
- 255 ：デフォルトの名無しさん：2020/09/28(月) 22:43:50.48 ID:F7s1Ev+m.net
- >>254
そんな話してないよ
- 256 ：デフォルトの名無しさん：2020/09/28(月) 23:19:53.80 ID:LFNRA5Wr.net
- 人はみな自分の話したいことのみを話す。
>>249
NECの漢字ROMに合わせると、旧JISになるのだが、それでよろしいか？
実はこれま語られた以外にも Shift JIS には、いわゆる旧JIS(JIS78) と新JIS(JIS83)の違いというヴァリアントがあるんだよな。
NECの漢字ROM は旧JIS準拠で、富士通の漢字ROMは新JIS準拠で、互換性が無かったりとか。
マイクロソフトも Shift JIS 作った時には旧JISしか無かったはずなので、旧JIS準拠だったはずなんだけど、
今の CP932 は新JIS準拠の字形になってるので、どこかの時点(多分 DOS/Vあたり)で、ちゃっかり入れ換えてるんだよな。
- 257 ：デフォルトの名無しさん：2020/09/29(火) 01:44:43.55 ID:xt+EJgQq.net
- なんとなーくNECの漢字ROMはShiftJISじゃないのか！？とかいい出す人がいいそうｗ
PC9801シリーズは漢字ROMが搭載されていて、
テキストVRAMに文字コードを書き込むだけで画面に漢字が表示される
そのときに使われる文字コードはシフトJISではなくJISコード
http://software.aufheben.info/oohpc/textvram.html
> JISコードで書き込む
> 通常MS-DOS上でプログラミングをしているのであれば、文字コードは
> シフトJISコードを使っていることでしょう。ところが、テキストV-RAMには
> JISコードで書き込まなければならないので、別途変換ルーチンが必要です。
MS-DOSはシフトJISを使っているが、文字を表示する場合はこのような簡単なアルゴリズムで変換できる
MS-DOSで使われてる文字コードはCP932といううが、実際にはシフトJIS→JISコードの変換アルゴリズムがあるだけ
だからCP932の空き領域だってJISコードにマッピングされるし、文字を表示は漢字ROMの仕事
もしPC9801シリーズにCP932を遵守しろというのであれば、
漢字ROM（JISコード）にCP932以外を乗せるな！というしかない
だがPC9801は別にMS-DOS専用のコンピュータというわけではない
ハードウェアの仕様の話なのになぜマイクロソフトに命令されなければならないのだ？という話になる
- 258 ：デフォルトの名無しさん：2020/09/29(火) 01:52:41.35 ID:xt+EJgQq.net
- >>256
> マイクロソフトも Shift JIS 作った時には旧JISしか無かったはずなので、旧JIS準拠だったはずなんだけど、
マイクロソフトがやったのは実質シフトJISからJISコードへの変換でしかないので
例えば古いバージョンのMS-DOSのバージョンで古い一太郎（笑）を使っていて
それを収録文字数が増えた新しいハードウェアに買い換えるとMS-DOSも一太郎も同じ古いままで
新しい文字に対応できてしまうんだよね。対応する文字は漢字ROMで決まることだから
つまりMS-DOSはCP932を想定していたとしても
実際に対応する文字はMS-DOSで決めることができない
マイクロソフトが使ってる文字コードをShiftJISと呼ぼうがCP932と呼ぼうが
NECや富士通なんかが勝手に文字を追加してしまうわけ
- 259 ：デフォルトの名無しさん：2020/09/29(火) 03:15:45.97 ID:3c9yndle.net
- そもそも IBM も NEC も富士通も、パソコンの主な使用目的の一つは、自社の大型コンピューターの端末として使うことだったからな。
だから自社の汎用機に合わせて文字を追加したんであって、MS-DOS とか眼中にはない。
追加した漢字が MS-DOS からもたまたま使えただけ。
パソコン専用の Apple の文字追加はまた別の理由だが。
- 260 ：デフォルトの名無しさん：2020/09/29(火) 06:39:24.27 ID:jqf8qavY.net
- 東風フォントの人元気かな
- 261 ：デフォルトの名無しさん：2020/09/29(火) 08:26:34.17 ID:asv0X/wS.net
- >>252
だったらWikipedia以外のまともなソースとやらを出してくれよ
どうせ出せないんだろ？
- 262 ：デフォルトの名無しさん：2020/09/29(火) 11:27:29.43 ID:3c9yndle.net
- 今となっては別に昔の名前なんてどうでもだが。
アスキー・マイクロソフトが出した最初に Shift JIS に対応した MS-DOS 2.01 では MIcrosoft Kanji Code が正式名称だった。
MS-DOS のソースコードの中でSJISの処理をする部分は KANJI という表記だった。
- 263 ：デフォルトの名無しさん：2020/09/29(火) 13:51:59.38 ID:qO9m7cfy.net
- https://upload.wikimedia.org/wikipedia/commons/thumb/b/ba/JIS_and_Shift-JIS_variants.svg/2880px-JIS_and_Shift-JIS_variants.svg.png
- 264 ：デフォルトの名無しさん：2020/09/29(火) 14:17:45.42 ID:xt+EJgQq.net
- >>263
図をまとめる下手すぎ
わざとわかりづらくしてるようにしか見えない
- 265 ：デフォルトの名無しさん：2020/09/29(火) 17:25:53.58 ID:3c9yndle.net
- 白黒の限界を感じる。後、矢印の向きが派生ではなく包含関係だったりして、
通常とは逆なので知らない人が見ても理解するのは難しいかも。努力は認める。
>>264
文句あったらお前が書き直せ(お約束)
- 266 ：デフォルトの名無しさん：2020/09/29(火) 17:37:33.69 ID:aO5ZnI7G.net
- >>264
時系列とかメーカーで横に並べるべきだろうね
- 267 ：デフォルトの名無しさん：2020/09/29(火) 17:39:10.32 ID:aO5ZnI7G.net
- EUC-JPとShiftJIS系とUnicode系でも分けるべきだし
包含関係でまとめられるのはまとめるべきだろう
- 268 ：デフォルトの名無しさん：2020/09/29(火) 17:51:57.33 ID:3c9yndle.net
- ぱっと見てみたけど、包含関係は、かなり正確だな。
今までここに上げられた、いい加減な図と比べるとかなりマシ。
NEC の CP932 と、IBM の CP932 を混ぜて Windows CP932 ができたなどという中途半端な説明が
間違いということが、わかるように書かかれている。
- 269 ：デフォルトの名無しさん：2020/09/29(火) 17:55:22.30 ID:aO5ZnI7G.net
- >>268
図の真ん中、Shift-JIS Windows 932は
Shift-JIS with NEC r13 and 89-92 and IBM DBCS からできたって書いてありますが？
- 270 ：デフォルトの名無しさん：2020/09/29(火) 18:03:23.01 ID:aO5ZnI7G.net
- そして、その「Shift-JIS with NEC r13 and 89-92 and IBM DBCS」は
「Shift-JIS with NEC r13 and 89-92」＋「Shift-JIS with IBM DBCS」のことだって書いてありますよね？
- 271 ：デフォルトの名無しさん：2020/09/29(火) 18:17:32.15 ID:3c9yndle.net
- 左からも矢印が延びてるの見えない？
- 272 ：デフォルトの名無しさん：2020/09/29(火) 18:20:25.83 ID:aO5ZnI7G.net
- 左からの矢印？
そりゃいわゆるShiftJISと呼ばれたものに「NECの追加文字」と「IBMの追加文字」を加えたって言ってるんだから
左のもの（基本的な文字セット）もあるに決まってんだろｗ
- 273 ：デフォルトの名無しさん：2020/09/29(火) 18:34:13.19 ID:3c9yndle.net
- 都合の悪いものは見えない目をしてる奴がいるようなので、
その図で表示されている文字集合の関係を表にしてみた。
Windows CP932 だけ他と比べて明らかに違うところあるだろ。
逆に IBM の CP932 にあって Windows 932 にないのとかも
A J K IBMex 漢 IBM漢 NEC特 NEC漢
Invaliant × ○ ○ × ○ × × ×
with NEC r13,80-92 × ○ ○ × ○ × ○ ○
with IBM DBCS × ○ ○ ○ ○ ○ × ×
IBM CP 932 × ○ ○ ○ ○ ○ × ×
with IBM DBCS & NEC × ○ ○ × ○ ○ ○ ○
Windows CP 932 ○ × ○ × ○ ○ ○ ○
IBM CP 943 × ○ ○ ○ ○ ○ ○ ○
A: ASCII
J: JIS X 0201 Romaji (JIS半角英数字)
K: JIS X 0201 Kana (JIS半角カナ)
漢: JIS X 0208 (JIS漢字)
IBMex: IBM katakana extesion (IBM半角拡張)
IBM漢: IBM DBCS extension (IBM漢字拡張)
NEC特: NEC row 13 (NEC特殊文字)
NEC漢: NEC row 89-92 (NEC漢字 + IBM選定NEC漢字)
- 274 ：デフォルトの名無しさん：2020/09/29(火) 18:35:11.83 ID:3c9yndle.net
- 表ズレた。すまん。
- 275 ：デフォルトの名無しさん：2020/09/29(火) 18:39:08.12 ID:aO5ZnI7G.net
- >>215のリンク先に書いてある
> マイクロソフト標準キャラクタセット (Windows-31J、MS932) は、
> マイクロソフト社が使用している日本語用文字コードで、 シフトJISの一種です。
> [37]標準的なシフトJISに加え、NEC や IBM の拡張に由来するいくつかの追加文字を収録しています。
NEC や IBM の拡張に由来する「いくつかの」追加文字を収録していますという話を繰り返しただけか
リンク先読んでねーなこいつｗ
- 276 ：デフォルトの名無しさん：2020/09/29(火) 18:41:53.46 ID:3c9yndle.net
- 再挑戦。
Ａ Ｊ Ｋ Ｘ 漢 Ｉ漢 Ｎ特 Ｎ漢
× ○ ○ × ○ × × × Invaliant
× ○ ○ × ○ × ○ ○ with NEC r13,80-92
× ○ ○ × ○ ○ × × with IBM DBCS
× ○ ○ ○ ○ ○ × × IBM CP 932
× ○ ○ × ○ ○ ○ ○ with IBM DBCS & NEC
○ × ○ × ○ ○ ○ ○ Windows 932
× ○ ○ ○ ○ ○ ○ ○ IBM 943
Ａ: ASCII
Ｊ: JIS X 0201 Romaji (JIS半角英数字)
Ｋ: JIS X 0201 Kana (JIS半角カナ)
Ｘ: IBM katakana extesion (IBM半角拡張)
漢: JIS X 0208 (JIS漢字)
Ｉ漢: IBM DBCS extension (IBM漢字拡張)
Ｎ特: NEC row 13 (NEC特殊文字)
Ｎ漢: NEC row 89-92 (NEC漢字 + IBM選定NEC漢字)
- 277 ：デフォルトの名無しさん：2020/09/29(火) 19:33:37.91 ID:3JpWukK6.net
- ASCII 互換じゃないから Linux では SJIS は使えないｷﾘ
とかほざいてたのいたけど、実際には ASCII 互換じゃないと困るのは Windows の方だったという落ち。
樂しい♪
- 278 ：デフォルトの名無しさん：2020/09/29(火) 19:49:07.20 ID:3c9yndle.net
- >>277
仕方ないよな。UNIX 系のパス区切りは / なので ISO-646 系ならどれでも共通だけど
Windows はパス区切り \ なので国ごとに違っていて、Unicode に変換した時に困る。
- 279 ：デフォルトの名無しさん：2020/09/29(火) 20:13:35.05 ID:gQNOuyE2.net
- >>278
ん？
Windowsのパス区切りは、あくまでバックスラッシュで、
それぞれの言語環境で別の文字に見えてるだけでしょ？
割り当てられた文字コード番号自体は同じじゃないのか？
- 280 ：：2020/09/29(火) 20:34:00.58 ID:5fiAtNx/.net
- >>279
win32api から見る限り、パス区切りは \ であっても / であっても使えます
- 281 ：デフォルトの名無しさん：2020/09/29(火) 20:51:03.40 ID:aO5ZnI7G.net
- >>277
アプリケーション側の問題だからね
OSだけ対応していても
- 282 ：デフォルトの名無しさん：2020/09/29(火) 20:55:47.86 ID:jqf8qavY.net
- mohtaの昔から文字コードの話はなんでこう揉めるんだろ
- 283 ：デフォルトの名無しさん：2020/09/29(火) 22:01:45.11 ID:9ObbGclz.net
- https://docs.microsoft.com/ja-jp/previous-versions/visualstudio/visual-studio-2008/77859s1t(v=vs.90)
UNIX ではパス デリミタとしてスラッシュ (/) しか使用できませんが、Win32 オペレーティング システムは円記号 (\) とスラッシュ (/) の両方を使用できます。
- 284 ：デフォルトの名無しさん：2020/09/29(火) 23:21:22.59 ID:ht078/Zc.net
- バックスラッシュをファイル名に使えるからデリミタに使う意味がない
- 285 ：デフォルトの名無しさん：2020/09/30(水) 00:15:57.00 ID:mE7lggX7.net
- それどころか多分どの制御コードやDEL、極めつけは
改行コードまでLinuxやUNIXはファイルめに使えるんだ
すごいだろー
findでどうやって改行コードが入ったファイル名を扱うのか知らんがｗ
- 286 ：デフォルトの名無しさん：2020/09/30(水) 00:17:36.68 ID:mE7lggX7.net
- バックスラッシュをファイル名に使うと面白いことができて
echoでそのファイル名を表示すると、色を付けたりできるんだｗ
- 287 ：デフォルトの名無しさん：2020/09/30(水) 00:18:07.91 ID:mE7lggX7.net
- 間違ったｗ 色をつけるのはエスケープコードだったｗ
- 288 ：デフォルトの名無しさん：2020/09/30(水) 00:24:04.53 ID:h1wvHACb.net
- 🐏スケープゴートに空目したわ
- 289 ：デフォルトの名無しさん：2020/09/30(水) 00:24:37.97 ID:JM4zIKtb.net
- >>285
たいていのシェル環境だとデフォルトは Ctrl-V の後に改行を入れる。カスタマイズ化。
- 290 ：デフォルトの名無しさん：2020/09/30(水) 00:25:31.56 ID:h1wvHACb.net
- 訂正。🐐ゴートは羊じゃなくて山羊
- 291 ：デフォルトの名無しさん：2020/09/30(水) 00:27:29.17 ID:JM4zIKtb.net
- 入力でなくて出力の話なら -0 オプションで、改行区切りから Null 文字区切りに変更できる。
- 292 ：デフォルトの名無しさん：2020/09/30(水) 01:46:35.60 ID:bt+pY3Wp.net
- ぬるぽ
- 293 ：デフォルトの名無しさん：2020/09/30(水) 02:06:47.48 ID:mE7lggX7.net
- >>291
それはPOSIX準拠じゃないんだよなｗ
UNIXは改行が使えるから、UNIXで苦労するｗ
- 294 ：デフォルトの名無しさん：2020/09/30(水) 02:08:30.20 ID:mE7lggX7.net
- ファイル名にコロンが使えるから
PATHのコロン区切りで問題が出るというねｗ
制御文字と一部の記号は使えないようにするべきだっただろうな
- 295 ：デフォルトの名無しさん：2020/09/30(水) 02:13:17.35 ID:JM4zIKtb.net
- アホか？ 使いたくない文字は使わなきゃ良いだけなんやで。
わざと変な文字入れて、変な文字入れられる方が悪いとか、小波。
- 296 ：デフォルトの名無しさん：2020/09/30(水) 02:17:17.38 ID:mE7lggX7.net
- >>295
論点ずれてるぞｗ
いろんな文字が使えちゃうから、それが原因でバグになるということだ
ファイル名に改行を入れられるってことを知らないで作っていたら
「bin<改行>lib<改行>etc」みたいなフォルダを消そうとして被害にあったり
「a*?」みたいなファイル名でaで始まるファイルが全部消えたりｗｗｗとか
実際に起きてるからな
- 297 ：デフォルトの名無しさん：2020/09/30(水) 02:26:40.95 ID:d/2ZwJCe.net
- >>292
ｶﾞｯ
- 298 ：デフォルトの名無しさん：2020/09/30(水) 02:26:53.11 ID:JM4zIKtb.net
- 制限したいやつが制限すればええんやで。Linux にはその仕組みがある。
普通の人はそんなことせんでも変は文字入れないから、困ってないだけ。
- 299 ：デフォルトの名無しさん：2020/09/30(水) 02:49:29.19 ID:mE7lggX7.net
- 入れたくていれるんじゃなくて
端末に文字をペーストしたら変な文字を実行しちゃったりして
その結果変な名前のファイルができたりするんだよ
*とか?とか<とか>とか!とかシェルのメタ文字は
ファイルに使えないようにするべきだった
互換性があるから手遅れなんだろうけど
普通の人は変な文字入れないというのなら
なおのこと入れられないようにしてよかったということになる
- 300 ：デフォルトの名無しさん：2020/09/30(水) 03:03:44.88 ID:JM4zIKtb.net
- だから、そんな間抜けなユーザー抱えてんなら管理者が制限設定入れとけや。
普通、変なファイルできても ls すれば、すぐ気付くし、シェルの補完とかも対応してる。
やってみもせずに妄想垂れ流す暇あったら触ってこい。
それでも駄目だと思うんなら、システム制限掛けとけ。
- 301 ：デフォルトの名無しさん：2020/09/30(水) 03:11:45.53 ID:mE7lggX7.net
- シェルの補完にバグがないとどうしているんだ？ｗ
メタ文字とかは勝手にエスケープが入ったりする。だがそれが正しいとどうしていえる？
どうエスケープすればいいかを知らなければ、今からエンター押しても大丈夫か？なんてわからんはずだが
だから俺はGUIから消すようにしてるよ。GUIならシェルのワイルドカード展開なんて使えないからね
- 302 ：デフォルトの名無しさん：2020/09/30(水) 03:15:35.92 ID:JM4zIKtb.net
- お前に Linux は早過ぎた。
バグが心配ならソースでも眺めとけ。ここプログラム板やし。
- 303 ：デフォルトの名無しさん：2020/09/30(水) 03:23:32.50 ID:mE7lggX7.net
- 初心者「バグがあるかもしれない」
プログラマ「バグなんてあるわけない」
こういう考えかｗ
- 304 ：デフォルトの名無しさん：2020/09/30(水) 03:39:20.46 ID:JM4zIKtb.net
- 初心者： いきなりバグとか心配しない。気になったたらドキュメントとか、ネット調べたり、試行錯誤して学習する。
プログラマ：いきなりバグとか心配しない。気になったらソースコード確認して、万一バグを見つけたら自分で直す。
お前：根拠無くバグが心配になり、5ch でOS の仕様にケチをつける。
- 305 ：デフォルトの名無しさん：2020/09/30(水) 03:41:07.93 ID:mE7lggX7.net
- >>304
お前が気になったことの例を１つでも上げてみてよｗ
- 306 ：デフォルトの名無しさん：2020/09/30(水) 03:51:15.98 ID:mE7lggX7.net
- なんてレスしてるうちにバグ報告したとある有名プロジェクトから
修正したってコメントが有ったわｗ
- 307 ：デフォルトの名無しさん：2020/09/30(水) 10:44:11.67 ID:fhthbmek.net
- MS「CON\CONなんてパスを指定する奴なんているはずないな」
- 308 ：デフォルトの名無しさん：2020/09/30(水) 11:03:16.10 ID:h1wvHACb.net
- >>307
バグじゃなくて仕様だよ。予約されてるから。
- 309 ：デフォルトの名無しさん：2020/09/30(水) 11:04:41.69 ID:h1wvHACb.net
- 制約事項として明記された不具合は仕様と呼んでいい。
- 310 ：デフォルトの名無しさん：2020/10/02(金) 03:35:07.39 ID:rHkefn4v.net
- >>99
それなら普遍的に使えるスタイルとの結合文字にすりゃいい話
だけどそうしないのはそもそもスタイルと文字は分ける設計だから
スタイルはCSSなり他の技術がある
- 311 ：デフォルトの名無しさん：2020/10/02(金) 03:36:07.77 ID:rHkefn4v.net
- 肌の色とか差別がなかったところに肌の色って概念を導入した結果結局偏りが生まれてるクソ仕様
- 312 ：デフォルトの名無しさん：2020/10/02(金) 03:47:03.40 ID:b+gARvx0.net
- >>311
それはもう解決済みの問題です
- 313 ：デフォルトの名無しさん：2020/10/02(金) 11:31:57.29 ID:vWjl5fwE.net
- こんにちは、初めまして。
今、個人的に amazon kindle端末用の電子書籍データを作るにあたって
仕様として JIS X 0213:2004 を保証すると書いてあるのでこの文字コードのユニコードのセットをまとめて
いわゆる JIS X 0213:2004 文字チェッカーのようなものを作っています。
Webページベースでユニコードのテキストを入力して、
使用してる文字が Kindle端末オーケーかどうかをチェックするプログラムです。
JavaScript(u16)用 と PHP(u8)用 で二種類のチェックプログラムを作ってます。
それで資料を集めて検証しているところなのですが、ちょっと判断に迷うコードがあったので、
他に聞ける場所も無いということで、ちょっとここで質問してみることにしました。
以下のコードなのですが、方や u16 で２文字(U+025B U+0300)、方や１文字(U+1F72) になってます。
https://ja.wikipedia.org/wiki/JIS_X_0213非漢字一覧
(A) ɛ̀ 1-11-48 0x866f U+025B U+0300 グレーブアクセント付きEPSILON小文字
(A) ɛ́ 1-11-49 0x8670 U+025B U+0301 アキュートアクセント付きEPSILON小文字
https://www.asahi-net.or.jp/~ax2s-kmtn/ref/unicode/u1f00.html#u1f72
(B) U+1F72 ὲ グレーブアクセント付きEPSILON小文字
(B) U+1F73 έ アキュートアクセント付きEPSILON小文字
この文字だけに限っての判断としますが、
どちらか一方が出た場合にどちらかに変換して正規化するとした場合、
正規化後は (A) と (B) のどちらが良いと思いますか？
気が向いたらレスを付けてくれたら嬉しいです、参考にしますので。
ちなみに、Windows10等でキーボード入力される 全角チルダ(U+FF5E,'～') は
JIS x0213:2004 コード規格の 波線(U+301C,'〜') に正規化することにしています。
(その他、似たような文字はなるべく一種類に正規化出来ればと考えています)
- 314 ：デフォルトの名無しさん：2020/10/02(金) 11:37:56.63 ID:vEIDHK0R.net
- グレープってなんだって思ったらグラーブのことか
- 315 ：デフォルトの名無しさん：2020/10/02(金) 11:59:54.40 ID:ooD45Zz3.net
- Ruby に、そのエンコードは無いの？
- 316 ：デフォルトの名無しさん：2020/10/02(金) 12:00:25.80 ID:vWjl5fwE.net
- どうぞ。
https://www.asahi-net.or.jp/~ax2s-kmtn/ref/unicode/u1f00.html#u1f72
1F72 ὲ GREEK SMALL LETTER EPSILON WITH VARIA ≡03B5(ε) 0300(◌̀) グレーブアクセント付きEPSILON小文字 2B50
1F73 έ GREEK SMALL LETTER EPSILON WITH OXIA ≡03AD(έ) アキュートアクセント付きEPSILON小文字
https://ja.wikipedia.org/wiki/JIS_X_0213非漢字一覧
` 1-1-14 0x814d U+0060 アクサングラーブ/グレーブアクセント グレイヴ・アクセント
https://ja.wikipedia.org/wiki/グレイヴ・アクセント
JIS X 0213の名称は、「アクサングラーブ, グレーブアクセント」
The grave accent ( ` ) (/ɡreɪv/ or /ɡrɑːv/)
- 317 ：デフォルトの名無しさん：2020/10/02(金) 14:38:35.67 ID:vWjl5fwE.net
- なんとなく備忘録
https://ja.wikipedia.org/wiki/JIS_X_0213非漢字一覧
\ 1-1-32 (JIS)2140 (SJIS)0x815f U+005c 逆斜線 バックスラッシュ
\ 1-1-79 (JIS)216f (SJIS)0x818f U+00a5 円記号 円記号
日本語環境だとどちらも円マークだけど、JISx0208 , JISx0213 だと U+00a5 に正規化すべきなのか・・・、
一応 JIS x0213:2004 規格だと、U+005c はバックスラッシュで表示されるらしいし？
自分とこで作る電子書籍は問答無用で全角円マークにするから検討すべき問題でもないのだけれど、
とりあえず日本語でしか使わないので U+005c → U+00a5 正規化コードを突っ込んどけばいいか。
というか、いい加減にカオスな状況が終わってると思ってチマチマ始めたというのに、
なんか微妙なところで微妙に決まってないというか、
mb_convert_encoding() で Unicode から JIS コードにしたいのに、
エラーも出さずにシラっと Unicode で返すのは辞めてほしかった・・・、
ちなみにこんなもので悩もうとか思ったのは、
kindle用電子書籍を作るにあたって第3水準や第4水準のつもりで使った漢字を
既存のWebサービスやツール類で 適性かどうかをチェック出来るものが無かったからなんですね。
まぁ、既存のツールがあったとしても他人が作ったそのツールの仕様を理解するのも面倒だって理由もありますが。
ちょっと気づいたんだけど、U+00a5 の方も普通に Windows のファイル名として使えるのね・・・、
見た目で違いを判別できないとか、まじに勘弁してほしい。
あと、他のサイトだけど、しらっと SJIS で６バイトのコードを表示するのも辞めてほしい・・・、
- 318 ：デフォルトの名無しさん：2020/10/02(金) 15:25:55.64 ID:rmc8/xO8.net
- 日本の PC の内臓フォントは JIS X 0201 だったので、SJIS の 0x5C は円記号ということで運用されていたのだけど
Windows 3.1 で Unicode 対応を入れる時に ASCII 互換じゃないとうまくいかないことに気付いて、
CP932 の 0x5C を「見かけは円記号に見えるけど、実際には逆射線ということにした。円記号に見えるのはフォントせいで心の目で見ると逆射線」ということにした。
そのせいで Windows の一部日本語フォントを使った場合のみ 0x5C と 0xA5 の両方が円記号で表示される。
解決法: (1)別のフォントに変える。(2)Windows を捨てる。
- 319 ：デフォルトの名無しさん：2020/10/02(金) 15:54:09.42 ID:rmc8/xO8.net
- Unicode 的にはどっちでも良いのだけど JIS X 0213 的には 1-11-48,49 は 1F72,1F73 との対応を示しているので、そっちにしておくのが無難かな。
一文字にしておけば、結合文字に未対応の環境でも変にならずにすむし。
- 320 ：デフォルトの名無しさん：2020/10/02(金) 16:07:25.61 ID:gdIx8v5/.net
- >>318
消火器と消化器は間違えんなよ。小火器も使う時あるからな。
- 321 ：デフォルトの名無しさん：2020/10/02(金) 17:58:09.59 ID:rmc8/xO8.net
- おう逆射線と逆斜線の変換ミスな。気付いてなかったわ。すまん。
- 322 ：デフォルトの名無しさん：2020/10/02(金) 18:49:02.52 ID:zXx3uGG2.net
- >>318
Windowsだけでなく、国産Android端末もそういうフォント入れてる。
Android標準のnotoなら正しくバックスラッシュ出るんだけど、SONY端末には入ってないんだな。
- 323 ：デフォルトの名無しさん：2020/10/02(金) 18:54:47.21 ID:vWjl5fwE.net
- >>319
サンクス。
U+1F70 , U+1F71 , U+1F72 , U+1F73 は一文字の方を正規化先にして作ってみることにします。
- 324 ：デフォルトの名無しさん：2020/10/02(金) 20:47:22.49 ID:ErcYaiEt.net
- >>318
Shift_JISがJIS X 0201 Romanだから困るからCP932で超解釈したのはC言語の問題じゃなかったっけ?
Shift_JISで厳密に次のコードを解釈すると
#include <stdio.h>
int main(int argc, char argv[])
{
int a = 0x0077ffaa;
printf("%08x %08x\n", a, ~a);
return 0;
}
バックスラッシュ＼ｎとチルダ～ではなく円記号￥ｎとオーバーライン￣だから、改行とビット反転にはならない
正しくはトライグラフを使って
#include <stdio.h>
int main(int argc, char argv[])
{
int a = 0x0077ffaa;
printf("%08x %08x??/n", a, ??-a);
return 0;
}
としないといけない
だけど誰もトライグラフなんて使っていないから、CP932は0x5cはグリフが￥なバックスラッシュという超解釈でごまかした
CP932では0x7eの意味はチルダでグリフも～だからそっちはそのままでいい
チルダ関係もカオスだよね
『～』と『～』別な文字だけど区別できる見た目で表示されているほうがむしろおかしいんだっけ?
- 325 ：デフォルトの名無しさん：2020/10/02(金) 21:00:45.39 ID:Va1PciQI.net
- PDF に謎の漢字が含まれるとき
https://gist.github.com/xl1/940d653451fd96a06618a6df08d5df84
- 326 ：デフォルトの名無しさん：2020/10/02(金) 21:17:20.27 ID:zXx3uGG2.net
- ピントはずれ。
シフトJISできる前からJIS C 6220のソースをコンパイラに食わせてた。
コンパイラは0x5cにASCIIのバックスラッシュ以外の意味知らないし、そう扱って問題は出ない。
シフトJISとコンパイラで問題がでるのは文字列リテラル中のダメ字。
- 327 ：デフォルトの名無しさん：2020/10/02(金) 21:57:12.83 ID:ErcYaiEt.net
- >>326
> コンパイラは0x5cにASCIIのバックスラッシュ以外の意味知らないし、そう扱って問題は出ない。
正しく国際化されているコンパイラでは問題を起こす
実際2000年前後の国際化対応gccでShift_JISで書かれたコードで問題が起きたことがある
(ダメ字を問題なく処理できるのに￥ｎが改行と解釈されない)
日本語環境ではみんな雑に捉えて￥と＼を区別していなかったのは事実だけど、トライグラフが
ANSI Cで導入された以降Shift_JISで書かれたコードは正しく解釈すると規格に反する状態であった
実際にトライグラフをまともに使っていたのはデンマークだっけ?
- 328 ：デフォルトの名無しさん：2020/10/02(金) 22:12:09.12 ID:rmc8/xO8.net
- 厳密にいうと C言語のソースは基本文字集合と呼ばれる 1バイト文字を含まなければならない。それには \ のみで ￥ は存在していない。
JIS の C言語の規格ではソースに JIS X 0201 を使用する場合は \ と ￥ を置き換えることになっている。
1バイト文字の解釈は必ず基本文字集合と同じでなければならない。
多バイト文字やシフト状態を持つ文字でナル以外の文字に 0x00 のバイトが来るのは禁止。
シフト状態を持つ場合には初期シフト状態に基本文字集合を持たなければならない。
上記を満たせば多バイト文字の解釈は実装依存。
- 329 ：デフォルトの名無しさん：2020/10/02(金) 22:13:24.20 ID:ErcYaiEt.net
- >>327
実際にgccのShift_JISとCP932ハマった人の例見つけた
ttps://blogger.tempus.org/2008/03/gcc-shiftjis.html
- 330 ：デフォルトの名無しさん：2020/10/03(土) 00:32:32.33 ID:5QIBKgVv.net
- 文字コードを意識せずにプログラミングが出来るようになる革命はまだですか？
- 331 ：デフォルトの名無しさん：2020/10/03(土) 00:59:47.45 ID:g9HEPfwG.net
- 革命とは過去の遺物を捨て去ることだよ。
- 332 ：デフォルトの名無しさん：2020/10/03(土) 09:47:26.20 ID:8tX55Lof.net
- >>328
> JIS の C言語の規格ではソースに JIS X 0201 を使用する場合は \ と ￥ を置き換えることになっている。
ANSI CやISO 9899にそんな規定はない
JISX3010で参考として追記された箇所であってローカル規格
そもそも￥を＼の代わりに使っていいなら何のためにトライグラフを国際規格に入れたの?
￥を＼と解釈するJISX3010は国際規格ISO 646に反しCP932と同じ超解釈の類
gccの振る舞いが国際規格に準拠する正しい動作
- 333 ：デフォルトの名無しさん：2020/10/03(土) 10:32:33.14 ID:1CYfZXkg.net
- ideone.com とかは
スマホから試すときとPCから試すときで
\と＼の扱いが違って動きが可笑しくなることがある
unicode になって区別が明確になったことによる弊害のひとつ
- 334 ：デフォルトの名無しさん：2020/10/03(土) 14:19:07.86 ID:asw2Nmie.net
- >>322
だから JIS の C言語の規格で、なおかつ入力に JIS X 0201 を使う時、限定と書いてるじゃん。
コンパイラがロカール規格に対応していたら使って良いんだよ。
gcc がローカル規格に対応する義務はないが、ちなみに gcc には LANG=C-SJIS という設定があってな。
- 335 ：デフォルトの名無しさん：2020/10/03(土) 14:23:10.98 ID:asw2Nmie.net
- アンカミス。 322 → 332
- 336 ：デフォルトの名無しさん：2020/10/03(土) 14:44:31.16 ID:y5FkQ2yd.net
- もちつけ
- 337 ：デフォルトの名無しさん：2020/10/05(月) 00:37:11.64 ID:aYBNZcXd.net
- >>323
どうなんだろうね。
確かにユニコード的には例えばNFDにしたときのベースの文字が正解かと。
一方 U+025X はIPAのブロックで、要は発音記号... ということは、文脈的に発音記号
として使われているならこっちだったりするのかも?
- 338 ：デフォルトの名無しさん：2020/10/08(木) 10:57:17.71 ID:tD965ZiH.net
- Rubyをやってるんだけど、分からないところあるから教えてほしいです…
クラスメソッド、インスタンスメソッド、インスタンス変数あたりの意味がさっぱりで…
- 339 ：デフォルトの名無しさん：2020/10/08(木) 11:08:48.28 ID:Riy1MZEi.net
- 説明読んでも意味が判らない間は無理に使う必要は無い
君にはまだ早いってこと
- 340 ：デフォルトの名無しさん：2020/10/08(木) 11:25:58.08 ID:e+h9pet/.net
- >>338
Ruby 初心者スレッド Part 66
https://mevius.5ch.net/test/read.cgi/tech/1578068134/
- 341 ：デフォルトの名無しさん：2020/10/08(木) 11:34:16.59 ID:SMtYwKCf.net
- 個人的に普段は ruby は使わないんだけど、文字コードの実装は perl や python や java に比べると ruby は筋が良いんだよな。(個人の感想です)
- 342 ：デフォルトの名無しさん：2020/10/08(木) 21:30:15.81 ID:24ftK7/Z.net
- >>341
python使いの私に文字コード関連でのrubyの利点についてぜひご教示ください。
rubyはさわったこと無いです。
- 343 ：デフォルトの名無しさん：2020/10/09(金) 09:29:33.69 ID:81dxs4Bx.net
- ドキュメントを見ると結構マイナー(?)なエンコーディングもあるっぽいね。
ケータイ各社の絵文字入りSJISとかもあるんだ。
https://en.wikibooks.org/wiki/Ruby_Programming/Encoding
- 344 ：デフォルトの名無しさん：2020/10/09(金) 11:37:23.24 ID:5kgt8bw0.net
- >>342
Python は内部格納文字コードに unicode を固定で使用していて、unicode に変換できない文字は使えないし、
unicode に変換した場合に unify などで消える情報は保持できないけど、
ruby は特定の文字コードを仮定した内部コードを持たないため、programing や library の実装でどうにでもなる。
初心者には Python の実装がわかりやすいけど、文字コードそのものをいじりたいレベルになると嵌ることがある。
概要は ruby m17n とかで、検索してい関連しそうな記事を読んで見ると良いかと。
- 345 ：デフォルトの名無しさん：2020/10/09(金) 11:44:47.75 ID:vl+UDRkB.net
- うそはいかんよ
python は binary も自由に扱える
- 346 ：デフォルトの名無しさん：2020/10/09(金) 12:08:49.92 ID:8qJEmYsV.net
- >>345
バイナリは文字じゃないので文字列の長さすらわからない
低機能なデータ形式でしかない
- 347 ：デフォルトの名無しさん：2020/10/09(金) 12:37:20.08 ID:vl+UDRkB.net
- ruby は文字じゃないものの文字列長をどうやって計算してるのですか？
- 348 ：デフォルトの名無しさん：2020/10/09(金) 12:38:41.36 ID:EjYkYVIx.net
- >>347
文字じゃないものの文字列長なんて計算できるわけ無いでしょ（笑）
だからいろんな文字コードを文字として認識できるようになってる
それに対しPythonはバイナリだから文字列の長さが計算できない（大爆笑）
- 349 ：デフォルトの名無しさん：2020/10/09(金) 12:44:19.84 ID:vl+UDRkB.net
- うそはいかんよ
馬鹿丸出しだから煽りは止めた方が良い
- 350 ：342：2020/10/09(金) 12:45:15.41 ID:hk0qQeVw.net
- >>344
ありがとうございます。
個々の文字列オブジェクトにエンコーディング情報を持たせてるので
文字コードを変換せずにm17nを実現できてる感じですね。
- 351 ：デフォルトの名無しさん：2020/10/09(金) 20:40:06.43 ID:phj7/P3X.net
- 漢字のようで漢字でないUnicodeの「康熙部首」と「CJK部首補助」
https://techracho.bpsinc.jp/hachi8833/2020_10_07/95257
- 352 ：デフォルトの名無しさん：2020/10/10(土) 09:48:22.75 ID:mP3lsNpF.net
- Unicode 3.0って1999年だろうに
- 353 ：デフォルトの名無しさん：2020/10/10(土) 22:38:12.17 ID:vUhDQSk6.net
- nuby からの流れで... nkf って今でもメンテされてるようで。
ネットニュースから shar で入手したのはいつの日か。
- 354 ：デフォルトの名無しさん：2020/10/10(土) 23:59:49.31 ID:33g/v1Rs.net
- Unicodeの文字の情報を見たいと思ったら
どれを参照すればいいの？
- 355 ：デフォルトの名無しさん：2020/10/11(日) 01:36:12.47 ID:PkCT08SK.net
- 情報って？
- 356 ：デフォルトの名無しさん：2020/10/11(日) 01:53:31.67 ID:QQ2vPcGT.net
- Aという文字の小文字はaであるとか
- 357 ：デフォルトの名無しさん：2020/10/11(日) 02:42:43.61 ID:Y6xs0w7V.net
- Unicodeのcode chartにはいちいち文字の説明が書いてあるがそれ以上の説明が欲しいのか否か？
https://unicode.org/charts/
- 358 ：デフォルトの名無しさん：2020/10/11(日) 06:59:02.20 ID:QQ2vPcGT.net
- >>357
それらの情報を全て文字ごとに知りたいんだよ
- 359 ：デフォルトの名無しさん：2020/10/11(日) 07:21:36.62 ID:X3noy0YM.net
- >>358
"Find chart by hex code:" ってとこにコードポイントを入れてみようw
- 360 ：デフォルトの名無しさん：2020/10/11(日) 07:33:27.40 ID:QQ2vPcGT.net
- >>359
情報が全く足りません
- 361 ：デフォルトの名無しさん：2020/10/11(日) 07:34:05.33 ID:QQ2vPcGT.net
- Aは大文字であり、対応する小文字はaである
という情報はどこに書かれているのでしょうか？
- 362 ：デフォルトの名無しさん：2020/10/11(日) 08:36:01.64 ID:9KwtZAoB.net
- https://unicode.org/charts/PDF/U0000.pdf
これの
LATIN CAPITAL LETTER A
LATIN SMALL LETTER A
区別じゃ足りないかい？
- 363 ：デフォルトの名無しさん：2020/10/11(日) 08:49:30.81 ID:biiSH/I3.net
- > 0041 A LATIN CAPITAL LETTER A
少なくとも「Aは大文字」は明記されてるけど？？
> 0061 a LATIN SMALL LETTER A
小文字aの定義の記述から対応する文字も分かると思うんだけど
それじゃわからないということであれば、
「大文字Aに対応する小文字はaである」みたいなことは
Unicodeの仕様書じゃなくて英語圏の小学生or幼稚園児向け教科書とかに書かれてるんじゃないかね
- 364 ：デフォルトの名無しさん：2020/10/11(日) 09:48:07.57 ID:EIUTbwb3.net
- 何が欲しいか、もっと明確に書かないと伝わらないぞ。
例えばこれとかは使える？
https://unicode.org/Public/UNIDATA/UnicodeData.txt
- 365 ：デフォルトの名無しさん：2020/10/11(日) 10:11:43.02 ID:X3noy0YM.net
- >>364
使えるかどうかは能力の問題ですよねw
- 366 ：デフォルトの名無しさん：2020/10/11(日) 10:24:25.43 ID:ieSx8e01.net
- >>364
これは対応した項目があるねぇ
装飾のあるアルファベットについても参照番号が載ってる
- 367 ：デフォルトの名無しさん：2020/10/11(日) 12:14:43.64 ID:kZXFoyze.net
- ほう
3041;HIRAGANA LETTER SMALL A;Lo;0;L;;;;;N;;;;;
3042;HIRAGANA LETTER A;Lo;0;L;;;;;N;;;;;
- 368 ：デフォルトの名無しさん：2020/10/11(日) 12:26:01.00 ID:j5pFI3Yh.net
- あ、あと文字の幅も知りたい
- 369 ：デフォルトの名無しさん：2020/10/11(日) 12:27:09.66 ID:j5pFI3Yh.net
- Aに対応する小文字がaなら
あに対応するカタカナはアという情報があっても
良いと思うのだがあるのか？
- 370 ：デフォルトの名無しさん：2020/10/11(日) 12:33:22.48 ID:kZXFoyze.net
- >>369
曾礼多
- 371 ：デフォルトの名無しさん：2020/10/11(日) 12:36:42.03 ID:j5pFI3Yh.net
- >>370
嫁無い
- 372 ：デフォルトの名無しさん：2020/10/11(日) 13:23:05.62 ID:a5ebPbEF.net
- 1，2，3
- 373 ：デフォルトの名無しさん：2020/10/11(日) 13:26:32.41 ID:a5ebPbEF.net
- 3042;HIRAGANA LETTER A;Lo;0;L;;;;;N;;;;;
30A2;KATAKANA LETTER A;Lo;0;L;;;;;N;;;;;
ないようだ
- 374 ：デフォルトの名無しさん：2020/10/11(日) 18:56:47.77 ID:lNYgVXzm.net
- いい加減自分で調べられるだろ... 釣りか
Unicodeの他のデータとかUnicodeに関するAPIとかにある。
そうやって、全世界が「あーUnicodeでいいね」ってなるように
Unicodeの世界戦略は着々と進んでいるのであった。
- 375 ：デフォルトの名無しさん：2020/10/11(日) 20:41:30.45 ID:EIUTbwb3.net
- 日本語のマップくらいは自分で作ればいいんじゃね？
https://unicode.org/charts/PDF/U1B000.pdf
- 376 ：デフォルトの名無しさん：2020/10/11(日) 21:37:26.96 ID:wm510+AL.net
- 変体仮名も収録されてるんだな
- 377 ：デフォルトの名無しさん：2020/10/13(火) 00:47:23.21 ID:tEy/04zZ.net
- あをアに対応させるのはtransliterationのカテゴリーらしい、Unicode的には。
日本語だと翻字というのかー。
- 378 ：デフォルトの名無しさん：2020/10/13(火) 06:17:14.44 ID:RnL4UaYd.net
- 漢字の読み方（複数）もUnicodeで定義されるべきではないのかな？
- 379 ：デフォルトの名無しさん：2020/10/13(火) 09:57:18.23 ID:FpFGKRx+.net
- 棚
- 380 ：デフォルトの名無しさん：2020/10/13(火) 13:54:08.89 ID:8ughZvwQ.net
- Unicode は文字コードであって漢和辞典ではないし、読みとか何の役にも建たないw
- 381 ：デフォルトの名無しさん：2020/10/16(金) 00:51:17.29 ID:zvezW4n7.net
- >>361
大文字小文字を区別しない検索を行うためのデータという意味ならこれ
http://www.unicode.org/Public/UNIDATA/CaseFolding.txt
ある文字が大文字または小文字に該当するかを知りたいなら>>364のデータの
3番目のフィールドを見る。Luなら大文字でLlなら小文字
- 382 ：デフォルトの名無しさん：2020/10/20(火) 08:39:00.75 ID:iDoXrFT4.net
- rubyを勉強中の超初心者なのですが、時代遅れだ！みたいな記事をちらほら見かえます。
言語変えた方がいいのでしょうか…？
- 383 ：デフォルトの名無しさん：2020/10/20(火) 10:25:40.98 ID:xAfCoP/O.net
- なぜ、ここで、その質問を？
文字コード的には変えるほど意味はない気がする。(むしろ ruby が便利)
複数の言語が使えた方が便利なので、色々試すことはおすすめ。
- 384 ：デフォルトの名無しさん：2020/10/20(火) 10:30:11.60 ID:pHiz9StD.net
- Yes, you can.
- 385 ：デフォルトの名無しさん：2020/10/20(火) 16:20:38.97 ID:Nlf6zVNG.net
- はい、あなたは管です。
- 386 ：デフォルトの名無しさん：2020/10/24(土) 21:01:49.65 ID:ehxRee/D.net
- いいえ、私は管(くだ)です
- 387 ：デフォルトの名無しさん：2020/10/25(日) 01:00:40.73 ID:+b3TKvfL.net
- いいえ、私は菅です。
- 388 ：デフォルトの名無しさん：2020/12/07(月) 15:52:31.12 ID:BlHR3DgB.net
- 櫻の絵文字🌸がPCやiPhoneだと花びら5枚なのに
Androidだと4枚ω
- 389 ：デフォルトの名無しさん：2020/12/07(月) 16:34:11.79 ID:TmqbbT66.net
- >>388
また友達に騙されちゃったんだね…
- 390 ：デフォルトの名無しさん：2020/12/07(月) 21:30:49.12 ID:8FTbf1dJ.net
- utf8でshiftjisで言う
iskanji()
iskanji2()
ishira()
iskata()
みたいなイディオム教えてください
- 391 ：デフォルトの名無しさん：2020/12/08(火) 11:51:17.55 ID:3Lge4PBr.net
- >>390
utf8のコードがshiftjisに変換可能かチェックして、可能なら変換したコードに
そのイディオムとやらを使えばいいのでは?
- 392 ：デフォルトの名無しさん：2020/12/08(火) 12:25:05.31 ID:no2frcgf.net
- >>391
shiftjisは扱わないのでutf8での方法を教えてください
- 393 ：デフォルトの名無しさん：2020/12/08(火) 17:31:43.20 ID:/pT3aml4.net
- >>390
Unicodeプロパティがサポートされているなら
正規表現で\p{Hiragana}とかが使える
サポートされてないなら自分でコードポイントの範囲を調べて頑張る
- 394 ：デフォルトの名無しさん：2020/12/08(火) 18:36:17.22 ID:E4wQPgos.net
- 長音（ー）とかの扱いがめんどくさい
- 395 ：デフォルトの名無しさん：2020/12/09(水) 06:33:19.08 ID:Hs7wcc9u.net
- ちょっと疑問に思ったのだけど、
utf8 の iskanji を作るとしたら、繁体字とかも含めますか？
それとも今は JISx0213:2004（11233文字） だけ？
それともこれの次の標準化規格になるものってありましたっけ？
- 396 ：デフォルトの名無しさん：2020/12/09(水) 06:43:54.04 ID:Hs7wcc9u.net
- ishankana() みたいなもの、javascript 版
if( /^[ｱｲｳｴｵｶｷｸｹｺｻｼｽｾｿﾀﾁﾂﾃﾄﾅﾆﾇﾈﾉﾊﾋﾌﾍﾎﾏﾐﾑﾒﾓﾔﾕﾖﾗﾘﾙﾚﾛﾜｦﾝｧｨｩｪｫｬｭｮｯ､｡ｰ｢｣ﾞﾟ･]/.test('ｱ') )
{
console.log( '半角カタカナです');
}
- 397 ：デフォルトの名無しさん：2020/12/09(水) 07:34:03.35 ID:qbXHpF4v.net
- そのiskanjiとやらであなたが何を判定したいか次第だと思うんだけど・・
サロゲートペアの漢字とかも気にしなきゃだめだろうねえ
- 398 ：デフォルトの名無しさん：2020/12/09(水) 08:14:17.98 ID:TKgHvdMy.net
- >>396
半角カナは後ろの方の文字コードでかたまってるから簡単じゃろ。
漢字とか結構カオスでテーブル作ったほうが良さそうだね。
必要文字コード列挙してバイナリサーチするアルゴリズムがええのかな？
厳格でなくていいなら半角カナみたいに文字コードテーブルみて
ざっくり判定でも割と行けるとは思うけど。
- 399 ：デフォルトの名無しさん：2020/12/09(水) 09:06:33.04 ID:Hs7wcc9u.net
- そういえば前に、amazon kindle端末用の電子書籍データ云々でここに書きこんだ記憶が、
と思い当って見直してみたら２か月前でした・・・、
私の方は KDP の仕様にあってるかどうかをチェックするのが目的だったのですが、
確かにカオスでしたね。ちなみに半角カナのコードを出しておいてあれなのですが、
JISx0213 規格的には半角カナは含まれてないっぽいです（x0208も同様です）。
チェック用のプログラムは結局普通の配列に規格の文字を全部入れておいて、
そこにあれば OK なければ NG という感じになりました。
サロゲートペアの扱いも面倒だったし。
あ、今気づいたけれど、JISx0213 的には全角英数記号ってもしかして NG なのでは？
いやでも wiki のページでは SJISコードは全角になってるし・・・、
- 400 ：デフォルトの名無しさん：2020/12/09(水) 09:18:54.21 ID:bCzZQrOf.net
- ライブラリ内ではユニコードスカラー値についてのみ取り扱うと良いと思います。
- 401 ：デフォルトの名無しさん：2020/12/09(水) 13:23:38.64 ID:y7KEYUhD.net
- Ruby の古いNKF を使うと、片仮名・平仮名の変換もできるけど、
片仮名・平仮名を判定するメソッドはない
たぶん、NKF の内部では、そういう関数があるのだろけど、公開されていないのかも
module NKF
https://docs.ruby-lang.org/ja/latest/class/NKF.html
require 'nkf'
p NKF.nkf( '-m0 -h3 -w', 'あイ' )
#=> "アい"
- 402 ：デフォルトの名無しさん：2020/12/09(水) 13:25:03.81 ID:rIU0lDlE.net
- オプションそのまま文字列で渡すとか
ダッセェインターフェースだな
手抜きにも程がある
- 403 ：401：2020/12/09(水) 14:41:10.37 ID:y7KEYUhD.net
- Ruby の正規表現・鬼雲で判別できた
re_hira = /\p{hiragana}{1}/ # 平仮名
re_kata = /\p{katakana}{1}/ # カタカナ
str = '愛あいカキうクx'
str.each_char do |ch|
ch.match( re_hira ){ |md| puts "平仮名 : #{ md[ 0 ] }" }
ch.match( re_kata ){ |md| puts "カタカナ : #{ md[ 0 ] }" }
end
出力
平仮名 : あ
平仮名 : い
カタカナ : カ
カタカナ : キ
平仮名 : う
カタカナ : ク
- 404 ：デフォルトの名無しさん：2020/12/09(水) 15:27:54.98 ID:tBDPYy0r.net
- >>402
tcl/tk
- 405 ：デフォルトの名無しさん：2020/12/09(水) 16:19:55.89 ID:H89RJ3R9.net
- こゝろ
- 406 ：401：2020/12/09(水) 17:51:11.38 ID:y7KEYUhD.net
- >>403
を修正
Ruby の正規表現・鬼雲で、平仮名・カタカナ・漢字を判別した
re_hira = /\p{Hiragana}{1}/ # 平仮名
re_kata = /\p{Katakana}{1}/ # カタカナ
re_han = /\p{Han}{1}/ # 漢字
str = 'Aあい善悪カキ愛うクx'
p str.encoding #=> <Encoding:UTF-8>
str.each_char do |ch| # 1文字ずつ処理する
ch.match( re_hira ){ |md| puts "平仮名 : #{ md[ 0 ] }" }
ch.match( re_kata ){ |md| puts "カタカナ : #{ md[ 0 ] }" }
ch.match( re_han ){ |md| puts "漢字 : #{ md[ 0 ] }" }
end
出力
平仮名 : あ
平仮名 : い
漢字 : 善
漢字 : 悪
カタカナ : カ
カタカナ : キ
漢字 : 愛
平仮名 : う
カタカナ : ク
- 407 ：デフォルトの名無しさん：2020/12/09(水) 18:21:03.27 ID:L/x3uoyo.net
- C++かC#でお願いします
- 408 ：401：2020/12/09(水) 18:56:51.76 ID:y7KEYUhD.net
- 鬼雲を、C++, C# など、他言語から使えないのか？
- 409 ：デフォルトの名無しさん：2020/12/09(水) 19:27:16.18 ID:jODQKuwy.net
- 高性能高速ライブラリがあるのに、
なぜわざわざ、
低性能低速言語Rubyの、
低性能低速libraryを使う必要が、
あるんだ？、
- 410 ：デフォルトの名無しさん：2020/12/09(水) 19:45:05.56 ID:ZEWfqGU4.net
- C/C++は生産性が低いから
- 411 ：401：2020/12/09(水) 19:59:27.39 ID:y7KEYUhD.net
- 鬼雲は、C じゃないの？
https://github.com/k-takata/Onigmo
- 412 ：デフォルトの名無しさん：2020/12/10(木) 07:33:03.31 ID:KWX3PjQ+.net
- >>406
ruby を全然しらんのだが、 each_char ってのはどういう単位で文字を切り出してくるの?
上であったがサロゲートとか、絵文字とか、そのあたり特に。
Hanというプロパティは日本に限らず中国や韓国のも全部入り?
- 413 ：デフォルトの名無しさん：2020/12/10(木) 08:02:18.65 ID:oexX+ZIk.net
- >>407
グダグダいってるうちにスクラッチで車輪の再発明実装が終わる頃だな。
iskanjiはテーブル使うしかないかね？JISコードに変換して昔ながらの判定
するにもJISコード変換にテーブル
使うことになるだろうし。
どこかのページに色分けして中国専用の漢字の混ざり具合見せてたけどエグいねｗ
- 414 ：デフォルトの名無しさん：2020/12/10(木) 10:34:51.08 ID:RjOF8qIo.net
- 謎のタイ語判定コード , Javascript 版
strThai = "\u0e01\u0e51\u0e3f ทำงาน";
re = strThai.match(/([\u0E00-\u0E7F])+/g);
console.log( re );
参考ページ等
http://www.asahi-net.or.jp/~ax2s-kmtn/ref/unicode/u0e00.html
https://0g0.org/category/0E00-0E7F/1/
サロゲートペアを考慮しなくて良い言語はこのパターンでオーケーかな？
- 415 ：401：2020/12/10(木) 12:43:53.30 ID:HstTQkWC.net
- >>412
Ruby の1文字は、バイトサイズと異なる
str = "👪θ💀Ω🄫"
p str.encoding #=> <Encoding:UTF-8>
str.each_char do |ch| # 1文字ずつ処理する
puts "#{ ch } : #{ ch.size }, #{ ch.bytesize }"
end
出力
👪 : 1, 4
θ : 1, 2
💀 : 1, 4
Ω : 1, 2
🄫 : 1, 4
- 416 ：401：2020/12/10(木) 12:51:25.91 ID:HstTQkWC.net
- >>412
Han の範囲が気になるなら
>>411
の鬼雲のサイトか
>>406
の、str = 'Aあい善悪カキ愛うクx'
に、調べたい文字列を書いて、paiza などで実行してみれば？
- 417 ：デフォルトの名無しさん：2020/12/10(木) 20:31:09.89 ID:CcbWokCZ.net
- >>415
おお、すごい!
早速ローカルで試してみた... スキントーンがいけてなかった。おしい。
str = "👨🏻🦲"
p str.encoding #=> <Encoding:UTF-8>
str.each_char do |ch| # 1文字ずつ処理する
puts "#{ ch } : #{ ch.size }, #{ ch.bytesize }"
end
出力
👨 : 1, 4
;🏻 : 1, 4
; : 1, 3
🦲 : 1, 4
ハゲが直った! みたいなw
- 418 ：デフォルトの名無しさん：2020/12/10(木) 20:34:43.12 ID:CcbWokCZ.net
- あ、出力が微妙に違うかも。5chブラウザにペーストしたせいかも。
あともしかしてスキントーンはあえて別キャラ扱いとか?
- 419 ：デフォルトの名無しさん：2020/12/10(木) 21:25:24.00 ID:YXjbRyJb.net
- オレオレ用語UZEEE!!
- 420 ：デフォルトの名無しさん：2020/12/11(金) 06:34:28.41 ID:5L91jtkU.net
- ん、何か変なこと書いてある?
しかし書き込む瞬間、絵文字が5chブラウザでちゃんと表示できるかちょっと不安に
なったが、一応いけるみたいね。少なくともオレオレ環境では。
5ch側はSJIS＋数値参照を流しているだけかもしれんが。
- 421 ：デフォルトの名無しさん：2020/12/14(月) 05:58:38.59 ID:uAdA9GXf.net
- 機械学習関係とかで使う奴です。
なんとなく出来たので晒しときますね。
// PHP(UTF-8) での全角カタカナチェック(JISx0213網羅版)
$sKana = ''
. "カ\xE3\x82\x99" // 304B+3099 カに濁点 (Mac,NFD)
. "カ\xE3\x82\x9A" // 304B+309A カに半濁点(JISのセット文字の半濁点 or Mac,NFD 半濁点)
. "゛" // 309B 濁点 (主にWin,半カナから変換される奴？)
. "゜" // 309C 半濁点 (主にWin,同上)
. "ァアィイゥウェエォオカガキギクグケゲコゴサザシジスズセゼソゾタダチヂッツヅテデトドナニヌネノハバパヒビピフブプヘベペホボポ"
. "マミムメモャヤュユョヨラリルレヮワヲン"
. "ヴヵヶヰヱ・ーヽヾ"
. "\xE3\x82\xA0" // ダブルハイフン , 30A0
. "\xE3\x83\xB7" // ワに濁点
. "\xE3\x83\xB8" // ヰに濁点
. "\xE3\x83\xB9" // ヱに濁点
. "\xE3\x83\xBA" // ヲに濁点
;
if( 1 === preg_match("/^[\x{3099}-\x{309C}\x{30A0}-ヾ]+$/u",$sKana) )
{
echo "全てカナカナです。";
}
else
{
echo " NG";
}
- 422 ：デフォルトの名無しさん：2020/12/14(月) 09:18:41.31 ID:dIR87NiF.net
- 0x31F0-F9のアイヌ語カナ拡張が抜けてるような
- 423 ：デフォルトの名無しさん：2020/12/14(月) 12:36:10.35 ID:uAdA9GXf.net
- >>422
どんな文字か全く見てませんけど、コードが分かれば並べていくだけですね。
アイヌ語カナ拡張版？差し替え用ってことで。
"/^[\x{3099}-\x{309C}\x{30A0}-ヾ\x{31F0}-\x{31F9}]+$/u"
- 424 ：デフォルトの名無しさん：2020/12/15(火) 07:45:42.06 ID:mpgmHFbH.net
- Flag for Tokyo て何だよ
https://emojipedia.org/flag-for-tokyo-jp13/
- 425 ：デフォルトの名無しさん：2020/12/15(火) 12:56:15.02 ID:vE8VpXlG.net
- 日本＋都道府県番号?
- 426 ：デフォルトの名無しさん：2020/12/15(火) 13:41:07.26 ID:OZzZpMYk.net
- >>424
市役所とか行ったことないのか？
- 427 ：デフォルトの名無しさん：2020/12/15(火) 17:27:11.75 ID:+Yh7x7Wy.net
- ISO 3166-2:JP
- 428 ：デフォルトの名無しさん：2020/12/15(火) 18:17:13.23 ID:Y7kqruGs.net
- 問題は東京みたいに旗が2種類あるところ
東京は歴史ある＊みたいなほうになるのか銀杏の葉っぱみたいなほうになるのか
- 429 ：デフォルトの名無しさん：2020/12/22(火) 20:48:11.38 ID:hjkCLTVe.net
- ISO - ISO/IEC 10646:2020 - Information technology — Universal coded character set (UCS)
https://www.iso.org/standard/76835.html
2020年の内に完成した模様
ABSTRACTのとこが何か文字化けしてるけど。
- 430 ：デフォルトの名無しさん：2020/12/23(水) 00:48:02.18 ID:r3ldn4Uo.net
- 何に時間がかかるの
- 431 ：デフォルトの名無しさん：2020/12/23(水) 14:15:22.80 ID:dwGREUpD.net
- ここでも行けるかな？ 𝐁𝐨𝐥𝐝 𝐼𝑡𝑎𝑖𝑐 𝒮𝒸𝓇𝒾𝓅𝓉 𝔻𝕠𝕦𝕓𝕝𝕖 𝖲𝖺𝗇𝗌𝖾𝗋𝗂𝖿 𝙼𝚘𝚗𝚘𝚂𝚙𝚊𝚜𝚞
- 432 ：デフォルトの名無しさん：2020/12/23(水) 16:04:04.77 ID:Yot4/iGO.net
- ��������������������
- 433 ：デフォルトの名無しさん：2020/12/23(水) 18:21:51.29 ID:dwGREUpD.net
- コード表一列読み間違えて16ズレた。
何かローマ字みたいになってるけど偶然。
- 434 ：デフォルトの名無しさん：2020/12/23(水) 20:48:10.24 ID:nit2qqbj.net
- SNSのアカウント名でこういう文字使ってる人いるよねえ
特に詳しそうには見えない人が多いが簡単入力できるツールかサイトがあるんだろうかね
- 435 ：デフォルトの名無しさん：2020/12/24(木) 08:15:43.26 ID:EahE3vDH.net
- テスト
🅿🅴🅽 🅿🅸🅽🅴🅰🅿🅿🅻🅴 🅰🅿🅿🅻🅴 🅿🅴🅽
- 436 ：デフォルトの名無しさん：2020/12/24(木) 13:14:04.00 ID:Tf2UBq9W.net
- ���������� ℤ
- 437 ：デフォルトの名無しさん：2020/12/24(木) 14:37:35.38 ID:LJDzLTFM.net
- 何だろう? 専ブラだと全部読めるけど Firefox だと読めたり読めなかったりする。
431 と 435 は Firefox でも読める。432は読めない。436 は Z だけ読める。
🄟⒜⒭⒠⒩⒯⒣⒠⒮⒤⒵⒠⒟
Ⓒⓘⓡⓒⓛⓔⓓ
🅂🅀🅄🄰🅁🄴🄳
🅝🅔🅖🅐🅣🅘🅥🅔 🅒🅘🅡🅒🅛🅔🅓
🅽🅴🆃🅰🅶🅸🆅🅴 🆂🆀🆄🅰🆁🅴🅳
- 438 ：デフォルトの名無しさん：2020/12/24(木) 14:50:54.98 ID:LJDzLTFM.net
- わかったサロゲートが原因だな。
BMP 以外の文字を ＆＃XXXXX; 形式で投げる時に、なぜかサロゲート分解して2文字にして投げてるクライアントがいるな。
内部でいったん UTF-16 に変換すれば復元できるけど、内部がUTF32やUTF8だと未定文字になる。
- 439 ：デフォルトの名無しさん：2020/12/25(金) 12:51:47.65 ID:qJluI3Ne.net
- 同じ専ブラでも端末が変わると読めなくなるみたいだけど
- 440 ：デフォルトの名無しさん：2020/12/25(金) 14:23:41.08 ID:wLkIv5a0.net
- そりゃフォントが違うから
- 441 ：デフォルトの名無しさん：2020/12/25(金) 21:14:44.85 ID:xu2VH6Eq.net
- フォントに？
- 442 ：デフォルトの名無しさん：2020/12/31(木) 06:07:50.70 ID:YZyBnRB+.net
- ㍾ → ㍽ → ㍼ → ㍻ のパターンでさりげなく令和が増えていて驚いた。
㋿ U+32ff
- 443 ：デフォルトの名無しさん：2020/12/31(木) 06:20:27.61 ID:rUTWKsHs.net
- あれほど騒ぎになったのに今更かよｗ
- 444 ：デフォルトの名無しさん：2020/12/31(木) 06:48:08.64 ID:YZyBnRB+.net
- >>443
いや、正確に言うと、自分の使ってるPCでその㋿が表示されることに驚いたのね。
買った直後だけアプデしてその後ずっとアプデしないようにしてたから。
アプデしてないアイポン６で表示されてないのを見てちょっと安心しました。
- 445 ：デフォルトの名無しさん：2020/12/31(木) 06:51:45.99 ID:YZyBnRB+.net
- 丸付きにも四角付きにも 音・訓・外 が無くて悲しい。
ということで以下は、ブラウザやアイポンでの表示チェックです。
音：㋔ Ⓒ㋾ⓞ
訓：㋗ Ⓙⓙ🅹🄹ⓝ
外：▲ ⓖⒼ
中：㊥ 厨Ⓒ
訓読みは Ⓚ という文字を使いたいくないので 字訓を元にしたⒿとか 大和言葉（和語）を基にする方がいいなぁ。
音読みは中国由来のⒸの方が㋔よりもいいかもしれない。
外字は小中学生や外人さんにはあまり使わない文字なので▲で良いと思う。
丸付きの ガ があればそれで決まりだったんだけどいろいろ揃って無いよなぁ。
で、辞書で出てくる 中 ってなんの意味か知ってる人が居たら教えてください。
なんとなく中国史で使うっていうような意味っぽいけど。あるいは中学で覚えるとか？
- 446 ：デフォルトの名無しさん：2020/12/31(木) 07:36:55.69 ID:YZyBnRB+.net
- >>445
自己レスです。
中は中学で学習する音訓と漢字ペディアに出てました。
ちなみに高というのもあって高校で習うそうです。
- 447 ：デフォルトの名無しさん：2020/12/31(木) 20:58:20.96 ID:DjLZ71J5.net
- サロゲートペアは本当に厄介者
- 448 ：デフォルトの名無しさん：2020/12/31(木) 21:04:25.88 ID:2bA0HVQw.net
- 結合文字「サロゲートペア程度にやられてるのか？」
異体字セレクタ「奴はUnicode四天王の中でも最弱」
？？？？「サロゲートペアごときに負けるとはプログラマの面汚しよ…」
- 449 ：デフォルトの名無しさん：2020/12/31(木) 23:29:53.71 ID:AP5qdpgj.net
- 混沌を極めるUNICODE界…
もう一回いちから(別案で)やり直す可能性ってあるのかな
- 450 ：デフォルトの名無しさん：2021/01/01(金) 02:12:50.76 ID:YAS452Oz.net
- ないよ
というか仕切り直したところで今のUnicodeは内包されるに決まってるからメリットがないよ
- 451 ：デフォルトの名無しさん：2021/01/01(金) 08:19:29.86 ID:u/6kYyhd.net
- BMPに還るのがいい
- 452 ：デフォルトの名無しさん：2021/01/01(金) 22:27:30.90 ID:rsUPFffA.net
- あけましておめでとうございます
Unicode 14.0.0の発表が9月に延期になって寂しい
- 453 ：デフォルトの名無しさん：2021/01/02(土) 00:20:21.99 ID:3z5SV0Cg.net
- 有名所の13対応のフリーのフォントてもう出てましたっけ?
- 454 ：デフォルトの名無しさん：2021/01/02(土) 09:08:13.69 ID:peE3gLXE.net
- あけおめ。
サロゲートペア対応の漢字のみ収集コード JavaScript版、
𪗱𪘂𪘚 の３つがサロゲートペアかな？ 読めなくてアレですが。
お隣の文字はちゃんと省いてる、使えば大願成就間違いなしの縁起物？バージョンです
絵文字も省いていたような気がするけどなんかいろいろ忘れてますね。
re = "abcd齆あ齓齕齘ab𪗱齝𪘂齩𪘚々齭てすと".match(/([\uD840-\uD869][\uDC00-\uDFFF]|[々〇\u303B\u3400-\u9FFF\uF900-\uFAFF])+/g);
console.log( re );
- 455 ：デフォルトの名無しさん：2021/01/02(土) 16:52:42.20 ID:c+PMhAgd.net
- >>450
まじかー
もう128bitくらい使って宇宙文字にも耐えられるようにすればいいのに
これが本当の異星体なんつって
- 456 ：デフォルトの名無しさん：2021/01/02(土) 21:50:17.89 ID:NzxSghB6.net
- GUIライブラリTkはいまだにサロゲートペアに対応しておらず絵文字を使えない。
- 457 ：デフォルトの名無しさん：2021/01/03(日) 14:22:31.22 ID:uzdBwonC.net
- ここもunicode=changeな板が多すぎてな
このオプション消滅せんかな
- 458 ：デフォルトの名無しさん：2021/01/05(火) 12:09:35.45 ID:G8BimKKu.net
- 5chもほぼSJIS専用やんけ
- 459 ：デフォルトの名無しさん：2021/01/05(火) 18:11:40.31 ID:F/xhjvIl.net
- >>458
なんだかんだSJISのままで存続できてるよね。
文字参照が使えればベースのエンコーディングは案外何でもいいのかな、
とか思ったり思わなかったり。
- 460 ：デフォルトの名無しさん：2021/01/05(火) 21:01:08.07 ID:Xkz87/Po.net
- たまにスレタイで絵文字入ってるのあるけど
あれも文字参照で入力してるのかな
- 461 ：デフォルトの名無しさん：2021/01/05(火) 21:11:16.54 ID:TUUmcJJM.net
- https://twitter.com/MarkusGerstel/status/1343249726456606720
UK/EU trade agreement redefines ASCII character 123 to be 3 characters, and ASCII 125 to be 2 characters.
But I'm sure the legal bits are fine and need no scrutiny whatsoever.
(deleted an unsolicited ad)
- 462 ：デフォルトの名無しさん：2021/01/05(火) 21:12:01.50 ID:TUUmcJJM.net
- https://pbs.twimg.com/media/EqQuVm0W4AAAxfv.png
- 463 ：デフォルトの名無しさん：2021/01/06(水) 09:23:40.34 ID:nouQm06h.net
- 絵文字テスト （↓の＆と￥は全角）
Growing star 🌟 , ＆#x1f31f; , ＆#127775; , ￥u{1f31f}
SJIS環境だとサロゲートペアはエラーになるんじゃね？
ウニコードベースのエディタへの移行に失敗というか断念して
未だにSJISベースのテキストエディタをメインに使ってる俺が言ってみたり。
そう言えばサクラエディタのマクロフルセット？サポート版てどこでダウンロードするのが良いのだろう？
- 464 ：デフォルトの名無しさん：2021/01/06(水) 18:53:39.44 ID:BIuq+YWk.net
- あ、Chromeって検索のとき全角半角を区別しないのか。今知ったw
っていうかそもそも大文字小文字も区別しないのか。へー。
でもこの手の正規化を無効にするオプションもないようだしちょっと不便。
- 465 ：デフォルトの名無しさん：2021/01/06(水) 19:42:47.04 ID:evtp6HPL.net
- chromeの検索の同一視はなんか怪しいというか独自テーブルかな
- 466 ：デフォルトの名無しさん：2021/01/07(木) 00:30:30.04 ID:RA5aGs7i.net
- 最近は知らないが昔のFirefoxは全角半角同一視してくれなくて大変困った
- 467 ：デフォルトの名無しさん：2021/01/07(木) 01:59:00.08 ID:HEGtY6UH.net
- >>459
海外からの荒らし対策になっているのでは
SJISは国内だけの希少コード
- 468 ：デフォルトの名無しさん：2021/01/07(木) 02:00:13.67 ID:o03LMIA7.net
- >>466
今でもFirefoxは全角半角を無視「しない」ように見えるけど?
いつだかダイアクリティカルを無視するというので問題になったけど。
- 469 ：デフォルトの名無しさん：2021/01/10(日) 18:48:17.35 ID:akopncMr.net
- >>449
別に一から作り直せとは言わんけど明らかにミス、バグだろって箇所は直してくれ
有名なのだと U+29FCE と U+29FD7 とか
- 470 ：デフォルトの名無しさん：2021/01/10(日) 20:04:42.25 ID:/+cMzhpZ.net
- やるとしてJSoueceの方をobsoleteされるんだろw
- 471 ：デフォルトの名無しさん：2021/01/20(水) 22:49:15.22 ID:Eoi5GIMM.net
- テキストエディターが改行コードを間違って解釈しないように
BOMの機能を拡張して改行コードの種類も表せるようにしたらどうなんだろう
- 472 ：デフォルトの名無しさん：2021/01/21(木) 00:18:54.31 ID:Nk7WM/aM.net
- 来月からUnicode 14に向けた準備が始まるそうだけど
WG2側でまったく投票が出来ていない状態でそんなことして大丈夫なのか
- 473 ：デフォルトの名無しさん：2021/01/21(木) 12:01:56.27 ID:uTJ86sk/.net
- 改行コード間違うのってたいてい改行コードが混在してるのが原因じゃないの？
- 474 ：342：2021/01/21(木) 17:12:51.59 ID:zM0oz2u8.net
- >>471
一行目の改行コードで充分では？
- 475 ：デフォルトの名無しさん：2021/01/22(金) 23:50:53.67 ID:SkpJ9szj.net
- eメールは8bitの文字を7bitに変換して送るのが一般的だけど
今でも7bitしか扱えないメールサーバーってあるんだろうか
- 476 ：デフォルトの名無しさん：2021/01/25(月) 20:49:52.31 ID:r2WhSNc4.net
- 前に件名を=?ISO-2022-JP?B?の形式でエンコードせずに直接ShiftJISを書きこみ
本文もMIMEを使わずにShiftJISをそのまま書いたメールを送ってみたが文字化けもせずに届いたから
7bitまでしか送れないのは昔の話なんじゃないかと
- 477 ：デフォルトの名無しさん：2021/01/25(月) 20:59:52.42 ID:nPU6SWGR.net
- 8bitを化けさせるようなメールサーバーが今でも存在するのかという質問であって、お前の化けなかった経験は何の解答にもなってない。
- 478 ：デフォルトの名無しさん：2021/01/25(月) 22:50:52.28 ID:dmbNtT1m.net
- そりゃあ、存在しないという解答は解答にならなくて存在しているという解答だけが解答になるわけだ。
- 479 ：デフォルトの名無しさん：2021/01/26(火) 00:14:38.98 ID:c6DHU6bT.net
- 現れないのが透明人間です
みたいな話
- 480 ：デフォルトの名無しさん：2021/01/29(金) 22:30:48.89 ID:SgmI7msw.net
- 規格上はオプションではあるがSMTP POP3 IMAP4全てでUTF-8をそのまま送受信できるから
8bitデータをそのまま送受信できるならBase64やquoted-printableも必要なくなるのかな
- 481 ：デフォルトの名無しさん：2021/01/30(土) 00:20:35.73 ID:nT2XTKgy.net
- >>480
一部の構造化されたヘッダは8ビット禁止なので、全部はなくせないかな。
- 482 ：デフォルトの名無しさん：2021/01/30(土) 01:48:16.96 ID:i+4/kULN.net
- 先賢の方々が何処かの頃合いで8bitクリーンに作り直しておいてくれればなぁ
- 483 ：デフォルトの名無しさん：2021/01/30(土) 04:51:50.38 ID:yJsdZMSi.net
- 問題になるのはTAB,SP,BS,ESC,DELとかの制御コードなのでBase64等は必須でしょうね
行頭の'.'も気にしなくて良くなる
- 484 ：デフォルトの名無しさん：2021/02/01(月) 15:56:04.61 ID:2wWFCs7L.net
- どうしてメールは7bitが基本になったんだろうね
少しでもデータ量を減らすためなのか
8bit目をパリティとして使う機種の名残りなのか
- 485 ：デフォルトの名無しさん：2021/02/01(月) 19:54:24.08 ID:daMBxrCa.net
- もともとインターネットでメールがやり取りされるようになる以前から
学内ネット、社内ネット、UUCPネットワークなどの個別メール網があって、
それをインターネットで相互接続したのが始まりなので、
最小公倍数的に全てを通過できる7ビットが要件になった。
- 486 ：デフォルトの名無しさん：2021/02/01(月) 19:58:08.39 ID:B8SI3YQR.net
- SMTPが出来たは40年ちかく昔だからなあ
Unicodeなんてまだ影も形もない時代
日本人ですら漢字をシフトしない7bitで表現してたくらいなのに
メールだけわざわざ8bitを基本にするような発想が出てくるわけがないだろう
- 487 ：デフォルトの名無しさん：2021/02/01(月) 21:54:37.95 ID:A78/KaWg.net
- コマンド以外は全て8bitのバイナリデータとして扱ってエンコードしないで
相手にそのまま送れるのが理想的なんだろうね
シェアの大きいMTA/MUAがRFCを無視してそんな実装にしたら
意外とそれがデファクトスタンダードになったりするかもしれない
- 488 ：：2021/02/01(月) 22:00:08.44 ID:o0ZguV06.net
- >>484
>8bit目をパリティとして使う
でしょうね、欧米はそれで足りるから
- 489 ：デフォルトの名無しさん：2021/02/02(火) 00:59:48.46 ID:ecf2UzG0.net
- binarymimeって使われてないの？
- 490 ：デフォルトの名無しさん：2021/02/02(火) 13:36:00.69 ID:8YNA1BPy.net
- >>486
>日本人ですら漢字をシフトしない7bitで表現してたくらいなのに
シフトするJISはあったでしょ
- 491 ：デフォルトの名無しさん：2021/02/03(水) 21:38:48.49 ID:nNuCDyZ2.net
- 記号以外のASCII文字はエンコード後も変化しないという意味でUTF-8を7bitにエンコードするなら
quoted printableがbase64より合っていると思うんだけど
メールでのUTF-8の普及に合わせてquoted printableも普及しないかな
- 492 ：デフォルトの名無しさん：2021/02/03(水) 22:02:22.02 ID:PgvsD/XS.net
- そういえばUTF7なんてのもあったね
どこで使ってたんだろう？と思ってググったらIMAP4とかだと2010年前後でも当たり前に使われていたらしい
メールはかなり最近まで（今も？）7bitを大事にする文化みたいだね
- 493 ：デフォルトの名無しさん：2021/02/03(水) 22:21:53.66 ID:WEk0ntun.net
- 本当はもう無いのに「読めないぞ」というクレームが怖くて残ってるんじゃ。
残ってても、そもそもそんなところに8bitのメールは送られないような。
- 494 ：デフォルトの名無しさん：2021/02/04(木) 01:36:54.71 ID:JoFJnM0w.net
- 今現在のメールの良さって汎用性・後方互換性に尽きるからなあ
- 495 ：デフォルトの名無しさん：2021/02/04(木) 18:23:08.62 ID:ez+Z5Z3J.net
- https://www.janog.gr.jp/meeting/janog31/resume/janog31-i18nmail-fujiwara-01.pdf#page=10
この形式でメールを送れるメールソフトがどのくらいあるのか分からないけど
今はこの形式でメールを送って、問題が出たら従来の形式で送るというくらいでもいいんじゃないの
- 496 ：デフォルトの名無しさん：2021/02/08(月) 21:58:11.42 ID:dRtPTDkz.net
- UTF-16がunicodeをややこしくさせる原因になってるよね
unicodeのコードポイントがU+7FFFFFFFからU+10FFFFまでに制限されたのも
サロゲートペアも考慮しないといけない所もUTF-16のせいなんだし
- 497 ：デフォルトの名無しさん：2021/02/12(金) 05:28:51.22 ID:iQJLsSxS.net
- 麻雀牌が全部登録されたのに🀄だけ先行だから見た目が違うのどうにかならんのか…
- 498 ：デフォルトの名無しさん：2021/02/12(金) 08:42:44.00 ID:9pKWi6uS.net
- フォント次第だろ
- 499 ：デフォルトの名無しさん：2021/02/12(金) 08:54:47.22 ID:nGt16DhZ.net
- >>498
大抵のフォントでも🀄だけは違うよ
- 500 ：デフォルトの名無しさん：2021/02/12(金) 14:05:54.17 ID:dwh87PNV.net
- Ninja Catは新たな機種依存文字といえるだろうか
- 501 ：デフォルトの名無しさん：2021/02/12(金) 16:22:53.75 ID:Dgq2mig/.net
- >>496
というかそれはUnicodeの歴史とむすびついてるわけだし。
当初16ビットでということでWindowsやMacがそれを採用、しかしリリース後に16ビット
では足りないことが判明。もうその時点ではサロゲートペア的なものでどうにかする
のは仕方ないかも。
というわけでややこしいのはUnicodeそのものw
- 502 ：デフォルトの名無しさん：2021/02/12(金) 23:39:41.89 ID:2MB5qean.net
- ♡
💙
- 503 ：デフォルトの名無しさん：2021/02/12(金) 23:59:30.90 ID:dwh87PNV.net
- 16ビットで足りない事が判明した時点でUTF-32に移行できればよかったんだけど
未だにUTF-32に対応したソフトは少ないんだよね
- 504 ：デフォルトの名無しさん：2021/02/13(土) 06:00:35.89 ID:neaggcXJ.net
- 理論上は、UTF-32でも足りない。無限に増えるユニコード表に対応するには、UTF-32にもサロゲートが必要。
- 505 ：デフォルトの名無しさん：2021/02/13(土) 06:02:18.96 ID:xr59QL32.net
- 歯磨き粉買ってくる
- 506 ：デフォルトの名無しさん：2021/02/13(土) 09:04:37.07 ID:+Dfn0XQq.net
- 無限に増える理屈を詳しく
- 507 ：デフォルトの名無しさん：2021/02/13(土) 10:43:02.72 ID:Xo6k9nK0.net
- 宇宙文明
- 508 ：デフォルトの名無しさん：2021/02/13(土) 11:01:30.65 ID:neaggcXJ.net
- ぼくのかんがえたさいきょうの文字が追加されても耐えられる仕様でなければならぬ。
よしんば絵文字の可能性は無限。
- 509 ：デフォルトの名無しさん：2021/02/14(日) 11:44:24.49 ID:PGTjJwEI.net
- 🐼🐼🍞🍞🐼🍞🐼
- 510 ：デフォルトの名無しさん：2021/02/14(日) 23:59:32.09 ID:u9kxNS7O.net
- >>497-499
同じ種類の文字なのに一部だけ先行して登録されて
他の文字は後から全く違うポイントに登録されている物もあるから
フォントだけで済んでるならまだマシじゃないかと
- 511 ：デフォルトの名無しさん：2021/02/15(月) 03:09:13.69 ID:N3rul/OC.net
- >>510
いや🀄だけ違うのはちょっとモヤるんだよなぁ
unicodeに送ろうと思ったら有料会員じゃないとだめだったorz
- 512 ：デフォルトの名無しさん：2021/02/15(月) 16:03:14.56 ID:0+vI5H2L.net
- unicode に送っても仕方ないやろ
フォントメーカーに送れ。
内蔵フォントなら機器メーカーに送れ。
- 513 ：デフォルトの名無しさん：2021/02/15(月) 16:39:10.57 ID:G46IYPHn.net
- 何送り付けるつもりなの
- 514 ：デフォルトの名無しさん：2021/02/15(月) 17:18:57.69 ID:ugNMmOOo.net
- ヷヸヹヺセ゚ツ゚ト゚の合字ではない平仮名は無いんだよな
「ゔ」を入れたのなら他の文字も平仮名版を入れればいいのに
- 515 ：デフォルトの名無しさん：2021/02/15(月) 20:05:59.00 ID:/z22KH1R.net
- ユニコードはウィルスなので送らないでください。
- 516 ：デフォルトの名無しさん：2021/02/16(火) 08:25:02.10 ID:mevxUua1.net
- >>512
Unicodeで決まってるんじゃなくて？
- 517 ：デフォルトの名無しさん：2021/02/16(火) 09:08:45.11 ID:3D5+Vdqo.net
- >>516
図柄を決めてるのはフォント屋。
Unicode的にはコードポイントが離れてても同じような図柄にすることを想定してるけど、フォントがそうなってないだけ。
- 518 ：デフォルトの名無しさん：2021/02/16(火) 16:32:28.02 ID:maqlUdeY.net
- 文字のバイト数が可変長のコードを作れば、弱い暗号に使えないのかな
１，２，３，４バイト不規則に混在、たまに７バイトや１０バイトも混ざる
- 519 ：デフォルトの名無しさん：2021/02/16(火) 17:46:12.13 ID:X0P7Oy5W.net
- もしかしてutf-8？
- 520 ：デフォルトの名無しさん：2021/02/16(火) 20:48:18.23 ID:qlfoq285.net
- >>496
UTF-8の4バイトに合わせてU+1FFFFFまでにしてくれればよかったのにとはちょっと思った。
- 521 ：デフォルトの名無しさん：2021/02/16(火) 21:51:25.16 ID:ABVOYRZa.net
- 可変長の究極は1文字ごとに
文字の切れ目を表すためのエスケープ文字とunicodeの登録名（HIRAGANA LETTER Aなど）
をテキストファイルに記録する事かもね。
コードポイントの概念を無くして16進数の番号で管理しないから
後から追加された文字でもコードポイントが飛んでいる事はなくなるし。
ただし文字によっては1文字に50バイト以上使うこともある。
- 522 ：デフォルトの名無しさん：2021/02/16(火) 23:05:15.94 ID:ZcpmZlC/.net
- >496
Unicodeの当初の16bit（最大65536文字）あれば
十分だろうという考えがそもそもの原因なんだから
UnicodeをややこしくさせてるのはUnicode自身だよ
最初の段階で16bitで足りないと認めていれば
今頃はUTF-32が主流になっていただろう
もっともUnixは互換性のためにUTF-32をネイティブで扱うのが
難しいのでUTF-8は生まれていたかもしれないがね
- 523 ：デフォルトの名無しさん：2021/02/17(水) 01:57:41.63 ID:1VpGhFke.net
- 枻（木へんに世）って、シフトJIS（のバリエーション）的にはどうなんだっけ。
というかこれ自体もテストだったり。
- 524 ：デフォルトの名無しさん：2021/02/17(水) 02:17:54.79 ID:1VpGhFke.net
- ちなみに自分はMacなんだが、0xFAE2を書き込んだ模様。
皆さんには見えてますでしょうか。
HTMLでcharset=Shift_JISのときってどうするのか揉めた記憶が。
- 525 ：デフォルトの名無しさん：2021/02/17(水) 02:44:16.94 ID:PIB5BTik.net
- ５ちゃんねるの仕様は文字コードと何の関係もない
- 526 ：デフォルトの名無しさん：2021/02/17(水) 03:22:07.19 ID:edB0ww9C.net
- っ https://encoding.spec.whatwg.org/shift_jis.html
今のブラウザはこの辺に従ってるで終了じゃねの?
- 527 ：デフォルトの名無しさん：2021/02/17(水) 08:12:07.90 ID:peDNmUYI.net
- >>525
5chをブラウザで見るとHTMLがcharset=Shift_JISなんだけど、それは関係ないってこと?
そもそもテキストデータのやり取りで文字コードの指定がない仕様というのは... もしかして
適当にデータを送受信して適当な文字コードを指定して見れたらラッキー、的な仕様?
そもそも5chの仕様ってどこかにあるんでしょうか。
- 528 ：デフォルトの名無しさん：2021/02/17(水) 09:42:15.24 ID:ty0uudwM.net
- やれやれ頭が固いなｗ
SJISでUnicodeが表示できないと思いこんでる
- 529 ：デフォルトの名無しさん：2021/02/17(水) 18:28:41.76 ID:8Df3qLX7.net
- もりおうがいしかる
森鷗外𠮟る
森鴎外叱る
- 530 ：デフォルトの名無しさん：2021/02/17(水) 19:54:41.88 ID:NZXazeNu.net
- 森鳩ﾀﾄﾛﾋる
- 531 ：デフォルトの名無しさん：2021/02/17(水) 20:00:49.86 ID:SpPvhnPe.net
- >>521
そこまで行くと文字コードというか最早マーク付け言語みたいだな
てかHTML (SGML/XML)の文字実体参照まんまでは
- 532 ：デフォルトの名無しさん：2021/02/17(水) 22:24:44.47 ID:gjncEnw2.net
- sjis には、Windows CP932 特有の環境依存文字がある
それで、バグルか、フォントが無いとか
- 533 ：デフォルトの名無しさん：2021/02/18(木) 00:08:48.51 ID:QtoO1FYc.net
- >>523-524
世に出てるブラウザの殆どはcharset=Shift_JISな文書をWindows-31Jとして解釈するだろうから
IBM拡張文字として表示されるんでない？
というか、何を疑問に感じてのレスなのかが分からないんだけど。
- 534 ：デフォルトの名無しさん：2021/02/18(木) 10:20:55.82 ID:64/LOwh9.net
- 不知佛
- 535 ：デフォルトの名無しさん：2021/02/18(木) 16:35:44.79 ID:SMktdrdB.net
- >>533
>charset=Shift_JISな文書をWindows-31Jとして解釈するだろうから
まさにそこ。本来はこの両者は違うから、正しく解釈すれば文字化けする。
しかし事情を知らないユーザーから見たら、文字化けするソフトウェアの方が劣ると
思われそうで悔しいw
そもそもShit_JISとWindows-31Jをごちゃ混ぜにして大量に垂れ流したWindowsのプラット
フォームないしユーザーに責任があると言えるが、それに迎合しないといけないのがw
- 536 ：デフォルトの名無しさん：2021/02/18(木) 17:36:53.61 ID:qR1rH4Mn.net
- >>535
なんでもかんでもWindowsのせいにするな
もともとSJISはMicrosoftがメインで策定したもので
その仕様はMicrosoftが一番知ってる
Microsoftが想定外だったのは、拡張性を持たせるための領域を
NECやIBMが拡張しまくってSJISとして広めてしまったことにある
ごちゃまぜにしたのはNECやIBMにすぎない
Microsoftはそれじゃデータの相互運用に困るから
Windowsでそれらを統合しただけ
MicrosoftのおかげでSJISはほぼ統一されたんだよ
例外は互換性がない形でSJISを確証したMacJapaneseだけ
Appleは独自拡張のうえ既存のSJISを無視して同じ領域に
別の文字を割り当てやがったアホ
- 537 ：デフォルトの名無しさん：2021/02/18(木) 18:09:37.01 ID:64/LOwh9.net
- Tower of Babel
- 538 ：デフォルトの名無しさん：2021/02/18(木) 18:54:47.31 ID:YbNTmpmE.net
- C言語の/r/nなどのエスケープシーケンスは制御文字に対するアルファベットの割り当てを
キャレット記法と同じにした方がよかったんじゃないかと思う
- 539 ：デフォルトの名無しさん：2021/02/18(木) 20:15:29.49 ID:qR1rH4Mn.net
- キャレットって^Cの^（CTRLという意味）のこと？
- 540 ：デフォルトの名無しさん：2021/02/18(木) 22:08:13.73 ID:UlBwu06v.net
- Ruby は、数十種類もの日本語の方言を変換できる。
方言同士の変換パスを作っている
最大6パスで変換できる方言もあるらしい
でも、今でも、NEC・ドコモ方言などを使うかどうか疑問
- 541 ：デフォルトの名無しさん：2021/02/18(木) 22:29:52.06 ID:YbNTmpmE.net
- >>539
例えばCRLFなら^M^JだからC言語でも\r\nではなく\m\jの方がよかったんじゃないかと
- 542 ：デフォルトの名無しさん：2021/02/18(木) 23:13:37.69 ID:oLKP0iIM.net
- あらゆる文字コードでCR=0x0D,LF=0x0Aだと本当に保証されているのか？
を考えてみれば答えが出るんじゃないかと
- 543 ：デフォルトの名無しさん：2021/02/19(金) 10:43:19.20 ID:KukrgKGP.net
- >>536
うむー確かに各ベンダーのせいはあるか。
しかし、このSJISの混乱があったにも関わらず、ガラケーでは各ベンダーが勝手な絵文字の
コードを割り当ててえらいことになりかけてたよね。
で今度はGoogleが中心になって事態を収拾した。
歴史は繰り返すってか。あるいは日本企業の変わらない体質?
- 544 ：デフォルトの名無しさん：2021/02/19(金) 11:24:24.47 ID:hDaaUxwq.net
- 最近はもうこんな感じのコードを必ず最初に入れるようにしてるなぁ。
$Text = preg_replace("/(\r\n|\r|\n)/" , "\n" , $Text );
- 545 ：デフォルトの名無しさん：2021/02/19(金) 21:20:37.86 ID:B4GlCKY0.net
- 絵文字はユーザーの利便性に直結する、最も重要な要素
絵文字でシェアが変わるから、他社よりも先に、魅力的な絵文字を作らないといけない。
Line は、絵文字・スタンプでシェアを不動のものにした
- 546 ：デフォルトの名無しさん：2021/02/19(金) 23:58:34.63 ID:vxkxW4Vf.net
- \nだとLFを指している場合と
CR単独、CRLF、LF単独に関係なく改行を指している場合の両方があって
ソフトによって違うから困る
前者と後者を区別できるようにしてほしいね
- 547 ：デフォルトの名無しさん：2021/02/20(土) 14:22:35.85 ID:MwzRkHxH.net
- 米アップル、注射器の絵文字を微調整 「血のしずく」を削除
https://www.cnn.co.jp/tech/35166607.html
- 548 ：デフォルトの名無しさん：2021/02/20(土) 16:11:25.88 ID:McCqWkok.net
- あきらめないで
- 549 ：デフォルトの名無しさん：2021/02/20(土) 20:02:11.54 ID:Rkd/h2tQ.net
- >>545
じゃあLineはどうしてるの、という疑問が。
探してみるととりあえず... https://developers.line.biz/media/messaging-api/emoji-list.pdf
これに関してはUnicodeの私用領域を使ってるみたいね。
確か絵文字が表示されないときに (laugh) みたいにちゃんと置き換わるやつがあった気が
するが... あれはHTML的なもの（か、そのもの）なのかな。
- 550 ：デフォルトの名無しさん：2021/02/20(土) 23:07:01.67 ID:reEV5cwz.net
- 調べてみると点字にも文字コードと同じ問題があるんだな
6bitだから仮名と数字とアルファベットを全て1文字で表せないから
数字とアルファベットはエスケープ文字を付けて対応しているし
漢点字だと8bitで可変長になっている
- 551 ：デフォルトの名無しさん：2021/02/21(日) 02:25:03.18 ID:SyjwfUNV.net
- >>550
そういえばUnicode上の点字はなぜか8個の点で例示してあり、実際256パターンある。
点字のUnucode化? 8bitで十分かは知らんけどw
でも8個以上は指で触って読むのが難しいかもしれない。
- 552 ：デフォルトの名無しさん：2021/02/21(日) 05:02:36.24 ID:x7XX42Aa.net
- >>546
\n は、LF だけど、
Python みたいに、global new line を設定すると、
CR単独・CRLF・LF単独と、OS によって改行コードを切り替える、言語がある
- 553 ：デフォルトの名無しさん：2021/02/21(日) 05:15:52.00 ID:kbkbRMiR.net
- >>552
テキストモードって知らんのか？
どのOSでも持ってる機能だぞ
- 554 ：デフォルトの名無しさん：2021/02/21(日) 05:33:13.41 ID:0HHdBuLy.net
- テキストモードという概念はOSというよりプログラミング言語じゃないかな。
- 555 ：：2021/02/21(日) 09:02:39.59 ID:3Ebck9FU.net
- >>553
テキストモード（正式にはクックドモードcooked mode／ローモード raw mode）は Micro Soft 社限定のような気が
- 556 ：デフォルトの名無しさん：2021/02/21(日) 14:27:37.46 ID:GfLXclnP.net
- Terminal mode
https://en.wikipedia.org/wiki/Terminal_mode
A terminal mode is one of a set of possible states of a terminal or pseudo terminal character device in Unix-like systems and determines how characters written to the terminal are interpreted.
In cooked mode data is preprocessed before being given to a program, while raw mode passes the data as-is to the program without interpreting any of the special characters.
- 557 ：：2021/02/21(日) 16:39:18.84 ID:3Ebck9FU.net
- >>556
thx
- 558 ：デフォルトの名無しさん：2021/02/21(日) 20:28:19.64 ID:x7XX42Aa.net
- たぶん、ascii・テキスト伝送は、Microsoft の規格だろ
基本、データはバイナリしかない。
バイナリを送っているだけ
それを、バイナリかテキストなのか、2種類に分けた
データベースと同じ。
バイナリしかないのに、各列を、バイナリ・テキスト・数値などに分類してる
- 559 ：デフォルトの名無しさん：2021/02/22(月) 03:41:51.59 ID:g4xweyOw.net
- Unix の raw-mode とういのはバイナリとかASCII とかじゃくて入力されたキーボードの文字を生のまま受け取るモード。
たとえばリターンキーを押すと 0x0D がバックスペースを押すと 0x08 がバイト単位でそのまま渡される。実際のコードは端末次第。
cooked-mode というのは端末の設定に従って行単位でバッファしながら入力を加工するモード。
端末設定で「改行文字入力」が 0x0D に設定されていて、キーボードから 0x0D が入力されたら
改行の入力とみなしてunixの内部的な改行 0x0A に変換して、それまでのバッファを渡す。
端末設定で「前の一文字削除」が 0x08 に設定されていて、キーボードから 0x08 がきたらバッファー内の最後の一文字を削除する。
Ctrl-C で割り込み中断とかも cooked の機能。
- 560 ：デフォルトの名無しさん：2021/02/22(月) 17:39:30.14 ID:bGamQ1pv.net
- >>533
>世に出てるブラウザの殆どはcharset=Shift_JISな文書をWindows-31Jとして解釈するだろうから
ちなiOSのSafariはそうじゃないっぽい。macOSの方はそうなんだが。
とりあえずiPhone買って、付いてきたSafariでウェブを見る、みたいなユーザーは多いんじゃない
かと思うんだが.. というわけで「殆ど」という言い方はできないかもしれない。
- 561 ：デフォルトの名無しさん：2021/02/22(月) 20:36:22.30 ID:DwYM6h5J.net
- >>551
バイナリコードに親しんでいる人が点字を覚えるなら従来の6点の点字より8点の点字で
そのままバイナリコードを表した方が分かりやすいって人はいるだろうね
昔は穿孔テープの穴を見て何が書いてあるか分かる人は多かったようだし
- 562 ：デフォルトの名無しさん：2021/02/23(火) 03:23:29.15 ID:DHJgW+88.net
- 後から穴の数が増えたのも出てくるけど、もともとの紙テープは5穴なので10分も練習すれば誰でも読めた。ただし会社ごとに個別に覚える必要があった。
このスレ的に言えば、各社バラバラだった5穴、6穴の規格を統一するために作られた7穴の共通規格が ASCII の始まり。
- 563 ：デフォルトの名無しさん：2021/02/23(火) 08:57:17.31 ID:I88lzdP8.net
- もうさ32ドット×32ドットぐらいの点字を作りなよ
そうすりゃかなりの文字を表現できるやろ？
- 564 ：デフォルトの名無しさん：2021/02/23(火) 12:06:09.45 ID:waG/I9Zl.net
- 32x32でいけると思ったのですが、森羅万象を表現するに全然足りないことが判明したので、サロゲート点字を導入します
- 565 ：デフォルトの名無しさん：2021/02/23(火) 16:52:17.61 ID:Z5ZYenTn.net
- 有史から遠い未来まで全人類の顔を絵文字として登録できる、という前提で文字コード規格を作らないとダメでしょ。
- 566 ：デフォルトの名無しさん：2021/02/23(火) 18:23:04.03 ID:1/jlbQjA.net
- 漢字には一画のぞくとか、わざと間違えるとかいう字もあるからなあ
- 567 ：デフォルトの名無しさん：2021/02/24(水) 15:37:09.38 ID:N1ZJD0Pr.net
- 「信長の野望」の家康画像みたいに元服前の顔、青年期の顔、老年期の顔をそれぞれ登録するようにしたらますます文字コードが増える。
- 568 ：デフォルトの名無しさん：2021/02/24(水) 15:43:59.66 ID:aaBs9O4Y.net
- 同じ顔は同一の文字コードにすればOK
- 569 ：デフォルトの名無しさん：2021/02/24(水) 16:00:01.95 ID:aweY/mLc.net
- >>545
そうなんだ。
ということはSJISのバリエーションに関しても、似たような経緯があったのかな?
「ウチのOSではこんな文字も使えますよ」的な?
- 570 ：デフォルトの名無しさん：2021/02/24(水) 16:13:32.49 ID:N1ZJD0Pr.net
- IPv6では宇宙誕生から消滅に至るまでの全宇宙のデバイスにIPアドレスを割り当てることはできない。勝手に最大量を決めてはダメってことだ。
- 571 ：デフォルトの名無しさん：2021/02/24(水) 16:25:49.69 ID:aaBs9O4Y.net
- >>569
OSじゃなくてハードウェアの問題
まずSJISの文字コード自体はMicrosoftとほか団体が協力して作ったが
SJISという文字コードと基本的な文字集合を定義したが、
当時のOSであるMS-DOSには文字集合という概念そのものがなかった
そもそもMS-DOSにはフォントというものが搭載されておらず
MS-DOSは単にSJISの文字コードに対応した出力機能を備えていたに過ぎない
そしてその文字コードに対応した文字（つまりフォント）はハードウェアの漢字ROMに搭載されていた
当時はPCの速度が遅く、ハードウェアにフォントを搭載しなければ
日本語はまともな速度が出なかった
そして漢字ROMを作っていたのはNECなどのパソコン屋。拡張領域に文字を入れることで
NEC「うちのパソコンは、こういう漢字にも対応していますよ。」ということが出来た
例えば PC-9801の初代は漢字ROMボードを搭載せず、
・JIS第一水準漢字ROMボード
・JIS第ニ水準漢字ROMチップ
・どちらにも含まれていない拡張漢字ROMチップ
がそれぞれ別売りされていた
- 572 ：デフォルトの名無しさん：2021/02/24(水) 16:32:05.41 ID:aaBs9O4Y.net
- 日本人が作る日本人のためのパソコンで
日本で使われている漢字が表示できないのは
マイナスでしかない。だからパソコン屋は
当初のSJISで定義されていた基本的な文字集合を超えた
文字を漢字ROMボードとして提供するしか道はなかった
そしてWindowsの時代となりフォントがOSに搭載されるようになってから
各メーカーが拡張していた漢字を相互運用できなくなるのは困るため
Microsoftは各拡張SJISを統合して改めてCP932として標準化した
もともとSJISを作ったのはMicrosoftなわけで
WindowsのSJISは、初期のSJISの正統後継といえる
- 573 ：デフォルトの名無しさん：2021/02/24(水) 17:13:57.11 ID:O/RKRWyd.net
- PC-98シリーズの漢字ROM、テキストVRAMはJISコードベースだ。SJISではない。
- 574 ：デフォルトの名無しさん：2021/02/24(水) 18:38:57.51 ID:CaexoUYp.net
- PC-98のMS-DOSでShift_JISのファイルを何も問題なく開けたけど
漢字ROMがJISだとするとファイルを開く時にどこかでShift_JISからJISに変換していたという事？
- 575 ：デフォルトの名無しさん：2021/02/24(水) 18:44:43.54 ID:zChO2spG.net
- 変換というかシフトしてる分を戻してるだけだな
- 576 ：デフォルトの名無しさん：2021/02/25(木) 16:21:35.59 ID:dtuEc+as.net
- 可変長で無限に文字を追加できる文字コードなると
全ての文字を実体参照で記録する形式にするしかないのでは？
- 577 ：デフォルトの名無しさん：2021/02/25(木) 17:21:18.30 ID:bCEhRyYb.net
- プレーンなgrepができなければ文字コード失格。
甲斐武田氏の家臣だけを抽出する正規表現クラス\p{KaiTakeda}みたいなのも使えなければダメ。
- 578 ：：2021/02/25(木) 19:01:31.51 ID:FipxGJhu.net
- >>574
VRAM が JIS ベースだ、という話というだけであって、ファイルが S-JIS だろうが UTF-16 であろうがどーでもいい話かと
- 579 ：デフォルトの名無しさん：2021/02/25(木) 19:53:40.28 ID:d2pfH4ce.net
- JISとSJISとEUC-JPの文字コードは
比較的単純な計算で変換することが出来るから
パフォーマンスの影響も少なくメモリも食わない
Unicodeの場合は変換にテーブルが必要になるから
MS-DOSの時代ではちょっと困るだろうな
- 580 ：デフォルトの名無しさん：2021/02/26(金) 23:06:18.58 ID:mLFL/iLf.net
- MS-DOS時代のテキストエディターで複数の文字コードに対応したものってあったんだろうか
- 581 ：デフォルトの名無しさん：2021/02/27(土) 00:23:55.40 ID:9B/eAMtf.net
- nemacsか
- 582 ：デフォルトの名無しさん：2021/02/27(土) 03:48:22.68 ID:8wUBQ4y1.net
- 単純計算だと非Unicode文字コード種ごとに128KBの変換テーブルが必要になる。
当時の揮発メモリに全部乗せたまま使うのは当然無理。LFUなりLRUなり使ってしのぐしかない。
- 583 ：：2021/02/27(土) 07:46:18.27 ID:H3Yv4o4X.net
- >>580
demacs/mule
- 584 ：デフォルトの名無しさん：2021/03/03(水) 00:32:39.49 ID:Fut02B/b.net
- 日本のsc2って今休業中なのかな
Unicode 14のalphaでKana Extended-Aに文字突っ込まれてるけどコメントしなくていいのか
このままbetaに進むと変更が難しくなりそうだけど
- 585 ：デフォルトの名無しさん：2021/03/04(木) 21:20:40.72 ID:jw7hSq/n.net
- ASCIIの制御文字にエスケープ文字(0x1b)や
その他の字の区切りを表す制御文字があるのに
メールでもHTMLでも制御文字は使わずに0x20-0x7eの印字可能文字の一部を
エスケープ文字として使うようになったのはなぜなのか
- 586 ：デフォルトの名無しさん：2021/03/04(木) 22:12:23.62 ID:BThS1gIP.net
- ここで言うHTMLのエスケープ文字ってどれのこと？
- 587 ：デフォルトの名無しさん：2021/03/04(木) 22:40:28.52 ID:jw7hSq/n.net
- >>586
タグを示す<>や実体参照で使う&;
- 588 ：デフォルトの名無しさん：2021/03/04(木) 23:10:32.38 ID:BThS1gIP.net
- その手の手書きする奴は図形文字じゃないと逆に不便じゃね？
- 589 ：デフォルトの名無しさん：2021/03/04(木) 23:54:15.04 ID:jw7hSq/n.net
- エスケープ文字に制御文字を使うと手で入力するのが面倒になるし
かといって図形文字を使うと文章中の文字と混同しないように注意しないといけなくなるから難しいか。
SJISの0x5c問題もこれが原因だよね。
- 590 ：デフォルトの名無しさん：2021/03/05(金) 02:36:48.86 ID:ZMKDWzIT.net
- 一言で言えば既存のテキストエディターで書けることを重視したから。
専用のハイパーテキスト用ツールは昔からあったけど不便だった。
- 591 ：デフォルトの名無しさん：2021/03/05(金) 17:53:33.38 ID:Zdg3nLGk.net
- ISO系(特にUnicode)が理解できなさすぎて辛い・・・・・・
・古い規格は数万払って買えw
・原文英語だけど頑張って読めw
・1993年の初版からいーっぱい改定して規格書いーっぱいあるでw
・JIS 「こうやで(決してISO版原文の解説ではない)」
・UnicodeとISO/IEC 10646で同じ用語使ってますw
・規格書で定義されてない用語を平気で使いますw
・規格書にUCS-2, UCS-4の定義, 解説がない
・文献によってコードポイントの表記が微妙に違う
UCS-4はU+00000000のからなのか, U+0000からなのか？w
・UCS-2/4は符号化文字集合だぞwあっ、やっぱり文字符号化方式だぞw
・CJK 「俺らも理解してくれよなw」
・日本人 「Unicodeが理解できん？こうやで！^^(ソースなし！w)」
おれはUnicodeの理解を諦めたぞ・・・・・・
- 592 ：デフォルトの名無しさん：2021/03/06(土) 02:52:41.34 ID:VRCzgeXN.net
- まず unicode と ISO10646 は建前上は別の規格で用語も適用範囲も一致していないと理解することから。
- 593 ：デフォルトの名無しさん：2021/03/06(土) 08:51:58.30 ID:Q5bee5g2.net
- >>591
Unicodeは諦めるとして
次はPOSIXとC++のどちらに挑戦する？
- 594 ：デフォルトの名無しさん：2021/03/06(土) 11:40:26.99 ID:6TyCcGYh.net
- Unicode公式 「ISOのUCS-4はUTF-32と同義語なんやでw」
おれ 「UCSは符号化文字集合でUTF-32は符号化方式では？ムキーーーーーーッ？？！」
つらい
全てを投げ出して北海道グルメ旅行したい
- 595 ：デフォルトの名無しさん：2021/03/06(土) 12:58:55.62 ID:VRCzgeXN.net
- >>594
違うねん。
ISO10646 でも UCS-4 と UTF-32 は同じ意味で符号化方式やねん。
UCS: 符号化文字集合
UCS-4: 符号化方式
UTF-32: 符号化方式
ISO/IEC 10646:2017 の定義だと
9.4 UTF-32 (UCS-4)
UTF-32 (or UCS-4) is the UCS encoding form that assigns each UCS
scalar value to a single unsigned 32-bit code unit. The terms UTF-32
and UCS-4 can be used interchangeably to designate this encoding form.
- 596 ：デフォルトの名無しさん：2021/03/06(土) 15:26:58.97 ID:6TyCcGYh.net
- 10646:2017だと明確に同義語として使われてたのか。
その版は持ってなくて中身確認できなかったから助かったわ
- 597 ：デフォルトの名無しさん：2021/03/06(土) 15:41:25.54 ID:6TyCcGYh.net
- マジで疲れた
UCS-4はUCSの部分集合だと思ってたけど実は違ったのかw
こんなことに悩んでたのかよクソすぎるw
- 598 ：デフォルトの名無しさん：2021/03/06(土) 18:39:02.04 ID:VRCzgeXN.net
- もしかして 10646:2020 を参照してん？ なら UCS-4 という用語自体が過去の遺物扱いや。
10.4 UTF-32
UTF-32 is the UCS encoding form that assigns each UCS scalar value to a single unsigned 32-bit code unit.
NOTE — Former editions of this document included “UCS-4” as an alternate term synonymous with “UTF-32”. Use of the term “UCS-4” to refer to this encoding form is deprecated.
- 599 ：デフォルトの名無しさん：2021/03/07(日) 12:36:06.36 ID:21gOPzKM.net
- あ、そこは見た
ただ10646:2020でいう「synonymous」が
どの程度の「同義」なのかが分からなかったけど
10646:2017を引用してくれたおかげで100％イコールなのが分かったわｻﾝｶﾞﾂな
- 600 ：デフォルトの名無しさん：2021/03/07(日) 12:38:04.56 ID:21gOPzKM.net
- やっとこれでクソつまらん文字コードからC++の参考書に戻れる
やったぜ
- 601 ：デフォルトの名無しさん：2021/03/07(日) 23:47:47.88 ID:gN+mrqU2.net
- UTF (Unicode Transformation Format)という言葉も昔の遺産だよね
今作り直すならUnicode Encoding SchemeでUES-8とかになるのかな
- 602 ：デフォルトの名無しさん：2021/03/08(月) 00:17:56.33 ID:8d5Xwcwc.net
- ちゃうねん。もともと UTF の U は unicode じゃなくて UCS や。Universal の U。
- 603 ：デフォルトの名無しさん：2021/03/08(月) 11:33:52.88 ID:3+uDlPP2.net
- 文字コードという呼び方をなくして
文字シーケンスと言ったほうが良いと思う
1文字は最大8バイトで表現する
- 604 ：デフォルトの名無しさん：2021/03/08(月) 12:58:27.48 ID:P3HygzNP.net
- EUCのU
- 605 ：デフォルトの名無しさん：2021/03/08(月) 13:47:48.99 ID:47hpvSbS.net
- >>602
おおっと、これは失礼しました
- 606 ：デフォルトの名無しさん：2021/03/08(月) 15:45:58.81 ID:nvShaTc9.net
- UTF-の後に続く数字は当初はバージョン番号のような意味だったのが
途中からビット数を表す意味に変わったようにも見える
- 607 ：デフォルトの名無しさん：2021/03/08(月) 23:38:40.10 ID:ccXfg1Ko.net
- >>606
Unicodeの種別をUTF-なんとかと言い出したのは、1文字を16ビットで表現することに限界を感じたため。UTF-8は一番やりたくなかったけど、世界中の文字を切り替えて表現する方法は支持されなかったから、最小単位が8バイトのUTF-8が標準になった。
- 608 ：デフォルトの名無しさん：2021/03/08(月) 23:41:28.57 ID:ccXfg1Ko.net
- SJISのように2バイトで表現するキャラクタセットとの相性を重視している場合はUTF-16が使われる。
- 609 ：デフォルトの名無しさん：2021/03/09(火) 09:45:27.84 ID:p4cuNQqC.net
- >>607
UTF-8が標準になったのはUnix系の互換性の問題
多バイト固定すると、文字列が1バイト前提であるC言語とC言語で作られてる
Unixのソースコードの多くを修正する必要があった。
そのため互換性があるUTF-8が作られた。
- 610 ：デフォルトの名無しさん：2021/03/09(火) 11:10:37.15 ID:oV9GYLDS.net
- >>609
EUCを知ってますか？
- 611 ：デフォルトの名無しさん：2021/03/09(火) 11:13:42.05 ID:p4cuNQqC.net
- >>610
EUCとUTF-8と同じようにC言語とC言語で作られてる
Unixのソースコードと互換性があるように作られたことを知ってますか？
そしてEUCがどうしましたか？
- 612 ：デフォルトの名無しさん：2021/03/09(火) 17:39:10.59 ID:oV9GYLDS.net
- キャラクタセットは選ぶもの
- 613 ：デフォルトの名無しさん：2021/03/09(火) 17:40:37.43 ID:oV9GYLDS.net
- アスキー文字は1バイトで同じ文字コードにしたいのはあたりまえ
- 614 ：デフォルトの名無しさん：2021/03/09(火) 17:41:09.24 ID:oV9GYLDS.net
- UTF-16にこだわったのは欧米人
- 615 ：デフォルトの名無しさん：2021/03/09(火) 17:53:03.04 ID:JYZP+6rB.net
- >>612
UTF-16を選べるというのなら選んでみるが良い
互換性がないキャラクタセットはサポートされていない
- 616 ：デフォルトの名無しさん：2021/03/09(火) 19:47:21.10 ID:qz7mFwyh.net
- UTF-16はユニコードの文学的表現と、あわしろ氏が言ってた。
- 617 ：デフォルトの名無しさん：2021/03/09(火) 19:49:34.87 ID:N+Xx0u4G.net
- じゃあ間違いってことだな
- 618 ：デフォルトの名無しさん：2021/03/09(火) 22:12:38.95 ID:uPwAQTWz.net
- UTF-16 にこだわったわけじゃないだろ。
昔こだわってたのは16ビット固定長。
当時の非力なパソコンだと都合が良かった。
ワークステーションとか性能に余裕がある機械使ってる人たちから絶対に文字数足りなくなる阿呆仕様とか言われてたが、仕方なかった。
後に性能に余裕が出てきた時に既に16ビットでOSとかAPI設計・使用していたので、16ビット可変長を導入した。それが今のUTF-16。
- 619 ：デフォルトの名無しさん：2021/03/10(水) 23:22:37.08 ID:rTwzo8YF.net
- ISO/IEC 8859-1前提で作られていたはずなのに
いつの間にかUTF-8に乗り換えようとしてる？とうに乗り換えた？
WWW(のHTTP)の世界
- 620 ：デフォルトの名無しさん：2021/03/15(月) 00:38:41.86 ID:nWbOihFX.net
- 0x7Fだけでなく0xFFがDELとして定義されていないのは
0x80-0xFFに文字が定義された時には既に紙テープは使われなくなっていたという事なのかな
- 621 ：デフォルトの名無しさん：2021/03/15(月) 08:07:57.71 ID:GifvrUGq.net
- その紙テープとDELの話、機能的に必要だからそうしたというわけじゃないと思うがな。
DELは「削除する」文字なのに紙テープは「削除された」文字になるよね。
- 622 ：デフォルトの名無しさん：2021/03/15(月) 09:04:25.39 ID:IkMjMWUP.net
- その 0x80-0xFF というのが 0xFF に文字を割当ててる ISO8859の時代ことなら、もう紙テープななんか使ってなかった。
それより古いの、例えば JISX0201 のカナとかの時代でもほぼ紙テープなんか使ってなかったけど 0xFF は未定義で文字は割当なかった。
- 623 ：デフォルトの名無しさん：2021/03/16(火) 14:48:47.22 ID:OdNNK18i.net
- 「削除する」というよりか「これは間違いだから無視してね」という印、みたいな感じ
- 624 ：デフォルトの名無しさん：2021/03/16(火) 16:03:04.87 ID:NeNdvqnK.net
- モールス信号は単音と長音の組み合わせだからビット表示みたいなもんかな
- 625 ：デフォルトの名無しさん：2021/03/16(火) 21:56:06.00 ID:fetr9hD4.net
- へー、DELをバックスペースの意味で使うようになったのが後付けなのか。
https://ja.wikipedia.org/wiki/削除文字
- 626 ：デフォルトの名無しさん：2021/03/18(木) 22:37:10.93 ID:bBSRtLnn.net
- 制御文字はASCIIコードの最初を占めているのにCUIでのコマンドに使わないのはもったいないと思う。
昔は制御文字をコマンドとして使っていたんだから
例えばSMTPは制御文字のSOH STX ETX EOTをコマンドにしてもよかったのでは
- 627 ：デフォルトの名無しさん：2021/03/19(金) 00:35:37.02 ID:pLBLA8wx.net
- あのう…、素人がひとつお尋ねしたいのですけど、よろしいですか？
大昔からWindowsパソコンを使っていて
今までにエディタで書いたテキスト資産をたくさん持つ人が
これからもWindowsパソコンを使い続けると仮定するなら
新しく書くテキストデータの文字コードは何を使えば良いのでしょう？
従来どおりShift-JIS？ それともUTF-8？
なお、テキストは書くだけではなく他人から貰ったデータを読むこともあります
- 628 ：デフォルトの名無しさん：2021/03/19(金) 00:37:01.06 ID:pLBLA8wx.net
- ゴメンなさい、最後の一文は
コピペしてテキストをマージすることもある、の意です
- 629 ：デフォルトの名無しさん：2021/03/19(金) 01:21:48.92 ID:hh9Kt8XT.net
- Windowsは表面的にはシフトJISですが、内部はUTF-16です。
メモ帳がBOM付きUTF-8に対応したりとしているので、UTF-8でも特に問題ありません。
テキストエディタやOffice製品でSJISが使えなくなることは、想定しなくてもいいと思います。
- 630 ：デフォルトの名無しさん：2021/03/19(金) 01:23:29.57 ID:hh9Kt8XT.net
- 日本語の世界でSJISがなくなることは想定しなくてよいという意味です。
- 631 ：デフォルトの名無しさん：2021/03/19(金) 06:55:45.01 ID:MDPOlxpG.net
- >>627
UTF-8一択
絵文字も使えない文字コードなんて使えるか
- 632 ：デフォルトの名無しさん：2021/03/19(金) 07:01:30.18 ID:pLBLA8wx.net
- >>629->>630
有り難うございます、てことは…
別に今後もずっとSJISだけを使い続けて良い…という言い方もできますかね？
実はメールでテキストをやり取りする際、相手がHTMLメール使っていたりすると
なぜか「～」が文字化けしたり、しなかったり…、コピペの時に苦労しておるのです
- 633 ：デフォルトの名無しさん：2021/03/19(金) 07:03:11.89 ID:pLBLA8wx.net
- >>631
いや、絵文字は一生使うつもりがありませんｗ
- 634 ：デフォルトの名無しさん：2021/03/19(金) 07:53:48.58 ID:/oetvOh6.net
- 自分自身が絵文字を使うかどうかは重要じゃなくて、他人の書いた絵文字を含む文書を劣化させずに保存できることが重要
- 635 ：：2021/03/19(金) 08:22:24.74 ID:p1PI4fNB.net
- >>631
絵文字は不要、誰が絵文字なんかを文字コードの中に押し込んだんだ？
- 636 ：デフォルトの名無しさん：2021/03/19(金) 08:45:35.33 ID:pPRPone1.net
- >>635
Appleだよ
https://ja.wikipedia.org/wiki/MacJapanese
- 637 ：デフォルトの名無しさん：2021/03/19(金) 09:58:34.93 ID:n/AYlKWK.net
- >>636
具体的にどれが?
一般的にはガラケーの各キャリアでは?
- 638 ：デフォルトの名無しさん：2021/03/19(金) 13:03:56.18 ID:eiJMVgO4.net
- 最初にコード化したのは誰かって意味ならワープロメーカーとかじゃね？
unicodeに入れたのはgoogle。
その元になった絵文字セットのうちの1つを最初に作ったのはドコモ
- 639 ：デフォルトの名無しさん：2021/03/19(金) 14:00:06.98 ID:D6AA0Wwh.net
- MSが何を考えているか外からではわからないけど
S-JISは切り捨てる可能性があるんじゃないかな
- 640 ：デフォルトの名無しさん：2021/03/19(金) 14:15:07.57 ID:/oetvOh6.net
- >>639
「切り捨てる」の定義次第でしょ。
ゴールポストを動かすように定義を変えることもできる。
- 641 ：デフォルトの名無しさん：2021/03/19(金) 15:26:48.13 ID:eiJMVgO4.net
- >>633
macだとcuiでも絵文字使ってるプログラムが増えてて、見やすいしわりと便利よ
- 642 ：デフォルトの名無しさん：2021/03/19(金) 16:19:10.35 ID:MDPOlxpG.net
- Powerlineとかのプログラミング用の絵文字
あれUnicodeに入れてくれないかな？
- 643 ：：2021/03/19(金) 16:31:55.75 ID:AfDayCIW.net
- 歩香桂銀金王角飛と杏圭全馬龍の逆さ文字は追加してほしいなぁ……
- 644 ：デフォルトの名無しさん：2021/03/19(金) 17:45:59.37 ID:hh9Kt8XT.net
- Unicodeの絵文字は全世界で使われているからね。
- 645 ：デフォルトの名無しさん：2021/03/19(金) 17:46:52.40 ID:hh9Kt8XT.net
- 日本の絵文字がベースだから、日本人っぽいものが多い。
- 646 ：デフォルトの名無しさん：2021/03/19(金) 18:07:03.09 ID:/oetvOh6.net
- >>643
文字を所定角度に回転させる異体字セレクタがいくつもあれば一番いいんだけど
30度ごとならアナログ時計の表現にも使えそう
- 647 ：デフォルトの名無しさん：2021/03/19(金) 22:38:34.45 ID:pLBLA8wx.net
- あのう…、皆さん色々ありがとうございます
それで…、結局のところ私は…、これから先テキストを新しく書いた時に
そのテキストデータの文字コードを何にして保存すれば良いのでしょうか？
- 648 ：デフォルトの名無しさん：2021/03/19(金) 23:10:26.99 ID:gtzZCHhj.net
- 何回も何回も裏切られてきたからな
一寸先は闇
UTFが優勢ではあるけど
何があるかわからん
- 649 ：：2021/03/19(金) 23:12:46.09 ID:AfDayCIW.net
- >>647
BOM 付きUTF-8 でいいんじゃないでしょうか…
- 650 ：デフォルトの名無しさん：2021/03/20(土) 00:19:36.84 ID:4rbcgKwq.net
- 異体字セレクタは無視可能だから>>643みたいな対比が重要な用途には向かん
- 651 ：デフォルトの名無しさん：2021/03/20(土) 03:11:58.85 ID:D8GShjRw.net
- >>649
UTF8 に BOM はいらんだろ。(原理主義)
- 652 ：デフォルトの名無しさん：2021/03/20(土) 03:46:25.95 ID:XiFOMzCU.net
- >>647
文字コードはなんでもいいので、...を空文字列に置換してから保存してください
- 653 ：デフォルトの名無しさん：2021/03/20(土) 04:03:35.66 ID:HNARUvnS.net
- >>651
627のwindowsでの質問なのでbom付きのが良い
- 654 ：デフォルトの名無しさん：2021/03/20(土) 06:00:23.16 ID:fwPpsQIN.net
- BOM付きはエラーの原因になったりするんだよね
647レベルだと恐らく原因にたどり着けない
- 655 ：デフォルトの名無しさん：2021/03/20(土) 12:04:30.81 ID:OmO/62/g.net
- 個人用なら UTF8一択でいいよ
ただし、以下が注意かな
1. 納品先、提出先の指定、プロジェクトでの指定があるなら合わせる
2. UTF8に対応していない古いツール類（エディタ含む）を使って処理しているなら合わせる
- 656 ：デフォルトの名無しさん：2021/03/20(土) 13:21:00.17 ID:N0CH58op.net
- >>654
エラーの原因になるというか、そのソフトがUTF8シグネチャに対応してないってだけだな。
結局のところ使うソフトや環境次第。
WindowsメインならUTF8シグネチャ付きの方がトラブルは少ないだろう。
- 657 ：デフォルトの名無しさん：2021/03/20(土) 14:11:52.17 ID:IyzEzHor.net
- BOM なしUTF-8(UTF-8N)が良い
Windows と言っても、WSL でLinux を使うかも知れないから、
BOMを付けると、動かないかも
- 658 ：デフォルトの名無しさん：2021/03/20(土) 14:43:30.24 ID:ATRyxlqT.net
- winにはofficeとか、utf-8でもbomがないと化けるメジャーソフトもあるんだよなあ
- 659 ：ID:pLBLA8wx：2021/03/20(土) 17:23:15.32 ID:kRdQNH2J.net
- 皆さん本当に色々とありがとうございました！
出てくる単語を片っ端からググって再確認しつつ、もっとも普遍的原理的な
考え方を自分の頭の中で屁理屈として組み立てあげました！
結論：これから私は、書いたテキストを原則UTF-8で保存する
(→必要に応じてBOMをつけて保存し使うこともある)
本当に勉強になりました。２日で１０年分(か２０年分)勉強した感じですw。
- 660 ：デフォルトの名無しさん：2021/03/20(土) 18:05:23.87 ID:fwPpsQIN.net
- もつかれ
- 661 ：デフォルトの名無しさん：2021/03/21(日) 02:58:59.19 ID:Hmh4/82J.net
- UTF8はBOMがないのが正式。規格書嫁。
BOMが付くのは他の文字コードから変換の時に頭悪いソフトが削り損ねたか、
メモ帳のように文字コード対応が不完全なソフトが、独自の文字コード判別機能のために規格無視で突っ込んだ
くらい。
- 662 ：デフォルトの名無しさん：2021/03/21(日) 08:53:26.10 ID:nNrBMbyx.net
- BOMはオプション的な扱いだけど正式なRFCの仕様だが？
プロトコルとして文字コードを決め打ちする場合とか他の方法で文字コードを受け渡す
仕組みがある場合はBOMを使用すべきではないというくらい。
そもそも「文字コード対応が不完全なソフト」って、UTF-8決め打ちのソフトのことじゃね？
- 663 ：デフォルトの名無しさん：2021/03/21(日) 10:07:00.18 ID:ZMzh4Q+Z.net
- >>661
UTF-8のBOMがなかったら以前の文字コード（日本だったらSJIS）とUTF-8の区別がつかないんだよ。
UTF-16やUTF-32なら1バイト単位で見た時にNULL文字が多数登場するという特徴があるが
UTF-8はバイト列をフルに使って詰め込んでるから区別することが不可能
UTF-8のBOMはUTF-8とそれ以外の文字コードを区別するための機能
昔は文字コードが自動判定できてたって？それはSJISとEUC-JPみたいに
バイト列をフルに使ってない文字コードかつ、日本語しか考慮してないから
できてたことなんだよ。UTF-8とそれ以外の文字コード判別は無理
- 664 ：：2021/03/21(日) 10:20:33.48 ID:Axw052vZ.net
- >>661
＞UTF8はBOMがないのが正式。規格書嫁。
であれば規格書（）にわざわざ UTF-8 のための BOM 0xEF 0xBB 0xBF が定義されているのは、なぜでしょうか？
- 665 ：デフォルトの名無しさん：2021/03/21(日) 10:46:26.36 ID:Hmh4/82J.net
- 規格はちゃんと読めとしか。
例えば Unicode 13.0 での扱いは
1) U+FEFF は基本は Zero Width Non-Breaking Space
2) バイト列化した UTF-16 と UTF-32 の先頭に来た場合は Byte Order Mark
3) Unicode Signature としても使用できるが、プロトコルが型無しの場合に使用し、それ以外では使用を推奨しない
という扱いだ。1) と 2) と 3) は別の使い方だと理解するところから始めろ
UTF-8 でも 1) は普通に使える、2)としては使用できない、3)はプロトコル次第(HTTPだと非推奨、FTPだと可)
UTF-16 から UTF-8 に変換する時は 1) の意味なら残す、2) の意味なら削る、3) の意味ならプロトコル次第。
不明ならば基本の 1) を仮定して残すのが正しい実装だ。
- 666 ：デフォルトの名無しさん：2021/03/21(日) 11:32:14.01 ID:nNrBMbyx.net
- >1) U+FEFF は基本は Zero Width Non-Breaking Space
「本来は～だった。」が正しいだろうな。
その意味で解釈するのはストリームの先頭以外に現れた場合に限るとされているし
今ではその意味でも使用すべきではないということになった。
>2) バイト列化した UTF-16 と UTF-32 の先頭に来た場合は Byte Order Mark
RFCで言う"BOM"にはバイトオーダーマークとシグネチャの両方の機能があって、
バイトオーダーマークとしての意味はUTF-16やUTF-32だけだけれども
シグネチャとしての意味はUTF-8でも有効だと書いてあるだろう。
- 667 ：デフォルトの名無しさん：2021/03/21(日) 12:02:55.18 ID:Hmh4/82J.net
- 最新規格でも ZWNBS が正式。BOM は例外的な使用法。
「だった」って過去形で主張するんなら規格のどこに過去形書いてあるか、どの規格で廃止されたか示してみろ。
カタカナでバイトオーダーマークって書いても誤魔化せないぞ。
- 668 ：ID:pLBLA8wx：2021/03/21(日) 13:46:50.50 ID:hcZhKSEU.net
- けんかをやめて 二人をとめて
私のためにBOMで争わないで もうこれ以上
- 669 ：デフォルトの名無しさん：2021/03/21(日) 14:28:20.22 ID:nNrBMbyx.net
- ああそうだな。文字の定義自体は変わっていないからその意味では過去形はおかしかったかな。
ただRFC3629では、今は同じ意味のU+2060があるからそっちを使うことを「強く推奨する」と。
- 670 ：デフォルトの名無しさん：2021/03/21(日) 15:38:22.99 ID:ahwL4b0J.net
- https://www.unicode.org/charts/PDF/UFE70.pdf
>may be used to detect byte order by contrast with the noncharacter code point FFFE
>use as an indication of non-breaking is deprecated; see 2060 instead
non-breakingとして使うのはdeprecatedだと言ってるし過去形でいいんじゃね
BOMとしての使い道だけが残った
- 671 ：デフォルトの名無しさん：2021/03/21(日) 23:32:21.54 ID:ZMzh4Q+Z.net
- > UTF-8 でも 1) は普通に使える、2)としては使用できない、3)はプロトコル次第(HTTPだと非推奨、FTPだと可)
Byte Order Markの意味わかってんのか？
UTF-8は1バイト単位で扱う文字列なんだから、2として使い方に
意味がないのは当たり前だろ。使えないというより意味がない
使っては駄目という意味じゃない。使ってもいいが本来の意味がないというだけだ。
16bitまたは32bitのときの順番を判断するためにあるのに
Byte（バイト） Order（順番） Mark（記号）
つまりU+FEFFは「文章のどこでも使っていい文字」で
先頭に来た場合に限りBOMとして解釈するというだけだ
- 672 ：デフォルトの名無しさん：2021/03/23(火) 08:39:38.88 ID:VNfq1a/Y.net
- Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If yes, then can I still assume the remaining UTF-8 bytes are in big-endian order?
http://www.unicode.org/faq/utf_bom.html#bom5
Yes, UTF-8 can contain a BOM. However, it makes no difference as to the endianness of the byte stream.
UTF-8 always has the same byte order. An initial BOM is only used as a signature - an indication that an otherwise unmarked text file is in UTF-8.
Note that some recipients of UTF-8 encoded data do not expect a BOM.
Where UTF-8 is used transparently in 8-bit environments,
the use of a BOM will interfere with any protocol or file format that expects specific ASCII characters at the beginning,
such as the use of "#!" of at the beginning of Unix shell scripts.
- 673 ：デフォルトの名無しさん：2021/03/28(日) 20:48:56.89 ID:24lC/lyM.net
- そもそも全く意味も機能も異なるZERO WIDTH NO-BREAK SPACEとBYTE ORDER MARKを
U+FEFFという単一のコードポイントに統合した馬鹿は何処の誰なん？
- 674 ：デフォルトの名無しさん：2021/03/29(月) 10:11:40.65 ID:wK+S1L2g.net
- >>673
英語よめないの？
ZERO WIDTH NO-BREAK SPACE（幅がない改行をしないスペース）
BOMは幅があるか？ないだろ
改行するか？しないだろ
BOMが途中に出てくることがあるか？
その場合どうすればいいんだ？
無視する＝幅がなくて改行しないスペースだろ
- 675 ：デフォルトの名無しさん：2021/03/29(月) 16:21:58.12 ID:OlONkL8s.net
- 落ち着け
ZWNBS は無視しちゃ駄目だよ。そこで自動改行禁止というマークなので、ちゃんと処理しないと駄目。
- 676 ：デフォルトの名無しさん：2021/03/29(月) 17:07:30.02 ID:wK+S1L2g.net
- >>675
自動改行禁止の意味わかってるか？
無視する＝そこに文字がないのと同じように扱うから
自動改行も禁止なんだよ
BOMとZERO WIDTH NO-BREAK SPACEを同じにしたと言うより
BOMはZERO WIDTH NO-BREAK SPACEと同じ動きをする文字だということ
- 677 ：デフォルトの名無しさん：2021/03/29(月) 21:25:17.42 ID:FXjqyr6T.net
- あまり文字コード関係ないけど笑ったので貼っとく
https://twitter.com/ryancdotorg/status/1375484757916672000
(deleted an unsolicited ad)
- 678 ：デフォルトの名無しさん：2021/03/30(火) 02:24:24.90 ID:T6lwQIyt.net
- >>676
嘘をつくな。
BOM は内部コードに変換する時に取り除くべき文字。制御コードとしての機能はない。
ZWNBS は内部コードでも残り制御コードとして前後の文字を一体として接続し、その間での改行を禁止する意味を持つ。
- 679 ：デフォルトの名無しさん：2021/03/30(火) 02:31:28.79 ID:ToWHw8Xp.net
- >>678
だからそのBOMが文書の内部に出てきたら
どう処理するんだよって話なんだが
データに絶対入らないように誰かが制限してるか？
バイナリエディタを使っても入れることが出来ないか？
入っていたら落ちたほうがいいか？
- 680 ：デフォルトの名無しさん：2021/03/30(火) 03:04:28.57 ID:T6lwQIyt.net
- >>679
寝ぼけっての？
文章の途中に来たら BOM じゃないよ。
- 681 ：デフォルトの名無しさん：2021/03/30(火) 05:29:26.08 ID:ToWHw8Xp.net
- >>680
だからバイナリエディタでBOMと同じコードを文章中に入れたものを
読み込んだら、どういう挙動をするべきかって話をしてるんだが
制御コードとして前後の文字を一体として接続し、その間での改行を禁止する意味を持たせたほうがいいだろうね
- 682 ：デフォルトの名無しさん：2021/03/30(火) 09:51:00.56 ID:T6lwQIyt.net
- 持たせたほうがいいも何も、規格上はそういう意味だよ。
バイナリ・エディタで入れようが、テキスト・エディタで入れようが ZWNBS として扱う。
もともと規格では
U+FEFF は制御コードとして ZERO WIDTH NO-BREAK SPACE としての機能を持つ。(その場所での分割を禁止する)
そしてこれが、UTF-16, UTF-32 ストリームの先頭に来た場合には Byte Order Mark (エンディアンの指定)という特別な機能を持つ
さらに先頭の BOMは Unicode Signature (その文章が Unicode で書かれている印)として使用できる。
この先頭の U+FEFF は制御コードとしての機能はないので処理の際には取り除け。
先頭に U+FEFF が二つ続いた場合は一つ目は BOM で、二つ目は ZWNBS として解釈せよ。
UTF-16LE や UTF-16BE などのようにエンディア決め打ちの文字コードや、他の方法でエンディアンが指定されている場合は、先頭にあっても ZWNBS で BOM ではない。
ファイルを結合する時とか、そのままつなぐと、後ろにファイルの先頭の U+FEFF が ZWNBS として解釈されるので取り除くのを忘れんな
その後の改訂で
やっぱ使ってみると、同じコードポイントに複数の機能があるのはややこしいので U+2060 WORD JOINWER ってのを作った。
この WORD JOINER は ZWNBS と全く同じ機能だけど、BOM としては使うことができない。制御コードには今後はこっちを使うのを強く推奨。
でも歴史的な経緯と過去の資産があるから、文章の途中に出てくる U+FEFF は、これまでどおり の意味で解釈せよ。
- 683 ：デフォルトの名無しさん：2021/03/31(水) 01:51:23.09 ID:AtIsL56M.net
- asciiの0-32までってc記法あるの以外ほぼ死語かと思ってたんだけど
バイナリエディタでMS系のフォーマット(特にOffice)で汎用されてるのな
セパレータ系とかなるべく原義に沿おうとしてて好感
いつもprintable文字抽出だけしてたからなかなか気付かんかった
- 684 ：デフォルトの名無しさん：2021/03/31(水) 01:57:57.39 ID:AtIsL56M.net
- 論理的に考えてcrlfが正義とか言い張り続けてたり、なんかこだわりあるんかねMS
- 685 ：デフォルトの名無しさん：2021/03/31(水) 09:30:13.62 ID:ekNiD538.net
- > 論理的に考えてcrlfが正義とか言い張り続けてたり
なんのこと？
意味的にCR LFが正しいことに間違いはないし、CR LF対応は
意味のないプライドとかじゃなくて互換性のためにでしょ
それにLinuxとの互換性のためにLFだけのファイルもメモ帳で受け付けるようになったじゃん
開発ツールに限れば昔からLFだけでも認めてた。
- 686 ：デフォルトの名無しさん：2021/03/31(水) 09:35:15.80 ID:1T2H/5i8.net
- >>685
crlfで正しいと思ってるよ、まあ蛇足だった
- 687 ：デフォルトの名無しさん：2021/03/31(水) 09:41:35.38 ID:1T2H/5i8.net
- Officeのalt/shift+retとかで特殊な改行したりするけど、ちゃんと対応するASCII制御文字入ってたんだなと感心してしまったもんで
- 688 ：デフォルトの名無しさん：2021/03/31(水) 10:06:28.66 ID:AtIsL56M.net
- 表の階層化にFS, GS, RS、複数行セルにVTとか使ってるねー、面白い
echoでコピペしてみたけどこれは受け付けてくれないっぽい…残念
- 689 ：デフォルトの名無しさん：2021/04/02(金) 14:48:41.83 ID:XKDKi0jd.net
- メモ帳で折り返しにCR CR LF入れるとかもこの流れなのかな？
- 690 ：デフォルトの名無しさん：2021/04/04(日) 09:56:09.95 ID:Y/fIEFRX.net
- やはりBOMは必要だな
「ASCIIをUTF-8にして」それが『できない』ことを理解してもらえなかった話
https://qiita.com/heeroo_ymsw/items/c6e15d5f9246b4e842eb
- 691 ：デフォルトの名無しさん：2021/04/04(日) 11:25:45.54 ID:BHN4NYpU.net
- >>689
きになる
Format>WordWrap?だよね
折返した状態で保存みたいなオプションがあるのかな
当たり前だけど保存しても改行してない（してたらバグだw
表示上だけ入れてるのかとコピペしても拾えない
内部で描画のコントロールに使ってるということ？かな？
- 692 ：デフォルトの名無しさん：2021/04/04(日) 11:47:39.11 ID:BHN4NYpU.net
- >>690
要するに
UTF-8、但しASCII/sjisとの共通部分はダメ、かつ英数字のみを使いたいということね
０１２０―ＡＢＣーＸＹＺ（ユニコfull-width latin
これで要件を満たせる！
- 693 ：デフォルトの名無しさん：2021/04/04(日) 11:59:15.19 ID:bg/3EMBi.net
- 顧客が本当に求めていたモノ…
- 694 ：デフォルトの名無しさん：2021/04/04(日) 20:11:30.38 ID:+Q6KU8is.net
- BOM付きだな
頭でっかちの原理主義者はいつでも間違っている
- 695 ：デフォルトの名無しさん：2021/04/05(月) 01:33:23.71 ID:HL3+b1wt.net
- あほ過ぎる
UTF8 や本来のSJISやEUCはASCIIの完全上位互換なのがメリットなのに BOM 入れて互換性無くすとか素人の極み。
ASCIIと互換性無くていいんなら UTF16でも使ってろ。
- 696 ：デフォルトの名無しさん：2021/04/05(月) 01:40:26.92 ID:6E9KDupE.net
- その考え方がそもそもの間違いだわ
- 697 ：デフォルトの名無しさん：2021/04/05(月) 01:48:11.31 ID:i9PX2oQn.net
- 全角で納品したら楽しそうだからそれで
- 698 ：デフォルトの名無しさん：2021/04/05(月) 07:02:33.51 ID:HL3+b1wt.net
- ファイル名にいちいちBOMが入ってて、ASCII で書かれたファイル名と、UTF8で書かれたファイル名が、別ファイルとして扱われる世界。
考えただけでも吐き気がする。
- 699 ：デフォルトの名無しさん：2021/04/05(月) 08:21:19.81 ID:qswNC1lG.net
- ファイル名にBOM入れる奴はさすがにいないだろ…
いないよね？
- 700 ：デフォルトの名無しさん：2021/04/05(月) 09:04:19.64 ID:Tyhmgvsu.net
- BOMは"ファイル"に入れるのは別に悪くないと思ってる
明示できるものは明示すべきだろう、何でもutf-8の時代になりつつあるから、むしろ他のutfやsjis/eucに入れるのが時代にそぐう
もはやBOMじゃなくて単なるマジックナンバーだが
ファイル名…ってのは正直思いつかなかった
でもBOM付きの細かいテキストを文字列として継ぎ接ぎした時にトリムするのが面倒だった経験があるわ
やはりマジックナンバー、テキストファイル=マジックナンバー+テキストとして扱うべき
テキストファイル以外に付けるのは勘弁
- 701 ：デフォルトの名無しさん：2021/04/05(月) 11:09:52.26 ID:gsx4ZFoJ.net
- そりゃ仕様できっちりとBOMを入れませんと
なってるものにBOMを入れる必要ないだろ
テキストファイルの場合はいろんな文字コードが
歴史的な経緯で許可されてるフォーマットだから
BOMをファイル形式を判断するヘッダとし
て利用するというだけであって
- 702 ：デフォルトの名無しさん：2021/04/05(月) 11:12:15.44 ID:gsx4ZFoJ.net
- >>695
BOMはテキストファイルにおいて文字コードを判別するための仕組み
BOMによってSJISやEUCではないと判別できるのに
互換性がなんの関係があるのか？
SJISやEUCと互換性がないからこそ、文字コードを判別するのに利用できる
- 703 ：デフォルトの名無しさん：2021/04/05(月) 11:51:41.26 ID:HL3+b1wt.net
- なんで UTF -8 と SJIS の互換性気にせにゃならんねん。
これやから、ロートル多いスレは。
今からの時代 BOM なんかくてもデフォルトは UTF-8 だよ。
Linux とか Mac は既にそうなってるし、日本語WIndowsだって次か、次の次のメジャーバージョンくらいで SJIS 捨てて UTF-8 いくやろ。
過去に生きてるやつはBOM 必要かもしれないが、今が過渡期なのでそんな気がしてるだけや。
どうせ欧米がナロー系の文字コードは UTF-8 に一本化で動いてるんで、今さらどうにかなるもんでもない。
- 704 ：デフォルトの名無しさん：2021/04/05(月) 13:58:26.49 ID:gsx4ZFoJ.net
- >>703
すぐバレる嘘を付くな
> Linux とか Mac は既にそうなってるし、
Linuxはローケルの変更から日本語だとEUC-JPに対応しているしSJISも使える
https://www.early2home.com/blog/os/linux/post-1314.html
WindowsはNTは最初からUTF-16だ
- 705 ：デフォルトの名無しさん：2021/04/05(月) 14:08:55.17 ID:i9PX2oQn.net
- ぶっちゃけUTF-8をマトモに実装するのは難しいので勘弁してほしい
正規化とかわけわかんぬ…
プログラミング言語やライブラリの内部ではコードポイントそのままで固定長で扱いやすいUTF-32採用が多いね
後に成熟してきたら変換のオーバヘッド削る為にUTF-8に切り替える風潮だけど（pythonはじめ諸々
将来ネットワークのスループットが良くなればUTF32も受け入れられたりしないかな、それまで生き残ってればの話だが
- 706 ：デフォルトの名無しさん：2021/04/05(月) 14:19:53.71 ID:HL3+b1wt.net
- >>704
デフォルトって言葉の意味知ってる？
- 707 ：デフォルトの名無しさん：2021/04/05(月) 15:36:03.55 ID:Wm92d7Ex.net
- >>706
WindowsのデフォルトはUTF-16です。
英語のアメリカでも日本語のSJISがデフォルトだとでも思ってた？
そんなんだから理解が浅いって言われるわけ
- 708 ：デフォルトの名無しさん：2021/04/05(月) 15:37:39.57 ID:Wm92d7Ex.net
- >>705
UTF-32はもはや固定長じゃないよ
漢字1文字が最大8バイトUnicodeの「IVS」が
32bit、4バイトに収まるわけがない
- 709 ：デフォルトの名無しさん：2021/04/05(月) 16:24:25.38 ID:4C6FED3z.net
- デフォルト、破産だよ
デフォルト国家、あの国やったろ
- 710 ：デフォルトの名無しさん：2021/04/05(月) 17:09:09.07 ID:HL3+b1wt.net
- >>707
日本語Windows のデフォルトの話してるのに、何で英語のアメリカとか関係してくるんや？
文字が読めない人なのだろうか？
お前の Windows 日本語インストールして直後のカスタマイズ無しの状態でコマンドプロプトで chcp って打ったら何と応えるの？
- 711 ：デフォルトの名無しさん：2021/04/05(月) 17:09:52.54 ID:w8t18er9.net
- 日本語版Windowsのデフォルトコードページは今でもCP932だが？
- 712 ：デフォルトの名無しさん：2021/04/05(月) 21:28:09.04 ID:EGK62I3K.net
- https://opcdiary.net/i18n-windows%E3%81%A8linux%E3%81%A7%E3%81%AE%E6%96%87%E5%AD%97%E5%87%A6%E7%90%86%E3%81%AE%E9%81%95%E3%81%84/
＞ 現状市場に製品としてリリースされているWindowsはベースのキャラクターセットとしてはUNCODEを用い、標準のエンコードはUTF-16LE。基本的にはOSの標準APIレベルでI18N,M17Nに対応している。
- 713 ：デフォルトの名無しさん：2021/04/05(月) 21:45:31.84 ID:OztXbvyw.net
- うんこーど
- 714 ：デフォルトの名無しさん：2021/04/05(月) 22:03:05.34 ID:2g7RifS+.net
- ユニコードには、UTF-8/16/32 の3つあって、
各OS・ファイルシステムによって異なるから、ややこしい
だから、システム関係には、ASCII 互換の部分だけを使えと言ってる。
128種類、7 bit ascii だっけ？
- 715 ：デフォルトの名無しさん：2021/04/05(月) 22:20:28.93 ID:Hlip8dzv.net
- >>711
何見て言っているのか知らんけどプログラムで文字列扱っていれば内部処理がUTF-16LEなのは知っているはず
- 716 ：デフォルトの名無しさん：2021/04/05(月) 23:10:35.17 ID:r3L3lQkE.net
- >>703
Windowsは当面過渡期のままだよ
「ワールドワイド言語サポートで Unicode UTF-8 を使用」って設定は登場から3年経ってもベータのままだし
- 717 ：デフォルトの名無しさん：2021/04/06(火) 00:46:43.57 ID:+n99AGjS.net
- >>711
> 日本語版Windowsのデフォルトコードページは今でもCP932だが？
UTF-16だよ
だから日本語版Windowsで絵文字が使えるんだが？
CP932がどこで使われるのかわかってない？
- 718 ：デフォルトの名無しさん：2021/04/06(火) 00:47:44.91 ID:+n99AGjS.net
- >>710
コマンドプロンプトの問題で
Windows全体（エクスプローラーやブラウザ等）には
当てはまらないと認めるかい？ｗ
- 719 ：デフォルトの名無しさん：2021/04/06(火) 00:50:23.32 ID:+n99AGjS.net
- >>716
その上に「Unicodeに対応してない古いアプリの場合」って書いてあるやろ？ｗ
Unicodeに対応している新しいアプリはUnicodeだし
お前「Unicodeに対応してない古いアプリ」がUTF-8にしたら
動くようになるとでも思ってんの？Unicodeに対応してないのにｗ
- 720 ：デフォルトの名無しさん：2021/04/06(火) 01:02:50.31 ID:4WR5kIDO.net
- 最近のwin10アップデで古いwinアプリが文字化けしだしたのはこれか？
設定で対応できるし内部で一貫してる限り問題はないけど
- 721 ：デフォルトの名無しさん：2021/04/06(火) 01:05:08.37 ID:+n99AGjS.net
- >>720
どこの設定をどう変えたら対応できたんだ？
- 722 ：デフォルトの名無しさん：2021/04/06(火) 01:18:09.92 ID:4WR5kIDO.net
- >>721
うろ覚えだけど英語圏向けwin10固有の問題だったかと
日本語版と日本語設定の英語版が違うと言う罠
システムロケールを日本語(英語以外)に変えるとユニコにフォールバックするようで
コードページ切り替えオプションがまた別にあるけどグローバルに適用されるので今度は他が化ける、アプリごとに設定開くので非常に面倒くさい
- 723 ：デフォルトの名無しさん：2021/04/06(火) 01:21:01.30 ID:4WR5kIDO.net
- 化けたメニューを記号として認識できるように訓練したから最近は弄ってない
高くても日本語版買おうね！
- 724 ：デフォルトの名無しさん：2021/04/06(火) 01:27:04.53 ID:T8jVvgda.net
- ロートルが多いとか関係ないんだがな
若くたって古いシステムの吐くログを見ようと思ったらEUCだったりするんだよなあ
- 725 ：デフォルトの名無しさん：2021/04/06(火) 01:33:59.26 ID:4WR5kIDO.net
- ローカル版windowsには、スクリーン上に同時に存在するテキストを複数の方式でデコードする機能がある、でいいのかな
- 726 ：デフォルトの名無しさん：2021/04/06(火) 02:47:28.83 ID:iR3Vnnhg.net
- >>719
ASCIIにしか対応してないソフトはそれで意外と動いたりするんだよな
Unicodeファイル名が普通に使えるようになったり、というかそのための設定
マルチバイト対応してるソフトは壊れるけど
今ならmanifestでアプリ単位でコードページをUTF-8にするのもあり
- 727 ：デフォルトの名無しさん：2021/04/06(火) 03:58:58.47 ID:xQBleszy.net
- どうしたらいいのか
- 728 ：デフォルトの名無しさん：2021/04/06(火) 08:00:46.97 ID:zE9kqee/.net
- 窓から投げ捨てればいいのさ
- 729 ：デフォルトの名無しさん：2021/04/06(火) 08:27:12.05 ID:MTiaA6bM.net
- >>722
> 日本語版と日本語設定の英語版が違うと言う罠
Windows自体はUTF-16で複数の言語に対応しているとは言え、
アプリは別の問題で、UTF-16に対応してない古いアプリは
特定の文字コードでしか動かないんだよ
その古いアプリも手厚くサポートしてるのがWindows
- 730 ：デフォルトの名無しさん：2021/04/06(火) 10:13:01.08 ID:wM6kHA3V.net
- >>729
新しいソフトでもナローAPI使ってるやつたくさんあるわ特に欧米産。
ワイドAPI (UTF16)が標準とか思ってる時点で何もわかってない。
- 731 ：デフォルトの名無しさん：2021/04/06(火) 13:40:51.68 ID:tV10gXpM.net
- 何で文字コードスレにこんな無知がいるんだろうなあ。
- 732 ：デフォルトの名無しさん：2021/04/06(火) 15:39:19.88 ID:P0s3gsjp.net
- >>730
そのアプリ、絵文字使えないってことだよね？
いまどきそんなのあるの？
3つぐらい名前言ってよ
- 733 ：デフォルトの名無しさん：2021/04/06(火) 15:54:30.38 ID:wM6kHA3V.net
- >>732
そんなことはない。どうして使えないと思った? もしかしてコードページの使い方知らないの？
コードページを CP65001 や CP1200 に設定すれば使える。
コードページが CP932 だと使えないのは、もちろんだが。
- 734 ：デフォルトの名無しさん：2021/04/06(火) 16:20:50.90 ID:P0s3gsjp.net
- >>733
コードページは関係ないナローAPIを使ってると
絵文字は使えない
- 735 ：デフォルトの名無しさん：2021/04/06(火) 17:48:00.38 ID:wM6kHA3V.net
- >> 734
「コードページは関係ないナローAPI」 ← 自己矛盾。
俺のいうナローは Windows ならコードページ、Linux ならロケール依存なんだが？
他にどんな意味で解釈したの？ お前の定義を教えて。
その上で、お前の定義だとどうして絵文字が使えないのか解説して。
- 736 ：デフォルトの名無しさん：2021/04/06(火) 18:33:56.50 ID:iJXUWS4l.net
- 絵文字のデータとしての扱いとフォント依存による表示の区別付かないのかよ
- 737 ：デフォルトの名無しさん：2021/04/06(火) 22:47:03.03 ID:P0s3gsjp.net
- >>735
ナローAPIとそうでないAPIを具体的に言ってみ
- 738 ：デフォルトの名無しさん：2021/04/07(水) 01:36:05.17 ID:vjDi/c6S.net
- >> 737
誤魔化さずに、まずはこっちの質問に答えろや？ できるもんならな。
お前、まとともに複数の言語と文字コードに対応したプログラムとか組んだことないやろ？
中途半端な知識で知ったかぶりしてて、引っ込みつかなくなっただけなら、謝ればすむんやで。
匿名掲示板なんだから、謝ると負けとかはないぞ、勉強して出直せばいい。
謝るのが、めんどくさかったら ROM っとけ。
- 739 ：デフォルトの名無しさん：2021/04/07(水) 01:55:04.39 ID:vjDi/c6S.net
- しかし、あれだな。
ナロー系のデフォルトは今後 UTF-8 になっていくって話してるのに、
「ナローだと絵文字使えない」とか言い出すやつが湧くのは、どうしたもんだか。
基礎知識が足りてないのか、文脈読めないのか、その両方なのか。闇は深い。
- 740 ：デフォルトの名無しさん：2021/04/07(水) 02:26:54.44 ID:g0cTo5ct.net
- 喧嘩腰なのはいいけどレスアンカくらいちゃんと書こうよ >>の後のスペースは不要
- 741 ：デフォルトの名無しさん：2021/04/07(水) 04:00:51.96 ID:APsY2wPt.net
- ナロー系ってなんだ？
オレオレ用語で言ってても誰にも通じない
- 742 ：デフォルトの名無しさん：2021/04/07(水) 04:16:35.54 ID:K+K6a3YU.net
- あれや、トラックに引かれて死ぬが異世界に転生
そこではなぜかチートじみたものすごい能力が・・
- 743 ：：2021/04/07(水) 05:15:10.31 ID:ALhqLzoC.net
- >>741
win32api の一部の api （文字列を与えるもの）は同一機能で W系とA系の両方が準備されていますが、
そのうちの A系のことをナロー系と呼んでいるのでは？
- 744 ：デフォルトの名無しさん：2021/04/07(水) 07:09:32.19 ID:dkOgfJAM.net
- >>735
Windowsでもロケールじゃないかな？
ここで言ってるコードページってどこで設定するやつ？
- 745 ：デフォルトの名無しさん：2021/04/07(水) 09:06:06.52 ID:hP9Ops4B.net
- Linuxはロケールの設定（LANGとかLC_ALL環境変数）でja_JP.UTF-8 みたいに
言語（ja_JP）と文字コード（UTF-8）の両方をいっぺんに設定するけど
本来この２つは別の概念
Windows NT系はOSが使う文字コードはUTF-16に統一されている
ロケールに相当する設定は「設定」の「地域」から「日本」等を選ぶ
これはUIで使用する言語やカレンダーの書式なんかを変更するが
文字コードはUTF-16しかないので変わることはない
これとシステムロケールの設定（コードページ）は別物
システムロケールの設定はUnicodeに対応してないアプリ（主にWin9x用）が
どの文字コードを使っているか？を推測するための互換機能
Windows 10でこのシステムロケールの設定としてUTF-8（ベータ機能）が追加されたから、
今後は（ユーザーがUTF-8に設定していれば）ANSI系APIでもUnicodeを使うことが可能になった。
もちろんOS内部はUTF-16に統一されてるので、UTF-8からUTF-16へ変換される
ANSI系APIでUnicodeが使えるようになったといっても、それはUTF-8対応で開発した新しくアプリの話
昔のSJIS前提で開発したアプリが自動的にUnicode対応に変わることはない。
Unicodeに対応してない古いアプリはASCII互換部分以外は文字化けする。
あくまで新しいアプリをUnicode対応で開発するときの選択肢の一つとして
ANSI系も使えるようになりましたよーという話
これはユーザーにUTF-8に変更してもらえる（＝古いアプリを使ってない）ことが前提
- 746 ：デフォルトの名無しさん：2021/04/07(水) 09:06:55.52 ID:vjDi/c6S.net
- >>741
俺も「ナロー」がそれほど良い用語だと思ってるわけではないけど Linux,Mac,Windows で共通の良い技術用語がないので、マシな方なんだよ。
Unix系の用語だと「ワイド文字」の対義語は「多バイト文字」なんだが、これだとさらに誤解する人多いしなあ。1バイト ASCIIでも「多バイト」ってなんだ？的な。
- 747 ：デフォルトの名無しさん：2021/04/07(水) 09:15:40.29 ID:EM71BOqG.net
- コードページはLC_CTYPE相当であってLANGやLC_ALLではない
CP932はLC_CTYPE=ja_JP.SJISのようなもの(CP932≠ShiftJISだけど)
なのでWindowsのデフォルト日本語環境はmacOSやLinuxのja_JP.UTF-8とは違う
それにUTF-8に対応するCP65001だけでなくEUC-JPに対応するCP20932もだいぶ昔から
前から存在している
あとこの辺のロケール関係はISO C C95で規定
Windows固有の話ではない
- 748 ：デフォルトの名無しさん：2021/04/07(水) 09:18:43.08 ID:oaQMbN7A.net
- このスレの人たちはエディタで書いたソースを何で保存するの？UTF-8？
秀丸はデフォルトでSJISだったよね？(今は違うのか？)
- 749 ：デフォルトの名無しさん：2021/04/07(水) 09:19:55.48 ID:hP9Ops4B.net
- >>747
> Windowsのデフォルト日本語環境はmacOSやLinuxのja_JP.UTF-8とは違う
Windowsのデフォルト日本語環境は
1. OSの文字コード・・・UTF-16統一
2. ロケール（UIやカレンダーなど）・・・日本語
3. Unicode非対応の古いアプリ用、CP932に設定
いい加減システムロケールというのは
OSのデフォルトとは関係ないと認識してくれ
- 750 ：デフォルトの名無しさん：2021/04/07(水) 09:21:37.00 ID:hP9Ops4B.net
- >>748
ずっと前（Windows 2000の頃）から
Linuxと相互運用するものはUTF-8
Windowsでしか使わないソースコードはUTF-16だよ
Windowsでしか使わないものは少ないからほとんどUTF-8だけど
- 751 ：デフォルトの名無しさん：2021/04/07(水) 09:24:13.21 ID:hP9Ops4B.net
- あと秀丸とかとうの昔に使うのをやめた
遅くともSublime Text（2008年ごろ？）からUTF-8に統一
atomを経て今はvscode
それまでは何使ってたっけ？vimとかemacsとか一時期使ってたけど
そういや昔はLinuxではEUC-JPを使ってたね
- 752 ：デフォルトの名無しさん：2021/04/07(水) 10:21:35.02 ID:gW8in2Np.net
- Win10 1803でANSI APIでUTF-8を使うようにする設定がベータで入ったけど、
結局MSは影響が大きすぎると判断したんだろう
代わりに1903で、システム全体じゃなくてアプリ単位でUTF-8を使えるようにする機能が入った
ANSI APIのデフォルトがシステム全体でUTF-8になるのは5年とか10年先の話じゃないかな
- 753 ：デフォルトの名無しさん：2021/04/07(水) 11:34:30.51 ID:hP9Ops4B.net
- > ANSI APIのデフォルトがシステム全体でUTF-8になるのは5年とか10年先の話じゃないかな
> 結局MSは影響が大きすぎると判断したんだろう
MSじゃなくても影響が大きいってわかるわ。デフォルトをUTF-8にするのは
古いアプリとの互換性を切り捨てるってことを意味する
デフォルトにしていいのは、既存のUnicodeに対応してないアプリが消え去って
互換性を気にしなくていい時代になってから。それぐらい時間がかかるのは当たり前だろう
アプリ単位でUTF-8が使えるならそれで十分でしょ
UTF-8用に作られたアプリは、システムロケールをUTF-8にするように
マニフェストかなにかで設定できるだろうし
Windows NTのデフォルトの文字コードがUTF-16に統一されてるわけだから
わざわざ古いアプリの方のデフォルトを変更する理由がない
- 754 ：デフォルトの名無しさん：2021/04/07(水) 12:27:49.00 ID:hP9Ops4B.net
- システムロケール（本来は古いアプリ用の設定）を
UTF-8に変更することの意味をわかってない人がいるようだから
くどいようだけどまとめておく
1. システムロケールでUTF-8を設定できるようになったのはWin10 1803から
2. 日本語をSJISで使うアプリが、システムロケールがSJISになってるのを前提としていたように
システムロケールがUTF-8になってることを前提としてアプリを作らなければいけない
3. つまりWin10 1803登場より前にシステムロケールUTF-8に対応してるアプリは存在しない
Windowsの本来の文字コードであるUTF-16に対応してるアプリ＝Unicodeや絵文字に対応してるアプリは
そもそもシステムロケールの設定には何も依存しない。
今現在システムロケールUTF-8に対応したアプリは殆どないのに
互換性を壊してまで今すぐデフォルトを変更してメリットあると思う？
そういう話。
これからはUTF-8前提で作られたアプリ（Linuxアプリ等）はWindowsに移植しやすくなりますよ。
これからはUTF-8前提で作ってもWindowsとLinuxに両対応出来ますよ。という話
- 755 ：デフォルトの名無しさん：2021/04/07(水) 13:30:36.82 ID:gW8in2Np.net
- ASCII専用の欧米ソフトは案外その設定で動いたりするんだよ
ASCII圏のユーザーにとってはチェックを入れるだけでUTF-8が使えるようになる（かもしれない）便利設定
別に新しく開発するアプリのための設定というわけではない
マルチバイト圏のユーザーにとっては互換性壊すだけの余計な設定だが
ちなみにANSI APIでUTF-8を使う際には、パス名がMAX_PATHバイトまでしか扱えないという
重大な欠点があるのは注意な
Wide APIならMAX_PATHコードユニットだから、それに比べると扱える文字数は最悪1/3になる
- 756 ：デフォルトの名無しさん：2021/04/07(水) 14:39:04.07 ID:UOCtMYlF.net
- Unicode and Character Sets
https://docs.microsoft.com/ja-jp/windows/win32/intl/unicode-and-character-sets
Unicode in the Windows API
https://docs.microsoft.com/ja-jp/windows/win32/intl/unicode-in-the-windows-api
- 757 ：デフォルトの名無しさん：2021/04/07(水) 16:22:47.71 ID:vjDi/c6S.net
- >>753
間違い。昔から複数の文字コードで動くプログラムはある。
コードページ切り換えによって SJIS でも KOI8 でも BIG5 でも動くように作られているプログラムは、
修正無しで UTF-8 にも対応するようになる。
そもそもコードページの切り換えにちゃんと対応したプログラムはそうなってるのが普通。
SJIS専用処理とかしてるアホが作ったプログラムは、修正が必要だが、それは複数文字コード対応できてないんだから仕方ない
- 758 ：デフォルトの名無しさん：2021/04/07(水) 17:58:42.18 ID:bf9TqbnX.net
- アプリ単位でUTF-8が使えるようになってたの知らなかった
横からだけどありがとう
https://superuser.com/questions/1033088/is-it-possible-to-set-locale-of-a-windows-application-to-utf-8/1451686#1451686
のUpdateのところに対応方法がまとまってた
- 759 ：デフォルトの名無しさん：2021/04/07(水) 20:05:39.59 ID:dkOgfJAM.net
- >>757
一般論としてはそうだけど、WindowsのANSI系APIやVSのCRTが本当に全部UTF-8に対応してるんだっけ？
- 760 ：デフォルトの名無しさん：2021/04/07(水) 21:05:32.99 ID:7mS/mNQI.net
- コマンドプロンプトとサロゲートペア縛り
https://zenn.dev/zetamatta/books/b820d588f4856bcf836c/viewer/95bfb9
- 761 ：デフォルトの名無しさん：2021/04/07(水) 22:56:12.09 ID:vjDi/c6S.net
- >>759
Windows には山ほどライブラリ(DLL)があって、その中には対応できてなかったり、できてるはずなのにバグバグなやつとか多数ある。
今後のアップデートで直るかもしれないやつも多数あるけど、仕様上どうやって直すんだ？！ みたいなやつもある。
一般論でしかないのは、その通り。過渡期なんだよ。
一方で Microsoft は CP_ACP はもう使うな CP_UTF8 使えとか言い出してる。
- 762 ：デフォルトの名無しさん：2021/04/07(水) 23:51:48.85 ID:hP9Ops4B.net
- > 一方で Microsoft は CP_ACP はもう使うな CP_UTF8 使えとか言い出してる。
そりゃそうだろ。CP_ACPは古いアプリが使ってるかもしれないが
それじゃUnicodeには対応できない。文字数とかサロゲートペアが
正しく判断できない。ANSI系でUnicode使うなら書き換えが必要
- 763 ：デフォルトの名無しさん：2021/04/08(木) 01:14:14.46 ID:osA77g/q.net
- >>762
ACP でも UTF8 や UTF16 が使えること知らない人は引っ込んでて。
- 764 ：デフォルトの名無しさん：2021/04/08(木) 07:51:09.35 ID:65tq2lAC.net
- CP_ACPとかってMultiByteToWideChar以外どこで使うんだっけ
- 765 ：デフォルトの名無しさん：2021/04/08(木) 08:24:03.75 ID:5KgENm+i.net
- 相手するなよ
- 766 ：デフォルトの名無しさん：2021/04/08(木) 14:33:47.10 ID:BYjSvKlS.net
- 過渡期30年
まだまだ続く過渡期
- 767 ：デフォルトの名無しさん：2021/04/08(木) 16:48:36.55 ID:osA77g/q.net
- コンピュータのコードなんてずっと更新中みたいなもんだけど。
MS が UTF-8 のサポートをまともに開始したのは 2017年から。
古い文字コードを捨てて,今後は UTF-8 のみを推奨ってアナウンスしたのが 2019年から。
30年が何を指すのかしらんけど、あと5年や10年くらいは待ってやれ
- 768 ：デフォルトの名無しさん：2021/04/08(木) 16:51:08.06 ID:cADyO+yl.net
- バッチスクリプトをUTF8で走らせられるようになったの？
- 769 ：デフォルトの名無しさん：2021/04/08(木) 17:54:09.52 ID:osA77g/q.net
- 中で呼び出すプログラムが code pege 切り換え対応、もしくは utf8 対応ならバッチできるよ
例えば UTF-8 で以下のようなバッチを書けば、日本語Windowsでも動くよ
chcp 65001
echo かな漢字 > file.txt
type file.txt
pause
- 770 ：デフォルトの名無しさん：2021/04/08(木) 18:08:44.31 ID:UozSJGhl.net
- >>767
> 古い文字コードを捨てて,今後は UTF-8 のみを推奨ってアナウンスしたのが 2019年から。
古い文字コードを捨ててません。
新たにUTF-8対応を増やしただけです。
Linuxは古い文字コードを捨てましたか？捨ててないでしょう。
そんなアホなことをするOSなんてありませんよ。
- 771 ：デフォルトの名無しさん：2021/04/08(木) 18:11:58.41 ID:UozSJGhl.net
- >>768
それはずっと前から出来る。
少なくともWindows 2000では確認した。
ただ画面の表示がおかしくなっていただけ
処理結果はまともだった
- 772 ：デフォルトの名無しさん：2021/04/08(木) 18:17:12.48 ID:cADyO+yl.net
- マルチバイト文字を含むコマンド引数がただの文字列じゃなくて、ファイルパスだったりすると積むはず。
- 773 ：デフォルトの名無しさん：2021/04/08(木) 18:27:11.87 ID:UozSJGhl.net
- ファイルパスも文字列だろ
ところでなんでcp932に設定していても
絵文字が含まれたディレクトリにcdできると思う？
絵文字はcp932には含まれてない。だから使えるはずがない
だけどコマンドプロンプトでcp932にしても普通にcdできる
答えは、cp932は古いアプリ用であって
コマンドプロンプト自体はUTF-16で動いてるからなんだよ
WindowsはNTの時代にすでに完全にUnicode対応を終えてる
OSはUnicode（UTF-16）で動いている
cp932とかいうのは互換性機能でOSとしては重要ではなく
互換性機能をなくすのは、それが不要になってからで十分なわけ
- 774 ：デフォルトの名無しさん：2021/04/08(木) 19:21:17.04 ID:osA77g/q.net
- >>770
「捨てる」っていうのが正確で無かったか？ サポートをしないって意味ではなくて
「今後は書かれるプログラムは古い文字コードをサポートする必要はない。UTF-8 だけ排他的に使用することを推奨する」
という方針を打ち出したんだよ。もう前のことなのでニュース記事のリンクとか出せないけど、かなり話題になった。
開発者ドキュメント等を読めば買いてると思う。
- 775 ：デフォルトの名無しさん：2021/04/08(木) 19:30:38.81 ID:osA77g/q.net
- >>771
わかってて言ってるんじゃないかと思うけど、重要なのは echo の行ではなくchcp 65001 の話。
これで TYPE の行のように正しく画面表示されるし、他のバッチから呼び出されるプログラムも UTF-8 の切替わる。
pause の行のように言語が日本語から英語に切替わってしまうので、メッセージとか日本語じゃないと困る人には駄目な方式なんだが
- 776 ：デフォルトの名無しさん：2021/04/08(木) 19:46:39.13 ID:osA77g/q.net
- >>773
お前は、バッチファイルすらまとも使ったことないだろ？
内部コードと外部(入出力)コードの区別すらまともについてないくせに、いちいちコメントすんな。
Windowsの内部コードがUTF16のことなんて全員わかってるんだよ。
みんなが議論しているのは外部コードのはなし。コードページとかUTF-8とかも全部、外部コードに何を使うか。
バッチファイルの文字コードも外部コード。
マイクロソフトは外部コードを UTF-8 に統一する方向で動いてるって話をしてる。
- 777 ：デフォルトの名無しさん：2021/04/08(木) 20:50:56.63 ID:UozSJGhl.net
- >>774
> 「今後は書かれるプログラムは古い文字コードをサポートする必要はない。UTF-8 だけ排他的に使用することを推奨する」
前からUnicode（UTF-16）推奨だったじゃん。
今後は書かれるプログラムは古い文字コードをサポートする必要はないのは
UTF-16でも同じことで、古い文字コードをサポートする必要なんてなかった
単にANSI系でもUTF-8が使えるようになりましたってだけだよ
- 778 ：デフォルトの名無しさん：2021/04/08(木) 20:54:30.34 ID:UozSJGhl.net
- >>776
> マイクロソフトは外部コードを UTF-8 に統一する方向で動いてるって話をしてる。
そんな動きないよ
今だって標準はUTF-16だし、UTF-8もサポートしたと言うだけの話
- 779 ：デフォルトの名無しさん：2021/04/08(木) 20:58:09.07 ID:UozSJGhl.net
- > みんなが議論しているのは外部コードのはなし。コードページとかUTF-8とかも全部、外部コードに何を使うか。
違うよ。コードページは古いアプリが使うコードのことだよ
- 780 ：デフォルトの名無しさん：2021/04/08(木) 21:26:50.32 ID:PAVlbVqd.net
- 古いだの新しいだのそういう曖昧な言葉を使うのは良くない
- 781 ：デフォルトの名無しさん：2021/04/08(木) 21:44:00.84 ID:5KgENm+i.net
- 入出力時のデフォルトコードページの話だから古いか新しいかなんて関係ないんだけどな。
いい加減みんなこのバカ相手するのやめようぜ。
- 782 ：デフォルトの名無しさん：2021/04/08(木) 22:03:05.49 ID:cADyO+yl.net
- マイクロソフト謹製のPowerShellは完全にコードページ依存だよ。
MSYSなどUTF8で出力する伝統的な実行バイナリとうまく共存できない。パイプが積む。それが現実。
- 783 ：デフォルトの名無しさん：2021/04/08(木) 23:16:12.03 ID:u7kxAAh5.net
- さすがに、このスレにいて Windowsの「メモ帳」アプリのデフォルト文字コードが「 UTF-8 (BOM無し)」に変更されたことを知らない人はいないだろ。
これはMSが UTF-8 BOM無しを今後の標準とすることに舵を切った結果だよ。
これが UTF-16 だったり BOM つきだったりしないのは、単なる気まぐれじゃない。
- 784 ：デフォルトの名無しさん：2021/04/09(金) 01:54:21.80 ID:ZRNzIbD0.net
- BOM付きじゃなくてBOM無しUTF-8がデフォルトになったのは驚いた
そっちに舵を切ったのはそうだろう
だがExcelでBOM無しUTF-8なCSVが扱えないとか、リソースコンパイラで
BOM付きUTF-8すら自動判別してくれないとか個々のアプリはまだまだ対応不足
- 785 ：デフォルトの名無しさん：2021/04/09(金) 01:56:45.03 ID:s5EJohG2.net
- デフォはありのほうがいいと思うんだがな
- 786 ：デフォルトの名無しさん：2021/04/09(金) 03:06:58.40 ID:3uc6Yjpo.net
- >>780
厳密に言うならANSI系のAPIを使ってるアプリのこと
このAPIは元々Win9x用で（UTF-8に対応が発表されるまで）
Unicodeに対応してない古いアプリ用だった
つまりUnicodeに対応しているアプリは
UTF-16を使っていたということ
もちろん内部文字コードとしてUTF-8を使ってるアプリもあるだろうが
それは今も昔も変わらずUTF-8が使える
そういうアプリはOSへ処理を渡すときにUTF-16に変換して渡してる
その変換は正しく作っているなら自動的に行われるのでさほど面倒ではない
なのでアプリ開発側からすれば、そんなにメリットはない
これからはANSI系APIも使えますよーと今更言われた所で
元からUTF-8を使ってるアプリは、UTF-16への（自動）変換が
省略できる程度の意味しかない
今どきWindowsのAPIにバリバリ依存して作ることなんてないしね
- 787 ：デフォルトの名無しさん：2021/04/09(金) 03:08:04.84 ID:3uc6Yjpo.net
- >>783
> さすがに、このスレにいて Windowsの「メモ帳」アプリのデフォルト文字コードが「 UTF-8 (BOM無し)」に変更されたことを知らない人はいな
> これはMSが UTF-8 BOM無しを今後の標準とすることに舵を切った結果だよ。
なあ。お前。メモ帳以外の事例は存在するか？
一テキストエディタにすぎないメモ帳のデフォルトが
変わった程度で騒ぎ過ぎだよ
- 788 ：デフォルトの名無しさん：2021/04/09(金) 04:36:09.91 ID:l1/kJ2NK.net
- はぁ？
クロスプラットフォームで開発されている実行バイナリはC/C++案件が多いから、WindowsのAPIにバリバリ依存だよ
.NETなんてLinuxやmacOSで動かないだろ
- 789 ：デフォルトの名無しさん：2021/04/09(金) 09:51:30.06 ID:dDP8WojW.net
- >>786
> 今どきWindowsのAPIにバリバリ依存して作ることなんてないしね
Windows の API 使わずにプログラムとかww
それこそ fopen() とかの標準Cライブラリこそコードページ依存だろ。もしかしてそれすら知らない？
Mac 使いですか？ それとも Java屋さん？
Windows の API まともに知らないやつが プログラム版で Windows について語ってんの？
- 790 ：デフォルトの名無しさん：2021/04/09(金) 10:10:06.15 ID:3uc6Yjpo.net
- > Windows の API 使わずにプログラムとかww
え？知らんの？そういうのは言語やライブラリが解決してくれるんだよ。
.NET フレームワークとか、nodeとかrubyとか
Windows APIを使わないことなんて当たり前
- 791 ：デフォルトの名無しさん：2021/04/09(金) 10:12:26.81 ID:3uc6Yjpo.net
- > .NETなんてLinuxやmacOSで動かないだろ
動くじゃん
- 792 ：デフォルトの名無しさん：2021/04/09(金) 10:21:23.24 ID:7vOVb2O0.net
- EcxelがBOMなしのCSV読めんからな
メモ帳がBOM無しでも関係ないな
- 793 ：デフォルトの名無しさん：2021/04/09(金) 11:02:02.21 ID:dDP8WojW.net
- それ以前に .Net デフォルトだとコードページ依存じゃないかwww
ruby は Windows のプログラムじゃないし。
node って何? もしかして Node.js のこと？ まさか JavaScript 基準で Windows の文字コード語ってたの？
さすがに、それはないよね...。
node というのは聞いたことない、もしくはどれを指すのが不明なので教えて。
- 794 ：デフォルトの名無しさん：2021/04/09(金) 12:38:07.07 ID:3OIwAD6R.net
- >>745
話題持ち込んじゃった人だけど分かりやすい
ありがとう
- 795 ：デフォルトの名無しさん：2021/04/09(金) 15:21:47.85 ID:tQcHQU6Y.net
- nodeはオワコン
るuびyはもっとオワコン
- 796 ：デフォルトの名無しさん：2021/04/09(金) 17:38:21.19 ID:3uc6Yjpo.net
- >>793
ああ、今どきのWindowsプログラムを知らんのね
例えばvscodeはJavaScriptで出来てるんだよ
.NETがコードページ依存って何を言ってるんだろうか
- 797 ：デフォルトの名無しさん：2021/04/09(金) 18:36:32.22 ID:dDP8WojW.net
- > .NETがコードページ依存って何を言ってるんだろうか
入出力用の文字コードの概念がないやつには一生理解できないだろう(確度の高い予測)
他の人のためにリンク張っとく
https://docs.microsoft.com/en-us/dotnet/api/system.text.encoding.default
ちなみに Linux とかでも動くオープンソース版の .NET Core はコードページないので、UTF-8 (BOM無し)になる。
- 798 ：デフォルトの名無しさん：2021/04/09(金) 18:47:45.05 ID:3uc6Yjpo.net
- >>797
そんなの出されても意味がないなぁ。
言語の内部コードと、外部コードの違いわかってる？
例えばPythonの文字コードはUTF-8なわけ
それをStreamRecodeを使って自動的に外部文字コードに変換する時
https://docs.python.org/ja/3/library/codecs.html#streamrecoder-objects
Pythonの文字コードはSJISだ！コードページに依存してるんだ！なんて言わないでしょ
.NETも内部の文字コードはUnicodeなわけ
外部への文字コードへの自動変換を備えてるけど
それはほとんどの言語で標準的に持ってる機能なわけ
- 799 ：デフォルトの名無しさん：2021/04/09(金) 18:48:43.58 ID:S5JYCJ7D.net
- そういえば、関係ないけど vscode も UTF-8 BOM無しが規定文字コードだね。
メモ帳だけじゃなくてテキストエディタは UTF-8 ってことか。
- 800 ：デフォルトの名無しさん：2021/04/09(金) 18:51:28.05 ID:3uc6Yjpo.net
- >>797
> ちなみに Linux とかでも動くオープンソース版の .NET Core はコードページないので、UTF-8 (BOM無し)になる。
デフォルトで入ってないだけ
PowerShell on Linux(Mac)でShift-JISを扱う
https://blog.shibata.tech/entry/2016/08/22/231538
- 801 ：デフォルトの名無しさん：2021/04/09(金) 19:25:48.50 ID:dDP8WojW.net
- >>798
> 言語の内部コードと、外部コードの違いわかってる？
お前がわかってないのは知ってる。ソースコードの文字コードを内部コードと勘違いしてるとか
Python の内部コードが UTF-8 だと思ってるあたり素人丸出し。
Python の内部文字コードはかなり昔から UTF-32 (UCS4) だよ。それ以前は UCS2。
- 802 ：デフォルトの名無しさん：2021/04/09(金) 19:33:45.09 ID:dDP8WojW.net
- >>800
> デフォルトで入ってないだけ
デフォルトのエンコーディングの話してたの忘れたの？
入出力用の文字コードが切り換えできるのは当り前で、そのデフォルトが何かっていう話をしてるんだけど
- 803 ：デフォルトの名無しさん：2021/04/09(金) 21:16:02.60 ID:ZRNzIbD0.net
- >>801
ID:3uc6Yjpoは何を言ってるのか分からんのでほっとくとして、
Python 3.3からはメモリ使用量節約のため、latin1, UCS2, UCS4の自動切り替えな
https://www.python.org/dev/peps/pep-0393/
- 804 ：デフォルトの名無しさん：2021/04/09(金) 22:16:54.05 ID:3uc6Yjpo.net
- >>802
だから.NETのデフォルトはUnicodeだろ
.NETアプリが世界中の文字に対応してるってわかってますかー？
- 805 ：デフォルトの名無しさん：2021/04/10(土) 01:56:42.91 ID:Tkmy4TcV.net
- >>803
正確にはそうだね。
ややこしい話しても絶対ついてこれないだろうと思ったの最終的に UTF=32 に落ちるのでいいかと思って簡略化しちゃった。
そこまで、ちゃんとわかってる人がいて良かった。訂正サンクス。
レベル低いの混ると、ついついレベル低い回答になってしまう。
- 806 ：デフォルトの名無しさん：2021/04/10(土) 07:57:12.51 ID:wS2LKV0q.net
- .NETアプリが絵文字を表示できるのはなんで？
- 807 ：デフォルトの名無しさん：2021/04/10(土) 07:59:08.31 ID:wS2LKV0q.net
- WPFアプリって言ったほうが正確かな？
- 808 ：デフォルトの名無しさん：2021/04/10(土) 09:09:41.00 ID:AcLZ31++.net
- 互換性のせいでコマンドプロンプトの仕組みが複雑だから勘違いしてるんだろうけど
コマンドプロンプト自体はUTF-16で動いてる
そうでなければUnicode文字を使ったファイル名とかが表示できるわけがない
それに対してコンソールアプリケーションはUnicode（UTF-8、UTF-16、UTF-32いずれにも対応）で
出力するモードとANSIで出力するモードを選べる
Unicodeで選んだらOSによってUTF-16に変換されてコマンドプロンプトに出力される
ANSIモードで出力した場合、OSが自動的にUnicodeに変換してコマンドプロンプトに出力する
このANSIモードからUnicodeに変換するときに利用する情報がコードページ
コンソールアプリケーションは、どれでも好きな文字コードで出力してくださいってだけだよ
コードページの情報を利用するもしないも自由
コードページの情報を無視してSJISで出力することだって出来る
まあそんな事するとコマンドプロンプト上では文字化けするがファイルに出力すればなんの問題もない
Unicodeに対応してるアプリはUnicodeモードで出力するだろうね
作り込んでるアプリなら、コードページに従うだろうねってだけの話
- 809 ：デフォルトの名無しさん：2021/04/12(月) 18:22:40.83 ID:rYLpZPiw+
- フリーランスに立ちはだかる「常駐」の壁。慣例を打ち壊し、
“テレワーク”案件3割→8割へと成長を遂げた「クラウドテック」の軌跡
https://prtimes.jp/story/detail/DBnPOktyljr
テレワークの一般化により、11月にはテレワーク可能案件83.7%へと増加。
2021年、フリーランスのトレンドは「移住＆テレワーク」と予測
https://prtimes.jp/main/html/rd/p/000000045.000050142.html
リモートワーク求人専門サイト「プロリモート」がリニューアルオープン、業務委託契約の求職者と企業をマッチング
https://www.value-press.com/pressrelease/262778
1/3以上が採用につながる高マッチング率、リモートワーク×エンジニア・デザイナー専門の
人材紹介サービス「ReworkerAgent」正式リリース場所からも時間からも自由な働き方を実現！
https://www.nishinippon.co.jp/item/o/713384/
フリーランスエンジニア必見！リモートワークや週3案件があるサービス5
https://yokowork.biz/week3_engineer/
地方在住者と都市部の仕事をつなげるリモートワークに特化したリクルートサイト
「remoteworkers」ワーカー事前募集開始
https://prtimes.jp/main/html/rd/p/000000002.000072591.html
- 810 ：デフォルトの名無しさん：2021/04/14(水) 13:39:34.45 ID:hz0wFRHA.net
- 練習
⥁⥀
⟳⟲
↻↺
⤾⤿
⤸⤹
- 811 ：デフォルトの名無しさん：2021/04/14(水) 15:39:07.59 ID:hz0wFRHA.net
- 🌍🌎🌏
サロゲ
- 812 ：デフォルトの名無しさん：2021/04/14(水) 15:40:00.22 ID:hz0wFRHA.net
- win10
コマンドプロンプトで
chcp 65001
でも
>>811
は化けたわ
- 813 ：デフォルトの名無しさん：2021/04/14(水) 19:39:34.04 ID:35zwdl55.net
- >>811
Windows 10 のIEで表示できた
色はつかんかったけど
もちろんEdgeなら色付きで表示できた
- 814 ：デフォルトの名無しさん：2021/04/14(水) 19:47:01.17 ID:35zwdl55.net
- >>812
フォントの問題だからね
echo その文字 > test.txt とかやってファイルに書き出したら
cmd /UのUnicodeモードでUTF-16LEで問題なく保存されたよ
もちろんcmd /Aだとchcp 65001でUTF-8にしたら保存される。
- 815 ：デフォルトの名無しさん：2021/04/14(水) 19:49:01.33 ID:35zwdl55.net
- × フォントの問題だからね
○ 表示周りの問題だからね
データ自体は問題なく扱えるといいたかった
- 816 ：デフォルトの名無しさん：2021/04/17(土) 14:25:57.05 ID:zVeqA+50.net
- Clarify guidance for use of a BOM as a UTF-8 encoding signature
https://www.unicode.org/L2/L2021/21038-bom-guidance.pdf
・Do not use U+FEFF as a ZWNBSP character; use U+2060 WORD JOINER instead.
・Include a BOM if one is known to be required by a targeted protocol.
・Otherwise, include a BOM when authoring a UTF-8 text file that contains non-ASCII characters,
is not targeting a specific protocol, and may be opened by applications that will not assume UTF-8 by default
(this is useful on systems like Microsoft Windows where some applications assume text files to be encoded with the Active Code Page).
・Otherwise, do not include a BOM.
- 817 ：デフォルトの名無しさん：2021/04/17(土) 15:20:55.47 ID:ijYyB/Qg.net
- >>814
/u スイッチで出力されるUTF-16LEはBOMなしなんだな
開けないエディタもあった
- 818 ：デフォルトの名無しさん：2021/04/17(土) 16:07:47.50 ID:WTle60vg.net
- >>816
要約：明示的に必要とされる場合以外は UTF-8 に BOM 入れるな。
- 819 ：デフォルトの名無しさん：2021/04/17(土) 16:17:49.74 ID:WqZ6rzHC.net
- そうでない場合は、非ASCII文字を含み、特定のプロトコルを対象としておらず、デフォルトでUTF-8を想定していない
アプリケーションで開かれる可能性のあるUTF-8テキストファイルを作成するときに、BOMを含めるようにしてください
（これは、Microsoft Windowsのように、一部のアプリケーションがテキストファイルをActive Code Pageでエンコード
することを想定している場合に有効です）。
- 820 ：デフォルトの名無しさん：2021/04/17(土) 19:34:14.90 ID:HVVFTxep.net
- >>817
BOMがなにか知っていれば、そんな感想はでてこないはずなんだがな
BOMっていうのは文字コードが「不明なモノ」を認識するためのものだよ
最初から「UTF-16である」と決まってるなら当然BOMはない
出力はUTF-16と決まってるのだから当然BOMは不要
それを文字コードが決まってないファイルに
出力したお前がつけるべきもの
ファイル形式によってはUTF-16と決まってる場合もあるだから
勝手につけるようなことはしない
- 821 ：：2021/04/17(土) 19:54:12.40 ID:OAsiuDOF.net
- >>820
というか、UTF-16 における BOM って Byte Order Mark という本来の意味の方が大きいと思いますが
もっとも私はアプリ内では全部例外なく UTF-32, win32api に渡すときは UTF-16 に変換, コンテンツの外部表現は UTF-8 にしていますけれども
- 822 ：デフォルトの名無しさん：2021/04/17(土) 19:56:30.03 ID:HVVFTxep.net
- だから？
- 823 ：：2021/04/17(土) 20:33:08.95 ID:OAsiuDOF.net
- >>822
BOMっていうのは文字コードが「不明なモノ」を認識するためのもの、というよりは、エンディアンを知らせるためのものでは？BOM の意義はそちらの方が優勢では？
- 824 ：デフォルトの名無しさん：2021/04/17(土) 22:23:07.48 ID:WTle60vg.net
- 規格では
UTF-16LE はBOM付けない
UTF-16BE はBOM付けない
UTF-16 はBOM必要
これらは別物なので混同するのは良くない。
- 825 ：デフォルトの名無しさん：2021/04/17(土) 22:25:44.67 ID:+T2toyLY.net
- >>820
事実を明示しただけなのに、何ドヤってんだよ
- 826 ：デフォルトの名無しさん：2021/04/17(土) 22:30:24.80 ID:WTle60vg.net
- 819はUTF-16にBOMが必要という常識すら知らない素人。
- 827 ：デフォルトの名無しさん：2021/04/17(土) 22:57:11.23 ID:HVVFTxep.net
- UTF-16にBOMが必要なら、なぜついてないのか説明してくれ
- 828 ：デフォルトの名無しさん：2021/04/17(土) 23:00:00.38 ID:HVVFTxep.net
- >>824
規格書ぐらい読みましょう
https://www.unicode.org/versions/Unicode12.0.0/UnicodeStandard-12.0.pdf
The UTF-16 encoding scheme may or may not begin with a BOM. However,
when there is no BOM, and in the absence of a higher-level protocol, the byte
order of the UTF-16 encoding scheme is big-endian
UTF-16 のエン コ ーデ ィ ン グ方式は、 BOM で始ま る こ と も 、 そ う でない こ と も あ り ます。
し か し 、BOM がない場合、 ま た、 上位プ ロ ト コ ルがない場合、
UTF-16 符号化方式のバ イ ト 順序はビ ッ グエンデ ィ ア ンです。
- 829 ：デフォルトの名無しさん：2021/04/18(日) 01:25:27.08 ID:cX9tiBqs.net
- ちょくちょく >>824 みたいな読解力ない人が沸くよね
なんでだろ
- 830 ：デフォルトの名無しさん：2021/04/18(日) 04:36:32.83 ID:qeZOgBPb.net
- 要するに「UTF-16」のパターンは5種類あるってことだね
UTF-16BE 00 4D
UTF-16LE 4D 00
UTF-16 BOM(BigEndian) FE FF 00 4D
UTF-16 BOM(LittleEndian) FF FE 4D 00
UTF-16 BOMなし(=BigEndian) 00 4D
- 831 ：デフォルトの名無しさん：2021/04/18(日) 07:59:39.77 ID:3LjqZ5tA.net
- ビッグエンディアンとリトルエンディアンの2つだけだよ
あとはBOMがあるかどうかだけ
- 832 ：デフォルトの名無しさん：2021/04/18(日) 08:08:13.68 ID:cX9tiBqs.net
- base64エンコーディングを加えればバリエーションはさらに増えるよ
よかったね
- 833 ：デフォルトの名無しさん：2021/04/18(日) 08:12:27.46 ID:cX9tiBqs.net
- 玉子とかお新香つけたらバリエーションさらに増える
- 834 ：デフォルトの名無しさん：2021/04/18(日) 16:24:37.92 ID:124qy3KD.net
- >>830
五番目と最初は全く同じバイト構成になるので4種類が正解。
BOMなしの UTF-16 は実質 UTF-16BE の別名に過ぎない。
- 835 ：デフォルトの名無しさん：2021/04/18(日) 16:31:23.17 ID:R7mD8LSe.net
- BOMはパターンじゃなくて追加のシグネチャだよ
もしこれがHTMLだとしてUTF-8というメタタグがない場合
それはUTF-8とは別のパターンになるかと言ったらそうはならない
パターンとしては同じUTF-8であり
シグネチャがあるかどうかの違いでしかない
- 836 ：デフォルトの名無しさん：2021/04/18(日) 19:12:05.70 ID:NuVJC4bd.net
- BOMでこうまで話が続くのな
- 837 ：デフォルトの名無しさん：2021/04/18(日) 19:24:29.98 ID:Qxa4OXG6.net
- なつかしのfree論争みたいだな
- 838 ：デフォルトの名無しさん：2021/04/18(日) 21:03:03.56 ID:pcxeaSJf.net
- Malloc and Free
https://groups.google.com/g/fj.comp.lang.c/c/G4HRnHTdImg
- 839 ：デフォルトの名無しさん：2021/04/18(日) 22:24:15.55 ID:Qxa4OXG6.net
- >>838
うわなつかしい、俺のアドレスもあったw
- 840 ：デフォルトの名無しさん：2021/04/18(日) 22:45:16.09 ID:124qy3KD.net
- 議論の理由も似てるかも
free()が必要かどうかは環境による。基本は必要最低限で使え。
BOMが必要かどうかは環境による。基本は必要最低限で使え。
というのが正しい答えだが、特定の環境のみ前提に主張するやつや、
念のためにいれておこうと考える不届き者のせいで話が混乱する。
- 841 ：デフォルトの名無しさん：2021/04/19(月) 00:36:54.81 ID:NjT32G/K.net
- ぜんぜん違うな。BOMはUnicodeの仕様
- 842 ：デフォルトの名無しさん：2021/04/19(月) 00:38:28.03 ID:VxMGqS+h.net
- >>838
俺はこれ知らんかったけど、太田・久野・河野…とそうそうたるメンバーですなあ懐かしい
- 843 ：デフォルトの名無しさん：2021/04/19(月) 00:41:47.58 ID:NjT32G/K.net
- 昔はみんなバカだった
- 844 ：：2021/04/19(月) 00:43:04.40 ID:6sLSrXGT.net
- >>840
それに「そもそも BOM という名前が」云々の原理主義者もお忘れなく、あー私のことか‥‥
- 845 ：デフォルトの名無しさん：2021/04/19(月) 01:58:51.92 ID:mD3HRAYB.net
- つまりBOMの話題はプログラマ界隈にとって爆弾のようなものだ、とこういうことか
- 846 ：デフォルトの名無しさん：2021/04/19(月) 03:49:32.03 ID:v/IxVhS5.net
- >>845
ミニマム・シンプルというのがプログラムの基本というのが理解できないやつがいる。
「不必要なものは入れるな」というのは最低限の知識.
- 847 ：デフォルトの名無しさん：2021/04/19(月) 05:11:58.25 ID:krfx63YD.net
- パーセントエンコーディングした文字列を正確にURL引数に渡すには
文字エンコーディングをサーバーに教えるためのパラメーターが別途必要になる。
だが、しかしサーバー側アプリにはBOMの情報をまるっと捨て去って平然と不具合を起こす権利がある。
文字エンコーディングをサーバーに教えるためのパラメーターと同じ役割を果たすのがBOM。
テキストエディタやコンパイラやブラウザはBOMをガン無視する権利がある。
- 848 ：デフォルトの名無しさん：2021/04/19(月) 09:26:00.95 ID:v/IxVhS5.net
- すっげー、面白い解釈してるな。どの規格読んだの？
URI は全体で一つの文字列なので、BOM つけるのなら最初の https: とかの前につけないと意味ないんだが？
そんな規格違反の URI に対応する必要があるという主張? それとも文字列の途中に BOM を入れて解釈しろという主張？
- 849 ：デフォルトの名無しさん：2021/04/19(月) 09:31:04.91 ID:NjT32G/K.net
- >>846
ギチギチしたら拡張性がなくなるだろ
- 850 ：デフォルトの名無しさん：2021/04/19(月) 09:32:40.01 ID:NjT32G/K.net
- 不要なもの入れるな＝16bitあれば十分＝破綻ｗ
- 851 ：デフォルトの名無しさん：2021/04/19(月) 13:35:40.29 ID:v/IxVhS5.net
- それは不要なもの入れる入れないではなくて、拡張性のある実装と拡張性の乏しい実装の違い。
unicode の文字の中には余計なものもあることは認めるが、それは関係ない。
- 852 ：デフォルトの名無しさん：2021/04/19(月) 13:37:50.42 ID:qMbr31eM.net
- >>851
つまりUTF-32が正解ってことでしょ？
- 853 ：デフォルトの名無しさん：2021/04/19(月) 15:24:44.16 ID:v/IxVhS5.net
- その辺は既に結論が出てる。
UTF-8: 可変長だが ASCII 互換。欧米の文章で長さが最短化。必要なら32bitまで拡張可能。外部コードに最適
UTF-32: 固定長。必要なら32bit分の文字まで拡張可能。内部コードに最適。
UTF-16: メリットがない。拡張性ない。オワコン。将来は特定のOSやプログラム言語やアプリで過去の遺物として残る
- 854 ：デフォルトの名無しさん：2021/04/19(月) 16:02:17.06 ID:krfx63YD.net
- UTF-32が固定長なのはすべての文字が32bit長に収まる時期限定の話でしかない
いずれUTF-64を固定長として定義してUTF-32を可変長にせざるを得ない
そしていつの日かUTF-64も可変長になる日が来る
以後ループ
- 855 ：デフォルトの名無しさん：2021/04/19(月) 17:13:36.69 ID:qMbr31eM.net
- >>853
あのさ、UTF-32のBOMを無視するなよ
- 856 ：デフォルトの名無しさん：2021/04/19(月) 17:22:51.43 ID:qMbr31eM.net
- > UTF-8: 可変長だが ASCII 互換。欧米の文章で長さが最短化。
って言ってるのに、これが
欧米ではない文章だとUTF-16に劣るという
意味になるってわかってないのかな？
- 857 ：デフォルトの名無しさん：2021/04/19(月) 17:25:16.03 ID:qMbr31eM.net
- UTF-16だと2バイトですむのに、UTF-8だと3バイト必要だからな
データ量が33%増加する
- 858 ：デフォルトの名無しさん：2021/04/19(月) 18:49:55.06 ID:v/IxVhS5.net
- 日本語の漢字かな中心の文章や、中国語の文章などでは UTF-16 の方が短かくなるけど
欧米のやつらは日本語での長さなんて気にもかけないので。もはや UTF-16 はオワコンで意見が固まってる。
欧米のやつらはラテン・アルファベットで効率が良いことと、自分たちが大量に持っている過去のASCIIの資産との互換が最優先。
日本のすみっこで、いくら叫んでも世界の流れは変えられないのだ。
少し腹立つけど仕方ない。
- 859 ：デフォルトの名無しさん：2021/04/19(月) 20:32:37.17 ID:FUkgXBz9.net
- WindowsやJavaの内部エンコードに使われている限り生き続けるだけだろ。日本がどうとか関係ない。
>欧米のやつらはラテン・アルファベットで効率が良いことと、自分たちが大量に持っている過去のASCIIの資産との互換が最優先。
そのマルチバイトエンコーディングからUTF-16に乗り換えたWindowsやJavaの中の人は欧米なんだが。
もしかしたらUTF-8を推したいのかもしれないけど論理が支離滅裂。
- 860 ：デフォルトの名無しさん：2021/04/19(月) 21:18:27.77 ID:krfx63YD.net
- U+xxxxxxxxで表現されるバイト列をRAWデータで扱うための概念としてUTF-16,UTF-32は必要とされ続ける
- 861 ：デフォルトの名無しさん：2021/04/19(月) 21:27:04.16 ID:zdVd8UEw.net
- 合成文字があるのにいつまで固定長なんて幻想にしがみついてんだよ
- 862 ：デフォルトの名無しさん：2021/04/20(火) 03:31:33.46 ID:CoLJETkU.net
- これからはUTF-16の時代だって思うやつがいるんなら英語の掲示板に行ってぜひ布教してくれ。
もう世の中の流れは変わってることがわかる。昔に戻せるならやってみてくれ。
無理だと思うが、個人的には嬉しいので。
- 863 ：デフォルトの名無しさん：2021/04/20(火) 04:46:32.12 ID:fd+AEuq4.net
- git diff コマンドがUTF-16テキストファイルをバイナリ扱いして困る
- 864 ：デフォルトの名無しさん：2021/04/20(火) 08:00:32.57 ID:4H0suX3D.net
- これからはUTF-16の時代だなんて思う奴はまずいないだろうが、
これからもUTF-16の時代が続くと思う奴はいるだろう。
- 865 ：デフォルトの名無しさん：2021/04/20(火) 10:21:46.36 ID:fKxAzJTs.net
- 欧米の奴らも絵文字は使いたがる、これはある意味いいことかも。
- 866 ：デフォルトの名無しさん：2021/04/20(火) 10:27:53.52 ID:iwSiTlyl.net
- >>862
これからもなにもずっと前からUnicodeの時代で
UTF-16もUTF-8もその表現の一つでしかないんだが
WindowsのAPIは柔軟だから両方に対応してるね
- 867 ：デフォルトの名無しさん：2021/04/20(火) 21:54:20.56 ID:tx5tKo/k.net
- U+xxxxxxxxで表現されるバイト列をRAWデータで扱うためとしても
UTF-16は桁が足りないんだからUTF-16を使っている箇所はUTF-32に移行すべき
- 868 ：デフォルトの名無しさん：2021/04/21(水) 18:18:57.57 ID:e3R+sPu0.net
- ASCII文字も1文字=7bitを前提にした文字の並びになっているから
1文字=8bitを前提に文字の並びを変えて
ISO646による言語別の文字の変更（バックスラッシュが円マークになる）も
廃止すればシンプルになっていいね。
ISO8859でもASCII文字の部分は何も変えなかったのは
ASCIIとISO646が普及してしまって変えられなかったから？
- 869 ：デフォルトの名無しさん：2021/04/21(水) 18:25:00.32 ID:tWbCEelV.net
- 文字コードとフォントは別のものだから…
- 870 ：デフォルトの名無しさん：2021/04/21(水) 18:26:38.07 ID:U7I+mJcY.net
- 過去のファイルは編集されずにずっと残るんだから古いファイルを
開くために仕様や規格を廃止することは不可能だよ
これからの話しか見えてないのは視野が狭すぎる
- 871 ：デフォルトの名無しさん：2021/04/21(水) 20:28:41.18 ID:4tTi5uFJ.net
- 過去の文字コードってASCIIでしょ。だったらUTF-8でそのまま読めるじゃん。というのがアメリカンの発想。
ローカルなSJISなどというものは念頭にない。ASCIIに比べれば大した量ではないので変換でも何でもしろくらいに思ってる。
オープンソース系のアプリとか気の早いやつは、もうUTF-8以外のサポート切り捨てようとか本気で言い出してる。
まだ時期尚早と説得してるが、どうなることやら。
- 872 ：デフォルトの名無しさん：2021/04/21(水) 20:58:34.18 ID:nyleF7PB.net
- もうAltコード覚えてしまってるから勘弁して
まあ今もアプリ側でマップしてるだろうけど、文字セットの実装が失われると参照が難しくなり方言化が進む
なにより二重ループで一覧表生成出来なくなるだろうしやだー
- 873 ：デフォルトの名無しさん：2021/04/21(水) 21:14:40.01 ID:jJZA2zpG.net
- コードポイント=エンコードにできるはずの128-255を捨てるutf-8一人勝ちは避けたい
欧州文字セットでも記号類とか重宝する
8-bitクリーンかを気にする機会減ってきたし、新規参入の機会では
ダイアクリティカルマークは別バイトにすれば記号いっぱい詰め込めるだろ
- 874 ：デフォルトの名無しさん：2021/04/21(水) 21:40:19.43 ID:U7I+mJcY.net
- >>871
あのさ頭が悪いって言われるでしょ
過去のファイルの対応を切り捨てるのは現実的じゃないか
仕様や規格からShiftJISが消えることはないという話をしてるの
誰もアプリが使う文字コードの話なんかしてないの
- 875 ：デフォルトの名無しさん：2021/04/21(水) 21:40:20.19 ID:U7I+mJcY.net
- >>871
あのさ頭が悪いって言われるでしょ
過去のファイルの対応を切り捨てるのは現実的じゃないか
仕様や規格からShiftJISが消えることはないという話をしてるの
誰もアプリが使う文字コードの話なんかしてないの
- 876 ：デフォルトの名無しさん：2021/04/21(水) 21:56:14.69 ID:tWbCEelV.net
- Windows用実行バイナリの場合、システムの文字コードに依存したC言語ライブラリを使ってコンパイルされた実行バイナリが大部分だから、移行は簡単じゃないよ。
新しいライブラリにリンクするよう作り直したバイナリを再配布する必要がある。動作検証がたいへん
- 877 ：デフォルトの名無しさん：2021/04/21(水) 22:23:29.33 ID:U7I+mJcY.net
- >>876
例えばどんなのがありますか？
- 878 ：デフォルトの名無しさん：2021/04/21(水) 22:29:47.38 ID:nyleF7PB.net
- お堅くwin32API叩いて書かれたバイナリの互換性は驚異的だよな
MSが気まぐれに出しては忘れるフレームワーク叩いてたら知らんが
バイナリ配布文化を育ててしまった原因でもあるが、ここまで大事にしてきたのにエンコード対応なんかで折れてもらっては残念
win10(64bit)でoffice97が元気に動くのは誇っていい
- 879 ：デフォルトの名無しさん：2021/04/21(水) 23:04:31.38 ID:tWbCEelV.net
- >>877
ロケール指定する処理が省かれたC言語アプリ全般
- 880 ：デフォルトの名無しさん：2021/04/21(水) 23:10:54.40 ID:U7I+mJcY.net
- >>879
だからそれはどれかって聞いてる
- 881 ：デフォルトの名無しさん：2021/04/21(水) 23:11:26.55 ID:U7I+mJcY.net
- 大部分と言う割に、事例を一個も思いつかないなら矛盾してる
- 882 ：デフォルトの名無しさん：2021/04/21(水) 23:20:34.30 ID:tWbCEelV.net
- Cで書かれたレガシープログラムほぼ全部なので挙げるまでもないんだけど、有名どころだとPerlだね
システムコード以外の文字を含むファイル名をperlに引数で渡せない
- 883 ：デフォルトの名無しさん：2021/04/21(水) 23:26:30.87 ID:tWbCEelV.net
- Cで書かれたmain()関数にはシステムコードページで引数が渡されるのだけど、その時点で文字化けしてるので復元不能。
- 884 ：デフォルトの名無しさん：2021/04/22(木) 09:25:25.74 ID:lWdVtKH+.net
- >>881
お前、もう少し黙っとけ。無知過ぎる。
アホを晒し続けてるの実は同一人物だろ。
- 885 ：デフォルトの名無しさん：2021/04/22(木) 11:05:09.03 ID:24mwOh0d.net
- このスレ読んでるとハゲそう
- 886 ：デフォルトの名無しさん：2021/04/22(木) 11:48:03.64 ID:cA5EjL24.net
- >>868
勿論普及してたからはあるだろうけど、そもそも変えるとかまた作り直すとかいう発想が無かったんじゃないかな。
ASCII制定→ISO 646制定→各国で変えられるのは10文字とか足りる訳無いだろ！→
ASCIIを拡張して8ビットフルに使おう→ISO 8859制定
とかそんな流れでしょ、増やして積んでけばいいと。当時のことは資料でしか知らないけどたぶん。
- 887 ：デフォルトの名無しさん：2021/04/22(木) 20:15:21.29 ID:H07mHdZr.net
- メールで添付ファイルを送ろうとしたらbase64でエンコードされたせいで容量オーバーした
ネットワークのトラフィックを減らすためにもメールでバイナリデータをエンコード無しで送れるのが標準化すればいいのに
- 888 ：デフォルトの名無しさん：2021/04/22(木) 22:46:03.04 ID:XWZJYEFR.net
- いち早く国際化はずのjavaもシステムのコードページでしか引数を受け取れない制約がある
- 889 ：デフォルトの名無しさん：2021/04/23(金) 00:48:19.99 ID:/P9+MOWj.net
- ほんまに？
Unicode対応していながら_wmain()とかGetCommandLineW()使ってないとは信じがたいが
- 890 ：デフォルトの名無しさん：2021/04/23(金) 01:33:18.30 ID:dmQwGyWy.net
- googleで検索したら以下ページすぐ見つかったけど、探すことさえしないタイプの人？
https://blogs.osdn.jp/2020/05/20/java-unicode.html
- 891 ：デフォルトの名無しさん：2021/04/23(金) 03:25:56.54 ID:z5iGgWRG.net
- Windows 専用ソフトでなくて、複数のOSに対応したソフトは当然そうなる。
特に Unix 系からの移植ならロケールをコードページに対応させるのは当たり前。
Windows独自の特殊APIで実装とか頭の悪いローカル変更は極力しない。
- 892 ：デフォルトの名無しさん：2021/04/23(金) 03:27:43.26 ID:Apsl8RTN.net
- というか単にC言語がASCII互換の文字コードしか
対応できないんだよな
そこは言語側の問題だと思う
- 893 ：デフォルトの名無しさん：2021/04/23(金) 03:29:09.72 ID:Apsl8RTN.net
- 例えばJavaとかはUnicode前提で設計されてるから
当然Javaで作った複数のOS対応のソフトは
WindowsでもUnicodeが使える
これは殆どの言語に当てはまると思う
C#、JavaScript、Ruby、Python、などなど
- 894 ：デフォルトの名無しさん：2021/04/23(金) 03:30:29.26 ID:Apsl8RTN.net
- そういやC言語はマルチバイト対応の機能は標準化されてないんだっけ？
流石にC++は標準化されてるよな？
- 895 ：デフォルトの名無しさん：2021/04/23(金) 04:04:31.01 ID:dmQwGyWy.net
- <locale>ヘッダがマルチバイト対応を実現してくれる
問題は誰もlocaleの機能を使ってないことだ
- 896 ：デフォルトの名無しさん：2021/04/23(金) 07:26:19.86 ID:Apsl8RTN.net
- おや？<locale>ヘッダとはなんのためにあるのでしょう？
使わなくても多言語対応できるのだったのでは？（苦笑）
- 897 ：デフォルトの名無しさん：2021/04/23(金) 09:16:27.68 ID:z5iGgWRG.net
- CがASCII互換じゃないと駄目ってどこの異世界。そんなもんコンパイラの実装次第。
規格では他の文字コードも考慮されてる。
実際 EBCDIC ですら動くやつあるのに。
- 898 ：デフォルトの名無しさん：2021/04/23(金) 09:17:21.12 ID:z5iGgWRG.net
- >>894
POSIX
- 899 ：デフォルトの名無しさん：2021/04/23(金) 13:53:41.29 ID:z7/roYpD.net
- >>897
CはASCII互換である必要はないが、
C言語文字列互換、つまり「文字列終端が\0」互換でなければならない
EBCDICはC言語文字列互換だが、UTF-16とUTF-32は互換性がない
- 900 ：デフォルトの名無しさん：2021/04/23(金) 22:37:45.17 ID:z5iGgWRG.net
- >>899
意味わからない。wchar はC言語とは認めない主義の人かな？
- 901 ：デフォルトの名無しさん：2021/04/23(金) 23:40:40.33 ID:vWq/Hknp.net
- 別にnull終端文字列を使うのがスタンダードかつ標準ライブラリもそう期待しているというだけであって、好きに実装したらいいよ
ぶっちゃけ舐めないと文字列長決められないので性能がスケーラブルでないし、null文字衝突の問題もあるし筋が良くない
マトモなCで書かれたテキスト関連アプリ、特にエディタでヌル終端文字列使ってるのなんて皆無だろ
普通はrope、もう少しカジュアルならパスカルストリング
- 902 ：デフォルトの名無しさん：2021/04/23(金) 23:42:50.22 ID:hyXGjiN1.net
- wcharω
- 903 ：デフォルトの名無しさん：2021/04/23(金) 23:45:37.62 ID:vWq/Hknp.net
- そもそも今時ゴミstdlib引いてC書く時点でアッて感じだし(組み込み等以外)
- 904 ：デフォルトの名無しさん：2021/04/24(土) 01:15:41.82 ID:lum8vFBO.net
- >>900
え？C言語の仕様にwchar_tを使うmainが無いんだからら
C言語の問題でしょうが
- 905 ：デフォルトの名無しさん：2021/04/24(土) 01:31:51.75 ID:+S3huMNR.net
- wmain() ってC言語じゃないの？
- 906 ：デフォルトの名無しさん：2021/04/24(土) 11:01:26.61 ID:h7gEVqDL.net
- >>903
Linux/Unix のプログラムはほとんど stdlib 使ってるけど、何か問題でも？
exit() とかの基本関数は stdlib にあるんだよ。
- 907 ：デフォルトの名無しさん：2021/04/24(土) 11:04:54.55 ID:fOHAtvcd.net
- OS l17n
- 908 ：デフォルトの名無しさん：2021/04/24(土) 13:26:44.28 ID:A8uXloOI.net
- C言語を捨てろと言ってるんだろ
他の言語に移ったところで文字コードから逃れることはできないがな
- 909 ：デフォルトの名無しさん：2021/04/24(土) 15:17:08.03 ID:iyr+Gwkk.net
- >>906
アプリケーションの話
- 910 ：デフォルトの名無しさん：2021/04/24(土) 15:48:16.06 ID:lum8vFBO.net
- >>908
他の言語はWindowsのUnicodeにちゃんと対応してる
- 911 ：デフォルトの名無しさん：2021/04/24(土) 15:57:56.64 ID:lkpB631F.net
- >>894
C++はヤバすぎる
utf-8用の1B型を最近標準化したけど、まともに実装されてないし設計もユルユル
WGの中の人がサードのライブラリ引いてね発言するくらいヤバい
- 912 ：デフォルトの名無しさん：2021/04/24(土) 16:15:59.56 ID:lum8vFBO.net
- 結局の所Unicode対応ができてないのはC/C++の言語自体と
無能なC/C++プログラマが根本的な原因なんだよな
無能なくせにクソ言語を使うなと
- 913 ：デフォルトの名無しさん：2021/04/24(土) 17:52:30.16 ID:h7gEVqDL.net
- OSなどの実行環境まで含めて全部をセルフ記述できる言語だけがC言語をけなして良い。
C言語の代わりになる高級アセンブラとか存在しないのが実情。
- 914 ：デフォルトの名無しさん：2021/04/24(土) 19:43:48.66 ID:lum8vFBO.net
- Windowsを全部セフル記述できる人だけが、Windowsをけなしていい
- 915 ：デフォルトの名無しさん：2021/04/24(土) 19:44:10.19 ID:lum8vFBO.net
- 訂正
Windowsを全部セルフ記述できる人だけが、Windowsをけなしていい
- 916 ：デフォルトの名無しさん：2021/04/25(日) 01:01:32.24 ID:mV4e9R8D.net
- >>913
C言語（とその派生）が無くなると世の中のほぼ全ての言語が一緒に死ぬからなあ。
ハンドアセンブルのマシン語は残るとして他に生き残りそうなやつって何があるだろうか？
汎用機のCOBOLとかなら大丈夫か？
C言語で使えない文字コードとかあったらゴミだな。
- 917 ：デフォルトの名無しさん：2021/04/25(日) 09:44:53.64 ID:5WfSbj4L.net
- Lisp MachineではFortranもCもlispで書かれていたのじゃよ、もうlisp専用ハードが無いけど…
今のハードがほぼC用に設計されているというだけ
それでもソフト資産が莫大だからCエミュレータは不滅だろうが
- 918 ：デフォルトの名無しさん：2021/04/25(日) 12:49:28.15 ID:mV4e9R8D.net
- lispマシンは滅びたのじゃよ。
javaマシンは産まれもしなかった。
別に今のCPUがCに合わせて設計されてるわけではない。
Cのオプティマイザーが頑張って今のCPUにあわせてるだけ。
lisp で lisp コンパイラと CPU オプティマイザ書けば理論的には同じことができるはずだけど誰もしようとしないだけ。
これ以上はスレチだな。
- 919 ：デフォルトの名無しさん：2021/04/25(日) 13:07:14.30 ID:FGclKzDI.net
- lispマシンのタグ付き思想はBOMに近いから関係ない事もないと思う
違うのは自動でオブジェクト=型+ワードから値だけ取り出す機構が(普及して)無いところだな
動的言語がこのまま持て囃され続ければ、ハードウェアGCの可能なlispマシン風ハードが出るかもしれん、何十年後になるか知らんが
- 920 ：デフォルトの名無しさん：2021/04/25(日) 13:18:17.37 ID:FGclKzDI.net
- アドレス付け単位としてのバイトが8bitでは効率良く型(あるいはエンコ)情報付けるのは厳しいな
文字単位で付けると少なくとも16bitになってしまう
やっぱり36bit時代の話だね
- 921 ：デフォルトの名無しさん：2021/04/25(日) 13:47:52.95 ID:y4+cdB21.net
- Jazelle...
- 922 ：デフォルトの名無しさん：2021/04/26(月) 14:21:24.82 ID:REE9nEfp.net
- lispすげーの人は夢を語りすぎ
鏡観ろ
- 923 ：デフォルトの名無しさん：2021/04/29(木) 14:26:38.37 ID:Wx+1i7qD.net
- やっぱりヤンキーはASCIIのことしか考えてないのか
Copying non-ASCII characters from Windows to WSLg broken
https://github.com/microsoft/wslg/issues/20
- 924 ：デフォルトの名無しさん：2021/04/29(木) 22:05:53.91 ID:aEwK4kMw.net
- WSLgはまだプレビュー版やろ
- 925 ：デフォルトの名無しさん：2021/04/30(金) 19:55:54.85 ID:m/tHuDzV.net
- ヨーロッパの人もびっくりといったところでしょうか
- 926 ：デフォルトの名無しさん：2021/05/10(月) 21:21:31.93 ID:dIUUxNIr.net
- CP932やUTF-8で保存されたテキストファイルをバイナリエディタで見る時、
0x0Dと0x0Aは常にCR・LFに対応するという理解であっていますか
例えば"東"は以下のように保存されますが、0x0Dや0x0Aが含まれる字が存在しない事を確かめたいです。
UTF-8: e6 9d b1
CP932: 93 8c
尚、ファイルは破損しておらず、デコードできない文字は含まれていません
- 927 ：デフォルトの名無しさん：2021/05/10(月) 21:32:43.96 ID:P0pDB+XT.net
- >>926
WikipediaのCP932とUTF-8の記事見てみ
- 928 ：デフォルトの名無しさん：2021/05/10(月) 21:51:44.48 ID:dIUUxNIr.net
- >>927
ありがとうございます
難しくてわかりませんでした
- 929 ：デフォルトの名無しさん：2021/05/10(月) 22:22:18.55 ID:ViCp850r.net
- プログラミングのお題スレ Part18
https://mevius.5ch.net/test/read.cgi/tech/1594702426/453
UTF-8 では、先頭ニブル(4ビット)が0なのは、1バイト文字だけだから、
0x0D・0x0A は、1バイト文字だけしかない
- 930 ：デフォルトの名無しさん：2021/05/10(月) 22:33:39.19 ID:+j6JaQYv.net
- MSのCP932や、UTF8はASCIIの上位互換。
つまり 0x0A とかは同じ解釈でいける。
UTF16とかUTF32とかは上位互換じゃないので駄目。
- 931 ：デフォルトの名無しさん：2021/05/10(月) 23:26:10.90 ID:P0pDB+XT.net
- >>928
どのあたりが難しかった？ 煽りじゃなくて
- 932 ：デフォルトの名無しさん：2021/05/11(火) 00:05:10.05 ID:0t6JOZiV.net
- ありがとうございます
>>929
UTF-8では、0x0Dと0x0Aは常にCR・LFと対応するのですね、助かりました
CP932も同様でしょうか
>>930
アスキー文字(0x00-0x7F)のみが書かれる時、CP932もUTF-8も同じバイト列であることは知っていましたが
0x0Dや0x0Aを含む文字が存在しない事を知らなかったので質問しました
例えば「帰」はCP932だと8b 41で、0x41が含まれていますが「A」を表してはいないわけで
同様の例が0x0D 0x0Aに当てはまるのか知りたかったのです
- 933 ：デフォルトの名無しさん：2021/05/11(火) 00:06:36.86 ID:0t6JOZiV.net
- 長すぎたので分割しました
>>931
うわ、どっちも文字がいっぱい……
UTF-8のページ
「エンコード体系」の表が関係しそうだなあ、でもよくわからんなあ。何故2進で書いたし……
今
あ、16進表記の列もあったのか。どれどれ…、あ、0x80以上なのか。じゃあ0D 0Aを含む文字はないんだなあ
CP932のページ
「構造」の表が関係しそうだなあ、でもこれはutf-8のサブセットのことを言っているのかな、それは知っているけどなあ
うーん、でも他に関連しそうな記載は見つけられないなあ
今
あ、CP932って必ず2バイトに収まるのか？そしたら第2バイトの0x00-0x3Fが未使用だから、0x0Dと0x0Aは常にCR・LFと対応すると言って良さそうだなあ
- 934 ：デフォルトの名無しさん：2021/05/11(火) 01:30:17.15 ID:c3IDGufy.net
- CP932に依存するコードを車輪の再発明するのはやめたほうがいい
UTF16を介して処理するのが堅実だよ
- 935 ：デフォルトの名無しさん：2021/05/11(火) 02:38:12.81 ID:1enRFFJU.net
- CP932だと絵文字が入ったファイル名とか扱えないからね
WindowsがUnicodeなんだからそれに従ったほうが良い
- 936 ：デフォルトの名無しさん：2021/05/11(火) 06:46:10.57 ID:InyAS07X.net
- >>933
わかりませんでしたって書いてたけどだいたい読めてるじゃん
「自信ないけどこう読み解きました」
「それでおｋ」
で済む(・∀・)
- 937 ：デフォルトの名無しさん：2021/05/11(火) 09:39:59.91 ID:Gl0wmygZ.net
- >>934
今更UTF16はないよ。中途半端なゴミ。
UTF32にするべき。じゃなければUTF8で処理する方かまし。
- 938 ：デフォルトの名無しさん：2021/05/11(火) 09:55:14.95 ID:c3IDGufy.net
- >>937
プログラミングやったことない人は回答しなくていいから
- 939 ：デフォルトの名無しさん：2021/05/11(火) 10:46:32.40 ID:FWZS8iTB.net
- >>926
読み込むとき CR を無視して LF だけ読んだとき CRLF が来たものとして処理
書き込むとき CR を無視して LF だけ書き込む
これで大抵の場合うまくいく
- 940 ：デフォルトの名無しさん：2021/05/11(火) 10:47:04.26 ID:FWZS8iTB.net
- >>926
ああすまんω
バイナリの話か
忘れてくれωω
- 941 ：デフォルトの名無しさん：2021/05/11(火) 15:53:24.06 ID:R6EacYeM.net
- >>938
技術的な反論ができないので、プログラムしたことがないとうレッテルを貼ってごまかそうとする。
醜いな。
- 942 ：デフォルトの名無しさん：2021/05/11(火) 15:59:10.29 ID:fJhAJw72.net
- なんでUTF-8で全世界統一しないんですか？
2000年問題みたいにやっちゃやーいいのに
- 943 ：デフォルトの名無しさん：2021/05/11(火) 16:02:46.19 ID:c3IDGufy.net
- >>941
WindowsのCライブラリはUTF-32には対応してないんだよ
- 944 ：デフォルトの名無しさん：2021/05/11(火) 17:51:32.38 ID:/14fii8B.net
- 2000年問題？
- 945 ：デフォルトの名無しさん：2021/05/11(火) 18:03:59.53 ID:jUIDYAvI.net
- >プログラムしたことがない
話や知識がかみあってない人は描いてる内容や雰囲気で判るけどな
プログラムしたことがあっても特定の分野に疎いとか
色々勘違いして覚えてるとか知識が偏ってるとかな
- 946 ：デフォルトの名無しさん：2021/05/11(火) 18:12:43.26 ID:c3IDGufy.net
- ICUはUTF-16がメインだよ。ソースとか見たことないの？
- 947 ：デフォルトの名無しさん：2021/05/11(火) 19:09:36.09 ID:fJhAJw72.net
- >>944
2000年問題の時は全世界で一斉に改修しただろ
文字コードも同様に全世界で一斉にUTF-8にすればいい
SJISとかEUCとか使ってソフトはDeprecatedに指定して
もう二年したら使えなくなるぞ、(#ﾟДﾟ) 凸ｺﾞﾙｧ!!、と伝えればすべての問題が解決
- 948 ：デフォルトの名無しさん：2021/05/11(火) 19:17:31.49 ID:vh9Kat/q.net
- おまえ明日から使用言語は英語な
明日まで翻訳終えられなかった日本語の文書は破棄するように
- 949 ：デフォルトの名無しさん：2021/05/11(火) 19:31:09.73 ID:fJhAJw72.net
- >>948
OK, no problem.
However, you all have to speak in English, too.
Is that OK with you?
- 950 ：デフォルトの名無しさん：2021/05/11(火) 19:51:27.17 ID:6D07FFeW.net
- じゃあ二年後の正月から日本全体で電気は50Hzな
例外は認めない
- 951 ：デフォルトの名無しさん：2021/05/11(火) 20:07:39.07 ID:fJhAJw72.net
- >>948
OK, it doesn't matter to me.
I currently live on the 50Hz-side.
Seriously, what the fuck is the matter to change all charsets to UTF-8?
At least, we have to start writing all characters in UTF-8.
You guys are just procrastinating the problem to the later generation.
- 952 ：デフォルトの名無しさん：2021/05/11(火) 20:37:23.10 ID:GFoNMADL.net
- 哎呀～
- 953 ：デフォルトの名無しさん：2021/05/11(火) 20:47:14.11 ID:vh9Kat/q.net
- >>949
No.
I resolutely refuse to your suggestions.
- 954 ：：2021/05/11(火) 20:49:53.68 ID:HFm5gSrp.net
- >>934
え？
UTF32 こそ正義なのではないですか？
UTF16 は、あくまでも特定用途のために UTF32 から変換して渋々使うものかと‥‥
- 955 ：：2021/05/11(火) 20:50:48.74 ID:HFm5gSrp.net
- >>942
外に出す文字コードは UTF-8
内側では基本 UTF-32 を使うべきかと、私は考えています
- 956 ：：2021/05/11(火) 20:52:11.20 ID:HFm5gSrp.net
- >>943
へんな言い方ですね
「Windows の C ライブラリ」ではなくて、Windows のシステムコール＝win32api というべきなのでは？
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
- 957 ：：2021/05/11(火) 20:55:50.64 ID:HFm5gSrp.net
- >>946
UTF-16 は Windows 等の特定用途なのでは？
むしろ正義は UTF-32 にあるでしょう
Shift-JIS や EUC は時代遅れだ、という意見には同意せざるを得ないのですが、だからといって、UTF-16 を提案するというのは、かえって悪手というか、頭が変なんじゃないかと私は考えます
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
- 958 ：：2021/05/11(火) 21:02:01.91 ID:HFm5gSrp.net
- >>950
50Hz は当時のドイツの会社「アルゲマイネ・エレクトリツィテート・ゲゼルシャフト」社から、
60Hz は当時の米国の会社「ゼネラル・エレクトリック」社から来ています
もし英語を第一言語に主張するのならば、50Hz ではなくて 60Hz が本流でしょう‥‥
実際、今で合衆国・カナダ・メキシコは 60Hz の国ですし
- 959 ：デフォルトの名無しさん：2021/05/11(火) 21:41:17.35 ID:fJhAJw72.net
- >>953
No, no, no, no, ... YOU suggested first.
- 960 ：デフォルトの名無しさん：2021/05/11(火) 21:58:18.19 ID:fJhAJw72.net
- >>955
いいですよ、UTF-32は一度も使ったことないですけど、
全世界で文字コードが統一されるなら協力しますよ。
自分はマなんですけど（って、ここにいる全員そうか）、
毎回文字コードの問題が浮上するたびに統一しろよと思ってきました。
UTF-8が出た時は「これでやっと統一される！」と思ってたら、ちっとも変わってない。
どこの馬鹿が舵切ってないんですか？
こんなもん、トップダウンでやらんと意味が無い。
蛇足だが、50Hz/60Hzも本気で統一すればいい。
地デジでアナログテレビを駆逐したんだからやれないことはない。
車の左側/右側通行も世界共通で左側通行にすべき。
- 961 ：デフォルトの名無しさん：2021/05/11(火) 22:01:33.58 ID:62zfmCQO.net
- Ubuntu は、UTF-32 だけど、英語圏では後半の2バイトが無駄。
メモリ使用量が、UTF-16 の2倍
だからWindows などの昔のOS は、UTF-16・サロゲートペアを使っている
- 962 ：：2021/05/11(火) 22:28:23.04 ID:HFm5gSrp.net
- >>960
＞50Hz/60Hzも本気で統一すればいい。
無理です……
変電・配電設備はどれも 50Hz/60Hz それぞれに専用で、もう一方の周波数には対応できません
仮に 60 Hz をやめて 50Hz に統一するとすると、西日本の電気設備は全部更新しないといけません、部品が全然足りなくて、多分西日本は3年くらい停電、電気なしの生活になりますね……
- 963 ：：2021/05/11(火) 22:29:39.96 ID:HFm5gSrp.net
- >>961
いまどき 32GiB RAM が常識な世の中で、後半の 2 バイトが無駄とかみみちいですね、そんなんじゃ駄目だ……
- 964 ：デフォルトの名無しさん：2021/05/11(火) 22:35:13.63 ID:6D07FFeW.net
- じゃあ明日から「円」は廃止「ドル」しか使えない
「メートル」は廃止してインチ、フィート、ヤード、マイルで
「摂氏」は廃止して華氏
「リットル」は廃止してガロン
これでアメリカと互換だぞ
便利だろ?
- 965 ：：2021/05/11(火) 22:37:00.60 ID:HFm5gSrp.net
- >>964
国民皆保険すらない後進国にあわせるのですか？
- 966 ：デフォルトの名無しさん：2021/05/12(水) 00:04:08.19 ID:XehBH/T/.net
- >>963
組込み用途では相変わらず厳しい制限があるだろ
- 967 ：デフォルトの名無しさん：2021/05/12(水) 00:56:08.99 ID:w4TAZAbA.net
- >>960
何をいってんの？ Unicodeの目的は「これからは」単一の文字コードで
世界中の文字を表現すること
過去の資産を無くすためじゃない
それからUTF-8はな、せっかくUTF-16に統一しようとしていたのに
Unicode団体でな無い所が新たに追加した文字コードだぞ
UTF-8がでたときは「また文字コード増やしたのかよ」って思うはずなんだが
- 968 ：デフォルトの名無しさん：2021/05/12(水) 01:47:55.23 ID:VbRrwICc.net
- あーもー！結局次が決まらんならS-JIS使い続けようぜ！
- 969 ：デフォルトの名無しさん：2021/05/12(水) 02:24:31.19 ID:S+EDWDjz.net
- >>966
組み込み用途では制限が厳しいのでUTF16を使いますｗｗｗ
お前、組み込みでどれだけ文字処理してんの？
いや、UTF8やUTF32じゃ駄目でUTF16じゃんないと制限に引っかる最近の実例があったの？
あったら具体例教えてほしい。
- 970 ：デフォルトの名無しさん：2021/05/12(水) 02:26:01.47 ID:Wqknze8k.net
- Cコンパイラがwchar_t型をUTF16とするかUTF32とするか次第じゃね
- 971 ：デフォルトの名無しさん：2021/05/12(水) 02:35:18.26 ID:S+EDWDjz.net
- >>967
だってUTF16がインターネットでの使用をまともに考慮して無かったので仕方ない。
unicode以前からインターネットは既に存在していて基本ASCIIベースだったので、それの上位互換がnetで普及するのは当然の流れ。
文字数が16ビットじゃ足りないことと、インターネットの普及を予測できなかったUnicodeコンソーシアムの不見識がUTF16の原因。
- 972 ：デフォルトの名無しさん：2021/05/12(水) 02:49:55.29 ID:Wqknze8k.net
- UTF8を使うにしても、SJIS -> UTF16 or UTF32 -> UTF8 と変換するからやってることは同じなんだよ
- 973 ：デフォルトの名無しさん：2021/05/12(水) 03:26:27.16 ID:rVJ0Zld2.net
- >>971
なんで文字コードがインターネットの使用を考慮しないといけないかもわからないし
インターネットでUTF-16が使えるのに、考慮してないというする理由もわからない
もしかしてネットサーフィン（笑）をインターネットという爺かお前
- 974 ：デフォルトの名無しさん：2021/05/12(水) 03:27:38.25 ID:rVJ0Zld2.net
- ASCIIは7ビットなんだからUTF-8だって非対応なんだがｗ
- 975 ：デフォルトの名無しさん：2021/05/12(水) 09:38:08.51 ID:HCx7UYF5.net
- >>960
言いたいことは判るが
君の発言はアーカイブとか文書の問題とすりかわってないか？
βのテープなんてまだあちこちにごろごろしてるだろ？
MO/MDなんかもまだあるだろ？
そのうちHDDもなくなってSSDばかりになるだろうがHDDはなくならないだろ？
新しいものはそっちで作っても古い方は面倒だから移動なんてしないだろ？
- 976 ：デフォルトの名無しさん：2021/05/12(水) 11:26:29.20 ID:rw/WEf9V.net
- 馬鹿メリカ式だと今日がこんなのになってしまう
5.12.2021
こんなの混ぜたら5月12日なのか12月5日なのか判別できずに混乱が生じる
混乱の対象となるのは各月12日までで月≠日のパターン(12*12-12=132通り)
年のうち36%もの日で混乱が生じている
馬鹿メリカ式さえ排除すれば大体うまくいくのだ
- 977 ：デフォルトの名無しさん：2021/05/12(水) 11:31:17.70 ID:S+EDWDjz.net
- >>974
プロトコルを拡張する時に上位互換の拡張が求められる、っていう常識すら知らないの？
まともに規格作ったり、実装したことないのかな。
一度動きだしたものは変更コストができるだけ小さい拡張が普及するんだよ。
- 978 ：：2021/05/12(水) 20:16:47.61 ID:HQn5nLJO.net
- >>967
＞せっかくUTF-16に統一しようとしていたのに
後世の模範となる康熙字典ですら 4万7035 字が収録されているというのに、UTF-16 の 6万5536 文字のキャパシティの面では圧倒的に足りないのでは？
世の中に存在する文字、かつて存在した古代文字を全部残らず収録する、という姿勢にしては、UTF-16 は「しょぼい」としかいいようのないキャパですね…
CJK 漢字統合なんて、東洋人からみればひたすら「醜い」の一言
「UTF-16 に統一」という基本設計、あるいは基本思想の時点で既に「根本的に間違っている」と私は結論づけます
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
- 979 ：：2021/05/12(水) 20:17:23.50 ID:HQn5nLJO.net
- >>970
wchar_t は死産でしょう‥‥
- 980 ：：2021/05/12(水) 20:18:07.73 ID:HQn5nLJO.net
- >>976
×馬鹿メリカ式
◎ダメリカ
- 981 ：デフォルトの名無しさん：2021/05/12(水) 20:22:17.19 ID:zdSe0i8P.net
- UTF-16 の最大文字数は 6万5536を遥かに超えるんだが
基礎知識がないやつとは、話にならんかな
- 982 ：デフォルトの名無しさん：2021/05/12(水) 20:39:17.81 ID:S+EDWDjz.net
- 昔に 65536 で十分ってアホなこと言い出したやつがいたのが、今の UTF-16 っていうヘンテコ文字コードができた原因だろ。
結果は、ごらんの有様。
- 983 ：デフォルトの名無しさん：2021/05/12(水) 20:41:59.59 ID:zdSe0i8P.net
- UTF-8ができたのはUTF-16の後な
最初はUTF-32と同じ文字数を表現できるようにしたが
最終的にUTF-16と同じ文字数に変更した
UTF-8とUTF-16が扱える文字数は同じ
- 984 ：デフォルトの名無しさん：2021/05/12(水) 21:12:17.60 ID:4TbGo10q.net
- えっなにこの流れ
UTF16で扱える文字数とUTF32で扱える文字数が違うとか言い張ってる人がいるように見えるんだけど
そんなことがあるの？？
- 985 ：デフォルトの名無しさん：2021/05/12(水) 21:17:37.12 ID:Bs1VBcWP.net
- https://ja.wikipedia.org/wiki/CJK%E7%B5%B1%E5%90%88%E6%BC%A2%E5%AD%97
1984年、ISOの文字コード規格委員会 (ISO/TC 97 - SC2) は文字セットの切り替えを行わずに世界中の文字を単一の文字集合として扱える
文字コード規格 (ISO 10646) を作成することを決定し、専門のワークグループ (WG2) を設置した。
当初、この文字コード規格は16ビットを想定し、その中に日本や中国など各国の漢字コード表をそのまま入れることを想定していた。
しかし中国はこの方式では自国で現在策定中の漢字コードが全て入らなくなるとしてこの方針に反対し、
1989年、各国の漢字コードを統合した漢字集合HCCのアイデアを提案した。
1990年、完成したISO 10646の初版ドラフト (DIS 10646) では、漢字コードは32ビットで表現され、各国の漢字コードはそのまま入れることになった。
しかし中国は漢字を各国でばらばらに符号化するのではなく、あくまで統一して扱うことを求めてこのドラフトには当初から反対しており、
今後の漢字コードの方針を決めるため、ワークグループはCJK-JRGと呼ばれるグループを別途設置し、そこで引き続き検討することにした。
- 986 ：デフォルトの名無しさん：2021/05/12(水) 21:37:03.94 ID:4TbGo10q.net
- ごめん誰か馬鹿な俺のために
(1) UTF16で表現できるがUTF32で表現できない文字
(2) UTF32で表現できるがUTF16で表現できない文字
を具体的に例示してもらえないだろうか
サロゲートペアなんてもう20年以上前には登場してたよね？
最大65536文字とか言ってる人は頭が平成１桁時代のまま取り残されてるの？
それとも、IVSや絵文字が絡むとUTF32で表現できない文字が出てきたりするんだっけ・・・？（こっちは自分が不勉強ゆえ自信なし）
- 987 ：デフォルトの名無しさん：2021/05/12(水) 22:41:39.87 ID:Be2Ur7pl.net
- >>962
変電・配電設備だって永遠に運転できる訳じゃない。
老朽化したら修理や建て直しぐらいするから、そのタイミングで変えていけ。
一斉にやるんじゃなくて、局所的に分けて10年～15年ぐらいかけてやればいい。
その間は隣の市から電気もらうのもOK。
>>964
「円」じゃなくて基準を「金」に戻すかな。
単位に関しては世界標準無視かよ？
>>967
正直、UTF-8でもUTF-16でもUTF-32でもまったく新しい文字コードでもいいよ、統一できるなら。
何ちんたらちんたらやってんだよ？
>>968
よし、今すぐ回線切ってﾀﾋね
- 988 ：デフォルトの名無しさん：2021/05/12(水) 22:42:55.43 ID:Be2Ur7pl.net
- >>975
βだろうがMO/MDだろうが、必要となったときに変換すりゃいいだけだろ。
少なくともその「必要となったとき」に吸い上げて変換した上で別の媒体に保存すればいい。
新しい文書は当然古い文字コードでは一切書かせてはいけない。
SJISなんぞ使った日にゃ秘密警察が見つけ出して206個ある骨をすべて砕く刑に処す。
>>976
その指摘は正しい。
ただ、一番正しい日付の表示法はヨーロッパ式で、
次に正しいのはお前が指摘しているアメリカ式で、一番馬鹿なのが日本式。
>>983
正確に数字で話せ。
で、真面目な話になるが、その中で最長の文字数を扱える文字コードはどれだ？
その最長の文字数でこの世のありとあらゆる文字は表現できるのか？
また、その最長の文字数を扱える文字コードだとデータ処理は遅くなってしまうのか？
- 989 ：デフォルトの名無しさん：2021/05/12(水) 23:15:30.39 ID:UT6XyfGi.net
- ISO8601よりヨーロッパ式を推すとはたまげたなあ
- 990 ：デフォルトの名無しさん：2021/05/12(水) 23:28:53.01 ID:LpmPGSmH.net
- 場末の掲示板の場末の板でイキってるんだから可愛いよね
- 991 ：デフォルトの名無しさん：2021/05/12(水) 23:30:48.38 ID:S+EDWDjz.net
- >>983
>UTF-8ができたのはUTF-16の後
それ何のジョーク？
UTF−16(サロゲートペア)方式が公開されたのは UTF−8 方式の4年後なんだが。
- 992 ：デフォルトの名無しさん：2021/05/13(木) 00:55:59.37 ID:bi8pzl4S.net
- >>979
C++のcwcharヘッダーからもわかるとおり、wchar_tは規格の一部
- 993 ：デフォルトの名無しさん：2021/05/13(木) 05:07:38.90 ID:nrtxeueq.net
- >>991
https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt
> Looking around at some UTF-8 background, I see the same incorrect
> story being repeated over and over. The incorrect version is:
> 1. IBM designed UTF-8.
> 2. Plan 9 implemented it.
> That's not true. UTF-8 was designed, in front of my eyes, on a
> placemat in a New Jersey diner one night in September or so 1992.
>
> What happened was this. We had used the original UTF from ISO 10646
> to make Plan 9 support 16-bit characters, but we hated it.
要約 16bitのUTFを使っていたが嫌いだったからUTF-8を作った
- 994 ：デフォルトの名無しさん：2021/05/13(木) 09:13:48.13 ID:jPZ0z7Tj.net
- で、どこに 16bit の "UTF" って書いてあるの？
勝手に UTF を補完すんな。その頃は UTF-16 はまだ存在してない。
- 995 ：デフォルトの名無しさん：2021/05/13(木) 11:09:24.10 ID:0pD51twu.net
- >>989
ああ、ISO8601よりもヨーロッパ式の方が断然いい
なんだ、その理由も分からないのか？
- 996 ：デフォルトの名無しさん：2021/05/13(木) 11:13:36.80 ID:0pD51twu.net
- >>990
場末の掲示板の場末の板で呟いているお前の方がよっぽど可愛いわ
せめて俺に直接レスしたらどうだ、この臆病者がｗ
- 997 ：デフォルトの名無しさん：2021/05/13(木) 13:46:00.24 ID:oT9LP7EK.net
- 成立順
UCS-2(かつてのUnicode)→UCS-4→UTF-8→UTF-16→UTF-32
ってことかな？訂正よろ
- 998 ：デフォルトの名無しさん：2021/05/13(木) 13:51:48.50 ID:pHijDXLB.net
- >>981
そのせいで shift_jis と同じ失敗を繰り返した訳だ
- 999 ：デフォルトの名無しさん：2021/05/13(木) 14:28:18.42 ID:oT9LP7EK.net
- >>998
同じ失敗って何？
shift-jisみたいに2文字目の判定に時間がかかったり読み違えたりする可能性はないと思うけど
- 1000 ：デフォルトの名無しさん：2021/05/13(木) 14:49:45.53 ID:jPZ0z7Tj.net
- >>997
その書き方だと UCS-4 == UTF-32 かな。
正確には UCS は符号化文字集合で UTF は符号化方式だけど。
- 1001 ：デフォルトの名無しさん：2021/05/13(木) 14:57:26.65 ID:aKG1Dap7.net
- 文字コード総合スレ part13
https://mevius.5ch.net/test/read.cgi/tech/1593777227/
- 1002 ：2ch.net投稿限界：Over 1000 Thread
- 2ch.netからのレス数が1000に到達しました。
総レス数 1002
306 KB
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★