文字コード総合スレ 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/

**デフォルトの名無しさん** · 2023/03/12(日) 16:18:15.25

>>111
レイヤの区別をできない素人かよ

**デフォルトの名無しさん** · 2023/03/12(日) 17:11:02.31

Windows の改行コードが 0D0A なのはMSDOS の名残
C言語の \n は1バイトなのだが，これを2バイトでも処理できるように
苦し紛れに作ったモードがテキストモード

**デフォルトの名無しさん** · 2023/03/12(日) 21:43:16.22

Why is the line terminator CR+LF?
https://devblogs.microsoft.com/oldnewthing/20040318-00/?p=40193

This protocol dates back to the days of teletypewriters. CR stands for “carriage return” – the CR control character returned the print head (“carriage”) to column 0 without advancing the paper. LF stands for “linefeed” – the LF control character advanced the paper one line without moving the print head. So if you wanted to return the print head to column zero (ready to print the next line) and advance the paper (so it prints on fresh paper), you need both CR and LF.

If you go to the various internet protocol documents, such as RFC 0821 (SMTP), RFC 1939 (POP), RFC 2060 (IMAP), or RFC 2616 (HTTP), you’ll see that they all specify CR+LF as the line termination sequence. So the the real question is not “Why do CP/M, MS-DOS, and Win32 use CR+LF as the line terminator?” but rather “Why did other people choose to differ from these standards documents and use some other line terminator?”

Unix adopted plain LF as the line termination sequence. If you look at the stty options, you’ll see that the onlcr option specifies whether a LF should be changed into CR+LF. If you get this setting wrong, you get stairstep text, where

each
　　line
　　　　begins

where the previous line left off. So even unix, when left in raw mode, requires CR+LF to terminate lines. The implicit CR before LF is a unix invention, probably as an economy, since it saves one byte per line.

**デフォルトの名無しさん** · 2023/03/12(日) 22:44:50.34

こんなスレにおるのはほぼオッサンなんだけど
キミに学びがあったのならよかった

**デフォルトの名無しさん** · 2023/03/12(日) 22:58:02.67

最後の方の Unix の記述は間違いだな。ちゃんと調査せずに適当な風説を元に回答したようだ。

**デフォルトの名無しさん** · 2023/03/12(日) 23:20:28.70

1) 大昔の teleprinter/teletypewriter では CR+LF で改行にしていた。違うのもあった。
2) それを引き継いでビデオ端末の多くが CR+LF を改行にしていた。違うのもあった。
3) デバイスに直接出力していた古いOSや、OS無しの低機能のシステムではデバイスの多数派に合わせて CR+LF を改行コードにした。
4) Multics ではデバイス・ドライバーで出力先デバイスに合わせて改行処理を変更する機能があるので、デバイスに依存しない抽象化された文字コードを採用することにした。
5) このときに、当時の ISO 646 のドラフトにおいて LF だけで改行とできる規定があったので、それを採用した。
6) unix はこの Multics の仕様を引き継いだ。
#）一方で CP/M はデバイス・ドライバーによる抽象化などの高度な機能は無かったので、CR+LF を改行コードにするしかなかった。MS-DOS および MS-Windows はこの仕様を引き継いだ。

**デフォルトの名無しさん** · 2023/03/13(月) 03:18:43.79

>>113
タイプライターの名残やろ

**デフォルトの名無しさん** · 2023/03/13(月) 09:07:24.07

CP/Mのパクリをしなければ改行にCR+LFを採用する必要はなかった
まあこのパクリのおかげでCP/M86に勝ったんだけどね

**デフォルトの名無しさん** · 2023/03/13(月) 11:13:13.34

レトロmac: "CR" ぼくも忘れないで

**デフォルトの名無しさん** · 2023/03/13(月) 13:38:04.06

>>120
お前は深く考えてない玩具 Apple II の文字コード継承しただけじゃないか？正直に白状したまえ。

**デフォルトの名無しさん** · 2023/03/13(月) 14:36:51.97

Macはワンボタンが素晴らしいと思ってるし、画面下にアプリ切り替えバーなんていらないし、UNIXなんてクソだからCRを使った

**デフォルトの名無しさん** · 2023/03/13(月) 21:35:59.50

CRはCarriage Returnで行頭に復帰
改行はしない

**デフォルトの名無しさん** · 2023/03/13(月) 22:29:34.49

それ端末の動作だし
だからなんやねん

**デフォルトの名無しさん** · 2023/03/14(火) 16:02:14.81

読むときは CR(単独) が来ようが CR+LF(連続) が来ようが LF(単独) が来ようが LF として処理する
描くときは LF のみ描き込む
これが正しい在り方

