文字コード総合スレ part15

文字コードについて語り合うスレです

前スレ埋まってたので立てといた
テンプレとか過去スレを張るとNGワードで弾かれたので省略した
可能な人がいたら適当に補完しといて

しゃぶれよ

Q. UTF-8にBOMは必要ですか？
A. Unicode規格ではUTF-8にBOMを付けることは非推奨と明記されています
LinuxやMacやInternetの各規格ではUTF-8にBOMをつける文化はありません
Microsoftはかつて技術者向けにBOMを付けることを推奨しておりWindowsのツールはデフォルトでBOMを付加していましたが新しいバージョンではBOMを追加しないよう変更されていっています
現時点でも文字コードの自動判別にBOMを使用しているアプリはあるのでそいうソフトウェアの使用に限って便利なこともあります

14 http://2chb.net/r/tech/1677826018/
13 http://2chb.net/r/tech/1593777227/
12 http://2chb.net/r/tech/1544931495/
11 http://2chb.net/r/tech/1516629503/

ms-vcでまだs_jisを使ってる人はただちに辞める方法

ms-vcでutf-8を使う方法
https://learn.microsoft.com/ja-jp/cpp/build/reference/utf-8-set-source-and-executable-character-sets-to-utf-8?view=msvc-170

https://learn.microsoft.com/ja-jp/cpp/build/reference/source-charset-set-source-character-set?view=msvc-170
https://learn.microsoft.com/ja-jp/cpp/build/reference/execution-charset-set-execution-character-set?view=msvc-170

UTF8は、BOMは、非推奨の意味は、
１)UTF8はBOMは法的には🈲
２)UTF8はBOMは私的には🈲
３)UTF8はBOMは使っても🆗
４)SHIFT JISにはBOMは使おう

きっと、３)だな
だってBOMっていきなり先頭バイト
からしてUTF8に存在しないよな？
てか、UTF8は🈲にして
UTF16ビッグエディアンのみ🆗とし
ポクの大好きな笑文字☺とかは
第四水準漢字を削除して笑文字に
割当なさーーーーーい。
てか、第3水準とか第2水準の
割当た場所ってグダグダで
変更は無理ぢゃーーーん。
てか、第四水準はスッキリした
とこに割当られてるし
ドンドンサロゲートは廃止し
第四の場所に絵文字🥳とか割り当てて

超新型UTF16 旧UTF16とは、
第四水準と絵文字以外は
相互に完璧互換性在るハズ

俺って極超々天才だろぉーーぅ

v=RiMT0r8f8aY

ASCII文字以外を使っているならアスキーアートではなく
シフトJISアートやユニコードアートと呼ぶべき

そんなの25年以上前の日本人に言えよ！

ターミネーターの姉はターミネーちゃん

終端抵抗

スレがターミネートしそうになってるやないかい！

もう丸囲み数字はやめようよ。
日本人はなんで打ちにくい①、②、③を書くのかな？

手間しかかからない。

>>15
かわりに何を書くの？
(1)って打って①に変換するんなら手間は一緒だと思うが
単に使ってる日本語入力環境の問題じゃね？

数字の１を変換したら候補に①はあるから打ちにくいとは思わないな

毛頭はIIやIIIを好むけど同じ問題だな

>>17
物理的なQueryキーの話じゃないぞ？

「いち」の変換の候補は、一、位置、市、イチ、一部、壱、1
、１、�T、�@　とかいろいろ、色とりどり、どれにしような
どれを使用しような。
てゆうーーか、「まるいち」って打ち込めば、丸一　だ
ま、「まるいち」って打ち込んでも、候補に�@はでるが
単に、「いち」でも�@が出てくる。てゆうか、
学習機能により、「いち」と打ち込むだけで
�@が2番に出るようになった。ちなみに、第１候補は、
無変換である　いち　のままだ。学習機能ヤバイ。スゴい。ありえない

�@が?に化けちゃってる。
�@は使用🈲を推奨を、推奨しようよ

