文字コード総合スレ part14

**デフォルトの名無しさん** · 2023/03/03(金) 15:46:58.08

Windows NTは初代からUnicodeがネイティブの文字コードです。cp932ではありません。
プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
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 https://mevius.5ch.net/test/read.cgi/tech/1516629503/
文字コード総合スレ Part12 https://mevius.5ch.net/test/read.cgi/tech/1544931495/
文字コード総合スレ part13
https://mevius.5ch.net/test/read.cgi/tech/1593777227/

**デフォルトの名無しさん** · 2024/02/09(金) 01:44:08.30

単にUNICODE非対応なだけでは？
新しくても英語圏のソフトだとだめなのもありそう

**デフォルトの名無しさん** · 2024/02/11(日) 18:02:55.68

↵の改行マークは下に行ってから左に行くから
LFCRを表しているように見えるが改行コードがLFCRの機種は無いんだよね
CRLFなら左に行ってから下に行く┏のようなマークにするのが正しいのではないだろうか

**デフォルトの名無しさん** · 2024/02/11(日) 18:42:08.50

リターン(enter)キーに印字されてる記号との兼ね合いもあるだろうし

**デフォルトの名無しさん** · 2024/02/12(月) 19:50:05.96

プリンタ端末が遅いから、本当はLFCRだけど、CRを先に送出したんじゃなかったけ？

**デフォルトの名無しさん** · 2024/02/12(月) 20:47:13.82

もともとは、タイプライターの動作から来てるからな。

文字をタイプして行末まできたら、送りレバーを右に動かすんだけど、
まず、レバーを押した瞬間に紙を送るドラムが回転して行送り（Line Feed）、
そのままレバーを送ればドラムの載ったキャリッジが右側に移動する（Carriage Return）。
（LFなしのCRのみの動作も可能なモードもある）

この2つを合わせたLFCRが本来の形で、
↵が改行マークなのはこれが影響していると思われる。

改行コードでCRLF（\r\n）になった経緯は、>>545 ということみたいだね。

**デフォルトの名無しさん** · 2024/02/13(火) 05:49:18.51

正規表現だと/nがLFだけではなく改行全般(CR/CRLF/LFの全て)を指している場合があるよね

**デフォルトの名無しさん** · 2024/02/13(火) 20:51:09.58

>>541
WindowsはSJISとUTF-16の世界だからな。

**デフォルトの名無しさん** · 2024/02/14(水) 02:41:15.71

いやWindowsはsjis残ってるけどmultibyteはもうutf8が主流と言っていいでしょ

**デフォルトの名無しさん** · 2024/02/14(水) 13:25:50.83

>>549
WindowsはデフォルトがUTF-16だから、BOMがないとUTF-8をUTF-16として扱うことが多い。

**デフォルトの名無しさん** · 2024/02/14(水) 14:21:18.91

BOMってことは交換用データの話だとおもうけど
だいぶ前からUTF-8推奨じゃね？
内部データとは別の話

**デフォルトの名無しさん** · 2024/02/14(水) 19:34:50.64

最初APIの話で当然内部コードの話だったんだけど違う話はじめたからな

**デフォルトの名無しさん** · 2024/02/15(木) 18:14:47.71

>>551
Windowsそのものの話

**デフォルトの名無しさん** · 2024/02/17(土) 21:31:39.77

絵文字同士を結合した文字はOSによっては結合して表示されないから新たな機種依存文字になってるよね

**デフォルトの名無しさん** · 2024/02/17(土) 21:49:18.90

機種？

**デフォルトの名無しさん** · 2024/02/18(日) 00:28:41.00

文字幅が実行時にやってみないと確定しないのはマジで困るし非効率すぎるよな

**デフォルトの名無しさん** · 2024/02/19(月) 14:52:55.18

市民への郵送物、JISコード外の氏名が文字化け　さいたま市が謝罪
https://www.itmedia.co.jp/news/articles/2402/19/news091.html

発送した12万通のうち4438通で、JIS規格の文字コードに含まれない外字を含む氏名について、正しい漢字が適用されなかったという。

対象の郵送物は「さいたま市物価高騰対応重点支援給付金のお知らせ」。

給付金に関する事務を受託している事業者が、外字を適正に印字する設定を誤ったため文字化けが起きたという。

**デフォルトの名無しさん** · 2024/02/19(月) 15:01:56.94

書き間違いで大量に発生したニセ漢字は今後使用禁止とするのがいいのかな
外字も必要なくなり皆がハッピー

