X

文字コード総合スレ Part12

レス数が1000を超えています。これ以上書き込みはできません。
1デフォルトの名無しさん
垢版 |
2018/12/17(月) 16:48:24.47ID:Pfqpaohb
プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
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.92ID:Pfqpaohb
■参考サイト
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.77ID:Pfqpaohb
■これまでに行われた議論
・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.91ID:Pfqpaohb
・中国語の簡体字では、へんやつくりが簡略化されるなら、その文字も自動的に簡略化して表記する国家規格が有る
・中国語の「噁心」簡化政策によると「恶(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.56ID:Pfqpaohb
・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.65ID:Pfqpaohb
もうひとつの過去スレ:
文字コード統一スレ 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.71ID:Pfqpaohb
■ライブラリ
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.40ID:Pfqpaohb
■単語一覧
・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.69ID:Pfqpaohb
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.64ID:Pfqpaohb
前スレが終了間近だったので立てました。
追加するサイトなどあればよろしくお願いします。
2018/12/17(月) 20:17:00.51ID:WCs/11MM
文字コード総合スレ Part12
https://mevius.5ch.net/test/read.cgi/tech/1544931495/
12デフォルトの名無しさん
垢版 |
2018/12/18(火) 10:08:11.45ID:xxM0ZIZ4
>>1
U+30B9 U+30EC U+7ACB U+3066 U+4E59
13デフォルトの名無しさん
垢版 |
2018/12/18(火) 11:22:14.11ID:/M0/bFGF
>>11 の本スレ推奨

Part 13 になったら起こしてくれ
14デフォルトの名無しさん
垢版 |
2019/03/08(金) 14:51:30.23ID:uMMKH+w1
一応メモ
https://qiita.com/yumetodo/items/54e1a8230dbf513ea85b
2019/03/09(土) 06:47:26.73ID:ZOfzHyh2
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.96ID:h0df79AA
C++自体が非推奨
17デフォルトの名無しさん
垢版 |
2019/03/09(土) 16:56:18.99ID:kfZA3URW
C++11の糞仕様がずっと放置されてる

本スレ消費はよ
2019/03/10(日) 00:54:02.53ID:ktyeDSUM
C++の次の改訂ではC++の全ての仕様が削除されるべき
19デフォルトの名無しさん
垢版 |
2019/03/10(日) 17:40:35.50ID:uFsYqTSV
CJKが頑張って苦情入れたら非推奨にされましたとさ
https://twitter.com/theoridetech/status/933329866392444929
https://twitter.com/5chan_nel (5ch newer account)
20デフォルトの名無しさん
垢版 |
2019/03/10(日) 17:47:41.69ID:yzd/Af8M
リョウくんにお返事貰ってるな。
21デフォルトの名無しさん
垢版 |
2019/03/10(日) 18:01:51.00ID:uFsYqTSV
非推奨というより使用禁止レベルの糞やでcodecvt
2019/03/10(日) 18:05:00.62ID:eLFCjw3Q
https://github.com/katahiromz/iconv_wrap
使ってね。
23デフォルトの名無しさん
垢版 |
2019/03/11(月) 04:49:49.14ID:pTTv+VC9
本当に怖い文字コードの話

なんか貼れないので分割
heppoko.
hatenadiary.
jp/
entry/
2018/04/28/184559
24デフォルトの名無しさん
垢版 |
2019/03/11(月) 08:44:07.99ID:u2Hto+zd
ツイッターで#テクノロジー犯罪と検索して、まじでやばいことを四代目澄田会の幹部がやってる
被害者に対して暴力団以外にタゲそらしをしてるがやってるのは暴力団で普段外に出ることが少ないため遊びで公共の電波と同じような電波を使って殺人をしてる
統失はほとんどが作られた病気で実際は電波によって音声送信や思考盗聴ができることが最近明らかになりつつある
警察や病院では病気としてマニュアル化されてしまっているのが現状で被害者は泣き寝入りしてる
被害者がリアルタイムで多い現状を知って、被害者間でしか本当の事だと認知できていない
実際にできると思われていない事だから、ただの幻聴ではない実際に頭の中で会話ができる
できないことだと思われているからこそ真面目に被害を訴えてる
海外でも周知されつつあることを知ってほしい。
このままだとどんどん被害が広がる一方

#テクノロジー犯罪
#四代目澄田会
25デフォルトの名無しさん
垢版 |
2019/03/11(月) 13:01:21.07ID:qRllmJaM
>>218
ㇹ゚ン゚'ㇳ̃ヴ゙ニ゙コ゚ヮヰ文̂字̠コ゚−ト゚ノ゙ㇵナ゚ㇱ
26デフォルトの名無しさん
垢版 |
2019/03/11(月) 14:24:48.05ID:hfHU2O5u
char_traits の length って信用していいの？
27デフォルトの名無しさん
垢版 |
2019/03/12(火) 03:51:12.13ID:FSVt1tPQ
若干違和感ある部分も

絵文字がある種のUnicodeバグを世界から一掃しつつある件について
note.mu/
ruiu/n/nc9d93a45c2ec
2019/07/12(金) 14:43:41.63ID:q8HbeEfz
Unicodeが出してるiconvみたいな変換ライブライあるじゃん？
あれどうなん？
2019/12/25(水) 20:38:30.91ID:N+K1pmuB
なんか文字追加されたね。
https://unicode.org/charts/beta/nameslist/
2019/12/27(金) 08:43:18.71ID:GMT90LLU
と思ったらUnicode 13発行されるのか。
2020/04/11(土) 19:22:36.64ID:md0SvLvZ
またUnicode.orgのサーバー落ちてる……
2020/06/17(水) 21:52:52.20ID:5H4oQmhP
https://abs-0.twimg.com/emoji/v2/svg/1f6f8.svg
2020/07/03(金) 16:13:30.65ID:o8JvC3od
文字コード総合スレ Part12
https://mevius.5ch.net/test/read.cgi/tech/1544931495/
が1000行ったけどこっち再利用するのかな?
34デフォルトの名無しさん
垢版 |
2020/07/03(金) 20:55:14.32ID:elbfDzqw
重複スレが残ってたのか
Part13立てちゃった
2020/07/03(金) 23:14:01.31ID:uIgOlo/V
「コマンドプロンプトはcp932（SJIS）である」はウソ

Windows NTの標準の文字コードであるUnicode（UTF16-LE）の
テキストファイルを作り、chcp 932のままtypeコマンドで表示してみましょう
文字化けせずに表示されますね？
（フォントがない場合は表示されないがそれ以外は問題ない）

これは明らかにコマンドプロンプトがUnicodeで動作している証拠です。

コマンドプロンプトがUnicode動いているという証明はこれで十分だと思いますが、
もし仮に反論があるならその根拠を言ってくれれば説明を追加します。
（根拠なしにcp932にきまってるだろ！みたいなものは一言で潰しますのでよろしく）
　　　
36デフォルトの名無しさん
垢版 |
2020/07/03(金) 23:59:01.41ID:2ewiuNjd
>>34
責任持って誘導しろ
https://mevius.5ch.net/test/read.cgi/tech/1593777227/
37デフォルトの名無しさん
垢版 |
2020/07/04(土) 00:12:44.08ID:xxQcNpXl
ヒラキ゛ノ角コ゛シック
2020/07/04(土) 02:05:01.27ID:Vdunr+kB
MS Gothic = ＭＳ ゴシック
MS PGothic = ＭＳ Ｐゴシック
MS UI Gothic = MS UI Gothic
2020/07/04(土) 21:58:35.22ID:0DTN05zS
「うわー、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.22ID:xxQcNpXl
cmd /U /C echo Hello | od -t x1
2020/07/04(土) 23:31:46.91ID:M3d71N9d
>>39
cmd /?
/A 内部コマンドの出力結果を ANSI でパイプまたはファイルに出力します。
/U 内部コマンドの出力結果を Unicode でパイプまたはファイルに出力します。
42デフォルトの名無しさん
垢版 |
2020/07/05(日) 12:27:30.05ID:dKznqT0V
>>39
chcp 65001
2020/07/05(日) 13:58:13.31ID:jQ41esUI
というか、コマンドプロンプトにCP932にない文字を貼り付けて普通に出力できている時点で
コマンドプロンプトが特定のコードページに依存していないと気づくだろ。

echo 六四清场
2020/07/05(日) 14:04:49.45ID:jQ41esUI
mingwのcatやgrepをコマンドプロンプトから呼び出すと一時的にchcp 65001な状態になって画面出力される。
2020/07/05(日) 21:04:09.52ID:M+BkbwUs
>>44
それはコマンドプロンプトがUTF-16なので、
mingwのcatやgrepがUTF-8で出力すると文字化けするからだね
2020/07/05(日) 23:20:17.80ID:jQ41esUI
>>45
コマンドプロンプトがUTF-16なので、
mingwのcatやgrepがSJISで出力すると文字化けするからだね

という論法も成り立つが。
2020/07/06(月) 01:59:06.09ID:T074ZQpk
mingwのcatやgrepでSJISにない文字も表示できるので
その論法は成り立たない
48デフォルトの名無しさん
垢版 |
2020/07/06(月) 10:35:57.48ID:vjiPzzt6
SJISちゃんのことは早く忘れろ
2020/07/07(火) 00:26:29.24ID:wqab1oeP
やだーExcelのマクロファイルSJISだもん
50デフォルトの名無しさん
垢版 |
2020/07/08(水) 17:17:18.70ID:h0xUNipw
Office文書自体はOOXMLでUTF-8になったのに
マクロは未だにShift_JISなのか。
2020/07/09(木) 09:25:45.33ID:vrNDocOm
唐突かつ広範な主張
マウントスタート
主観的な理由
地に足のつかない結論

わずかな文章に愚かさが詰め込まれていて揶揄せずにおれない
52デフォルトの名無しさん
垢版 |
2020/07/18(土) 13:33:37.82ID:uRU3MGLx
知られざる顔文字の世界
https://www.hottolink.co.jp/blog/20161114_66202/
2020/07/20(月) 21:19:31.88ID:SNT5szCU
AppleとGoogle、世界絵文字デーに新絵文字を披露
https://www.itmedia.co.jp/news/articles/2007/20/news053.html
54デフォルトの名無しさん
垢版 |
2020/07/21(火) 11:54:04.73ID:+OCbOnRh
絵文字の話題鹿無いのか
2020/07/21(火) 11:57:01.74ID:SHIoqAPz
もうそろそろ音文字もできてほしいよね
2020/07/21(火) 19:48:37.21ID:yq9jKXcW
昔懐かしMIDI復活
2020/07/22(水) 01:25:29.84ID:u6QrHnkl
いつかはアニメ文字も作られるのかな?
2020/07/22(水) 03:14:08.06ID:WLvtiBEO
>>57
iモードにあったような無かったような
2020/07/22(水) 03:39:38.34ID:IIwMuy9z
<MARQUEE><BLINK>動きがあるのは気が散るからやめてほしいな</BLINK></MARQUEE>
2020/07/22(水) 07:25:55.44ID:IySnQNum
懐かしのって
初音ミクとかMIDIで出来てるだろ
2020/07/22(水) 11:49:19.63ID:J4Vacr3k
>>59
<ITALIC><BIG>旧タグなら書き込めるんだw</BIG></ITALIC>
2020/07/24(金) 03:27:13.24ID:6ZonvnML
音文字か。そう言えば Ctrl+G (7) は BELL だったような。
ASCIIだけか? Unicode だと決まってないんだっけ？
2020/07/24(金) 03:43:48.92ID:5ghYNMX+
マザボのブザーでも鳴るの？
2020/07/24(金) 05:05:05.45ID:6ZonvnML
さあ? 処理するプログラムに寄るんだろうな。
Windows のコマンドプロンプトで 7 のコード出力してみたら音が出たよ。
2020/07/24(金) 05:05:33.57ID:6ZonvnML
BIOSのビープ音ではなく Windows 側のサウンドの設定が関係しているんだろうと思う。
2020/07/24(金) 10:07:32.92ID:gSKUw3+G
UnicodeでもU+0007はBELL CHARACTER
67デフォルトの名無しさん
垢版 |
2020/07/24(金) 10:53:36.75ID:qMgm686n
printf("\x7\n");
2020/07/24(金) 11:02:13.19ID:kTZ1cNqr
マザボのビープスピーカではなくサウンドデバイスで鳴らすようになったのはwin7以降だっけ
2020/07/24(金) 11:14:24.17ID:f4UMJCtp
2000ジャマイカ
2020/07/24(金) 17:43:05.10ID:YBlLKE+B
2000の時代に練習した時はprintfでビープ鳴ってた
2020/07/24(金) 18:43:29.22ID:sQG3RcOn
>>68
普通に考えりゃvista以降からでしょう
7かvistaかで本体beep鳴らすapi叩いたらpcmでがっかりだったのは覚えてる
apiだとATのbios同様周波数や長さ指定できて遊べたんだがな
同時にいじられるとよくないから切られたんでしょう
2020/07/24(金) 19:01:43.86ID:vNSj5xVg
なついなぁ。

Win32API Beep()
https://docs.microsoft.com/en-us/windows/win32/api/utilapiset/nf-utilapiset-beep
2020/07/24(金) 19:18:02.12ID:yBBtjj2V
beep用スピーカーがマザーボードから省略され始めたんだよ。
2020/07/24(金) 19:22:19.50ID:7vmGBdx3
昔は音を鳴らせるアプリは一つだけだった。
いつからか複数のアプリが同時に鳴らせるようになったんだが
いつからだっけな
2020/07/25(土) 00:55:48.04ID:W2vK2AQR
うろ覚えだが、ビープスピーカーで力業で音楽演奏するソフトがあったような気がする
2020/07/30(木) 04:08:23.78ID:y8VtuE5G
>>66
Unicode では ALERT
または BEL
77デフォルトの名無しさん
垢版 |
2020/07/30(木) 16:30:24.90ID:EPvquY9v
tab は \t
だから
bell は \b
と思ってた時期がある
78デフォルトの名無しさん
垢版 |
2020/07/30(木) 16:41:49.22ID:TNnZNpws
合わせると
食べる
2020/07/31(金) 22:29:23.92ID:j/9/9lyu
>>77
\bの本当の意味ってなんだっけ。
2020/07/31(金) 22:33:31.30ID:LZrfPAZb
バックスペース
2020/07/31(金) 22:42:27.48ID:LZrfPAZb
しかしこういうのってティッカーテープとかテレタイプの時代にさかのぼるらしいね。
現物を見たことはないが用語だけはいろいろ残っているという。
2020/08/01(土) 01:00:50.03ID:WNKlelSF
遠隔で物理CR/LFは夢がある
2020/08/01(土) 18:43:21.40ID:6JQgXAfu
一番夢があるのは肯定応答とかかな。
というのも，改行やエスケープとかはもちろん，場合によっては警鈴なんかも
未だに現役なのに対して，「肯定応答」という意味で^Fが使われているのを見たことがないから。
^Fはもう，各ベンダーごとに都合の良い，全く違う制御シーケンスになっちゃってる。
2020/08/01(土) 19:03:29.73ID:hFu7PbvL
NAK
2020/08/26(水) 16:48:18.06ID:P4l77+uM
毎日新聞ニュースさんはTwitterを使っています 「天皇陛下即位のお祝い品のリストと写真を㏋で公開　宮内庁」 / Twitter
https://
twi
tter.com/
mainichijpnews/status/1297833742753439744

HPが合字の㏋ (U+33CB)に
2020/08/26(水) 17:29:56.14ID:tn5jjKWE
正規化のせいやな。
知らんけど。
2020/08/27(木) 00:37:34.21ID:Jx+0/WN9
いまだに手書き、あるいは印刷した紙で原稿を入れてくる記者がいて、
入稿をOCRで文字起こししたらHPをその合字の方に認識、そのまま放置、とか?

ちなみにこれってHorse Powerでよかったですか?
2020/08/27(木) 11:49:50.52ID:igmT7d/I
馬力
2020/09/02(水) 16:48:23.22ID:wDhsuzOT
そう言えば中国のGB 18030が改訂されるって話はどうなったんだろう？
何年か前にKenが最終原案を見たよって言ってた気がしたけど、続報がない。
2020/09/02(水) 23:24:39.67ID:jWdQ7Iud
その後Kenの姿を見た者はいないという
2020/09/03(木) 15:58:49.10ID:ACS7FND0
13対応の花園もﾏﾀﾞｰ?
2020/09/20(日) 08:14:38.84ID:BIMERbR5
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
2020/09/20(日) 18:04:46.19ID:j6+bQw5M
Androidの絵文字追加がOSバージョンアップ前提だから取り残される環境が多すぎるんだよな
どうにかアプリ枠で配信してくれたらいいのに
94デフォルトの名無しさん
垢版 |
2020/09/20(日) 18:46:29.19ID:RjVJO5D2
woman with beard
誰得？
95デフォルトの名無しさん
垢版 |
2020/09/20(日) 18:47:31.92ID:RjVJO5D2
https://www.unicode.org/announcements/emoji-13-1-annc-couples.jpg
最初から顔に色なんか付けなきゃ良かったのに
2020/09/20(日) 20:32:09.64ID:69fdZo9j
だっぷるがつけちゃったんだもん
97デフォルトの名無しさん
垢版 |
2020/09/21(月) 00:08:08.68ID:fGf6DMu1
顔に色が無いと全部白人に観えるんだろ
黒い顔だけ造っておけばよかった
2020/09/21(月) 09:05:25.63ID:apXLM6YN
そもそも文字コードになんで色情報なんか含めたんだろ
あれも発端はPCがらみだっけ？
2020/09/21(月) 10:33:58.83ID:13UcesYH
俺は良かったと思うけどな。おかげで文章としての表現力が上がった。
2020/09/21(月) 10:35:23.80ID:13UcesYH
一夫多妻を表す絵文字はつくらないのかね？
101デフォルトの名無しさん
垢版 |
2020/09/21(月) 10:44:58.40ID:M8W5JifW
姦
嬲
嫐
2020/09/21(月) 17:50:51.21ID:ttv6HIBF
>>95
そっか、これコードを結合していくと作れるんだ。面白い。
男＋白肌＋ハート＋男＋黒肌 みたいな。

仕組みは面白いが、処理する側は大変そうw
あとキーボードの絵文字パレットとか、全パターン表示しないといけないのかな?
2020/09/21(月) 18:17:56.53ID:fI5zzMAW
> 仕組みは面白いが、処理する側は大変そうw

うん。だから個々の人が処理するんじゃなくて
OS標準のテキスト処理として実装されたから素晴らしいんだよ
普通に文字を出力すれば、絵文字対応になるから
2020/09/21(月) 18:45:37.15ID:ttv6HIBF
>>103
OSレベルでテキストのレンダリングとかめんどくさくなったはいうまでもなく、
一般のデベロッパもユニコード文字列をうかつに処理できなくなった罠。
ま、 ちゃんとAPIを使えとか、そういうことで、それはいいことなのかもしれないけど。
2020/09/21(月) 19:08:16.33ID:sDzSgcbr
ユニコードはウィルスなので送らないでください
2020/09/21(月) 19:45:05.95ID:LKcGYABn
>>104
それは絵文字以前の話だけどね。

Unicodeの当初の目標でも16bit固定＝C言語の終端文字である\0が1文字の中に
含まれる事があるので、文字はUnicodeとして扱わなければいけないことが決定していた。

Unix/Linux系ではC言語の終端文字である\0を避けるためにUTF-8を採用したが
可変長バイトだから、これもUnicodeとして扱わなければいけない。

どちらにしろちゃんとAPIを使えという話は避けられなかったんだよ。
そして絵文字のおかげでサロゲートペアが必要となる文字への対応が進むといういい結果をもたらしたｗ
2020/09/21(月) 21:02:01.32ID:XIYZJxnC
想定しないといけない1文字の長さを具体的有限にしてくれないかなあ
2020/09/21(月) 21:15:43.93ID:GxzcHgtD
アキラメロン
最終的には複数の文字を組み合わせて64 x 64 ドットに
自由なアイコンを作れるようになるだろう
2020/09/21(月) 23:04:34.98ID:dVFtF0fU
今時ピクセルは無いだろ。
SVG埋め込みの方が可能性がある。
110デフォルトの名無しさん
垢版 |
2020/09/22(火) 03:30:53.25ID:EwzeVKsQ
>Unix/Linux系ではC言語の終端文字である\0を避けるためにUTF-8を採用したが

これは違うんじゃまいか
結果的にそうなっただけであって
意図してそうした訳じゃない
2020/09/22(火) 03:34:39.51ID:Ab752W48
>>110
意図してUTF-8を作ったんだよ
本来はUnicodeにはUTF-16しか無かった。
外部機関があとから作り出したもの。それがUnicode本家に採用された
2020/09/22(火) 05:08:49.52ID:w/6Y1Cd5
UTF8の方がUTF16より歴史が古いよ。
ユニコードが国際規格になる前からある。
2020/09/22(火) 11:24:31.43ID:X1mK+PSm
>>98
NTTDoCoMo・au・Softbankの絵文字の時点でカラーになってたじゃん
互換性を保つために必要
2020/09/22(火) 11:58:02.00ID:UY6+hZuP
>>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の実装と互換性がありません。
2020/09/22(火) 12:07:37.87ID:EwzeVKsQ
それは単にカラーで表示していただけで色情報を持っていたわけじゃないだろ。

発端はやっぱり肌色の問題だったらしい。
https://internet.watch.impress.co.jp/docs/special/670150.html
116デフォルトの名無しさん
垢版 |
2020/09/22(火) 14:22:08.65ID:iCejn/78
ナメック星人用に緑の肌もあるの？
2020/09/22(火) 15:07:13.30ID:pk1eyzkq
>>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で策定
2020/09/22(火) 15:35:18.08ID:6o8of7S0
>>117
UTF-16という名称はついてないはずとかお前の希望はいらん
証拠もってこいや
2020/09/22(火) 15:37:16.35ID:6o8of7S0
> UTF8の方がUTF16より歴史が古いよ。
> ユニコードが国際規格になる前からある。

ユニコードってなにか知ってますか？
Unicode 1.0もユニコードなんですがｗ
2020/09/22(火) 15:37:46.01ID:6o8of7S0
さてユニコードが国際規格になる前とはいつのことでしょうかねｗ
2020/09/22(火) 16:12:08.88ID:uF0JvJPV
TkライブラリがいまだにUCS-2のままなのはなぜなんだぜ？
2020/09/22(火) 22:03:17.96ID:72aYjsjv
>>98
文字の色が意味を持つトンパ文字なんてのもあるから
どのみち色情報は必要になったんじゃない？
2020/09/22(火) 22:08:31.29ID:6VKGlvlr
utf8の歴史は知らんけど7zやrar5のヘッダの64bit値の可変長は影響されて出てきたもんだと思ってるわ
2020/09/22(火) 22:17:21.12ID:qhIXHkhL
可変長の数値といえばMIDIかなー
2020/09/23(水) 03:28:56.77ID:mCjrd8MP
答え出てるじゃん
UTF8方式が発明されたのは1992年
UTF16方式は1995年
国際規格(ISO)になったのは1996年
2020/09/23(水) 08:26:01.74ID:+jrDbaEU
Unicode 1.0.0 (October, 1991)
http://www.unicode.org/versions/components-1.0.0.html
2020/09/23(水) 08:34:33.77ID:7Cl+Ulja
Unicodeは業界規格であって国際規格ではない
国際規格なのはISO/IEC 10646で初版は1993年

文字コード関係で専門用語を雑に扱うと議論が混乱するから正確に用語を使え
2020/09/23(水) 09:04:10.27ID:mCjrd8MP
さらに ISO 10646 の 1993 年版は Unicode とは厳密には異なる文字コード規格。
1996年版と Unicode 2.0 で両者が統一された。
2020/09/23(水) 09:07:37.04ID:irsqaiS+
>>125
UCS-2はUTF-8より前からあったんだが？
話理解してる？UTF-8はUCS-2（UTF-16）で困ったから
外部機関が作り出したものって話をしてる
2020/09/23(水) 09:08:10.50ID:irsqaiS+
この話

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本家に採用された
2020/09/23(水) 09:10:39.13ID:irsqaiS+
> UTF8方式が発明されたのは1992年
当時はUTF8という名前ではなかった。UTF-16と同時につけられた名前
最初はUTF-1という名前があった。
これの改良版としてPlan9が考えたものを採用しUTF-8と名付けた
132デフォルトの名無しさん
垢版 |
2020/09/23(水) 09:47:37.94ID:hJkRvCZv
>>124
この板では ruby だろ常考
2020/09/23(水) 12:40:50.21ID:mCjrd8MP
かなり誤解しているやつがいるので業界規格(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)という考え方を導入
(続く)
2020/09/23(水) 12:41:36.26ID:mCjrd8MP
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 はまだ採用されてない
(続く)
2020/09/23(水) 12:43:30.64ID:mCjrd8MP
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.51ID:YfY3TQQ4
>補足よろしく

わろす
2020/09/23(水) 12:51:35.74ID:irsqaiS+
つまり>>106は正しいということ

> Unicodeの当初の目標でも16bit固定＝C言語の終端文字である\0が1文字の中に
> 含まれる事があるので、文字はUnicodeとして扱わなければいけないことが決定していた。

> Unix/Linux系ではC言語の終端文字である\0を避けるためにUTF-8を採用したが
> 可変長バイトだから、これもUnicodeとして扱わなければいけない。
2020/09/23(水) 13:42:18.16ID:mCjrd8MP
>>137
厳密には違う。
UTF-1 の時点で 0x00 は入らないくて C言語で使用可能。
でも / が 2バイト目以降にが入ってるので Unix 等のファイルシステムで使えない欠点があった。
これを改良するために考案されたのが FSS-UTF (UTF-2)、のちに UTF-8 と命名。
2020/09/23(水) 13:50:08.66ID:BgUeNus/
>>137
業界規格としてのUnicodeは符号化方式（今のUTF-16）について，
Cやシェルのことを考えていなかったけど，
それが国際標準になる時に，
符号化方式の一つとしてUTF-8を採用してCやシェルを考慮した，
ってこと？
2020/09/23(水) 13:59:02.67ID:mCjrd8MP
重要なのは 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.77ID:7/mhYxCT
ルーピー儲であふれてるスレ
2020/09/23(水) 20:40:55.14ID:FfABxMH0
>>125
で、UTF-8が国際標準に入ったのは何時なの？
なんで開発された年と標準化された年を比較してるの？
2020/09/24(木) 01:15:56.19ID:2TpuCg1t
>>142
だれもそんな比較してない。よく読め
UTF8方式が提案された年とUTF16方式が提案された年を比較してる。
2020/09/24(木) 01:22:18.61ID:27/WCIy4
>>143
え？なんでそんな話してるの？
それの何が重要なの？
2020/09/24(木) 01:26:57.76ID:27/WCIy4
UTF16がUCS2と違うというのなら、サロゲートペアの話でもしてるんだろうが
サロゲートペアが登場してるなら16bitでは収まらないと諦めた後であるということ
だからUCS4がすでに登場している
そしてUCS4があるからこそ、UTF-8からUCS4に変換するロジックを作ることができる
つまりUTF-8があるなら、UCS4がありUTF-16もあったことになる
2020/09/24(木) 01:48:26.24ID:2TpuCg1t
>>145
何？ その超理論、詳しく教えて？
どうやったらサロゲートペアより前に UTF16が存在できるの？
どの規格書に書いてある用語使ってるの？
2020/09/24(木) 08:50:32.68ID:hsn7nUMR
>>112 のツッコミ方が完全に間違ってるんだよな。
Unicodeには16bitエンコーディングしかなかったところに
後から8bitエンコーディングが追加されたって話なんだから
そこでツッコむべきはUTF-16という用語を使うのが間違っているという点。
それなのにあさっての方向にツッコむもんだから話がこじれる。
2020/09/24(木) 09:22:54.19ID:2TpuCg1t
>>147
だから、それも違うんだ。
Unicode に固定長エンコーディングしか無かったのは正しい。
一方で UTF-8 は Unicode のために作られらのでは無くて国際規格の UCS-4 のために作られた。
その後に Unicode と国際規格が事実上統合された。
2020/09/24(木) 10:38:14.21ID:27/WCIy4
UTFがUCSにTransformするフォーマットの略って知らないのかな？
2020/09/24(木) 11:57:01.94ID:2TpuCg1t
>>149
細かいこ指摘だけど UCS に Tranmsform するのではなくて、UCS から Transform がより正確だよ。
2020/09/24(木) 12:55:17.64ID:2TpuCg1t
簡単な用語定義 (※元々は 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 などと呼ばれていた
2020/09/24(木) 13:18:02.55ID:2TpuCg1t
以上の用語定義で 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 方式を入れ換えた。
2020/09/24(木) 20:34:57.66ID:anZxJGRt
UTF-8の祖先にUTF-1があるから歴史が古いんだと言えるなら、同じ論理で
UTF-16の祖先にUCS-2を直接使用する原ユニコードがあるとも言えるんじゃね？
2020/09/24(木) 23:00:01.78ID:2TpuCg1t
UTF-1 があるから歴史が古いなんて言ってる人いないけど、どこ見てるの。
UTF-1 のすぐ後に UTF-8 が提案されてて間は1年もないよ。寝惚けてるの？
2020/09/24(木) 23:04:21.45ID:4CFVaDi9
論点はそこじゃなくてUTF-8はUnix系でUTF-16に対応できなかったから
しかたなく作ったものだって話だろ
外部が作って後からUnicodeに追加された仕様
2020/09/24(木) 23:19:57.03ID:KWqR4FD9
あきらめろ。
UTF-8 は Unicode ではなく UCS 用に作られた。
UTF-8 は欠陥のある UTF−1 の代わりにするために作られた。
UTF-8 が考案された時には UTF-16 は影も形も無かった。
2020/09/24(木) 23:22:52.82ID:2TpuCg1t
>>155
だから、それが間違いって指摘してるんだが
2020/09/24(木) 23:31:22.25ID:tp/LFCei
>>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の実装と互換性がありません。
2020/09/25(金) 01:42:25.42ID:gzmvGmy3
>>158
そこに書かれている original UTF というのは UTF-1 のことで UTF-16 のことじゃないぞ。
ちゃんと理解できてるか？
2020/09/25(金) 02:18:28.45ID:N+dUj7Ty
だからUnicodeに対応するためにUCS-2ではなくてUTF-1を使ってたんだろ
UnixがUCS-2に対応するのは現実的に不可能だったから
2020/09/25(金) 02:46:48.42ID:4J6tgyym
>>156
> UTF-8 が考案された時には UTF-16 は影も形も無かった。

UTF16の直接の先祖のUnicode1.0の符号化方式が厳然と存在してるのに影も形もないはないな
2020/09/25(金) 02:48:35.22ID:gzmvGmy3
>>160
だから、それ、お前の妄想だろ。不可能とかどこにも書かれてない。

実際やろうと思えばできる。素人じゃあるまいし。Ken って誰だか知ってるか？
ただ、互換性がないから嫌っていたという話。
Windows とかはしょちゅう非互換な変更を加えるけど、Unix とかは文化として相互の協調動作を重視するんだ。
それで、可能な限り非互換な変更を避けようとする、仕方がない場合にはやるけど。
実際問題 Plan-9 には UCS-2 と UTF-1 の両方が既に開発済みで、リリース間近だった。
ちょうど、その時に X/Open comitee の人から電話がかかって来て、UTF の改良について相談されたので、速攻でより互換性の高い新しい符号((UTF-8)を設計して提案したという話。
2020/09/25(金) 02:51:32.21ID:gzmvGmy3
>>161
そんな見苦しい言い分けしても、お前の間違いはごまかせないんだぜ。
2020/09/25(金) 03:18:37.40ID:4J6tgyym
お前の間違いってどれよ、挙げてみｗｗｗお前が思ってるお前の発言は多分俺の発言じゃないから
一人を相手にしてると思ってるなら大間違い
2020/09/25(金) 03:20:48.06ID:N+dUj7Ty
>>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の実装と互換性がありません。
2020/09/25(金) 04:05:10.29ID:gzmvGmy3
>>165
互換性がないとしか書いてないようだが？
2020/09/25(金) 08:01:55.95ID:N+dUj7Ty
だからOSの方を書き換えるのが現実的に不可能だったんだろ
2020/09/25(金) 08:06:49.98ID:Joe/ViIu
>>162
＞ Windows とかはしょちゅう非互換な変更を加える

これって何のギャグよ
2020/09/25(金) 08:14:51.08ID:ElnYG5aU
互換性がないから嫌いとしか読めん
現実に各社 Unix でも Linux でも UTF-16 実装してるんだよなあ。
不可能とは？
2020/09/25(金) 08:19:51.13ID:N+dUj7Ty
不可能なのは各コマンドをUTF-16対応にすること
2020/09/25(金) 09:16:58.00ID:gzmvGmy3
なんで？
プログラムと API を書き換えれば、普通にできるよ。
実際 Windows はそれをやったわけだし。
2020/09/25(金) 09:28:26.81ID:ElnYG5aU
>>171
Mivrosoft は愚直に全てのプログラムを書き換えた。
UNIX陣営は UTF-8 を発明して、その手間を大幅に省いた、天才。って話だわな。
2020/09/25(金) 09:31:02.93ID:N+dUj7Ty
>>171
永遠の時間があればできるだろうなって話
Windows NTは最初のバージョンからUnicode対応だった
2020/09/25(金) 09:36:14.75ID:gzmvGmy3
逆だろ、Unicode 対応のために DOS-FAT から NTFS に非互換な変更したってだけだろ。
DOS-FAT はあまりにもダメダメなので、他の理由でも置き換えるのが必須だったので決断は簡単だった。
一方 UNIX 系の FS は FAT に比べれば良くできてたので、置き換える意欲に乏しかった。
2020/09/25(金) 10:34:03.53ID:N+dUj7Ty
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)
2020/09/25(金) 11:53:51.78ID:ET4Ww2dt
DOS-FATなんて使われてない用語を使ってるのは、印象操作でも目論んでるようにしか見えないが
FATの正統後継であるexFATは今も使われてるしSDカードの標準のファイルシステムとして公式採用されてる
だめだめの部分がなにか知らんがとっくに改良されておりよくできたファイルの一つとなってる
2020/09/25(金) 11:57:18.65ID:ElnYG5aU
お前はネットで検索した情報を知ったかする前に、まずは時系列順に並べ替えてみろ。
2020/09/25(金) 12:43:52.40ID:fcTjdC6n
>>177
それはお前がやるべきことだ
　　
なぜ俺が不利になる（？）ようなことを
俺がわざわざ調べないといけないんだｗ

反論があるならお前がしろ
自分が反論できないからって相手に反論の
材料を探させるという間抜けをするな
やるわけねーだろアホｗ
2020/09/25(金) 14:19:51.56ID:ElnYG5aU
ちゃんと調べれば自分が間違っていることに気づくぞ、というアドバイスなんだが。
不都合な真実は知りたくないというのなら、永遠に間違って理解してろ。
残念ながらお前は技術者には向いてないんだろうと思う。
2020/09/25(金) 14:27:52.78ID:Aqlkxpe2
ANSI文字列を扱うAPIをいまだに保守し続けているWindows
デフォルトエンコーディングをEUCから突然UTF-8に切り替えたunix

互換性を軽視しているのはどちらでしょう
2020/09/25(金) 14:29:21.59ID:6tDTZ4vt
>>179
調べてた結果正しかったです。調べたくない人が事実を知りたくないだと思います（笑）
2020/09/25(金) 16:02:35.34ID:ElnYG5aU
調べなくても、その辺の時系列はよく知ってるんだよ。当時、リアルタイムでおっかけてたので。
時系列誤解して、知ってるやつなら絶対に間違えないレベルの主張してるのがいたので指摘しとこうかと思っただけ。
お前は知りたくなければ知らなくて良いよ。
十分に事実は書いたので、後から奇特にもこのスレ覗きに来て、お前の妄言に惑わされる奴もいないだろうし。
p.s. 上から目線なのはジジイなので許せ。
2020/09/25(金) 21:10:47.40ID:DCkHs+Bt
>>180
その unix とやらの具体的で正式な OS の名称を教えてください…
2020/09/25(金) 21:18:32.55ID:K0BToZeX
しょっちゅう非互換な変更を加えるWindowsって具体的にはどれの事よ
2020/09/25(金) 21:22:39.15ID:K0BToZeX
https://docs.microsoft.com/ja-jp/archive/blogs/nakama/win10waas-part5a

カーネル依存性のないデスクトップアプリの場合、少なくとも「まったく動作しなくなる」といった致命的な問題はほとんど出ないと思います。
Windows 7 で動作していた .NET 3.5 のアプリのほとんどは、Windows 10 上の .NET 3.5 でもまず十中八九動作するはずで、
先行検証しているあるお客様からは、「まるで非互換問題が出てこないんだけれども、名前だけ変えてお金稼ごうとしてない？」とか言われたことがあるぐらいです；。
2020/09/25(金) 21:53:11.91ID:jsxvfqFg
>>185
マイクロソフトは互換性が高いと主張しています。それは事実だと思いますが
それでも断定はできないし保証はできないので検証は必要です。

ただしお客様の方で検証していただければお金は不要です。
問題があった場合は有償でサポートしますが対応に時間がかかることがあるので
余裕を持ったスケジュールで行ってください。

って言えば良いんかな？
2020/09/26(土) 04:29:55.57ID:V6Zu3iZf
>>183
そんなUNIXは存在しない。
Unix系の OS は Unicode よりずっと前に複数文字コード対応終わってるので。
MacOS を Unix だと主張するなら、違うかもしれない。解釈次第。
2020/09/26(土) 05:50:51.04ID:dJRFq1YT
> 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 などでは問題ない。
2020/09/26(土) 05:52:24.09ID:dJRFq1YT
ちなみにWindows NTは最初のバージョンから複数文字コード対応が終わっている
UTF-16（初期はUCS-2）がOSの標準文字コードだからね
2020/09/26(土) 08:35:16.23ID:4p5kvQE6
その定義だと WindowsNT は ShiftJIS に対応してないんだなこれが。
あくまで対応しているのは CP932 なんだ。
Linux は正しく ShiftJIS を規格書どおりに実装している。
問題は CP932 と ShiftJIS を後出しで別物にしちゃったマイクロソフトにある。
だから Linux でMS互換の文字コードを使いたい場合、ShiftJIS ではなく CP932 と設定する必要がある。
2020/09/26(土) 09:57:54.54ID:dJRFq1YT
>>190
だからLinuxはCP932に完全対応できずに終わったって言ってるじゃん
話すり替えるなよ
2020/09/26(土) 10:55:23.76ID:HIxn44p8
そういえば CP932 は ASCII 互換だったな。
（互換だったということにマイクロソフトがした）
2020/09/26(土) 11:00:49.52ID:ToQOodFb
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
2020/09/26(土) 11:16:52.56ID:lj7tia+j
>>191
話そらしてるようにしか読めないのなら、それがお前の知識の限界ってやつだ。
2020/09/26(土) 11:18:06.83ID:lj7tia+j
>>193
ちなみに Sony の NEWS とか知ってる？
196デフォルトの名無しさん
垢版 |
2020/09/26(土) 14:37:10.24ID:ER2LZL5Z
plamoっって久々に観たわ
2020/09/26(土) 15:20:39.47ID:dJRFq1YT
>>192
マイクロソフトはCP932がASCII互換なんて言ってないよ
それもあってかWindowsではANSIという呼び方をしている
2020/09/26(土) 15:23:26.93ID:dJRFq1YT
>>194
話をそらしてるのはお前でしょ。Linux および Unix が CP932 または ShiftJIS に対応してないって話なのに
Windowsがー、ShiftJISじゃなくてー、CP932なんだーってWindowsの話にすり替えてる

Linux および Unix の話に戻しましょう。

Linux および Unix が CP932 または ShiftJIS に完全対応してない
>>193にも書いてあるように日本語はASCII互換のEUC-JPを使っていた
2020/09/26(土) 15:35:39.57ID:nz56jET8
AIXはCP932系のCP943がデフォルトだったしSolarisも一応PCKというのを提供していた。
使うコマンド全てちゃんとlocaleに従う国際化していればできる話。
2020/09/26(土) 15:56:41.68ID:HIxn44p8
どんどんボロが出るな。
お前のういう ANSI と ASCII の違いって何。
Linux において Shift_JIS と CP932 の違いはわかる？
Sony の NEWS って知ってる？
2020/09/26(土) 15:59:25.33ID:HIxn44p8
>>199
IBM の Shift JIS とか教えてやんなよw
にわか君の脳がバグってこれまで以上に面白いことになりそう。
202デフォルトの名無しさん
垢版 |
2020/09/26(土) 16:25:27.51ID:Xs9MiFl7
NEWSとX68kは欲しかったな
2020/09/26(土) 16:26:57.63ID:QQeUS8EE
かつて、シフトJISは皆同じものであった。
その名は様々であったが、人々はシフトJISを使って互いに話し合うことができた。
ほんとは空き領域にメーカー独自に文字を追加してたり、外字領域として使っていたりしたが、同じものと主張していた。

傲慢になった人々はさらに多くの文字を要求した。
お怒りになられた神は Unicode をもたらされた。
各社が勝手気儘に Unicode とシフトJISの変換表を定義したので、ひとつのシフトJISは沢山のシフトJISに分割された。
人々は互いに言葉が通じなくなった。
204デフォルトの名無しさん
垢版 |
2020/09/26(土) 16:47:43.71ID:htO/NqgS
故・永井一郎氏でナレーションをつけたらガンダムみあってよいね。
2020/09/26(土) 17:05:55.71ID:iJutkljl
>>203
パソコン通信の時代
「文字化け」はノイズでテキストデータが一部壊れることを意味していた
文字化けをなくすしくみとして「MNP」があったけどそれも今では違う意味で使われている
206デフォルトの名無しさん
垢版 |
2020/09/26(土) 17:45:01.52ID:P5ZUvIL5
以前、GB18030の話したときの感じだと、素人集団だし、あまり他人のことをとやかく言っても仕方ないのでは。
2020/09/26(土) 21:16:56.96ID:v2ZzDIc8
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
2020/09/26(土) 21:54:59.76ID:BUinzsCm
ｲｲﾈ
2020/09/27(日) 00:06:12.54ID:YQFWAWcL
あんざいでいいのかな
2020/09/27(日) 01:32:39.82ID:m5Rqyw0A
あきらめたんじゃなかったのかオヤジ…
2020/09/27(日) 01:58:25.37ID:UrweFCig
ANSI の本来の意味は「アメリカ国会標準協会」、日本の JIS にあたる。
一般的な読みは「アンシー」。
もちろん文字コードだけを規定しているのでなくて、色々な規格を決めてる。
でも日本で俗に文字コードのことを JIS って呼ぶ感じで、ANSI って呼んじゃう。
ちなみに ASCII のアメリカ規格での正式な名称は ANSI X3.4 だった。(国際規格だとISO 646 IRV)
Windows の人たちは ASCII だけでなくて ASCII 系の拡張コードを全て ANSI って呼ぶ(ことが多い)。
(もちろん正式名称ではないので、正式なドキュメントでは使用しない)。
2020/09/27(日) 02:03:10.77ID:UrweFCig
国会じゃねえ、国家だ、「アメリカ国家標準協会」
2020/09/27(日) 14:48:04.56ID:UbuOwcm8
あまり詳しくないけどShiftJISの規格書とかあるんだな
2020/09/27(日) 17:40:16.09ID:UrweFCig
JIS X 0208 に「シフト符号化」として規格がある。Linux の SHIFT-JIS は基本これに従っている。
でも各社が空領域に勝手に追加した文字は、使ってはいけないことになってるのでマイクロソフトの CP932 とかとは完全な互換ではない。
2020/09/27(日) 18:22:15.82ID:I+ot45zN
もともと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
2020/09/27(日) 19:50:11.19ID:UrweFCig
そこにも書いてあるけど、最初に作られたシフトJIS には追加文字は無かった。
その後に各社が勝手に文字を追加していった。マイクロソフトもその後から互換性を無視した追加した一社。
JIS がシフト符号化方式を規格化する時の特定の会社に肩入れするわけにはいかないので、本来の空領域は使用禁止という方針を維持した。
Linux も OSS で多くの会社が開発に参加しているので、特定の会社には肩入れできないので、中立な JIS 規格のものを選ばざえる得なかった。
2020/09/27(日) 20:01:06.53ID:duNnLcqR
> マイクロソフトもその後から互換性を無視した追加した一社。
何を追加したというの？
2020/09/27(日) 20:02:45.37ID:duNnLcqR
> Linux も OSS で多くの会社が開発に参加しているので、特定の会社には肩入れできないので、中立な JIS 規格のものを選ばざえる得なかった。

多くのソフトはCP932とかいう名前で対応してるけど？
2020/09/27(日) 20:16:06.46ID:PpIfQt3T
何この馬鹿
2020/09/27(日) 20:42:09.15ID:UrweFCig
>> 217
もともとマイクロソフトの CP932 には追加文字は無かったんだけベンダー各社が勝手に文字を追加することを許していた。
Microsoft は Windows 3.1 を出す時に NEC と IMB が拡張した文字を参考に独自に CP932 に文字を追加し、さらに各社が勝手に Windows に文字を追加することを禁止した。
つまりマイクロソフト CP932 には昔ながらのものと、拡張されたものと2種類がある。
インターネットの正式規格(IANA)には後者に Windows-3.1J として登録されている。
両者を区別した場合に俗に後者を MS932 と呼ぶ人たちもいる。
2020/09/27(日) 20:55:03.90ID:UrweFCig
>>218
そう。Linux では Shift_JIS と CP932 は別の文字コードという扱いになってる。
2020/09/27(日) 21:07:18.47ID:xq8pY9v9
なんか主張がブレまくってる気がするけど、結局どういうことを主張したいの？
2020/09/27(日) 21:09:23.04ID:UrweFCig
SHIFT JIS には種類がいっぱいある。同じ名前でも同じものだとは思うな。互換性はない。
2020/09/27(日) 22:15:06.93ID:duNnLcqR
>>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
2020/09/27(日) 23:12:33.54ID:G6Rp/5vA
nkfだと、sjisとcp932で扱いが異なる。
最初sjisでうまくいかないで、cp932だとうまくいった。
俺にとってのcp932事始め。
2020/09/27(日) 23:17:27.83ID:xq8pY9v9
結局、Linuxがどうたら言っていた話はなんの関係があったんだろうか
2020/09/27(日) 23:21:06.50ID:duNnLcqR
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.65ID:yUM2IYPL
2022も一枚岩じゃねーのにMSシフトだけ悪者かよw
2020/09/28(月) 00:45:44.06ID:IvlPnhNT
そういやEUC-JPも亜種が多かったね
2020/09/28(月) 02:22:56.82ID:LFNRA5Wr
技術の話だからな、誰が邪悪で誰が正義とかはないぞ。
種類が多数あるから気をつけろ。あえて言えば非互換な変更は可能な限り避けろ。

あと別に NEC と IBM だけが独自拡張してたわではないぞ。
Apple や Fujitsu を始めとして他も各社独自拡張してた。
マイクロソフトはビジネス上の都合で普及してた NEC と IBM のもののみから取捨選択した。
そこそこ普及してたけどライバルだった Apple のもは無視した(互換にする理由が無かった)。
2020/09/28(月) 03:00:06.80ID:aMwTz6q2
code page 932 って元々MSじゃなくて IBM の規格だけどな。
IBM が作った OS/2 とうのがあってな。それ用の文字コード名だった。
MS は IBM が OS/2 を作るのに技術協力しててな、その後に Windows 作る時にその用語をそのまま使った。
MS が拡張する前の CP932 を IBM 932 と呼ぶ人がいるのはこれが理由。
232デフォルトの名無しさん
垢版 |
2020/09/28(月) 03:09:14.91ID:Btw2QdlH
うちがIBM社から依頼されて制作したのが始まり。
当時は広く調査する手段が無く、偏りがある事は認める。
2020/09/28(月) 03:09:23.25ID:LFNRA5Wr
>>231
そういえば IBM は律義なので、文字を追加して互換性のないやつは CP943 とか別の番号を割当てて名前を変えてたんだよな。
MS はその辺を参考に文字を追加したやつも CP932 と呼び続けたのは何でだろう。
2020/09/28(月) 03:39:47.21ID:IvlPnhNT
>>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年のようだ
2020/09/28(月) 04:20:00.06ID:LFNRA5Wr
code page 番号での管理は IBM が汎用機時代からずっとやってきた名前で、
マイクロソフトは後から、その番号をそのまま採用したって聞いたけど、違うの？
2020/09/28(月) 05:06:08.90ID:IvlPnhNT
>>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
2020/09/28(月) 09:14:02.90ID:8EXAUbY4
共通のコードページを使うようになったのはいつから？
そこが曖昧なんだよな。
マイクロソフトは元々 CP932 とは呼んでなかったという意見があるみたいなんだが。
2020/09/28(月) 09:33:14.92ID:UEVgwzRH
>>234
NEC は厳密に言えば CP932 に文字を追加したわけではないからなあ。
NEC や Fujitsu がやったのは漢字ROMの空き領域に字形を追加した。
これをやると OS とか文字コードに関係無く使える漢字が増える。CP/M でも BASIC でも。
2020/09/28(月) 09:42:09.44ID:ZQPU+aZv
ANSI先生、シフトジスがめんどくさいです...

>>227
HTMLでcharset=Shift_JISであっても実際はWindows-31Jだったりする。
巷の大概のブラウザはWindows-31Jにしかない文字があっても開ける。はしご高とか。

そうやってある意味グダグダになっていく（った）わけやね。でもしょうがないのかな。
厳密な挙動をしても「えーこのブラウザ文字化けするー」とか言われちゃうのがオチだし。

ま、HTMLはもうだいぶUTF-8になってきてるし、いっかw
2020/09/28(月) 10:30:21.69ID:IvlPnhNT
>>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は存在しないから
日本では知られてなかっただけじゃないの？
2020/09/28(月) 10:39:54.81ID:Uhat3CEo
>>238
NEC の汎用機に文字が追加された。もちろんSJIS関係ない。
NEC の汎用機の端末として使えるようにするために PC9801 の漢字ROM は NEC追加文字が含まれて状態で発売された。
ちばみに IBM拡張漢字ROMは別売オプション。
PC9801 に MS-DOS を移植したら、あーら不思議、最初から使える文字が増えてた。
という順序だな。
2020/09/28(月) 10:41:07.34ID:IvlPnhNT
>>238
MS-DOS、漢字ROMの時代はOSが知っているのは文字コードだけで
そこで表示されるフォントはハードウェア搭載されてるものだったからね

ShiftJIS系は全て同じものとして扱うことしかできなかった
勝手に違う文字コードに化けさせるわけには行かないし

細かい文字コードを区別できるようになったのはフォントをOSで
処理するようになったWindowsから
だからそのときに改めて統一する必要がでてきた
2020/09/28(月) 10:45:58.86ID:Uhat3CEo
>>240
最初(1982年)からCP932だったという主張は撤回するのん？
2020/09/28(月) 10:46:31.48ID:IvlPnhNT
NEC独自の文字としては2バイト系半角文字がお気に入りだったな

数字やアルファベットが縦長で、全角半角混ぜても違和感ないんだよ
2バイトだけど文字幅は1バイトと同じでな

表示位置の調整の計算は、2バイトは1バイトの倍として
計算するだけでは駄目だったんだよ
1文字ずつ見ていって文字コードの範囲をみて計算する必要がある

ライブラリもなかったしC言語で実装するのはすっげーめんどくさかったクソ仕様
2020/09/28(月) 10:47:44.81ID:IvlPnhNT
>>243
してないよ。MS-DOSでは最初からCPxxxというコード体系が使われていたと言ってる
当時は日本で広まっていないだけ
2020/09/28(月) 11:04:04.80ID:PU8P18gE
>>245
推測とかじゃなくて、その根拠が知りたいんだが。どこ情報？
2020/09/28(月) 11:07:15.33ID:cf3OGOhX
あ、別に否定してるわけじゃないよ。
世間一般に曖昧なんでちゃんとした根拠があるなら知りたい。
2020/09/28(月) 11:21:20.86ID:IvlPnhNT
>>246
そんなに答えを求めてるなら「今となってはわからない」が正解じゃねｗ
少なくともCP932が使われていなかったという根拠はないからね
2020/09/28(月) 19:55:51.42ID:iFBbxDDj
もう、PC98 に搭載されている漢字 ROM が正義、とするのがいいかと
で、PC9801 各シリーズおよび PC9821 各シリーズで差異があるかどうかが問題

私の一番すきな 98 は 98FA なので、98FA が正義でありたい
2020/09/28(月) 20:15:42.82ID:LpDzonCU
□□□□□□□□□□□□□□□□□□□□□□□□□
□□■□■■□□□□■■□□■■■□□□■■■□□
□■■□□□□■□■□□□□□□□■□□□□□■□
□□■□■□□■□□□□□□□□□□□□□□□□□
□■□□■□□■□□□□□□□□□□□□□□□□□
□□□■■■□■□□■■□■□□□□□■□□□□□
□□□■■□□□■□□□□□■■■■□□■■■■□
□□□□□□□□□□□□□□□□□□□□□□□□□
2020/09/28(月) 21:40:36.46ID:o1iMmVBZ
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を採用しているコンピュータであるにもかかわらず、登録されている文字集合がバラバラだった。
2020/09/28(月) 21:49:17.49ID:TR69hVPT
jawpをソースにするなよ
2020/09/28(月) 22:15:52.03ID:F7s1Ev+m
当時としてはMS-DOSはコンピュータで動くOSの１つでしかないのに
マイクロソフトがコンピュータに搭載する文字集合を決めるなって話だろ
2020/09/28(月) 22:32:50.70ID:iFBbxDDj
>>253
そういう意見など、奴らは無視して漢字を 16ビットに無理やり押し込めにかかり、
あわてた中日韓が妥協させられてできあがったのが CJK 漢字統合
月日は流れ、結局 16 ビットの中に世界の文字を押し込めることなど出来ないと奴らが悟った後には、醜い CJK 漢字統合だけが残されたのであった…
2020/09/28(月) 22:43:50.48ID:F7s1Ev+m
>>254
そんな話してないよ
2020/09/28(月) 23:19:53.80ID:LFNRA5Wr
人はみな自分の話したいことのみを話す。

>>249
NECの漢字ROMに合わせると、旧JISになるのだが、それでよろしいか？

実はこれま語られた以外にも Shift JIS には、いわゆる旧JIS(JIS78) と新JIS(JIS83)の違いというヴァリアントがあるんだよな。
NECの漢字ROM は旧JIS準拠で、富士通の漢字ROMは新JIS準拠で、互換性が無かったりとか。
マイクロソフトも Shift JIS 作った時には旧JISしか無かったはずなので、旧JIS準拠だったはずなんだけど、
今の CP932 は新JIS準拠の字形になってるので、どこかの時点(多分 DOS/Vあたり)で、ちゃっかり入れ換えてるんだよな。
2020/09/29(火) 01:44:43.55ID:xt+EJgQq
なんとなーく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専用のコンピュータというわけではない

ハードウェアの仕様の話なのになぜマイクロソフトに命令されなければならないのだ？という話になる
2020/09/29(火) 01:52:41.35ID:xt+EJgQq
>>256
> マイクロソフトも Shift JIS 作った時には旧JISしか無かったはずなので、旧JIS準拠だったはずなんだけど、

マイクロソフトがやったのは実質シフトJISからJISコードへの変換でしかないので
例えば古いバージョンのMS-DOSのバージョンで古い一太郎（笑）を使っていて
それを収録文字数が増えた新しいハードウェアに買い換えるとMS-DOSも一太郎も同じ古いままで
新しい文字に対応できてしまうんだよね。対応する文字は漢字ROMで決まることだから

つまりMS-DOSはCP932を想定していたとしても
実際に対応する文字はMS-DOSで決めることができない

マイクロソフトが使ってる文字コードをShiftJISと呼ぼうがCP932と呼ぼうが
NECや富士通なんかが勝手に文字を追加してしまうわけ
2020/09/29(火) 03:15:45.97ID:3c9yndle
そもそも IBM も NEC も富士通も、パソコンの主な使用目的の一つは、自社の大型コンピューターの端末として使うことだったからな。
だから自社の汎用機に合わせて文字を追加したんであって、MS-DOS とか眼中にはない。
追加した漢字が MS-DOS からもたまたま使えただけ。
パソコン専用の Apple の文字追加はまた別の理由だが。
260デフォルトの名無しさん
垢版 |
2020/09/29(火) 06:39:24.27ID:jqf8qavY
東風フォントの人元気かな
2020/09/29(火) 08:26:34.17ID:asv0X/wS
>>252
だったらWikipedia以外のまともなソースとやらを出してくれよ
どうせ出せないんだろ？
2020/09/29(火) 11:27:29.43ID:3c9yndle
今となっては別に昔の名前なんてどうでもだが。
アスキー・マイクロソフトが出した最初に Shift JIS に対応した MS-DOS 2.01 では MIcrosoft Kanji Code が正式名称だった。
MS-DOS のソースコードの中でSJISの処理をする部分は KANJI という表記だった。
2020/09/29(火) 13:51:59.38ID:qO9m7cfy
https://upload.wikimedia.org/wikipedia/commons/thumb/b/ba/JIS_and_Shift-JIS_variants.svg/2880px-JIS_and_Shift-JIS_variants.svg.png
2020/09/29(火) 14:17:45.42ID:xt+EJgQq
>>263
図をまとめる下手すぎ
わざとわかりづらくしてるようにしか見えない
2020/09/29(火) 17:25:53.58ID:3c9yndle
白黒の限界を感じる。後、矢印の向きが派生ではなく包含関係だったりして、
通常とは逆なので知らない人が見ても理解するのは難しいかも。努力は認める。
>>264
文句あったらお前が書き直せ(お約束)
2020/09/29(火) 17:37:33.69ID:aO5ZnI7G
>>264
時系列とかメーカーで横に並べるべきだろうね
2020/09/29(火) 17:39:10.32ID:aO5ZnI7G
EUC-JPとShiftJIS系とUnicode系でも分けるべきだし
包含関係でまとめられるのはまとめるべきだろう
2020/09/29(火) 17:51:57.33ID:3c9yndle
ぱっと見てみたけど、包含関係は、かなり正確だな。
今までここに上げられた、いい加減な図と比べるとかなりマシ。
NEC の CP932 と、IBM の CP932 を混ぜて Windows CP932 ができたなどという中途半端な説明が
間違いということが、わかるように書かかれている。
2020/09/29(火) 17:55:22.30ID:aO5ZnI7G
>>268
図の真ん中、Shift-JIS Windows 932は
Shift-JIS with NEC r13 and 89-92 and IBM DBCS からできたって書いてありますが？
2020/09/29(火) 18:03:23.01ID:aO5ZnI7G
そして、その「Shift-JIS with NEC r13 and 89-92 and IBM DBCS」は
「Shift-JIS with NEC r13 and 89-92」＋「Shift-JIS with IBM DBCS」のことだって書いてありますよね？
2020/09/29(火) 18:17:32.15ID:3c9yndle
左からも矢印が延びてるの見えない？
2020/09/29(火) 18:20:25.83ID:aO5ZnI7G
左からの矢印？
そりゃいわゆるShiftJISと呼ばれたものに「NECの追加文字」と「IBMの追加文字」を加えたって言ってるんだから
左のもの（基本的な文字セット）もあるに決まってんだろｗ
2020/09/29(火) 18:34:13.19ID:3c9yndle
都合の悪いものは見えない目をしてる奴がいるようなので、
その図で表示されている文字集合の関係を表にしてみた。
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漢字)
2020/09/29(火) 18:35:11.83ID:3c9yndle
表ズレた。すまん。
2020/09/29(火) 18:39:08.12ID:aO5ZnI7G
>>215のリンク先に書いてある

> マイクロソフト標準キャラクタセット (Windows-31J、MS932) は、
> マイクロソフト社が使用している日本語用文字コードで、 シフトJISの一種です。
> [37]標準的なシフトJISに加え、NEC や IBM の拡張に由来するいくつかの追加文字を収録しています。

NEC や IBM の拡張に由来する「いくつかの」追加文字を収録していますという話を繰り返しただけか
リンク先読んでねーなこいつｗ
2020/09/29(火) 18:41:53.46ID:3c9yndle
再挑戦。
Ａ　Ｊ　Ｋ　Ｘ　漢　Ｉ漢　Ｎ特　Ｎ漢
×　○　○　×　○　×　　×　　×　　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漢字)
2020/09/29(火) 19:33:37.91ID:3JpWukK6
ASCII 互換じゃないから Linux では SJIS は使えないｷﾘ
とかほざいてたのいたけど、実際には ASCII 互換じゃないと困るのは Windows の方だったという落ち。
樂しい♪
2020/09/29(火) 19:49:07.20ID:3c9yndle
>>277
仕方ないよな。UNIX 系のパス区切りは / なので ISO-646 系ならどれでも共通だけど
Windows はパス区切り \ なので国ごとに違っていて、Unicode に変換した時に困る。
2020/09/29(火) 20:13:35.05ID:gQNOuyE2
>>278
ん？
Windowsのパス区切りは、あくまでバックスラッシュで、
それぞれの言語環境で別の文字に見えてるだけでしょ？
割り当てられた文字コード番号自体は同じじゃないのか？
2020/09/29(火) 20:34:00.58ID:5fiAtNx/
>>279
win32api から見る限り、パス区切りは \ であっても / であっても使えます
2020/09/29(火) 20:51:03.40ID:aO5ZnI7G
>>277
アプリケーション側の問題だからね
OSだけ対応していても
2020/09/29(火) 20:55:47.86ID:jqf8qavY
mohtaの昔から文字コードの話はなんでこう揉めるんだろ
2020/09/29(火) 22:01:45.11ID:9ObbGclz
https://docs.microsoft.com/ja-jp/previous-versions/visualstudio/visual-studio-2008/77859s1t(v=vs.90)

