X
文字コード総合スレ Part11
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
垢版 |
2018/01/22(月) 22:58:23.45ID:UK/uqEp5
プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
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/
0682デフォルトの名無しさん
垢版 |
2018/08/14(火) 20:25:18.83ID:cWcfj41B
正確には、既存のコードの多くは wchar_t が使われて無くて、
その対応が大変だっていう話

WindowsはOSすべてを自分たちで作ってるからどうにかなったが、
オープンソースで他人が作ったものの寄せ集めだと対応が大変だろうね
0683デフォルトの名無しさん
垢版 |
2018/08/14(火) 20:38:21.12ID:+lmSJTba
gcc は、 wchar_t を16bitと32bitでコンパイル時に選択できるようになっているので、のちのちWindows以上に厄介なことになるでしょう。
0684デフォルトの名無しさん
垢版 |
2018/08/14(火) 22:54:07.34ID:YfFk5ERN
>>681
Linuxではそうだけど、Unix一般の話でいうとwchar_tはcharの多バイト文字をひとつの値で表せられるならなんでもいいし
実際BSDはcharがSJISならwchar_tはJISコード
0685デフォルトの名無しさん
垢版 |
2018/08/15(水) 01:31:39.17ID:URD+Lz/b
OSの中とかプログラム言語とかどうでもいい。
インターネットとかの通信プロトコルでオクテット(8bit)単位で交信、終端は0x0A 0x0Dとかの特定のオクテットコード列を使用とかになってるのが多数ある。
内部では好きなビット数で処理すれば良いけど、通信には8bit単位の処理系も必須。
ユニコード使うかどうか以前の問題。
0686デフォルトの名無しさん
垢版 |
2018/08/15(水) 01:44:12.43ID:Vx/KYfiZ
ケチケチ言わずIPV6くらいドカンと拡張しようぜ
0687デフォルトの名無しさん
垢版 |
2018/08/15(水) 02:10:10.66ID:sxh1cciH
wcharは、内部の符号化に依存しちゃいけないし、幅が 16bitか32bitかに依存するのもよくない
使うのがなかなか難しいね

但し、char と混在させるのは単なる誤り。printf に使うと途中で切れるとかいうのは使う側のミス
0689デフォルトの名無しさん
垢版 |
2018/08/15(水) 11:55:41.55ID:RPpo5aFa
>>687
printfで途切れる云々は仮にLANG=C.UTF-16みたいなロケールがあったとしての話だろ？
isdigit等も実装できないし、規格上できないようになってるとは思うけど
0690デフォルトの名無しさん
垢版 |
2018/08/15(水) 13:30:59.38ID:/R99sNfj
>>687
printfはchar（のポインタ）を受け取るんだから、wchar_tは使えないでしょ？
というかcharで表示できない文字だから、wchar_tが作られたというのが正しい

そうなると、printfだけでなく多くの文字列用関数に対して
charバージョンとwchar_tバージョンが必要になって、変更しなければいけなくなるよね
それが大変だからUnix/LinuxはUTF-16には対応するのは現実的に不可能
対応が簡単なUTF-8を作りました。という流れ。

>>689
> LANG=C.UTF-16みたいなロケールがあったとしての話だろ

Unix/LinuxはUTF-16に対応するの大変だから、
そんなロケールは実現できないだろうね

似たような理由EUC-JPは対応できたけど、SJISは対応できなかった