**デフォルトの名無しさん** · 2024/02/19(月) 15:09:57.93

文字化けと言っても記号列の様な感じじゃなく中華フォントになったのだろう
普段から一部の粗悪アプリで中華フォントを見させれれてる弊害だな

**デフォルトの名無しさん** · 2024/02/19(月) 15:17:29.77

外字とあるから
書き間違いで戸籍などに登録された、
書き間違いニセ漢字のことだと思うよ

**デフォルトの名無しさん** · 2024/02/19(月) 15:31:19.40

Unicodeも振られていない「外字」が4%弱の人名に使われてるとは思わないけどね
どうなの？

**デフォルトの名無しさん** · 2024/02/19(月) 16:04:50.11

> 2月9日（金曜日）に委託事業者から納品された通知を、郵便局に差し出すために仕分けをしている際に、
> 市職員が外字が正しく適用できていない通知を発見したことで覚知しました。

記号列(◇の中に？等)タイプだと委託業者や印刷所が気が付く可能性が高いから
ワタナベやサイトウ等のIVSを反映してなかった、と言う可能性はあるかも
チェックした職員はGJだな、普段から外字を気に掛けてるのだろう

**デフォルトの名無しさん** · 2024/02/19(月) 16:29:42.83

右から左に字を書く文化圏でもBackSpaceやEnterキーの矢印は右から左なんだよね

**デフォルトの名無しさん** · 2024/02/20(火) 00:03:22.85

そりゃそうだろうよ

**デフォルトの名無しさん** · 2024/02/20(火) 08:17:36.44

>>563
え? 某OS上の某キーボードの中の人だったが、逆向きにしたぞ
UIは基本的に左右が逆
あと、括弧や不等号を入力すると逆向きになったりする
おかげで一時期頭がアラビア語脳だった

しかし、日本も戦争に負けなければ「右から左に文字を書く文化圏」なんて
他人事じゃなかったはず
アメ公のせいじゃけんのう。くやしいのう

**デフォルトの名無しさん** · 2024/02/21(水) 00:09:55.88

あれ、でも実はそうかな?
念の為、競合の某大手のもチェック.... OK,、仲間発見。
焦るじゃないか。いい加減なこと言うんじゃない

**デフォルトの名無しさん** · 2024/02/21(水) 00:24:01.03

ああ、OSによってはリターンキーのデザインとかキーボードの言語でなく
UIの言語で決めていたのもあったような気がするな
くそっ、俺にとって今はどうでもいい事なのに気になるじゃないかw

**デフォルトの名無しさん** · 2024/02/23(金) 13:32:00.44

>>565
>あと、括弧や不等号を入力すると逆向きになったりする
>おかげで一時期頭がアラビア語脳だった

頭がパニックになりそう
頭脳パズルで使える

**デフォルトの名無しさん** · 2024/02/23(金) 14:11:14.91

文字は右から左だけど、数字は左から右だったような
日本語で表現すると「すーまりいはータッリ30ンリソガ」みたいな感じ

**デフォルトの名無しさん** · 2024/02/23(金) 14:21:21.57

数字をリトルエンディアンで表記していると考えると自然。

**デフォルトの名無しさん** · 2024/02/23(金) 23:20:37.86

日本語は中国語と同様に元々縦書きで右から左に行が移る言語なので、横書きした場合は右から左に書いていた。1行の長さが1文字になったみたいな感覚だ。だから戦前戦中は横書きというと右から左に書いてあるのが多い。
これが左から右の英語と同じようにした理由は戦後英語から翻訳した文を下に書く時に見易いから。

**デフォルトの名無しさん** · 2024/02/23(金) 23:36:24.87

左から右の横書きは戦後ではなくそれよりもずっと前からだよ
あくまで右から左がなくなったのが戦後というだけの話

**デフォルトの名無しさん** · 2024/02/24(土) 21:11:27.48

縦書きと横書き
https://ja.wikipedia.org/?curid=329702

**デフォルトの名無しさん** · 2024/02/25(日) 21:12:56.55

>>569
「ガソリン30リッター」の部分が英語だとしたら、そこは左->右なので
「すーまりいはガソリン30リッター」としなければならない

**デフォルトの名無しさん** · 2024/02/25(日) 23:52:14.62

>>574
アラビア文字のおハナシ

**デフォルトの名無しさん** · 2024/02/27(火) 11:38:12.52

>>575
もちろんそうですが何か? というか右->左の言語一般かな。ヘブライとかも