25年以上前からUnicodeに含まれてる文字が化けるソフトを使用禁止にしろよ

すまん5chで文字コードバグが起きてるんだがどういう事態になってんの？

bugってるのは君の頭だ

>>23
直ったみたいだよ
ブラウザが変換・送信した数値文字参照をぶっ壊していた模様

サンプル
http://2chb.net/r/operatex/1724088826/94-103n
http://2chb.net/r/poverty/1725160810/

「いち」なんて打たなくても「１」だけで良いんだけどな

UTF-8で見た目が同じものを二重に定義してしまった。

①～⑩までは昔からあるが、丸0と丸11以降を作り出してしまい、環境依存がさらに進んでいる。

IMEで変換する時に環境依存文字と出る文字は
CP932に無い文字ということ？

>�@〜�Iまでは昔からあるが、丸0と丸11以降を作り出してしまい

しかも文字コードで丸内数字の大小比較出来ないんだぜ

>>29
あれ、大小比較駄目なんだっけ?

大小比較は出来るけど連続性は全く出鱈目
しかもskipしてるし場所もバラバラ

>>27
>環境依存
この場合の「環境」って何?

今って皆Unicode環境じゃん

がフォントに全ての文字含まれているわけではない

今は標準のフォントで結構文字が入ってない?
そこにNotoあたりでも足せば... No Tofuというぐらいで

市販の日本語フォントはProフォントでも Adobe-Japan1-7 にある文字どまりで2万3千文字程度
Noto も国ごと文字種ごとにファイル分割されているのでフォント切り替えないと全ての文字は表示できない（あと新しく追加された文字はない
いろいろ都合があって一つのフォントファイルに入れるのは最大でも6万字程度に抑えられてるのが実情

なんでたまに中国の漢字が混ざるんかね
普通に使ってても混ざった事ないけど

CJK統合漢字という黒歴史
中国が文句言ったせいで

>>36
囲み文字の話だろこれ。無理に話広げんなっちゅーの

文字列"c9" と"c10"　大小比較考察に、
数値9と10は、後者は、デカい有。さて
文字列のそれは、後者はデカく無アル？
てか、wind○wsは、ファイル名並替順は
ロジックは、意味は、ワカラン有る。
てか、豆腐文字□ぽぃのとか？はやめて、👻
に、豆腐文字ぽぃのは、統一してよ。

文字コードに国境がないと想像してみよう 　そんなに難しいことじゃない
争いや宗教がなくなり 　全世界の人が平和に暮らせる
僕のことを夢想家だと言うかもしれないね

とんでとんでとんでとんで まわってまわってまわってまわる

日本語のソートはJISコード順じゃないと使い物にならないから内部でUnicodeからJISに変換しているという本末転倒感。

何で今までと順番が違うんだとか言われても面倒だからね
文句言う連中は文字コード云々なんて知らないだろうし

今までと違うとか言う以前に、Unicodeのコードポイント順に整列しても意味不明だしね。
はっきり言って使い物にならない。

Unicodeで数字とアルファベットはフォント違いや上付きや下付きの文字があって
丸囲みでもデザインの違いが何種類もあるよね
こういう装飾的な物は文字コードの方でやるのか
HTMLなどの別の規格でやるのかどっちがいいんだろうね
文字コードの方でやるとプレーンテキストでも
文を見やすくできるけど文字の検索がしづらくなるんだよね

>>46
最近は記号や絵文字とかまでを登録するようなってるので普通の文字じゃなかたりするのも多数ある
一見アラビア数字に見えても実際は飾り記号(dingbat)だったり数学記号(math symbol)だったりするのも多い
（フォント違いに見えるのは数学記号）
（同じ丸数字が複数あるように見えるのは修飾数字と飾り記号）
日本からだと全角数字とかフォントによって見かけだけ違うのもあるし

>>37
日本語とはっきり設定していないから