UNIX ではパス デリミタとしてスラッシュ (/) しか使用できませんが、Win32 オペレーティング システムは円記号 (\) とスラッシュ (/) の両方を使用できます。
2020/09/29(火) 23:21:22.59ID:ht078/Zc
バックスラッシュをファイル名に使えるからデリミタに使う意味がない
2020/09/30(水) 00:15:57.00ID:mE7lggX7
それどころか多分どの制御コードやDEL、極めつけは
改行コードまでLinuxやUNIXはファイルめに使えるんだ
すごいだろー

findでどうやって改行コードが入ったファイル名を扱うのか知らんがｗ
2020/09/30(水) 00:17:36.68ID:mE7lggX7
バックスラッシュをファイル名に使うと面白いことができて
echoでそのファイル名を表示すると、色を付けたりできるんだｗ
2020/09/30(水) 00:18:07.91ID:mE7lggX7
間違ったｗ 色をつけるのはエスケープコードだったｗ
2020/09/30(水) 00:24:04.53ID:h1wvHACb
🐏スケープゴートに空目したわ
2020/09/30(水) 00:24:37.97ID:JM4zIKtb
>>285
たいていのシェル環境だとデフォルトは Ctrl-V の後に改行を入れる。カスタマイズ化。
2020/09/30(水) 00:25:31.56ID:h1wvHACb
訂正。🐐ゴートは羊じゃなくて山羊
2020/09/30(水) 00:27:29.17ID:JM4zIKtb
入力でなくて出力の話なら -0 オプションで、改行区切りから Null 文字区切りに変更できる。
292デフォルトの名無しさん
垢版 |
2020/09/30(水) 01:46:35.60ID:bt+pY3Wp
ぬるぽ
2020/09/30(水) 02:06:47.48ID:mE7lggX7
>>291
それはPOSIX準拠じゃないんだよなｗ
UNIXは改行が使えるから、UNIXで苦労するｗ
2020/09/30(水) 02:08:30.20ID:mE7lggX7
ファイル名にコロンが使えるから
PATHのコロン区切りで問題が出るというねｗ
制御文字と一部の記号は使えないようにするべきだっただろうな
2020/09/30(水) 02:13:17.35ID:JM4zIKtb
アホか？ 使いたくない文字は使わなきゃ良いだけなんやで。
わざと変な文字入れて、変な文字入れられる方が悪いとか、小波。
2020/09/30(水) 02:17:17.38ID:mE7lggX7
>>295
論点ずれてるぞｗ
いろんな文字が使えちゃうから、それが原因でバグになるということだ