**デフォルトの名無しさん** · 2023/03/14(火) 17:57:34.43

問題はCRとLFとCRLFが混ざっているときだ

**デフォルトの名無しさん** · 2023/03/14(火) 19:20:49.37

LF, CR, LF, LF, LF, CR ときたら何行改行するか問題。
CR+LF 派にこれを突きつけると、言行がバグる人が多い。CR+LF派は脳に欠陥があるに違いない。

**デフォルトの名無しさん** · 2023/03/14(火) 19:52:03.66

>>127
LRの次がCRだったら無視する（読み飛ばす）
CRの次がLFだったら無視する（読み飛ばす）
で問題なし

**デフォルトの名無しさん** · 2023/03/14(火) 19:53:53.28

CRLFで1回、CRで1回、LFで1回だろ？

**デフォルトの名無しさん** · 2023/03/14(火) 20:20:53.43

LF派：誰に聞いても同じ回答を返す
CR+LF派：人によって回答が違う。謎のオレオレ理論を説明しだす
CR派：問を無視してアップルへの恨み言を言い始める

**デフォルトの名無しさん** · 2023/03/14(火) 20:23:34.83

BOMは諦めて今度は改行かね

**デフォルトの名無しさん** · 2023/03/14(火) 20:27:00.01

>>131
ﾜﾛﾀ

**デフォルトの名無しさん** · 2023/03/14(火) 23:03:37.37

CRは先頭位置に戻す
LFは行替え
だから>>127は4行改行して先頭位置になる

**デフォルトの名無しさん** · 2023/03/14(火) 23:25:04.85

>>133
本来はそんなんだけど
タイプライターで打つときにそれだと二動作必要になるので
一動作でcr+lfにするようにした
これが混乱の始まりかも

**デフォルトの名無しさん** · 2023/03/15(水) 01:01:29.12

>>133
つまり先頭位置にある時には CR は不要で LF だけで改行すべきで、
毎回 CR+LF を出力している某OSは無駄と言いたいの？
それでは CR+LF 派とは言えないよな？

**デフォルトの名無しさん** · 2023/03/15(水) 02:30:17.71

HTTPプロトコルは改行がCR+LFなのはどうして？

**デフォルトの名無しさん** · 2023/03/15(水) 04:53:01.78

>>136
まじめに答えると、
SMTPなどの既存のプロトコルを参考にしたから。
で、SMTPがCRLFなのは、インターネット以前の汎用機とか使ったメールシステムとの相互接続性に気を使ったから。
実際のHTMLは場所によってLFだけやCRだけの改行も許されていてかなり複雑なんだが。

**デフォルトの名無しさん** · 2023/03/15(水) 11:00:18.93

ほー、ってことはWindowsも
そういった互換性を大切にしてたんだな

**デフォルトの名無しさん** · 2023/03/15(水) 11:12:26.56

むしろ>>127なんて通常はあり得ないって事さ

**デフォルトの名無しさん** · 2023/03/15(水) 12:41:20.81

>>138
まあ、そうだな。
Windows が大事にしたのは MS-DOS との互換性で、
MS-DOS が大事にしたのは CP/M との互換性で、
CP/M は大昔の汎用機と同じくらい古臭い<BS><BS><BS>シンプルな設計だったというだけだな。

**デフォルトの名無しさん** · 2023/03/15(水) 22:20:01.44

UNIXは元々研究用だからね
互換性なんか考えちゃいない
だからUNIXはBSD系とSystemV系に分離した
多くのコマンドの互換性がなくなった

**デフォルトの名無しさん** · 2023/03/16(木) 00:21:30.90

>>141
歴史をまったく知らない素人妄想だな。
Multics で導入されたテキストデータの抽象化とか知ってるか？

**デフォルトの名無しさん** · 2023/03/16(木) 03:57:32.72

http2以降はヘッダに改行なくなったんだね、、、

**デフォルトの名無しさん** · 2023/03/16(木) 07:48:28.62

>>141
多くのコマンドの互換性ってたかだかオプションが違うくらい
シェルスクリプトでどのバージョンでも対応できた

**デフォルトの名無しさん** · 2023/03/16(木) 10:25:24.39

>>142
知ってる。お前のターン。
俺を論破してみせろやｗ

**デフォルトの名無しさん** · 2023/03/16(木) 10:25:51.36

>>144
歴史を知らんのねｗ

**デフォルトの名無しさん** · 2023/03/16(木) 10:41:46.04

知ってる→実は何もわかってない
知らんのかね→自分が何も知らない
どうして、こういう知ったかぶりする小学生みたいんな奴が混ざってるんだろう？