そういやアップル圏のアプリの実装って
濁点半濁点付きの平仮名片仮名はちゃんと表示できてるの？
折り返し処理だとかそういう所で

ｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘｱｯﾌﾟﾙ圏のｱﾌﾟﾘ

「Unicode 16.0」が公開 〜エジプト象形文字、レガシーコンピューティング記号を大量追加
5,185の新たな文字が追加。総計で154,998文字に
https://forest.watch.impress.co.jp/docs/news/1622857.html

Windows環境では〜記号が波ダッシュより全角チルダの方で普及しているからなのか
日本語フォントでもフォントによっては全角チルダは表示できても波ダッシュは表示できなくて
波ダッシュが指定したフォントにならないなんて事がある

>>52
駄目フォントじゃのぉ

全角チルダをちゃんとチルダっぽくして波ダッシュと全角チルダを見た目で区別つくようにして欲しいって言ったら
全角チルダを波ダッシュ代わりにしてるWindowsユーザーからクレームが来るから面倒って言われた記憶

>>51
キャラクタベースの画面でインベーダーやパックマンができるようになるのか、胸熱

しかしこのレガシーコンピューティングの部分の多角形とかって持ってるフォントある?
https://en.wikipedia.org/wiki/Symbols_for_Legacy_Computing

以前アプリを作ってた時にこの手のマークがあるなら是非使いたかったのだが
なさそうだったので自前でアイコンを作って表示した記憶が

>>54
キャラジェネなんか？

無能な働き者の集まり

>>51
Game spritesやIconsのリファレンス元が知りたい

Symbols for Legacy Computing Supplement
https://www.unicode.org/charts/PDF/Unicode-16.0/U160-1CC00.pdf

>>58
インベーダーっぽいのは「ALIEN CRAB」（異星カニ）、パックマンっぽいのは
「SNAKE」（ヘビ）等、固有名を避けあくまでも一般的なものとして逃げようとする
姿勢が見える

ソリッドスネーク

ソリッドステートサバイバー ＋ スネークマンショー

なんつーか、PCGだなあ。
今更だけど。

横1列のドットパターンでコード割り当てて
合成も拡張して縦に並べられるとええかも

YMOと描いてイモと読む

YMO欽トリオ... テクノな曲あったよな

「U+〜」の表記法って正式な名称ないの？「Short Identifier」？

https://www.unicode.org/versions/Unicode16.0.0/core-spec/appendix-a/#G12668
ないんでコードポイント表記とか

>>66
そもそもUTF-8はその表記が正式な表記だから、表記の名称が存在しない。

天皇に名字がないようのなものか? って違うか

回答ありがとう。表記法や表現自体には特には名前ないんか。

正規表現のグループに名前を付けようとして
「(?<UnicodeCodePoint>(?<Prefix>U\+)(?<Hex>[0-9A-F]{4,6}))」
みたいにしたんだけど、
「U+HHHH」全体をコードポイントって呼んでいいのか、
「HHHH」部分だけがコードポイントと呼べるものなのか、
っていう疑問が湧いたんだよね。
調べたらすぐ分かるかと思ったら全然分からなくてモヤモヤしてた。

>>70
xxxx がコードポイント（code point)
U+xxxx がコードポイント表記 (code point notation)
とかで良いんじゃね
知らんけど

0xBEEFとBEEFは表現は違うけどどちらも16進表記で指してる値は同じ
10進表記の48879も同じ値を指す
Unicodeのコードポイントってのは値を指してる
だからなんやねんだけど

>>70
「U+」の部分はUTF-8だという意味

>>73
コードポイントとエンコードの区別が付かない男の人って

>>68 ≒ >>73
これはひどい

Cスレの通りにやって文字出力したら化けるんだけど、文字コード民的な正しい対処法は？
ちゃんとソースファイルがUTF-8なのは確認した

http://2chb.net/r/tech/1721137434/350

#include <windows.h>