ファイル名に改行を入れられるってことを知らないで作っていたら
「bin<改行>lib<改行>etc」みたいなフォルダを消そうとして被害にあったり
「a*?」みたいなファイル名でaで始まるファイルが全部消えたりｗｗｗとか
実際に起きてるからな
2020/09/30(水) 02:26:40.95ID:d/2ZwJCe
>>292
ｶﾞｯ
2020/09/30(水) 02:26:53.11ID:JM4zIKtb
制限したいやつが制限すればええんやで。Linux にはその仕組みがある。
普通の人はそんなことせんでも変は文字入れないから、困ってないだけ。
2020/09/30(水) 02:49:29.19ID:mE7lggX7
入れたくていれるんじゃなくて
端末に文字をペーストしたら変な文字を実行しちゃったりして
その結果変な名前のファイルができたりするんだよ

*とか?とか<とか>とか!とかシェルのメタ文字は
ファイルに使えないようにするべきだった
互換性があるから手遅れなんだろうけど

普通の人は変な文字入れないというのなら
なおのこと入れられないようにしてよかったということになる
2020/09/30(水) 03:03:44.88ID:JM4zIKtb
だから、そんな間抜けなユーザー抱えてんなら管理者が制限設定入れとけや。
普通、変なファイルできても ls すれば、すぐ気付くし、シェルの補完とかも対応してる。
やってみもせずに妄想垂れ流す暇あったら触ってこい。
それでも駄目だと思うんなら、システム制限掛けとけ。
2020/09/30(水) 03:11:45.53ID:mE7lggX7
シェルの補完にバグがないとどうしているんだ？ｗ
メタ文字とかは勝手にエスケープが入ったりする。だがそれが正しいとどうしていえる？
どうエスケープすればいいかを知らなければ、今からエンター押しても大丈夫か？なんてわからんはずだが
だから俺はGUIから消すようにしてるよ。GUIならシェルのワイルドカード展開なんて使えないからね
2020/09/30(水) 03:15:35.92ID:JM4zIKtb
お前に Linux は早過ぎた。
バグが心配ならソースでも眺めとけ。ここプログラム板やし。
2020/09/30(水) 03:23:32.50ID:mE7lggX7
初心者「バグがあるかもしれない」
プログラマ「バグなんてあるわけない」

こういう考えかｗ
2020/09/30(水) 03:39:20.46ID:JM4zIKtb
初心者： いきなりバグとか心配しない。気になったたらドキュメントとか、ネット調べたり、試行錯誤して学習する。
プログラマ：いきなりバグとか心配しない。気になったらソースコード確認して、万一バグを見つけたら自分で直す。
お前：根拠無くバグが心配になり、5ch でOS の仕様にケチをつける。
2020/09/30(水) 03:41:07.93ID:mE7lggX7
>>304
お前が気になったことの例を１つでも上げてみてよｗ
2020/09/30(水) 03:51:15.98ID:mE7lggX7
なんてレスしてるうちにバグ報告したとある有名プロジェクトから
修正したってコメントが有ったわｗ
2020/09/30(水) 10:44:11.67ID:fhthbmek
MS「CON\CONなんてパスを指定する奴なんているはずないな」
2020/09/30(水) 11:03:16.10ID:h1wvHACb
>>307
バグじゃなくて仕様だよ。予約されてるから。
2020/09/30(水) 11:04:41.69ID:h1wvHACb
制約事項として明記された不具合は仕様と呼んでいい。
2020/10/02(金) 03:35:07.39ID:rHkefn4v
>>99
それなら普遍的に使えるスタイルとの結合文字にすりゃいい話
だけどそうしないのはそもそもスタイルと文字は分ける設計だから
スタイルはCSSなり他の技術がある
2020/10/02(金) 03:36:07.77ID:rHkefn4v
肌の色とか差別がなかったところに肌の色って概念を導入した結果結局偏りが生まれてるクソ仕様
2020/10/02(金) 03:47:03.40ID:b+gARvx0
>>311
それはもう解決済みの問題です
313デフォルトの名無しさん
垢版 |
2020/10/02(金) 11:31:57.29ID:vWjl5fwE
こんにちは、初めまして。

今、個人的に 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,'&#xFF5E;') は
JIS x0213:2004 コード規格の 波線(U+301C,'&#x301C;') に正規化することにしています。
(その他、似たような文字はなるべく一種類に正規化出来ればと考えています)
314デフォルトの名無しさん
垢版 |
2020/10/02(金) 11:37:56.63ID:vEIDHK0R
グレープってなんだって思ったらグラーブのことか
2020/10/02(金) 11:59:54.40ID:ooD45Zz3
Ruby に、そのエンコードは無いの？
316デフォルトの名無しさん
垢版 |
2020/10/02(金) 12:00:25.80ID:vWjl5fwE
どうぞ。

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.67ID:vWjl5fwE
なんとなく備忘録

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 で６バイトのコードを表示するのも辞めてほしい・・・、
2020/10/02(金) 15:25:55.64ID:rmc8/xO8
日本の PC の内臓フォントは JIS X 0201 だったので、SJIS の 0x5C は円記号ということで運用されていたのだけど
Windows 3.1 で Unicode 対応を入れる時に ASCII 互換じゃないとうまくいかないことに気付いて、
CP932 の 0x5C を「見かけは円記号に見えるけど、実際には逆射線ということにした。円記号に見えるのはフォントせいで心の目で見ると逆射線」ということにした。
そのせいで Windows の一部日本語フォントを使った場合のみ 0x5C と 0xA5 の両方が円記号で表示される。
解決法: (1)別のフォントに変える。(2)Windows を捨てる。
2020/10/02(金) 15:54:09.42ID:rmc8/xO8
Unicode 的にはどっちでも良いのだけど JIS X 0213 的には 1-11-48,49 は 1F72,1F73 との対応を示しているので、そっちにしておくのが無難かな。
一文字にしておけば、結合文字に未対応の環境でも変にならずにすむし。
320デフォルトの名無しさん
垢版 |
2020/10/02(金) 16:07:25.61ID:gdIx8v5/
>>318
消火器と消化器は間違えんなよ。小火器も使う時あるからな。
2020/10/02(金) 17:58:09.59ID:rmc8/xO8
おう逆射線と逆斜線の変換ミスな。気付いてなかったわ。すまん。
2020/10/02(金) 18:49:02.52ID:zXx3uGG2
>>318
Windowsだけでなく、国産Android端末もそういうフォント入れてる。
Android標準のnotoなら正しくバックスラッシュ出るんだけど、SONY端末には入ってないんだな。
323デフォルトの名無しさん
垢版 |
2020/10/02(金) 18:54:47.21ID:vWjl5fwE
>>319
サンクス。
U+1F70 , U+1F71 , U+1F72 , U+1F73 は一文字の方を正規化先にして作ってみることにします。
2020/10/02(金) 20:47:22.49ID:ErcYaiEt
>>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の意味はチルダでグリフも～だからそっちはそのままでいい

チルダ関係もカオスだよね
『～』と『～』別な文字だけど区別できる見た目で表示されているほうがむしろおかしいんだっけ?
2020/10/02(金) 21:00:45.39ID:Va1PciQI
PDF に謎の漢字が含まれるとき
https://gist.github.com/xl1/940d653451fd96a06618a6df08d5df84
2020/10/02(金) 21:17:20.27ID:zXx3uGG2
ピントはずれ。
シフトJISできる前からJIS C 6220のソースをコンパイラに食わせてた。
コンパイラは0x5cにASCIIのバックスラッシュ以外の意味知らないし、そう扱って問題は出ない。

シフトJISとコンパイラで問題がでるのは文字列リテラル中のダメ字。
2020/10/02(金) 21:57:12.83ID:ErcYaiEt
>>326
> コンパイラは0x5cにASCIIのバックスラッシュ以外の意味知らないし、そう扱って問題は出ない。
正しく国際化されているコンパイラでは問題を起こす

実際2000年前後の国際化対応gccでShift_JISで書かれたコードで問題が起きたことがある
(ダメ字を問題なく処理できるのに￥ｎが改行と解釈されない)

日本語環境ではみんな雑に捉えて￥と＼を区別していなかったのは事実だけど、トライグラフが
ANSI Cで導入された以降Shift_JISで書かれたコードは正しく解釈すると規格に反する状態であった

実際にトライグラフをまともに使っていたのはデンマークだっけ?
2020/10/02(金) 22:12:09.12ID:rmc8/xO8
厳密にいうと C言語のソースは基本文字集合と呼ばれる 1バイト文字を含まなければならない。それには \ のみで ￥ は存在していない。
JIS の C言語の規格ではソースに JIS X 0201 を使用する場合は \ と ￥ を置き換えることになっている。
1バイト文字の解釈は必ず基本文字集合と同じでなければならない。
多バイト文字やシフト状態を持つ文字でナル以外の文字に 0x00 のバイトが来るのは禁止。
シフト状態を持つ場合には初期シフト状態に基本文字集合を持たなければならない。
上記を満たせば多バイト文字の解釈は実装依存。
2020/10/02(金) 22:13:24.20ID:ErcYaiEt
>>327
実際にgccのShift_JISとCP932ハマった人の例見つけた
ttps://blogger.tempus.org/2008/03/gcc-shiftjis.html
330デフォルトの名無しさん
垢版 |
2020/10/03(土) 00:32:32.33ID:5QIBKgVv
文字コードを意識せずにプログラミングが出来るようになる革命はまだですか？
2020/10/03(土) 00:59:47.45ID:g9HEPfwG
革命とは過去の遺物を捨て去ることだよ。
2020/10/03(土) 09:47:26.20ID:8tX55Lof
>>328
> JIS の C言語の規格ではソースに JIS X 0201 を使用する場合は \ と ￥ を置き換えることになっている。
ANSI CやISO 9899にそんな規定はない
JISX3010で参考として追記された箇所であってローカル規格

そもそも￥を＼の代わりに使っていいなら何のためにトライグラフを国際規格に入れたの?
￥を＼と解釈するJISX3010は国際規格ISO 646に反しCP932と同じ超解釈の類

gccの振る舞いが国際規格に準拠する正しい動作
333デフォルトの名無しさん
垢版 |
2020/10/03(土) 10:32:33.14ID:1CYfZXkg
ideone.com とかは
スマホから試すときとPCから試すときで
\と＼の扱いが違って動きが可笑しくなることがある
unicode になって区別が明確になったことによる弊害のひとつ
2020/10/03(土) 14:19:07.86ID:asw2Nmie
>>322
だから JIS の C言語の規格で、なおかつ入力に JIS X 0201 を使う時、限定と書いてるじゃん。
コンパイラがロカール規格に対応していたら使って良いんだよ。
gcc がローカル規格に対応する義務はないが、ちなみに gcc には LANG=C-SJIS という設定があってな。
2020/10/03(土) 14:23:10.98ID:asw2Nmie
アンカミス。 322 → 332
336デフォルトの名無しさん
垢版 |
2020/10/03(土) 14:44:31.16ID:y5FkQ2yd
もちつけ
2020/10/05(月) 00:37:11.64ID:aYBNZcXd
>>323
どうなんだろうね。
確かにユニコード的には例えばNFDにしたときのベースの文字が正解かと。
一方 U+025X はIPAのブロックで、要は発音記号... ということは、文脈的に発音記号
として使われているならこっちだったりするのかも?
2020/10/08(木) 10:57:17.71ID:tD965ZiH
Rubyをやってるんだけど、分からないところあるから教えてほしいです…
クラスメソッド、インスタンスメソッド、インスタンス変数あたりの意味がさっぱりで…
339デフォルトの名無しさん
垢版 |
2020/10/08(木) 11:08:48.28ID:Riy1MZEi
説明読んでも意味が判らない間は無理に使う必要は無い
君にはまだ早いってこと
2020/10/08(木) 11:25:58.08ID:e+h9pet/
>>338
Ruby 初心者スレッド Part 66
https://mevius.5ch.net/test/read.cgi/tech/1578068134/
2020/10/08(木) 11:34:16.59ID:SMtYwKCf
個人的に普段は ruby は使わないんだけど、文字コードの実装は perl や python や java に比べると ruby は筋が良いんだよな。(個人の感想です)
2020/10/08(木) 21:30:15.81ID:24ftK7/Z
>>341
python使いの私に文字コード関連でのrubyの利点についてぜひご教示ください。
rubyはさわったこと無いです。
2020/10/09(金) 09:29:33.69ID:81dxs4Bx
ドキュメントを見ると結構マイナー(?)なエンコーディングもあるっぽいね。
ケータイ各社の絵文字入りSJISとかもあるんだ。
https://en.wikibooks.org/wiki/Ruby_Programming/Encoding
2020/10/09(金) 11:37:23.24ID:5kgt8bw0
>>342
Python は内部格納文字コードに unicode を固定で使用していて、unicode に変換できない文字は使えないし、
unicode に変換した場合に unify などで消える情報は保持できないけど、
ruby は特定の文字コードを仮定した内部コードを持たないため、programing や library の実装でどうにでもなる。
初心者には Python の実装がわかりやすいけど、文字コードそのものをいじりたいレベルになると嵌ることがある。
概要は ruby m17n とかで、検索してい関連しそうな記事を読んで見ると良いかと。
345デフォルトの名無しさん
垢版 |
2020/10/09(金) 11:44:47.75ID:vl+UDRkB
うそはいかんよ
python は binary も自由に扱える
2020/10/09(金) 12:08:49.92ID:8qJEmYsV
>>345
バイナリは文字じゃないので文字列の長さすらわからない
低機能なデータ形式でしかない
347デフォルトの名無しさん
垢版 |
2020/10/09(金) 12:37:20.08ID:vl+UDRkB
ruby は文字じゃないものの文字列長をどうやって計算してるのですか？
2020/10/09(金) 12:38:41.36ID:EjYkYVIx
>>347
文字じゃないものの文字列長なんて計算できるわけ無いでしょ（笑）
だからいろんな文字コードを文字として認識できるようになってる
それに対しPythonはバイナリだから文字列の長さが計算できない（大爆笑）
349デフォルトの名無しさん
垢版 |
2020/10/09(金) 12:44:19.84ID:vl+UDRkB
うそはいかんよ
馬鹿丸出しだから煽りは止めた方が良い
350342
垢版 |
2020/10/09(金) 12:45:15.41ID:hk0qQeVw
>>344
ありがとうございます。
個々の文字列オブジェクトにエンコーディング情報を持たせてるので
文字コードを変換せずにm17nを実現できてる感じですね。
2020/10/09(金) 20:40:06.43ID:phj7/P3X
漢字のようで漢字でないUnicodeの「康熙部首」と「CJK部首補助」
https://techracho.bpsinc.jp/hachi8833/2020_10_07/95257
2020/10/10(土) 09:48:22.75ID:mP3lsNpF
Unicode 3.0って1999年だろうに
2020/10/10(土) 22:38:12.17ID:vUhDQSk6
nuby からの流れで... nkf　って今でもメンテされてるようで。
ネットニュースから shar で入手したのはいつの日か。
2020/10/10(土) 23:59:49.31ID:33g/v1Rs
Unicodeの文字の情報を見たいと思ったら
どれを参照すればいいの？
2020/10/11(日) 01:36:12.47ID:PkCT08SK
情報って？
2020/10/11(日) 01:53:31.67ID:QQ2vPcGT
Aという文字の小文字はaであるとか
2020/10/11(日) 02:42:43.61ID:Y6xs0w7V
Unicodeのcode chartにはいちいち文字の説明が書いてあるがそれ以上の説明が欲しいのか否か？

https://unicode.org/charts/
2020/10/11(日) 06:59:02.20ID:QQ2vPcGT
>>357
それらの情報を全て文字ごとに知りたいんだよ
2020/10/11(日) 07:21:36.62ID:X3noy0YM
>>358
"Find chart by hex code:" ってとこにコードポイントを入れてみようw
2020/10/11(日) 07:33:27.40ID:QQ2vPcGT
>>359
情報が全く足りません
2020/10/11(日) 07:34:05.33ID:QQ2vPcGT
Aは大文字であり、対応する小文字はaである
という情報はどこに書かれているのでしょうか？
2020/10/11(日) 08:36:01.64ID:9KwtZAoB
https://unicode.org/charts/PDF/U0000.pdf
これの
LATIN CAPITAL LETTER A
LATIN SMALL LETTER A
区別じゃ足りないかい？
2020/10/11(日) 08:49:30.81ID:biiSH/I3
> 0041 A LATIN CAPITAL LETTER A
少なくとも「Aは大文字」は明記されてるけど？？

> 0061 a LATIN SMALL LETTER A
小文字aの定義の記述から対応する文字も分かると思うんだけど
それじゃわからないということであれば、
「大文字Aに対応する小文字はaである」みたいなことは
Unicodeの仕様書じゃなくて英語圏の小学生or幼稚園児向け教科書とかに書かれてるんじゃないかね
2020/10/11(日) 09:48:07.57ID:EIUTbwb3
何が欲しいか、もっと明確に書かないと伝わらないぞ。
例えばこれとかは使える？
https://unicode.org/Public/UNIDATA/UnicodeData.txt
2020/10/11(日) 10:11:43.02ID:X3noy0YM
>>364
使えるかどうかは能力の問題ですよねw
2020/10/11(日) 10:24:25.43ID:ieSx8e01
>>364
これは対応した項目があるねぇ
装飾のあるアルファベットについても参照番号が載ってる
367デフォルトの名無しさん
垢版 |
2020/10/11(日) 12:14:43.64ID:kZXFoyze
ほう
3041;HIRAGANA LETTER SMALL A;Lo;0;L;;;;;N;;;;;
3042;HIRAGANA LETTER A;Lo;0;L;;;;;N;;;;;
2020/10/11(日) 12:26:01.00ID:j5pFI3Yh
あ、あと文字の幅も知りたい
2020/10/11(日) 12:27:09.66ID:j5pFI3Yh
Aに対応する小文字がaなら
あに対応するカタカナはアという情報があっても
良いと思うのだがあるのか？
370デフォルトの名無しさん
垢版 |
2020/10/11(日) 12:33:22.48ID:kZXFoyze
>>369
曾礼多
2020/10/11(日) 12:36:42.03ID:j5pFI3Yh
>>370
嫁無い
2020/10/11(日) 13:23:05.62ID:a5ebPbEF
1，2，3
2020/10/11(日) 13:26:32.41ID:a5ebPbEF
3042;HIRAGANA LETTER A;Lo;0;L;;;;;N;;;;;
30A2;KATAKANA LETTER A;Lo;0;L;;;;;N;;;;;

ないようだ
2020/10/11(日) 18:56:47.77ID:lNYgVXzm
いい加減自分で調べられるだろ... 釣りか
Unicodeの他のデータとかUnicodeに関するAPIとかにある。

そうやって、全世界が「あーUnicodeでいいね」ってなるように
Unicodeの世界戦略は着々と進んでいるのであった。
2020/10/11(日) 20:41:30.45ID:EIUTbwb3
日本語のマップくらいは自分で作ればいいんじゃね？
https://unicode.org/charts/PDF/U1B000.pdf
2020/10/11(日) 21:37:26.96ID:wm510+AL
変体仮名も収録されてるんだな
2020/10/13(火) 00:47:23.21ID:tEy/04zZ
あをアに対応させるのはtransliterationのカテゴリーらしい、Unicode的には。
日本語だと翻字というのかー。
2020/10/13(火) 06:17:14.44ID:RnL4UaYd
漢字の読み方（複数）もUnicodeで定義されるべきではないのかな？
379デフォルトの名無しさん
垢版 |
2020/10/13(火) 09:57:18.23ID:FpFGKRx+
棚
2020/10/13(火) 13:54:08.89ID:8ughZvwQ
Unicode は文字コードであって漢和辞典ではないし、読みとか何の役にも建たないw
2020/10/16(金) 00:51:17.29ID:zvezW4n7
>>361
大文字小文字を区別しない検索を行うためのデータという意味ならこれ
http://www.unicode.org/Public/UNIDATA/CaseFolding.txt

ある文字が大文字または小文字に該当するかを知りたいなら>>364のデータの
3番目のフィールドを見る。Luなら大文字でLlなら小文字
2020/10/20(火) 08:39:00.75ID:iDoXrFT4
rubyを勉強中の超初心者なのですが、時代遅れだ！みたいな記事をちらほら見かえます。
言語変えた方がいいのでしょうか…？
2020/10/20(火) 10:25:40.98ID:xAfCoP/O
なぜ、ここで、その質問を？
文字コード的には変えるほど意味はない気がする。(むしろ ruby が便利)
複数の言語が使えた方が便利なので、色々試すことはおすすめ。
384デフォルトの名無しさん
垢版 |
2020/10/20(火) 10:30:11.60ID:pHiz9StD
Yes, you can.
2020/10/20(火) 16:20:38.97ID:Nlf6zVNG
はい、あなたは管です。
2020/10/24(土) 21:01:49.65ID:ehxRee/D
いいえ、私は管(くだ)です
2020/10/25(日) 01:00:40.73ID:+b3TKvfL
いいえ、私は菅です。
388デフォルトの名無しさん
垢版 |
2020/12/07(月) 15:52:31.12ID:BlHR3DgB
櫻の絵文字🌸がPCやiPhoneだと花びら5枚なのに
Androidだと4枚ω
2020/12/07(月) 16:34:11.79ID:TmqbbT66
>>388
また友達に騙されちゃったんだね…
390デフォルトの名無しさん
垢版 |
2020/12/07(月) 21:30:49.12ID:8FTbf1dJ
utf8でshiftjisで言う
iskanji()
iskanji2()
ishira()
iskata()
みたいなイディオム教えてください
2020/12/08(火) 11:51:17.55ID:3Lge4PBr
>>390
utf8のコードがshiftjisに変換可能かチェックして、可能なら変換したコードに
そのイディオムとやらを使えばいいのでは?
2020/12/08(火) 12:25:05.31ID:no2frcgf
>>391
shiftjisは扱わないのでutf8での方法を教えてください
2020/12/08(火) 17:31:43.20ID:/pT3aml4
>>390
Unicodeプロパティがサポートされているなら
正規表現で\p{Hiragana}とかが使える
サポートされてないなら自分でコードポイントの範囲を調べて頑張る
2020/12/08(火) 18:36:17.22ID:E4wQPgos
長音（ー）とかの扱いがめんどくさい
395デフォルトの名無しさん
垢版 |
2020/12/09(水) 06:33:19.08ID:Hs7wcc9u
ちょっと疑問に思ったのだけど、
utf8 の iskanji を作るとしたら、繁体字とかも含めますか？
それとも今は JISx0213:2004（11233文字） だけ？
それともこれの次の標準化規格になるものってありましたっけ？
396デフォルトの名無しさん
垢版 |
2020/12/09(水) 06:43:54.04ID:Hs7wcc9u
ishankana() みたいなもの、javascript 版
if( /^[ｱｲｳｴｵｶｷｸｹｺｻｼｽｾｿﾀﾁﾂﾃﾄﾅﾆﾇﾈﾉﾊﾋﾌﾍﾎﾏﾐﾑﾒﾓﾔﾕﾖﾗﾘﾙﾚﾛﾜｦﾝｧｨｩｪｫｬｭｮｯ､｡ｰ｢｣ﾞﾟ･]/.test('ｱ') )
{
console.log( '半角カタカナです');
}
2020/12/09(水) 07:34:03.35ID:qbXHpF4v
そのiskanjiとやらであなたが何を判定したいか次第だと思うんだけど・・
サロゲートペアの漢字とかも気にしなきゃだめだろうねえ
2020/12/09(水) 08:14:17.98ID:TKgHvdMy
>>396
半角カナは後ろの方の文字コードでかたまってるから簡単じゃろ。

漢字とか結構カオスでテーブル作ったほうが良さそうだね。
必要文字コード列挙してバイナリサーチするアルゴリズムがええのかな？

厳格でなくていいなら半角カナみたいに文字コードテーブルみて
ざっくり判定でも割と行けるとは思うけど。
399デフォルトの名無しさん
垢版 |
2020/12/09(水) 09:06:33.04ID:Hs7wcc9u
そういえば前に、amazon kindle端末用の電子書籍データ云々でここに書きこんだ記憶が、
と思い当って見直してみたら２か月前でした・・・、

