I have purchased RapidPHP just two days ago because I liked the UI very much. Unfortunately there seem to be quite some functional problems with the software.
Occasional access violations I don't want to analyze here since there are not easily reproducible.
Encoding problem:
1. I created a user template with UTF-8* encoding.
2. I create new document from it by New from template...
3. Everything looks OK, there UTF-8* in the status bar. I save the document in my project folder.
4. After RapidPHP is restarted, this document has ANSI encoding in the status bar!
Default encoding in the Preferences (Files->General) is set to UTF-8 without BOM.
System:
WinXP SP2
RapidPHP 8.0.2.77
Inconsistent encoding at saving files
Moderator: kfury77
Forum rules
Please try to follow these guidelines. This will help to receive faster and more accurate response.
Please try to follow these guidelines. This will help to receive faster and more accurate response.
- Check the Support section of the corresponding product first. Chances are you will find your answer there;
- Do not create new topics for already reported problems. Add your comments to the existing topics instead;
- Create separate topic for each problem request. Do NOT post a number of non-related problem reports in a single topic;
- Give your topic a meaningful title. Titles such as "A question," "Bug report" and "Help!" provide others no clue what your message is about;
- Include the version number of the software you are using;
- This is not an official customer support helpdesk. If you need a prompt and official response, please contact our support team directly instead. It may take a while until you receive a reply in the forum;
-
Karlis
- Site Admin
- Posts: 3605
- Joined: Mon Jul 15, 2002 5:24 pm
- Location: Riga, Latvia, Europe
- Contact:
Actually this is how it should be. Please let me explain.
UTF-8 without BOM means that file will be saved with special chars encoded in UTF-8 format, however without the byte order mask that marks the file as UTF-8. So if you choose this encoding, the file is not marked as UTF-8 by its header - it is a simple text file but with special chars encoded like in real UTF-8
Now if your file happens not to contain any special characters then it IS a simple text file and it is NOT possible for any software on earth to detect it as UTF-8 because it is not.
When existing file is opened Rapid PHP, it tries to detect the encoding, however if the file does not have BOM and also does not have any special chars, it is detected as simple text file.
A solution that enforces UTF-8 would be to use UTF-8, but not UTF-8 without BOM.
UTF-8 without BOM means that file will be saved with special chars encoded in UTF-8 format, however without the byte order mask that marks the file as UTF-8. So if you choose this encoding, the file is not marked as UTF-8 by its header - it is a simple text file but with special chars encoded like in real UTF-8
Now if your file happens not to contain any special characters then it IS a simple text file and it is NOT possible for any software on earth to detect it as UTF-8 because it is not.
When existing file is opened Rapid PHP, it tries to detect the encoding, however if the file does not have BOM and also does not have any special chars, it is detected as simple text file.
A solution that enforces UTF-8 would be to use UTF-8, but not UTF-8 without BOM.
Thank you for the explanation!
You are absolutely right about the BOM issue, but in such a case where the encoding of a file is unclear because of that, I would expect the program to use the default encoding I set in the preferences!
There are still more similar issues:
If I create a new file by a right click from the project view ->New file... then it is open as ANSI as well, despite my Unicode default setting.
Cheers,
Kybos
You are absolutely right about the BOM issue, but in such a case where the encoding of a file is unclear because of that, I would expect the program to use the default encoding I set in the preferences!
There are still more similar issues:
If I create a new file by a right click from the project view ->New file... then it is open as ANSI as well, despite my Unicode default setting.
Cheers,
Kybos
Hi Karlis,
my first point from the message above is not 100% plausible. I checked the setting in the preferences once again and it says in the frame title: 'Encoding for newly created files'. In this respect you are probably right not to use it for already existing files.
So there seems to be some 'deeper' default setting which tells the program to choose ANSI if it's not sure about a file's encoding. Can this be changed in some way? I would like to have 100% unicode program. I hate ANSI
.
By the way: I would not mind if there were a real ANSI support but this is obviously not the case.
I am not able to properly load an older site of mine which is ANSI (win-1250 = East European languages). All special characters get broken on loading the files, despite my font setting with East European script.
Am I doing something wrong here? Or is your variant of ANSI only supporting West European (Latin-1) languages?
Thanks, Kybos
my first point from the message above is not 100% plausible. I checked the setting in the preferences once again and it says in the frame title: 'Encoding for newly created files'. In this respect you are probably right not to use it for already existing files.
So there seems to be some 'deeper' default setting which tells the program to choose ANSI if it's not sure about a file's encoding. Can this be changed in some way? I would like to have 100% unicode program. I hate ANSI
.By the way: I would not mind if there were a real ANSI support but this is obviously not the case.
I am not able to properly load an older site of mine which is ANSI (win-1250 = East European languages). All special characters get broken on loading the files, despite my font setting with East European script.
Am I doing something wrong here? Or is your variant of ANSI only supporting West European (Latin-1) languages?
Thanks, Kybos
-
Karlis
- Site Admin
- Posts: 3605
- Joined: Mon Jul 15, 2002 5:24 pm
- Location: Riga, Latvia, Europe
- Contact:
Using UTF-8 with BOM should solve the problem, because it marks all files properly as UTF-8 according to specification. And once saved in UTF-8 (with BOM), file is tagged as UTF-8 even if it does not contain Unicode symbols.
Alternatively it is easy to switch encoding (two-clicks) by clicking on status bar section that displays encoding.
Alternatively it is easy to switch encoding (two-clicks) by clicking on status bar section that displays encoding.
You are right again.
Unfortunately UTF-8 with BOM is not an option for PHP files sending a header since the BOM is causing PHP errors in that case (nothing must precede the http header, not even BOM...).
A solution for this dilemma (used by some other HTML and text editors as well) is to parse the file for "charset=utf-8" string - if found, then the file should be opened as utf-8.
Could you please consider this? That would solve the problem for most html/php files.
Another option would be to offer a default setting in preferences for files with unrecognized encoding or even let the user decide on opening such a file with a dialog...
The situation as it is now is very error-prone. I know I can switch the encoding variants easily but that means that I would have to be checking this all the time, and also if the special chars in my documents are not broken (it's not always obvious at the first sight in some languages) - this is simply not feasible...
Thanks, Kybos
Unfortunately UTF-8 with BOM is not an option for PHP files sending a header since the BOM is causing PHP errors in that case (nothing must precede the http header, not even BOM...).
A solution for this dilemma (used by some other HTML and text editors as well) is to parse the file for "charset=utf-8" string - if found, then the file should be opened as utf-8.
Could you please consider this? That would solve the problem for most html/php files.
Another option would be to offer a default setting in preferences for files with unrecognized encoding or even let the user decide on opening such a file with a dialog...
The situation as it is now is very error-prone. I know I can switch the encoding variants easily but that means that I would have to be checking this all the time, and also if the special chars in my documents are not broken (it's not always obvious at the first sight in some languages) - this is simply not feasible...
Thanks, Kybos
No, incredibly enough, this highly annoying and most obvious PHP bug is not going to be solved until PHP release 6 ...
See http://bugs.php.net/bug.php?id=22108
It will take years before all web providers get PHP 6 ...
See http://bugs.php.net/bug.php?id=22108
It will take years before all web providers get PHP 6 ...