**デフォルトの名無しさん** · 2023/03/16(木) 10:46:31.88

コマンドラインにプログレスバーを出したり
固定レイアウトでリアルタイム更新する画面とか
きちんとCRとLFは区別されてるって感じる

**デフォルトの名無しさん** · 2023/03/16(木) 11:13:17.10

BOMは文字コード？
ZWNBSは文字コード？
CRは文字コード？
LFは文字コード？

**デフォルトの名無しさん** · 2023/03/16(木) 11:31:30.24

>>147
俺のこと言ってる？

「知らんだろ」っていうやつは、
自分が知らないことを相手に要求して
揚げ足取ろうとしているだけだから
「知ってる」っていうと相手に大ダメージを与えられる

知ってた？

**デフォルトの名無しさん** · 2023/03/16(木) 14:30:41.33

知っとって知らんて言うのは犯罪やぞ

**デフォルトの名無しさん** · 2023/03/16(木) 14:32:32.77

>>150
無知なやつは恥も知らんなwww
自分が知らないから相手も知らないはずwww

**デフォルトの名無しさん** · 2023/03/16(木) 14:59:26.59

UNIX終了wwやはり正義はWindowsだったwwww

Unix is dead. Long live Unix!
https://www.theregister.com/2023/01/17/unix_is_dead/

**デフォルトの名無しさん** · 2023/03/16(木) 16:43:13.46

Unix というか Linux に徐々に移行でしょ
メインフレームやスーパーコンピュータはLinux になっちゃたし

**デフォルトの名無しさん** · 2023/03/16(木) 16:58:32.87

>>153
タイトルすらまともに読めてなくてｗ
その記事
IBM が Redhat 買ってこれからは Linux を始めとする unix-like の時代。AIX とかの(旧来の) Unix は終わり。
Windows についてはマイクロソフトも WSL を頑張ってるとしか書かれてない。

そもそも文字コードに何の関係が？

**デフォルトの名無しさん** · 2023/03/16(木) 17:04:46.17

>>141,153
お前 UTF-8 に BOM つけろ君だろ
教養が感じられないあたりがそっくり
主張が通らなかった、腹いせにスレを荒らすな！

**デフォルトの名無しさん** · 2023/03/16(木) 17:42:30.76

>>156
アホ化。逆だわ
UTF-8にBOMつけるな
あれはMSが歪めた仕様
元々はバグだ
シランなら黙っとれ

**デフォルトの名無しさん** · 2023/03/17(金) 20:09:59.24

このスレは以下で全員が一致している
・文字コードはUTF8で統一
・UTF8はBOMを付けない

**デフォルトの名無しさん** · 2023/03/17(金) 21:06:51.85

https://i.imgur.com/5H1ZeBj.png
＞ LinuxやMacでは、ファイル名やメタデータから文字コードを判断することが多いので、BOMは不要です。

これマジ？

**デフォルトの名無しさん** · 2023/03/17(金) 21:09:37.93

BOMって、 UTF16とかじゃないと意味が無いやん？

**デフォルトの名無しさん** · 2023/03/17(金) 21:21:18.90

一応は出典付きになってんだからそれ辿って判断しろ

**デフォルトの名無しさん** · 2023/03/17(金) 22:17:32.94

mac のファイルシステムはリソースフォークを持っているので
そこにTextEncoding を格納しておけば良い

**デフォルトの名無しさん** · 2023/03/18(土) 09:15:45.80

>>159
出典を挙げてくれるところが親切だな。そのqiitaどこ？

**デフォルトの名無しさん** · 2023/03/19(日) 12:16:38.49

Windows のファイルシステムは拡張子を持っているので
そこが .txt なら BOM 無し UTF-8 を前提にして良い

**デフォルトの名無しさん** · 2023/03/19(日) 12:24:54.52

おいおい
Windowsで.txtなんてそれこそ山程CP932のファイルがあるだろう(日本の場合)
それらは全て無視かい

**デフォルトの名無しさん** · 2023/03/19(日) 13:04:41.50

>>165
そいつらは将来に備えて .sjt とかにでも改名しとけw

**デフォルトの名無しさん** · 2023/03/19(日) 13:31:52.51

UTF-8を使う俺が困らなければ他人はどうでもいい。

**デフォルトの名無しさん** · 2023/03/19(日) 14:22:28.77

>>167
UTF-8を使う俺＝将来のお前
どうせ嫌でも皆がUTF-8を使うことになる
遅いか早いかの違いでしかない

**デフォルトの名無しさん** · 2023/03/19(日) 14:46:22.57