私の方は KDP の仕様にあってるかどうかをチェックするのが目的だったのですが、
確かにカオスでしたね。ちなみに半角カナのコードを出しておいてあれなのですが、
JISx0213 規格的には半角カナは含まれてないっぽいです（x0208も同様です）。
チェック用のプログラムは結局普通の配列に規格の文字を全部入れておいて、
そこにあれば OK なければ NG という感じになりました。
サロゲートペアの扱いも面倒だったし。

あ、今気づいたけれど、JISx0213 的には全角英数記号ってもしかして NG なのでは？
いやでも wiki のページでは SJISコードは全角になってるし・・・、
400デフォルトの名無しさん
垢版 |
2020/12/09(水) 09:18:54.21ID:bCzZQrOf
ライブラリ内ではユニコードスカラー値についてのみ取り扱うと良いと思います。
2020/12/09(水) 13:23:38.64ID:y7KEYUhD
Ruby の古いNKF を使うと、片仮名・平仮名の変換もできるけど、
片仮名・平仮名を判定するメソッドはない

たぶん、NKF の内部では、そういう関数があるのだろけど、公開されていないのかも

module NKF
https://docs.ruby-lang.org/ja/latest/class/NKF.html

require 'nkf'

p NKF.nkf( '-m0 -h3 -w', 'あイ' )
#=> "アい"
2020/12/09(水) 13:25:03.81ID:rIU0lDlE
オプションそのまま文字列で渡すとか
ダッセェインターフェースだな
手抜きにも程がある
403401
垢版 |
2020/12/09(水) 14:41:10.37ID:y7KEYUhD
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.98ID:tBDPYy0r
>>402
tcl/tk
2020/12/09(水) 16:19:55.89ID:H89RJ3R9
こゝろ
406401
垢版 |
2020/12/09(水) 17:51:11.38ID:y7KEYUhD
>>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

出力
平仮名 : あ
平仮名 : い
漢字 : 善
漢字 : 悪
カタカナ : カ
カタカナ : キ
漢字 : 愛
平仮名 : う
カタカナ : ク
2020/12/09(水) 18:21:03.27ID:L/x3uoyo
C++かC#でお願いします
408401
垢版 |
2020/12/09(水) 18:56:51.76ID:y7KEYUhD
鬼雲を、C++, C# など、他言語から使えないのか？
2020/12/09(水) 19:27:16.18ID:jODQKuwy
高性能高速ライブラリがあるのに、
なぜわざわざ、
低性能低速言語Rubyの、
低性能低速libraryを使う必要が、
あるんだ？、
2020/12/09(水) 19:45:05.56ID:ZEWfqGU4
C/C++は生産性が低いから
411401
垢版 |
2020/12/09(水) 19:59:27.39ID:y7KEYUhD
鬼雲は、C じゃないの？

https://github.com/k-takata/Onigmo
2020/12/10(木) 07:33:03.31ID:KWX3PjQ+
>>406
ruby を全然しらんのだが、 each_char ってのはどういう単位で文字を切り出してくるの?
上であったがサロゲートとか、絵文字とか、そのあたり特に。

Hanというプロパティは日本に限らず中国や韓国のも全部入り?
2020/12/10(木) 08:02:18.65ID:oexX+ZIk
>>407
グダグダいってるうちにスクラッチで車輪の再発明実装が終わる頃だな。
iskanjiはテーブル使うしかないかね？JISコードに変換して昔ながらの判定
するにもJISコード変換にテーブル
使うことになるだろうし。
どこかのページに色分けして中国専用の漢字の混ざり具合見せてたけどエグいねｗ
414デフォルトの名無しさん
垢版 |
2020/12/10(木) 10:34:51.08ID:RjOF8qIo
謎のタイ語判定コード , 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/

サロゲートペアを考慮しなくて良い言語はこのパターンでオーケーかな？
415401
垢版 |
2020/12/10(木) 12:43:53.30ID:HstTQkWC
>>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
416401
垢版 |
2020/12/10(木) 12:51:25.91ID:HstTQkWC
>>412
Han の範囲が気になるなら

>>411
の鬼雲のサイトか

>>406
の、str = 'Aあい善悪カキ愛うクx'
に、調べたい文字列を書いて、paiza などで実行してみれば？
2020/12/10(木) 20:31:09.89ID:CcbWokCZ
>>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
2020/12/10(木) 20:34:43.12ID:CcbWokCZ
あ、出力が微妙に違うかも。5chブラウザにペーストしたせいかも。
あともしかしてスキントーンはあえて別キャラ扱いとか?
2020/12/10(木) 21:25:24.00ID:YXjbRyJb
オレオレ用語UZEEE!!
2020/12/11(金) 06:34:28.41ID:5L91jtkU
ん、何か変なこと書いてある?

しかし書き込む瞬間、絵文字が5chブラウザでちゃんと表示できるかちょっと不安に
なったが、一応いけるみたいね。少なくともオレオレ環境では。
5ch側はSJIS＋数値参照を流しているだけかもしれんが。
421デフォルトの名無しさん
垢版 |
2020/12/14(月) 05:58:38.59ID:uAdA9GXf
機械学習関係とかで使う奴です。
なんとなく出来たので晒しときますね。

// 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";
}
2020/12/14(月) 09:18:41.31ID:dIR87NiF
0x31F0-F9のアイヌ語カナ拡張が抜けてるような
423デフォルトの名無しさん
垢版 |
2020/12/14(月) 12:36:10.35ID:uAdA9GXf
>>422
どんな文字か全く見てませんけど、コードが分かれば並べていくだけですね。
アイヌ語カナ拡張版？差し替え用ってことで。

"/^[\x{3099}-\x{309C}\x{30A0}-ヾ\x{31F0}-\x{31F9}]+$/u"
2020/12/15(火) 07:45:42.06ID:mpgmHFbH
Flag for Tokyo て何だよ

https://emojipedia.org/flag-for-tokyo-jp13/
2020/12/15(火) 12:56:15.02ID:vE8VpXlG
日本＋都道府県番号?
2020/12/15(火) 13:41:07.26ID:OZzZpMYk
>>424
市役所とか行ったことないのか？
2020/12/15(火) 17:27:11.75ID:+Yh7x7Wy
ISO 3166-2:JP
2020/12/15(火) 18:17:13.23ID:Y7kqruGs
問題は東京みたいに旗が2種類あるところ

東京は歴史ある＊みたいなほうになるのか銀杏の葉っぱみたいなほうになるのか
2020/12/22(火) 20:48:11.38ID:hjkCLTVe
ISO - ISO/IEC 10646:2020 - Information technology — Universal coded character set (UCS)
https://www.iso.org/standard/76835.html

2020年の内に完成した模様
ABSTRACTのとこが何か文字化けしてるけど。
2020/12/23(水) 00:48:02.18ID:r3ldn4Uo
何に時間がかかるの
2020/12/23(水) 14:15:22.80ID:dwGREUpD
ここでも行けるかな？ 𝐁𝐨𝐥𝐝 𝐼𝑡𝑎𝑖𝑐 𝒮𝒸𝓇𝒾𝓅𝓉 𝔻𝕠𝕦𝕓𝕝𝕖 𝖲𝖺𝗇𝗌𝖾𝗋𝗂𝖿 𝙼𝚘𝚗𝚘𝚂𝚙𝚊𝚜𝚞
2020/12/23(水) 16:04:04.77ID:Yot4/iGO
��������������������
2020/12/23(水) 18:21:51.29ID:dwGREUpD
コード表一列読み間違えて16ズレた。
何かローマ字みたいになってるけど偶然。
2020/12/23(水) 20:48:10.24ID:nit2qqbj
SNSのアカウント名でこういう文字使ってる人いるよねえ
特に詳しそうには見えない人が多いが簡単入力できるツールかサイトがあるんだろうかね
2020/12/24(木) 08:15:43.26ID:EahE3vDH
テスト
🅿🅴🅽 🅿🅸🅽🅴🅰🅿🅿🅻🅴 🅰🅿🅿🅻🅴 🅿🅴🅽
2020/12/24(木) 13:14:04.00ID:Tf2UBq9W
���������� ℤ
437デフォルトの名無しさん
垢版 |
2020/12/24(木) 14:37:35.38ID:LJDzLTFM
何だろう? 専ブラだと全部読めるけど Firefox だと読めたり読めなかったりする。
431 と 435 は Firefox でも読める。432は読めない。436 は Z だけ読める。
🄟⒜⒭⒠⒩⒯⒣⒠⒮⒤⒵⒠⒟
Ⓒⓘⓡⓒⓛⓔⓓ
🅂🅀🅄🄰🅁🄴🄳
🅝🅔🅖🅐🅣🅘🅥🅔 🅒🅘🅡🅒🅛🅔🅓
🅽🅴🆃🅰🅶🅸🆅🅴 🆂🆀🆄🅰🆁🅴🅳
2020/12/24(木) 14:50:54.98ID:LJDzLTFM
わかったサロゲートが原因だな。
BMP 以外の文字を ＆＃XXXXX; 形式で投げる時に、なぜかサロゲート分解して2文字にして投げてるクライアントがいるな。
内部でいったん UTF-16 に変換すれば復元できるけど、内部がUTF32やUTF8だと未定文字になる。
2020/12/25(金) 12:51:47.65ID:qJluI3Ne
同じ専ブラでも端末が変わると読めなくなるみたいだけど
2020/12/25(金) 14:23:41.08ID:wLkIv5a0
そりゃフォントが違うから
2020/12/25(金) 21:14:44.85ID:xu2VH6Eq
フォントに？
442デフォルトの名無しさん
垢版 |
2020/12/31(木) 06:07:50.70ID:YZyBnRB+
㍾ → ㍽ → ㍼ → ㍻ のパターンでさりげなく令和が増えていて驚いた。

㋿ U+32ff
2020/12/31(木) 06:20:27.61ID:rUTWKsHs
あれほど騒ぎになったのに今更かよｗ
444デフォルトの名無しさん
垢版 |
2020/12/31(木) 06:48:08.64ID:YZyBnRB+
>>443
いや、正確に言うと、自分の使ってるPCでその㋿が表示されることに驚いたのね。
買った直後だけアプデしてその後ずっとアプデしないようにしてたから。
アプデしてないアイポン６で表示されてないのを見てちょっと安心しました。
445デフォルトの名無しさん
垢版 |
2020/12/31(木) 06:51:45.99ID:YZyBnRB+
丸付きにも四角付きにも 音・訓・外 が無くて悲しい。
ということで以下は、ブラウザやアイポンでの表示チェックです。

音：㋔ Ⓒ㋾ⓞ
訓：㋗ Ⓙⓙ🅹🄹ⓝ
外：▲ ⓖⒼ
中：㊥ 厨Ⓒ

訓読みは Ⓚ という文字を使いたいくないので 字訓を元にしたⒿとか 大和言葉（和語）を基にする方がいいなぁ。
音読みは中国由来のⒸの方が㋔よりもいいかもしれない。
外字は小中学生や外人さんにはあまり使わない文字なので▲で良いと思う。
丸付きの ガ があればそれで決まりだったんだけどいろいろ揃って無いよなぁ。

で、辞書で出てくる 中 ってなんの意味か知ってる人が居たら教えてください。
なんとなく中国史で使うっていうような意味っぽいけど。あるいは中学で覚えるとか？
446デフォルトの名無しさん
垢版 |
2020/12/31(木) 07:36:55.69ID:YZyBnRB+
>>445
自己レスです。
中は中学で学習する音訓と漢字ペディアに出てました。
ちなみに高というのもあって高校で習うそうです。
2020/12/31(木) 20:58:20.96ID:DjLZ71J5
サロゲートペアは本当に厄介者
2020/12/31(木) 21:04:25.88ID:2bA0HVQw
結合文字「サロゲートペア程度にやられてるのか？」
異体字セレクタ「奴はUnicode四天王の中でも最弱」
？？？？「サロゲートペアごときに負けるとはプログラマの面汚しよ…」
2020/12/31(木) 23:29:53.71ID:AP5qdpgj
混沌を極めるUNICODE界…
もう一回いちから(別案で)やり直す可能性ってあるのかな
2021/01/01(金) 02:12:50.76ID:YAS452Oz
ないよ
というか仕切り直したところで今のUnicodeは内包されるに決まってるからメリットがないよ
2021/01/01(金) 08:19:29.86ID:u/6kYyhd
BMPに還るのがいい
452デフォルトの名無しさん
垢版 |
2021/01/01(金) 22:27:30.90ID:rsUPFffA
あけましておめでとうございます
Unicode 14.0.0の発表が9月に延期になって寂しい
2021/01/02(土) 00:20:21.99ID:3z5SV0Cg
有名所の13対応のフリーのフォントてもう出てましたっけ?
454デフォルトの名無しさん
垢版 |
2021/01/02(土) 09:08:13.69ID:peE3gLXE
あけおめ。

サロゲートペア対応の漢字のみ収集コード JavaScript版、
𪗱𪘂𪘚 の３つがサロゲートペアかな？ 読めなくてアレですが。
お隣の文字はちゃんと省いてる、使えば大願成就間違いなしの縁起物？バージョンです
絵文字も省いていたような気がするけどなんかいろいろ忘れてますね。

re = "abcd齆あ齓齕齘ab𪗱齝𪘂齩𪘚々齭てすと".match(/([\uD840-\uD869][\uDC00-\uDFFF]|[々〇\u303B\u3400-\u9FFF\uF900-\uFAFF])+/g);
console.log( re );
2021/01/02(土) 16:52:42.20ID:c+PMhAgd
>>450
まじかー
もう128bitくらい使って宇宙文字にも耐えられるようにすればいいのに
これが本当の異星体なんつって
456デフォルトの名無しさん
垢版 |
2021/01/02(土) 21:50:17.89ID:NzxSghB6
GUIライブラリTkはいまだにサロゲートペアに対応しておらず絵文字を使えない。
2021/01/03(日) 14:22:31.22ID:uzdBwonC
ここもunicode=changeな板が多すぎてな
このオプション消滅せんかな
458デフォルトの名無しさん
垢版 |
2021/01/05(火) 12:09:35.45ID:G8BimKKu
5chもほぼSJIS専用やんけ
2021/01/05(火) 18:11:40.31ID:F/xhjvIl
>>458
なんだかんだSJISのままで存続できてるよね。
文字参照が使えればベースのエンコーディングは案外何でもいいのかな、
とか思ったり思わなかったり。
2021/01/05(火) 21:01:08.07ID:Xkz87/Po
たまにスレタイで絵文字入ってるのあるけど
あれも文字参照で入力してるのかな
2021/01/05(火) 21:11:16.54ID:TUUmcJJM
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.
https://twitter.com/5chan_nel (5ch newer account)
2021/01/05(火) 21:12:01.50ID:TUUmcJJM
https://pbs.twimg.com/media/EqQuVm0W4AAAxfv.png
463デフォルトの名無しさん
垢版 |
2021/01/06(水) 09:23:40.34ID:nouQm06h
絵文字テスト 　　（↓の＆と￥は全角）
Growing star 🌟 , ＆#x1f31f; , ＆#127775; , ￥u{1f31f}

SJIS環境だとサロゲートペアはエラーになるんじゃね？
ウニコードベースのエディタへの移行に失敗というか断念して
未だにSJISベースのテキストエディタをメインに使ってる俺が言ってみたり。

そう言えばサクラエディタのマクロフルセット？サポート版てどこでダウンロードするのが良いのだろう？
2021/01/06(水) 18:53:39.44ID:BIuq+YWk
あ、Chromeって検索のとき全角半角を区別しないのか。今知ったw
っていうかそもそも大文字小文字も区別しないのか。へー。
でもこの手の正規化を無効にするオプションもないようだしちょっと不便。
2021/01/06(水) 19:42:47.04ID:evtp6HPL
chromeの検索の同一視はなんか怪しいというか独自テーブルかな
2021/01/07(木) 00:30:30.04ID:RA5aGs7i
最近は知らないが昔のFirefoxは全角半角同一視してくれなくて大変困った
2021/01/07(木) 01:59:00.08ID:HEGtY6UH
>>459
海外からの荒らし対策になっているのでは
SJISは国内だけの希少コード
2021/01/07(木) 02:00:13.67ID:o03LMIA7
>>466
今でもFirefoxは全角半角を無視「しない」ように見えるけど?
いつだかダイアクリティカルを無視するというので問題になったけど。
2021/01/10(日) 18:48:17.35ID:akopncMr
>>449
別に一から作り直せとは言わんけど明らかにミス、バグだろって箇所は直してくれ
有名なのだと U+29FCE と U+29FD7 とか
2021/01/10(日) 20:04:42.25ID:/+cMzhpZ
やるとしてJSoueceの方をobsoleteされるんだろw
2021/01/20(水) 22:49:15.22ID:Eoi5GIMM
テキストエディターが改行コードを間違って解釈しないように
BOMの機能を拡張して改行コードの種類も表せるようにしたらどうなんだろう
2021/01/21(木) 00:18:54.31ID:Nk7WM/aM
来月からUnicode 14に向けた準備が始まるそうだけど
WG2側でまったく投票が出来ていない状態でそんなことして大丈夫なのか
2021/01/21(木) 12:01:56.27ID:uTJ86sk/
改行コード間違うのってたいてい改行コードが混在してるのが原因じゃないの？
474342
垢版 |
2021/01/21(木) 17:12:51.59ID:zM0oz2u8
>>471
一行目の改行コードで充分では？
2021/01/22(金) 23:50:53.67ID:SkpJ9szj
eメールは8bitの文字を7bitに変換して送るのが一般的だけど
今でも7bitしか扱えないメールサーバーってあるんだろうか
2021/01/25(月) 20:49:52.31ID:r2WhSNc4
前に件名を=?ISO-2022-JP?B?の形式でエンコードせずに直接ShiftJISを書きこみ
本文もMIMEを使わずにShiftJISをそのまま書いたメールを送ってみたが文字化けもせずに届いたから
7bitまでしか送れないのは昔の話なんじゃないかと
2021/01/25(月) 20:59:52.42ID:nPU6SWGR
8bitを化けさせるようなメールサーバーが今でも存在するのかという質問であって、お前の化けなかった経験は何の解答にもなってない。
2021/01/25(月) 22:50:52.28ID:dmbNtT1m
そりゃあ、存在しないという解答は解答にならなくて存在しているという解答だけが解答になるわけだ。
2021/01/26(火) 00:14:38.98ID:c6DHU6bT
現れないのが透明人間です
みたいな話
2021/01/29(金) 22:30:48.89ID:SgmI7msw
規格上はオプションではあるがSMTP POP3 IMAP4全てでUTF-8をそのまま送受信できるから
8bitデータをそのまま送受信できるならBase64やquoted-printableも必要なくなるのかな
2021/01/30(土) 00:20:35.73ID:nT2XTKgy
>>480
一部の構造化されたヘッダは8ビット禁止なので、全部はなくせないかな。
2021/01/30(土) 01:48:16.96ID:i+4/kULN
先賢の方々が何処かの頃合いで8bitクリーンに作り直しておいてくれればなぁ
2021/01/30(土) 04:51:50.38ID:yJsdZMSi
問題になるのはTAB,SP,BS,ESC,DELとかの制御コードなのでBase64等は必須でしょうね
行頭の'.'も気にしなくて良くなる
2021/02/01(月) 15:56:04.61ID:2wWFCs7L
どうしてメールは7bitが基本になったんだろうね
少しでもデータ量を減らすためなのか
8bit目をパリティとして使う機種の名残りなのか
2021/02/01(月) 19:54:24.08ID:daMBxrCa
もともとインターネットでメールがやり取りされるようになる以前から
学内ネット、社内ネット、UUCPネットワークなどの個別メール網があって、
それをインターネットで相互接続したのが始まりなので、
最小公倍数的に全てを通過できる7ビットが要件になった。
2021/02/01(月) 19:58:08.39ID:B8SI3YQR
SMTPが出来たは40年ちかく昔だからなあ
Unicodeなんてまだ影も形もない時代
日本人ですら漢字をシフトしない7bitで表現してたくらいなのに
メールだけわざわざ8bitを基本にするような発想が出てくるわけがないだろう
2021/02/01(月) 21:54:37.95ID:A78/KaWg
コマンド以外は全て8bitのバイナリデータとして扱ってエンコードしないで
相手にそのまま送れるのが理想的なんだろうね
シェアの大きいMTA/MUAがRFCを無視してそんな実装にしたら
意外とそれがデファクトスタンダードになったりするかもしれない
2021/02/01(月) 22:00:08.44ID:o0ZguV06
>>484
>8bit目をパリティとして使う
でしょうね、欧米はそれで足りるから
2021/02/02(火) 00:59:48.46ID:ecf2UzG0
binarymimeって使われてないの？
2021/02/02(火) 13:36:00.69ID:8YNA1BPy
>>486
>日本人ですら漢字をシフトしない7bitで表現してたくらいなのに
シフトするJISはあったでしょ
2021/02/03(水) 21:38:48.49ID:nNuCDyZ2
記号以外のASCII文字はエンコード後も変化しないという意味でUTF-8を7bitにエンコードするなら
quoted printableがbase64より合っていると思うんだけど
メールでのUTF-8の普及に合わせてquoted printableも普及しないかな
2021/02/03(水) 22:02:22.02ID:PgvsD/XS
そういえばUTF7なんてのもあったね
どこで使ってたんだろう？と思ってググったらIMAP4とかだと2010年前後でも当たり前に使われていたらしい
メールはかなり最近まで（今も？）7bitを大事にする文化みたいだね
2021/02/03(水) 22:21:53.66ID:WEk0ntun
本当はもう無いのに「読めないぞ」というクレームが怖くて残ってるんじゃ。
残ってても、そもそもそんなところに8bitのメールは送られないような。
2021/02/04(木) 01:36:54.71ID:JoFJnM0w
今現在のメールの良さって汎用性・後方互換性に尽きるからなあ
2021/02/04(木) 18:23:08.62ID:ez+Z5Z3J
https://www.janog.gr.jp/meeting/janog31/resume/janog31-i18nmail-fujiwara-01.pdf#page=10
この形式でメールを送れるメールソフトがどのくらいあるのか分からないけど
今はこの形式でメールを送って、問題が出たら従来の形式で送るというくらいでもいいんじゃないの
2021/02/08(月) 21:58:11.42ID:dRtPTDkz
UTF-16がunicodeをややこしくさせる原因になってるよね
unicodeのコードポイントがU+7FFFFFFFからU+10FFFFまでに制限されたのも
サロゲートペアも考慮しないといけない所もUTF-16のせいなんだし
2021/02/12(金) 05:28:51.22ID:iQJLsSxS
麻雀牌が全部登録されたのに🀄だけ先行だから見た目が違うのどうにかならんのか…
2021/02/12(金) 08:42:44.00ID:9pKWi6uS
フォント次第だろ
2021/02/12(金) 08:54:47.22ID:nGt16DhZ
>>498
大抵のフォントでも🀄だけは違うよ
2021/02/12(金) 14:05:54.17ID:dwh87PNV
Ninja Catは新たな機種依存文字といえるだろうか
2021/02/12(金) 16:22:53.75ID:Dgq2mig/
>>496
というかそれはUnicodeの歴史とむすびついてるわけだし。
当初16ビットでということでWindowsやMacがそれを採用、しかしリリース後に16ビット
では足りないことが判明。もうその時点ではサロゲートペア的なものでどうにかする
のは仕方ないかも。

というわけでややこしいのはUnicodeそのものw
2021/02/12(金) 23:39:41.89ID:2MB5qean
♡
💙
2021/02/12(金) 23:59:30.90ID:dwh87PNV
16ビットで足りない事が判明した時点でUTF-32に移行できればよかったんだけど
未だにUTF-32に対応したソフトは少ないんだよね
504デフォルトの名無しさん
垢版 |
2021/02/13(土) 06:00:35.89ID:neaggcXJ
理論上は、UTF-32でも足りない。無限に増えるユニコード表に対応するには、UTF-32にもサロゲートが必要。
2021/02/13(土) 06:02:18.96ID:xr59QL32
歯磨き粉買ってくる
2021/02/13(土) 09:04:37.07ID:+Dfn0XQq
無限に増える理屈を詳しく
2021/02/13(土) 10:43:02.72ID:Xo6k9nK0
宇宙文明
508デフォルトの名無しさん
垢版 |
2021/02/13(土) 11:01:30.65ID:neaggcXJ
ぼくのかんがえたさいきょうの文字が追加されても耐えられる仕様でなければならぬ。
よしんば絵文字の可能性は無限。
509デフォルトの名無しさん
垢版 |
2021/02/14(日) 11:44:24.49ID:PGTjJwEI
🐼🐼🍞🍞🐼🍞🐼
2021/02/14(日) 23:59:32.09ID:u9kxNS7O
>>497-499
同じ種類の文字なのに一部だけ先行して登録されて
他の文字は後から全く違うポイントに登録されている物もあるから
フォントだけで済んでるならまだマシじゃないかと
2021/02/15(月) 03:09:13.69ID:N3rul/OC
>>510
いや🀄だけ違うのはちょっとモヤるんだよなぁ
unicodeに送ろうと思ったら有料会員じゃないとだめだったorz
2021/02/15(月) 16:03:14.56ID:0+vI5H2L
unicode に送っても仕方ないやろ
フォントメーカーに送れ。
内蔵フォントなら機器メーカーに送れ。
2021/02/15(月) 16:39:10.57ID:G46IYPHn
何送り付けるつもりなの
2021/02/15(月) 17:18:57.69ID:ugNMmOOo
ヷヸヹヺセ゚ツ゚ト゚の合字ではない平仮名は無いんだよな
「ゔ」を入れたのなら他の文字も平仮名版を入れればいいのに
2021/02/15(月) 20:05:59.00ID:/z22KH1R
ユニコードはウィルスなので送らないでください。
2021/02/16(火) 08:25:02.10ID:mevxUua1
>>512
Unicodeで決まってるんじゃなくて？
2021/02/16(火) 09:08:45.11ID:3D5+Vdqo
>>516
図柄を決めてるのはフォント屋。
Unicode的にはコードポイントが離れてても同じような図柄にすることを想定してるけど、フォントがそうなってないだけ。
2021/02/16(火) 16:32:28.02ID:maqlUdeY
文字のバイト数が可変長のコードを作れば、弱い暗号に使えないのかな
１，２，３，４バイト不規則に混在、たまに７バイトや１０バイトも混ざる
2021/02/16(火) 17:46:12.13ID:X0P7Oy5W
もしかしてutf-8？
2021/02/16(火) 20:48:18.23ID:qlfoq285
>>496
UTF-8の4バイトに合わせてU+1FFFFFまでにしてくれればよかったのにとはちょっと思った。
2021/02/16(火) 21:51:25.16ID:ABVOYRZa
可変長の究極は1文字ごとに
文字の切れ目を表すためのエスケープ文字とunicodeの登録名（HIRAGANA LETTER Aなど）
をテキストファイルに記録する事かもね。
コードポイントの概念を無くして16進数の番号で管理しないから
後から追加された文字でもコードポイントが飛んでいる事はなくなるし。
ただし文字によっては1文字に50バイト以上使うこともある。
2021/02/16(火) 23:05:15.94ID:ZcpmZlC/
>496
Unicodeの当初の16bit（最大65536文字）あれば
十分だろうという考えがそもそもの原因なんだから
UnicodeをややこしくさせてるのはUnicode自身だよ

最初の段階で16bitで足りないと認めていれば
今頃はUTF-32が主流になっていただろう
もっともUnixは互換性のためにUTF-32をネイティブで扱うのが
難しいのでUTF-8は生まれていたかもしれないがね
2021/02/17(水) 01:57:41.63ID:1VpGhFke
枻（木へんに世）って、シフトJIS（のバリエーション）的にはどうなんだっけ。
というかこれ自体もテストだったり。
2021/02/17(水) 02:17:54.79ID:1VpGhFke
ちなみに自分はMacなんだが、0xFAE2を書き込んだ模様。
皆さんには見えてますでしょうか。
HTMLでcharset=Shift_JISのときってどうするのか揉めた記憶が。
2021/02/17(水) 02:44:16.94ID:PIB5BTik
５ちゃんねるの仕様は文字コードと何の関係もない
2021/02/17(水) 03:22:07.19ID:edB0ww9C
っ https://encoding.spec.whatwg.org/shift_jis.html
今のブラウザはこの辺に従ってるで終了じゃねの?
2021/02/17(水) 08:12:07.90ID:peDNmUYI
>>525
5chをブラウザで見るとHTMLがcharset=Shift_JISなんだけど、それは関係ないってこと?

そもそもテキストデータのやり取りで文字コードの指定がない仕様というのは... もしかして
適当にデータを送受信して適当な文字コードを指定して見れたらラッキー、的な仕様?

そもそも5chの仕様ってどこかにあるんでしょうか。
2021/02/17(水) 09:42:15.24ID:ty0uudwM
やれやれ頭が固いなｗ
SJISでUnicodeが表示できないと思いこんでる
529デフォルトの名無しさん
垢版 |
2021/02/17(水) 18:28:41.76ID:8Df3qLX7
もりおうがいしかる
森鷗外𠮟る
森鴎外叱る
2021/02/17(水) 19:54:41.88ID:NZXazeNu
森鳩ﾀﾄﾛﾋる
2021/02/17(水) 20:00:49.86ID:SpPvhnPe
>>521
そこまで行くと文字コードというか最早マーク付け言語みたいだな
てかHTML (SGML/XML)の文字実体参照まんまでは
2021/02/17(水) 22:24:44.47ID:gjncEnw2
sjis には、Windows CP932 特有の環境依存文字がある