int main(void)
{
LPTSTR lptStr = TEXT("テスト😊");
printf("%s\n", lptStr);
}

win32でのAやW、charとwchar_tの事は分かっていて
Linux他でのクロスコンパイルを考えてwchar_tは使わずにUTF-8 everywhereで通しつつ

puts("テスト😊");

が文字化けしない様にしたい
特定システムロケールは仮定せず
ターミナルではchcp 65001してある
場合です

端末がUTF-8非対応なのはないとして
出力をファイルへリダイレクトするかダンプして
想定どおりのバイト列か確認してみては？

C詳しくないんで、正しい対処法は知らんけど、どこの通りで手元で出力できた。

https://www.reddit.com/r/C_Programming/comments/1adv86p/how_do_i_print_a_penguin_emoji_in_c_language/?rdt=48269

分かってるならなんでLPTSTRから変換せずに使ってんの

具体的な回答のリンクにできてなかったんで張り直し
これの前半のほうやね
https://www.reddit.com/r/C_Programming/comments/1adv86p/comment/kk5vdm1/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

>>78-81
ありがとうございます

putsで文字化けしていたのは、コマンドラインでソースutf-8指定したら文字化けは直りました
だけど、引数が受け取れないですね

#include <stdio.h>

int main(int argc, char **argv) {
puts("テスト0😊");
for (int i = 1; i < argc; i++)
puts(argv[i]);
}

$ cl -utf-8 ConsoleApplication1.c
$ ./ConsoleApplication1.exe テスト1😊 テスト2😊
テスト0😊
???1??
???2??

$ ./ConsoleApplication1.exe テスト1😊 テスト2😊 > out.txt
$ cat out.txt
テスト0😊
???1??
???2??

(システムロケールEnglishでの環境です)

デバッグで確認したところ、引数のテスト1😊 テスト2😊は受け取りの時点(argv[i])でアルファベット以外の各コードポイントが?になってます

WindowsTerminal
MSYSTEM=UCRT64のMSYS2 bashです

$ echo テスト1😊 テスト2😊
テスト1😊 テスト2😊

$ gcc ConsoleApplication1.c
$ ./a.exe
テスト0😊

$ ./a.exe テスト1😊 テスト2😊
Error: Command line contains characters that are not supported
in the active code page (1252).

UTF8 everywhereは厳しいですかね?

WindowsでワイドキャラクタってのはUTF16LEのことだよ？

UTF-8 everywhere行けました

$ cat utf8.rc
#include "winuser.h"
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "utf8.manifest"

$ cat utf8.manifest
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings";>
<activeCodePage>UTF-8</activeCodePage>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>

$ cl -utf-8 ConsoleApplication1.c
$ mt.exe -nologo -manifest "utf8.manifest" -outputresource:"ConsoleApplication1.exe;#1"
$ ./ConsoleApplication1.exe テスト1😊 テスト2😊
テスト0😊
テスト1😊
テスト2😊

$ windres --input utf8.rc --output utf8.res --output-format=coff
$ gcc ConsoleApplication1.c utf8.res
$ ./a.exe テスト1😊 テスト2😊
テスト0😊
テスト1😊
テスト2😊

>>87
下記の手続きを適用したってことなのかな？

Windows アプリで UTF-8 コード ページを使用する - Windows apps | Microsoft Learn
https://learn.microsoft.com/ja-jp/windows/apps/design/globalizing/use-utf8-code-page

はい、検索して適当に拾ってきたのでxmlnsが微妙に違いますが同じことですね

MinGW64ツールチェーンではutf8.rcを経由してマニフェスト埋め込みしてますが
MSVCツールチェーンではその経路だとこうなります

$ rc utf8.rc
$ cl -utf-8 ConsoleApplication1.c utf8.res

ついでにPythonでもやってみました

$ cat ConsoleApplication1.py
import sys
print("テスト0😊")
for s in sys.argv[1:]:
print(s)

$ python313.exe ConsoleApplication1.py テスト1😊 テスト2😊
テスト0😊
テスト1😊
テスト2😊

