文字コード総合スレ Part12
■ このスレッドは過去ログ倉庫に格納されています
>> 737 誤魔化さずに、まずはこっちの質問に答えろや? できるもんならな。 お前、まとともに複数の言語と文字コードに対応したプログラムとか組んだことないやろ? 中途半端な知識で知ったかぶりしてて、引っ込みつかなくなっただけなら、謝ればすむんやで。 匿名掲示板なんだから、謝ると負けとかはないぞ、勉強して出直せばいい。 謝るのが、めんどくさかったら ROM っとけ。 しかし、あれだな。 ナロー系のデフォルトは今後 UTF-8 になっていくって話してるのに、 「ナローだと絵文字使えない」とか言い出すやつが湧くのは、どうしたもんだか。 基礎知識が足りてないのか、文脈読めないのか、その両方なのか。闇は深い。 喧嘩腰なのはいいけどレスアンカくらいちゃんと書こうよ >>の後のスペースは不要 ナロー系ってなんだ? オレオレ用語で言ってても誰にも通じない あれや、トラックに引かれて死ぬが異世界に転生 そこではなぜかチートじみたものすごい能力が・・ >>741 win32api の一部の api (文字列を与えるもの)は同一機能で W系とA系の両方が準備されていますが、 そのうちの A系のことをナロー系と呼んでいるのでは? >>735 Windowsでもロケールじゃないかな? ここで言ってるコードページってどこで設定するやつ? Linuxはロケールの設定(LANGとかLC_ALL環境変数)でja_JP.UTF-8 みたいに 言語(ja_JP)と文字コード(UTF-8)の両方をいっぺんに設定するけど 本来この2つは別の概念 Windows NT系はOSが使う文字コードはUTF-16に統一されている ロケールに相当する設定は「設定」の「地域」から「日本」等を選ぶ これはUIで使用する言語やカレンダーの書式なんかを変更するが 文字コードはUTF-16しかないので変わることはない これとシステムロケールの設定(コードページ)は別物 システムロケールの設定はUnicodeに対応してないアプリ(主にWin9x用)が どの文字コードを使っているか?を推測するための互換機能 Windows 10でこのシステムロケールの設定としてUTF-8(ベータ機能)が追加されたから、 今後は(ユーザーがUTF-8に設定していれば)ANSI系APIでもUnicodeを使うことが可能になった。 もちろんOS内部はUTF-16に統一されてるので、UTF-8からUTF-16へ変換される ANSI系APIでUnicodeが使えるようになったといっても、それはUTF-8対応で開発した新しくアプリの話 昔のSJIS前提で開発したアプリが自動的にUnicode対応に変わることはない。 Unicodeに対応してない古いアプリはASCII互換部分以外は文字化けする。 あくまで新しいアプリをUnicode対応で開発するときの選択肢の一つとして ANSI系も使えるようになりましたよーという話 これはユーザーにUTF-8に変更してもらえる(=古いアプリを使ってない)ことが前提 >>741 俺も「ナロー」がそれほど良い用語だと思ってるわけではないけど Linux,Mac,Windows で共通の良い技術用語がないので、マシな方なんだよ。 Unix系の用語だと「ワイド文字」の対義語は「多バイト文字」なんだが、これだとさらに誤解する人多いしなあ。1バイト ASCIIでも「多バイト」ってなんだ?的な。 コードページはLC_CTYPE相当であってLANGやLC_ALLではない CP932はLC_CTYPE=ja_JP.SJISのようなもの(CP932≠ShiftJISだけど) なのでWindowsのデフォルト日本語環境はmacOSやLinuxのja_JP.UTF-8とは違う それにUTF-8に対応するCP65001だけでなくEUC-JPに対応するCP20932もだいぶ昔から 前から存在している あとこの辺のロケール関係はISO C C95で規定 Windows固有の話ではない このスレの人たちはエディタで書いたソースを何で保存するの?UTF-8? 秀丸はデフォルトでSJISだったよね?(今は違うのか?) >>747 > Windowsのデフォルト日本語環境はmacOSやLinuxのja_JP.UTF-8とは違う Windowsのデフォルト日本語環境は 1. OSの文字コード・・・UTF-16統一 2. ロケール(UIやカレンダーなど)・・・日本語 3. Unicode非対応の古いアプリ用、CP932に設定 いい加減システムロケールというのは OSのデフォルトとは関係ないと認識してくれ >>748 ずっと前(Windows 2000の頃)から Linuxと相互運用するものはUTF-8 Windowsでしか使わないソースコードはUTF-16だよ Windowsでしか使わないものは少ないからほとんどUTF-8だけど あと秀丸とかとうの昔に使うのをやめた 遅くともSublime Text(2008年ごろ?)からUTF-8に統一 atomを経て今はvscode それまでは何使ってたっけ?vimとかemacsとか一時期使ってたけど そういや昔はLinuxではEUC-JPを使ってたね Win10 1803でANSI APIでUTF-8を使うようにする設定がベータで入ったけど、 結局MSは影響が大きすぎると判断したんだろう 代わりに1903で、システム全体じゃなくてアプリ単位でUTF-8を使えるようにする機能が入った ANSI APIのデフォルトがシステム全体でUTF-8になるのは5年とか10年先の話じゃないかな > ANSI APIのデフォルトがシステム全体でUTF-8になるのは5年とか10年先の話じゃないかな > 結局MSは影響が大きすぎると判断したんだろう MSじゃなくても影響が大きいってわかるわ。デフォルトをUTF-8にするのは 古いアプリとの互換性を切り捨てるってことを意味する デフォルトにしていいのは、既存のUnicodeに対応してないアプリが消え去って 互換性を気にしなくていい時代になってから。それぐらい時間がかかるのは当たり前だろう アプリ単位でUTF-8が使えるならそれで十分でしょ UTF-8用に作られたアプリは、システムロケールをUTF-8にするように マニフェストかなにかで設定できるだろうし Windows NTのデフォルトの文字コードがUTF-16に統一されてるわけだから わざわざ古いアプリの方のデフォルトを変更する理由がない システムロケール(本来は古いアプリ用の設定)を UTF-8に変更することの意味をわかってない人がいるようだから くどいようだけどまとめておく 1. システムロケールでUTF-8を設定できるようになったのはWin10 1803から 2. 日本語をSJISで使うアプリが、システムロケールがSJISになってるのを前提としていたように システムロケールがUTF-8になってることを前提としてアプリを作らなければいけない 3. つまりWin10 1803登場より前にシステムロケールUTF-8に対応してるアプリは存在しない Windowsの本来の文字コードであるUTF-16に対応してるアプリ=Unicodeや絵文字に対応してるアプリは そもそもシステムロケールの設定には何も依存しない。 今現在システムロケールUTF-8に対応したアプリは殆どないのに 互換性を壊してまで今すぐデフォルトを変更してメリットあると思う? そういう話。 これからはUTF-8前提で作られたアプリ(Linuxアプリ等)はWindowsに移植しやすくなりますよ。 これからはUTF-8前提で作ってもWindowsとLinuxに両対応出来ますよ。という話 ASCII専用の欧米ソフトは案外その設定で動いたりするんだよ ASCII圏のユーザーにとってはチェックを入れるだけでUTF-8が使えるようになる(かもしれない)便利設定 別に新しく開発するアプリのための設定というわけではない マルチバイト圏のユーザーにとっては互換性壊すだけの余計な設定だが ちなみにANSI APIでUTF-8を使う際には、パス名がMAX_PATHバイトまでしか扱えないという 重大な欠点があるのは注意な Wide APIならMAX_PATHコードユニットだから、それに比べると扱える文字数は最悪1/3になる >>753 間違い。昔から複数の文字コードで動くプログラムはある。 コードページ切り換えによって SJIS でも KOI8 でも BIG5 でも動くように作られているプログラムは、 修正無しで UTF-8 にも対応するようになる。 そもそもコードページの切り換えにちゃんと対応したプログラムはそうなってるのが普通。 SJIS専用処理とかしてるアホが作ったプログラムは、修正が必要だが、それは複数文字コード対応できてないんだから仕方ない >>757 一般論としてはそうだけど、WindowsのANSI系APIやVSのCRTが本当に全部UTF-8に対応してるんだっけ? >>759 Windows には山ほどライブラリ(DLL)があって、その中には対応できてなかったり、できてるはずなのにバグバグなやつとか多数ある。 今後のアップデートで直るかもしれないやつも多数あるけど、仕様上どうやって直すんだ?! みたいなやつもある。 一般論でしかないのは、その通り。過渡期なんだよ。 一方で Microsoft は CP_ACP はもう使うな CP_UTF8 使えとか言い出してる。 > 一方で Microsoft は CP_ACP はもう使うな CP_UTF8 使えとか言い出してる。 そりゃそうだろ。CP_ACPは古いアプリが使ってるかもしれないが それじゃUnicodeには対応できない。文字数とかサロゲートペアが 正しく判断できない。ANSI系でUnicode使うなら書き換えが必要 >>762 ACP でも UTF8 や UTF16 が使えること知らない人は引っ込んでて。 CP_ACPとかってMultiByteToWideChar以外どこで使うんだっけ コンピュータのコードなんてずっと更新中みたいなもんだけど。 MS が UTF-8 のサポートをまともに開始したのは 2017年から。 古い文字コードを捨てて,今後は UTF-8 のみを推奨ってアナウンスしたのが 2019年から。 30年が何を指すのかしらんけど、あと5年や10年くらいは待ってやれ バッチスクリプトをUTF8で走らせられるようになったの? 中で呼び出すプログラムが code pege 切り換え対応、もしくは utf8 対応ならバッチできるよ 例えば UTF-8 で以下のようなバッチを書けば、日本語Windowsでも動くよ chcp 65001 echo かな漢字 > file.txt type file.txt pause >>767 > 古い文字コードを捨てて,今後は UTF-8 のみを推奨ってアナウンスしたのが 2019年から。 古い文字コードを捨ててません。 新たにUTF-8対応を増やしただけです。 Linuxは古い文字コードを捨てましたか?捨ててないでしょう。 そんなアホなことをするOSなんてありませんよ。 >>768 それはずっと前から出来る。 少なくともWindows 2000では確認した。 ただ画面の表示がおかしくなっていただけ 処理結果はまともだった マルチバイト文字を含むコマンド引数がただの文字列じゃなくて、ファイルパスだったりすると積むはず。 ファイルパスも文字列だろ ところでなんでcp932に設定していても 絵文字が含まれたディレクトリにcdできると思う? 絵文字はcp932には含まれてない。だから使えるはずがない だけどコマンドプロンプトでcp932にしても普通にcdできる 答えは、cp932は古いアプリ用であって コマンドプロンプト自体はUTF-16で動いてるからなんだよ WindowsはNTの時代にすでに完全にUnicode対応を終えてる OSはUnicode(UTF-16)で動いている cp932とかいうのは互換性機能でOSとしては重要ではなく 互換性機能をなくすのは、それが不要になってからで十分なわけ >>770 「捨てる」っていうのが正確で無かったか? サポートをしないって意味ではなくて 「今後は書かれるプログラムは古い文字コードをサポートする必要はない。UTF-8 だけ排他的に使用することを推奨する」 という方針を打ち出したんだよ。もう前のことなのでニュース記事のリンクとか出せないけど、かなり話題になった。 開発者ドキュメント等を読めば買いてると思う。 >>771 わかってて言ってるんじゃないかと思うけど、重要なのは echo の行ではなくchcp 65001 の話。 これで TYPE の行のように正しく画面表示されるし、他のバッチから呼び出されるプログラムも UTF-8 の切替わる。 pause の行のように言語が日本語から英語に切替わってしまうので、メッセージとか日本語じゃないと困る人には駄目な方式なんだが >>773 お前は、バッチファイルすらまとも使ったことないだろ? 内部コードと外部(入出力)コードの区別すらまともについてないくせに、いちいちコメントすんな。 Windowsの内部コードがUTF16のことなんて全員わかってるんだよ。 みんなが議論しているのは外部コードのはなし。コードページとかUTF-8とかも全部、外部コードに何を使うか。 バッチファイルの文字コードも外部コード。 マイクロソフトは外部コードを UTF-8 に統一する方向で動いてるって話をしてる。 >>774 > 「今後は書かれるプログラムは古い文字コードをサポートする必要はない。UTF-8 だけ排他的に使用することを推奨する」 前からUnicode(UTF-16)推奨だったじゃん。 今後は書かれるプログラムは古い文字コードをサポートする必要はないのは UTF-16でも同じことで、古い文字コードをサポートする必要なんてなかった 単にANSI系でもUTF-8が使えるようになりましたってだけだよ >>776 > マイクロソフトは外部コードを UTF-8 に統一する方向で動いてるって話をしてる。 そんな動きないよ 今だって標準はUTF-16だし、UTF-8もサポートしたと言うだけの話 > みんなが議論しているのは外部コードのはなし。コードページとかUTF-8とかも全部、外部コードに何を使うか。 違うよ。コードページは古いアプリが使うコードのことだよ 古いだの新しいだのそういう曖昧な言葉を使うのは良くない 入出力時のデフォルトコードページの話だから古いか新しいかなんて関係ないんだけどな。 いい加減みんなこのバカ相手するのやめようぜ。 マイクロソフト謹製のPowerShellは完全にコードページ依存だよ。 MSYSなどUTF8で出力する伝統的な実行バイナリとうまく共存できない。パイプが積む。それが現実。 さすがに、このスレにいて Windowsの「メモ帳」アプリのデフォルト文字コードが「 UTF-8 (BOM無し)」に変更されたことを知らない人はいないだろ。 これはMSが UTF-8 BOM無しを今後の標準とすることに舵を切った結果だよ。 これが UTF-16 だったり BOM つきだったりしないのは、単なる気まぐれじゃない。 BOM付きじゃなくてBOM無しUTF-8がデフォルトになったのは驚いた そっちに舵を切ったのはそうだろう だがExcelでBOM無しUTF-8なCSVが扱えないとか、リソースコンパイラで BOM付きUTF-8すら自動判別してくれないとか個々のアプリはまだまだ対応不足 >>780 厳密に言うならANSI系のAPIを使ってるアプリのこと このAPIは元々Win9x用で(UTF-8に対応が発表されるまで) Unicodeに対応してない古いアプリ用だった つまりUnicodeに対応しているアプリは UTF-16を使っていたということ もちろん内部文字コードとしてUTF-8を使ってるアプリもあるだろうが それは今も昔も変わらずUTF-8が使える そういうアプリはOSへ処理を渡すときにUTF-16に変換して渡してる その変換は正しく作っているなら自動的に行われるのでさほど面倒ではない なのでアプリ開発側からすれば、そんなにメリットはない これからはANSI系APIも使えますよーと今更言われた所で 元からUTF-8を使ってるアプリは、UTF-16への(自動)変換が 省略できる程度の意味しかない 今どきWindowsのAPIにバリバリ依存して作ることなんてないしね >>783 > さすがに、このスレにいて Windowsの「メモ帳」アプリのデフォルト文字コードが「 UTF-8 (BOM無し)」に変更されたことを知らない人はいな > これはMSが UTF-8 BOM無しを今後の標準とすることに舵を切った結果だよ。 なあ。お前。メモ帳以外の事例は存在するか? 一テキストエディタにすぎないメモ帳のデフォルトが 変わった程度で騒ぎ過ぎだよ はぁ? クロスプラットフォームで開発されている実行バイナリはC/C++案件が多いから、WindowsのAPIにバリバリ依存だよ .NETなんてLinuxやmacOSで動かないだろ >>786 > 今どきWindowsのAPIにバリバリ依存して作ることなんてないしね Windows の API 使わずにプログラムとかww それこそ fopen() とかの標準Cライブラリこそコードページ依存だろ。もしかしてそれすら知らない? Mac 使いですか? それとも Java屋さん? Windows の API まともに知らないやつが プログラム版で Windows について語ってんの? > Windows の API 使わずにプログラムとかww え?知らんの?そういうのは言語やライブラリが解決してくれるんだよ。 .NET フレームワークとか、nodeとかrubyとか Windows APIを使わないことなんて当たり前 > .NETなんてLinuxやmacOSで動かないだろ 動くじゃん EcxelがBOMなしのCSV読めんからな メモ帳がBOM無しでも関係ないな それ以前に .Net デフォルトだとコードページ依存じゃないかwww ruby は Windows のプログラムじゃないし。 node って何? もしかして Node.js のこと? まさか JavaScript 基準で Windows の文字コード語ってたの? さすがに、それはないよね...。 node というのは聞いたことない、もしくはどれを指すのが不明なので教えて。 >>745 話題持ち込んじゃった人だけど分かりやすい ありがとう >>793 ああ、今どきのWindowsプログラムを知らんのね 例えばvscodeはJavaScriptで出来てるんだよ .NETがコードページ依存って何を言ってるんだろうか > .NETがコードページ依存って何を言ってるんだろうか 入出力用の文字コードの概念がないやつには一生理解できないだろう(確度の高い予測) 他の人のためにリンク張っとく https://docs.microsoft.com/en-us/dotnet/api/system.text.encoding.default ちなみに Linux とかでも動くオープンソース版の .NET Core はコードページないので、UTF-8 (BOM無し)になる。 >>797 そんなの出されても意味がないなぁ。 言語の内部コードと、外部コードの違いわかってる? 例えばPythonの文字コードはUTF-8なわけ それをStreamRecodeを使って自動的に外部文字コードに変換する時 https://docs.python.org/ja/3/library/codecs.html#streamrecoder-objects Pythonの文字コードはSJISだ!コードページに依存してるんだ!なんて言わないでしょ .NETも内部の文字コードはUnicodeなわけ 外部への文字コードへの自動変換を備えてるけど それはほとんどの言語で標準的に持ってる機能なわけ そういえば、関係ないけど vscode も UTF-8 BOM無しが規定文字コードだね。 メモ帳だけじゃなくてテキストエディタは UTF-8 ってことか。 >>797 > ちなみに Linux とかでも動くオープンソース版の .NET Core はコードページないので、UTF-8 (BOM無し)になる。 デフォルトで入ってないだけ PowerShell on Linux(Mac)でShift-JISを扱う https://blog.shibata.tech/entry/2016/08/22/231538 >>798 > 言語の内部コードと、外部コードの違いわかってる? お前がわかってないのは知ってる。ソースコードの文字コードを内部コードと勘違いしてるとか Python の内部コードが UTF-8 だと思ってるあたり素人丸出し。 Python の内部文字コードはかなり昔から UTF-32 (UCS4) だよ。それ以前は UCS2。 >>800 > デフォルトで入ってないだけ デフォルトのエンコーディングの話してたの忘れたの? 入出力用の文字コードが切り換えできるのは当り前で、そのデフォルトが何かっていう話をしてるんだけど >>801 ID:3uc6Yjpoは何を言ってるのか分からんのでほっとくとして、 Python 3.3からはメモリ使用量節約のため、latin1, UCS2, UCS4の自動切り替えな https://www.python.org/dev/peps/pep-0393/ >>802 だから.NETのデフォルトはUnicodeだろ .NETアプリが世界中の文字に対応してるってわかってますかー? >>803 正確にはそうだね。 ややこしい話しても絶対ついてこれないだろうと思ったの最終的に UTF=32 に落ちるのでいいかと思って簡略化しちゃった。 そこまで、ちゃんとわかってる人がいて良かった。訂正サンクス。 レベル低いの混ると、ついついレベル低い回答になってしまう。 互換性のせいでコマンドプロンプトの仕組みが複雑だから勘違いしてるんだろうけど コマンドプロンプト自体はUTF-16で動いてる そうでなければUnicode文字を使ったファイル名とかが表示できるわけがない それに対してコンソールアプリケーションはUnicode(UTF-8、UTF-16、UTF-32いずれにも対応)で 出力するモードとANSIで出力するモードを選べる Unicodeで選んだらOSによってUTF-16に変換されてコマンドプロンプトに出力される ANSIモードで出力した場合、OSが自動的にUnicodeに変換してコマンドプロンプトに出力する このANSIモードからUnicodeに変換するときに利用する情報がコードページ コンソールアプリケーションは、どれでも好きな文字コードで出力してくださいってだけだよ コードページの情報を利用するもしないも自由 コードページの情報を無視してSJISで出力することだって出来る まあそんな事するとコマンドプロンプト上では文字化けするがファイルに出力すればなんの問題もない Unicodeに対応してるアプリはUnicodeモードで出力するだろうね 作り込んでるアプリなら、コードページに従うだろうねってだけの話 win10 コマンドプロンプトで chcp 65001 でも >>810 は化けたわ >>810 Windows 10 のIEで表示できた 色はつかんかったけど もちろんEdgeなら色付きで表示できた >>811 フォントの問題だからね echo その文字 > test.txt とかやってファイルに書き出したら cmd /UのUnicodeモードでUTF-16LEで問題なく保存されたよ もちろんcmd /Aだとchcp 65001でUTF-8にしたら保存される。 × フォントの問題だからね ○ 表示周りの問題だからね データ自体は問題なく扱えるといいたかった Clarify guidance for use of a BOM as a UTF-8 encoding signature https://www.unicode.org/L2/L2021/21038-bom-guidance.pdf ・Do not use U+FEFF as a ZWNBSP character; use U+2060 WORD JOINER instead. ・Include a BOM if one is known to be required by a targeted protocol. ・Otherwise, include a BOM when authoring a UTF-8 text file that contains non-ASCII characters, is not targeting a specific protocol, and may be opened by applications that will not assume UTF-8 by default (this is useful on systems like Microsoft Windows where some applications assume text files to be encoded with the Active Code Page). ・Otherwise, do not include a BOM. >>813 /u スイッチで出力されるUTF-16LEはBOMなしなんだな 開けないエディタもあった >>815 要約:明示的に必要とされる場合以外は UTF-8 に BOM 入れるな。 そうでない場合は、非ASCII文字を含み、特定のプロトコルを対象としておらず、デフォルトでUTF-8を想定していない アプリケーションで開かれる可能性のあるUTF-8テキストファイルを作成するときに、BOMを含めるようにしてください (これは、Microsoft Windowsのように、一部のアプリケーションがテキストファイルをActive Code Pageでエンコード することを想定している場合に有効です)。 >>816 BOMがなにか知っていれば、そんな感想はでてこないはずなんだがな BOMっていうのは文字コードが「不明なモノ」を認識するためのものだよ 最初から「UTF-16である」と決まってるなら当然BOMはない 出力はUTF-16と決まってるのだから当然BOMは不要 それを文字コードが決まってないファイルに 出力したお前がつけるべきもの ファイル形式によってはUTF-16と決まってる場合もあるだから 勝手につけるようなことはしない >>819 というか、UTF-16 における BOM って Byte Order Mark という本来の意味の方が大きいと思いますが もっとも私はアプリ内では全部例外なく UTF-32, win32api に渡すときは UTF-16 に変換, コンテンツの外部表現は UTF-8 にしていますけれども >>821 BOMっていうのは文字コードが「不明なモノ」を認識するためのもの、というよりは、エンディアンを知らせるためのものでは?BOM の意義はそちらの方が優勢では? 規格では UTF-16LE はBOM付けない UTF-16BE はBOM付けない UTF-16 はBOM必要 これらは別物なので混同するのは良くない。 >>819 事実を明示しただけなのに、何ドヤってんだよ 819はUTF-16にBOMが必要という常識すら知らない素人。 UTF-16にBOMが必要なら、なぜついてないのか説明してくれ >>823 規格書ぐらい読みましょう https://www.unicode.org/versions/Unicode12.0.0/UnicodeStandard-12.0.pdf The UTF-16 encoding scheme may or may not begin with a BOM. However, when there is no BOM, and in the absence of a higher-level protocol, the byte order of the UTF-16 encoding scheme is big-endian UTF-16 のエン コ ーデ ィ ン グ方式は、 BOM で始ま る こ と も 、 そ う でない こ と も あ り ます。 し か し 、BOM がない場合、 ま た、 上位プ ロ ト コ ルがない場合、 UTF-16 符号化方式のバ イ ト 順序はビ ッ グエンデ ィ ア ンです。 ちょくちょく >>823 みたいな読解力ない人が沸くよね なんでだろ 要するに「UTF-16」のパターンは5種類あるってことだね UTF-16BE 00 4D UTF-16LE 4D 00 UTF-16 BOM(BigEndian) FE FF 00 4D UTF-16 BOM(LittleEndian) FF FE 4D 00 UTF-16 BOMなし(=BigEndian) 00 4D ビッグエンディアンとリトルエンディアンの2つだけだよ あとはBOMがあるかどうかだけ base64エンコーディングを加えればバリエーションはさらに増えるよ よかったね >>829 五番目と最初は全く同じバイト構成になるので4種類が正解。 BOMなしの UTF-16 は実質 UTF-16BE の別名に過ぎない。 BOMはパターンじゃなくて追加のシグネチャだよ もしこれがHTMLだとしてUTF-8というメタタグがない場合 それはUTF-8とは別のパターンになるかと言ったらそうはならない パターンとしては同じUTF-8であり シグネチャがあるかどうかの違いでしかない >>837 うわなつかしい、俺のアドレスもあったw ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる