I use Macs.
For years I have been updating the content of an ExpressionEngine website based on PHP/MySQL. This process involves linking the content of InDesign pages to a Filemaker database, exporting specified fields to an Excel spreadsheet and using Navicat to update corresponding fields in the MySQL database. I know from experiments in linking Filemaker directly to MySQL that character encoding is a minefield.
The process I have outlined has always worked OK, provided in the Navicat import step I specify that the Excel spreadsheet is using Mac OS Roman encoding. This year, however, the result of the updating was garbage where I should have accented characters or fancy "typesetting" characters - en rules, inverted commmas etc.
What had changed? Well, I am using a new Mac, running Yosemite. I still have my old iMac, now in use as a second display, so I went back to that. Result: perfect. No garbage.
I have of course checked that the Excel file's text looks OK. (I am using the same file on both Macs, shared via Dropbox.) I'm running the same version of Navicat on both Macs.
So what is Yosemite doing to cause Navicat to stuff different characters into MySQL? And how can I stop it?
Chris
Related
I'm using Laravel 5.1 on Ubuntu PHP5.6 and the GUID to string conversion is working just fine. However on my development environment in PHP 7 it's pritining out like how it used to when I had to use the old mssql driver that came with php.
So all my string comparisons are failing on 7 for GUID's saved in mysql.
My gut says that some PDO setting that's not being set correctly. The query in question is using the DB class to fetch data through a raw sql. I think Eloquent is rendering correctly, I've not seen this problem before and I've been using it throughout (this is an older code base before I leaned additional tricks I currently use to work with this database)
Any ideas where I can start looking.
Turns out it was the particular set of credentials and set up for the software that was causing the byte problem. I was logging in fine but changing the connection string fixed the problem.
Here is the situation:
I'm using UTF-8 to input Japanese characters into a MySQL database, using a php form. However while done from my PC it works perfectly and the script records the characters correctly into the DB, but from other PCs the script inputs raw symbols. I've declared completely all the things regarding the UTF-8 header, meta tag, etc. I'm sure this is not a php/sql issue, (because it works perfectly from one pc) but something from windows configuration I cannot understand.
Anyone knows something regarding this issue?
I have a small mySQL database and a few simple php based webpages that query the database, generate html tables and present them in the browser. The database is no longer being updated. So, searching and viewing subsets of the data is all that is required.
Some users are interested in distributing the searchable database on a cd or usb memory stick. SQLite seems to offer the answer, but I don't understand what is needed to make this work. What will be required to make a web browser based "app" work from a memory stick in the absence of a server like xampp?
XAMPP Lite from http://portableapps.com/apps/development/xampp
What you want is called a "standalone server". This is very common in almost every other modern language except PHP, for some reason. Googling "standalone php server" reveals several options:
QuickPHP
Nanoweb
Server2Go
Is it possible to write .MDF files using PHP. I have a simple HTML table - x columns, y rows that I wish to convert into a MS Access dataset. There are no foreign keys or anything exotic, just a number of rows and columns.
I have Google searched but the only advice I seem to be able to find is to save it as a .CSV. Unfortunately this isn't acceptable for my client. They want to simply be able to double click the icon and have the database load up in Access (Seems you have to import csv files and can't just double click them).
Those are actually two different problems:
1) Parsing HTML to separate values
Since you seem to have found a way to export to csv, I won't be answering this. You already got your parser then.
2) Create an mdb file.
You can use odbc to talk to Access, that is, if you are in Windows. That means that PHP must be installed on a Windows machine. I'm not aware of any Linux drivers for Access..
You can use odbc_connect to connect to the database:
$conn = odbc_connect("dbname","" ,"");
From there, working with the database is pretty similar to MySQL as long as you use the ODBC functions.
The only problem is creating the actual MDB. This cannot be done in ODBC, you'll need the JET engine. It may be possible to create an MDB file from PHP, but it may be easier to create an empty MDB once, and copy that file from PHP whenever you need a new database.
Jackcess is a pure Java library for reading from and writing to MS Access databases. It is part of the OpenHMS project from Health Market Science, Inc. . It is not an application. There is no GUI. It's a library, intended for other developers to use to build Java applications.
http://jackcess.sourceforge.net/
But an MDF file is not a standard Access file extension. MDB and MDE are while MDW is for user level security.
Have not tested this but this might help you:
http://devzone.zend.com/article/4065
Note that active development of MDB Tools has moved from Sourceforge to Github
https://github.com/brianb/mdbtools
For the last years I used Notepad++ on Win XP SP2.
As I just have seen, the setting in Notepad++ is to encode new files in "ANSI" in "Windows Format". Basically all files on my harddisk should be ANSI files then, but I'm not sure.
Most .html-files have a charset-tag as "text/html; charset=iso-8859-1", but some have none.
Other files, especially text-files (for example keyword-lists) I stored with Firefox XPCOM-system, I don't know how they are currently encoded.
On Server-side I have Apache with PHP and MySql.
For Upload I used Filezilla.
Now the problem is: I want to use Japanes signs (or arabic, etc.). This only works partly.
I can get my selfmade Firefox-Application to constantly write or read UTF-8. But I can't check everytime which of the old files is which encoding.
Having just read Joel Spolsky's old article about UTF-8 strengthens my view that I simply have to get my whole system changed as much as possible to UTF-8.
As long as I have it running that way locally on my Hard-Disk I could just re-upload everything to the server.
So: How do I get all my files locally transfered to UTF-8?
And: Is it possible at all to have Win XP SP2 using constantly UTF-8 everywhere? Or do I have to check it with every program, or even worse with every file, that the right encoding is to be used.
How about files I get for example in E-Mails or via an USB-stick, or that I download in zip-files? (Or a thousand possibilities more.)
Update:
1.-4. went OK so far. I tried first with BOM, but without seems to be better.
So to 5.) Something I have to change there too. I changed as in 3.) the charset in the html-template-file, and the text coming from the template is displayed correctly. But the text coming from MySql/Php shows the UnknownChar-sign at some places currently, i.e. where there should be Umlaute äöü.
I have changed all collations for text fields in the MySql-Database via phpmyadmin to "utf8_unicode_ci", but that didn't do the trick.
Is it a php-issue, or do I only have to convert somehow the data in the MySql-Database once?
The beauty of UTF-8 is that it's a superset to ASCII, so if your html and php files only contain Latin alphabets (i.e. English and programing/HTML syntax), you don't need to convert the file at all. You can leave most of your file unchanged.
Should you find few exceptions that you want to convert it manually, you may open them up in Notepad++, and do 'Encoding' - 'Convert to UTF-8 (No BOM)'.
Yes, you do need to change/add <meta> charset tag to all the HTML files to make sure the browser render your files in UTF-8.
In Notepad++ you could set the new file to always open with 'UTF-8 (No BOM), Unix'. Also, check the tick on "Apply to ANSI files" so old file can be correctly saved to the new encoding. I suggest the format is because even though you are working on a Windows machine, the web servers usually runs Linux/BSD so the format is the native form (keeping files in native form is important especially when you are using a version control system).
Migrate a live site with database is a different issue. Data in MySQL comes with their own encoding, and from your question I cannot tell if you need to do it and how to do it. Need more specifics on that (if you need to).