環境変数がセットされてたので強制的に空にしても問題ないようです
$ PYTHONIOENCODING= PYTHONUTF8= python313.exe ConsoleApplication1.py テスト1😊 テスト2😊
テスト0😊
テスト1😊
テスト2😊

スレ汚しでしかない

>>90
まあ、あの荒れそうな言語がユニコード引数でエラー出すからな

>>73
コードはユニコード
それをどうエンコーディングするかでUTF8やUTF16やUTF32などがある
ネットの標準がUTF8に統一されてなって
ファイルシステムでもUTF8に統一されつつあり
プログラム内部でもほとんどの用途はそのまま透過的にUTF8が有利に

固定長で扱うUTF32はムダすぎで
可変長のUTF8は後ろからでも切れ目を間違えことなく
表示幅問題はUTF8/UTF32関係なく発生するため

>>92
>ファイルシステムでもUTF8に統一されつつあり
例を挙げてもらえますか?

>>93
Linux distro, MacOS, android, iOS,...
挙げ始めたが最近のリリースだと Windows 以外のメジャーどころは全部じゃね？

UTF-8は世界の誰もが好むわけではない。
どの民族もUTF-8の良いところと悪いところで悩んでいる

>>94
勘違いしているけど、それらの製品でも区別して使う分けている。

>>94
Linux (ext4) は、ファイルシステムとしてはエンコーディングは規定されてないのでは?
ディストロやユーザーがUTF-8を使ったりするのは自由だが
よってAndroidも同様

なんだAppleだけじゃんw

>>97
そんなこと言いだしたら APFS も NTFS も単にバイト列を記録してるのに過ぎない。
それをOSやライブラリとしてどう解釈するかがファイルシステムの文字列。
だから linux kernel でなくて linux distro の問題。
（もっとも最近の Linux kernel はデフォルトで UTF-8 を指定するABIとかあって文字コードの変換したりするけど。別問題）

UTF-8も完璧じゃないからな

>>99
キミの言う「完璧」とは一体...

>>98
>そんなこと言いだしたら APFS も NTFS も単にバイト列を記録してるのに過ぎない。
いいえ

UTF8を推しているのは形を変えたASCII信者の老害。

刷新できていない古いシステムを除くと
文字コードはユニコードになったね

エンコーディングはネット上がUTF8なので
それをそのまま扱うのが一般的となったね

UTF-8 より完璧な文字コードって何だい？
ASCII と SJIS と UTF-8 はいいねしたい

なんか色々ごっちゃだな

元のユニコードがクソだからなあ
結局どうにもならなくなって異体字セレクタとか出てくるし

ishの出力ってSJISが標準？
utf-8板のish欲しいと思ったけど
-Dutf8付けてコンパイルしても結局SJIS出力だった

バイトデータで出力してるだけでエンコーディング関係ないような
UTF-8対応してもバイト単位でみたら7ビットしか情報持てないから損
効率気にしないならコード変換したらいい
半角カナが3バイトになるけどエラー訂正なんかは使える

たまたまSJISでデコードしたら人間に読める(かもしれない)ってだけで
只のバイナリデータだよね

SJISとして不正なバイト列は含まれないはず

ファイル名がユニコードだと、
例えば2つのファイル名が同一かどうかの判定は、２つのユニコード列が同一かどうかの
判定をしなくてはならない。この場合の同一とはなんだろう。めんどくさい

>>111
「ユニコード列」みたいな曖昧な用語で考えると曖昧な結果にしかならなんわな

「ファイル名」という用語に限ってもOSごとに異なる意味をもち、「バイト列/コードポイント表現」(Linux/Windows)と「 unicode 正規化表現」(MacOS)のどっちのやり方もあるし unicode の正規化には複数の種類がある

>>103
ネットはJISもあるから、そう簡単な話ではない。

EメールだとまだJISが主流。