それで、バグルか、フォントが無いとか
2021/02/18(木) 00:08:48.51ID:QtoO1FYc
>>523-524
世に出てるブラウザの殆どはcharset=Shift_JISな文書をWindows-31Jとして解釈するだろうから
IBM拡張文字として表示されるんでない？
というか、何を疑問に感じてのレスなのかが分からないんだけど。
534デフォルトの名無しさん
垢版 |
2021/02/18(木) 10:20:55.82ID:64/LOwh9
不知佛
2021/02/18(木) 16:35:44.79ID:SMktdrdB
>>533
>charset=Shift_JISな文書をWindows-31Jとして解釈するだろうから

まさにそこ。本来はこの両者は違うから、正しく解釈すれば文字化けする。
しかし事情を知らないユーザーから見たら、文字化けするソフトウェアの方が劣ると
思われそうで悔しいw

そもそもShit_JISとWindows-31Jをごちゃ混ぜにして大量に垂れ流したWindowsのプラット
フォームないしユーザーに責任があると言えるが、それに迎合しないといけないのがw
2021/02/18(木) 17:36:53.61ID:qR1rH4Mn
>>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.01ID:64/LOwh9
Tower of Babel
2021/02/18(木) 18:54:47.31ID:YbNTmpmE
C言語の/r/nなどのエスケープシーケンスは制御文字に対するアルファベットの割り当てを
キャレット記法と同じにした方がよかったんじゃないかと思う
2021/02/18(木) 20:15:29.49ID:qR1rH4Mn
キャレットって^Cの^（CTRLという意味）のこと？
2021/02/18(木) 22:08:13.73ID:UlBwu06v
Ruby は、数十種類もの日本語の方言を変換できる。
方言同士の変換パスを作っている

最大6パスで変換できる方言もあるらしい

でも、今でも、NEC・ドコモ方言などを使うかどうか疑問
2021/02/18(木) 22:29:52.06ID:YbNTmpmE
>>539
例えばCRLFなら^M^JだからC言語でも\r\nではなく\m\jの方がよかったんじゃないかと
2021/02/18(木) 23:13:37.69ID:oLKP0iIM
あらゆる文字コードでCR=0x0D,LF=0x0Aだと本当に保証されているのか？
を考えてみれば答えが出るんじゃないかと
2021/02/19(金) 10:43:19.20ID:KukrgKGP
>>536
うむー確かに各ベンダーのせいはあるか。
しかし、このSJISの混乱があったにも関わらず、ガラケーでは各ベンダーが勝手な絵文字の
コードを割り当ててえらいことになりかけてたよね。
で今度はGoogleが中心になって事態を収拾した。
歴史は繰り返すってか。あるいは日本企業の変わらない体質?
544デフォルトの名無しさん
垢版 |
2021/02/19(金) 11:24:24.47ID:hDaaUxwq
最近はもうこんな感じのコードを必ず最初に入れるようにしてるなぁ。
$Text = preg_replace("/(\r\n|\r|\n)/" , "\n" , $Text );
2021/02/19(金) 21:20:37.86ID:B4GlCKY0
絵文字はユーザーの利便性に直結する、最も重要な要素

絵文字でシェアが変わるから、他社よりも先に、魅力的な絵文字を作らないといけない。
Line は、絵文字・スタンプでシェアを不動のものにした
2021/02/19(金) 23:58:34.63ID:vxkxW4Vf
\nだとLFを指している場合と
CR単独、CRLF、LF単独に関係なく改行を指している場合の両方があって
ソフトによって違うから困る
前者と後者を区別できるようにしてほしいね
547デフォルトの名無しさん
垢版 |
2021/02/20(土) 14:22:35.85ID:MwzRkHxH
米アップル、注射器の絵文字を微調整　「血のしずく」を削除
https://www.cnn.co.jp/tech/35166607.html
2021/02/20(土) 16:11:25.88ID:McCqWkok
あきらめないで
2021/02/20(土) 20:02:11.54ID:Rkd/h2tQ
>>545
じゃあLineはどうしてるの、という疑問が。

探してみるととりあえず... https://developers.line.biz/media/messaging-api/emoji-list.pdf
これに関してはUnicodeの私用領域を使ってるみたいね。

確か絵文字が表示されないときに (laugh) みたいにちゃんと置き換わるやつがあった気が
するが... あれはHTML的なもの（か、そのもの）なのかな。
550デフォルトの名無しさん
垢版 |
2021/02/20(土) 23:07:01.67ID:reEV5cwz
調べてみると点字にも文字コードと同じ問題があるんだな
6bitだから仮名と数字とアルファベットを全て1文字で表せないから
数字とアルファベットはエスケープ文字を付けて対応しているし
漢点字だと8bitで可変長になっている
2021/02/21(日) 02:25:03.18ID:SyjwfUNV
>>550
そういえばUnicode上の点字はなぜか8個の点で例示してあり、実際256パターンある。
点字のUnucode化? 8bitで十分かは知らんけどw
でも8個以上は指で触って読むのが難しいかもしれない。
2021/02/21(日) 05:02:36.24ID:x7XX42Aa
>>546
\n は、LF だけど、

Python みたいに、global new line を設定すると、
CR単独・CRLF・LF単独と、OS によって改行コードを切り替える、言語がある
2021/02/21(日) 05:15:52.00ID:kbkbRMiR
>>552
テキストモードって知らんのか？
どのOSでも持ってる機能だぞ
554デフォルトの名無しさん
垢版 |
2021/02/21(日) 05:33:13.41ID:0HHdBuLy
テキストモードという概念はOSというよりプログラミング言語じゃないかな。
2021/02/21(日) 09:02:39.59ID:3Ebck9FU
>>553
テキストモード（正式にはクックドモードcooked mode／ローモード raw mode）は Micro Soft 社限定のような気が
2021/02/21(日) 14:27:37.46ID:GfLXclnP
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.
2021/02/21(日) 16:39:18.84ID:3Ebck9FU
>>556
thx
2021/02/21(日) 20:28:19.64ID:x7XX42Aa
たぶん、ascii・テキスト伝送は、Microsoft の規格だろ

基本、データはバイナリしかない。
バイナリを送っているだけ

それを、バイナリかテキストなのか、2種類に分けた

データベースと同じ。
バイナリしかないのに、各列を、バイナリ・テキスト・数値などに分類してる
2021/02/22(月) 03:41:51.59ID:g4xweyOw
Unix の raw-mode とういのはバイナリとかASCII とかじゃくて入力されたキーボードの文字を生のまま受け取るモード。
たとえばリターンキーを押すと 0x0D がバックスペースを押すと 0x08 がバイト単位でそのまま渡される。実際のコードは端末次第。
cooked-mode というのは端末の設定に従って行単位でバッファしながら入力を加工するモード。
端末設定で「改行文字入力」が 0x0D に設定されていて、キーボードから 0x0D が入力されたら
改行の入力とみなしてunixの内部的な改行 0x0A に変換して、それまでのバッファを渡す。
端末設定で「前の一文字削除」が 0x08 に設定されていて、キーボードから 0x08 がきたらバッファー内の最後の一文字を削除する。
Ctrl-C で割り込み中断とかも cooked の機能。
2021/02/22(月) 17:39:30.14ID:bGamQ1pv
>>533
>世に出てるブラウザの殆どはcharset=Shift_JISな文書をWindows-31Jとして解釈するだろうから

ちなiOSのSafariはそうじゃないっぽい。macOSの方はそうなんだが。

とりあえずiPhone買って、付いてきたSafariでウェブを見る、みたいなユーザーは多いんじゃない
かと思うんだが.. というわけで「殆ど」という言い方はできないかもしれない。
2021/02/22(月) 20:36:22.30ID:DwYM6h5J
>>551
バイナリコードに親しんでいる人が点字を覚えるなら従来の6点の点字より8点の点字で
そのままバイナリコードを表した方が分かりやすいって人はいるだろうね
昔は穿孔テープの穴を見て何が書いてあるか分かる人は多かったようだし
2021/02/23(火) 03:23:29.15ID:DHJgW+88
後から穴の数が増えたのも出てくるけど、もともとの紙テープは5穴なので10分も練習すれば誰でも読めた。ただし会社ごとに個別に覚える必要があった。

このスレ的に言えば、各社バラバラだった5穴、6穴の規格を統一するために作られた7穴の共通規格が ASCII の始まり。
2021/02/23(火) 08:57:17.31ID:I88lzdP8
もうさ32ドット×32ドットぐらいの点字を作りなよ
そうすりゃかなりの文字を表現できるやろ？
2021/02/23(火) 12:06:09.45ID:waG/I9Zl
32x32でいけると思ったのですが、森羅万象を表現するに全然足りないことが判明したので、サロゲート点字を導入します
2021/02/23(火) 16:52:17.61ID:Z5ZYenTn
有史から遠い未来まで全人類の顔を絵文字として登録できる、という前提で文字コード規格を作らないとダメでしょ。
2021/02/23(火) 18:23:04.03ID:1/jlbQjA
漢字には一画のぞくとか、わざと間違えるとかいう字もあるからなあ
2021/02/24(水) 15:37:09.38ID:N1ZJD0Pr
「信長の野望」の家康画像みたいに元服前の顔、青年期の顔、老年期の顔をそれぞれ登録するようにしたらますます文字コードが増える。
2021/02/24(水) 15:43:59.66ID:aaBs9O4Y
同じ顔は同一の文字コードにすればOK
2021/02/24(水) 16:00:01.95ID:aweY/mLc
>>545
そうなんだ。
ということはSJISのバリエーションに関しても、似たような経緯があったのかな?
「ウチのOSではこんな文字も使えますよ」的な?
2021/02/24(水) 16:13:32.49ID:N1ZJD0Pr
IPv6では宇宙誕生から消滅に至るまでの全宇宙のデバイスにIPアドレスを割り当てることはできない。勝手に最大量を決めてはダメってことだ。
2021/02/24(水) 16:25:49.69ID:aaBs9O4Y
>>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チップ
がそれぞれ別売りされていた
2021/02/24(水) 16:32:05.41ID:aaBs9O4Y
日本人が作る日本人のためのパソコンで
日本で使われている漢字が表示できないのは
マイナスでしかない。だからパソコン屋は
当初のSJISで定義されていた基本的な文字集合を超えた
文字を漢字ROMボードとして提供するしか道はなかった

そしてWindowsの時代となりフォントがOSに搭載されるようになってから
各メーカーが拡張していた漢字を相互運用できなくなるのは困るため
Microsoftは各拡張SJISを統合して改めてCP932として標準化した

もともとSJISを作ったのはMicrosoftなわけで
WindowsのSJISは、初期のSJISの正統後継といえる
2021/02/24(水) 17:13:57.11ID:O/RKRWyd
PC-98シリーズの漢字ROM、テキストVRAMはJISコードベースだ。SJISではない。
2021/02/24(水) 18:38:57.51ID:CaexoUYp
PC-98のMS-DOSでShift_JISのファイルを何も問題なく開けたけど
漢字ROMがJISだとするとファイルを開く時にどこかでShift_JISからJISに変換していたという事？
2021/02/24(水) 18:44:43.54ID:zChO2spG
変換というかシフトしてる分を戻してるだけだな
2021/02/25(木) 16:21:35.59ID:dtuEc+as
可変長で無限に文字を追加できる文字コードなると
全ての文字を実体参照で記録する形式にするしかないのでは？
2021/02/25(木) 17:21:18.30ID:bCEhRyYb
プレーンなgrepができなければ文字コード失格。
甲斐武田氏の家臣だけを抽出する正規表現クラス\p{KaiTakeda}みたいなのも使えなければダメ。
2021/02/25(木) 19:01:31.51ID:FipxGJhu
>>574
VRAM が JIS ベースだ、という話というだけであって、ファイルが S-JIS だろうが UTF-16 であろうがどーでもいい話かと
2021/02/25(木) 19:53:40.28ID:d2pfH4ce
JISとSJISとEUC-JPの文字コードは
比較的単純な計算で変換することが出来るから
パフォーマンスの影響も少なくメモリも食わない

Unicodeの場合は変換にテーブルが必要になるから
MS-DOSの時代ではちょっと困るだろうな
2021/02/26(金) 23:06:18.58ID:mLFL/iLf
MS-DOS時代のテキストエディターで複数の文字コードに対応したものってあったんだろうか
2021/02/27(土) 00:23:55.40ID:9B/eAMtf
nemacsか
2021/02/27(土) 03:48:22.68ID:8wUBQ4y1
単純計算だと非Unicode文字コード種ごとに128KBの変換テーブルが必要になる。
当時の揮発メモリに全部乗せたまま使うのは当然無理。LFUなりLRUなり使ってしのぐしかない。
2021/02/27(土) 07:46:18.27ID:H3Yv4o4X
>>580
demacs/mule
2021/03/03(水) 00:32:39.49ID:Fut02B/b
日本のsc2って今休業中なのかな
Unicode 14のalphaでKana Extended-Aに文字突っ込まれてるけどコメントしなくていいのか
このままbetaに進むと変更が難しくなりそうだけど
2021/03/04(木) 21:20:40.72ID:jw7hSq/n
ASCIIの制御文字にエスケープ文字(0x1b)や
その他の字の区切りを表す制御文字があるのに
メールでもHTMLでも制御文字は使わずに0x20-0x7eの印字可能文字の一部を
エスケープ文字として使うようになったのはなぜなのか
2021/03/04(木) 22:12:23.62ID:BThS1gIP
ここで言うHTMLのエスケープ文字ってどれのこと？
2021/03/04(木) 22:40:28.52ID:jw7hSq/n
>>586
タグを示す<>や実体参照で使う&;
2021/03/04(木) 23:10:32.38ID:BThS1gIP
その手の手書きする奴は図形文字じゃないと逆に不便じゃね？
2021/03/04(木) 23:54:15.04ID:jw7hSq/n
エスケープ文字に制御文字を使うと手で入力するのが面倒になるし
かといって図形文字を使うと文章中の文字と混同しないように注意しないといけなくなるから難しいか。
SJISの0x5c問題もこれが原因だよね。
2021/03/05(金) 02:36:48.86ID:ZMKDWzIT
一言で言えば既存のテキストエディターで書けることを重視したから。
専用のハイパーテキスト用ツールは昔からあったけど不便だった。
591デフォルトの名無しさん
垢版 |
2021/03/05(金) 17:53:33.38ID:Zdg3nLGk
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の理解を諦めたぞ・・・・・・
2021/03/06(土) 02:52:41.34ID:VRCzgeXN
まず unicode と ISO10646 は建前上は別の規格で用語も適用範囲も一致していないと理解することから。
2021/03/06(土) 08:51:58.30ID:Q5bee5g2
>>591
Unicodeは諦めるとして
次はPOSIXとC++のどちらに挑戦する？
594デフォルトの名無しさん
垢版 |
2021/03/06(土) 11:40:26.99ID:6TyCcGYh
Unicode公式 「ISOのUCS-4はUTF-32と同義語なんやでw」

おれ 「UCSは符号化文字集合でUTF-32は符号化方式では？ムキーーーーーーッ？？！」

つらい
全てを投げ出して北海道グルメ旅行したい
2021/03/06(土) 12:58:55.62ID:VRCzgeXN
>>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.97ID:6TyCcGYh
10646:2017だと明確に同義語として使われてたのか。
その版は持ってなくて中身確認できなかったから助かったわ
597デフォルトの名無しさん
垢版 |
2021/03/06(土) 15:41:25.54ID:6TyCcGYh
マジで疲れた
UCS-4はUCSの部分集合だと思ってたけど実は違ったのかw
こんなことに悩んでたのかよクソすぎるw
2021/03/06(土) 18:39:02.04ID:VRCzgeXN
もしかして 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.36ID:21gOPzKM
あ、そこは見た
ただ10646:2020でいう「synonymous」が
どの程度の「同義」なのかが分からなかったけど
10646:2017を引用してくれたおかげで100％イコールなのが分かったわｻﾝｶﾞﾂな
600デフォルトの名無しさん
垢版 |
2021/03/07(日) 12:38:04.56ID:21gOPzKM
やっとこれでクソつまらん文字コードからC++の参考書に戻れる
やったぜ
2021/03/07(日) 23:47:47.88ID:gN+mrqU2
UTF (Unicode Transformation Format)という言葉も昔の遺産だよね
今作り直すならUnicode Encoding SchemeでUES-8とかになるのかな
2021/03/08(月) 00:17:56.33ID:8d5Xwcwc
ちゃうねん。もともと UTF の U は unicode じゃなくて UCS や。Universal の U。
2021/03/08(月) 11:33:52.88ID:3+uDlPP2
文字コードという呼び方をなくして
文字シーケンスと言ったほうが良いと思う
1文字は最大8バイトで表現する
604デフォルトの名無しさん
垢版 |
2021/03/08(月) 12:58:27.48ID:P3HygzNP
EUCのU
2021/03/08(月) 13:47:48.99ID:47hpvSbS
>>602
おおっと、これは失礼しました
2021/03/08(月) 15:45:58.81ID:nvShaTc9
UTF-の後に続く数字は当初はバージョン番号のような意味だったのが
途中からビット数を表す意味に変わったようにも見える
607デフォルトの名無しさん
垢版 |
2021/03/08(月) 23:38:40.10ID:ccXfg1Ko
>>606
Unicodeの種別をUTF-なんとかと言い出したのは、1文字を16ビットで表現することに限界を感じたため。UTF-8は一番やりたくなかったけど、世界中の文字を切り替えて表現する方法は支持されなかったから、最小単位が8バイトのUTF-8が標準になった。
608デフォルトの名無しさん
垢版 |
2021/03/08(月) 23:41:28.57ID:ccXfg1Ko
SJISのように2バイトで表現するキャラクタセットとの相性を重視している場合はUTF-16が使われる。
2021/03/09(火) 09:45:27.84ID:p4cuNQqC
>>607
UTF-8が標準になったのはUnix系の互換性の問題
多バイト固定すると、文字列が1バイト前提であるC言語とC言語で作られてる
Unixのソースコードの多くを修正する必要があった。
そのため互換性があるUTF-8が作られた。
610デフォルトの名無しさん
垢版 |
2021/03/09(火) 11:10:37.15ID:oV9GYLDS
>>609
EUCを知ってますか？
2021/03/09(火) 11:13:42.05ID:p4cuNQqC
>>610
EUCとUTF-8と同じようにC言語とC言語で作られてる
Unixのソースコードと互換性があるように作られたことを知ってますか？
そしてEUCがどうしましたか？
612デフォルトの名無しさん
垢版 |
2021/03/09(火) 17:39:10.59ID:oV9GYLDS
キャラクタセットは選ぶもの
613デフォルトの名無しさん
垢版 |
2021/03/09(火) 17:40:37.43ID:oV9GYLDS
アスキー文字は1バイトで同じ文字コードにしたいのはあたりまえ
614デフォルトの名無しさん
垢版 |
2021/03/09(火) 17:41:09.24ID:oV9GYLDS
UTF-16にこだわったのは欧米人
2021/03/09(火) 17:53:03.04ID:JYZP+6rB
>>612
UTF-16を選べるというのなら選んでみるが良い
互換性がないキャラクタセットはサポートされていない
616デフォルトの名無しさん
垢版 |
2021/03/09(火) 19:47:21.10ID:qz7mFwyh
UTF-16はユニコードの文学的表現と、あわしろ氏が言ってた。
2021/03/09(火) 19:49:34.87ID:N+Xx0u4G
じゃあ間違いってことだな
2021/03/09(火) 22:12:38.95ID:uPwAQTWz
UTF-16 にこだわったわけじゃないだろ。
昔こだわってたのは16ビット固定長。
当時の非力なパソコンだと都合が良かった。

ワークステーションとか性能に余裕がある機械使ってる人たちから絶対に文字数足りなくなる阿呆仕様とか言われてたが、仕方なかった。

後に性能に余裕が出てきた時に既に16ビットでOSとかAPI設計・使用していたので、16ビット可変長を導入した。それが今のUTF-16。
619デフォルトの名無しさん
垢版 |
2021/03/10(水) 23:22:37.08ID:rTwzo8YF
ISO/IEC 8859-1前提で作られていたはずなのに
いつの間にかUTF-8に乗り換えようとしてる？とうに乗り換えた？
WWW(のHTTP)の世界
2021/03/15(月) 00:38:41.86ID:nWbOihFX
0x7Fだけでなく0xFFがDELとして定義されていないのは
0x80-0xFFに文字が定義された時には既に紙テープは使われなくなっていたという事なのかな
2021/03/15(月) 08:07:57.71ID:GifvrUGq
その紙テープとDELの話、機能的に必要だからそうしたというわけじゃないと思うがな。
DELは「削除する」文字なのに紙テープは「削除された」文字になるよね。
2021/03/15(月) 09:04:25.39ID:IkMjMWUP
その 0x80-0xFF というのが 0xFF に文字を割当ててる ISO8859の時代ことなら、もう紙テープななんか使ってなかった。
それより古いの、例えば JISX0201 のカナとかの時代でもほぼ紙テープなんか使ってなかったけど 0xFF は未定義で文字は割当なかった。
2021/03/16(火) 14:48:47.22ID:OdNNK18i
「削除する」というよりか「これは間違いだから無視してね」という印、みたいな感じ
2021/03/16(火) 16:03:04.87ID:NeNdvqnK
モールス信号は単音と長音の組み合わせだからビット表示みたいなもんかな
2021/03/16(火) 21:56:06.00ID:fetr9hD4
へー、DELをバックスペースの意味で使うようになったのが後付けなのか。
https://ja.wikipedia.org/wiki/削除文字
2021/03/18(木) 22:37:10.93ID:bBSRtLnn
制御文字はASCIIコードの最初を占めているのにCUIでのコマンドに使わないのはもったいないと思う。
昔は制御文字をコマンドとして使っていたんだから
例えばSMTPは制御文字のSOH STX ETX EOTをコマンドにしてもよかったのでは
2021/03/19(金) 00:35:37.02ID:pLBLA8wx
あのう…、素人がひとつお尋ねしたいのですけど、よろしいですか？

大昔からWindowsパソコンを使っていて
今までにエディタで書いたテキスト資産をたくさん持つ人が
これからもWindowsパソコンを使い続けると仮定するなら
新しく書くテキストデータの文字コードは何を使えば良いのでしょう？

従来どおりShift-JIS？　それともUTF-8？
なお、テキストは書くだけではなく他人から貰ったデータを読むこともあります
2021/03/19(金) 00:37:01.06ID:pLBLA8wx
ゴメンなさい、最後の一文は
コピペしてテキストをマージすることもある、の意です
629デフォルトの名無しさん
垢版 |
2021/03/19(金) 01:21:48.92ID:hh9Kt8XT
Windowsは表面的にはシフトJISですが、内部はUTF-16です。

メモ帳がBOM付きUTF-8に対応したりとしているので、UTF-8でも特に問題ありません。

テキストエディタやOffice製品でSJISが使えなくなることは、想定しなくてもいいと思います。
630デフォルトの名無しさん
垢版 |
2021/03/19(金) 01:23:29.57ID:hh9Kt8XT
日本語の世界でSJISがなくなることは想定しなくてよいという意味です。
2021/03/19(金) 06:55:45.01ID:MDPOlxpG
>>627
UTF-8一択
絵文字も使えない文字コードなんて使えるか
2021/03/19(金) 07:01:30.18ID:pLBLA8wx
>>629->>630
有り難うございます、てことは…
別に今後もずっとSJISだけを使い続けて良い…という言い方もできますかね？

実はメールでテキストをやり取りする際、相手がHTMLメール使っていたりすると
なぜか「～」が文字化けしたり、しなかったり…、コピペの時に苦労しておるのです
2021/03/19(金) 07:03:11.89ID:pLBLA8wx
>>631
いや、絵文字は一生使うつもりがありませんｗ
2021/03/19(金) 07:53:48.58ID:/oetvOh6
自分自身が絵文字を使うかどうかは重要じゃなくて、他人の書いた絵文字を含む文書を劣化させずに保存できることが重要
2021/03/19(金) 08:22:24.74ID:p1PI4fNB
>>631
絵文字は不要、誰が絵文字なんかを文字コードの中に押し込んだんだ？
2021/03/19(金) 08:45:35.33ID:pPRPone1
>>635
Appleだよ

https://ja.wikipedia.org/wiki/MacJapanese
2021/03/19(金) 09:58:34.93ID:n/AYlKWK
>>636
具体的にどれが?
一般的にはガラケーの各キャリアでは?
2021/03/19(金) 13:03:56.18ID:eiJMVgO4
最初にコード化したのは誰かって意味ならワープロメーカーとかじゃね？
unicodeに入れたのはgoogle。
その元になった絵文字セットのうちの1つを最初に作ったのはドコモ
2021/03/19(金) 14:00:06.98ID:D6AA0Wwh
MSが何を考えているか外からではわからないけど
S-JISは切り捨てる可能性があるんじゃないかな
2021/03/19(金) 14:15:07.57ID:/oetvOh6
>>639
「切り捨てる」の定義次第でしょ。
ゴールポストを動かすように定義を変えることもできる。
2021/03/19(金) 15:26:48.13ID:eiJMVgO4
>>633
macだとcuiでも絵文字使ってるプログラムが増えてて、見やすいしわりと便利よ
2021/03/19(金) 16:19:10.35ID:MDPOlxpG
Powerlineとかのプログラミング用の絵文字
あれUnicodeに入れてくれないかな？
2021/03/19(金) 16:31:55.75ID:AfDayCIW
歩香桂銀金王角飛と杏圭全馬龍の逆さ文字は追加してほしいなぁ……
644デフォルトの名無しさん
垢版 |
2021/03/19(金) 17:45:59.37ID:hh9Kt8XT
Unicodeの絵文字は全世界で使われているからね。
645デフォルトの名無しさん
垢版 |
2021/03/19(金) 17:46:52.40ID:hh9Kt8XT
日本の絵文字がベースだから、日本人っぽいものが多い。
2021/03/19(金) 18:07:03.09ID:/oetvOh6
>>643
文字を所定角度に回転させる異体字セレクタがいくつもあれば一番いいんだけど
30度ごとならアナログ時計の表現にも使えそう
2021/03/19(金) 22:38:34.45ID:pLBLA8wx
あのう…、皆さん色々ありがとうございます

それで…、結局のところ私は…、これから先テキストを新しく書いた時に
そのテキストデータの文字コードを何にして保存すれば良いのでしょうか？
2021/03/19(金) 23:10:26.99ID:gtzZCHhj
何回も何回も裏切られてきたからな
一寸先は闇
UTFが優勢ではあるけど
何があるかわからん
2021/03/19(金) 23:12:46.09ID:AfDayCIW
>>647
BOM 付きUTF-8 でいいんじゃないでしょうか…
2021/03/20(土) 00:19:36.84ID:4rbcgKwq
異体字セレクタは無視可能だから>>643みたいな対比が重要な用途には向かん
2021/03/20(土) 03:11:58.85ID:D8GShjRw
>>649
UTF8 に BOM はいらんだろ。(原理主義)
2021/03/20(土) 03:46:25.95ID:XiFOMzCU
>>647
文字コードはなんでもいいので、...を空文字列に置換してから保存してください
2021/03/20(土) 04:03:35.66ID:HNARUvnS
>>651
627のwindowsでの質問なのでbom付きのが良い
654デフォルトの名無しさん
垢版 |
2021/03/20(土) 06:00:23.16ID:fwPpsQIN
BOM付きはエラーの原因になったりするんだよね
647レベルだと恐らく原因にたどり着けない
2021/03/20(土) 12:04:30.81ID:OmO/62/g
個人用なら UTF8一択でいいよ

ただし、以下が注意かな
1. 納品先、提出先の指定、プロジェクトでの指定があるなら合わせる
2. UTF8に対応していない古いツール類（エディタ含む）を使って処理しているなら合わせる
2021/03/20(土) 13:21:00.17ID:N0CH58op
>>654
エラーの原因になるというか、そのソフトがUTF8シグネチャに対応してないってだけだな。
結局のところ使うソフトや環境次第。
WindowsメインならUTF8シグネチャ付きの方がトラブルは少ないだろう。
2021/03/20(土) 14:11:52.17ID:IyzEzHor
BOM なしUTF-8(UTF-8N)が良い

Windows と言っても、WSL でLinux を使うかも知れないから、
BOMを付けると、動かないかも
2021/03/20(土) 14:43:30.24ID:ATRyxlqT
winにはofficeとか、utf-8でもbomがないと化けるメジャーソフトもあるんだよなあ
659ID:pLBLA8wx
垢版 |
2021/03/20(土) 17:23:15.32ID:kRdQNH2J
皆さん本当に色々とありがとうございました！

出てくる単語を片っ端からググって再確認しつつ、もっとも普遍的原理的な
考え方を自分の頭の中で屁理屈として組み立てあげました！

結論：これから私は、書いたテキストを原則UTF-8で保存する
　　　　 (→必要に応じてBOMをつけて保存し使うこともある)

本当に勉強になりました。２日で１０年分(か２０年分)勉強した感じですw。
660デフォルトの名無しさん
垢版 |
2021/03/20(土) 18:05:23.87ID:fwPpsQIN
もつかれ
2021/03/21(日) 02:58:59.19ID:Hmh4/82J
UTF8はBOMがないのが正式。規格書嫁。
BOMが付くのは他の文字コードから変換の時に頭悪いソフトが削り損ねたか、
メモ帳のように文字コード対応が不完全なソフトが、独自の文字コード判別機能のために規格無視で突っ込んだ
くらい。
2021/03/21(日) 08:53:26.10ID:nNrBMbyx
BOMはオプション的な扱いだけど正式なRFCの仕様だが？
プロトコルとして文字コードを決め打ちする場合とか他の方法で文字コードを受け渡す
仕組みがある場合はBOMを使用すべきではないというくらい。
そもそも「文字コード対応が不完全なソフト」って、UTF-8決め打ちのソフトのことじゃね？
2021/03/21(日) 10:07:00.18ID:ZMzh4Q+Z
>>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とそれ以外の文字コード判別は無理
2021/03/21(日) 10:20:33.48ID:Axw052vZ
>>661
＞UTF8はBOMがないのが正式。規格書嫁。

