I'm using Access with Slavic characters in VBA on many computers without any problems
but on my home computer, that I rarely use, I get problems as VBA (Accesss?) doesn't recognize the encoding.
I get an error at login as the code tries to add the log in entry to datumčas field . I get the error that datum'as is not recognized. The problem is obvious I guess, tables are keeping Central European encoding but the VBA reads it as Western encoding, something like that.
Is there a way to correct this? bypass it? My home computer Windows language is set to Slovenian with Slovenian and English installed, but I guess those settings are the same on other computers.
I changed the Windows system locale to Slovenian and now it works well. I guess I was fancy at setup and went with the US locale.
Related
I'm relatively new to Django and am looking to read my MySQL connection info from a file using the read_default_file process. I test this on Windows and it seems to work perfectly. I move to my linux pre-prod server and i get an issue access issue. Through countless hours of testing, i find that the issue seems to be with my password contains a special character # and it seems that this process is translating that to mean the start of a comment. I have no control over the password and need to be able to handle this character. on a side note, if i load the details directly into my django app (settings.py) then i have no issue and all is fine, but if i try to offload them into my conenction file, this situation arises.
I have looked but cannot seem to find a way to escape the PW to handle this character (and arguably others). What am i missing and is there a way to handle passwords with special characters like my situation?
Cheers!
I feel I'm a bit in over my head on this one. I have developed an ASP.Net MVC website for a friend that allows them to paste in Hebrew words and it does some conversion/translation. I am using MySQL as a data backend with ASP.Net MVC 5.
The website is fairly simple. The database consists of two tables which store letters, and translations. I am using MySQL EF6 for data access layer. There are basically three screens on the website, one for managing each table, and one for doing the translations.
When I run it in my development environment (VS 2017/Windows 10), everything works as expected. I can edit data using the Hebrew Unicode characters and they save properly to the database. Here is an example:
When I click Save, I expect those values to be saved to the database, and they work fine. However, I have recently converted the website to run on a Mono/Ubuntu environment for hosting. I got the environment setup using mod_mono and Apache2. Everything is working perfectly, except when I save a page like this, the Hebrew character א gets converted into a question mark (?):
Here's what I've determined so far.
I know Apache/MySQL is setup properly to handle these values, because the data displays fine. It only gets messed up when I save it.
I am also running PhpMyAdmin on the same server, and when I modify that same row through the table editor, it does not mess up the encoding.
I've tried adding the Default Encoding utf-8 to the Apache configuration with no luck.
I've tried adding globalization with default encodings of utf-8 to web.config and it didn't help.
How do I troubleshoot where the value is getting messed up? Is there a simple solution I need to apply to fix this?
Thanks!
The bytes to be stored are not encoded as utf8/utf8mb4. Fix this.
The column in the database is CHARACTER SET utf8 (or utf8mb4). Fix this.
Also, check that the connection during reading is UTF-8.
HTML forms should start like <form accept-charset="UTF-8">.
For more discussion, see Trouble with utf8 characters; what I see is not what I stored
If that is not enough to solve your problem, find the HEX, as discussed in "Test the data" in that link; then ask for more help.
I have an old site where visitors can add their comments. Until now it always worked well, it doesn't have many visitors (it's for a niche audience). It was built in classic ASP and it's using MySQL (now 5.6). It's running on IIS 8.5 and it connects to the DB without DSN.
Whenever someone adds emoji characters to their posts it'll make the IIS service go into some kind of loop using more than 60% of the CPU and never stops.
I do not want to filter these characters out, I think they fit in well with the site's premise, however I did not foresee this issue. When I first set up MySQL I used UTF-16 to make sure my users could write in any language, and I never had issues until now. There are messages in what looks like Japanese and Korean, and I only figured out it was an issue with Emojis when a user told me what he was doing when the site crashed on him.
All the site's pages/files are saved in Unicode and for all of them the charset is set as "utf-8".
The database's collation is utf16_unicode_ci and so are the tables'.
I can insert Emojis into the tables directly from command line or via HeidiSQL, however....
The server is sending the Emojis as question marks (?).
Here's my connection string:
Driver={MySQL ODBC 5.3 Unicode
Driver};Server=...;User=******;Password=******;Option=3;charset=utf16;
Use CHARACTER SET utf8mb4 end-to-end in MySQL.
I know this question has been asked in many forms before but I could not find an answer to my specific question.
THE SCENARIO
Database Mysql, West European - Latin 1
Exported using sequel pro to sql file
Reimported the exact same file and had quotes, apostrophes, em dash, en dash, TM, Reg characters turn to question marks.
I fixed these by opening the sql file in vim and replacing the <94>, <95>, ect. hex codes with their correct counterpart.
Reference:
:%s/<93>/\'/g
Source
MY QUESTION
How can I prevent this from happening in the future? My guess is that these characters are being pasted in from a word doc in the admin part of the website but I don't understand why it re-imports incorrectly. For now, I have replaced all the characters and everything is close to normal. Should I convert the table to utf8? I do have several translations of the site in the DB.
NOTES
I have exported this database several times before and never had this problem. I have exported it to a staging server (which is the same server as the live server, just a different host) and a local server. Any ideas of why this might happen all of a sudden?
I have looked into a lot of issues like double character encoding and wrong encoding formats but I think this situation is different. I also tried several of those solutions and they did not work.
Similar Questions
Special characters get lost in MySQL export/import
We are hosting a contest on our site that is open to the international community. A small percentage of our users are Japanese and have asked to be able to post comments on our site using Hiragana.
Currently, their comments show up as strings of ?????? question marks.
We are using a Win 2008 server running IIS 7 and Coldfusion 10. The DB where the comments are stored (and also appear as ?????? question marks) is SQL Server 2012.
The site is currently using the UTF-8 charset:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
Not sure where I need to make changes. DB? CF? Windows? IIS? Website code? Any ideas?
I've found other similar questions, but they usually have to do specifically with WordPress, Joomla, or site's that are entirely Japanese.
Thanks!
You might claim you are using UTF-8, but are you really? If your database, strings (the programming language might need to be told to handle strings as UTF-8), and actual output encoding aren't UTF-8, then you won't get proper results.
Then here is the font issue; many characters are not included in every font and thus don't work on a lot of computers.
Also try setting headers like this as actual headers.
collation has nothing to do with this neither do fonts (your unicode data is getting garbaged going into the db). so...
you should be talking to your db via one of the JDBC drivers not ODBC.
your db should be unicode capable & you must use unicode capable datatypes to hold the data (eg, for sql server use the "N" datatypes like Nvarchar, etc).
i assume you're using cfqueryparam (its a user facing form after all), so you need to enable the "Enable High ASCII characters"... option for that datasource in cfadmin (under the advanced menu).