難しいのは言語の境界で、例えば「ガソリン30はいりまーす」だとして、
「ガソリン」が英語、「30はいりまーす」が日本語（右->左）だと思えば
「すーまりいは30ガソリン」となるが、「ガソリン30」で区切れると判断してしまうと
「すーまりいはガソリン30」と、違う結果になってしまう
あるあるだよね～

**デフォルトの名無しさん** · 2024/02/27(火) 14:32:58.93

縦日
に本
書語
けな
　ら

**デフォルトの名無しさん** · 2024/02/28(水) 01:29:44.98

MS-IMEのせいで丸印が、漢数字の零(ゼロ)に置き換わってしまった。
日本マイクロソフトは常に中国人に日本語を担当させているから、取り返しのつかない事態になってしまった。

**デフォルトの名無しさん** · 2024/02/28(水) 15:41:15.50

嘘も百回言えば真実となるってやつか

**デフォルトの名無しさん** · 2024/02/28(水) 19:33:10.15

漢数字はフォントによっては真円じゃないからな。
潰れた丸印だと何これと思う未来がみえる。

**デフォルトの名無しさん** · 2024/03/05(火) 01:45:14.40

区切り文字としてHorizontal Tabは使われているが
Vertical TabはTSV形式でも使われていないよね
他にも0x1C-0x1FのFS GS RS USも区切り文字として想定されているのに使われていない

**デフォルトの名無しさん** · 2024/03/05(火) 18:49:24.75

oO0◯○。゜❍〇⁰

**デフォルトの名無しさん** · 2024/03/07(木) 05:14:15.03

UTF-8で記号がたくさん登録されてしまったのも問題だよな

ハイフンのような横棒は種類がたくさんあって、文字フォントの見た目では区別できなようなものもある。

**デフォルトの名無しさん** · 2024/03/07(木) 16:55:28.90

それよりもはるかに深刻なのはスペースに見える文字がたくさんあって
スペースを取り除くプログラムを書くのが不可能に近い

**デフォルトの名無しさん** · 2024/03/07(木) 17:41:11.51

\s \p{Zs}以外は知りませんではダメ？

**デフォルトの名無しさん** · 2024/03/08(金) 17:23:14.35

>>584
近いだけで不可能ではないので大丈夫

**デフォルトの名無しさん** · 2024/03/09(土) 19:20:37.58

Unicodeの正規表現でいける?

**デフォルトの名無しさん** · 2024/03/09(土) 20:38:58.52

正規表現じゃ無理に近い
素直にブラックリストです

**デフォルトの名無しさん** · 2024/03/09(土) 21:24:45.91

>>587
正規表現はASCII文字くらしか想定していないが、UTF-8のASCII文字限定であれば問題ない。

**デフォルトの名無しさん** · 2024/03/09(土) 23:16:58.67

UnicodeProperty「...

**デフォルトの名無しさん** · 2024/03/10(日) 02:07:22.30

まだこんなレベルが複数いるとはな
585はなんだとおもってるんだろうか

**デフォルトの名無しさん** · 2024/03/15(金) 23:58:29.83

FS GS RS USを区切り文字にしている形式はあるんだろうか

**デフォルトの名無しさん** · 2024/03/16(土) 12:13:18.07

文字列の１６進コードでも正規表現できればわかりやすくなる
何語でもよくなる

**デフォルトの名無しさん** · 2024/03/16(土) 13:00:35.09

わかりやすいか？

**デフォルトの名無しさん** · 2024/03/22(金) 23:58:21.79

Unicodeのコードポイントが7FFFFFFFではなく10FFFFまでになったのはUTF-16で表せるのが10FFFFまでだから？

**デフォルトの名無しさん** · 2024/03/23(土) 00:18:21.28

>>595
>>7FFFFFFFではなく

その前提はどこから来たのやら...

**デフォルトの名無しさん** · 2024/03/23(土) 01:10:47.92

>>596
UTF-8 で表現可能な上限が 0x7fffffff だな。
UCS-4 すなわち UTF-32 だと 0xffffffff
UCS-2 だと 0xffff
UTF-16 の上限に合わせているというの合ってる。

**デフォルトの名無しさん** · 2024/03/23(土) 02:34:19.03

微妙にかみあってなくて笑う

**デフォルトの名無しさん** · 2024/03/23(土) 07:47:34.76

仮にUTF-8のビットパターンで1バイト目に11111111を使っていいとしたら
その後は10******が8バイト続くことになり48bitまで表現できることになるね