遅いか早いか、まさにそこがポイントだわな。
100年後には確実に死んでいるだろうからといって明日すぐに死んでもいいなんて考える人はまずいない。

**デフォルトの名無しさん** · 2023/03/19(日) 15:05:53.25

あきらめろ！もう勝負はついてしまったんだ
今は粛々と対応を進めるフェーズだ
早く対応するほど傷は浅くてすむぞ

**デフォルトの名無しさん** · 2023/03/19(日) 15:11:12.34

>>166
むしろ新しいほうが.utf8のほうが合理的かと

**デフォルトの名無しさん** · 2023/03/19(日) 15:20:23.00

>>171
あきらめろ。どうせSJISのファイルは無くなるんだ。
何ならSJISのテキスト .txt ファイル今後一切作らなくても生きていける。 UTF-8はそうはいかない。

**デフォルトの名無しさん** · 2023/03/19(日) 15:26:26.02

春休みっぽいね。

**デフォルトの名無しさん** · 2023/03/19(日) 16:57:13.82

今日は日曜日なんだぜ。仕事引退したご老人は気づかんかもだが。

**デフォルトの名無しさん** · 2023/03/19(日) 17:30:01.32

C言語でShiftJISからUTF-8に変換するコードをライブラリは使用しないで書いて下さい。

以下はC言語でShiftJISからUTF-8に変換する簡単なコードです。このコードでは、ShiftJISの1バイト目が0x81以上0x9F以下または0xE0以上0xEF以下の場合には2バイト文字、それ以外の場合には1バイト文字として扱います。

#include <stdio.h>

void sjis_to_utf8(char *sjis, char *utf8) {
unsigned char c1, c2;
while (*sjis != '\0') {
c1 = *(unsigned char *)sjis++;
if (c1 <= 0x7F) {
*utf8++ = c1;
} else {
c2 = *(unsigned char *)sjis++;
if ((0x81 <= c1 && c1 <= 0x9F) || (0xE0 <= c1 && c1 <= 0xEF)) {
*utf8++ = ((c1 << 8) | c2) + 0x3C00;
} else {
*utf8++ = c1;
sjis--;
}
}
}
*utf8 = '\0';
}

int main() {
char sjis[] = "こんにちは、世界！";
char utf8[100];
sjis_to_utf8(sjis, utf8);
printf("%s\n", utf8);
return 0;
}

**デフォルトの名無しさん** · 2023/03/19(日) 17:39:03.96

ShiftJISって表現だと文字集合定まらないのに回答もらえんだ
どんだけクソ記事多いんだよ

**デフォルトの名無しさん** · 2023/03/19(日) 21:07:41.87

>>162
macのリソースフォークとか、知識が化石だな
今は大概のファイルシステムが拡張ファイル属性をサポートするので、そこにメタデータを
記録することが可能

**デフォルトの名無しさん** · 2023/03/19(日) 22:36:34.34

apfs はxattr もresource fork も両方使える
named resource fork は無くなってるが

**デフォルトの名無しさん** · 2023/03/28(火) 06:36:26.58

>>175
バッファオーバーフローのチェックがなく不合格

**デフォルトの名無しさん** · 2023/03/28(火) 08:25:55.12

それ以前の問題だろ。>>175はChatGPTに作らせたんじゃね？

**デフォルトの名無しさん** · 2023/04/03(月) 12:56:12.62

AIによるプログラミングはまだ無理だね

**デフォルトの名無しさん** · 2023/04/03(月) 16:26:10.65

AIって、コンピュータのくせに自分でトレース実行してバグ無いか確認しないのなw

**デフォルトの名無しさん** · 2023/04/09(日) 09:21:00.03

検算してもその検算が正しいかどうかすら自身が持てないのがchatGPT

**デフォルトの名無しさん** · 2023/04/09(日) 09:22:48.40

WindowsだがExcelもWordも入れてない
自分のHDD/SSDにはSJISで保存されたファイルなんてもうほぼ存在しない

**デフォルトの名無しさん** · 2023/04/09(日) 12:54:00.15

今MacユーザーになるともれなくUnicode絡みの問題が付いてくるよ
https://applech2.com/archives/20230402-nfd-and-nfc-issues-in-macos-13-3-ventura.html

**デフォルトの名無しさん** · 2023/04/09(日) 13:04:53.10

>>185
Mac が定期的にかかる病気。
すぐ治るけど、時間をおいてまた再発する。

**デフォルトの名無しさん** · 2023/04/09(日) 14:46:54.72

Macは日本の野党と同じで世間からの評価が甘いよなあ。
Macが基幹業務で使われてない何よりの証拠でもあるが。

**デフォルトの名無しさん** · 2023/04/09(日) 17:56:56.24