>>113
Macのせいで記号や改行コードの解釈がめちゃくちゃになった。

>>111はあえて雑に書いてあるんだが（めんどくさいからw）
>>113は「曖昧じゃない」んだ?

見苦しいぞ

ﾊﾝｶｸｶﾀｶﾅ.txtと
ハンカクカタカナ.txtは
区別されると困るか区別して欲しいかは個人の好みだな

>>111,118
主観と好みの問題だから、現状がそれを孕んでいるかどうか心配ならNKFCで突合チェックしたら良いだけかな

>>118
自分はまったく別物だろうという考えだが、逆にそれを同じと思う人がいるというのに驚きだ

MacOS/iOS だと OS 的にファイル名はNFD強制なのでその2つ区別できないのが普通だな
Macユーザーは「半角カナはファイル名には使えない」という言い方してることが多いけど

Windowsは大文字小文字の区別を付けないのがデフォルトなんだけど、
WSL内からアクセスする兼ね合いで区別設定できる(fsutil)

>>121
Macにも同様の理由でNFD強制解除の設定があるのでは？

>>122
強制解除とかはなかったと思うが古い HFS+ と違って新しい APFS では論理的には書き込み可能なはず
一方でライブラリで、ファイルオープンする時にファイル名が強制的にNFD変換されるので通常のプログラムでは全部NFDになるのは避けられない

Macが一番遅れているのは意外だな

> Mac で NAS (SMB) のファイルが見えない問題を Unicode 正規化方式を変えて解決
> Unicode 正規化方式として NFD を採用しているのは Mac なのに，SMB (NAS) を介してみると当の Mac だけがそういったファイルを認識できない（ことがある）というのはなんとも皮肉な結果ですね...。