であれば規格書（）にわざわざ UTF-8 のための BOM 0xEF 0xBB 0xBF が定義されているのは、なぜでしょうか？
2021/03/21(日) 10:46:26.36ID:Hmh4/82J
規格はちゃんと読めとしか。
例えば 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) を仮定して残すのが正しい実装だ。
2021/03/21(日) 11:32:14.01ID:nNrBMbyx
>1) U+FEFF は基本は Zero Width Non-Breaking Space

「本来は～だった。」が正しいだろうな。
その意味で解釈するのはストリームの先頭以外に現れた場合に限るとされているし
今ではその意味でも使用すべきではないということになった。

>2) バイト列化した UTF-16 と UTF-32 の先頭に来た場合は Byte Order Mark

RFCで言う"BOM"にはバイトオーダーマークとシグネチャの両方の機能があって、
バイトオーダーマークとしての意味はUTF-16やUTF-32だけだけれども
シグネチャとしての意味はUTF-8でも有効だと書いてあるだろう。
2021/03/21(日) 12:02:55.18ID:Hmh4/82J
最新規格でも ZWNBS が正式。BOM は例外的な使用法。
「だった」って過去形で主張するんなら規格のどこに過去形書いてあるか、どの規格で廃止されたか示してみろ。
カタカナでバイトオーダーマークって書いても誤魔化せないぞ。
668ID:pLBLA8wx
垢版 |
2021/03/21(日) 13:46:50.50ID:hcZhKSEU
けんかをやめて　二人をとめて
私のためにBOMで争わないで　もうこれ以上
2021/03/21(日) 14:28:20.22ID:nNrBMbyx
ああそうだな。文字の定義自体は変わっていないからその意味では過去形はおかしかったかな。
ただRFC3629では、今は同じ意味のU+2060があるからそっちを使うことを「強く推奨する」と。
2021/03/21(日) 15:38:22.99ID:ahwL4b0J
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としての使い道だけが残った
2021/03/21(日) 23:32:21.54ID:ZMzh4Q+Z
> UTF-8 でも 1) は普通に使える、2)としては使用できない、3)はプロトコル次第(HTTPだと非推奨、FTPだと可)

Byte Order Markの意味わかってんのか？
UTF-8は1バイト単位で扱う文字列なんだから、2として使い方に
意味がないのは当たり前だろ。使えないというより意味がない
使っては駄目という意味じゃない。使ってもいいが本来の意味がないというだけだ。

16bitまたは32bitのときの順番を判断するためにあるのに
Byte（バイト） Order（順番） Mark（記号）

つまりU+FEFFは「文章のどこでも使っていい文字」で
先頭に来た場合に限りBOMとして解釈するというだけだ
2021/03/23(火) 08:39:38.88ID:VNfq1a/Y
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.
2021/03/28(日) 20:48:56.89ID:24lC/lyM
そもそも全く意味も機能も異なるZERO WIDTH NO-BREAK SPACEとBYTE ORDER MARKを
U+FEFFという単一のコードポイントに統合した馬鹿は何処の誰なん？
2021/03/29(月) 10:11:40.65ID:wK+S1L2g
>>673
英語よめないの？

ZERO WIDTH NO-BREAK SPACE（幅がない改行をしないスペース）
BOMは幅があるか？ないだろ
改行するか？しないだろ

BOMが途中に出てくることがあるか？
その場合どうすればいいんだ？
無視する＝幅がなくて改行しないスペースだろ
2021/03/29(月) 16:21:58.12ID:OlONkL8s
落ち着け
ZWNBS は無視しちゃ駄目だよ。そこで自動改行禁止というマークなので、ちゃんと処理しないと駄目。
2021/03/29(月) 17:07:30.02ID:wK+S1L2g
>>675
自動改行禁止の意味わかってるか？
無視する＝そこに文字がないのと同じように扱うから
自動改行も禁止なんだよ

BOMとZERO WIDTH NO-BREAK SPACEを同じにしたと言うより
BOMはZERO WIDTH NO-BREAK SPACEと同じ動きをする文字だということ
2021/03/29(月) 21:25:17.42ID:FXjqyr6T
あまり文字コード関係ないけど笑ったので貼っとく

https://twitter.com/ryancdotorg/status/1375484757916672000
https://twitter.com/5chan_nel (5ch newer account)
2021/03/30(火) 02:24:24.90ID:T6lwQIyt
>>676
嘘をつくな。
BOM は内部コードに変換する時に取り除くべき文字。制御コードとしての機能はない。
ZWNBS は内部コードでも残り制御コードとして前後の文字を一体として接続し、その間での改行を禁止する意味を持つ。
2021/03/30(火) 02:31:28.79ID:ToWHw8Xp
>>678
だからそのBOMが文書の内部に出てきたら
どう処理するんだよって話なんだが

データに絶対入らないように誰かが制限してるか？
バイナリエディタを使っても入れることが出来ないか？
入っていたら落ちたほうがいいか？
2021/03/30(火) 03:04:28.57ID:T6lwQIyt
>>679
寝ぼけっての？
文章の途中に来たら BOM じゃないよ。
2021/03/30(火) 05:29:26.08ID:ToWHw8Xp
>>680
だからバイナリエディタでBOMと同じコードを文章中に入れたものを
読み込んだら、どういう挙動をするべきかって話をしてるんだが

制御コードとして前後の文字を一体として接続し、その間での改行を禁止する意味を持たせたほうがいいだろうね
2021/03/30(火) 09:51:00.56ID:T6lwQIyt
持たせたほうがいいも何も、規格上はそういう意味だよ。
バイナリ・エディタで入れようが、テキスト・エディタで入れようが 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 は、これまでどおり の意味で解釈せよ。
2021/03/31(水) 01:51:23.09ID:AtIsL56M
asciiの0-32までってc記法あるの以外ほぼ死語かと思ってたんだけど
バイナリエディタでMS系のフォーマット(特にOffice)で汎用されてるのな
セパレータ系とかなるべく原義に沿おうとしてて好感
いつもprintable文字抽出だけしてたからなかなか気付かんかった
2021/03/31(水) 01:57:57.39ID:AtIsL56M
論理的に考えてcrlfが正義とか言い張り続けてたり、なんかこだわりあるんかねMS
2021/03/31(水) 09:30:13.62ID:ekNiD538
> 論理的に考えてcrlfが正義とか言い張り続けてたり

なんのこと？
意味的にCR LFが正しいことに間違いはないし、CR LF対応は
意味のないプライドとかじゃなくて互換性のためにでしょ

それにLinuxとの互換性のためにLFだけのファイルもメモ帳で受け付けるようになったじゃん
開発ツールに限れば昔からLFだけでも認めてた。
2021/03/31(水) 09:35:15.80ID:1T2H/5i8
>>685
crlfで正しいと思ってるよ、まあ蛇足だった
2021/03/31(水) 09:41:35.38ID:1T2H/5i8
Officeのalt/shift+retとかで特殊な改行したりするけど、ちゃんと対応するASCII制御文字入ってたんだなと感心してしまったもんで
2021/03/31(水) 10:06:28.66ID:AtIsL56M
表の階層化にFS, GS, RS、複数行セルにVTとか使ってるねー、面白い
echoでコピペしてみたけどこれは受け付けてくれないっぽい…残念
2021/04/02(金) 14:48:41.83ID:XKDKi0jd
メモ帳で折り返しにCR CR LF入れるとかもこの流れなのかな？
2021/04/04(日) 09:56:09.95ID:Y/fIEFRX
やはりBOMは必要だな

「ASCIIをUTF-8にして」それが『できない』ことを理解してもらえなかった話
https://qiita.com/heeroo_ymsw/items/c6e15d5f9246b4e842eb
2021/04/04(日) 11:25:45.54ID:BHN4NYpU
>>689
きになる
Format>WordWrap?だよね

折返した状態で保存みたいなオプションがあるのかな

当たり前だけど保存しても改行してない（してたらバグだw
表示上だけ入れてるのかとコピペしても拾えない
内部で描画のコントロールに使ってるということ？かな？
2021/04/04(日) 11:47:39.11ID:BHN4NYpU
>>690
要するに
UTF-8、但しASCII/sjisとの共通部分はダメ、かつ英数字のみを使いたいということね

０１２０―ＡＢＣーＸＹＺ（ユニコfull-width latin

これで要件を満たせる！
2021/04/04(日) 11:59:15.19ID:bg/3EMBi
顧客が本当に求めていたモノ…
2021/04/04(日) 20:11:30.38ID:+Q6KU8is
BOM付きだな
頭でっかちの原理主義者はいつでも間違っている
2021/04/05(月) 01:33:23.71ID:HL3+b1wt
あほ過ぎる
UTF8 や本来のSJISやEUCはASCIIの完全上位互換なのがメリットなのに BOM 入れて互換性無くすとか素人の極み。
ASCIIと互換性無くていいんなら UTF16でも使ってろ。
696デフォルトの名無しさん
垢版 |
2021/04/05(月) 01:40:26.92ID:6E9KDupE
その考え方がそもそもの間違いだわ
2021/04/05(月) 01:48:11.31ID:i9PX2oQn
全角で納品したら楽しそうだからそれで
2021/04/05(月) 07:02:33.51ID:HL3+b1wt
ファイル名にいちいちBOMが入ってて、ASCII で書かれたファイル名と、UTF8で書かれたファイル名が、別ファイルとして扱われる世界。
考えただけでも吐き気がする。
2021/04/05(月) 08:21:19.81ID:qswNC1lG
ファイル名にBOM入れる奴はさすがにいないだろ…
いないよね？
2021/04/05(月) 09:04:19.64ID:Tyhmgvsu
BOMは"ファイル"に入れるのは別に悪くないと思ってる
明示できるものは明示すべきだろう、何でもutf-8の時代になりつつあるから、むしろ他のutfやsjis/eucに入れるのが時代にそぐう
もはやBOMじゃなくて単なるマジックナンバーだが

ファイル名…ってのは正直思いつかなかった
でもBOM付きの細かいテキストを文字列として継ぎ接ぎした時にトリムするのが面倒だった経験があるわ
やはりマジックナンバー、テキストファイル=マジックナンバー+テキストとして扱うべき
テキストファイル以外に付けるのは勘弁
2021/04/05(月) 11:09:52.26ID:gsx4ZFoJ
そりゃ仕様できっちりとBOMを入れませんと
なってるものにBOMを入れる必要ないだろ

テキストファイルの場合はいろんな文字コードが
歴史的な経緯で許可されてるフォーマットだから
BOMをファイル形式を判断するヘッダとし
て利用するというだけであって
2021/04/05(月) 11:12:15.44ID:gsx4ZFoJ
>>695
BOMはテキストファイルにおいて文字コードを判別するための仕組み
BOMによってSJISやEUCではないと判別できるのに
互換性がなんの関係があるのか？
SJISやEUCと互換性がないからこそ、文字コードを判別するのに利用できる
2021/04/05(月) 11:51:41.26ID:HL3+b1wt
なんで UTF -8 と SJIS の互換性気にせにゃならんねん。
これやから、ロートル多いスレは。
今からの時代 BOM なんかくてもデフォルトは UTF-8 だよ。
Linux とか Mac は既にそうなってるし、日本語WIndowsだって次か、次の次のメジャーバージョンくらいで SJIS 捨てて UTF-8 いくやろ。
過去に生きてるやつはBOM 必要かもしれないが、今が過渡期なのでそんな気がしてるだけや。
どうせ欧米がナロー系の文字コードは UTF-8 に一本化で動いてるんで、今さらどうにかなるもんでもない。
2021/04/05(月) 13:58:26.49ID:gsx4ZFoJ
>>703
すぐバレる嘘を付くな

> Linux とか Mac は既にそうなってるし、
Linuxはローケルの変更から日本語だとEUC-JPに対応しているしSJISも使える
https://www.early2home.com/blog/os/linux/post-1314.html

WindowsはNTは最初からUTF-16だ
2021/04/05(月) 14:08:55.17ID:i9PX2oQn
ぶっちゃけUTF-8をマトモに実装するのは難しいので勘弁してほしい
正規化とかわけわかんぬ…
プログラミング言語やライブラリの内部ではコードポイントそのままで固定長で扱いやすいUTF-32採用が多いね
後に成熟してきたら変換のオーバヘッド削る為にUTF-8に切り替える風潮だけど（pythonはじめ諸々

将来ネットワークのスループットが良くなればUTF32も受け入れられたりしないかな、それまで生き残ってればの話だが
2021/04/05(月) 14:19:53.71ID:HL3+b1wt
>>704
デフォルトって言葉の意味知ってる？
2021/04/05(月) 15:36:03.55ID:Wm92d7Ex
>>706
WindowsのデフォルトはUTF-16です。
英語のアメリカでも日本語のSJISがデフォルトだとでも思ってた？
そんなんだから理解が浅いって言われるわけ
2021/04/05(月) 15:37:39.57ID:Wm92d7Ex
>>705
UTF-32はもはや固定長じゃないよ

漢字1文字が最大8バイトUnicodeの「IVS」が
32bit、4バイトに収まるわけがない
2021/04/05(月) 16:24:25.38ID:4C6FED3z
デフォルト、破産だよ
デフォルト国家、あの国やったろ
2021/04/05(月) 17:09:09.07ID:HL3+b1wt
>>707
日本語Windows のデフォルトの話してるのに、何で英語のアメリカとか関係してくるんや？
文字が読めない人なのだろうか？
お前の Windows 日本語インストールして直後のカスタマイズ無しの状態でコマンドプロプトで chcp って打ったら何と応えるの？
2021/04/05(月) 17:09:52.54ID:w8t18er9
日本語版Windowsのデフォルトコードページは今でもCP932だが？
2021/04/05(月) 21:28:09.04ID:EGK62I3K
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.84ID:OztXbvyw
うんこーど
2021/04/05(月) 22:03:05.34ID:2g7RifS+
ユニコードには、UTF-8/16/32 の3つあって、
各OS・ファイルシステムによって異なるから、ややこしい

だから、システム関係には、ASCII 互換の部分だけを使えと言ってる。
128種類、7 bit ascii だっけ？
2021/04/05(月) 22:20:28.93ID:Hlip8dzv
>>711
何見て言っているのか知らんけどプログラムで文字列扱っていれば内部処理がUTF-16LEなのは知っているはず
2021/04/05(月) 23:10:35.17ID:r3L3lQkE
>>703
Windowsは当面過渡期のままだよ
「ワールドワイド言語サポートで Unicode UTF-8 を使用」って設定は登場から3年経ってもベータのままだし
2021/04/06(火) 00:46:43.57ID:+n99AGjS
>>711
> 日本語版Windowsのデフォルトコードページは今でもCP932だが？

UTF-16だよ
だから日本語版Windowsで絵文字が使えるんだが？

CP932がどこで使われるのかわかってない？
2021/04/06(火) 00:47:44.91ID:+n99AGjS
>>710
コマンドプロンプトの問題で
Windows全体（エクスプローラーやブラウザ等）には
当てはまらないと認めるかい？ｗ
2021/04/06(火) 00:50:23.32ID:+n99AGjS
>>716
その上に「Unicodeに対応してない古いアプリの場合」って書いてあるやろ？ｗ

Unicodeに対応している新しいアプリはUnicodeだし

お前「Unicodeに対応してない古いアプリ」がUTF-8にしたら
動くようになるとでも思ってんの？Unicodeに対応してないのにｗ
2021/04/06(火) 01:02:50.31ID:4WR5kIDO
最近のwin10アップデで古いwinアプリが文字化けしだしたのはこれか？
設定で対応できるし内部で一貫してる限り問題はないけど
2021/04/06(火) 01:05:08.37ID:+n99AGjS
>>720
どこの設定をどう変えたら対応できたんだ？
2021/04/06(火) 01:18:09.92ID:4WR5kIDO
>>721
うろ覚えだけど英語圏向けwin10固有の問題だったかと
日本語版と日本語設定の英語版が違うと言う罠
システムロケールを日本語(英語以外)に変えるとユニコにフォールバックするようで
コードページ切り替えオプションがまた別にあるけどグローバルに適用されるので今度は他が化ける、アプリごとに設定開くので非常に面倒くさい
2021/04/06(火) 01:21:01.30ID:4WR5kIDO
化けたメニューを記号として認識できるように訓練したから最近は弄ってない
高くても日本語版買おうね！
2021/04/06(火) 01:27:04.53ID:T8jVvgda
ロートルが多いとか関係ないんだがな
若くたって古いシステムの吐くログを見ようと思ったらEUCだったりするんだよなあ
2021/04/06(火) 01:33:59.26ID:4WR5kIDO
ローカル版windowsには、スクリーン上に同時に存在するテキストを複数の方式でデコードする機能がある、でいいのかな
2021/04/06(火) 02:47:28.83ID:iR3Vnnhg
>>719
ASCIIにしか対応してないソフトはそれで意外と動いたりするんだよな
Unicodeファイル名が普通に使えるようになったり、というかそのための設定
マルチバイト対応してるソフトは壊れるけど
今ならmanifestでアプリ単位でコードページをUTF-8にするのもあり
2021/04/06(火) 03:58:58.47ID:xQBleszy
どうしたらいいのか
728デフォルトの名無しさん
垢版 |
2021/04/06(火) 08:00:46.97ID:zE9kqee/
窓から投げ捨てればいいのさ
2021/04/06(火) 08:27:12.05ID:MTiaA6bM
>>722
> 日本語版と日本語設定の英語版が違うと言う罠

Windows自体はUTF-16で複数の言語に対応しているとは言え、
アプリは別の問題で、UTF-16に対応してない古いアプリは
特定の文字コードでしか動かないんだよ
その古いアプリも手厚くサポートしてるのがWindows
2021/04/06(火) 10:13:01.08ID:wM6kHA3V
>>729
新しいソフトでもナローAPI使ってるやつたくさんあるわ特に欧米産。
ワイドAPI (UTF16)が標準とか思ってる時点で何もわかってない。
2021/04/06(火) 13:40:51.68ID:tV10gXpM
何で文字コードスレにこんな無知がいるんだろうなあ。
2021/04/06(火) 15:39:19.88ID:P0s3gsjp
>>730
そのアプリ、絵文字使えないってことだよね？
いまどきそんなのあるの？
3つぐらい名前言ってよ
2021/04/06(火) 15:54:30.38ID:wM6kHA3V
>>732
そんなことはない。どうして使えないと思った? もしかしてコードページの使い方知らないの？
コードページを CP65001 や CP1200 に設定すれば使える。
コードページが CP932 だと使えないのは、もちろんだが。
2021/04/06(火) 16:20:50.90ID:P0s3gsjp
>>733
コードページは関係ないナローAPIを使ってると
絵文字は使えない
2021/04/06(火) 17:48:00.38ID:wM6kHA3V
>> 734
「コードページは関係ないナローAPI」 ← 自己矛盾。
俺のいうナローは Windows ならコードページ、Linux ならロケール依存なんだが？
他にどんな意味で解釈したの？ お前の定義を教えて。
その上で、お前の定義だとどうして絵文字が使えないのか解説して。
2021/04/06(火) 18:33:56.50ID:iJXUWS4l
絵文字のデータとしての扱いとフォント依存による表示の区別付かないのかよ
2021/04/06(火) 22:47:03.03ID:P0s3gsjp
>>735
ナローAPIとそうでないAPIを具体的に言ってみ
2021/04/07(水) 01:36:05.17ID:vjDi/c6S
>> 737
誤魔化さずに、まずはこっちの質問に答えろや？ できるもんならな。
お前、まとともに複数の言語と文字コードに対応したプログラムとか組んだことないやろ？
中途半端な知識で知ったかぶりしてて、引っ込みつかなくなっただけなら、謝ればすむんやで。
匿名掲示板なんだから、謝ると負けとかはないぞ、勉強して出直せばいい。
謝るのが、めんどくさかったら ROM っとけ。
2021/04/07(水) 01:55:04.39ID:vjDi/c6S
しかし、あれだな。
ナロー系のデフォルトは今後 UTF-8 になっていくって話してるのに、
「ナローだと絵文字使えない」とか言い出すやつが湧くのは、どうしたもんだか。
基礎知識が足りてないのか、文脈読めないのか、その両方なのか。闇は深い。
2021/04/07(水) 02:26:54.44ID:g0cTo5ct
喧嘩腰なのはいいけどレスアンカくらいちゃんと書こうよ >>の後のスペースは不要
2021/04/07(水) 04:00:51.96ID:APsY2wPt
ナロー系ってなんだ？
オレオレ用語で言ってても誰にも通じない
2021/04/07(水) 04:16:35.54ID:K+K6a3YU
あれや、トラックに引かれて死ぬが異世界に転生
そこではなぜかチートじみたものすごい能力が・・
2021/04/07(水) 05:15:10.31ID:ALhqLzoC
>>741
win32api の一部の api （文字列を与えるもの）は同一機能で W系とA系の両方が準備されていますが、
そのうちの A系のことをナロー系と呼んでいるのでは？
2021/04/07(水) 07:09:32.19ID:dkOgfJAM
>>735
Windowsでもロケールじゃないかな？
ここで言ってるコードページってどこで設定するやつ？
2021/04/07(水) 09:06:06.52ID:hP9Ops4B
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に変更してもらえる（＝古いアプリを使ってない）ことが前提
2021/04/07(水) 09:06:55.52ID:vjDi/c6S
>>741
俺も「ナロー」がそれほど良い用語だと思ってるわけではないけど Linux,Mac,Windows で共通の良い技術用語がないので、マシな方なんだよ。
Unix系の用語だと「ワイド文字」の対義語は「多バイト文字」なんだが、これだとさらに誤解する人多いしなあ。1バイト ASCIIでも「多バイト」ってなんだ？的な。
2021/04/07(水) 09:15:40.29ID:EM71BOqG
コードページは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固有の話ではない
2021/04/07(水) 09:18:43.08ID:oaQMbN7A
このスレの人たちはエディタで書いたソースを何で保存するの？UTF-8？
秀丸はデフォルトでSJISだったよね？(今は違うのか？)
2021/04/07(水) 09:19:55.48ID:hP9Ops4B
>>747
> Windowsのデフォルト日本語環境はmacOSやLinuxのja_JP.UTF-8とは違う

Windowsのデフォルト日本語環境は
1. OSの文字コード・・・UTF-16統一
2. ロケール（UIやカレンダーなど）・・・日本語
3. Unicode非対応の古いアプリ用、CP932に設定

いい加減システムロケールというのは
OSのデフォルトとは関係ないと認識してくれ
2021/04/07(水) 09:21:37.00ID:hP9Ops4B
>>748
ずっと前（Windows 2000の頃）から
Linuxと相互運用するものはUTF-8
Windowsでしか使わないソースコードはUTF-16だよ
Windowsでしか使わないものは少ないからほとんどUTF-8だけど
2021/04/07(水) 09:24:13.21ID:hP9Ops4B
あと秀丸とかとうの昔に使うのをやめた
遅くともSublime Text（2008年ごろ？）からUTF-8に統一
atomを経て今はvscode

それまでは何使ってたっけ？vimとかemacsとか一時期使ってたけど
そういや昔はLinuxではEUC-JPを使ってたね
2021/04/07(水) 10:21:35.02ID:gW8in2Np
Win10 1803でANSI APIでUTF-8を使うようにする設定がベータで入ったけど、
結局MSは影響が大きすぎると判断したんだろう
代わりに1903で、システム全体じゃなくてアプリ単位でUTF-8を使えるようにする機能が入った
ANSI APIのデフォルトがシステム全体でUTF-8になるのは5年とか10年先の話じゃないかな
2021/04/07(水) 11:34:30.51ID:hP9Ops4B
> ANSI APIのデフォルトがシステム全体でUTF-8になるのは5年とか10年先の話じゃないかな
> 結局MSは影響が大きすぎると判断したんだろう

MSじゃなくても影響が大きいってわかるわ。デフォルトをUTF-8にするのは
古いアプリとの互換性を切り捨てるってことを意味する
デフォルトにしていいのは、既存のUnicodeに対応してないアプリが消え去って
互換性を気にしなくていい時代になってから。それぐらい時間がかかるのは当たり前だろう

アプリ単位でUTF-8が使えるならそれで十分でしょ
UTF-8用に作られたアプリは、システムロケールをUTF-8にするように
マニフェストかなにかで設定できるだろうし
Windows NTのデフォルトの文字コードがUTF-16に統一されてるわけだから
わざわざ古いアプリの方のデフォルトを変更する理由がない
2021/04/07(水) 12:27:49.00ID:hP9Ops4B
システムロケール（本来は古いアプリ用の設定）を
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に両対応出来ますよ。という話
2021/04/07(水) 13:30:36.82ID:gW8in2Np
ASCII専用の欧米ソフトは案外その設定で動いたりするんだよ
ASCII圏のユーザーにとってはチェックを入れるだけでUTF-8が使えるようになる（かもしれない）便利設定
別に新しく開発するアプリのための設定というわけではない
マルチバイト圏のユーザーにとっては互換性壊すだけの余計な設定だが

ちなみにANSI APIでUTF-8を使う際には、パス名がMAX_PATHバイトまでしか扱えないという
重大な欠点があるのは注意な
Wide APIならMAX_PATHコードユニットだから、それに比べると扱える文字数は最悪1/3になる
2021/04/07(水) 14:39:04.07ID:UOCtMYlF
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
2021/04/07(水) 16:22:47.71ID:vjDi/c6S
>>753
間違い。昔から複数の文字コードで動くプログラムはある。
コードページ切り換えによって SJIS でも KOI8 でも BIG5 でも動くように作られているプログラムは、
修正無しで UTF-8 にも対応するようになる。
そもそもコードページの切り換えにちゃんと対応したプログラムはそうなってるのが普通。
SJIS専用処理とかしてるアホが作ったプログラムは、修正が必要だが、それは複数文字コード対応できてないんだから仕方ない
2021/04/07(水) 17:58:42.18ID:bf9TqbnX
アプリ単位でUTF-8が使えるようになってたの知らなかった
横からだけどありがとう
https://superuser.com/questions/1033088/is-it-possible-to-set-locale-of-a-windows-application-to-utf-8/1451686#1451686
のUpdateのところに対応方法がまとまってた
2021/04/07(水) 20:05:39.59ID:dkOgfJAM
>>757
一般論としてはそうだけど、WindowsのANSI系APIやVSのCRTが本当に全部UTF-8に対応してるんだっけ？
2021/04/07(水) 21:05:32.99ID:7mS/mNQI
コマンドプロンプトとサロゲートペア縛り
https://zenn.dev/zetamatta/books/b820d588f4856bcf836c/viewer/95bfb9
2021/04/07(水) 22:56:12.09ID:vjDi/c6S
>>759
Windows には山ほどライブラリ(DLL)があって、その中には対応できてなかったり、できてるはずなのにバグバグなやつとか多数ある。
今後のアップデートで直るかもしれないやつも多数あるけど、仕様上どうやって直すんだ？！ みたいなやつもある。
一般論でしかないのは、その通り。過渡期なんだよ。
一方で Microsoft は CP_ACP はもう使うな CP_UTF8 使えとか言い出してる。
2021/04/07(水) 23:51:48.85ID:hP9Ops4B
> 一方で Microsoft は CP_ACP はもう使うな CP_UTF8 使えとか言い出してる。
そりゃそうだろ。CP_ACPは古いアプリが使ってるかもしれないが
それじゃUnicodeには対応できない。文字数とかサロゲートペアが
正しく判断できない。ANSI系でUnicode使うなら書き換えが必要
2021/04/08(木) 01:14:14.46ID:osA77g/q
>>762
ACP でも UTF8 や UTF16 が使えること知らない人は引っ込んでて。
2021/04/08(木) 07:51:09.35ID:65tq2lAC
CP_ACPとかってMultiByteToWideChar以外どこで使うんだっけ
2021/04/08(木) 08:24:03.75ID:5KgENm+i
相手するなよ
766デフォルトの名無しさん
垢版 |
2021/04/08(木) 14:33:47.10ID:BYjSvKlS
過渡期30年
まだまだ続く過渡期
2021/04/08(木) 16:48:36.55ID:osA77g/q
コンピュータのコードなんてずっと更新中みたいなもんだけど。
MS が UTF-8 のサポートをまともに開始したのは 2017年から。
古い文字コードを捨てて,今後は UTF-8 のみを推奨ってアナウンスしたのが 2019年から。
30年が何を指すのかしらんけど、あと5年や10年くらいは待ってやれ
2021/04/08(木) 16:51:08.06ID:cADyO+yl
バッチスクリプトをUTF8で走らせられるようになったの？
2021/04/08(木) 17:54:09.52ID:osA77g/q
中で呼び出すプログラムが code pege 切り換え対応、もしくは utf8 対応ならバッチできるよ
例えば UTF-8 で以下のようなバッチを書けば、日本語Windowsでも動くよ
chcp 65001
echo かな漢字 > file.txt
type file.txt
pause
2021/04/08(木) 18:08:44.31ID:UozSJGhl
>>767
> 古い文字コードを捨てて,今後は UTF-8 のみを推奨ってアナウンスしたのが 2019年から。

古い文字コードを捨ててません。
新たにUTF-8対応を増やしただけです。

Linuxは古い文字コードを捨てましたか？捨ててないでしょう。
そんなアホなことをするOSなんてありませんよ。
2021/04/08(木) 18:11:58.41ID:UozSJGhl
>>768
それはずっと前から出来る。
少なくともWindows 2000では確認した。
ただ画面の表示がおかしくなっていただけ
処理結果はまともだった
2021/04/08(木) 18:17:12.48ID:cADyO+yl
マルチバイト文字を含むコマンド引数がただの文字列じゃなくて、ファイルパスだったりすると積むはず。
2021/04/08(木) 18:27:11.87ID:UozSJGhl
ファイルパスも文字列だろ

