VARCHAR(X)やINT(X)の「X」は何を表しているのか - Qiita
はじめに 新人研修にてLaravelを使っている時のお話です。 テーブル設計を行う時にデータ型とサイズを決めなければなりませんでした。 その時に、例えば、INTの(X)のXは何を表しているのか正確に理解していなかったので、この機会に使用頻度の高いCHAR型やVARCHAR型などの文字列を格納するデータ型も含め、調べたいと思いました。 この記事を読み終えたあなたが適切にデータ型やサイズを決めることができることをこの記事の目標にしたいと思います。 ちなみにQiita初投稿です(なんか緊張する...)。 検証環境 macOS Catalina ver 10.15.7 Docker ver 20.10.5 docker-compose ver 1.29.0 Laravel ver 7.30.4 MySQL ver 8.20.3 内容 「ユニコード(Unicode)とは」 その前に、まず「文字コード
ZIP中のファイル名の文字化け - @tmtms のメモ
こんな記事がありました。 gihyo.jp これはMacユーザー用の書籍の宣伝記事らしいのですが、「Windowsを使ってる人のためにMac側がひと手間かけてあげよう」なんて殊勝なことをマカーが言うとは時代も変わったもんです。（[追記] はてブのコメントを見たらさすがマカーという意見が並んでて安心しました） まあ私はWindowsユーザーでもMacユーザーでもないのでどうでもいいのですが、文字化けなネタなので食いついてみます。 記事中に、「付物出稿.zip」というファイルを開いた時の画像が載ってます。 文字の並びからして、UTF-8文字列をシフトJIS(CP932)とみなして表示してしまった文字列でしょう（「繧ｫ繝上ｙ繝ｼ繝輔か繝ｫ繧ｿ繧･」の元の文字は「カバーフォルダ」で、「蟶ｯ繝輔か繝ｫ繧ｿ繧･」は「帯フォルダ」）。 つまり、Macはファイル名をUTF-8でZIPに書き込み、Wi
zip ファイル解凍時の文字化けに関する情報 - Cube Lilac
CubeICE の利用動機の一つとして Mac などで作成された zip ファイルを解凍する際に文字化けしない と言うものが挙げられます。この記事では、なぜ文字化けが発生するのかと言う基本的な情報から、Windows における主要な解凍ソフトの対応状況までを簡単に紹介していきます。 必ずしも UTF-8 の zip ファイル解凍時に文字化けする訳ではない Mac で作成された zip ファイルを Windows で解凍すると文字化けする原因は、Mac （Windows 以外） で採用されている文字コードが UTF-8 なので、日本語用 Windows で採用されている Shift_JIS (CP932) と異なるからと言われます。ただ、Windows 標準の解凍機能を用いた場合でも、必ずしも UTF-8 の zip ファイルで文字化けする訳ではありません。例えば、CubeICE には UT
C++標準化委員会、ついに文字とは何かを理解する: char8_t - Qiita
C++ Advent Calendar 2018 この記事はC++ Advent Calendar 2018 15日目の記事です。 14日目: VTKライブラリ 16日目: C++のエラー処理との付き合い方 当初見積もりよりも大幅に長い記事となり、投稿したのは12/22で1週間遅刻です。すみません。 お知らせ cpprefjpにchar8_t型追加について解説を書きました。ぎゅぎゅっとコンパクトに、また査読を受けて中立的な表現で書いていますので、よければどうぞ。 UTF-8エンコーディングされた文字の型としてchar8_tを追加 - cpprefjp C++日本語リファレンス 追記 全ての開発者が知っておくべきUnicodeについての最低限の知識 - GIGAZINE Unicodeについて簡潔にまとまってるいい記事を見つけました。 Caution この文章には以下の要素が含まれます。苦手
UTF-8のテーブル(MySQL5.6)に竈門禰󠄀豆子が格納できない問題を調べてみた - Qiita
竈門禰󠄀豆子をMySQL5.6のテーブルにinsertしようとすると正しく格納できず、竈門禰となってしまうケースがあるという話を聞き、調べてみました。 実践 まずは試しにやってみます。 mysql> show create table verification\G *************************** 1. row *************************** Table: verification Create Table: CREATE TABLE `verification` ( `name` varchar(100) COLLATE utf8_bin DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin 1 row in set (0.01 sec) mysql> inse
nginxで静的jsonファイル配信時に日本語が文字化けしないようにする
androidアプリ開発時に、volleyを使ってjson形式のapiを取得する処理を書いていたのですが、jsonに日本語が入っていると文字化けする現象に遭遇しました。 調べてみるとapiのレスポンスヘッダーにContent-Typeが正しく指定されていない模様。 自前で用意したapiだったのでnginxの設定を変えて、正しくContent-Typeを指定するように修正したところ、文字化けが直りました。 /etc/nginx/mime.types にjsonを追加# sudo vi /etc/nginx/mime.types types { text/html html htm shtml; # ・・・・ application/json json; }jsonの文字コードがutf-8になるように指定server { listen 80; # ・・・・ include /etc/nginx
Content-type:text/htmlのcharset指定はUTF-8,utf-8,utf8どれが正しいの？調べてみた。 · DQNEO日記
Home Subscribe UTF-8? utf-8? UTF8? utf8? 気になったので調べてみました。 結論 公式名称は "UTF-8" である。 UTF-8, a transformation format of ISO 10646 大文字小文字は区別されない。 UTF-8でもutf-8でもどちらでもいいようです。 " HTTP character sets are identified by case-insensitive tokens. " Hypertext Transfer Protocol -- HTTP/1.1 したがって、 Shift_JIS/shift_jis EUC-JP/euc-jp どちらでもＯＫということになります。 気になるあのサイトでは？ 世の中的にはこうなっていました。(2011/8/17現在)
本当は怖くないCP932 - Qiita
先に結論 CP932 は、Shift_JIS の独自実装 符号化文字集合がいろいろ拡張されている 拡張文字の有無で、Shift_JIS と判別可能 CP932ってなあに? 実はいろいろある Microsoftコードページ932 IBMコードページ932 PC-9800仕様OEMコードページ932 Windows-31J(MS932) Microsoftコードページ932 Microsoftが、MS-DOS 用に作った Shift_JIS の実装 IBMコードページ932PC-9800仕様OEMコードページ932 IBM、NECが作った、Microsoftコードページ932 の拡張 Windows-31J(MS932) Microsoftが互換性確保の為に、IBM、NECの拡張を吸収した、Windows 用の CP932 CP932 といったらほぼほぼこれを指す MS932 は、Java で
Linux/UNIXでファイルの文字コード(UTF-8 or Shift_JIS or EUC-JP…)を確認する | 俺的備忘録 〜なんかいろいろ〜
Linux/UNIXで、指定したファイルの文字コード(UTF-8とか、EUC-JPとか)を調べる場合は、以下のような方法がある。 1.fileコマンドで調べる UTF-8か、EUC-JPなのか、それともShift_JISなのか… 日本語のファイルだとはわかっていて、その違いを調べるだけであれば、fileコマンドで事足りる。 以下のように、「-i」オプションを付与してfileコマンドを実行することで、文字コードを調べることができる(Shift_JISのみ、「unknown-8bit」として出力される)。 file -i ファイルPATH blacknon@BS-PUB-UBUNTU-01:~$ file -i /tmp/ascii.txt /tmp/ascii.txt: text/plain; charset=us-ascii blacknon@BS-PUB-UBUNTU-01:~$ fil
ASCIIとISO-8859文字コードに特化したテキストエディタ「GNU Moe 1.9」が公開 | OSDN Magazine
GNU Project下で開発が進められているコンソール向けテキストエディタ「Moe Editor」プロジェクトは6月28日、最新版となる「GNU Moe 1.9」を公開した。 Moeは「My Own Editor（MOE）」の略で、ISO-8859およびASCII文字コードという「8ビット文字コード」向けのコンソールテキストエディタ。モードレス、使いやすいユーザーインターフェイス、オンラインヘルプ、複数のウィンドウ表示、無制限のundo/redoや無制限のファイルサイズ/バッファ、グローバル検索/置換、自動インデントといった機能を備える。 UTF-8と比較して8ビット文字コードの方が日常のコンピューティングやコミュニケーション作業には適しているという見解から、UTF-8ではなくISO-8859-15をサポートするとしている。8ビット文字セットは、安全性と効率性に優れるとも記している。 G
mysqlで文字コードをutf8にセットする - Qiita
mysqlの文字コードはチェックする場所が多いので原因を突き止めるのに毎回苦労します。 大きく二種類に分けられて、 クライアント側、サーバー側（mysqlサーバー）、及びそれらの接続の文字コード データベース/テーブル/カラムの文字コード です。 デフォルトをきちんと設定しておく そもそも作成したDBの文字コードが意図しない設定になっていたら、デフォルトの設定が間違っている可能性が高いので、再度同じ問題を起こさないためにも、設定見直し→DBをdrop→DBをcreateという順番で直しに行きます。 1も2もデフォルトの設定は下記を実行すればok。 +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+-----------
mb_convert_encodingのautoが危険な理由 - Qiita
mb_convert_encoding ( string $str , string $to_encoding [, mixed $from_encoding ] ) は文字エンコーディングを変換する関数です。 mb_convert_encodingに潜む問題 第3引数の $from_encoding には変換前の文字エンコーディング名を指定しますが、ここを"auto"と指定しておくと、環境によっては Warning: mb_convert_encoding(): Unable to detect character encoding のようなエラーが発生し、文字エンコーディングの変換が失敗する場合があります。 ですので、"auto" は極力使わず、文字エンコーディングを指定することをおすすめします。 autoとphp.iniの依存関係 なぜこのようなエラーが発生するかというと、autoは
JavaScriptで文字コード変換ライブラリ作ってみた
↓動作サンプルを作りました 文字コード変換 動作サンプル Unicode の変換が可能になりました。 文字コード配列から URLエンコード/デコード が可能になりました。 あと説明とサンプルも少し載せました。。(説明不足でごめんなさい) こないだの 「JavaScriptだけでzipファイルの解凍 - Unzipper.js」が SJIS ファイルとかだと表示で文字化けするので、ついつい。。 動作確認は、zip ファイル解凍のデモページでわかると思います。 zip の中に SJIS や EUC-JP のファイル (ファイル名) がある場合でも UTF-8 表示で化けなければ問題なしです。 zip 解凍デモページ ↑のデモページを開いて、デスクトップなどから zip ファイルをドロップすると 解凍して結果のテキストを表示します。 ※ JavaScript だけで動いていて、どっかのサーバなど
javascriptで文字コード変換 - Qiita
概要 javascriptの文字列はUTF-16で String#charCodeAt(i) で取得出来る数値は2byte(0x0000から0xffff)になる。 escape("あ") は UTF-16がそのままエスケープされ "%u3042" になるが encodeURI("あ"),encodeURIComponent("あ") などではUTF-8に変換されて "%E3%81%82" になる。 var str = "文字列をUTF-8に"; var utf8str = unescape(encodeURIComponent(str)); var utf16str = decodeURIComponent(escape(utf8str)); if (str == utf16str) {alert(true);} //=> true とすることで UTF-16<=>UTF-8 の変換は出来
Rubyの内部文字コードはUTF-8ではない...だと...？！｜TechRacho by BPS株式会社
こんにちは、hachi8833です。 少し前に、babaさんから「Rubyの内部文字コードはUTF-8じゃないよ」とツッコミがありました。 （追記: 上は会話の途中から切り取りましたのでご了承ください） いきなりの展開にくらくらきましたが、babaさんはさらにたたみかけます。 こうしたことはとっくにご存じの方も多いと思いますが、「Rubyといえば2.0以来UTF-8完全対応なんじゃないの」と勝手に思い込んでた私は脳に掌底を食らったような思いです。ああ、でもこういうことがあるから面白い。 ⚓ プログラミング言語と内部文字コードの関係 まず最初に押さえておきたい点です。プログラミング言語で文字コードに関連する部分は、「文字列」「正規表現」「入出力」「コード中の文字リテラル（""の中など）」「コード中の文字リテラル以外の要素（変数名など）」「ファイル名」などが中心になります。そして文字列に関連し
.htaccessによる文字化け対策
TypeKey認証やコメント投稿の後で文字化けが発生するという質問を最近何件か頂いています。TypeKeyの文字化けについてはHTTPリダイレクトを伴っており、ページ直前のHTTPレスポンスで返却されたcharsetを見てしまうのが文字化けの要因と思われます（発生するサイトとしないサイトの違いは不明です）。下記のサイトに解説があります。 エンタープライズ：Linux Tips：リダイレクト先で文字化けしてしまう ただしコメント投稿後の文字化けは原因不明（リダイレクトではないという認識）です。 上記のサイトにも少し書かれていますが、リダイレクトによる文字化け解消について .htaccess を利用する方法がありましたのでご紹介します。 １．.htaccess ファイル作成 まず .htaccess というファイルをテキストエディタ等で新たに作成し（既に存在する場合はその中）、そこに下記のいず
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
28800 – non-ascii character cannot display correctly in tui-mode's extended-prompt
Printing utf8 symbols in gdbtui
Loading...
https://mayer.jp.net/?p=4396