>>124
Mac はローカルファイルは NFD (っぽい独自仕様）で正規化されてる前提で、リモートのSMBの先は NFC （っぽい独自仕様）で正規化されている前提で動作するという謎仕様なので
Lunux は基本的に正規化されずに全部別の文字扱いで unicode の全文字が使える
Windows も基本的には正規化を前提にしていないが独自仕様の使えない文字がある

わかりやすいようにたとえで説明するとさ、
オマエんちに人を招待したら、土足のまま上がってきた
オマエはイラっとするんじゃね? はいオマエ遅れてる〜

服装カジュアルな場所でも常にスーツ着てきてスーツ着てないやつは家族だろうと友人だろうと全員無視するのが Mac 仕草
その上、自宅用と訪問用に別の種類のスーツを使い分けてて同じ種類のスーツ着てないと相手してくれない

UnicodeはUnicodeで様々な言語の様々な表現ができるようにするなかで一意性についても
用途や目的によって方法は異なるとしているわけで、そもそもファイルをファイル名で特定するという
昔ながらのやり方との齟齬が出てきているのかもね。
使うなら使うでファイルシステムに用いる正規化ルールなどを定めなければならないんだろう。

同一性やコロケーション問題として
path-win-ntfs、path-linux-ext4のようにunicodeでpath-localeを定めてicu実装されたら良いのにと思った事はあったけど、
それで他の方法が駆逐されるわけじゃなく新たなバリエーションを増やすだけだから、今は余計な事するなと思うよ

>>128
ファイル名はOS的には単なる識別子なのでバイト列一致で良い
それを文字コードと絡めて正規化しようとするのがそもそもの間違い
バイト列をどのように解釈するかは別のレイヤーの問題

FSとしてならそれでいい
OSをどの層までとするかでも変わってくるけど
マウント時に変換かけてOS間の相互運用気にしてほしい
ネットワーク透過考えるとパスはURIで扱いたいしね

>>131
基本的にはアプリ側のライブラリ層でやるべきこと
OS標準ライブラリかユーザ追加ライブラリかはOSの思想によるし Linux とかだとOS標準ライブラリという考え方は縁遠いけど
マウントの時にファイルシステムで文字コード変換するのも否定しないけど、あくまで代替手段なので、固定ではなくオプションや設定で利用者で任意に変更できるべきもの

>他の方法が駆逐されるわけじゃなく新たなバリエーションを増やすだけ

ほんそれ

まずはMacを駆逐しよう

Mac で日本語を駆逐でいいんじゃね？

ファイル名にはASCIIにある文字しか使わないようにすれば解決

>>136
ASCII のバックスラッシュが円記号になってしまう OS がるらしい

>>136
じゃあまずはASCII以外でここに書き込むのやめろよ

>>138
ここにファイル名を書いてる人あまりいないと思うんだけど？

波ダッシュ（〜）と全角チルダ（〜）は違う文字

JISで全角チルダ定義したのがアレだよな
全角しか表示できない場面のためだろうけど

>>141
JIS は全角と半角とか定義してない（定期

>>142
えー、をMSIMEで変換したら
全角チルダ(U+FF5E)でした

抑揚のある伸ばし棒はこれが正解ですか？

>>143
知らん
MS が決めたことは MS に聞け
全角とか半角とか関係ない

この板には表層的にMSを持ち出すだけで思考停止する若干一名がいるね

>>145
シフトJISの「波ダーシ」を unicode の「全角チルダ」にマッピングする CP932 を規定したのはマイクロソフト
マイクロソフト以外の Linux とか MacOS とかその他の各社OSではそうなっていない

マイクロソフトが何でこんなマッピングにしたのかは専門家でも分かんない謎
unicode がまだドラフトの時代にあわてて作業したのでミスっただけの可能性も指摘されてるが、一度決めたものは互換性のために変えられないのだろう点は理解できる

マイクロソフト憎しにも程がある
デマだめ絶対

マイクロソフトの場合親の敵の可能性があるから俺は許すね
気の済むまでじゃんじゃんやっといてくれ

unicode 規格が最初に作られた時サイトに参考情報として JIS と unicode のマッピング表が置いてあった
Linux も Mac も商用Unixもこの表に従ってJISの波ダーシを unicode の wave dash にマッピングした。さらに JISの規格書にもこのマッピングで記載された
ただ Microsoft 1社だけは JIS の波ダーシを unicode の fullwidth tilde にマッピングした

こんなんマイクロソフトの中の人以外に理由が分かるわけねーだろ

初期のUnicode仕様書の文字の形がおかしかったのがそもそもの原因なんだけどね

いまの仕様書では、〜（U+301C、波ダッシュ）は、～（U+FF5E、全角チルダ）と同じ字形だけど、
古いものは、上下反転した存在しない文字の形だったので、どちらに合わせるかを決める時点で、
MSは形の相似した全角チルダのU+FF5Eを、その他は仕様どおりの波ダッシュのU+301Cを割り当てた
更にMacは仕様書を無視して字形を変更し、現在の仕様書と同じようにU+301Cに本来の波ダッシュの形を割り当てた

ただ、上下反転した字形は、縦書きの際の全角チルダ（左右の順）文字を横書きにしたために紛れ込んだとも言われているので、
仕様書制定の段階で縦書きのある日本語を理解した人が加わっていなかったのだろうな

まぁ、仕様書の字形がおかしかったことがそもそもの原因ではあるけれど、
これの対応を話し合いをすることなく各社で独自に行なってしまったというのが一番大きいな
結局、日本語が軽んじられていたんだろうけど、なんとも間抜けな話

>>150
仕様書も文字の形がおかしかったはネットの素人が勝手に推測した迷信、文字形は規定していない
文字コード的にはフォントで変わる文字の形は意味がない

unicode の wave dash は JIS 第一水準の波ダージなどに対応する文字として準備された
unicode の互換領域の fullwidth tilde は EUC-JP とかで使用されいたJIS補助漢字のチルダをマッピングするために準備された
EUC-JP では ASCII の1バイト文字のチルダと補助漢字の2倍と文字のチルダに両方が使われていたので互換領域が必要だった