**デフォルトの名無しさん** · 2024/03/23(土) 09:10:32.39

>>593
マルチバイト文字に [] が使えなくて | で書かなきゃならんから少し面倒にはなるな。

**デフォルトの名無しさん** · 2024/03/23(土) 11:39:26.85

>>599
未定義なので定義次第。6バイトの次が7バイトや8バイトは限らないので10バイトとか定義すればそのまま64ビットをカバーすることできるし、拡張の余地は残してある。

**デフォルトの名無しさん** · 2024/03/24(日) 09:08:35.50

>>595
当初UCS-4は最上位ビットをエスケープなどの用途に使い
それを除いた7FFFFFFFまで使用可能にする計画だったはず
しかしUnicodeの上限が10FFFFと決まったためにUCS-4もそれに合わせて10FFFFになったのでは

**デフォルトの名無しさん** · 2024/03/30(土) 15:01:07.51

C: \のようにディレクトリの区切りが円マークなのは文字化けの結果なんだよね
C:\のようにバックスラッシュが本来の文字なのに
円マークの方が見慣れていてバックスラッシュだと違和感を感じてしまう
なぜディレクトリ区切りにスラッシュではなくバックスラッシュを採用したんだろうか

**603** · 2024/03/30(土) 15:05:16.11

603の1行目でC:の後に0xA5を入れたらバックスラッシュになってしまった・・・

**デフォルトの名無しさん** · 2024/03/30(土) 15:07:21.72

別に文字化けでもないでしょ
バクスラなのはオプションがスラッシュだから

**デフォルトの名無しさん** · 2024/03/30(土) 15:16:04.30

Win32のファイル関連APIはスラッシュでOK
NT APIを直接使う時にはスラッシュはNG
GUIコントロール、ダイアログなどで独自処理してる箇所はスラッシュの考慮漏れ多数

**デフォルトの名無しさん** · 2024/03/30(土) 16:10:17.92

Windows のRuby では、/ も使う。
C:/Users/Owner/Documents/a.txt

WSL2, Linux なら、/mnt/c/ とか
/mnt/c/Users/Owner/Documents/a.txt

**デフォルトの名無しさん** · 2024/03/31(日) 00:46:19.56

C:\Users\Owner/Documents/a.txt なんてのが OK な処理系もあるな

**デフォルトの名無しさん** · 2024/03/31(日) 01:53:54.19

処理系というかDOS/WindowsならOSがそうなってる

**デフォルトの名無しさん** · 2024/03/31(日) 06:08:53.00

>>603
UNIXの真似したかったんだけど同じにしたくなかったんじゃね？

**デフォルトの名無しさん** · 2024/03/31(日) 07:10:21.54

ゼロは、〇とか０とか0もいいけど、ぼくはΘが僕はスキです。

**デフォルトの名無しさん** · 2024/03/31(日) 07:11:47.66

ディレクトリ区切り　は、>　が、ボクは、好き❦❤♥

**デフォルトの名無しさん** · 2024/03/31(日) 07:25:21.69

もともとDOSはCP/Mの互換OSでディレクトリは無かった。で新バージョンで UNIX 等を真似てディレクトリを導入しようとしたんだけど、その時点で / はオプションの導入記号として使用済みだったので仕方なく \ を使った。単なる歴史的経緯。

**デフォルトの名無しさん** · 2024/03/31(日) 14:18:23.86

DOSはSWITCHARをコマンドでオプションの記号を/から-に変えられたようだが
Windowsにも同じ機能はあるんだろうか？

**デフォルトの名無しさん** · 2024/03/31(日) 16:22:56.09

>>614
config.sys に書くやつなので同じのはないな。
一方で windows の内部API は \ だけじゃなくて / もディレクトリ区切りとして受け付けるというか、むしろ内部的には / に統一なのでDOS互換の目的以外でオプションに / を使う意味はない。

**デフォルトの名無しさん** · 2024/04/02(火) 21:41:53.85

Windowsのパス区切り文字は、なぜ逆スラッシュになったのか？
https://ascii.jp/elem/000/001/763/1763591/

**デフォルトの名無しさん** · 2024/04/03(水) 09:15:12.66

2018年の記事でこのネタを扱って「この事実が開発者の間に広く知られるようになったのはここ数年ぐらいのこと」と書いちゃうの
筆者さんのお年頃を感じるわ

**デフォルトの名無しさん** · 2024/04/03(水) 15:47:23.50

Windowsは長いパスを想定していないなど、いまさらどうにもならない部分はたくさんあるからなあ。