地震ないのに自信たっぷりに回答するのがChatGPT

**デフォルトの名無しさん** · 2023/04/09(日) 18:30:06.98

ｸｴｰｯ!

**デフォルトの名無しさん** · 2023/04/09(日) 19:01:55.55

知らないことは知らない
調査した限りでは存在しない
そういう答えのほうがいいのに
なんで捏造するんだろうね

**デフォルトの名無しさん** · 2023/04/09(日) 21:05:33.99

そういうのはだいたい、知らないと答えたらひどく怒られた経験があって委縮して育ってしまったんだと思う

**デフォルトの名無しさん** · 2023/04/12(水) 12:03:52.02

自信たっぷりに嘘を答えるから
文系はすぐにだまされるωωω

**デフォルトの名無しさん** · 2023/04/14(金) 14:38:56.45

キャラ名に「ソ」があると画面がフリーズ　Switchの新作ゲームにバグ　制作会社が謝罪
https://www.itmedia.co.jp/news/articles/2304/14/news119.html

**デフォルトの名無しさん** · 2023/04/14(金) 15:45:01.31

>>193
ShiftJISならバックスラッシュ誤判定だろうけど、ShiftJISなわけないよな

**デフォルトの名無しさん** · 2023/04/14(金) 15:53:05.13

浅慮すぎるのは置いといて
ゲームだし手軽にバイト長固定で処理したかったは十分考えられる

**デフォルトの名無しさん** · 2023/04/14(金) 17:03:50.51

芸能人は化ける

**デフォルトの名無しさん** · 2023/04/14(金) 18:27:55.47

ネットの論調は「ソ」と言ったらSJISバグみたいになってるけど今時ありえるだろうか？
もし事実だとしたら旧作からライブラリか何かを移植して流用したのかな？

**デフォルトの名無しさん** · 2023/04/14(金) 18:50:37.36

「ソ」とか「ポ」を含む文字列で壊れる問題、昔はS-JIS絡みで時々見かけたね

**デフォルトの名無しさん** · 2023/04/14(金) 21:31:31.20

ここで念のため

**デフォルトの名無しさん** · 2023/04/15(土) 11:49:15.28

ノーパソ

**デフォルトの名無しさん** · 2023/04/15(土) 12:43:38.13

XAMPP は、MSYS2 なのか？
Windows のsjis(CP932), MySQL, PHP を使っているのかも

Ruby on Rails では、日本語のバグを避けるため、
Linux, UTF-8, PostgreSQL しか使わない

**201** · 2023/04/15(土) 12:55:47.99

>>193
アイディアファクトリー(コンパイルハート)のゲーム開発の求人には、

C/C++, C#, Windows, Unity と書いてある

**デフォルトの名無しさん** · 2023/04/16(日) 08:38:15.57

Unityの文字化けを解消する！
https://qiita.com/kumi0708/items/2f8dd2fc2ccb673ff12b

UnityからC#のスクリプトファイルを作成するとUTF-8(BOM無し)になりますが、
VisualStudioはUTF-8(BOM付き)じゃないとコードページを解釈できずにShift-JISになってしまうようです。

**デフォルトの名無しさん** · 2023/04/16(日) 11:48:59.76

WindowsがUTF-16だと知らないのは不思議だな

**デフォルトの名無しさん** · 2023/04/16(日) 12:01:24.12

SwitchとWindowsでBOMなしテキスト使ってると、結構困ったことになるんだよね
char：Switch=utf8 Win32=sjis
wchar_t：Switch=utf32 Win32=utf16
char16_t／char32_t：対応しているライブラリが少ない

**デフォルトの名無しさん** · 2023/04/16(日) 12:09:09.12

ターゲット固定なのにそんなのある？
ネットとか客先とか何くるかわからん状況じゃないんだし

**201** · 2023/04/17(月) 12:35:43.54

Windows はUTF-16 か。
確か、Ubuntu はUTF-32 とか？

たとえLinux 内部で、4バイト文字を使っていたとしても、
Ruby などのウェブ系言語では、UTF-8 前提でモジュールを作るでしょ？

CP932 の「表・ソ」などのダメ文字は、数十年前の話

**デフォルトの名無しさん** · 2023/04/18(火) 00:06:47.73

一方ビックカメラは令和でもSJISを使った

**デフォルトの名無しさん** · 2023/04/18(火) 04:27:16.75

>>208
5ch…

**デフォルトの名無しさん** · 2023/04/18(火) 05:51:45.47

〄🆗

**デフォルトの名無しさん** · 2023/04/18(火) 10:05:55.09

森鷗外��る
森鷗外𠮟る