ところでなんでcp932に設定していても
絵文字が含まれたディレクトリにcdできると思う？
絵文字はcp932には含まれてない。だから使えるはずがない
だけどコマンドプロンプトでcp932にしても普通にcdできる

答えは、cp932は古いアプリ用であって
コマンドプロンプト自体はUTF-16で動いてるからなんだよ
WindowsはNTの時代にすでに完全にUnicode対応を終えてる
OSはUnicode（UTF-16）で動いている

cp932とかいうのは互換性機能でOSとしては重要ではなく
互換性機能をなくすのは、それが不要になってからで十分なわけ
2021/04/08(木) 19:21:17.04ID:osA77g/q
>>770
「捨てる」っていうのが正確で無かったか？ サポートをしないって意味ではなくて
「今後は書かれるプログラムは古い文字コードをサポートする必要はない。UTF-8 だけ排他的に使用することを推奨する」
という方針を打ち出したんだよ。もう前のことなのでニュース記事のリンクとか出せないけど、かなり話題になった。
開発者ドキュメント等を読めば買いてると思う。
2021/04/08(木) 19:30:38.81ID:osA77g/q
>>771
わかってて言ってるんじゃないかと思うけど、重要なのは echo の行ではなくchcp 65001 の話。
これで TYPE の行のように正しく画面表示されるし、他のバッチから呼び出されるプログラムも UTF-8 の切替わる。
pause の行のように言語が日本語から英語に切替わってしまうので、メッセージとか日本語じゃないと困る人には駄目な方式なんだが
2021/04/08(木) 19:46:39.13ID:osA77g/q
>>773
お前は、バッチファイルすらまとも使ったことないだろ？
内部コードと外部(入出力)コードの区別すらまともについてないくせに、いちいちコメントすんな。
Windowsの内部コードがUTF16のことなんて全員わかってるんだよ。
みんなが議論しているのは外部コードのはなし。コードページとかUTF-8とかも全部、外部コードに何を使うか。
バッチファイルの文字コードも外部コード。
マイクロソフトは外部コードを UTF-8 に統一する方向で動いてるって話をしてる。
2021/04/08(木) 20:50:56.63ID:UozSJGhl
>>774
> 「今後は書かれるプログラムは古い文字コードをサポートする必要はない。UTF-8 だけ排他的に使用することを推奨する」

前からUnicode（UTF-16）推奨だったじゃん。
今後は書かれるプログラムは古い文字コードをサポートする必要はないのは
UTF-16でも同じことで、古い文字コードをサポートする必要なんてなかった

単にANSI系でもUTF-8が使えるようになりましたってだけだよ
2021/04/08(木) 20:54:30.34ID:UozSJGhl
>>776
> マイクロソフトは外部コードを UTF-8 に統一する方向で動いてるって話をしてる。
そんな動きないよ

今だって標準はUTF-16だし、UTF-8もサポートしたと言うだけの話
2021/04/08(木) 20:58:09.07ID:UozSJGhl
> みんなが議論しているのは外部コードのはなし。コードページとかUTF-8とかも全部、外部コードに何を使うか。

違うよ。コードページは古いアプリが使うコードのことだよ
2021/04/08(木) 21:26:50.32ID:PAVlbVqd
古いだの新しいだのそういう曖昧な言葉を使うのは良くない
2021/04/08(木) 21:44:00.84ID:5KgENm+i
入出力時のデフォルトコードページの話だから古いか新しいかなんて関係ないんだけどな。

いい加減みんなこのバカ相手するのやめようぜ。
2021/04/08(木) 22:03:05.49ID:cADyO+yl
マイクロソフト謹製のPowerShellは完全にコードページ依存だよ。
MSYSなどUTF8で出力する伝統的な実行バイナリとうまく共存できない。パイプが積む。それが現実。
2021/04/08(木) 23:16:12.03ID:u7kxAAh5
さすがに、このスレにいて Windowsの「メモ帳」アプリのデフォルト文字コードが「 UTF-8 (BOM無し)」に変更されたことを知らない人はいないだろ。
これはMSが UTF-8 BOM無しを今後の標準とすることに舵を切った結果だよ。
これが UTF-16 だったり BOM つきだったりしないのは、単なる気まぐれじゃない。
2021/04/09(金) 01:54:21.80ID:ZRNzIbD0
BOM付きじゃなくてBOM無しUTF-8がデフォルトになったのは驚いた
そっちに舵を切ったのはそうだろう
だがExcelでBOM無しUTF-8なCSVが扱えないとか、リソースコンパイラで
BOM付きUTF-8すら自動判別してくれないとか個々のアプリはまだまだ対応不足
2021/04/09(金) 01:56:45.03ID:s5EJohG2
デフォはありのほうがいいと思うんだがな
2021/04/09(金) 03:06:58.40ID:3uc6Yjpo
>>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にバリバリ依存して作ることなんてないしね
2021/04/09(金) 03:08:04.84ID:3uc6Yjpo
>>783
> さすがに、このスレにいて Windowsの「メモ帳」アプリのデフォルト文字コードが「 UTF-8 (BOM無し)」に変更されたことを知らない人はいな
> これはMSが UTF-8 BOM無しを今後の標準とすることに舵を切った結果だよ。

なあ。お前。メモ帳以外の事例は存在するか？
一テキストエディタにすぎないメモ帳のデフォルトが
変わった程度で騒ぎ過ぎだよ
2021/04/09(金) 04:36:09.91ID:l1/kJ2NK
はぁ？
クロスプラットフォームで開発されている実行バイナリはC/C++案件が多いから、WindowsのAPIにバリバリ依存だよ
.NETなんてLinuxやmacOSで動かないだろ
2021/04/09(金) 09:51:30.06ID:dDP8WojW
>>786
> 今どきWindowsのAPIにバリバリ依存して作ることなんてないしね
Windows の API 使わずにプログラムとかww
それこそ fopen() とかの標準Cライブラリこそコードページ依存だろ。もしかしてそれすら知らない？
Mac 使いですか？ それとも Java屋さん？
Windows の API まともに知らないやつが プログラム版で Windows について語ってんの？
2021/04/09(金) 10:10:06.15ID:3uc6Yjpo
> Windows の API 使わずにプログラムとかww

え？知らんの？そういうのは言語やライブラリが解決してくれるんだよ。
.NET フレームワークとか、nodeとかrubyとか
Windows APIを使わないことなんて当たり前
2021/04/09(金) 10:12:26.81ID:3uc6Yjpo
> .NETなんてLinuxやmacOSで動かないだろ
動くじゃん
2021/04/09(金) 10:21:23.24ID:7vOVb2O0
EcxelがBOMなしのCSV読めんからな
メモ帳がBOM無しでも関係ないな
2021/04/09(金) 11:02:02.21ID:dDP8WojW
それ以前に .Net デフォルトだとコードページ依存じゃないかwww
ruby は Windows のプログラムじゃないし。
node って何? もしかして Node.js のこと？ まさか JavaScript 基準で Windows の文字コード語ってたの？
さすがに、それはないよね...。
node というのは聞いたことない、もしくはどれを指すのが不明なので教えて。
2021/04/09(金) 12:38:07.07ID:3OIwAD6R
>>745
話題持ち込んじゃった人だけど分かりやすい
ありがとう
795デフォルトの名無しさん
垢版 |
2021/04/09(金) 15:21:47.85ID:tQcHQU6Y
nodeはオワコン
るuびyはもっとオワコン
2021/04/09(金) 17:38:21.19ID:3uc6Yjpo
>>793
ああ、今どきのWindowsプログラムを知らんのね
例えばvscodeはJavaScriptで出来てるんだよ
.NETがコードページ依存って何を言ってるんだろうか
2021/04/09(金) 18:36:32.22ID:dDP8WojW
> .NETがコードページ依存って何を言ってるんだろうか
入出力用の文字コードの概念がないやつには一生理解できないだろう(確度の高い予測)
他の人のためにリンク張っとく
https://docs.microsoft.com/en-us/dotnet/api/system.text.encoding.default

ちなみに Linux とかでも動くオープンソース版の .NET Core はコードページないので、UTF-8 (BOM無し)になる。
2021/04/09(金) 18:47:45.05ID:3uc6Yjpo
>>797
そんなの出されても意味がないなぁ。
言語の内部コードと、外部コードの違いわかってる？

例えばPythonの文字コードはUTF-8なわけ
それをStreamRecodeを使って自動的に外部文字コードに変換する時
https://docs.python.org/ja/3/library/codecs.html#streamrecoder-objects

Pythonの文字コードはSJISだ！コードページに依存してるんだ！なんて言わないでしょ
.NETも内部の文字コードはUnicodeなわけ
外部への文字コードへの自動変換を備えてるけど
それはほとんどの言語で標準的に持ってる機能なわけ
2021/04/09(金) 18:48:43.58ID:S5JYCJ7D
そういえば、関係ないけど vscode も UTF-8 BOM無しが規定文字コードだね。
メモ帳だけじゃなくてテキストエディタは UTF-8 ってことか。
2021/04/09(金) 18:51:28.05ID:3uc6Yjpo
>>797
> ちなみに Linux とかでも動くオープンソース版の .NET Core はコードページないので、UTF-8 (BOM無し)になる。

デフォルトで入ってないだけ

PowerShell on Linux(Mac)でShift-JISを扱う
https://blog.shibata.tech/entry/2016/08/22/231538
2021/04/09(金) 19:25:48.50ID:dDP8WojW
>>798
> 言語の内部コードと、外部コードの違いわかってる？
お前がわかってないのは知ってる。ソースコードの文字コードを内部コードと勘違いしてるとか
Python の内部コードが UTF-8 だと思ってるあたり素人丸出し。
Python の内部文字コードはかなり昔から UTF-32 (UCS4) だよ。それ以前は UCS2。
2021/04/09(金) 19:33:45.09ID:dDP8WojW
>>800
> デフォルトで入ってないだけ
デフォルトのエンコーディングの話してたの忘れたの？
入出力用の文字コードが切り換えできるのは当り前で、そのデフォルトが何かっていう話をしてるんだけど
2021/04/09(金) 21:16:02.60ID:ZRNzIbD0
>>801
ID:3uc6Yjpoは何を言ってるのか分からんのでほっとくとして、
Python 3.3からはメモリ使用量節約のため、latin1, UCS2, UCS4の自動切り替えな
https://www.python.org/dev/peps/pep-0393/
2021/04/09(金) 22:16:54.05ID:3uc6Yjpo
>>802
だから.NETのデフォルトはUnicodeだろ
.NETアプリが世界中の文字に対応してるってわかってますかー？
2021/04/10(土) 01:56:42.91ID:Tkmy4TcV
>>803
正確にはそうだね。
ややこしい話しても絶対ついてこれないだろうと思ったの最終的に UTF=32 に落ちるのでいいかと思って簡略化しちゃった。
そこまで、ちゃんとわかってる人がいて良かった。訂正サンクス。
レベル低いの混ると、ついついレベル低い回答になってしまう。
2021/04/10(土) 07:57:12.51ID:wS2LKV0q
.NETアプリが絵文字を表示できるのはなんで？
2021/04/10(土) 07:59:08.31ID:wS2LKV0q
WPFアプリって言ったほうが正確かな？
2021/04/10(土) 09:09:41.00ID:AcLZ31++
互換性のせいでコマンドプロンプトの仕組みが複雑だから勘違いしてるんだろうけど
コマンドプロンプト自体は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/14(水) 13:39:34.45ID:hz0wFRHA
練習
⥁⥀
⟳⟲
↻↺
⤾⤿
⤸⤹
810デフォルトの名無しさん
垢版 |
2021/04/14(水) 15:39:07.59ID:hz0wFRHA
🌍🌎🌏

サロゲ
811デフォルトの名無しさん
垢版 |
2021/04/14(水) 15:40:00.22ID:hz0wFRHA
win10
コマンドプロンプトで
chcp 65001
でも
>>810
は化けたわ
2021/04/14(水) 19:39:34.04ID:35zwdl55
>>810
Windows 10 のIEで表示できた
色はつかんかったけど
もちろんEdgeなら色付きで表示できた
2021/04/14(水) 19:47:01.17ID:35zwdl55
>>811
フォントの問題だからね
echo その文字 > test.txt とかやってファイルに書き出したら
cmd /UのUnicodeモードでUTF-16LEで問題なく保存されたよ
もちろんcmd /Aだとchcp 65001でUTF-8にしたら保存される。
2021/04/14(水) 19:49:01.33ID:35zwdl55
× フォントの問題だからね
○ 表示周りの問題だからね

データ自体は問題なく扱えるといいたかった
2021/04/17(土) 14:25:57.05ID:zVeqA+50
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.
2021/04/17(土) 15:20:55.47ID:ijYyB/Qg
>>813
/u スイッチで出力されるUTF-16LEはBOMなしなんだな
開けないエディタもあった
2021/04/17(土) 16:07:47.50ID:WTle60vg
>>815
要約：明示的に必要とされる場合以外は UTF-8 に BOM 入れるな。
2021/04/17(土) 16:17:49.74ID:WqZ6rzHC
そうでない場合は、非ASCII文字を含み、特定のプロトコルを対象としておらず、デフォルトでUTF-8を想定していない
アプリケーションで開かれる可能性のあるUTF-8テキストファイルを作成するときに、BOMを含めるようにしてください
（これは、Microsoft Windowsのように、一部のアプリケーションがテキストファイルをActive Code Pageでエンコード
することを想定している場合に有効です）。
2021/04/17(土) 19:34:14.90ID:HVVFTxep
>>816
BOMがなにか知っていれば、そんな感想はでてこないはずなんだがな

BOMっていうのは文字コードが「不明なモノ」を認識するためのものだよ
最初から「UTF-16である」と決まってるなら当然BOMはない

出力はUTF-16と決まってるのだから当然BOMは不要
それを文字コードが決まってないファイルに
出力したお前がつけるべきもの

ファイル形式によってはUTF-16と決まってる場合もあるだから
勝手につけるようなことはしない
2021/04/17(土) 19:54:12.40ID:OAsiuDOF
>>819
というか、UTF-16 における BOM って Byte Order Mark という本来の意味の方が大きいと思いますが
もっとも私はアプリ内では全部例外なく UTF-32, win32api に渡すときは UTF-16 に変換, コンテンツの外部表現は UTF-8 にしていますけれども
2021/04/17(土) 19:56:30.03ID:HVVFTxep
だから？
2021/04/17(土) 20:33:08.95ID:OAsiuDOF
>>821
BOMっていうのは文字コードが「不明なモノ」を認識するためのもの、というよりは、エンディアンを知らせるためのものでは？BOM の意義はそちらの方が優勢では？
2021/04/17(土) 22:23:07.48ID:WTle60vg
規格では
UTF-16LE はBOM付けない
UTF-16BE はBOM付けない
UTF-16 はBOM必要
これらは別物なので混同するのは良くない。
2021/04/17(土) 22:25:44.67ID:+T2toyLY
>>819
事実を明示しただけなのに、何ドヤってんだよ
2021/04/17(土) 22:30:24.80ID:WTle60vg
819はUTF-16にBOMが必要という常識すら知らない素人。
2021/04/17(土) 22:57:11.23ID:HVVFTxep
UTF-16にBOMが必要なら、なぜついてないのか説明してくれ
2021/04/17(土) 23:00:00.38ID:HVVFTxep
>>823
規格書ぐらい読みましょう
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 符号化方式のバ イ ト 順序はビ ッ グエンデ ィ ア ンです。
2021/04/18(日) 01:25:27.08ID:cX9tiBqs
ちょくちょく >>823 みたいな読解力ない人が沸くよね
なんでだろ
2021/04/18(日) 04:36:32.83ID:qeZOgBPb
要するに「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
2021/04/18(日) 07:59:39.77ID:3LjqZ5tA
ビッグエンディアンとリトルエンディアンの2つだけだよ
あとはBOMがあるかどうかだけ
2021/04/18(日) 08:08:13.68ID:cX9tiBqs
base64エンコーディングを加えればバリエーションはさらに増えるよ
よかったね
2021/04/18(日) 08:12:27.46ID:cX9tiBqs
玉子とかお新香つけたらバリエーションさらに増える
2021/04/18(日) 16:24:37.92ID:124qy3KD
>>829
五番目と最初は全く同じバイト構成になるので4種類が正解。
BOMなしの UTF-16 は実質 UTF-16BE の別名に過ぎない。
2021/04/18(日) 16:31:23.17ID:R7mD8LSe
BOMはパターンじゃなくて追加のシグネチャだよ
もしこれがHTMLだとしてUTF-8というメタタグがない場合
それはUTF-8とは別のパターンになるかと言ったらそうはならない

パターンとしては同じUTF-8であり
シグネチャがあるかどうかの違いでしかない
2021/04/18(日) 19:12:05.70ID:NuVJC4bd
BOMでこうまで話が続くのな
2021/04/18(日) 19:24:29.98ID:Qxa4OXG6
なつかしのfree論争みたいだな
2021/04/18(日) 21:03:03.56ID:pcxeaSJf
Malloc and Free
https://groups.google.com/g/fj.comp.lang.c/c/G4HRnHTdImg
2021/04/18(日) 22:24:15.55ID:Qxa4OXG6
>>837
うわなつかしい、俺のアドレスもあったw
2021/04/18(日) 22:45:16.09ID:124qy3KD
議論の理由も似てるかも
free()が必要かどうかは環境による。基本は必要最低限で使え。
BOMが必要かどうかは環境による。基本は必要最低限で使え。
というのが正しい答えだが、特定の環境のみ前提に主張するやつや、
念のためにいれておこうと考える不届き者のせいで話が混乱する。
2021/04/19(月) 00:36:54.81ID:NjT32G/K
ぜんぜん違うな。BOMはUnicodeの仕様
2021/04/19(月) 00:38:28.03ID:VxMGqS+h
>>837
俺はこれ知らんかったけど、太田・久野・河野…とそうそうたるメンバーですなあ懐かしい
2021/04/19(月) 00:41:47.58ID:NjT32G/K
昔はみんなバカだった
2021/04/19(月) 00:43:04.40ID:6sLSrXGT
>>839
それに「そもそも BOM という名前が」云々の原理主義者もお忘れなく、あー私のことか‥‥
2021/04/19(月) 01:58:51.92ID:mD3HRAYB
つまりBOMの話題はプログラマ界隈にとって爆弾のようなものだ、とこういうことか
2021/04/19(月) 03:49:32.03ID:v/IxVhS5
>>844
ミニマム・シンプルというのがプログラムの基本というのが理解できないやつがいる。
「不必要なものは入れるな」というのは最低限の知識.
2021/04/19(月) 05:11:58.25ID:krfx63YD
パーセントエンコーディングした文字列を正確にURL引数に渡すには
文字エンコーディングをサーバーに教えるためのパラメーターが別途必要になる。
だが、しかしサーバー側アプリにはBOMの情報をまるっと捨て去って平然と不具合を起こす権利がある。
文字エンコーディングをサーバーに教えるためのパラメーターと同じ役割を果たすのがBOM。
テキストエディタやコンパイラやブラウザはBOMをガン無視する権利がある。
2021/04/19(月) 09:26:00.95ID:v/IxVhS5
すっげー、面白い解釈してるな。どの規格読んだの？
URI は全体で一つの文字列なので、BOM つけるのなら最初の https: とかの前につけないと意味ないんだが？
そんな規格違反の URI に対応する必要があるという主張? それとも文字列の途中に BOM を入れて解釈しろという主張？
2021/04/19(月) 09:31:04.91ID:NjT32G/K
>>845
ギチギチしたら拡張性がなくなるだろ
2021/04/19(月) 09:32:40.01ID:NjT32G/K
不要なもの入れるな＝16bitあれば十分＝破綻ｗ
850デフォルトの名無しさん
垢版 |
2021/04/19(月) 13:35:40.29ID:v/IxVhS5
それは不要なもの入れる入れないではなくて、拡張性のある実装と拡張性の乏しい実装の違い。
unicode の文字の中には余計なものもあることは認めるが、それは関係ない。
2021/04/19(月) 13:37:50.42ID:qMbr31eM
>>850
つまりUTF-32が正解ってことでしょ？
2021/04/19(月) 15:24:44.16ID:v/IxVhS5
その辺は既に結論が出てる。
UTF-8: 可変長だが ASCII 互換。欧米の文章で長さが最短化。必要なら32bitまで拡張可能。外部コードに最適
UTF-32: 固定長。必要なら32bit分の文字まで拡張可能。内部コードに最適。
UTF-16: メリットがない。拡張性ない。オワコン。将来は特定のOSやプログラム言語やアプリで過去の遺物として残る
853デフォルトの名無しさん
垢版 |
2021/04/19(月) 16:02:17.06ID:krfx63YD
UTF-32が固定長なのはすべての文字が32bit長に収まる時期限定の話でしかない
いずれUTF-64を固定長として定義してUTF-32を可変長にせざるを得ない
そしていつの日かUTF-64も可変長になる日が来る
以後ループ
2021/04/19(月) 17:13:36.69ID:qMbr31eM
>>852
あのさ、UTF-32のBOMを無視するなよ
2021/04/19(月) 17:22:51.43ID:qMbr31eM
> UTF-8: 可変長だが ASCII 互換。欧米の文章で長さが最短化。
って言ってるのに、これが
欧米ではない文章だとUTF-16に劣るという
意味になるってわかってないのかな？
2021/04/19(月) 17:25:16.03ID:qMbr31eM
UTF-16だと2バイトですむのに、UTF-8だと3バイト必要だからな
データ量が33%増加する
2021/04/19(月) 18:49:55.06ID:v/IxVhS5
日本語の漢字かな中心の文章や、中国語の文章などでは UTF-16 の方が短かくなるけど
欧米のやつらは日本語での長さなんて気にもかけないので。もはや UTF-16 はオワコンで意見が固まってる。
欧米のやつらはラテン・アルファベットで効率が良いことと、自分たちが大量に持っている過去のASCIIの資産との互換が最優先。
日本のすみっこで、いくら叫んでも世界の流れは変えられないのだ。
少し腹立つけど仕方ない。
2021/04/19(月) 20:32:37.17ID:FUkgXBz9
WindowsやJavaの内部エンコードに使われている限り生き続けるだけだろ。日本がどうとか関係ない。

>欧米のやつらはラテン・アルファベットで効率が良いことと、自分たちが大量に持っている過去のASCIIの資産との互換が最優先。

そのマルチバイトエンコーディングからUTF-16に乗り換えたWindowsやJavaの中の人は欧米なんだが。
もしかしたらUTF-8を推したいのかもしれないけど論理が支離滅裂。
2021/04/19(月) 21:18:27.77ID:krfx63YD
U+xxxxxxxxで表現されるバイト列をRAWデータで扱うための概念としてUTF-16,UTF-32は必要とされ続ける
2021/04/19(月) 21:27:04.16ID:zdVd8UEw
合成文字があるのにいつまで固定長なんて幻想にしがみついてんだよ
2021/04/20(火) 03:31:33.46ID:CoLJETkU
これからはUTF-16の時代だって思うやつがいるんなら英語の掲示板に行ってぜひ布教してくれ。
もう世の中の流れは変わってることがわかる。昔に戻せるならやってみてくれ。
無理だと思うが、個人的には嬉しいので。
2021/04/20(火) 04:46:32.12ID:fd+AEuq4
git diff コマンドがUTF-16テキストファイルをバイナリ扱いして困る
2021/04/20(火) 08:00:32.57ID:4H0suX3D
これからはUTF-16の時代だなんて思う奴はまずいないだろうが、
これからもUTF-16の時代が続くと思う奴はいるだろう。
2021/04/20(火) 10:21:46.36ID:fKxAzJTs
欧米の奴らも絵文字は使いたがる、これはある意味いいことかも。
2021/04/20(火) 10:27:53.52ID:iwSiTlyl
>>861
これからもなにもずっと前からUnicodeの時代で
UTF-16もUTF-8もその表現の一つでしかないんだが
WindowsのAPIは柔軟だから両方に対応してるね
2021/04/20(火) 21:54:20.56ID:tx5tKo/k
U+xxxxxxxxで表現されるバイト列をRAWデータで扱うためとしても
UTF-16は桁が足りないんだからUTF-16を使っている箇所はUTF-32に移行すべき
2021/04/21(水) 18:18:57.57ID:e3R+sPu0
ASCII文字も1文字=7bitを前提にした文字の並びになっているから
1文字=8bitを前提に文字の並びを変えて
ISO646による言語別の文字の変更（バックスラッシュが円マークになる）も
廃止すればシンプルになっていいね。
ISO8859でもASCII文字の部分は何も変えなかったのは
ASCIIとISO646が普及してしまって変えられなかったから？
2021/04/21(水) 18:25:00.32ID:tWbCEelV
文字コードとフォントは別のものだから…
2021/04/21(水) 18:26:38.07ID:U7I+mJcY
過去のファイルは編集されずにずっと残るんだから古いファイルを
開くために仕様や規格を廃止することは不可能だよ
これからの話しか見えてないのは視野が狭すぎる
2021/04/21(水) 20:28:41.18ID:4tTi5uFJ
過去の文字コードってASCIIでしょ。だったらUTF-8でそのまま読めるじゃん。というのがアメリカンの発想。
ローカルなSJISなどというものは念頭にない。ASCIIに比べれば大した量ではないので変換でも何でもしろくらいに思ってる。
オープンソース系のアプリとか気の早いやつは、もうUTF-8以外のサポート切り捨てようとか本気で言い出してる。
まだ時期尚早と説得してるが、どうなることやら。
2021/04/21(水) 20:58:34.18ID:nyleF7PB
もうAltコード覚えてしまってるから勘弁して
まあ今もアプリ側でマップしてるだろうけど、文字セットの実装が失われると参照が難しくなり方言化が進む
なにより二重ループで一覧表生成出来なくなるだろうしやだー
2021/04/21(水) 21:14:40.01ID:jJZA2zpG
コードポイント=エンコードにできるはずの128-255を捨てるutf-8一人勝ちは避けたい
欧州文字セットでも記号類とか重宝する
8-bitクリーンかを気にする機会減ってきたし、新規参入の機会では
ダイアクリティカルマークは別バイトにすれば記号いっぱい詰め込めるだろ
2021/04/21(水) 21:40:19.43ID:U7I+mJcY
>>870
あのさ頭が悪いって言われるでしょ
過去のファイルの対応を切り捨てるのは現実的じゃないか
仕様や規格からShiftJISが消えることはないという話をしてるの
誰もアプリが使う文字コードの話なんかしてないの
2021/04/21(水) 21:40:20.19ID:U7I+mJcY
>>870
あのさ頭が悪いって言われるでしょ
過去のファイルの対応を切り捨てるのは現実的じゃないか
仕様や規格からShiftJISが消えることはないという話をしてるの
誰もアプリが使う文字コードの話なんかしてないの
2021/04/21(水) 21:56:14.69ID:tWbCEelV
Windows用実行バイナリの場合、システムの文字コードに依存したC言語ライブラリを使ってコンパイルされた実行バイナリが大部分だから、移行は簡単じゃないよ。
新しいライブラリにリンクするよう作り直したバイナリを再配布する必要がある。動作検証がたいへん
2021/04/21(水) 22:23:29.33ID:U7I+mJcY
>>875
例えばどんなのがありますか？
2021/04/21(水) 22:29:47.38ID:nyleF7PB
お堅くwin32API叩いて書かれたバイナリの互換性は驚異的だよな
MSが気まぐれに出しては忘れるフレームワーク叩いてたら知らんが

バイナリ配布文化を育ててしまった原因でもあるが、ここまで大事にしてきたのにエンコード対応なんかで折れてもらっては残念
win10(64bit)でoffice97が元気に動くのは誇っていい
2021/04/21(水) 23:04:31.38ID:tWbCEelV
>>876
ロケール指定する処理が省かれたC言語アプリ全般
2021/04/21(水) 23:10:54.40ID:U7I+mJcY
>>878
だからそれはどれかって聞いてる
2021/04/21(水) 23:11:26.55ID:U7I+mJcY
大部分と言う割に、事例を一個も思いつかないなら矛盾してる
2021/04/21(水) 23:20:34.30ID:tWbCEelV
Cで書かれたレガシープログラムほぼ全部なので挙げるまでもないんだけど、有名どころだとPerlだね
システムコード以外の文字を含むファイル名をperlに引数で渡せない
2021/04/21(水) 23:26:30.87ID:tWbCEelV
Cで書かれたmain()関数にはシステムコードページで引数が渡されるのだけど、その時点で文字化けしてるので復元不能。
2021/04/22(木) 09:25:25.74ID:lWdVtKH+
>>880
お前、もう少し黙っとけ。無知過ぎる。
アホを晒し続けてるの実は同一人物だろ。
2021/04/22(木) 11:05:09.03ID:24mwOh0d
このスレ読んでるとハゲそう
2021/04/22(木) 11:48:03.64ID:cA5EjL24
>>867
勿論普及してたからはあるだろうけど、そもそも変えるとかまた作り直すとかいう発想が無かったんじゃないかな。

ASCII制定→ISO 646制定→各国で変えられるのは10文字とか足りる訳無いだろ！→
ASCIIを拡張して8ビットフルに使おう→ISO 8859制定