と思ったけど以下のような警告出るけど使えるのかｗ
> # localedef -f SHIFT_JIS -i ja_JP /usr/lib/locale/ja_JP.SJIS
> キャラクタマップ `SHIFT_JIS' は ASCII 互換ではありません, ロケールは ISO C に従っていません

こんなのまで見つけた
http://www.ossforum.jp/jossfiles/Linux_SJIS_Support.pdf
ダメ文字（文字の一部に\が含まれる場合）にさえ、あたらなければ大丈夫ってことなんかな
UTF-16と違って確率的には低いだろうけど
0692デフォルトの名無しさん
垢版 |
2018/08/15(水) 16:15:54.08ID:Y4UT7naw
乳首の甘噛み
0694デフォルトの名無しさん
垢版 |
2018/08/15(水) 16:43:22.85ID:BHOopni+
>>693
だからダメ文字だって

http://ash.jp/code/code.htm
>　また、2バイト文字の中に"\"(0x5C)を含むデータが存在するため、文字列がメタ処理されてしまい、文字化けする可能性があります。

LinuxやUnixに限った話ではないけど、
文字を1バイトずつ処理するようなもの（つまりcharポインタ）は
ASCIIと互換性がないと不具合の原因になる

だからSJISやUTF-16やUTF-32はLinuxやUnixで
ネイティブに処理するのは苦手なんだ
0696デフォルトの名無しさん
垢版 |
2018/08/15(水) 22:23:06.07ID:URD+Lz/b
アホか、アホしか居ないか？
それともわざとボケてんのか？
なんで wchar_t の話と printf の話を一緒に語ってるんだ？

wprintf 🤔
0697デフォルトの名無しさん
垢版 |
2018/08/16(木) 02:36:38.02ID:agaekNdO
>>696
だからprintfで実装されているものをwprintfに修正するのが大変だって話
またwopenfなどワイド文字対応の関数が存在しない場合も存在する。

それに単純に置き換えてしまうと、今度はASCII環境で動かなくなってしまう
なぜならwchar_tは16bit または 32bitという固定サイズなので
8bitのASCIIは扱えない（当然可変長バイトのUTF-8もwchar_tでは扱えない）

だからwchart_tというものが作られたけど、Linux/Unixはそれを使用して
ワイド文字列対応にするのは現実的に不可能と判断し、
printfで扱えるASCII互換のUTF-8を使うことにした
0698デフォルトの名無しさん
垢版 |
2018/08/16(木) 02:59:55.06ID:HgLxU9xg
ダウト
wchar_t で普通に ASCII も使える。当たり前。i18n でプログラム組んだことないだろ？
UNIX 系で utf8 が好まれる最大の理由は内部コードとかじゃなくて、ファイル名。
ファイル名に直接 0x00 が入れられないので。あとはネットワークまわり。
0699デフォルトの名無しさん
垢版 |
2018/08/16(木) 03:50:25.48ID:agaekNdO
そりゃ16bit（つまりUTF-16）として書くか変換すりゃASCIIの範囲の文字列は
扱えるだろうさ、そうじゃなくて8bitのASCII文字が扱えないって話

charは1文字8bitとして定義されたものだが、UTF-8を扱う場合は可変長としても考えられる
wchar_tは16bit （または 環境によっては32bit）であるがUTF-16を扱う場合は16bit単位の可変長、
つまりサロゲートペアを扱える。しかしwchar_tは所詮16bit（または32bit）単位なので8bitは扱えない

そのためUTF-8のファイルを読み込むときには、wchar_tに変換して読み込まなければいけない。
例えば8bitのASCIIコードであれば残りの8bitを\x00で埋めた16bitのUTF-8に変換するとかしてだ。

このようにASCII互換のデータを扱うためには単純にchar型をwchar_t型に置換しただけでは
だめで変換処理が必要になる。それに対してUTF-8であれば、char型を可変長char型と
みなすことでそのまま扱うことができる。文字列の長さをカウントするときとか
1文字単位で処理しなければいけないところだけ、UTF-8を扱えるライブラリを使えば良い
0700デフォルトの名無しさん
垢版 |
2018/08/16(木) 06:01:32.95ID:agaekNdO
訂正

そのためUTF-8のファイルを読み込むときには、wchar_tに変換しながら読み込まなければいけない。
例えば8bitのASCIIコードであれば残りの8bitを\x00で埋めた16bitのUTF-16に変換するとかしてだ。
0701デフォルトの名無しさん
垢版 |
2018/08/16(木) 08:19:53.82ID:RvAH1val
ファイルシステムに記録された物理的encodingに依存したコーディングができる方が良いという主張かねぇ。
0702デフォルトの名無しさん
垢版 |
2018/08/16(木) 08:31:16.13ID:FM/GQ3/9
Windows標準のXmlLiteというXMLパーサーは、入力ファイルがどんな文字エンコードだろうと、
UTF16に適宜変換するようになっているので、プログラマに読み取り時の文字エンコード選択の余地はない。
0703デフォルトの名無しさん
垢版 |
2018/08/16(木) 10:25:22.61ID:Lp1O0T8c
>>701
内部ネイティブ文字コードがcharになっているLinux/Unixでは
char非互換の文字コードに対応するのが大変だったという主張

>>702
Windowsは内部ネイティブ文字コードがUnicode（UTF-16）だから
別にそれでいいのでは？



それにしても結果論ではあるけど、wchar_tは失敗だったねぇ
16bitでは足りないことは最初からわかっていたけど、たとえ32bitであっても
異字体セレクタやらで意味的な1文字のbit数が固定ではなくなってしまった。
固定でないならば単純な実装で文字を扱うのは不可能。
whar_t使うメリットが無くなってしまった。

まあその怪我の功名で絵文字に色がつけられるようになり、肌色の違いも
対応も可能になったんだけど、これも良かったんだか悪かったんだが。
ここまで来たら絵文字以外の文字も全て色変化対応にしたらって思う
そうすりゃエスケープシーケンスなしで色を付けられるよ
もはや文字コードじゃないね
0705デフォルトの名無しさん
垢版 |
2018/08/16(木) 11:03:08.50ID:wiNukf+g
アホが頑張るとろくなことにならない
0706デフォルトの名無しさん
垢版 |
2018/08/16(木) 20:21:21.81ID:HgLxU9xg
wchar_t のこと何もわかっていないのに適当なこと言ってるな。
wchar_t は一つのプログラムで複数の文字コードを切り換えて使うための仕組みで、外部用の多バイトコードから内部文字コードに変換するのは当たり前。
char を wchar_t に書き換えるだけで済むとか誰も思っていない。そんなの言うだけ恥かしい。
大きさも規格では少なくとも 8bit で sizeof(wchar_t) >= 1 というだけ。なので 8bit でも 64 bit でも何でも良い。
windows で UTF16、linux の glibc で UTF32 を wchar_t にいれてるのは勝手にそうしてるだけで、そうしないといけないという決まりはないし、そうじゃないOSも普通にある。内部コードなので何を入れてるかはプログラマやユーザが気にする必要はない。
あと「8bit のASCII」とか寝惚けたこと言ってるけどそんなこと言うやつは文字コードの話する資格ない。ASCII が 7bit というのは常識レベルの知識。
0708デフォルトの名無しさん
垢版 |
2018/08/16(木) 21:43:39.72ID:rfZ8gqJr
常識だし当たり前のことだから、
言ってることに間違いはないってことかな？
0709デフォルトの名無しさん
垢版 |
2018/08/16(木) 21:50:57.04ID:VSd23G4R
ｵﾚですら電子ﾒｰﾙでは半角ｶﾅは使わないからな
0710デフォルトの名無しさん
垢版 |
2018/08/16(木) 22:12:07.10ID:RvAH1val
今時のまともなMUAでいわゆる半角カナに対応できないものってあるかな？
fj全盛の20年前ならいざ知らず。
0711デフォルトの名無しさん
垢版 |
2018/08/16(木) 22:16:46.79ID:VSd23G4R
C/C++

　The C and C++ standard libraries include a number of facilities for dealing with
　wide characters and strings composed of them. The wide characters are defined using
　datatype wchar_t, which in the original C90 standard was defined as

　　"an integral type whose range of values can represent distinct codes for all
　　 members of the largest extended character set specified among the supported
　　 locales" (ISO 9899:1990 §4.1.5)

　Both C and C++ introduced fixed-size character types char16_t and char32_t in the
　2011 revisions of their respective standards to provide unambiguous representation
　of 16-bit and 32-bit Unicode transformation formats, leaving wchar_t implementation-defined.
　The ISO/IEC 10646:2003 Unicode standard 4.0 says that:

　　"The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently,
　　 programs that need to be portable across any C or C++ compiler should not use
　　 wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined
　　 wide characters, which may be Unicode characters in some compilers."

ｶﾝﾍﾟｷな引用
やはりｵﾚのﾚｽはｶﾝﾍﾟｷ
0712デフォルトの名無しさん
垢版 |
2018/08/16(木) 22:23:45.92ID:VSd23G4R
会社のﾒｰﾙは勝手にﾒｰﾙに含まれる半角を全角にかえやがる
※　必要で半角をいれてるからな

半角でﾌｫﾙﾀﾞ名つけるﾊﾞｶがいるせいで
その半角を含むﾊﾟｽに格納されてる資料のおいてあるﾊﾟｽを送ると
ﾒｰﾙ送ったあと一時期必ず文句がきてたからな

　その資料にｱｸｾｽできないと
　そんな場所ないと

うんざりしたから
この部分が半角ですと書いてやっても
ｱｸｾｽできないと返信が来る

何度か半角でﾌｫﾙﾀﾞ名つけたﾊﾞｶを探しだして
しばいたろかと思ったわ
0713デフォルトの名無しさん
垢版 |
2018/08/16(木) 22:33:35.19ID:jJkSajo2
しばくんじゃなくてフォルダ名を変更すれば済むじゃん
あんたタイムゾーンスレでずっとそういう趣旨のこと言ってるよねｗ
0714デフォルトの名無しさん
垢版 |
2018/08/16(木) 22:38:11.04ID:VSd23G4R
ﾌｫﾙﾀﾞ名は一回変更したわ

すると突然
半角以下にあるﾘﾝｸがすべてｱｸｾｽできなくって
みなが大騒ぎになったわ

そんなことやったのはだれだと
幸いｵﾚがやったとﾊﾞﾚずに済んだが
0716デフォルトの名無しさん
垢版 |
2018/08/17(金) 01:01:58.63ID:6wrElEJt
メールで送らなければいい
会社のメールを変えればいい
会社を変えればいい

半角君の発想だとこんな感じ
0719デフォルトの名無しさん
垢版 |
2018/08/17(金) 05:32:43.08ID:DWhhxT1h
>>718
そいつは勘違いしてるよ。

Linux/UnixはUTF-16などASCIIと互換性がない文字コードに
対応するのが大変だからUTF-8を作ったという話をしてるのにそれをわかってない
UTF-16に対応しようと思ったら、あちこちで使われてるcharをwchar_tに変えないといけない
printfですら使うことができない。まあ現実的に不可能だわな

最初からUnicode（UTF-16）対応として設計開発された
Windows NTとは違うわけだ
0721デフォルトの名無しさん
垢版 |
2018/08/17(金) 07:06:48.04ID:p3S4iKgX
外国人は鼻ほじりながら「おまいら大変だなー」と同情してるだろうな
charで全て賄える文字文化圏が羨ましい
0722デフォルトの名無しさん
垢版 |
2018/08/17(金) 14:32:22.25ID:qwkl5VTB
＞外国人は鼻ほじりながら「おまいら大変だなー」と同情してる

その手の輩も今はemojiに対応するために結局Unicodeと向き合わなくちゃならなくなってるけどな
0725デフォルトの名無しさん
垢版 |
2018/08/17(金) 17:57:13.67ID:RTbKyx/W
バカ「半角カナを使うと文字化けするんだぞ！使うの禁止！」

それは昔メールでよく使われていたISO-2022-JPに半角カナがないのが
理由なのでSJISやEUC-JP、今の主流のUnicodeにはあてはまりません。
ISO-2022-JPでなければ半角カナ使って良いんですよ。

バカ「む、難しい言葉でごまかすな！」
0727デフォルトの名無しさん
垢版 |
2018/08/17(金) 20:09:50.97ID:yTcXDgUV
やっぱりバカどもは
なんにもわかってないわ。。。

電子メールでいうテキストというのは
７ｂｉｔだけで表現されたもんをテキストといってるワケ
つまり、伝統的にａｓｃｉｉ（７ｂｉｔ）だけで表現されてるデータをテキストと呼称してる

昔は、７ｂｉｔのデータしかやりとりできなかったネットワークもあったからな
ｕｔｆ－８とかｓｈｉｆｔ－ｊｉｓとかな、メールでは意味不明なバイナリーなわけ

分かる？

そんなテキストもどきでも
いまでもプロトコルの規定どおり７ｂｉｔのデータ以外を発信してはいけないのは当然

　
　Ｃｏｎｔｅｎｔ－Ｔｒａｎｓｆｅｒ－Ｅｎｃｏｄｉｎｇ：　７ｂｉｔ　←　コレは絶対だからな

ｕｔｆ－８やｓｈｉｆｔ－ｊｉｓのテキストもどきならｂａｓｅ６４エンコードするとかしないといけない
そのままがいいならｕｎｉｃｏｄｅのエンコード形式でｕｔｆ－７という選択肢もある
0728デフォルトの名無しさん
垢版 |
2018/08/17(金) 20:12:42.50ID:yTcXDgUV
お、書けた
ﾙｰﾀ再起動でも書けなかったのに
>>727のﾚｽをｻｸﾗで半角全角変換するだけで書けた
どの部分がよくなかったのかよくわからん
ｻｰﾊﾞｰが>>727のﾚｽをｾｷｭﾘﾃｨﾌﾞﾛｯｸではじいてるみたいだったからな

まあいいか
0730デフォルトの名無しさん
垢版 |
2018/08/17(金) 20:14:07.81ID:yTcXDgUV
日本のすべてのｼｽﾃﾑではずっとな
ﾒｰﾙのﾃｷｽﾄ表示まで保証されてるのはiso-2022-jpにﾏｯﾋﾟﾝｸﾞできる文字だけだからな
iso-2022-jpにﾏｯﾋﾟﾝｸﾞできない文字はそもそも保証されてない

※ JISにﾏｯﾋﾟﾝｸﾞできないUnicodeやShift半角ｶﾅなんか保証してない
※ 最低でもiso-2022-jpのﾌｫﾝﾄなら日本のどのｼｽﾃﾑにも用意できてるﾊｽﾞだからな
※ そうでないとﾃｷｽﾄすら表示できない

保証されなくてもいいなら、そのままばっちいままのﾃｷｽﾄもどきをｴﾝｺｰﾄﾞして発信すればいいﾜｹ
別にUTF-8、Shift_JISで送ってはいけないということはない
※ UTF-8なんかもともとｴﾝｺｰﾄﾞされてるｵｸﾃｯﾄをさらに7bitにｴﾝｺｰﾄﾞしてから発信することになる

わかった？
0731デフォルトの名無しさん
垢版 |
2018/08/17(金) 20:17:14.05ID:yTcXDgUV
結論をいえば
受信されるｼｽﾃﾑで最終的にそのｼｽﾃﾑ用にﾃﾞｺｰﾄﾞまでできて
表示まできるのなら問題ない
それだったら受信したﾔﾂも腹もたたない

表示できないﾒｰﾙもらったら腹立つだろ
ﾃﾞｺｰﾄﾞ未対応だったり未対応形式だったりするｴﾛ動画をしらずにﾀﾞｳｿしてな、
そのｴﾛ動画が再生できないのと同じぐらいの強いｲﾗﾀﾞﾁを感じるﾊｽﾞだからな
0732デフォルトの名無しさん
垢版 |
2018/08/17(金) 20:18:53.90ID:yTcXDgUV
ﾎﾝﾄなこの板は低学歴底辺知恵遅れのｺﾞﾐｸｽﾞしかいないのがよく分かるわ

　> あと「8bit のASCII」とか寝惚けたこと言ってるけどそんなこと言うやつは文字コードの話する資格ない。
　> ASCII が 7bit というのは常識レベルの知識。

ID:HgLxU9xgやｵﾚみたいにきわめて常識的なこといってるﾔﾂが叩かれて
しったかﾃｷﾄｰなこといってる低学歴底辺知恵遅れが幅をきかせてるのがこの板だからな。。。
0733デフォルトの名無しさん
垢版 |
2018/08/17(金) 20:29:28.96ID:RgiGOjCt
>Ｃｏｎｔｅｎｔ－Ｔｒａｎｓｆｅｒ－Ｅｎｃｏｄｉｎｇ：　７ｂｉｔ　←　コレは絶対だからな

前世紀の遺物かよｗ
つかオマエ、mohtaみたいでキモいんだが。
0734デフォルトの名無しさん
垢版 |
2018/08/17(金) 20:32:13.67ID:yTcXDgUV
　MIME-Version: 1.0

MIME-Versionは1.0しかない
ﾎﾝﾄな知恵遅れがいってることは
いつも意味が分からない
0735デフォルトの名無しさん
垢版 |
2018/08/17(金) 20:34:01.29ID:yTcXDgUV
低学歴底辺知恵遅れの世界にﾌﾟﾛﾄｺﾙなんかないからな

低学歴底辺知恵遅れﾄﾞｶﾀは
ﾈｯﾄﾜｰｸのﾌﾟﾛｸﾞﾗﾑなんかやらないから関係ない
0736デフォルトの名無しさん
垢版 |
2018/08/17(金) 20:37:37.32ID:yTcXDgUV
低学歴底辺知恵遅れと
まともな人間の間では
そもそも意思疎通は不可能

ﾌﾟﾛﾄｺﾙがまったく違う
低学歴底辺知恵遅れ特有のﾌﾟﾛﾄｺﾙがあるらしいが
ｵﾚはそのﾌﾟﾛﾄｺﾙがまったく分からない
0737デフォルトの名無しさん
垢版 |
2018/08/17(金) 22:48:02.68ID:dUYwrsCb
氏名における「髙」や「𠮷」や「乭」 | yasuokaの日記 | スラド
https://srad.jp/~yasuoka/journal/623209/

読売の元の記事貼ろうと思ったらネット上には無かった……。
JIS X 0213ベースなのか？
戸籍統一文字と住基ネット文字コードの擦り合わせしたデータベースはどうするんだあれ
0738デフォルトの名無しさん
垢版 |
2018/08/18(土) 12:04:57.41ID:TgZCKLMK
UNICODEで恥ずかしい書き込みしてた人が
大量レスでスレ流ししてるようにしか見えない
0741デフォルトの名無しさん
垢版 |
2018/08/18(土) 12:33:47.22ID:KC80I9ck
unicode の議論と wchar_t の議論を混ぜるやつは素人。
unicode が普及するすっと前から wchar_t は普通に使われてる。
0742デフォルトの名無しさん
垢版 |
2018/08/18(土) 14:13:23.54ID:5gN61dbI
そりゃ使われてるかどうかで言えば使われてるだろうけど。

そんなことよりも技術的な所気にならない？

問1 16bitのwchar_tで1バイト または 3バイトのEUC-JPを
扱う場合メモリイメージはどのようになるでしょうか？

問2 32bitのwchar_tで1バイトのEUC-JPを扱う場合
メモリイメージはどのようになるでしょうか？

答えわかる？意外すぎてびっくりするよ。
0745デフォルトの名無しさん
垢版 |
2018/08/18(土) 14:33:57.87ID:KC80I9ck
>>744
コンパイラとか libc を設計する奴以外は内部実装関係ないやろ。内部実装に依存したら移植性が無くなる。
知りたかったらlibcのソース嫁。最近の linux の glibc ならUCS4に統一。昔のunixだと EUCコードそのまま16ビットでフラグ付きで入れてた。
0746デフォルトの名無しさん
垢版 |
2018/08/18(土) 14:42:51.01ID:5gN61dbI
> 昔のunixだと EUCコードそのまま16ビットでフラグ付きで入れてた。
それはwchar_tが32bitってことかな？
16bitでは不可能だよね？
0747デフォルトの名無しさん
垢版 |
2018/08/18(土) 14:48:48.76ID:/4eOy7p1
wchar_t自体はcharset/encoding独立だとしても、実際にEUC-JPを格納する実装が
存在していたとは知らなかったな。
0748デフォルトの名無しさん
垢版 |
2018/08/18(土) 14:55:58.85ID:KC80I9ck
>>746
知らないなら、変な知ったかぶりせずに黙ってるべき。
実装によって色々差があるけど最上位ビットとかをフラグに使用して16ビットに詰め込んでたんだよ。
うろ覚えだけど、例えば
0021-007e に ascii
00a1-00fe に jis kana
2121-7e7e に 0208
a1a1-fefe に 0212
とか、そんな感じ。
0749デフォルトの名無しさん
垢版 |
2018/08/18(土) 15:23:20.80ID:bNUWoVQ1
やけに wchar_t にこだわる（かみつく）奴がいるけど理由がわからん
内部がどういうエンコーディングかはプログラマは意識する必要ないのに
0750デフォルトの名無しさん
垢版 |
2018/08/18(土) 15:32:18.21ID:KC80I9ck
>>747
16ビットでなくて 32ビットで良いなら、今でも FreeBSD は EUC-JP をそのまま wchar_t に入れてる。
32bit なのでフラグ操作とかもなくて生のまま 0x008fa2be とか 0x00008ea0 とか。
0751デフォルトの名無しさん
垢版 |
2018/08/18(土) 16:04:03.91ID:M4v7ary7
低学歴低知能のｸｸｿﾆｰﾄどもや底辺ﾄﾞｶﾀどもは
自分がどんだけ知恵遅れなこと書いてるのか
なかったことにししてる

ｻﾏｰﾀｲﾑｽﾚでも同じだからな
ｺｲﾂﾗ
0752デフォルトの名無しさん
垢版 |
2018/08/18(土) 19:02:32.17ID:IyhzoKxX
>>742
漏れの知ってる答えは
１も２もそういうコード書く奴はクビ
0758デフォルトの名無しさん
垢版 |
2018/08/24(金) 18:18:47.09ID:mVdVBkdF
すいません 文字コードについて教えてほしいことがあります マジものの初心者なんですがどうかおねがいします

Unicodeの一種（？）で65280文字ある種類のものを、なんと呼ぶのでしょうか。
（最初の方は透明に見えるフォントで始まり、最後の方は全角英数などが割り当てられています
http://www.m-hoz.com/jsp/unicode.jsp?Bgn=0&;End=65536
このページと想定しているものはまったく同じです）
WikipediaなどでUnicodeの記事を読んだのですが、バージョンや面やサブセットなどたくさんの種類があり
私が利用したいと思っている65280文字を含むUnicodeの一集合のことをなんと呼べばいいのか分かりませんでした。
というか 正直、Unicodeというのは65280文字（0xFFFF番目ですから）までしかないものと思っていましたが
なんかそれを遥かに凌ぐ量の文字が収録されていると書いてあり 余計に混乱してしまいました
文字コードに関する知識がほとんどなく おかしい文章になってしまいすいません よろしくおねがいします。
0759デフォルトの名無しさん
垢版 |
2018/08/24(金) 18:42:02.68ID:NFTQhSIK
65536-256
0761デフォルトの名無しさん
垢版 |
2018/08/24(金) 19:19:57.24ID:wXpFbMeR
>>758
基本多言語面
https://ja.wikipedia.org/wiki/%E9%9D%A2_(%E6%96%87%E5%AD%97%E3%82%B3%E3%83%BC%E3%83%89)#%E5%9F%BA%E6%9C%AC%E5%A4%9A%E8%A8%80%E8%AA%9E%E9%9D%A2

Unicodeは似てる文字を一つにまとめて約6万5000文字（16bit）に収めるぞーって
言っていたのが、案の定無理だと破綻し（だから言っただろうがバカメリケンが）、
21bitを使い最大で約111万文字収録可能になってる
最新のUnicode 11.0 では13万7439文字が収録されてる
0762デフォルトの名無しさん
垢版 |
2018/08/24(金) 19:24:24.02ID:wXpFbMeR
Unicodeはもはや文字コードじゃない
文字シーケンスというべきだろう
複数の文字を使って1文字を表している
0763デフォルトの名無しさん
垢版 |
2018/08/24(金) 20:11:02.68ID:mVdVBkdF
>>761
「基本多言語面」
ありがとうございます！ すみません。言い方がボケナスで余計な労力をお掛けしました。
この言葉が知りたかったのです。

ちなみに極めてどうでもいいことですが
マインクラフトというゲームのフォントを変えたいと思っており
その為のフォントおよび文字コードの勉強していこうとしていたところでした。
0764デフォルトの名無しさん
垢版 |
2018/08/25(土) 06:50:31.16ID:gxBSyOuw
HTML のフォント指定は、こういう感じ。
「html フォント指定」で検索！

HTMLの文字コードは、UTF-8

<font face="候補1,候補2,候補3">フォントを変更します</font>

<p><font face="ＭＳ Ｐ明朝,ＭＳ 明朝">これは明朝体を指定</font></p>

それとも、マインクラフトはHTMLじゃないのか？
0765デフォルトの名無しさん
垢版 |
2018/08/25(土) 07:11:24.89ID:5ar3I1wr
>>762
合字はそうすることが自然だからそうなってるんだと思ってるんだけど、全部個別に文字コードを割り当てたほうがいいってこと？
0766デフォルトの名無しさん
垢版 |
2018/08/25(土) 09:10:13.50ID:2/0/KxdV
>>764
マインクラフトのフォントは
./assets/minecraft/textures/font
というディレクトリに16ドットフォントが16列16行配置されたPNG形式の画像が0xFF枚格納されてる
というような仕様になってますね
HTMLはあんまり関係ないです。
0768デフォルトの名無しさん
垢版 |
2018/09/10(月) 17:53:51.80ID:wWJP5KoS
Unicodeの公式サイト（http://unicode.org/）で，Unicodeの最新安定バージョンがなにかを調べるにはどこを見ればいいんですかね。
今11.0だそうですが，他サイトの情報なので，なるべく本家本元の情報が欲しいんです。
0769デフォルトの名無しさん
垢版 |
2018/09/10(月) 19:07:05.53ID:Xr++yj7Q
>>768
ちゃんとメニューを見よう。

サイトの左側のメニューから The Unicode Standard プルダウンの中にある Latest Version を選べばよい。
というわけで、現時点では 11.0 が最新という認識で正解です。
0771デフォルトの名無しさん
垢版 |
2018/09/12(水) 15:59:00.59ID:DAmcAY4y
Unicodeって，なんで初めに多バイト文字のことを考えなかったんだろう。
そもそも多バイト文字を統一するために設立したようなもんなんだから，
2^16では済まないことくらい予測できた筈なのにね
0773デフォルトの名無しさん
垢版 |
2018/09/12(水) 16:39:35.87ID:1j3hWxX7
>>771
アルファベット二十数文字しか使ってない奴らが
六万文字もあれば世界中全部の文字カバーできるよな
って雑に考えたから
0774デフォルトの名無しさん
垢版 |
2018/09/12(水) 17:33:44.29ID:lrlSblfi
>>773
ちょっと漢字の知識があっても漢字が５万字くらいだろ？
漢字で5万使って残り1万5千だな、余裕だろって感じだったんだろうな
0776デフォルトの名無しさん
垢版 |
2018/09/12(水) 22:25:38.00ID:yfKtIfo2
で、ﾊﾞｶは5ﾏﾝの漢字全部読めるの？
で、ﾊﾞｶは5ﾏﾝの漢字全部書けるの？
で、ﾊﾞｶは5ﾏﾝの漢字全部使えるの？
で、ﾊﾞｶは5ﾏﾝの漢字全部使ってるの？
0777デフォルトの名無しさん
垢版 |
2018/09/12(水) 22:30:26.22ID:yfKtIfo2
卜部の卜
トﾅｶｲの卜
見た目でも違いなんかまったくわからない
0778デフォルトの名無しさん
垢版 |
2018/09/13(木) 02:31:52.28ID:cMp+qWRQ
でもコンピュータに合わせて世界を
作り変えることができるなら、
65535文字に抑えるだろうな

サマータイムもない世の中
文字も16進数が基本かな
電気の流れもマイナスからプラスへだ
0779デフォルトの名無しさん
垢版 |
2018/09/13(木) 08:51:11.89ID:wI3BpnoI
君が代によれば、天皇の世は八千代続くので、
元号の合字も８０００個必要になる。
Unicodeのどこかの面にまとめて確保できないものだろうか。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況