**デフォルトの名無しさん** · 2024/04/03(水) 15:47:57.80

正確には長いシステム文字列だけど

**デフォルトの名無しさん** · 2024/04/05(金) 09:39:34.21

Windows 10 バージョン 1607 以降で長いパスを有効にする
https://learn.microsoft.com/ja-jp/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later

**デフォルトの名無しさん** · 2024/04/06(土) 02:00:07.31

システムそのもののことを書いたんだけどな

**デフォルトの名無しさん** · 2024/04/06(土) 02:00:42.72

Windowsそのものは互換性の維持から変えられない

**デフォルトの名無しさん** · 2024/04/06(土) 06:49:25.04

いい加減消えろよ荒らしかなんかなのか?

**デフォルトの名無しさん** · 2024/04/08(月) 00:02:59.85

Windowsだと日本語のパスを普通に扱うから、UTF-8のストレージからコピーしたものなどは、キャラクタセットの問題で同じファイルと認識されないことがある。

**デフォルトの名無しさん** · 2024/04/08(月) 00:06:46.79

robocopyコマンドなどは日本語の濁点文字を変換できないので、Macなどから持ってきたファイル、フォルダなどをWindowsは正確に置き換えられず、新しい別のファイルだと判断してしまう。

**デフォルトの名無しさん** · 2024/04/08(月) 06:23:54.81

Unicodeの正規化の問題はマカーでもMacが変だとおもってるから
zipとかを客に要求されたときは気を使ってる
俺はスクリプトでアーカイバ書いた

**デフォルトの名無しさん** · 2024/04/09(火) 20:36:20.01

UTF-8は同じ記号を二重に定義したりと迷惑極まりない

**デフォルトの名無しさん** · 2024/04/09(火) 20:39:38.16

日本語のフォルダ名、日本語のファイル名、半角スペースが入っているパスなどは、やはりキャラクタセットの問題、区切り文字と誤認識したりと日本語を使う弊害があるから、MacユーザーはWindowsでも問題ない名前にしてくれないと無用なトラブルを起こす。

**デフォルトの名無しさん** · 2024/04/09(火) 21:34:31.96

>>628
そんなこと言うとマックユーザーは濁点や半濁点が禁止になるぞ？！

**デフォルトの名無しさん** · 2024/04/09(火) 21:45:35.69

>>629
UNIXで日本語を普通に使っている時点で問題があるのにな
Macユーザーは知識のない人間が多いのは事実だし、シェアが低いのにMacの方が売れているかのような嘘を話す。

**デフォルトの名無しさん** · 2024/04/09(火) 22:14:36.89

昔は句点にしったかはいなかったのに時代かな

**デフォルトの名無しさん** · 2024/04/10(水) 01:10:50.60

句読点話とか昔から議論があって、国とマスコミが合わせている話を最近の話だと思っているのは、ネットの捏造話題に振り回されすぎだw

**デフォルトの名無しさん** · 2024/04/10(水) 17:32:28.51

大文字と小文字の使い分けで問題が出るので

**デフォルトの名無しさん** · 2024/04/15(月) 15:11:19.52

改行コードは、LF CR LF＋CR どれが間違えなのか統一しろっつうの

**デフォルトの名無しさん** · 2024/04/15(月) 20:58:18.76

>>634
その前提が間違っています

**デフォルトの名無しさん** · 2024/04/16(火) 01:11:44.84

>>634
迷ったときはとにかくBOMなしUTF-8でLFにしろ

**デフォルトの名無しさん** · 2024/04/17(水) 05:36:29.22

>>636
Windowsの知識がないのか？

**デフォルトの名無しさん** · 2024/04/17(水) 05:37:28.83

WindowsはBOM付きじゃないとUTF-16だとみなすことが多い。

**デフォルトの名無しさん** · 2024/04/17(水) 06:30:22.24

>>636
正解
それで世界標準が確立した

**デフォルトの名無しさん** · 2024/04/17(水) 18:58:24.59

>>638
そりゃあWindowsはそう判定するかもしれんけどな
普通はWindows上で動作するアプリの方にファイルを食わすんよ
そんでそのデファクトがBOMなしLF UTF-8って寸法さね

**デフォルトの名無しさん** · 2024/04/17(水) 23:38:18.72

Windows なら BOM 無し CRLF UTF8 ではないかと思う
どっちみちアプリ専用なら決め打ちだろうしな
自動判別が必要なものなんてテキストエディタくらいだろう