とかそんな流れでしょ、増やして積んでけばいいと。当時のことは資料でしか知らないけどたぶん。
2021/04/22(木) 20:15:21.29ID:H07mHdZr
メールで添付ファイルを送ろうとしたらbase64でエンコードされたせいで容量オーバーした
ネットワークのトラフィックを減らすためにもメールでバイナリデータをエンコード無しで送れるのが標準化すればいいのに
887デフォルトの名無しさん
垢版 |
2021/04/22(木) 22:46:03.04ID:XWZJYEFR
いち早く国際化はずのjavaもシステムのコードページでしか引数を受け取れない制約がある
2021/04/23(金) 00:48:19.99ID:/P9+MOWj
ほんまに？
Unicode対応していながら_wmain()とかGetCommandLineW()使ってないとは信じがたいが
889デフォルトの名無しさん
垢版 |
2021/04/23(金) 01:33:18.30ID:dmQwGyWy
googleで検索したら以下ページすぐ見つかったけど、探すことさえしないタイプの人？

https://blogs.osdn.jp/2020/05/20/java-unicode.html
2021/04/23(金) 03:25:56.54ID:z5iGgWRG
Windows 専用ソフトでなくて、複数のOSに対応したソフトは当然そうなる。
特に Unix 系からの移植ならロケールをコードページに対応させるのは当たり前。
Windows独自の特殊APIで実装とか頭の悪いローカル変更は極力しない。
2021/04/23(金) 03:27:43.26ID:Apsl8RTN
というか単にC言語がASCII互換の文字コードしか
対応できないんだよな
そこは言語側の問題だと思う
2021/04/23(金) 03:29:09.72ID:Apsl8RTN
例えばJavaとかはUnicode前提で設計されてるから
当然Javaで作った複数のOS対応のソフトは
WindowsでもUnicodeが使える

これは殆どの言語に当てはまると思う
C#、JavaScript、Ruby、Python、などなど
2021/04/23(金) 03:30:29.26ID:Apsl8RTN
そういやC言語はマルチバイト対応の機能は標準化されてないんだっけ？
流石にC++は標準化されてるよな？
894デフォルトの名無しさん
垢版 |
2021/04/23(金) 04:04:31.01ID:dmQwGyWy
<locale>ヘッダがマルチバイト対応を実現してくれる
問題は誰もlocaleの機能を使ってないことだ
2021/04/23(金) 07:26:19.86ID:Apsl8RTN
おや？<locale>ヘッダとはなんのためにあるのでしょう？
使わなくても多言語対応できるのだったのでは？（苦笑）
2021/04/23(金) 09:16:27.68ID:z5iGgWRG
CがASCII互換じゃないと駄目ってどこの異世界。そんなもんコンパイラの実装次第。
規格では他の文字コードも考慮されてる。
実際 EBCDIC ですら動くやつあるのに。
2021/04/23(金) 09:17:21.12ID:z5iGgWRG
>>893
POSIX
2021/04/23(金) 13:53:41.29ID:z7/roYpD
>>896
CはASCII互換である必要はないが、
C言語文字列互換、つまり「文字列終端が\0」互換でなければならない
EBCDICはC言語文字列互換だが、UTF-16とUTF-32は互換性がない
2021/04/23(金) 22:37:45.17ID:z5iGgWRG
>>898
意味わからない。wchar はC言語とは認めない主義の人かな？
2021/04/23(金) 23:40:40.33ID:vWq/Hknp
別にnull終端文字列を使うのがスタンダードかつ標準ライブラリもそう期待しているというだけであって、好きに実装したらいいよ
ぶっちゃけ舐めないと文字列長決められないので性能がスケーラブルでないし、null文字衝突の問題もあるし筋が良くない
マトモなCで書かれたテキスト関連アプリ、特にエディタでヌル終端文字列使ってるのなんて皆無だろ
普通はrope、もう少しカジュアルならパスカルストリング
901デフォルトの名無しさん
垢版 |
2021/04/23(金) 23:42:50.22ID:hyXGjiN1
wcharω
2021/04/23(金) 23:45:37.62ID:vWq/Hknp
そもそも今時ゴミstdlib引いてC書く時点でアッて感じだし(組み込み等以外)
2021/04/24(土) 01:15:41.82ID:lum8vFBO
>>899
え？C言語の仕様にwchar_tを使うmainが無いんだからら
C言語の問題でしょうが
2021/04/24(土) 01:31:51.75ID:+S3huMNR
wmain() ってC言語じゃないの？
2021/04/24(土) 11:01:26.61ID:h7gEVqDL
>>902
Linux/Unix のプログラムはほとんど stdlib 使ってるけど、何か問題でも？
exit() とかの基本関数は stdlib にあるんだよ。
906デフォルトの名無しさん
垢版 |
2021/04/24(土) 11:04:54.55ID:fOHAtvcd
OS l17n
2021/04/24(土) 13:26:44.28ID:A8uXloOI
C言語を捨てろと言ってるんだろ
他の言語に移ったところで文字コードから逃れることはできないがな
2021/04/24(土) 15:17:08.03ID:iyr+Gwkk
>>905
アプリケーションの話
2021/04/24(土) 15:48:16.06ID:lum8vFBO
>>907
他の言語はWindowsのUnicodeにちゃんと対応してる
2021/04/24(土) 15:57:56.64ID:lkpB631F
>>893
C++はヤバすぎる
utf-8用の1B型を最近標準化したけど、まともに実装されてないし設計もユルユル
WGの中の人がサードのライブラリ引いてね発言するくらいヤバい
2021/04/24(土) 16:15:59.56ID:lum8vFBO
結局の所Unicode対応ができてないのはC/C++の言語自体と
無能なC/C++プログラマが根本的な原因なんだよな

無能なくせにクソ言語を使うなと
2021/04/24(土) 17:52:30.16ID:h7gEVqDL
OSなどの実行環境まで含めて全部をセルフ記述できる言語だけがC言語をけなして良い。
C言語の代わりになる高級アセンブラとか存在しないのが実情。
2021/04/24(土) 19:43:48.66ID:lum8vFBO
Windowsを全部セフル記述できる人だけが、Windowsをけなしていい
2021/04/24(土) 19:44:10.19ID:lum8vFBO
訂正

Windowsを全部セルフ記述できる人だけが、Windowsをけなしていい
2021/04/25(日) 01:01:32.24ID:mV4e9R8D
>>912
C言語（とその派生）が無くなると世の中のほぼ全ての言語が一緒に死ぬからなあ。
ハンドアセンブルのマシン語は残るとして他に生き残りそうなやつって何があるだろうか？
汎用機のCOBOLとかなら大丈夫か？
C言語で使えない文字コードとかあったらゴミだな。
2021/04/25(日) 09:44:53.64ID:5WfSbj4L
Lisp MachineではFortranもCもlispで書かれていたのじゃよ、もうlisp専用ハードが無いけど…
今のハードがほぼC用に設計されているというだけ
それでもソフト資産が莫大だからCエミュレータは不滅だろうが
2021/04/25(日) 12:49:28.15ID:mV4e9R8D
lispマシンは滅びたのじゃよ。
javaマシンは産まれもしなかった。
別に今のCPUがCに合わせて設計されてるわけではない。
Cのオプティマイザーが頑張って今のCPUにあわせてるだけ。
lisp で lisp コンパイラと CPU オプティマイザ書けば理論的には同じことができるはずだけど誰もしようとしないだけ。
これ以上はスレチだな。
2021/04/25(日) 13:07:14.30ID:FGclKzDI
lispマシンのタグ付き思想はBOMに近いから関係ない事もないと思う
違うのは自動でオブジェクト=型+ワードから値だけ取り出す機構が(普及して)無いところだな

動的言語がこのまま持て囃され続ければ、ハードウェアGCの可能なlispマシン風ハードが出るかもしれん、何十年後になるか知らんが
2021/04/25(日) 13:18:17.37ID:FGclKzDI
アドレス付け単位としてのバイトが8bitでは効率良く型(あるいはエンコ)情報付けるのは厳しいな
文字単位で付けると少なくとも16bitになってしまう
やっぱり36bit時代の話だね
2021/04/25(日) 13:47:52.95ID:y4+cdB21
Jazelle...
921デフォルトの名無しさん
垢版 |
2021/04/26(月) 14:21:24.82ID:REE9nEfp
lispすげーの人は夢を語りすぎ
鏡観ろ
2021/04/29(木) 14:26:38.37ID:Wx+1i7qD
やっぱりヤンキーはASCIIのことしか考えてないのか

Copying non-ASCII characters from Windows to WSLg broken
https://github.com/microsoft/wslg/issues/20
2021/04/29(木) 22:05:53.91ID:aEwK4kMw
WSLgはまだプレビュー版やろ
2021/04/30(金) 19:55:54.85ID:m/tHuDzV
ヨーロッパの人もびっくりといったところでしょうか
925デフォルトの名無しさん
垢版 |
2021/05/10(月) 21:21:31.93ID:dIUUxNIr
CP932やUTF-8で保存されたテキストファイルをバイナリエディタで見る時、
0x0Dと0x0Aは常にCR・LFに対応するという理解であっていますか

例えば"東"は以下のように保存されますが、0x0Dや0x0Aが含まれる字が存在しない事を確かめたいです。
UTF-8: e6 9d b1
CP932: 93 8c

尚、ファイルは破損しておらず、デコードできない文字は含まれていません
2021/05/10(月) 21:32:43.96ID:P0pDB+XT
>>925
WikipediaのCP932とUTF-8の記事見てみ
2021/05/10(月) 21:51:44.48ID:dIUUxNIr
>>926
ありがとうございます
難しくてわかりませんでした
2021/05/10(月) 22:22:18.55ID:ViCp850r
プログラミングのお題スレ Part18
https://mevius.5ch.net/test/read.cgi/tech/1594702426/453

UTF-8 では、先頭ニブル(4ビット)が0なのは、1バイト文字だけだから、
0x0D・0x0A は、1バイト文字だけしかない
2021/05/10(月) 22:33:39.19ID:+j6JaQYv
MSのCP932や、UTF8はASCIIの上位互換。
つまり 0x0A とかは同じ解釈でいける。
UTF16とかUTF32とかは上位互換じゃないので駄目。
2021/05/10(月) 23:26:10.90ID:P0pDB+XT
>>927
どのあたりが難しかった？ 煽りじゃなくて
2021/05/11(火) 00:05:10.05ID:0t6JOZiV
ありがとうございます

>>928
UTF-8では、0x0Dと0x0Aは常にCR・LFと対応するのですね、助かりました
CP932も同様でしょうか

>>929
アスキー文字(0x00-0x7F)のみが書かれる時、CP932もUTF-8も同じバイト列であることは知っていましたが
0x0Dや0x0Aを含む文字が存在しない事を知らなかったので質問しました
例えば「帰」はCP932だと8b 41で、0x41が含まれていますが「A」を表してはいないわけで
同様の例が0x0D 0x0Aに当てはまるのか知りたかったのです
2021/05/11(火) 00:06:36.86ID:0t6JOZiV
長すぎたので分割しました

>>930
うわ、どっちも文字がいっぱい……

UTF-8のページ
「エンコード体系」の表が関係しそうだなあ、でもよくわからんなあ。何故2進で書いたし……
今
あ、16進表記の列もあったのか。どれどれ…、あ、0x80以上なのか。じゃあ0D 0Aを含む文字はないんだなあ

CP932のページ
「構造」の表が関係しそうだなあ、でもこれはutf-8のサブセットのことを言っているのかな、それは知っているけどなあ
うーん、でも他に関連しそうな記載は見つけられないなあ
今
あ、CP932って必ず2バイトに収まるのか？そしたら第2バイトの0x00-0x3Fが未使用だから、0x0Dと0x0Aは常にCR・LFと対応すると言って良さそうだなあ
2021/05/11(火) 01:30:17.15ID:c3IDGufy
CP932に依存するコードを車輪の再発明するのはやめたほうがいい
UTF16を介して処理するのが堅実だよ
2021/05/11(火) 02:38:12.81ID:1enRFFJU
CP932だと絵文字が入ったファイル名とか扱えないからね
WindowsがUnicodeなんだからそれに従ったほうが良い
2021/05/11(火) 06:46:10.57ID:InyAS07X
>>932
わかりませんでしたって書いてたけどだいたい読めてるじゃん
「自信ないけどこう読み解きました」
「それでおｋ」
で済む(・∀・)
2021/05/11(火) 09:39:59.91ID:Gl0wmygZ
>>933
今更UTF16はないよ。中途半端なゴミ。
UTF32にするべき。じゃなければUTF8で処理する方かまし。
2021/05/11(火) 09:55:14.95ID:c3IDGufy
>>936
プログラミングやったことない人は回答しなくていいから
938デフォルトの名無しさん
垢版 |
2021/05/11(火) 10:46:32.40ID:FWZS8iTB
>>925
読み込むとき CR を無視して LF だけ読んだとき CRLF が来たものとして処理
書き込むとき CR を無視して LF だけ書き込む
これで大抵の場合うまくいく
939デフォルトの名無しさん
垢版 |
2021/05/11(火) 10:47:04.26ID:FWZS8iTB
>>925
ああすまんω
バイナリの話か
忘れてくれωω
2021/05/11(火) 15:53:24.06ID:R6EacYeM
>>937
技術的な反論ができないので、プログラムしたことがないとうレッテルを貼ってごまかそうとする。
醜いな。
941デフォルトの名無しさん
垢版 |
2021/05/11(火) 15:59:10.29ID:fJhAJw72
なんでUTF-8で全世界統一しないんですか？
2000年問題みたいにやっちゃやーいいのに
2021/05/11(火) 16:02:46.19ID:c3IDGufy
>>940
WindowsのCライブラリはUTF-32には対応してないんだよ
2021/05/11(火) 17:51:32.38ID:/14fii8B
2000年問題？
944デフォルトの名無しさん
垢版 |
2021/05/11(火) 18:03:59.53ID:jUIDYAvI
>プログラムしたことがない

話や知識がかみあってない人は描いてる内容や雰囲気で判るけどな
プログラムしたことがあっても特定の分野に疎いとか
色々勘違いして覚えてるとか知識が偏ってるとかな
2021/05/11(火) 18:12:43.26ID:c3IDGufy
ICUはUTF-16がメインだよ。ソースとか見たことないの？
946デフォルトの名無しさん
垢版 |
2021/05/11(火) 19:09:36.09ID:fJhAJw72
>>943
2000年問題の時は全世界で一斉に改修しただろ
文字コードも同様に全世界で一斉にUTF-8にすればいい
SJISとかEUCとか使ってソフトはDeprecatedに指定して
もう二年したら使えなくなるぞ、(#ﾟДﾟ) 凸ｺﾞﾙｧ!!、と伝えればすべての問題が解決
2021/05/11(火) 19:17:31.49ID:vh9Kat/q
おまえ明日から使用言語は英語な
明日まで翻訳終えられなかった日本語の文書は破棄するように
948デフォルトの名無しさん
垢版 |
2021/05/11(火) 19:31:09.73ID:fJhAJw72
>>947
OK, no problem.
However, you all have to speak in English, too.
Is that OK with you?
2021/05/11(火) 19:51:27.17ID:6D07FFeW
じゃあ二年後の正月から日本全体で電気は50Hzな
例外は認めない
950デフォルトの名無しさん
垢版 |
2021/05/11(火) 20:07:39.07ID:fJhAJw72
>>947
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.
2021/05/11(火) 20:37:23.10ID:GFoNMADL
哎呀～
2021/05/11(火) 20:47:14.11ID:vh9Kat/q
>>948
No.
I resolutely refuse to your suggestions.
2021/05/11(火) 20:49:53.68ID:HFm5gSrp
>>933
え？
UTF32 こそ正義なのではないですか？
UTF16 は、あくまでも特定用途のために UTF32 から変換して渋々使うものかと‥‥
2021/05/11(火) 20:50:48.74ID:HFm5gSrp
>>941
外に出す文字コードは UTF-8
内側では基本 UTF-32 を使うべきかと、私は考えています
2021/05/11(火) 20:52:11.20ID:HFm5gSrp
>>942
へんな言い方ですね
「Windows の C ライブラリ」ではなくて、Windows のシステムコール＝win32api というべきなのでは？

そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
2021/05/11(火) 20:55:50.64ID:HFm5gSrp
>>945
UTF-16 は Windows 等の特定用途なのでは？
むしろ正義は UTF-32 にあるでしょう
Shift-JIS や EUC は時代遅れだ、という意見には同意せざるを得ないのですが、だからといって、UTF-16 を提案するというのは、かえって悪手というか、頭が変なんじゃないかと私は考えます

そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
2021/05/11(火) 21:02:01.91ID:HFm5gSrp
>>949
50Hz は当時のドイツの会社「アルゲマイネ・エレクトリツィテート・ゲゼルシャフト」社から、
60Hz は当時の米国の会社「ゼネラル・エレクトリック」社から来ています

もし英語を第一言語に主張するのならば、50Hz ではなくて 60Hz が本流でしょう‥‥
実際、今で合衆国・カナダ・メキシコは 60Hz の国ですし
958デフォルトの名無しさん
垢版 |
2021/05/11(火) 21:41:17.35ID:fJhAJw72
>>952
No, no, no, no, ... YOU suggested first.
959デフォルトの名無しさん
垢版 |
2021/05/11(火) 21:58:18.19ID:fJhAJw72
>>954
いいですよ、UTF-32は一度も使ったことないですけど、
全世界で文字コードが統一されるなら協力しますよ。

自分はマなんですけど（って、ここにいる全員そうか）、
毎回文字コードの問題が浮上するたびに統一しろよと思ってきました。
UTF-8が出た時は「これでやっと統一される！」と思ってたら、ちっとも変わってない。
どこの馬鹿が舵切ってないんですか？
こんなもん、トップダウンでやらんと意味が無い。

蛇足だが、50Hz/60Hzも本気で統一すればいい。
地デジでアナログテレビを駆逐したんだからやれないことはない。
車の左側/右側通行も世界共通で左側通行にすべき。
2021/05/11(火) 22:01:33.58ID:62zfmCQO
Ubuntu は、UTF-32 だけど、英語圏では後半の2バイトが無駄。
メモリ使用量が、UTF-16 の2倍

だからWindows などの昔のOS は、UTF-16・サロゲートペアを使っている
2021/05/11(火) 22:28:23.04ID:HFm5gSrp
>>959
＞50Hz/60Hzも本気で統一すればいい。

無理です……
変電・配電設備はどれも 50Hz/60Hz それぞれに専用で、もう一方の周波数には対応できません
仮に 60 Hz をやめて 50Hz に統一するとすると、西日本の電気設備は全部更新しないといけません、部品が全然足りなくて、多分西日本は3年くらい停電、電気なしの生活になりますね……
2021/05/11(火) 22:29:39.96ID:HFm5gSrp
>>960
いまどき 32GiB RAM が常識な世の中で、後半の 2 バイトが無駄とかみみちいですね、そんなんじゃ駄目だ……
2021/05/11(火) 22:35:13.63ID:6D07FFeW
じゃあ明日から「円」は廃止「ドル」しか使えない
「メートル」は廃止してインチ、フィート、ヤード、マイルで
「摂氏」は廃止して華氏
「リットル」は廃止してガロン
これでアメリカと互換だぞ
便利だろ?
2021/05/11(火) 22:37:00.60ID:HFm5gSrp
>>963
国民皆保険すらない後進国にあわせるのですか？
2021/05/12(水) 00:04:08.19ID:XehBH/T/
>>962
組込み用途では相変わらず厳しい制限があるだろ
2021/05/12(水) 00:56:08.99ID:w4TAZAbA
>>959
何をいってんの？　Unicodeの目的は「これからは」単一の文字コードで
世界中の文字を表現すること
過去の資産を無くすためじゃない

それからUTF-8はな、せっかくUTF-16に統一しようとしていたのに
Unicode団体でな無い所が新たに追加した文字コードだぞ

UTF-8がでたときは「また文字コード増やしたのかよ」って思うはずなんだが
2021/05/12(水) 01:47:55.23ID:VbRrwICc
あーもー！結局次が決まらんならS-JIS使い続けようぜ！
2021/05/12(水) 02:24:31.19ID:S+EDWDjz
>>965
組み込み用途では制限が厳しいのでUTF16を使いますｗｗｗ
お前、組み込みでどれだけ文字処理してんの？
いや、UTF8やUTF32じゃ駄目でUTF16じゃんないと制限に引っかる最近の実例があったの？
あったら具体例教えてほしい。
2021/05/12(水) 02:26:01.47ID:Wqknze8k
Cコンパイラがwchar_t型をUTF16とするかUTF32とするか次第じゃね
2021/05/12(水) 02:35:18.26ID:S+EDWDjz
>>966
だってUTF16がインターネットでの使用をまともに考慮して無かったので仕方ない。
unicode以前からインターネットは既に存在していて基本ASCIIベースだったので、それの上位互換がnetで普及するのは当然の流れ。
文字数が16ビットじゃ足りないことと、インターネットの普及を予測できなかったUnicodeコンソーシアムの不見識がUTF16の原因。
2021/05/12(水) 02:49:55.29ID:Wqknze8k
UTF8を使うにしても、SJIS -> UTF16 or UTF32 -> UTF8 と変換するからやってることは同じなんだよ
2021/05/12(水) 03:26:27.16ID:rVJ0Zld2
>>970
なんで文字コードがインターネットの使用を考慮しないといけないかもわからないし
インターネットでUTF-16が使えるのに、考慮してないというする理由もわからない
もしかしてネットサーフィン（笑）をインターネットという爺かお前
2021/05/12(水) 03:27:38.25ID:rVJ0Zld2
ASCIIは7ビットなんだからUTF-8だって非対応なんだがｗ
974デフォルトの名無しさん
垢版 |
2021/05/12(水) 09:38:08.51ID:HCx7UYF5
>>959
言いたいことは判るが
君の発言はアーカイブとか文書の問題とすりかわってないか？

βのテープなんてまだあちこちにごろごろしてるだろ？
MO/MDなんかもまだあるだろ？
そのうちHDDもなくなってSSDばかりになるだろうがHDDはなくならないだろ？
新しいものはそっちで作っても古い方は面倒だから移動なんてしないだろ？
975デフォルトの名無しさん
垢版 |
2021/05/12(水) 11:26:29.20ID:rw/WEf9V
馬鹿メリカ式だと今日がこんなのになってしまう
5.12.2021
こんなの混ぜたら5月12日なのか12月5日なのか判別できずに混乱が生じる
混乱の対象となるのは各月12日までで月≠日のパターン(12*12-12=132通り)
年のうち36%もの日で混乱が生じている
馬鹿メリカ式さえ排除すれば大体うまくいくのだ
2021/05/12(水) 11:31:17.70ID:S+EDWDjz
>>973
プロトコルを拡張する時に上位互換の拡張が求められる、っていう常識すら知らないの？
まともに規格作ったり、実装したことないのかな。
一度動きだしたものは変更コストができるだけ小さい拡張が普及するんだよ。
2021/05/12(水) 20:16:47.61ID:HQn5nLJO
>>966
＞せっかくUTF-16に統一しようとしていたのに

後世の模範となる康熙字典ですら 4万7035 字が収録されているというのに、UTF-16 の 6万5536 文字のキャパシティの面では圧倒的に足りないのでは？
世の中に存在する文字、かつて存在した古代文字を全部残らず収録する、という姿勢にしては、UTF-16 は「しょぼい」としかいいようのないキャパですね…

CJK 漢字統合なんて、東洋人からみればひたすら「醜い」の一言
「UTF-16 に統一」という基本設計、あるいは基本思想の時点で既に「根本的に間違っている」と私は結論づけます

そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
2021/05/12(水) 20:17:23.50ID:HQn5nLJO
>>969
wchar_t は死産でしょう‥‥
2021/05/12(水) 20:18:07.73ID:HQn5nLJO
>>975
×馬鹿メリカ式
◎ダメリカ
2021/05/12(水) 20:22:17.19ID:zdSe0i8P
UTF-16 の最大文字数は 6万5536を遥かに超えるんだが
基礎知識がないやつとは、話にならんかな
2021/05/12(水) 20:39:17.81ID:S+EDWDjz
昔に 65536 で十分ってアホなこと言い出したやつがいたのが、今の UTF-16 っていうヘンテコ文字コードができた原因だろ。
結果は、ごらんの有様。
2021/05/12(水) 20:41:59.59ID:zdSe0i8P
UTF-8ができたのはUTF-16の後な
最初はUTF-32と同じ文字数を表現できるようにしたが
最終的にUTF-16と同じ文字数に変更した
UTF-8とUTF-16が扱える文字数は同じ
2021/05/12(水) 21:12:17.60ID:4TbGo10q
えっなにこの流れ
UTF16で扱える文字数とUTF32で扱える文字数が違うとか言い張ってる人がいるように見えるんだけど
そんなことがあるの？？
2021/05/12(水) 21:17:37.12ID:Bs1VBcWP
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と呼ばれるグループを別途設置し、そこで引き続き検討することにした。
2021/05/12(水) 21:37:03.94ID:4TbGo10q
ごめん誰か馬鹿な俺のために
(1) UTF16で表現できるがUTF32で表現できない文字
(2) UTF32で表現できるがUTF16で表現できない文字
を具体的に例示してもらえないだろうか

サロゲートペアなんてもう20年以上前には登場してたよね？
最大65536文字とか言ってる人は頭が平成１桁時代のまま取り残されてるの？

それとも、IVSや絵文字が絡むとUTF32で表現できない文字が出てきたりするんだっけ・・・？（こっちは自分が不勉強ゆえ自信なし）
986デフォルトの名無しさん
垢版 |
2021/05/12(水) 22:41:39.87ID:Be2Ur7pl
>>961
変電・配電設備だって永遠に運転できる訳じゃない。
老朽化したら修理や建て直しぐらいするから、そのタイミングで変えていけ。
一斉にやるんじゃなくて、局所的に分けて10年～15年ぐらいかけてやればいい。
その間は隣の市から電気もらうのもOK。

>>963
「円」じゃなくて基準を「金」に戻すかな。
単位に関しては世界標準無視かよ？

>>966
正直、UTF-8でもUTF-16でもUTF-32でもまったく新しい文字コードでもいいよ、統一できるなら。
何ちんたらちんたらやってんだよ？

>>967
よし、今すぐ回線切ってﾀﾋね
987デフォルトの名無しさん
垢版 |
2021/05/12(水) 22:42:55.43ID:Be2Ur7pl
>>974
βだろうがMO/MDだろうが、必要となったときに変換すりゃいいだけだろ。
少なくともその「必要となったとき」に吸い上げて変換した上で別の媒体に保存すればいい。
新しい文書は当然古い文字コードでは一切書かせてはいけない。
SJISなんぞ使った日にゃ秘密警察が見つけ出して206個ある骨をすべて砕く刑に処す。

>>975
その指摘は正しい。
ただ、一番正しい日付の表示法はヨーロッパ式で、
次に正しいのはお前が指摘しているアメリカ式で、一番馬鹿なのが日本式。

>>982
正確に数字で話せ。
で、真面目な話になるが、その中で最長の文字数を扱える文字コードはどれだ？
その最長の文字数でこの世のありとあらゆる文字は表現できるのか？
また、その最長の文字数を扱える文字コードだとデータ処理は遅くなってしまうのか？
2021/05/12(水) 23:15:30.39ID:UT6XyfGi
ISO8601よりヨーロッパ式を推すとはたまげたなあ
2021/05/12(水) 23:28:53.01ID:LpmPGSmH
場末の掲示板の場末の板でイキってるんだから可愛いよね
2021/05/12(水) 23:30:48.38ID:S+EDWDjz
>>982
>UTF-8ができたのはUTF-16の後
それ何のジョーク？
UTF−16(サロゲートペア)方式が公開されたのは UTF−8 方式の4年後なんだが。
2021/05/13(木) 00:55:59.37ID:bi8pzl4S
>>978
C++のcwcharヘッダーからもわかるとおり、wchar_tは規格の一部
2021/05/13(木) 05:07:38.90ID:nrtxeueq
>>990
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を作った
2021/05/13(木) 09:13:48.13ID:jPZ0z7Tj
で、どこに 16bit の "UTF" って書いてあるの？
勝手に UTF を補完すんな。その頃は UTF-16 はまだ存在してない。
994デフォルトの名無しさん
垢版 |
2021/05/13(木) 11:09:24.10ID:0pD51twu
>>988
ああ、ISO8601よりもヨーロッパ式の方が断然いい
なんだ、その理由も分からないのか？
995デフォルトの名無しさん
垢版 |
2021/05/13(木) 11:13:36.80ID:0pD51twu
>>989
場末の掲示板の場末の板で呟いているお前の方がよっぽど可愛いわ
せめて俺に直接レスしたらどうだ、この臆病者がｗ
2021/05/13(木) 13:46:00.24ID:oT9LP7EK
成立順
UCS-2(かつてのUnicode)→UCS-4→UTF-8→UTF-16→UTF-32
ってことかな？訂正よろ
997デフォルトの名無しさん
垢版 |
2021/05/13(木) 13:51:48.50ID:pHijDXLB
>>980
そのせいで shift_jis と同じ失敗を繰り返した訳だ
2021/05/13(木) 14:28:18.42ID:oT9LP7EK
>>997
同じ失敗って何？
shift-jisみたいに2文字目の判定に時間がかかったり読み違えたりする可能性はないと思うけど
2021/05/13(木) 14:49:45.53ID:jPZ0z7Tj
>>996
その書き方だと UCS-4 == UTF-32 かな。
正確には UCS は符号化文字集合で UTF は符号化方式だけど。
2021/05/13(木) 14:57:26.65ID:aKG1Dap7
文字コード総合スレ part13
https://mevius.5ch.net/test/read.cgi/tech/1593777227/
10011001
垢版 |
Over 1000Thread
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 877日 22時間 9分 2秒
10021002
垢版 |
Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況