文字コード総合スレ Part10 [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
■これまでに行われた議論
・WinでCP50220 は Unicode からマルチバイト文字への変換でいわゆる半角カタカナを全角カタカナに置き換え
内部的には Unicode -> CP932 -> CP5022x って変換な気もする
・人名をソートかけたらバストサイズ順の並びになる?
・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のほうが化けにくい ・中国語の簡体字では、へんやつくりが簡略化されるなら、その文字も自動的に簡略化して表記する国家規格が有る
・中国語の「?心」簡化政策によると「?(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サニタイズが面倒になるのか ・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の人にはそれがわからんのですよ。 ■単語一覧
・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とか。 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/ 文化庁の文化審議会漢字小委員会は16日、漢字の手書き文字について、「とめる」か「はらう」かなど、細部にこだわって正誤を判断せず、多様な字形を認めるべきだとする指針の中間報告案をまとめた。 明日から松江でWG2らしいけど文書非公開だと流れが追えなくてつまらんな Unicodeおじさんがミラーしてくれた
http://www.unicode.org/wg2/docs/
Nushuが1b170からになってるってことはKana Supplementがそこまで広がったのかな >>15
これか。
http://srad.jp/story/15/10/20/0510245/
ただでさえ漢字が多すぎて困っている。それをさらに増やすような法務省の莫迦に対する歯止めとして期待。 3-5と9はもうテンプレから外していいんじゃないかなって話かと
20も言うように古いし更新されてないしどういう文脈の話かわからないのもあるし
レス番指定してるレスが混じってるけどPart何スレかもわからないしよく見ると色々あれ >>3-5はいらないけど、しれっと>>9を紛れ込ませるのは許さん >>9は議論の軌跡としては正しいのかも知れないけど内容が間違いだらけなので消した方が吉 絵文字馬鹿のOむかつく
とっとと干されりゃいいのに ほんとにな
他に実績ない絵を字として登録してない?
そのうちLINEスタンプとか報道写真も登録するんじゃねえの。
一方で互換性ガー言って過去のミス登録を修正しないし。
WAVE DASH例示字形ですら25年かかるという無能揃いの組織。
過去版との互換性なんかとうの昔になくなってるのに。 Unicodeコンソーシアムがアレなのは否定しないってか同意だが
WAVE DASHの問題はMSが独自の変換表を使ってるからなので
正直例示字形だけ直されてもあまり意味がってか字形だけならWindows Vista以降修正されてるし
いやそりゃ正しい波の形になったから気分はすっきりするけど。 ってか全角チルダのほうの字形(?)を上に寄せてくれんかな。 >WAVE DASHの問題はMSが独自の変換表を使ってるから
どうしてこういう見え透いた嘘を平気でつけるんだろうか >>29
無知?それとも俺には問題ないという青年の主張? クローゼットの中にそういうハンガーみたいな金具たくさん入ってるけど
どういうときに使えるのか未だにわからない。 肩の厚みのあるハンガーをたくさんかけると、
スペースが無駄になるので互い違いに高さを変える。 向きが90度ずれない?
S字のを2個連結すれば戻るけど2個使い前提の道具なの? あれはスペースの有効活用が優先で
向きがずれる(逆になる)のは承知で使うんじゃないか?
>>31
しかし、チルダの全角形を本来の意味(?)で必要としているユーザーはどれだけいるんだろうかと思う スレ違いかもしれんが
ネットで、ある日本語のテキストファイルを見たら化け化けだった
3分の1くらいのみ見れる
これをブラウザで簡体字中国語を選ぶと見れるという書き込みを見つけたので、
そうしたら見れた
これはどういうこと?
中国語扱う人が日本語をGB2312でエンコードしてたってこと? >>39
使用頻度は気にしなくていいんだよ
全チルがあればそれでいい
あとはマッピング直してくれれば。 お国自慢絵文字か。文字コードに押し込もうというわけでなければ、
ありふれたご当地ゆるキャラを何匹か並べたら大体同じ趣旨の日本版になるな。 絵文字は文字以上に定義も難しいしキリがないからユーザー外字領域に閉じ込めておけばよかったのに。 さすがに、外字領域での大規模な運用ぐらいはされてないと押し込みの提案も出ないんじゃなかろうか Unicode 10.0あたりになったら収録されるんだろうか? GB2312に平仮名、片仮名が収録されているというのも不可解なもんだ。
あいつら反日、嫌日のはずなのに。 シュエエアィサィ的な使い方を想定していたんじゃなかろうか しかも簡体字フォントの仮名のデザインが脱力。
日本語版Windowsにも標準で付いている。たぶんMacにも。 韓国のKS C 5601(KS X 1001)にも平仮名、片仮名入ってるし
単にJIS C 6226(JIS X 0208)の構造コピーして必要なところ以外はそのまま放置しただけなんじゃ……。 GBKはX 0208をベースに作った
韓国はX 0208をパクった上に起源を主張し出した Androidでのダウンロードしたアプリのapkファイルを取り出してESファイルエクスプローラというアプリでapkファイルの拡張子をzipにして中身を見てるんだけど文字化けしてみえない
どの文字コードにしても見えない すみません
今ISO-IRの資料を収集してるんですが
http://www.itscj.ipsj.or.jp/ISO-IR/232mapping.txt
の対応表ファイル持ってる方いらっしゃいませんか?
PDFはサーバーにデータ残ってるみたいで保存出来たんですが
他は消されちゃったみたいなんですよね。。。 >>66
そう、これです!
ありがとうございます!
ずっと
http://www.itscj.ipsj.or.jp/〜
と
http://kikaku.itscj.ipsj.or.jp/〜
の方ばかり探してたんですが、
https://の方にまだあったんですね、気付かなかった。。。
ありがとうございました。 gbkの ひらがな はEUC-JPと互換性がある
ひらがなが含まれてるgbkなテキストファイルを自動判別すると
EUC-JPと認識される お前かお前の使ってるクソソフトが認識したことを
さも普遍的であるかのように「認識される」と書かれても >>70
EmEditor と 日本語しか対応してないものはすべて同様なんだが
英語圏の方がまとも >>73
ANSI(SJIS) / JIS / EUC(EUC-JP) / UNICODE / UTF-8
だけしか対応してないんなら仕様だろうけど
EmEditorはgbk / big5も表示可能だが自動識別はダメ EUC系の自動判別には限界があるってだけの話じゃないのそれ 文字コードの仕様の話と製品の仕様(実装)の話をごっちゃにしないでください 文字化けし辛い・自動判別に強いという意味ではISO-2022-JP最強だな プログラミングやマークアップで場面によって"utf8"だったり"utf-8"だったり"UTF8"だったり"UTF-8"だったりするのは何とかならんのですかね >>81
それな。
動きおかしいと思ったらハイフンついてたとかある。 >>79
https://ja.wikipedia.org/wiki/ISO-2022-JP
独自拡張しすぎだろ
utf-8最強なのだが
Win9x時代に ANSI(s-jis) + utf-8(※s-jisに無い文字をutf-8にしてる) なんてファイル作る糞ソフトがあったな >>82
utf-8に関しては-が付いてておかしくなる方がおかしい。 そんなのはプログラミングやマークアップでの指定方法の仕様次第
おかしくなると思うのはバカ >>74
がまんしないで、要望をかいたほうがいいとおもう
どういうgrepがいいのかな?
コマンドですか? GUIですか?
コマンドなら、画面の環境に依存したりする >>89
検索対象のデータだけでなく、
引数や端末のencoding systemも関係するからねえ。 「して欲しい」じゃなく自分でやってみればいいのに。 UTF-8って日本語はほぼ3バイトだと思っていいんだっけ?
仕事仲間がそう言ってたけど不安。 そういう曖昧な表現なら答えはyesでありnoでもあるだろう iconv -f Shift_JIS -t UTF-8 file_name > new_file
サイズを比較
new_fileは、file_nameより1.5倍おおきい
# 日本人にとってUTF-8がいいわけない ほとんど3バイト
Japanese, Chinese and Korean characters are almost entirely (if not entirely) 3 bytes on UTF-8.
3バイトは、UTF-16をつかう理由になる。
the three-byteness of CJK characters is an often-cited reason to use UTF-16 instead of UTF-8.
http://forum.dlang.org/post/hum5gl$2hfm$1@digitalmars.com >>94-95
ファイルサイズの事を書くならもっと考慮すべきだな
UTF-8に変換するとどの程度ファイルサイズが膨らむのかは文書の内容により異なる
例えばこのスレの95までのdatファイルの場合は次のようになっていて
元のファイルに対してUTF-8は約 1.25 倍、UTF-16は約 1.5 倍だった
$ wc -c 1444822140-*
26775 1444822140-cp932.dat
40234 1444822140-utf16.dat
33434 1444822140-utf8.dat
ワープロなどの独自形式の内部でUCS2を使うことは十分に意味があると思う
しかしSHIFT_JISのプレーンテキストを変換する場合は、おおよそUTF-8が最大1.5倍
なのに対してUTF-16は最大2倍になる事を忘れてはいけない UTF-8で日本語が基本3バイト、はもう慣れたけど
ブログやらWikiで日本語使うと1文字につき9バイト必要なのはさすがにちょっと萎える
%E3%81%8B%E3%81%A3%E3%81%B1%E3%81%88%E3%81%B3%E3%81%9B%E3%82%93
とかたった数文字を表すのに長すぎだっての。
文字コードというかUTF-8をパーセントエンコーディング?する時の問題だけれど。 パーセントエンコーディングって単語自体が長くてめんどい。
もっと短く、パンコとかで通用するようにならないかな。 別に人が手作業でやってるわけじゃないのに
なにぶつぶつ言ってるんだろ >>94
そんな程度のことでutf-8を辞める訳にはいかない。 ■ このスレッドは過去ログ倉庫に格納されています